Spyware

'Aurora' Attacks Still Under Way, Investigators Closing In On Malware Creators

Researchers find 'markers' associated with authors of Aurora malware used in attacks against Google, others

The targeted attacks that hit Google, Adobe, and other U.S. organizations are still ongoing and have affected many more companies than the original 20 to 30 or so reported by Google and others.

Security experts who have worked on forensics investigations and cleanup of the victim organizations from the attacks that originated out of China say they are also getting closer to identifying the author or authors of the malware used to breach Google and others.

...

He and other forensics firms say they have no direct evidence implicating the Chinese government in the Aurora attacks, but that doesn't mean other investigators or officials have it and just aren't sharing it publicly, Hoglund says. HBGary has found trails left behind in the Aurora code by its creators that are "very specific to the developer who compiled the malware," Hoglund says, and it has Chinese language ties.

HBGary has identified registry keys, IP addresses, suspicious runtime behavior, and other data about the Aurora malware and its origins using the firm's latest analysis tool, he says.

/*
Call me cynical, but it sounds to me like HBG is using this whole 'Aurora' thing to try to sell copies of it's latest product.
*/

Hoglund says HBGary was able to identify "markers" specific to the way the Aurora developer wrote the malware. But he says his firm did not include this in its new report. "This is not in the report because we don't want him to know what we know about his coding," he says. "[It] is algorithmic in nature."

/*
Assuming they did find distinct characteristics about the programmer('s) code, that's like having a partial fingerprint and no database of fingerprints to compare it to. Do they expect to get every person in the world that can write code to submit samples for comparison?
*/

Kevin Mandia, CEO of forensics firm Mandiant, also says his firm's investigators are getting close to exposing the creators of the Operation Aurora malware. "We feel like we know a couple of them in their coding -- we recognize their trademarks ... down to the person."

/*
I also find this hard to believe. In working with people over extended periods of time, a decent programmer can generally figure out which of his coworkers wrote a piece of code based on things such as commonly-used variable names, snippets of syntax, tab-width, 1TBS vs. Allman bracing style and comments. Most or all of this information is lost when the code is compiled and debugging symbols removed.
*/

He says attacks that steal intellectual property typically funnel the goods via IP addresses based in China. But Mandia says he doesn't know if the Chinese government is involved in the recent attacks or other APT attacks, though some trends with these attacks raise questions. "We see patterns that just make us curious. If you're doing merger and acquisition work in China, you're targeted," Mandia says. "We've seen when we respond to client sites [that were attacked] a lot of legal counsel, external counsel, and C-level executives [targeted] in M&A with China."

/*
As usual, I'm going to apply Occam's Razor here and guess that if it walks like a duck, and quacks like a duck, it's probably going to be served with packets of duck sauce. :)
*/

'Aurora' Code Circulated for Years on English Sites

Updated An error-checking algorithm found in software used to attack Google and other large companies circulated for years on English-speakinglanguage books and websites, casting doubt on claims it provided strong evidence that the malware was written by someone inside the People's Republic of China.

The smoking gun said to tie Chinese-speaking programmers to the Hydraq trojan that penetrated Google's defenses was a cyclic redundancy check routine that used a table of only 16 constants. Security researcher Joe Stewart said the algorithm "seems to be virtually unknown outside of China," a finding he used to conclude that the code behind the attacks dubbed Aurora "originated with someone who is comfortable reading simplified Chinese."

/*
Doubt is now being cast upon the assumption that someone within China was behind the attacks. I still have my suspicions.
*/

In fact, the implementation is common among English-speaking programmers of microcontrollers and other devices where memory is limited. In 2007, hardware designer Michael Karas discussed an almost identical algorithm here. Undated source code published here also bears more than a striking resemblance.

...

"Digging this a little deeper though, the algorithm is a variation of calculating CRC using a nibble (4 bits) instead of a byte," programmer and Reg reader Steve L. wrote in an email. "This is widely used in single-chip computers in the embedded world, as it seems. I'd hardly call this a new algorithm, or [an] obscure one, either."

/*
Gee, where are nearly all microchips/microcontrollers fabricated these days? China.
*/

Two weeks ago, Google said it was the victim of highly sophisticated attacks originating from China that targeted intellectual property and the Gmail accounts of human rights advocates. The company said similar attacks hit 20 other companies in the internet, finance, technology, media and chemical industries. Independent security researchers quickly raised the number of compromised companies to 34.

/*
Targeting the human-rights advocates kind of seals-the-deal in my mind. We've got three major parts of the world where the vast majority of malware originates; eastern Europe, Russia, and China. Let's see, who has the most atrocious human-rights abuses of the three? China.
*/

One of the only other reported links between China and the attacks is that they were launched from at least six internet addresses located in Taiwan, which James Mulvenenon, the director of the Center for Intelligence Research and Analysis at Defense Group, told The Wall Street Journal is a common strategy used by Chinese hackers to mask their origin. But it just as easily could be the strategy of those trying to make the attacks appear to have originated in China.

/*
This is a valid point; it could be someone wishing to make it appear that the Chinese were behind the attack. I'd have to admit, the Chinese hackers and malware authors are generally smart enough to cover their tracks, so for the attacks to originate in a favored part of the world for the Chinese does seem a little short-sighted.
*/

The lack of evidence is important. Google's accusations have already had a dramatic effect on US-China relations. If proof beyond a reasonable doubt is good enough in courts of law, shouldn't it be good enough for relations between two of the world's most powerful countries?

/*
I would like to see something a little more definitive before saying I'm certain that the Chinese were behind the attacks; but so far, we've got a "smoking gun" (the exploit code contained in the targeted phishing attacks), but have yet to identify any "fingerprints." Applying "Occam's razor," as I'm wont to do, it would appear that someone in China was behind this.

I whole-heartedly support Google on their threat to pull out of China. With Wal-Mart already selling this country out from under us every day, I don't like to see any U.S.-based company doing business with China. Unfortunately, in this situation, it appears that the Chinese citizens will really be the ones that lose.
*/

Law Firm Suing China Hit By Cyber Attack

Last week, Santa Barbara, Calif.-based CYBERsitter sued the People's Republic of China, the two Chinese software makers, and seven computer manufacturers for distributing Web filtering software known as Green Dam with allegedly stolen code.

This week, the law firm representing the company said that it had been targeted in a cyber attack from China.

In a phone interview, Elliot B. Gipson of Gipson Hoffman & Pancione described what amounts to a spear-phishing attack -- the same technique used against Google in China. "They were e-mails targeted at individuals in our law firm that were made to appears as if they were coming from other individuals at our law firm," he said. "They attempted to get the target to click on a link or attachment."

/*
It looks like China is at it again. When will our government say "enough is enough?"

Given that we've "outsourced" essentially all of our manufacturing jobs to China, India, and Mexico, all we have left to power our economy is our ingenuity; our intellectual property. The Chinese government has made little effort to hide the fact that they are behind these attacks.

I'm really starting to favor a new "Cold War," this time against China. We toppled the Soviet Union without firing a single shot; there's no reason we couldn't do the same to China. With carefully coordinated electronic attacks, we could cripple their booming economy and leave them in ruins without risking one single American life.

For those who have no reason to receive email, or other network traffic, from China and the other "problem children" in APNIC, here is a list of subnets that are managed by APNIC. You may wish to null-route all of them, or fine-tune the list to your needs.

*/

Researchers Identify Command Servers Behind Google Attack

VeriSign's iDefense security lab has published a report with technical details about the recent cyberattack that hit Google and over 30 other companies. The iDefense researchers traced the attack back to its origin and also identified the command-and-control servers that were used to manage the malware.

The cyber-assault came to light on Tuesday when Google disclosed to the public that the Gmail Web service was targeted in a highly-organized attack in late December. Google said that the intrusion attempt originated from China and was executed with the goal of obtaining information about political dissidents, but the company declined to speculate about the identity of the perpetrator.

/*
Emphasis is my own, but I wanted to ensure that those reading this immediately saw that it was China behind these attacks.
*/

Citing sources in the defense contracting and intelligence consulting community, the iDefense report unambiguously declares that the Chinese government was, in fact, behind the effort. The report also says that the malicious code was deployed in PDF files that were crafted to exploit a vulnerability in Adobe's software.

"The source IPs and drop server of the attack correspond to a single foreign entity consisting either of agents of the Chinese state or proxies thereof," the report says.

/*
In other words, these attacks weren't carried out by people who just-so-happened to be Chinese citizens; but were carried out by, or at least encouraged by, the Chinese government.

Later in the article, there's an update stating that it appears the attacks did not use specially crafted PDFs but most likely an unpatched vulnerability in Microsoft Internet Explorer.

I'd bet that there's probably a 0day exploit floating around for every 10 lines of code in IE. It's just pathetic. The single biggest recommendation that I offer all of my friends and family is to not use IE if they value their computer and it's data. I tell them that by using Firefox -- which is not without it's own security issues -- instead of IE, that it's the single most effective action they can take to avoid malware on their systems.
*/

"The servers used in both attacks employ the HomeLinux DynamicDNS provider, and both are currently pointing to IP addresses owned by Linode, a US-based company that offers Virtual Private Server hosting. The IP addresses in question are within the same subnet, and they are six IP addresses apart from each other," the report says. "Considering this proximity, it is possible that the two attacks are one and the same, and that the organizations targeted in the Silicon Valley attacks have been compromised since July."

/*
"six IP addresses apart" is probably within the same /28 or /29.

On my home network, I typically block all subnets handled by APNIC; using either Linux netfilter on the firewall, or regex pattern matching via Squid proxy. This is using a cannon to kill a mosquito, and would definitely not work in the enterprise, but it works fine for my own personal protection. I have no need to visit any sites hosted on APNIC addresses as I cannot read any language other than English.

Unfortunately, my tendency to block wide swaths of IP space would not have protected my home computers from becoming zombies in this attack. It appears that the C&C servers were hosted in the U.S.
*/

/*
A while back, I set up a transparent Squid proxy at my border to limit my exposure to "drive-by downloads." It's a pretty standard setup; Squid running on the gateway/firewall, and iptables configured to route all tcp/80 traffic back into itself on port 3128.

An unfortunate side effect of this is that tcptraceroute breaks. As port 80 is the default port that tcptraceroute uses (as the destination port), you end up with a traceroute that looks something like this:

(root@desktop1) ~# tcptraceroute www.ebay.com
Selected device eth0, address 172.25.X.XXX, port 39068 for outgoing packets
Tracing the path to www.ebay.com (66.135.200.145) on TCP port 80 (www), 30 hops max
1 hp-core.ebay.com (66.135.200.145) [open] 0.558 ms 0.384 ms 0.315 ms

I can assure you, I'm not 1 hop off from www.ebay.com. Since iptables is mangling the packet at the very first hop, my gateway/firewall, I'm receiving the SYN-ACK from that first hop.

Keep in mind, tcptraceroute will use any destination port you specify, but the default is port 80 since it's usually allowed through most firewalls, and often open.

Given that the default TTL of a Linux-based computer is 64, I can use the TTL match in iptables to selectively capture what tcp/80 traffic goes to the proxy and what does not. Consider the following rule:

iptables -t nat -A PREROUTING -i $IF_INT -p tcp --dport 80 \
-j DNAT --to-destination 172.25.X.XXX:3128

This is the rule that routes all outbound traffic, originating on the internal network, to the Squid proxy. Now if we change that rule to match only packets with a TTL larger than, say, 48, we end up with the following:

iptables -t nat -A PREROUTING -m ttl --ttl-gt 48 -i $IF_INT -p tcp --dport 80 \
-j DNAT --to-destination 172.25.X.XXX:3128

With this rule in place, a tcptraceroute headed for www.ebay.com on tcp/80 looks more like the following:

(root@desktop1) ~# tcptraceroute -f6 www.ebay.com
Selected device eth0, address 172.25.X.XXX, port 57684 for outgoing packets
Tracing the path to www.ebay.com (66.135.200.145) on TCP port 80 (www), 30 hops max
6 so-1-2-0.gar2.chi1.bbnplanet.net (4.79.74.1) 76.668 ms 23.024 ms 30.840 ms
7 ae-31-55.ebr1.Chicago1.Level3.net (4.68.101.158) 57.014 ms 34.438 ms 36.097 ms
8 ae-68.ebr3.Chicago1.Level3.net (4.69.134.58) 25.716 ms 22.857 ms 32.941 ms
9 ae-3.ebr2.Denver1.Level3.net (4.69.132.61) 84.660 ms 49.091 ms 40.722 ms
10 ae-1-100.ebr1.Denver1.Level3.net (4.69.132.37) 79.996 ms 52.921 ms 52.897 ms
11 ae-3.ebr2.SanJose1.Level3.net (4.69.132.57) 71.323 ms 70.999 ms 71.651 ms
12 ae-82-82.csw3.SanJose1.Level3.net (4.69.134.218) 66.468 ms 70.863 ms 72.099 ms
13 ae-32-89.car2.SanJose1.Level3.net (4.68.18.132) 65.688 ms 62.794 ms 59.597 ms
14 EBAY-INC.car2.SanJose1.Level3.net (166.90.140.134) 60.576 ms 65.507 ms 58.566 ms
15 10.6.1.158 71.070 ms 59.413 ms 59.670 ms
16 10.6.1.146 61.397 ms 88.846 ms 68.280 ms
17 hp-core.ebay.com (66.135.200.145) [open] 84.341 ms 59.523 ms 62.286 ms

Now that looks a little more reasonable. Given that I'm 1 hop off from the gateway/firewall, and Linux uses a default TTL of 64, then all of my packets generated by, say, Firefox, will come into $IF_INT with a TTL of 64. With 64 > 48, the DNAT rule matches, and the request gets routed through the Squid. As tcptraceroute works like any other traceroute tool, only using TCP SYN packets, the first packet will only have a TTL of 1. With 1 < 48, it does not match the DNAT rule, and passes through unchanged. The second packet will have a TTL of 2, with 2 < 48, and so on. As most all destinations on the internet are reachable in 30 hops or less, this guarantees that my browser generated requests are proxied, while my diagnostic requests are passed through unchanged.

You can view/change your default TTL as such:
(root@desktop1) ~# cat /proc/sys/net/ipv4/ip_default_ttl
64

Needless to say, the IP addresses have been changed to protect the innocent. ;)
*/

Sourcefire Acquires ClamAV

Sourcefire, a maker of intrusion detection products, announced on Friday that the company had acquired the intellectual property and copyrights to the open-source antivirus project, ClamAV, from five key developers.

...

"Sourcefire pioneered the business of balancing commercial solutions with open source innovation, and we intend to apply those same Snort sensibilities to the ClamAV project," Roesch said in a statement.

/*
This basically sounds like they're going to ruin ClamAV like they've done with Snort. My guess is that ClamAV will not be available for free, at least not the fully capable version, for much longer. You may end up being able to download and install/run a binary version of ClamAV with half the features missing; or just having to come up with the cash to license it legit.
*/

---

Some more information in regards to the purchase of ClamAV. I think this guy says it best:

Anybody feels like placing bets on how long it’s going to take SourceFire to pull the same trick with ClamAV signatures they pulled with Snort signatures where you’ll need to “conveniently” license the signatures from SourceFire to have the latest ones to be properly protected :-)

The engine source code will be useless if you don’t have the very latest AV sigs…

Know Your Enemy: Fast-Flux Service Networks

/*
This is an excellent, in-depth look at how high-profile scammers and phishers are tricking people into submitting their most private information. This is hosted by the HoneyNet project, so it's certainly worth a read.
*/

Beware: Bogus Better Business Bureau Blast

Security vendor Websense is reporting the return of a bogus Better Business Bureau e-mail. The attached Word document in this release contains a Trojan that, when opened, attempts to download and install a keylogger which then uploads stolen data from the compromised PC to an IP address located in Malaysia.