Tracking Coreflood from Shellcode

Sometimes, it can be surprisingly difficult to get malicious code removed from servers. It can be due to a lack of server support by the owners and their support staff, a lack of responsiveness from the ISP, or an intended scheme to profit from malware distribution, as with the groups involved at the RBN this past year.
It's just as surprising when users' systems are getting attacked with malcode that's been in circulation for at least five years and right now, it's almost completely undetected by the major av vendors. Here are some scanning results on the executable. Four of thirty two scanners is not pretty:



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.

Wachovia Link

If you have received an email with a confusedly long link for a supposed Wachovia site that looks like http://commercial.wachovia.online.financial.business....cashman766.com/Service.htm, delete it. It seems that users in Great Britain are receiving these messages. That page will serve up file "wachovia_certificatev102.exe". When run, you do not install certificates new to Wachovia.

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.

Ongoing targeted attacks during Tibet, Burma controversy and Olympic torch protests

Unfortunately, targeted computer attacks commonly occur. This morning's NPR show exposed such problems in regards to activists and journalists in China. Sadly, not much data is public about these sorts of attacks and it would be easy to speculate that such types of attacks are on the rise. Sometimes, the groups being attacked do not want members to be exposed or further put into public light and sometimes they do not fully understand they are being attacked. The NPR audio mentioned groups like the Falun Gong, Students for a Free Tibet, Human Rights in China and some China-based foreign journalists. Often, the attackers' identities are more difficult to uncover than more entertaining examples we've given in the past. While spoofed sources may seem to be from friends or friendly members of organizations, the true source remains in the shadows, hiding university or seemingly public ip addresses.

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 visitor db compromised

While the Oak Ridge National Lab may be known for high tech research like analytical chemistry, neutron science, and providing technology and expertise to support national and homeland security needs, they also might become known for a recent breach of security at their own premises. Granted, the only data they are reporting as having been compromised is their visitors database. Seriously.

"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.

The Cars of the Future

Drum roll please...a great NYT article was published this morning about progress that has been made on car technology that learns to drive itself:
In the Future, Smart People Will Let Cars Take Control
Does that mean my parents won't be on the road at 80? Maybe this is a good thing, I remember how my grandmother drove at that age.

"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.

How do Storm, NotFound and other threats infiltrate so many PC's?

As the trend continues to move away from exploiting system services and more commonly toward exploiting client applications like web browsers and third party plugins, our research has turned towards these threats and overturned some fairly new stones for the commoditized exploit packages currently in the wild. The Storm threat, and numerous others have been using these packages to deliver driveby browser and, in this case, third party plugin exploits. These sorts of threats have been very effective recently at compromising users' systems in order to build botnets and send spam, and steal passwords and other sensitive information.

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.

They keep coming! 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 it. 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.