Buy An Ad, Own a Browser Botnet | Hacker News Reader

Buy An Ad, Own a Browser Botnet

threatpost.com

46 pointsctoth43 comments

The researchers in the article are quoted as saying they don't know who's fault this is. That's B.S. It's absolutely the fault of the ad network/ad buying tool/DSP/whatever.

When you open up a platform to let people buy ads, there are loads of decisions to be made. The ones around "what content do we let people submit without vetting" are pretty simple. At Perfect Audience, self-service customers can upload static image banners and traffic those. We host them. No JS. No flash. If folks want to traffic those kinds of ads, we have an enterprise support play they can sign up for and we'll help them do that easily.

Letting anyone traffic js or flash files without prior vetting is hugely lazy. I wish they'd named the ad network they bought through so they could be black-balled and barred from the exchanges.

It's so easy to say no to crap advertising, and yet there's always unscrupulous players who say yes to it. There's no excuse. It's all their fault for just not giving a crap.

Edit: Also, when you get access to the ad exchanges, you sign a ton of documents and agree to be responsible for what you traffic in many ways. This network is dropping the ball.

Does vetting necessarily help? If I send some JS through for your adops to traffic, and they call code on my own adserver, what's to stop me from altering it after you have trafficked it and it's already live showing to users?

And even if I submit code that is malicious from the start, if it also correctly serves an advert, will you actually notice the extra code if all it's doing is opening a few extra connections?

Maybe you have answers to these questions - I've never worked on an adops side at all, I'm on the buying side, so never had to worry about it.

p.s. Dropped you an email earlier Brad - give me a shout, I really want to try out Perfect Audience!

> Does vetting necessarily help? If I send some JS through for your adops to traffic, and they call code on my own adserver, what's to stop me from altering it after you have trafficked it and it's already live showing to users?

You can let your advertisers run JavaScript in ads without letting them inject script tags pointing to external URLs. There's no risk in the script changing if you're only hosting inline code they have no access to after review.

There's many (perfectly legitimate) buyers out there for whom this would be a deal breaker. If you don't run the adverts through my server (i.e. including using JS on my adserver) then you won't be serving my adverts. And in the world of media buying, that's not at all uncommon.

> let your advertisers run JavaScript in ads without letting them inject script tags pointing to external URLs

How would you do that? That's equivalent to the halting problem. There is an infinite number of ways to assemble code that will execute arbitrary code, which can can assemble code that will execute arbitrary code, which ...

Deleted comment

It means that every piece of the code must be examined by a human. That's expensive.

D'oh! Just wrote you back. My bad.

So the vetting we do is somewhat extreme. We ask you to sign on as an enterprise customer to run ads like that. Making things more official tends to weed people out pretty quickly and leaves us just the well-intending players.

Agreed.

I do want to know what network it is - probably a fly-by-night outfit.

We can allow HTML/JS in our ads because we inspect them and only allow direct references (no external libraries) in-ad.

Okay, so you allow me to post an advert with a direct reference to "//myhost.com/ad/campain-456/advert.js" ??? If that's the case, what's to prevent me from changing that JS file?

The safer thing to do, would be to require that the entire payload be delivered together, index.html, with images/js/css etc (uncompressed)... then do the min/merge and inline it all into the html before serving.

We don't allow any external calls/loads and strictly limit access to just DOM operations in the iframe. Not many people use JS in ads with our platform, so we spend the time to thoroughly vet them.

>It's absolutely the fault of the ad network/ad buying tool/DSP/whatever.

So which is it? They generally know whose fault it is, but not whose fault it is (person/team/some developer) is what they probably meant.

It's the CEO's fault. It's a business decision to allow un-checked code in ads or to not assign enough resources to properly check the code.

"And with respect to DDoS, NoScript wouldn’t help because we could have done it all with HTML,"

"RequestPolicy" on the other hand does work against this. For example, when I visit threatpost.com, it wants to pull in content from the following external domains:

  kasperskycontenthub.com
  addthis.com
  gravatar.com
  wordpress.com
  google.com
  twitter.com
  google-analytics.com
  cloudfront.net
  fonts.googleapis.com

RequestPolicy blocks all of this by default, and the site and content is still perfectly readable.

In my browser it takes 39 http requests and 1MB of data transfer to view the page. If I were to disable RequestPolicy however, due to all the extra pointless crap the site wants to load those numbers would increase to 86 requests and 2.3MB.

Your browser isn't the problem, it's the hundreds of thousands of others that are using the default configuration and have no such protection.

So it's the browser vendors fault.

Seems like ad networks should be liable for the javascript they serve up. There has to be an incentive for them to check it out, and they should strongly prefer that their clients NOT have any javascript.

Seems like site owners should be liable for the arbitrary third party content they allow ad networks to inject into their pages.

If you don't want your sites security to depend on a third party, don't allow that third party to run code on it.

There are still ad networks that allow advertisers submit Javascript? Or html for that matter? Good time to be a blackhat I guess.

Mobile ad networks are particularly crazy. Source: I have reverse engineered >100 of them.

All of them allow you to serve an iframe. and there you are king.

It's a very simple concept that shouldn't really come as a surprise to anyone. That said, I spend a load of money on adverts every day, am regularly sending over JS snippets which I'm well aware will be executed on the machines of millions of people, and yet the thought of using adverts for this sort of thing never occurred to me.

Iframe sandboxing is the solution - removing allowscripts permission will fix this.

http://www.html5rocks.com/en/tutorials/security/sandboxed-if...

Now it may be argued that genuine Rich HTML ads do need javascript, for example, to expand or interact with the page. To me, the solution to this is to limit what sort of javascript is allowed to run. We need an mraid.js for the web, which specifies the subset of javascript that could be run.

I don't think it will happen until there is a major attack. Other than botnets, javascript can mess with cookies, steal data, and do a lot of damage.

Google's caja is that software:

https://developers.google.com/caja/

This is an issue we've been aware of for some time.

This isn't quite as easy to do as you might think however. While the cost might be low to run the ads, typically most RTB ad networks do not actually allow you to use external ad tags that can call arbitrary JS.

That said, some do allow this (like the one the speaker used), and the ones who don't police their JS ad tags are going to be wide awake tonight thinking of how they can.

Maybe you could develop a better utility for this (not that a good old DDoS isn't fun and all). Instead of irritating ads you could sell invisible "adspace" and the value would actually be in the fact that you were enabling a massive distributed computing effort. Imagine if SETI at home or several other distributed projects bought ads and had them process the work. It's a more productive monetization strategy than telling me how I can lose weight or grow my dick.

Edit: I'm thinking more about this and I think it'd be fun to work on if anyone feels the same way.

It's more productive but less profitable. The potential "advertisers" would only advertise with this network if they could purchase computing time through it at a lower rate than the spot price on Amazon EC2 -- otherwise they'd get their computation done faster and cheaper going to EC2. At the current spot prices EC2 charges, this network could not pay out within even two orders of magnitude of the CPMs even low-quality sites earn from ads now. The processing power of JavaScript time slices on commodity laptops is just too far apart from running compiled code on even the slowest EC2 instance size. That means it's unlikely for a significant publisher base to develop to sell the ads onto.

If you're interested in working on it, there's at least one or two startups trying it at any given time you could try to work with. http://crowdprocess.com/ is relatively new. Many have had the same idea and eventually closed down.

I wonder if mining bitcoins with JavaScript and/or WebGL could yield a higher return than the cost of the ads. (Not that gobbling CPU power in that way would be ethical, but it would be a fun demo.)

I don't think it'd come close. Here's my napkin calculations:

Let's say you pay $5CPM - $5 for every 1000 views. Let's say every viewer stays on the page for a minute, and every viewer is able to provide 10 MHash/s, which I think is pretty generous for a Javascript based miner. That means you get a minute of 10,000Mhash/s for $5. The Mining Factor 100 is currently 0.17 USD/24h@100MHash/s (http://www.bitcoinx.com/profit/). That works out to be about $0.0047 in return for that $5. My numbers are probably off, but I think it's still a couple orders of magnitude from being profitable.

Even if everyone was running a top-of-the-line GPU, and you were able to squeeze 500Mhash/s out of everyone, it'd still just be about $0.24 for every $5 spent.

I wonder if this could be used to do any sort of useful computation. A cheap supercomputer, if you will.

EDIT: Oooo, others have thought of something similar: http://hackaday.com/2009/03/03/distributed-computing-in-java...

The networks that allow untrusted code (js or flash) are the ones to blame for this, and I'm glad that seems to be the general consensus. It seems bizarre to me that anyone would allow this in 2013. We've been talking about scripting "attack" vectors for years now. It's not new.

This appears to be a repeat of 6 year old research - https://twitter.com/abortz posted the following https://abortz.net/papers/dns-rebinding.pdf

Wonderfull. Now let's just combine that with the new BREACH attack discussed on https://news.ycombinator.com/item?id=6141286 and wreak havoc. I'm really curious how these problems will be fixed...

Ahem, what about all those external jquery hosters, or google analytics..?

Not really an issue - Google doesn't allow you to add arbitrary JS that other sites use to their tag.

Link this to PTC scheme and you are doing well better than in the article; for 10 second display time, you will get 1000 guaranteed visits to your website, for whopping $1,5.

(Shameless plug)

For exactly this kind of issue, we're building an ad tag monitoring solution for publishers (and we're hiring). www.clarityad.com

you can always fetch a website with pure html, something like <img src="http://news.ycombinator.com"/> + an ad network that's too many requests. but still I'm not 100% sure whether that's possible.

w8... does adwords allow you to include JS into ads? If no, how he get his js into ads?

Last time I checked, adwords failed to detect javascript injection from an obfuscated Flash creative. That's the kind of things that we detect at ClarityAd via dynamic analysis.

Aren't people moving away from flash creatives yet?

Flash is still the standard for "rich media" ads, despite the lack of mobile coverage. HTML5 ads are growing fast but still very small.

No - AdWords is bidding on search and only allows text in ads. He is most likely using one of the less-policed RTB trading desks.

Reply on news.ycombinator.com