Admin Kunal Vohra
After reading Incapsula’s blog post about how an “Alexa Top 50″ website suffered an XSS vulnerability which hacker(s) used to attack a victim domain it got me thinking. The attack simply preformed an XMLHttpRequest to the victim domain on a continuous loop to flood the target with rogue GET requests.
The snippet provided by Incapsula:
This attack seemed very simple and perhaps was just a test of the functionality of this attack.
Clever, the attacker uses an XSS vulnerability in a popular site to make uninfected victims attack a target domain. No need for dirty exploit packs and keeping malware under detection from AV! Although a simple patch from the vulnerable site could stop this exploit pretty quickly.
Better XSS DoS Attack?
So our biggest fear as a hacker would be:
- The vulnerable site figuring out our madness and fixing their vulnerable site
- The victim site figuring out where the attack originated from and contacting the vulnerable site about it
- The victim site being able to filter out these malicious requests from happening
- Not causing enough damage with the flood of requests coming in (think more bang for your request!)
- Finding a vulnerable site with lots of traffic and persistent viewers
Here are a few tricks that a hacker could use to make this type of attack even stronger and more stealthy.
Request the Most Resource Intensive Page
Every request counts – a hacker should ensure that his victim’s flood isn’t going to waste. Choosing a page which upon request would cause the most backend work is an important part.
For example a request for:
http://victim.com/index.php
Wouldn’t be as resource intensive as:
http://victim.com/search.php?query=e&category=all&results=100
The second URL would cause a considerable amount more work on the victim’s server. Searching for the letter “e” in the entire database is a pretty exhaustive action!
Even worse if a site had a page such as:
http://victim.com/email_us.php
Without any sort of CSRF token protection, chaining the vulnerabilities together could cause one hell of a headache! A bunch of XMLHttpRequests hammering an email contact form could end very badly indeed.
The possibilities are quite endless especially when you start chaining together other “low risk” vulnerabilities.
Hide the Source with Link Shorteners and Open Redirect Chaining
Hiding the source of the attack is probably a good idea as well, if the victim site sees lots of “Referer” headers pointing to “hacker-site.pw” or “vulnerable-site.com” they may investigate.
A better route would probably look more like this following:
[ Vulnerable Site XSS ] -> Hacker Site With Redirect -> Link Shortener -> Victim Site Search Query
That seems like a pretty long chain but it has the advantage of having the referer come out as a link shortener service and not the hacker’s site or the vulnerable site. It also allows flexibility to swap out link shortening services if a link is marked as bad or deleted.
What about chaining another vulnerability to make things better? What if our victim site was vulnerable to open redirect? Perhaps just a random site with an open redirect vulnerability?
[ Vulnerable Site XSS ] -> Hacker Site With Redirect -> Victim Site Open Redirect Page -> Victim Site Search Query
Now the victim site is gonna have a bit of an issue filtering traffic since it’s coming from a page of their own!
[ Vulnerable Site XSS ] -> Hacker Site With Redirect -> Random Site Open Redirect Page -> Victim Site Search Query
This chain involves some random site with an open redirect vulnerability being the last hop. This effectively removes the issue of being flagged by a URL shortener and shifts the work onto the victim site to fix the open site redirect page.
If the hacker wanted to be extra clever he could simple make his domain appear as an ad server or some sort of analytics service. For example a background HTTP request for a site like “burst-analytics.com” looks a lot more legitimate then a site like “viagra-free-sample.ru” or “03495ja.info”. If done in a clever way the attack could be preformed for a reasonable period without detection by any of the users preforming the attack.
Finding a Good Vulnerable Site
Finally, having a certain type of vulnerable site is an important factor. As pointed out by Incapsula video sites are an effective target because victims spend a long period on a page watching a video to completion. This becomes the perfect site because the longer the page is open the longer the attack goes on for.
Even better, what if it was a site that people usually had multiple tabs open? Videos are cool but having 20 tabs open (like seemingly every Chrome user in existence) is a multitude stronger of an attack.
Sites like Reddit, Digg, and other linked sharing services are a good choice for these types of attacks. It also goes without saying that porn sites are *ahem* a good option due to the fact that users often open lots of tabs for the same site. Not that I’m judging.
Even better are sites like Spotify or desktop apps that are basically watered down web views which can sit in your dock idling forever. If you had an XSS attack running on one of those services it could continue 24/7 uninterrupted.
If you really wanna get crazy, make the XSS a worm and spread it across even more of the site. See this post about doing JavaScript self propagating worms here that I wrote a while ago.
No comments:
Post a Comment