4 X Security Team

Researchers mix cross-site scripting and cross-site request forgery together in a deadly cocktail


MARCH 29, 2007 | Researchers will demonstrate a lethal combination of cross-site scripting (XSS) and cross-site request forgery (CSRF) attacks tomorrow at Black Hat Europe in Amsterdam.

The goal is to show the danger of the two pervasive Web vulnerabilities teaming up in an attack. "Cross-site scripting has its strengths and limitations. Cross-site request forgery has its strengths and limitations," says Billy Rios, senior researcher with Ernst & Young's advanced security center. "We will show how when you use the two in combination, you can use the strength of one to overcome the weakness of the other." (See CSRF Vulnerability: A 'Sleeping Giant'.)

XSS bugs are rampant in Websites and have been well-documented by hacker groups such as sla.ckers.org. And CSRF, which is a bit more complex to execute in an attack, is just as pervasive, Rios says, but has mostly been ignored so far because there's no real solution for detecting it. "We're in a stage now where people know about it, but are ignoring it, and that's kind of dangerous." CSRF hasn't hit the front burner yet mainly because it's tougher to detect than XSS and other threats, he adds. (See Hackers Reveal Vulnerable Websites.)

But Rios and colleague Raghav Dube, also a senior researcher with E&Y's advanced security center, consider any type of one-two punch attack exploiting multiple client-side Web vulnerabilities -- not just XSS and CSRF -- a serious problem. "Any kind of client-side vulnerability that's leveraged by using it in combination with another one expands your arsenal [as an attacker]. It's more dangerous," Rios says, and the next big thing security experts need to be on the lookout for.

The researchers will release the client-side JavaScript code they developed for the two attacks, including the payloads. "We're not going to release our XSS proxy," Rios says. "We want people to understand you don't need my tool to pull this off. You have all you need already on the Net to do those attacks."

In the first attack, the researchers show how to take over a user's account via XSS and use that browser to attack another Website. In the demo, the user first visits a social networking/blogging site, which is easier to get XSS-infected due to the ability to upload content, post messages/comments, etc. But the attacker's real target is a large credit union site. It works like this: Once the user falls victim to the XSS exploit on the social networking site, XSS is used to take over the victim's browser, Rios says.

"In the grand scheme, we don't actually care about the social networking site," he says. The attack then uses CSRF to link between the social networking site and the credit union site, he says. "Once we control the victim's session with the social networking site, we can force and control a session between the browser and the credit union site."

From there, the attacker can attack the credit union site. "We will go into techniques for attacking the credit union, but it's actually the victim that is doing it" unknowingly with their browser, he says. And the victim would have little or no clue the attack was underway, Rios adds. The advantage of combining XSS and CSRF here is that it lets the browser move to different Web domains, not just a single one.

The second attack demo shows how XSS and CSRF can be used to do damage to an internal corporate network. "Because we're using the victim's browser to do these attacks, we can take advantage of all the privileges and trust established by their browser," Rios says. "Because it's inside the corporate LAN, we can drive it to attack other machines inside the firewall. The age-old moat-around-the-internal-net model is basically thrown out the door because our staging point is inside the internal net."

The victim's browser then attacks a network management system on his internal network. CSRF is then able to get information on the internal network. And if the attack is caught or traced back, it's on the victimized user's doorstep. "If they kick down the victim's door, the evidence is on that machine. It was [his] browser that did the attack," and he didn't even know it, Rios says.

And XSS lets CSRF work more two-way instead of just one way: "CSRF alone is a one-way deal," Rios says. "You do the attack and hope it executed. The only way to verify it is through a secondary channel. With XSS, you can verify the CSRF went through, and you get instant feedback."

The demos show targeted attacks on a specific user, but Rios says it would be easy to automate it across multiple users. "We're trying to show that this doesn't require that much sophistication to exploit."

[Source: darkreading]