Before getting into the focus of the post I’d like to provide some background:CSRF, like XSS, is one of web application security industries skeletons in the closet. Over the years only a precious few industry insiders were aware of CSRF and appreciated its significance. The larger infosec industry discounted CSRF (and XSS) because it wasn’t “elite” enough for their taste as it didn’t enable “root” access. All attention was instead placed on various types of buffer overflows, which is important, but not exclusively so. Web security experts on the other hand tend not to care about getting root on boxes because all the value is now within the browser walls. Why hack someone’s machine when its easier to go after a Web bank/email/brokerage directly?
Even today on this very blog are comments saying, “XSS is not hacking, get some real exploits”, and I’m sure most readers here have encountered similar attitudes elsewhere. It’s this type arrogance and closed mindedness that got us into this mess and why maybe 20% of infosec conference audiences have even heard of CSRF. Developer audiences it’s lesser still. As a result we’re faced with a situation where millions of websites are already built (and vulnerable) where developers never considered CSRF protection because they didn’t know it existed. Browser vendor are trying to figure out what to do and likely years off from meaningful results. And now the bad guys have recently caught on and beginning to cause real damage.
It’s with this context in mind that I share my thoughts about DDoS attacks carried out by way of CSRF. Also, I take no credit for the novelty of this attack as its been rumored around in various circles for years. I’m merely drawing attention to the issue. Here’s the basic exploit code that a bad guy would need:
<* IMG SRC=”http://victim/” >
Simple enough? All the bad guy needs to do is post the HTML snippet to a large number of public websites where other users would come in contact with it. These websites could be message boards, guest books, WebMail, blog comments, social networks, chat rooms, and so on. All the types of websites quite popular, free to sign-up, and easy to automate (save for CAPTCHA). The code instructs a users browser to make an HTTP request to an arbitrary location (victim) invisibly and behind the scenes with connections originating from all over. This makes the attack difficult to stop and obviously the more frequented the websites are the more effective it is.
Want increase the number of connections per user? Just multiply the number of injections per page, probably maxing out right around 10 or so per user. I’ve tested this across a dozen websites simultaneously reaching about 200 requests per second on the target web server. Something more automated and advanced could easily surpass what I was able to accomplish.
Want to increase the per request CPU processing of the target? Target the search application using several keywords separated “AND” operators, like so:
<* IMG SRC=”http://victim/search?q=TERM1+AND+TERM2+AND+TERM3 …” >
Want suck up a lot more bandwidth? Try URLs that are 2K or so in size:
<* IMG SRC=”http://victim/AAA…” >
Want to scrub the referers from the requests? There are tricks for that to. Anyway, you get the idea. Anyone have any bright ideas on what a defense might be?
11 comments:
It's not clear to me that DDoS via image tags is a cross-site request forgery attack. It certainly involves a cross-site requests, but I'm not sure there is any forgery involved.
I guess that's fair enough, though we probably need to call it something, but I'd prefer we didn't add another esoteric name or acronym to the pool . :)
CSDDoS add that one to the list ;)
Oh great. Here we go. :)
@Adam
That's why the term CSRF is outdated, because it isn't XSS also. It are unauthorized requests, the mechanism -or distribution layer- used in CSRF as well as XSS to work. Since "cross-site" also can happen locally, in your browser, or in your phone or any other place, I feel that we should drop the term all together, because it restricts us and limit us. Payload and transportation of it are different mechanisms which should not be confused with each other. The payload like Javascript or HTML cannot fall under the same name as "scripting" because it isn't.
It's payload transported over the mechanism that triggers an unauthorized request on behalf of the person or software that makes it. But as I said, that can happen in your phone also, so it isn't "cross-site-scripting" nor a "cross-site-request-forgery".
I've written an article on it and my viewpoints on it yesterday:
http://www.0x000000.com/?i=553
It's funny that you should post about how people underestimate CSRF as a vulnerability. I just posted about a purely CSRF attack that I can use to compromise someone's box a couple days ago. The stuff is dangerous and people need to take it seriously, especially with the proliferation of new products that start up web servers on the local system.
http://r00tin.blogspot.com/2008/04/utorrent-pwn3d.html
It would be cool if the browsers can add something the request header if the request is coming from a img, iframe etc., versus the main page being loaded in the browser ... that would give us web developers another potential defense against certain types of CSRF such as the one mentioned here. Of course this doesn't solve it all, but it would certainly up the ante for the bad guys
Jeremiah,
You might be interested in the Puppetnets paper.
CSRF is useful for a lot of different applications depending on all of the variables that need to be taken into account. If POST requests can be done via GET requests instead (most times they can indeed), there are very few checks in place for referrering URLs, and a token system is either nonexistent or hardly implemented then you have all the necessary bits for a CSRF worm.
And we have a very good practical example from the recent DDoS on CNN.
I'm going to quote a recent post from Dancho Danchev here:
What if a simple script that is automatically refreshing CNN.com multiple times in several IFRAME windows, gets embedded at thousands of sites, and then promoted at hundreds of forums, with a single line stating that - "If you're a patriot, forward this to all your friends"? Now, what if this gets coordinate to happen at a particular moment in time? This is perhaps the most realistic scenario to what exactly happened with CNN.com, and data speaks for itself, in fact I can easily state that the bandwidth generated by this massive PSYOPs campaign is greater than the one used by a botnet that's also been DDoS-ing CNN.com.
http://ddanchev.blogspot.com/2008/04/ddos-attack-against-cnncom.html
ps, adam that paper looks really interesting, thanks!!!
it is very nice text. thanks for it..
Post a Comment