Wednesday, June 24, 2009

Google Analytics targeted by hackers

The twitersphere is on fire over a Google Analytics support forum thread. I was chatting with Eran Ben Sabat, a London-based fellow web analytics consultant who said "have you seen the latest with the GA code? The regex thingy sending trafic to a another domain". I relayed the info on Twitter, which was picked up by several people and started to spread like crazy.

This post is a summary of several threads and resources about this exploit.

Is my GA being hacked?

The thread shows several accounts of websites using GA were the default implementation script was replaced with a gibberish string of JavaScript code. It's fascinating to see the thread evolving with the help of people contributing various hypothesis: ftp security, software hole, etc.

Have you been infected?
  1. Visit your site home page
  2. Do a view source
  3. If the typical Google Analytics script code block contains a string of weird characters, your site has been infected
    (another similar exploit uses an IFRAME, so check your source code for something like "document.write("<"+"i"+"f"+"ram"+"e"..., which creates an IFRAME referencing a site named "")
Tip: To help identify if Google Analytics isn't behaving as expected, you can install the Web Analytics Solution Profiler. If it doesn't show Google Analytics while you expect it, check your source code.

The exploit is as follow:
  1. htttp:// is being change by the regex to
  3. which runs
  4. this executes an Adobe Reader exploit BID27641 and BID 34169 (Symantec call this the Bloodhound.Exploit.196)
  5. files with typical names such as login, index, default, home with PHP, ASP or HTML extensions are targetted
Bloodhound.Exploit.196 is a heuristic detection for files attempting to exploit the Adobe Acrobat and Reader Multiple Arbitrary Code Execution and Security Vulnerabilities (BID 27641) or the Adobe Acrobat and Reader Collab 'getIcon()' JavaScript Method Remote Code Execution Vulnerability (BID 34169).
We now have an explanation of the exploit, but we still don't know how the code is being altered.

The injection

Some accounts reports as much as 25% of Joomla (a popular platform running on Apache servers with PHP) forum posts being about this and several other threads discussing similar issues. The reality: the injection is an exploit on week security settings on Apache HTTP servers and unencrypted FTP passwords saved by popular tools used for editing websites. Once a client machine is infected, all commonly used tools are harvested to collect more unencrypted FTP passwords and contribute to the dissemination of the attach.

Is it a Google Analytics security issue: No
Is it a Google Analytics exploit: Yes

This hack is not a Google Analytics security issue, it is not an Apache or PHP issue either. It is a server security & maintenance issue. Some fellow tweeters have pointed this out, however, the onsite malicious javascript code is disguised as Google Analytics code. the onsite malicious javascript code is disguised as Google Analytics code, then and it may have implications for the trust in the Google Analytics brand. Thus it might be worthwhile for Google investing resources trying to help web developers fix and also prevent from happening in the future.
The 1st message in the forum thread was on June 16th, and the 1st Google employee reply came a week later, on the 23rd, merely saying it is NOT a Google Analytics security issue and pointing to some general best practices on good website management. But none of them really address the specifics of this exploit.

The fact Google Analytics is so widely used, and the script code block is always identical, certainly made it a target of choice for this exploit.

Closing the door

Google suggests to look at those resources:
Interesting, but certainly not to the point, instead, do this:
  1. Start with your own computer. Scan it with anti-virus and anti-spyware tools.
  2. Once you are sure your computer is clean, change all site passwords. (You might want to change computer and network passwords too.)
  3. Make sure you have the latest Adobe Acrobat reader
  4. Now keep the new passwords secure. Don’t use auto-upload features of your web site editors. Enter passwords every time you upload new content instead. Use SFTP instead of FTP if possible.
  5. Now remove the malicious code (the iframes/regex) from your files on server. The easiest way to do it is upload a clean content from a backup.
  6. Scan your server directories for any new/suspicious files (don’t forget to check hidden files). Remove anything that should not be there.
  7. If your site was flagged by Google, request a malware review via Webmaster Tools.
  8. Regularly check your site with diagnostics tools of your choice
Hope that helps!