Cenzic 232 Patent
Paid Advertising
web application security lab

Attacking Applications Via XSS Proxies

Attackers can use Cross site scripting (XSS) as a proxy to perform website security auditing. Jeremiah Grossman and I have been toying with this idea for a while now, but it occured to me much later, that we never got into the basics of how this could work. The basic premise is that by using Cross Site Request Forgeries (CSRF), I can get users to perform systematic security penetration tests against web application targets of my design.

Typically XSS works in this way: You have a site that you want to attack, and by injecting HTML into it the users who go to that URL are then fooled into entering their credentials, or the information that is sent via the browser (like cookies) are logged off host. It’s a very direct path, that doesn’t leave much room for obfuscation. The other problem is that testing the application to find the vulnerable cross site scripting holes can take a lot of poking, and all the while you are leaving signatures all over the host.

You may get around that by using a proxy, but here’s an idea. Why not use existing users as your proxy? All it takes is one compromised host, or another site that is frequented that you can inject HTML into. So I have random site “A” that is not the ultimate target, and the victim site “B” that you are interested in. I inject HTML into site “A” and the visitors of that site stumble accross the injected XSS. That XSS tells their machine to connect to site “B” and test for a simple exploit (say another XSS hole - just to make this easy).

The first XSS vulnerability in site “A” runs a series of attacks against known potential holes, like in PHP nuke, or whatever. Those attacks attempt to inject HTML and JavaScript. That JavaScript contains a script to post cookies (or anything really) and the exploit that worked to a remote machine somewhere named “C” (this could be a bullitin board or anything - it doesn’t matter, as long as it accepts incoming anonymous requests and logs them in a way that you can view later). The script will continue to run until the user navigates away from the page on site “A”. When site “B” is found to be vulnerable, the user automatically sends their own cookies to site “C” along with the vulnerable URL and string that worked.

Now the bad guy simply needs to go to site “C” and look for any string that might have worked. Voila! Now what did the victim host “B” see? They saw an IP address connect to their machine and perform a series of XSS attacks. They may see one succeed, but either way they can no doubt see where the information was intended to be logged on site “C”. You can remove site “A” from the logs by using a series of META refreshes so it doesn’t show up in the referring URL (as META refreshes remove the referring URL). The important part here is that the real attacker’s IP address never shows up in the log files of the victim, site “B” and it is highly unlikely that the user who’s machine is being used as an attack relay probably won’t have any idea about what is going on.

Here’s a diagram that should help explain it:

cross site scripting can act as a web application security penetration proxy
Click to enlarge

Cross site scripting is probably the most important initial vulnerability to find, because that will then open the doors to remove the browser cross domain policy issues so you can perform more interesting attacks, like SQL injection and code injection. Once those attacks are performed they will need an XML RPC call (requiring cross site scripting) to send the data that is outputted to a logging remote host (site “C” or otherwise).

In this way you can use XSS to completely proxy all of your web attacks so that the victim in question (site “B”) will never see the originating IP address. This does rely on having two other cross site scripting vulnerable machines at your disposal, but those are a dime a dozen. This concept really falls into the category of XSS malware (a term coined by Jeremiah) where XSS goes beyond a simple way to inject HTML, but actually can be used as a launch pad by which to initiate much more destructive attacks.

7 Responses to “Attacking Applications Via XSS Proxies”

  1. Dave Says:

    Sure, this method is pretty secure, if you want to find out some xss holes.
    Some of my minds:
    - In some cases (don’t no why) the browser redirected by a meta refresh submits a referrer.
    - It lasts a lot of time and gets more complicated. Typing is much quicker - as you can see and reverse the rules that your input is filtered
    - Do you know http://xss-proxy.sourceforge.net/ ? Didn’t take a closer look but it seems to be interesting

  2. WhiteAcid Says:

    This is a great idea, but I think that finding an XSS hole using this could take too long. On the other hand, if it’s an application such as phpbb, phpnuke etc, then you could find the XSS on your localhost and simply initiate it on the victim site this way. That way you’re still anonymous and it’s done quickly. Of course you’re not always using XSS holes in software that you can install locally to test.

  3. RSnake Says:

    Hi, Dave, I’m not aware of any situations where Meta submits a referrer (if you can isolate an example of it, I’d be very curious to see it). If you’re right, it should be fairly easy to code against it, since you are already running JS on the machine in question. Typing is definitely quicker, but the issue isn’t speed, it’s getting caught. And, yah, I’ve checked out xss-proxy, that’s a very different type of proxy (and certainly anything but anonymous). ;)

    WhiteAcid, yes, again, the duration is almost irrellevant, since you aren’t against a time constraint. You could probably speed this method up by surfing the site initially, as a normal user (without doing anything weird). The recon could uncover all the form submission boxes, and QUERY_STRING params, so that you could more effectively target the host in question via the variables it uses. But, yes, if it is running a common exploitable application I’d try the known holes first.

  4. ha.ckers.org web application security lab - Archive » Expect Header Injection Via Flash Says:

    […] The ramifications for this are huge. Being able to run any JavaScript you want one just about any website has some very serious issues. Of course you still need to get the user to view your Flash movie, so this has no added security issues if you always know where you are clicking, and the website itself has no cross site scripting vulnerabilities. However, if the site has XSS holes, or you are directed off site, suddenly all of your information is now able to be leaked via XML over RPC. If you happened to be logged into a major website that has the Expect issue flaw, your cookies can be stolen, any page that you have access to can be scraped. You can be used as a tool to launch XSS proxy attacks. This definitely goes into the JavaScript Malware bucket. […]

  5. richie Says:

    isnt it possible to use this trick for google adsense and increase our revenue

  6. Mobile User Says:

    Really it’s gud technique to rewrite HTML content of any site and we can take maxi benefit through this script. But Any one suggest me some gud site where i can get tutorials on this….

  7. RSnake Says:

    In re-reading this, I should point out that this would also work for remote file includes, command injection and SQL injection.