This blog posting’s a small writeup about a topic I’ve first mentioned in my talk at the 0sec 2006 and at the last OWASP Switzerland Local Chapter Meeting (12. February 2007) I discussed it during my presentation about XSS-Worms. The topic I’m talking about, is one I personally call “Webbased Dynamic Botnets” because AFAIK nobody else have written something similar and so there’s no other name for it yet.

What’s a webbased dynamic botnet (WDB)?
We all know what a botnet is, just a group of computers which are infected for example by a worm and someone else then the owner of the machine, can control it. Now the idea of WBDs is, that we don’t infect machines permanently, we’ve the control only for a very short time. This is because we use Javascript for it and this kind of code will just be executed when someone for example visits a prepared website. I think I don’t have to talk about what malicious stuff we can do with Javascipt because there’s much stuff you can find on the net and most of it just depends on the imaginative power of an attacker. For now, this is normal XSS and nothing special but think about a XSS-Worm on a social networking platform. When we’ve got 1000 profiles which are infected by our worm and at any time there are 200 visitors who visit one of the infected profile, we can control 200 machines and execute our predefined payload.

This image should show you the basic concept.

Now the interesting point comes. What happens when in our example social networking platform a few profiles contain a how I call it “master script”.

The following five images show you how such a worm spreads, build the botnet and launch a DDoS attack:

1.) The attacker has infected the first object which’s vulnerable to XSS. This object could be once more a user profile on a social networking patform. Now, the infected object requests the master script and get the payload from there.

2.) To stay by our example; a user which’s logged in, have a look at the infected profile/object and so on the client side of this user he’ll send requests to a target.

3.) When the user is visiting the infected profile, not just the requests to the target will be sent, also his own profile becomes infected and so the worm starts spreading.

4.) The new infected profile now also starts to send requests to the target.

5.) In this last phase, think about thousands of infected profiles and every time someone visits one of them, his browser will start sending as much request to the target as possible and so we have a distributed denial of service (DDoS) attack.

Now we have our botnet which is build by the users who are just visiting an infected profile and because this people changing very fast it’s dynamic and we can control the payload over the master scripts which can also have the behavior to synchronize with each other or for example to build a new master script infected profile when one of the master scripts was deleted. This is the basic idea but now I’ve splitted this kind of botnets into two types, which have much things which’s similar but some of these things are on another layer and there are also things where the two types are very different.

Single Application Botnet:
This kind of WDBs is the normal type which’s based on just one web application which’s for example once more a social networking platform. The following image shows you, how the botnet structure looks like on a social networking platform:

Multi Application Botnet:
The basic structure’s the same as in a single application botnet but the main difference is, that the multi application one is based on different and independent web applications. Because of every single application’s independent, it’s from my point of view with todays techniques impossible to stop such a botnet in a short time. The only problem an attacker has, is that he has to find enough web applications which are vulnerable to permanent XSS but a skilled attacker can also try to automate this step. The following image shows the structure of this WDB type:

Countermeasures:
To protect users from such WDBs it’s most important, that there’s protection on the server side because in the time of AJAX and Javascript stuff at all it’s from my point of view not practicable to give users the advise to disable Javascript because then they can’t use most of todays web applications. So, the question’s now, what we can do on the server side or also in the implementation of our application at all. I think the most important thing to think about here’s that Protection against XSS-Worms means protection against XSS and when we can protect users against XSS we automatically protect them against becoming part of a webbased dynamic botnet. Now, to get the best protection, the following four points give you the security you need at least and then you can go further and build stuff like special filters based on application specific regular expressions and so on.

• Whitelisting
• Setting default values wherever possible
• Filter EVERY input
• Convert all applicable characters to HTML entities wherever possible

If you find an ultimate (and practicable) protection mechanism against XSS, please contact me immediately

Summary:
Until now, not that much security professional really care about webappsec at all and so they’re even not interested in XSS or better be more specific, XSS-Worms. This kind of webbased malware will become more and more important in the next few years I think and webbased dynamic botnets are only one way to misuse web technologies. We can say that today we haven’t the techniques to really stop such botnets but we should start thinking about it because they’ll come.