Risk

3/29/2007
07:45 AM
Connect Directly
Google+
Twitter
RSS
E-Mail
50%
50%

Killer Combo: XSS + CSRF

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

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."

— Kelly Jackson Higgins, Senior Editor, Dark Reading

  • Ernst & Young International
  • Black Hat Inc. Kelly Jackson Higgins is Executive Editor at DarkReading.com. She is an award-winning veteran technology and business journalist with more than two decades of experience in reporting and editing for various publications, including Network Computing, Secure Enterprise ... View Full Bio

    Comment  | 
    Print  | 
    More Insights
  • Comments
    Newest First  |  Oldest First  |  Threaded View
    Brother Printer Support
    50%
    50%
    Brother Printer Support,
    User Rank: Guru
    7/3/2018 | 8:03:39 PM
    AOL Support
    I have shared the support bright, there are technical any issues there then go to support for help, but I need to what kind of support, Which supports give the proper resolution. Then My friend suggest that , I thought its helpful AOL Support
    White House Cybersecurity Strategy at a Crossroads
    Kelly Jackson Higgins, Executive Editor at Dark Reading,  7/17/2018
    The Fundamental Flaw in Security Awareness Programs
    Ira Winkler, CISSP, President, Secure Mentem,  7/19/2018
    Register for Dark Reading Newsletters
    White Papers
    Video
    Cartoon Contest
    Current Issue
    Flash Poll
    Twitter Feed
    Dark Reading - Bug Report
    Bug Report
    Enterprise Vulnerabilities
    From DHS/US-CERT's National Vulnerability Database
    CVE-2018-14492
    PUBLISHED: 2018-07-21
    Tenda AC7 through V15.03.06.44_CN, AC9 through V15.03.05.19(6318)_CN, and AC10 through V15.03.06.23_CN devices have a Stack-based Buffer Overflow via a long limitSpeed or limitSpeedup parameter to an unspecified /goform URI.
    CVE-2018-3770
    PUBLISHED: 2018-07-20
    A path traversal exists in markdown-pdf version <9.0.0 that allows a user to insert a malicious html code that can result in reading the local files.
    CVE-2018-3771
    PUBLISHED: 2018-07-20
    An XSS in statics-server <= 0.0.9 can be used via injected iframe in the filename when statics-server displays directory index in the browser.
    CVE-2018-5065
    PUBLISHED: 2018-07-20
    Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have a Use-after-free vulnerability. Successful exploitation could lead to arbitrary code execution in the context of the current user.
    CVE-2018-5066
    PUBLISHED: 2018-07-20
    Adobe Acrobat and Reader 2018.011.20040 and earlier, 2017.011.30080 and earlier, and 2015.006.30418 and earlier versions have an Out-of-bounds read vulnerability. Successful exploitation could lead to information disclosure.