LAS VEGAS – Researchers have figured out how to leverage the reach of online advertising networks to distribute javascript of their choosing, creating the equivalent of a botnet of ad impressions capable of crashing underlying webservers or distributing malware on a massive scale for pennies on the dollar.

Jeremiah Grossman and Matt Johansen of White Hat Security presented their research today at Black Hat USA 2013, research that did not include a zero-day vulnerability or exploit. All they had to do was buy an ad.

“We’re not really hacking stuff. We’re just using the Web the way it was meant to be used,” Grossman said. “We are using it for our own purposes and there are no solutions.”

Grossman has been a fixture at Black Hat for many years, delivering revolutionary research along the way on Web-based attacks such as clickjacking and cross-site scripting. With today’s attack, a hacker could spend relatively few dollars with one of the popular ad networks such as DoubleClick or AdSense and exploit a fundamental Web infrastructure shortcoming to distribute their code and let the ad network do the heavy lifting.

“When you go to any webpage, that page controls your browser as long as you’re there to make any request you want to any location on the planet,” Grossman said. “So the nature of the problem is that when you put code on an ad network, that code gets in front of a lot of people and now we control a whole lot of browsers. It’s the Web infrastructure. When you go to a website, it’s pulling in images and resources from all over the Web—and you want it to be able to do that. We’re using the exact same features [to our advantage].”

The end result for the hacker could range from a simple denial-of-service attack against a webserver to using the scale of the browsers viewing an ad to brute force password hashes. The cost too is relatively inexpensive for an attacker.

“It all depends on how much money you want to spend. For a DDoS attack, for mere dollars we could bring down one Apache server very quickly for probably under $10 and hold it down for a long time,” Grossman said. “I don’t know if it has good DDoS protection how much it would cost us, but it probably wouldn’t cost $100. This means that anyone without DDoS protection is susceptible to a $10 attack that could bring them down.”

Johansen said there are benefits to hacking this way versus other means such as a traditional distributed denial-of-service attack, search engine poisoning or drive-by downloads, as examples.

“It’s not a botnet because it’s not persistent. That’s a good thing because it all goes away, no traces,” he said. “It’s very easy too; the code isn’t crazy.”

Once javascript is on the ad network and gets distributed, it runs in the user’s browser; the attacker would have control as long as the user is on the page hosting the ad. During a demonstration, Grossman and Johansen said one ad network enabled them to select keywords to target with their ad, topical channels, even geolocation for the distribution of their ad. The ad network failed to properly validate their javascript—which was not malicious; their ad was a nondescript banner promising a free 30-day trial. In one day, more than 8,000 impressions were loaded onto browsers—in this case one impression would correlate to one bot in a botnet—and their generic ad landed them 15 clicks.

They could also, via the same technique, force browsers to make as many requests as they wanted in order to DDoS the underlying webserver. Most browsers have a built-in protection, a connection limit for stability purposes that maxes out at six to eight connections. Those connections are tied to the HTTP protocol handler, Grossman and Johansen said. They demonstrated a script that was set to loop 300 times, but was limited to six connections, proving that the limiter worked. In Firefox, however, if they switched out of HTTP to FTP, they could get their 300 connections and crash the webserver.

“We’re able to bypass these connection limits, and in this case, cause Apache some pain,” Johansen said. With this loop running constantly again their Apache server, the researchers said they were currently averaging 1.5 million connections per hour on 256 concurrent connections.

“Our Apache server is feeling it,” Johansen said of the server which was hosted on an Amazon instance. “Hosting it on Amazon is more expensive than the hack.”

As for solutions, even Grossman and Johansen are stumped.

“We don’t know who is responsible, who is culpable. It’s everybody’s problem,” Grossman said. “The browser can’t do anything about it without breaking the web. The ad vendors can’t do anything about it because their business model prevents it. The user isn’t a victim either because we’re using their browser temporarily to attack someone else, and we’re not negatively impacting them.”

NoScript could be a mitigation, Johansen said, against certain attacks but would likely be unfeasible because users would not be incentivized to install the browser extension just to protect others.

“And with respect to DDoS, NoScript wouldn’t help because we could have done it all with HTML,” Grossman said. “If you’re going to turn off HTML, nothing will work.”

Categories: Web Security

Comments (11)

  1. No
    3

    No. The solution is for *everyone* to run NoScript & ABP, and that completely breaks the advertising model that everyone currently uses to mitigate their own costs.

    • gack
      4

      does ‘No Script’ mean no little pointers to ther sites for weather and video, right? have to point to the local server and it has to go get it?

      very sad.

      cant we just execute hackers instead?

      • Tux
        5

        You think people running NoScript is said. But you are willing to execute hackers ? What a f*ck*ng toothpick. If you have nothing useful to say please don’t even bother to say it.

        • Steven
          6

          Execution may be a bit of hyperbole,but why would extreme punishment not be appropriate for those who act in such a malicious, self-centered, destructive way?

          • Robert Baindourov
            7

            I agree with Mike. Its the ad server’s responsibility to vet the ads. They are ultimately the gatekeepers to this powerful resource.

  2. David
    8

    Thing is, NoScript is often a pain to use. I use it because I’m paranoid, but I’m often looking at reduced or eliminated functionality, and wondering which script sources to enable. Sometimes I just give up and temporarily allow everything on the page. Assuming the malicious scripter doesn’t use an obvious name like ddos.com (bear in mind that some small companies have sinister-sounding names, like “Evil Hat”, which produces role-playing games), and assuming the usual array of source names, some of which allow you to do what you want to do, and some allowing me to do what they want, what do I do?

    • Tux
      9

      If you know how to properly configure it and use it its not hard to use at all. Security is not suppose to be easy. People always choice to use something easy rather then secure.

  3. jonnofcc
    10

    Unfortunately there is nothing new in this research to those in the know. Very similar work was presented at DCC in a six hour lab run by Microsoft’s Digital Crime Unit and Ipensatori in 2011.

  4. Mike
    11

    Having the ad service validate the code for the ad and keeping the vetted copy on their own server could help mitigate it. They may not spot everything, but they should be able to catch obvious DoS attempts. Watching the ad load and perform on a monitored system would server as additional verification before approving it for distribution.

Comments are closed.