flagged for malware by Google, researchers confirm it was no false positive

Root cause appears to be recently-modified JavaScript file

On Thursday, was flagged by Google's Safe Browsing for malware. The warning, sparked debate among the development and security communities, as the initial reaction claimed Google triggered a false positive. However, additional research makes that claim seem unlikely.

[Poor design fosters hacker attacks of websites running PHP]

By mid-morning on Thursday, Google's Safe Browsing initiative was flagging, warning visitors that the site was malicious. The root cause appears to be a JavaScript file that had undergone several modifications over the last 24-hours.

The file is clean now, but the version flagged by Google was embedding iFrames and treating visitors to malware hosted on four different sites. According to Google's report, there were only four pages on serving the malicious JavaScript, out of a scan of more than 2,000. The low results, and the fact that only some visitors were seeing the warnings, led many to believe that Google had falsely flagged

There was plenty of debate on the topic, but some visitors were able to get a copy of the altered JavaScript file (userprefs.js), and examine the obfuscated code. The malicious part of the content was selective, as the obfuscated code only showed up when a visitor hit the domain with a desktop browser; those using incognito mode or a smartphone were not impacted.

Researchers at Barracuda Labs were able to confirm that Google's assessment was correct, and provided a pcap (packet capture) file for researchers to examine. Those who examine the file can see the malicious activity start with a suspicious DNS request at packet 158, while packets 177 and 180 show malicious Shockwave (Flash) files being delivered. It's unknown what vulnerabilities the SWF files were targeting.

Speculation has driven the notion that this incident could be related to a watering hole attack, which as become a popular attack method over the last year or so. Many of those contributing to this speculation are referencing an attack earlier this year, where a popular iOS developers forum was compromised, leveraging Zero-Day vulnerabilities in Java to compromise systems used by developers at Apple, Facebook, and Twitter.

During a watering hole attack, an attacker will compromise a domain that's likely to be visited by their selected victims, such as a group of developers or programmers, rather than attempting to attack them directly though phishing or another means. The hope is that eventually, someone from the targeted group will visit the compromised domain — the watering hole — and compromise their systems.

This style of attack exploits the trust users place in frequented domains. Such attacks are also popular for run-of-the-mill attackers, because the exploited trust allows them to target a wider pool of potential victims, which is one of the reasons exploit kits were created.

[PHP patches actively exploited CGI vulnerability]

The suspect file on has been restored, but there is no information available as to how file was changed. Despite the findings from Barracuda Labs and others who investigated the issue, opinion remains split on the topic, with some remaining doubtful that a problem existed to begin with.

Copyright © 2013 IDG Communications, Inc.

7 hot cybersecurity trends (and 2 going cold)