Black Hat: Ads Could Provide a Vehicle for Enslaving Your Browser

An attacker could spend a small amount to almost instantly create a massive JavaScript-driven browser botnet, WhiteHat researchers found.
LAS VEGAS—Every day millions of ads are displayed to tens of millions of users across the Web. According to a pair of WhiteHat Security researchers speaking at the Black Hat security conference here, those ads could be the gateway to enslaving your browser into a botnet army.

There is little preventing an attacker from spending a small amount of money to almost instantly create a massive JavaScript-driven browser botnet—a so-called "million browser botnet," Matt Johanson, manager of the Threat Research Center at WhiteHat Security, told eWEEK.

Perhaps even more disturbing is the fact that WhiteHat's browser botnet attack isn't technically about disclosing a vulnerability. Rather, it's about abusing functionality that is part of the way the Internet works today.

Johanson explained that WhiteHat deployed some JavaScript inside of ad code and then submitted the ad to various ad networks. He noted that some networks allow JavaScript code functionality, while others do not. The overall goal for WhiteHat was to generate as much traffic as possible.


In short order, WhiteHat's bogus ad generated 20 million hits on the target tracking site. But that doesn't mean the ad was deployed or clicked 20 million times. The JavaScript code that WhiteHat deployed forces the browser to repeatedly connect as quickly as possible to a given target. It's a condition that if deployed widely could enable a distributed denial-of-service (DDoS) attack.

WhiteHat's JavaScript code wasn't doing anything overtly malicious and it wasn't dropping a payload on any user's machine either, Johanson said. The attack isn't even a cross-site scripting (XSS) issue, and it isn't abusing the same domain origin policy—designed to limit the risk of external scripts acting outside of a specific domain—that most browsers respect.

"This is just how the Internet works," Johanson said. "A Web browser can go grab an image that sits on a third-party site and the source of the image doesn't even matter."

He explained that all they did was deploy simple code, that is just running through a loop as the ad is displayed. It's also possible that WhiteHat could have extended their JavaScript code to perform other functions, such as distributed hash cracking.

The WhiteHat browser botnet only worked on ad networks that allowed JavaScript code in submitted ads.

"Ad networks go through an approval process, but all they care about is that the image looks right and fits, and when you click, it goes to a page that exists," Johanson said. "On the networks that allowed JavaScript, there was no analysis done of our code."

Though it was the ad networks that allowed the WhiteHat code to run, Johanson said that he's not pointing fingers at any particular ad network. The challenge, he said, is a bigger one than just the ad networks, as JavaScript code running in a browser is commonplace across the Web. The ad network in the Million Browser Botnet example was merely the distribution mechanism.

In Johanson's view, the ad code issue isn't an issue of avoiding certain sites either, as he found that he was able to get the ads running on common legitimate Websites.

In terms of fixing the problem, browser vendors might be part of the solution. Johanson said that WhiteHat has already opened up lines of conversation with Google and Mozilla.

So what should users do today to protect themselves?

There aren't too many options, but there are a few. Johanson suggests the browser users make use of browser extensions to control what's running. Two tools in particular are NoScript and Request Policy, which explicitly ask the user if they want to enable a script to run and make an external site request.