Weaponizing Web 2.0

WASHINGTON POST - Imagine simply visiting a Web forum and finding that doing so forced your browser to post an embarrassing Twitter message to all of your contacts, or caused you to admit a stranger to your online social network. Now consider the same dynamic being used to move money out of your online auction account or delete the contents of your e-mail inbox.

These are just a taste of the Web 2.0 cross-site trust issues explored in a talk delivered at the Black Hat security conference in Las Vegas today. The presenters, researchers Nathan Hamiel and Shawn Moyer, delivered a related talk at Black Hat last year called "Satan is on my Friends List," that was highly entertaining and relevant to similar trust concerns that plague dozens of social networking sites. And since I am unfortunately not going to be at Black Hat this year, I wanted to catch up with them again to see what they've cooked up this year.

In this year's talk, entitled Weaponizing the Web, Hamiel and Moyer demo a new tool that makes it simple for bad guys to force a user's Web's browser into taking actions on behalf of that user without their permission or knowledge.

While the tool could be used to attack others online, it could also help site owners better visualize how to protect their sites from this kind of attack, the researchers said.

The tool takes advantage of a new twist on an old form of attack known as cross-site request forgery (CSRF), called "dynamic CSRF." In the classical CSRF attack, the perpetrator tricks the victim into loading a specially crafted page designed to perform an action on a specific site where the victim is already authenticated.

For example: A relatively benign CSRF attack takes place on a Web forum, wherein Alice browses a posting left by Bob. Unbeknownst to Alice, Bob has included in his message a booby-trapped image that takes advantage of the fact that she is logged in to that forum in an active session. Inside that image is a link tag that includes the URL needed to post messages on that forum. Once that image loads on Alice's machine, the embedded link posts a message in her name to the forum, via her browser, without her permission.

More serious CSRF attacks can be used against victims who are logged into an online banking account, forcing the target to initiate an unauthorized withdrawal or transfer from that account. Indeed, as phishing expert Lance James wrote in his book "Phishing Exposed," the beauty of cross-site request forging is that all requests an attacker wants to make will appear to come from the victim while the victim is at the "trusted" site.

The typical defense against CSRF attacks is for a Web site to include a unique, alphanumeric token in each link that is requested or generated after the user has logged in. This token is then stored on the Web server where the visitor is interacting. If subsequent requests from the visitor's Web browser do not also include that same token in the URL, the Web server will assume that someone or something else has intercepted or manipulated that request, invalidating that browsing session.

The problem with the token-based security approach, as researchers prior to Hamiel and Moyer have noted, is that it works only if the attacker doesn't have access to that random string of data as well.

To take the Alice and Bob on the forum example a step further, consider what happens when Alice views a forum posting by Bob that includes a link to an off-site image hosted at a site controlled by Bob. That image, when loaded by Alice's browser, will automatically send Bob's site a referrer URL that includes the full token that is unique to Alice's browser session with that forum. Armed with the referring URL's token, Bob can then respond to the image request from Alice's browser with a request to silently take action on that forum in Alice's name.

The two researchers say they plan to release a Web-based tool at Black Hat called "monkeyfist," which automates this process to some degree for a number of high-traffic sites, including Wikipedia and Livejournal.

"We've come up with a way to take those tokens and repackage them on a payload-per-domain basis, with different types of payloads based on the referring site," Hamiel said. "So, if it's linked off of Twitter, the tool might respond one way, or if it's linked off of something like LinkedIn, it might respond another way."

Moyer said one way to prevent this attack is commonly used on banking Web sites involves what's known as a nonce, which is essentially a random, one-time-use-only number that is appended to a URL each time a visitor loads a page on that site. He noted that one reason most sites don't adopt this approach is that it requires far more computational and Web server capacity, which can drive up costs -- particularly for high-traffic sites.

A copy of Moyer and Hamiel's white paper on this talk is available here.