Warning to web developers: My google analytics attack

[Red Emerald]

I've been working on building client-side javascript apps (http://brunch.io) and am really wanting to make sure that they are secure as possible.  There are people that openly laugh when javascript and security are brought up in the same sentence, but I think they are a bit misguided.  Many of the vulnerabilities that have been pointed out to me exist on any website where javascript is enabled, not just on client-side javascript apps.

I was researching javascript injection (which many people consider "game over") and had an idea.  LOTS of sites use google-analytics.  The default code snippit for google analytics loads HTTP if the page is HTTP and HTTPS if the page is HTTPS.  This is pretty common behavior for most file requests.  So what if I had control of a DNS server? If I modified my public DNS or poised someone's DNS or editing a target's hosts file, could I serve them whatever javascript I want?  Turns out, YES!

I downloaded http://google-analytics.com/ga.js and https://github.com/scottschiller/snowstorm/ and combined them into one minified file.  This way, the analytics still work, but it also snows.  I dropped this file into a new folder on my webserver-- google-pwnalytics.com.  I then setup nginx to serve both google-analytics.com and www.google-analytics.com (but NOT ssl.google-analytics.com so not all of the HTTPS queries throw errors).  Then I configured my personal DNS server to point google-analytics.com to my webserver.  I cleared my browser cache and went to one of my own sites that has analytics.  It snowed.  Then I went to a few sites that I don't run.  It was snowing on lifehacker.

The number of sites that this attack affects is scary.  This attack doesn't get every site, but it got enough that I am concerned.  Most attacks are targeted at one site.  This one gets every site that uses HTTP analytics.

Obviously, having it snow isn't going to do anything bad, but what if the script grabbed cookies? Injected cookies? Searched for forms with a "password" field and redirected input to me?  Javascript injection is bad news.

There are a few things that can easily stop this attack like DNSSEC and HTTPS.  Maybe we could start doing javascript checksums lol.  Most people don't do anything though.  It also doesn't help that the recommended code snippit from google is affected.  If you are building an app that needs to be secure, make sure you only serve 100% trusted code only via SSL.

tl;dr... As a web developer, don't trust CDNs for high security sites; serve all your own code over SSL.  As a user, be wary of Public DNSs.  Use HTTPS everywhere that it is available.

[Fireball]

The number of sites that this attack affects is scary.

It's not an attack against a particular website. Also it's wrong to tell "number of sites this attack affects". Same way, you can put microsoft.com 127.0.0.1 in your etc/hosts file and say you hacked microsoft.com because whenever a user working on your PC opens up microsoft.com, he really opens your own website.

Captain obvious also says that if you're connected through a network which you can't fully trust, it's mandatory to use SSL and take precaution measures.

[Red Emerald]

The number of sites that this attack affects is scary.

It's not an attack against a particular website. Also it's wrong to tell "number of sites this attack affects". Same way, you can put microsoft.com 127.0.0.1 in your etc/hosts file and say you hacked microsoft.com because whenever a user working on your PC opens up microsoft.com, he really opens your own website.

Captain obvious also says that if you're connected through a network which you can't fully trust, it's mandatory to use SSL and take precaution measures.

The number of sites is very high.  TONS of sites use google analytics.  The number of people infected is low and highly dependent on your control over the target's network.

Lots of developers have SSL enabled for login pages but still fetch code from HTTP CDNs.  This is bad practice and I want to make sure people know it.

What is obvious to you is obvious to you.  Most people have no idea how a DNS server actually works and so would have no idea that they can be compromised.  It is obvious to techy people.  Not everyone is techy.

EDIT: The hosts file was more for testing and pranking my coworker who hates the snow effect. And editing microsoft.com in the hosts file would only affect microsoft.com.  Everyone doesn't fetch supposedly trusted JS from microsoft.  They do from google-analytics.

[Bitsky]

tl;dr: If you control the DNS, you can serve malware.

I fail to see the spectacular news.

[Red Emerald]

It isn't spectacular news that is going to crush the internet. I am simply trying to make people more aware that a controlled DNS doesn't even have to specifically target your site.

It isn't a huge revelation in security that we should hash passwords, but how many months did it take Mt Gox? "Obvious" things need to be repeated so that people actually do them.

If we want to build websites that replace banks, we need to make sure that people here know how to do it correctly.

I hear tons of people telling others to use SSL, protect against XSS or SQL injection, and countless other things.  Often times those warnings don't actually come with an actual example attack.  I presented an actual example.

[Bitsky]

For a developer, this is however a scenario that's pretty much outside his control. He could server ga.js from his server, but then always needs to keep it updated. Until DNSSEC is rolled out, cache poisoning will always be an attack vector. That aside, I wish people would null route analytics; it's annoying and often causes lags.

[Maged]

Thing is, this isn't as bad as you think this is. Sure, they can point Google Analytics to a rouge server, but if they have control of the dns, they could do the same to any other HTTP site as well, regardless of whether or not the site uses Google Analytics. That's why DNSSEC is so important.

If your site involves private personal information at all, every page with said information (or where said information can be entered) MUST be entirely HTTPS (especially any external scripts), at least until DNSSEC is out. With DNSSEC, you can relax that requirement to only require HTTPS when private data is submitted (as in, the login page can be HTTP, but the submission of the login has to be HTTPS) and when private data is displayed.

[dark_st3alth]

This reminds me of another tool that does a similar thing but on a wireless network, it's attack is officially called packet hijacking or something.

But anyways, accessing a CDN or Public DNS server would be quite the pull off. One of them going rouge basically would never happen as well.

[coreking]

This attack is useful when, a victim is on an unsafe network such as an open wifi hotspot, and intentionally avoids doing anything important while on the network. The victim goes home, but the attackers modified 3rd party script is still cached, and continues to run arbitrary javascript on any site with the "infected" 3rd party script.

The victim might start to browse different websites that are more sensitive once they are no longer on an untrustworthy network that utilize the 3rd party script.

[molecular]

If you control DNS, you can do all kinds of bad stuff, obviously.

The attack you describe doesn't really involve google analytics, that's just your way of "showing off" you p0wned DNS.

[Bitsky]

This attack is useful when, a victim is on an unsafe network such as an open wifi hotspot, and intentionally avoids doing anything important while on the network. The victim goes home, but the attackers modified 3rd party script is still cached, and continues to run arbitrary javascript on any site with the "infected" 3rd party script.

The victim might start to browse different websites that are more sensitive once they are no longer on an untrustworthy network that utilize the 3rd party script.

That's why you configure your browser to delete all cached data when you close it.

[Red Emerald]

This attack is useful when, a victim is on an unsafe network such as an open wifi hotspot, and intentionally avoids doing anything important while on the network. The victim goes home, but the attackers modified 3rd party script is still cached, and continues to run arbitrary javascript on any site with the "infected" 3rd party script.

The victim might start to browse different websites that are more sensitive once they are no longer on an untrustworthy network that utilize the 3rd party script.

That's why you configure your browser to delete all cached data when you close it.

While clearing your cache would fix this, hardly anyone actually has their browsers configured to do that.  Most people don't even consider CDNs such as google analytics an attack vector.  If we want non-technical users able to securely browse the internet, then these security problems (simple as many of them are) need to be brought to people's attention.

[Maged]

This attack is useful when, a victim is on an unsafe network such as an open wifi hotspot, and intentionally avoids doing anything important while on the network. The victim goes home, but the attackers modified 3rd party script is still cached, and continues to run arbitrary javascript on any site with the "infected" 3rd party script.

The victim might start to browse different websites that are more sensitive once they are no longer on an untrustworthy network that utilize the 3rd party script.

That's why you configure your browser to delete all cached data when you close it.

That's also why no sane developer should be serving sensitive data over HTTP or have HTTP content on a sensitive page, period. HTTPS is *never* cached to disk.

[deepceleron]

This attack is useful when, a victim is on an unsafe network such as an open wifi hotspot, and intentionally avoids doing anything important while on the network. The victim goes home, but the attackers modified 3rd party script is still cached, and continues to run arbitrary javascript on any site with the "infected" 3rd party script.

The victim might start to browse different websites that are more sensitive once they are no longer on an untrustworthy network that utilize the 3rd party script.

That's why you configure your browser to delete all cached data when you close it.

While clearing your cache would fix this, hardly anyone actually has their browsers configured to do that.  Most people don't even consider CDNs such as google analytics an attack vector.  If we want non-technical users able to securely browse the internet, then these security problems (simple as many of them are) need to be brought to people's attention.

When I close Firefox it should automatically clear all:
☑ Browsing History    ☑ Cache


Adblock Filter Rule:

||google-analytics.com^

☑ Enabled


As far as DNS queries making it through my firewall to any DNS server other than my own...

/sbin/iptables -A OUTPUT -p udp -o eth1 --dport 53 --sport 1024:65535 -j DROP 

[Red Emerald]

Nice tips for the security conscious/paranoid, deepceleron.

[Bitsky]

That's also why no sane developer should be serving sensitive data over HTTP or have HTTP content on a sensitive page, period. HTTPS is *never* cached to disk.

I beg to differ: http://blogs.msdn.com/b/ieinternals/archive/2010/04/21/internet-explorer-may-bypass-cache-for-cross-domain-https-content.aspx

[Red Emerald]

That's also why no sane developer should be serving sensitive data over HTTP or have HTTP content on a sensitive page, period. HTTPS is *never* cached to disk.

I beg to differ: http://blogs.msdn.com/b/ieinternals/archive/2010/04/21/internet-explorer-may-bypass-cache-for-cross-domain-https-content.aspx

I feel like bringing up IE as an example of insecurity is unnecessary lol

[Bitsky]

Completely dropping all caching for https sessions makes not much sense and would hurt performance because every static image or stylesheet needs to be re-fetched every time. Also, you can enforce a disk caching in Firefox with "Cache-Control: Public". As far as I know, there is no RFC prohibiting the caching of https content.

Setting up a correct caching policy is the job of the webmaster. There's no reason not to cache e.g. layout images or css when doing https. You cannot rely on browsers as a webmaster. With "Cache-Control: Public", the guy running the bad DNS in this example could enforce the disk cache, circumventing the "https is never cached" assumption.

If you want a more trustworthy reply than mine: http://code.google.com/intl/en/speed/page-speed/docs/caching.html ("HTTP/S supports local caching of static resources by the browser.")

[coreking]

This attack in particular is mitigated using HTTPS anyway, since an attacker will not be able to perform the man in the middle/dns poisoning attack to inject a malicious payload into a 3rd party script. (assuming that the attacker cant bypass HTTPS and that the user doesnt click through warnings...)

The main problem is that websites allow insecure connections to 3rd party scripts (or first party scripts).