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.

Integrated Windows Authentication

Mon, 16 Apr 2007 19:54:00 GMT

On the face of it Integrated Windows Authentication for your intranet applications (formerly known as NTLM) seems like a good deal; you can protect your users' credentials without needing to set up SSL (so your credentials are safer than with basic authentication) and if you're running IIS you can turn it on with the click of a mouse. There's the additional benefit of convenience; your users don't need to bother with interactive login as Windows makes use of user information from the current Windows session. It's like having single sign-on for all of your intranet applications.

Unfortunately there's a catch. The convenience that comes from the fact that users are not usually prompted to log in can extend to attackers as well as legitimate users.

How does this work? We're going to take a look at two different types of attack; cross site request forgery (often abbreviated to CSRF or, less commonly, XSRF) and anti dns pinning:

CSRF:
This is a type of attack where an attacker crafts web content that instructs a user's browser to forge requests to another web site on the user's behalf. Depending on how the site is crafted, the attacker may be able to perform any operation that the user would normally be able to perform, although the attacker can't read the results of the operations that have been performed. The user will often be completely unaware that the attack is taking place. You can read more about this type of attack here.

Anti DNS pinning:
This is a type of attack where an attacker fools a user's browser into making connections firstly to a server under the attackers control, then servers on your local network believing they are all one and the same host; this is achieved by some trickery with DNS and some selective firewalling. This attack is somewhat harder to understand than CSRF (you can read more about this technique here) but the key feature of this attack is that the attacker can read information from webservers on your internal network that they would not normally be able to see.

So how does Integrated Windows Authentication relate to these types of attack? Let's say you're an attacker and you want to make use of one of these techniques to hack a company intranet. To be able to make use of CSRF you need your user on the target network to already be authenticated to the application you're attacking; if the user is not authenticated then the forged requests will not carry the cookie or auth. header necessary for certain operations. If you've got Integrated Windows Authentication enabled on your server then all bets are off; the user's browser and the server will (in most cases) negotiate authentication with no interaction whatsoever from the user so, even if the user hasn't used the application at all in the current browser session, the attacker can directly hit the functionality they require.

And what about Anti-DNS pinning? The situation is even worse here; because the browser believes the target servers are actually in the same security domain as the attacker's server, any cookies the user may have set for the target server under it's normal name are unavailable to the attacker. This means that under normal circumstances Anti-DNS pinning attacks can't be used for any operations that require authentication. Again, with servers that have Integrated Windows Authentication enabled things get much easier for the attacker. The user's browser will negotiate authentication with the server without the user's knowledge and the attacker can read any data or make any request that the user would normally have permissions for.

Many problems in security are about finding a good balance between making life hard for attackers and making life easy for everyday users; we've just looked at how Integrated Windows Authentication makes life rather easier for attackers than you might at first think.

Mark Goodwin's Blog - csrf tag

Browser based DDOS

Integrated Windows Authentication