Botnets in the browser

The holder of the title of the first botnet is a matter of debate, but there are a number of strong contenders from 1999, such as Sub7 and Pretty Park, both of which could be controlled via an IRC channel. Since then, botnets have continued to evolve: we have seen IRC superseded by HTTP and P2P botnets; mobile botnets and Mac botnets have also arrived on the scene. Now, with the arrival of HTML5, I believe we are at a crossroads once more.

HTML5 is a set of new standards for the development of the web. Rather than being a new version in the sense of traditional software, it is made up of a lot of individual new features – each with varying support among today’s browsers. This includes the likes of geolocation, drag & drop, and a range of upgrades for sharing multimedia online. Several of these features blur the line between web application and native application, making it tricky to determine where local stops and the cloud begins. Some features are very well supported, while others may only work in a single browser.

But like any new abilities, these features can be a double-edged sword. They open up a range of new attack possibilities, including enhanced cross-site scripting (XSS), form tampering, port scanning and cross-origin attacks, to name but a few.

Most alarming, however (and game changing in my opinion), are the abilities added by HTML5 which finally facilitate browser-based botnets. For a botnet to be successful on a platform it needs four core components: it needs to be able to spread, it needs to be able to receive commands, it needs to have a payload, and it needs to be persistent.

Spreading malicious JavaScript has never been an issue – criminals can use purely malicious sites, compromised sites, XSS and so on. Just look at the Samy MySpace worm from 2005 to see how effective these can be.

New additions such as WebSockets and Cross Origin Resource Sharing (CORS) allow for cross-domain, real-time networking communication – perfect for C&C control channels and a notable improvement over AJAX-style polling.

Perhaps the final piece in the puzzle is Web Workers. Essentially these are background threads which can execute JavaScript in the background of a page, while the site’s main content continues to run in the foreground. When combined with some of the technologies previously mentioned, Web Workers are perfect engines for DDoS attacks – and even spamming using poorly configured web forms to act as mail relays. The attacker’s code will continue to run silently without interfering with the main page, leaving the victim none the wiser.

The one area in which botnets in the browser suffer compared to traditional botnets is that of persistence. In most cases, closing the browser (or even the infected tab within the browser) will remove the threat. However, the life of these botnets can be prolonged using a variety of approaches such as tabnabbing, clickjacking or just plain, good old-fashioned social engineering. Botnet business models can also adapt to work with a more fluid botnet where hosts come on and offline frequently.

I believe that when all of these factors are combined, attackers can trivially create a botnet that will run on any modern OS, on any personal Internet device, in any location in the world. Browser-based botnets can be engineered to barely touch the hard disk, making detection via classic file scanning more difficult. Obfuscating JavaScript can easily be engineered to bypass most network IDSs, and the entire attack takes place over simple HTTP traffic – which is allowed through almost every firewall.

I love the web – and ensuring that people have unrestricted, safe access to it is the reason I became involved in security in the first place. I have no doubt that the new features brought about by HTML5 have serious potential for abuse, but I’m an optimist, and I can’t wait to watch as those same features are used for good, to bring the web to the next step in its evolution.

Latest articles:

Bulletin Archive