The 0day Google hack attacked a invalid pointer reference within Internet Explorer. It seems that malicious web links were visited by Google employees, resulting in FUD spyware installations on their workstations. Over the past couple of decades, this type of vulnerability has been exploited and sometimes resulted in hugely prevalent and successful exploits on the web, such as the infamous createTextRange Internet Explorer mshtml.dll hole.

Update: Google China employees seem to have been given an early holiday, according to Tech Crunch IMers.

The trojan itself has been analyzed and described on our ThreatExpert blog here and more information from Symantec on the attacks here.

The past year showed massive numbers of malware being run on systems across the globe. Behind the malware was an active malware marketplace, often with forums full of services for hire, advice on distributing and maintaining crimeware, and devious ways to hire money-mules.

There is more than meets the eye to these services. Much of the activity was not being discussed in these public forums or was as front and center in the media as the Conficker circus. While bot activity is not new to the party, a recently published study “SBotMiner: Large Scale Search Bot Detection“ brings in the year with a fresh start on identifying and quantifying malicious search bot traffic. The activity is under-studied and significant: the “miner” identified that almost 4% of all query traffic is bot-related (which represents at least hundreds of millions of search queries every couple of months), and that seems to be only the tip of the iceberg. The traffic was collected in Feb and April 2009, the search engine is not specified (google, yahoo!, live, altavista, ask, etc.) and that selection may have impacted the studies’ volumes and results. It is suggested that Live search results were used, so results most likely are much larger when the other engines are considered. The study also includes more forms of bot-based attacker-related traffic, instead of exclusively examining click fraud related bot queries and activity.

The discussion and findings included:

“More importantly, detecting bot-generated search traffic has profound implications for the ongoing arms race of network security. While many bot queries from individual hosts may be legitimate (e.g., academic crawling of specific Web pages), a significant fraction of bot search traffic is associated with malicious attacks at different phases. In addition to the well known click-fraud attacks that can be commonly observed in query logs, attackers also use search engines to find Web sites with vulnerabilities, to harvest email addresses for spamming, or to search well-known blacklists.”

“Attackers are leveraging search engines for exploiting vulnerabilities of Web sites. SBotMiner Identifies 88K searchbot groups searching for various PHP scripts and ASP scripts.”

“Using the entire datasets, SBotMiner detects 8,678 groups searching for PHP scripts in Feb and 79,337 such groups in April; 64 groups searching for ASP scripts in Feb and 301 groups in April. These searches spread all over the world.”

“Initial evidence shows that many of them might be associated with various forms of malicious activities such as phishing attacks, searching for vulnerabilities and spamming targets, or checking blacklists. Interestingly, attacks from different countries and regions do exhibit distinct characteristics, and search bots from countries with high bandwidth Internet access are more likely to be aggressive in submitting more queries.”

“We used sampled query logs collected in two different months and identified 700K bot groups with more than 123 million pageviews involved. The percentage of bot traffic is non-trivial — accounting for 3.8% of total traffic”  

So how might this effect you, dear reader? Well, 2010 already brings with it more publicly available information on the methods being used to harvest information about you, the blackhat Seo that these groups are increasingly relying on and the means in which these groups attempt to identify vulnerable servers to attack and use, in turn, to attack your system. It’s a fine read with some fresh information and an enjoyable way to settle into the New Year.

Anyways we are observing some download and execute shellcode attacking user systems that pull down the malicious file from a server (that server’s admin, the owners of the site, and the ISP have all been contacted over the past couple of days. At least the ISP got back to us with a low priority ticket). Here is an example of the malcode calling “urlmon.UrlDownloadToFileA” on hxxp:// 20x.x16.xx.xx/ white.ccs and copying the undetected “AFCode” or “CoreFlood” variant download to c:\index.tmp. We use a tool and process that we posted last year for shellcode examination:

And here is the call to “kernel32.Winexec” to get that file started on the system, which drops and loads its dll file:

The binary, c:\index.tmp, doesn’t carry much of an unpacking stub. We see more xor loops and import redirection tricks than anything, which makes it unusual that the AV crowd can’t keep up with this one. It drops a set of unusual looking dat files, and adds CLSIDs and an unusual ShellIconOverlayIdentifiers registry entry for startup. Inside the dropped dll, we find a slew of strings that suggest this malicious component is simply reused Coreflood code:
AFCORE
Removing AF from the system . . .
AF up time: %t
Flooding %s . . .
Flooding of %s has been completed
Processing diskflood log file %s . . .

The file immediately POSTs information about its host operating system, version of the software, etc, back to another server over http, among other things.

It’s not especially fun to see this coreflood family back in the wild. Coreflood seems to have caused problems for individuals performing online banking in the past few years, as the Secret Service found it on Joe Lopez’s laptop in the disturbing BofA v Lopez. But I suppose we’ll never really know for sure about that one. It was settled out of court, and neither side will respond to repeated calls regarding their own settlement.

Update: over the weekend, the malicious “white.ccs” file was silently removed from the server. And the ISP handling the problem interestingly deleted the support ticket they had issued for my request.

Instead, this trojan downloads “cb_1.exe” and runs it, installing multiple password stealing and rootkit components that are not new (but this version of the fraudulent scheme is new). The components, including 9129837.exe (Spyware.Papras) and new_drv.sys (Rootkit.Agent.ex) will steal all web form input (from any and all banks, for example), most any other stored passwords on the system, and send the data off to a server hosted in Singapore.

The various code used in targeted attacks that we have evaluated to date are not terribly impressive pieces of malware. The trojans and spyware often are delivered over email as embedded data within files of all formats with enticing names that the recipient would most likely be interested in. For example, the NPR interview mentioned a “resume.doc” file that was delivered to current board members and staff of the targeted Students for a Free Tibet from the spoofed email address of an ex-board member. These Microsoft Word docs, Excel spreadsheets, malicious .chm help files, and Powerpoint slideshows usually are malformed in one way or another to attack vulnerabilities in flawed software on the receiver’s side. When opened by outdated software, these maliciously crafted files and the included code drop and run trojans and spyware embedded in the files on the victim’s system.
Most can be prevented by keeping software updated and patched, running security solutions, and as always, security in layers is recommended.

The audio mentions that most AV scanners are often evaded by the software components of these targeted attacks (an unusual admission from a member of the AV industry!). And that trojan builders create nastier rodents in response to the AV companies’ better mousetraps.
ThreatFire is different — our behavioral-based cat is bigger and faster than that little piece of cheese sitting on the wire and wood thing in the attic. Purrs like a kitten too.

“Oak Ridge National Laboratory (ORNL) recently experienced a sophisticated cyber attack that appears to be part of a coordinated attempt to gain access to computer networks at numerous laboratories and other institutions across the country. A hacker illegally gained access to ORNL computers by sending staff e-mails that appeared to be official legitimate communications. When the employees opened the attachment or accessed an embedded link, the hacker planted a program on the employees’ computers that enabled the hacker to copy and retrieve information. The original e-mail and first potential corruption occurred on October 29, 2007. We have reason to believe that data was stolen from a database used for visitors to the Laboratory.”

Targeted attacks like this one are more common than they were a couple of years ago. Be wary of incoming email attachments and hyperlinks.

UPDATE (12.13.2007): Speaking of data breaches and network intrusion, Bruce Schneier has a related post on his blog today about a newly released study. The UC Berkeley Samuelson Law, Technology, & Public Policy Clinic recently completed and released a study on “Security Breach Notification Laws: Views from Chief Security Officers“. It evaluates the profound effects on practices within U.S. companies resulting from the implementation of security breach notification state laws. Great read.

“Some people won’t ever want to yield control; others will worry that the first smart cars will be like the early versions of Windows. There will be many, many car-computer jokes involving the word “crash.” “

Yeah, sounds fantastic. Cars that drive themselves. The statement conjures up fond memories of field trips to Chicago’s massive Museum of Science and Technology, the futuristic transportation gizmo Piccard Gondola, and other cliches like “the Home of the Future”.
Or just maybe, a version of Microsoft Windows driving my car. That statement conjures up memories of blue screens of death (sounds horrible in relation to cars that drive themselves!), third party component heap overflow attacks, flawed ActiveX permissions, “Venetian shell code” techniques, and the confusing acronym soup of security hype that plagues users of the internet. There’s a new swarm of security concerns every quarter. And this stuff is going to drive my car?

The implementation is where the rubber hits the road, and it always seems to happen that security concerns fall last in the list of engineering priorities in a project (except for some fine examples, vsFtp and OpenBSD folks). If you’ve seen The Italian Job, you’ve watched what can happen when the networking meets transportation — the L.A. transporation department gets reminded “You’ll never shut down the real Napster”. These sorts of concerns are very relavent to projects like computer-automated driving learning systems. My hope is that the security efforts of the sorts that Microsoft has aggressively begun attending to over the past couple of years will be built into these driving platforms from the ground up.

Grandma might have thought that would be a fine idea.

Now, not only are these packages delivering repacked and crypted binaries via harmless looking but malicious web pages, but they are re-obfuscating the malicious content hidden on the web pages at very small intervals. The threats, at every level, are constantly changing.

We collected up these changing pages from multiple malicious web sites, de-obfuscated their code, and isolated each exploit with its shellcode to analyze them, and to identify any problems they might cause for security products. Here are some notes from our research on in-the-wild web exploits:

The code across malicious groups is becoming more and more similar. There most definitely is code sharing between the groups writing the exploits. Some of them are the exact same techniques for identical exploits.

One recent addition to the commoditized exploit packages that are bought and sold online that has not been much discussed is exploitation of a recently disclosed Yahoo Messenger vulnerability, with shellcode that evades some of the major av vendors’ security software.

The vulnerability effects a version of a component called the “Webcam Viewer Networking and Imaging” ActiveX component (ywcvwr.dll v2.0.1.4). Basically, an old-fashioned stack-based buffer overflow occurs because a 1023 byte buffer is set aside to store input for webcam functionality, but the input is not properly checked, allowing for maliciously crafted webcam objects to run arbitrary code of the attacker’s choosing.

We examined the attacker’s approach. They use a reliable method of delivering control to their shellcode on XP Sp2 and Vista systems over IE6 and IE7 with default settings: they spray the heap with shellcode of their choosing simply by creating a dozen or so variables in their javascript, and stuffing them with lots of NOP followed by shellcode. They then deliver a large amount of data (5000 bytes) to this unchecked 1023 byte buffer and overrun values on the stack, including the exception handler. An exception occurs, and because the exception handler is overwritten with an address on the heap, control is passed to their download and execute shellcode.

By default, this exploit works on Vista systems when IE6 and IE7 do not have the “Data Execution Prevention” feature enabled. But techniques to disable the DEP check even when it is enabled have been published as well.

This image shows the thread stack as it is overflowed. An exception has been caused at this point, and we break on it to notice that the stack is covered with “\x0a\x0a\x0a\x0a”.

When this exception occurs, we can take a peek at the exception handler, which also is stored on the stack. It has been overwritten with “\x0a\x0a\x0a\x0a” as well. Because the exception has been thrown, our goat system tries to provide control to the first handler in the list, which happens to be at the craftily overwritten “0a0a0a0a”.

Interestingly, the heap has been sprayed with shellcode because the javascript sets up multiple variables full of shellcode. Due to this spray, the location “0a0a0a0a” now points to “0c0c0c0c”, which also is located on the heap. This heap contains two things – a nop sled of “0c0c0c0c” and “download and execute” shellcode.

Control will slide down the sled to our shellcode, and the attackers will effectively download and execute a set of binaries stored on another web server. These binaries download and execute even more malware, including bots, rootkits, password stealers, adware and other problematic software.

And whoa, they keep coming as this post is written! Another Yahoo webcam viewer vulnerability has been discovered and its exploit posted by a Chinese security group without having notified Yahoo, so we’ll keep an eye on this 0day as well and probably post on attacking activity abusing this new vulnerability. We’ve looked through the code, and it attacks a heap overflow instead of a stack overflow like this one, but methods to effectively defend against it remain the same.

Beware web sites and links that you have not visited before, especially if they are sent to you via email, and update your security software. Buffer overflow exploits like this one can turn an unwitting user into a victim.