From:
http://www.bluecoat.com/blog/look-google-hack-aka-aurora-attackBackground
In what is easily the biggest malware story since the Conficker outbreak, Google announced on January 12th that they'd been investigating "a highly sophisticated and targeted attack" on their systems. Further, they took the unusual step of openly stating that the attack originated from China, and that they had found evidence that more than twenty other larger corporations had also been targeted.
A couple of days later, this was followed by news that the attack used a vulnerability in Microsoft's Internet Explorer browser. (Late last week, news leaked out that Microsoft had known about this vuln since last August, that a patch had been developed, and was in testing for a scheduled February rollout.) An IE patch for this vuln plus six or seven others that were pending was rolled out by Microsoft on the 21st.
Because Google has not released an official update on their blog since the original Jan. 12th post, the security community has been trying to piece together more of the details. Here is a sampling of what we know so far:
The "Command and Control" servers for this attack were traced by Google to Taiwan (which is where their engineers accessed a server that contained the evidence of the attacks on the other companies). This by itself, of course, would not prove a Chinese origin for the attacks, as servers can be hosted anywhere (this is the Internet, after all!) However, the fact that one of the key datasets sought by the attackers was the Gmail accounts of Chinese human rights activists, and a bit of nifty sleuthing based on a unique algorithm in the malware source code, point more directly to China. (BTW, that last link also shows where the "aurora" name came from.)
Technical Details
While some have questioned the plausibility that all of the companies were hacked via the same IE6-only exploit, that's the official story so far, so we'll stick to that. Basically, this bug in IE is found in all versions since v6, but the exploit used in the attacks was only functional with IE6 -- it would require modification to work in IE7, and further modification to work in IE8, which contains additional safeguards against this sort of thing.
At some point, someone investigating the malware apparently posted a sample of the javascript-based exploit trigger to wepawet (an experimental tool that looks for suspicious javascript in web pages). Someone else noticed, and wrote up a formalized version of the exploit. From there, the rest of the Bad Guy universe, who didn't know about the new exploit, have picked it up and added it to their exploit toolkits.
We can assume that the IE6 exploit packages will soon be joined by versions that target IE7 (and possibly IE8), if they haven't already. But the fact is that there are dozens and dozens of recent (and not-so-recent!) exploits still being deployed by the Bad Guys in their attacks every day. (Even long after patches have been released by the targeted software vendors, the Bad Guys know that there are always plenty of unpatched systems out there.) So, we can confidently predict that future attacks will certainly contain exploits based on "aurora". As so many exploits have before, it will quickly make the transition from "new and scary" to "old hat". Fortunately, the Good Guys also know about it now, which means we're back to a normal status quo: if you've got good defenses, and you're adequately patched, you'll be OK, but if you're not, then you'll probably get infected, just like always.
On the WebPulse™ front, as details about the attack emerged, we began identifying the sites being used to host the attack malware (and, more importantly, what the traffic looked like). Most of the malicious sites were hosted on subdomains served via Dynamic DNS hosting services. As I look back through the database, it appears that these sites came into use after the exploit was publicly posted. In other words, these represented the second wave of Aurora-based attacks. My hunch is that the original attacks that Google noticed back in December are completely separate from this second wave. (I'm still digging through logs going back a month; I'll post anything interesting I find.)
Implications
First of all, whenever security pros hear "targeted attack" they think "spear phishing". Unlike normal phishing, which relies on very widespread spam or social networking attack vectors, spear phishing focuses on a particular group of targets. If an attacker can put together a list of email addresses for a particular corporation (not too hard), and a general idea of the org chart (also not too hard), they can produce a much more believable email than a common spammer can. With the headers forged to look like it's coming from someone within the organization, and its content dealing with some current event relevant to the company, the recipients are skillfully manipulated from the "don't open attachments in emails from people you don't know" mindset to the "it's OK to click on links in emails from people you do know" mindset. If even one of the recipients with a vulnerable system takes the bait, the exploit triggers.
The spear-phish email contains a link to a malicious Web page, with the exploit contained directly in its javascript (for browser exploits), or else the script downloads an auxiliary file with an exploit that targets a browser plug-in (bogus PDF files being a continuing favorite). In either case, the computer's security is "exploited", and the attacker can then direct the browser to secretly download the actual malware package. Once the malware is installed, the attacker has a foothold in the corporate network, and can begin searching for the desired data.
In a nutshell, this is the scary part: thirty big corporations had their systems penetrated, and it looks like none of them knew about it until Google raised the alert. (I'm assuming that what Google found on the enemy server was evidence of successful attacks -- actual evidence of stolen data, not just a list of targets being attacked.) The victims' anti-spam defenses failed to catch the bogus emails. Their web filter permitted the link to the site with the exploit, and the connection to download the malware payload. Their antivirus didn't recognize the malware download (as it was brand-new for this attack). Their IDS/IPS (Intrusion Detection/Prevention Systems) didn't spot it. And their DLP (Data Loss Prevention) systems didn't catch the data as it left.
Or maybe not. It might not be that bad. Lacking many details from Google and Adobe (the only two companies who have said much about it), and not knowing anything about the other victims, we're only guessing about the scope and severity. But it sure looks like the Bad Guys defeated all the Good Guy technology and won this round, and it was up to an alert sysadmin at Google to notice something amiss in the network logs and start investigating....
As you might expect for a story of this size, we'll be doing further blog posts in the future, looking at specific aspects of this attack and the implications for corporate web security.
Further Reading
A very interesting commentary thread emerged that focused on one of the apparent targets within Google: a system designed to collect user account information (including email headers but not email content, for example) so that it could be more easily handed to government agencies with search warrants. See commentary here and here on the security ramifications of building systems with such "official security vulnerability" access points, with the original source for the story here.
And, for an excellent four-page overview of the whole incident and side stories, with plenty of links, try the zdnet blog.
Posts
