Ad Replacers Let Dan Kaminsky RickRoll the Entire Web

I’ve talked before about ad replacers, where ISPs dynamically edit the contents of web traffic for their customers, replacing ads on web sites with ads of their own. This is a threat to the business model of the internet, as if done on a wide scale it would render small, advertiser-supported websites unable to support themselves. It’s also difficult to fight, as it’s a variation of the Times Square effect (the fact that in any movie that shows Times Square, all the ads have been replaced with ads from the movie’s sponsors) — companies do it because it makes money and they have no contractual obligation not to. About the only things that would stop it would be enough customers caring about it to make it a competitive advantage not to replace ads, or some sort of net neutrality law banning ad replacers. The former isn’t too likely, because by and large customers hate all ads equally, and couldn’t care less whose ads they’re seeing.

Dan Kaminsky, however, gives us another reason to oppose ad replacers in his latest presentation, which he gave last week at Toorcon 10. A bunch of ISPs (and I mean big ISPs — Comcast, Earthlink, Cox, Verizon, Quest) decided that rather than replacing ads in live pages, they’d go after something less controversial — typos. They set up their DNS servers to return ad servers run by a British company called Barefruit when a DNS lookup failed (rather than following the RFC and returning NXDOMAIN, the code for “no such domain.”) This is similar to what Verisign SiteFinder did a couple years ago (SiteFinder was taken down after a storm of bad publicity), but instead of affecting the entire Internet (VeriSign did this on the root domain name servers), it only affects customers of the specific ISPs doing it.

The result is that if you mistype “www.google.com” as “www.gogole.com” or somesuch (actually, gogole.com is registered to Google, too, but it’s just an example) on one of these ISPs, you get a “site not found” page from the Barefruit, filled with ads. Doesn’t seem too harmful — after all, you’re still getting the error message, and seeing some ads never hurt anybody.

Except for one problem. Dan Kaminsky found that the Barefruit page constructs the error message from an argument in the URL querystring (telling the server which site you were trying to hit, so it can say “Sorry, we couldn’t find an entry for www.gogole.com” or somesuch.) This is the classic cross-site scripting vulnerability — you can just toss in some JavaScript in that URL, and when someone clicks a link to the corrupt URL, the JavaScript will execute in their browser. Normally, this is bad — a site with an XSS vulnerability can be used to carry out phishing attacks, where users are sent a link to a site (say, a bank), but clicking the link executes the attacker’s script and steals their credentials to the site.

When it happens in this ad replacer that’s based on DNS voodoo, though, it’s not just bad — it’s catastrophic. The ad replacer page comes up for subdomains, too. Not only does a typo of Google send you to the Barefruit site, so does trying to go to this-domain-does-not-exist.perimetergrid.com. Since the Barefruit page comes up in response to a call to any bad subdomain, and the Barefruit page has a severe XSS vulnerability on it, this means that an attacker now has an XSS to work with on an arbitrary subdomain of every domain on the Internet. A really insidious, intelligent attacker (e.g. Dan Kaminsky) can do terrible things with this.

Luckily, Dan is a nice guy, and instead only did ridiculous things with them, crafting links to RickRolled versions of Facebook, MySpace, Apple, Microsoft, eBay, ToorCon, Fox News, etc. However, he could have just as easily crafted links to GMail, Hotmail, Chase, Bank of America, Fidelity, and eTrade that steal your credentials when you click on them.

The presentation slides do not make it obvious what exactly his script does (presumably because Dan explained that out loud during the presentation.) However, I can see from context how this attack works. The attacker writes a script to exploit a given site, and then creates a link to a nonexistent subdomain containing the script. They then send this out in a phishing email, or embed it in a hidden iFrame on a compromised site, and wait to receive credentials. Any user who clicks on the link:

http://evil-subdomain.gmail.com/index,html,aaa=bbb&ccc=ddd<script>[long evil script file here]</script>

gets sent to the Barefruit page, but with the attacker’s long evil script inserted into that page. That script then takes over:

  1. The browser thinks that the script is running off of “evil-subdomain.gmail.com”, since that was the DNS query that (falsely) returned the Barefruit page.
  2. The script sets document.domain to “gmail.com”. Since it is on a subdomain of gmail.com, this is allowed under the same-origin policy, and the browser lets it happen. The script is now permitted to script against gmail.com.
  3. The script creates a frame that occupies the entire browser window (thus hiding the Barefruit page entirely) and loads the real gmail.com into the frame.
  4. The script grabs document.cookie out of the frame. Since the frame is gmail.com, and document.domain is set to gmail.com, this is permitted. Document.cookie contains the user’s GMail credentials, or at least a session ID that will let the attacker in.
  5. The script generates code to load a resource from the attacker’s malicious server, with the cookie contents in the resource value. Loading a resource (e.g. an <img src=…> tag) is allowed on other domains, without the same-origin policy applying.
  6. That resource doesn’t exist on the malicious server’s pages, of course… but now the user’s cookie is in the attacker’s server logs where he can retrieve it at his leisure.

And what does the user see when this happens? Just a normal load of the GMail login page. And there’s nothing wrong with GMail in this example! It could be any site, including online banking, shopping, etc. There is nothing that the site — or the user — can do about it. Click a link or visit a malicious web page and the attacker steals your credentials to any site he wants.

All this is made possible because you’re on an ISP that is running an ad replacer, and that ad replacer contains a vulnerability. Using the ad replacers makes a simple cross-site scripting vulnerability into a full compromise of the entire Internet.

Are you on Comcast, Earthlink, Cox, Verizon, or Quest? They’re some of the biggest ISPs in the nation, so probably so. If so, be glad Dan Kaminsky found this simple, obvious XSS before some malicious hacker did, or that hacker could have been stealing credentials from half the Internet for months without detection.

“Without detection.” Yeah, maybe Dan wasn’t the first one to find this. We’ll never really know for sure.

This vulnerability is fixed now — it was very straightforward, and Barefruit fixed it within hours. But Barefruit isn’t the only ad replacer out there, and there will be more experiments like this in the future. Whether “net neutrality” becomes a law or not, it needs to be something we demand from our ISPs, or this won’t be the last internet-wide compromise we see.

attacks, legal, society

If you enjoyed this post, please consider to leave a comment or subscribe to the feed and get future articles delivered to your feed reader.