Browser based DDOS

Thu, 17 May 2007 19:49:00 GMT

Everybody is saying that JavaScript is the new malware. There's an interesting application of this idea that probably hasn't occurred to many people; we've all heard about standard CSRF and using this type of technique to perform sophisticated operations on an attacker's behalf but what about the simple stuff?

I've been working on a tool which allows you to stress test an application using scripted browser clients (like a stress test version of Selenium). One of the advantages of this approach over something like, say, the Grinder is that it allows you to get a view of what real traffic from real browsers might look like. You simply set up some virtual machine images with various different browsers, point your virtual machine images at the test tool (via the target site if you want detailed client reporting or the ability to script around CSRF protection), clone your image as many times as is necessary and run them. The test clients poll a management application to find out what they should be doing and how often and report back when they're done.

The scary thing about the possibility of using this against real users is that the user of the browser needn't necessarily know that their machine has just been conscripted as part of a vast stress-testing army. You could be browsing away minding your own business whilst in the background your browser is making forged requests to DOS a website on an attacker's behalf. Because it's JavaScript based your AV won't alert you and you can patch all you like but this is possible because of a feature of browser design not a vulnerability. Your machine will forget all about it when your browser session ends, but that's no problem to the attacker if they can attract enough browsers. Jikto was aimed at breaking in - this is similar, but rather more brutal.

So what's necessary from the attacker's perspective? The attacker needs to do the following:

Find some expensive functionality on the target site (preferably available to non authenticated users).
Find somewhere to host the scripts and the management application (a simple PHP script and a few lines of JavaScript would suffice for most purposes); sites vulnerable to various PHP remote file include issues are easy to come by for free hosting
Once these are in place the attacker gets people infected either by driving traffic to their scripts from a popular site, or inviting people directly (spoof e-mail from a bulk mailer perhaps)

I've had a look around and this appears to be easier than I'd initially dared imagine; people are starting to understand the need to protect functionality that makes changes to their systems or data, but I'm not sure people are wise to the possibility of DDOS via CSRF. Given that this is all entirely plausible; do we need to start protecting expensive, publicly accessible functionality in our web applications with some kind of CSRF protection?

Just a thought.

Mark Goodwin's Blog - malware tag

Browser based DDOS