Reversing a suspicious dll continued

In a post earlier this month, I presented steps for unpacking and restoring the IT/IAT of a suspicious BHO for analysis purposes. In that case, it was packed with a tool called "Upack", otherwise known as the "Ultimate PE Packer" by its author Dwing. Upack often is used on executable files around 40kb in size. It compresses the file's contents with the LZMA algorithm and adds an unpacking stub to the target file for self-decompressing at runtime.
In other words, to make a file smaller for download and delivery without requiring a decompression utility like WinZip or WinRar to already be installed on another system at runtime, an author can compress their executable creation with this tool.
This posting will work with the PE file that was recreated from that previous work.

Here are some of the steps we used to work on this file, leaving off at the last step to identify some behaviors of this malicious file:
Change PE file to .exe in PE header, rename dll to exe extension
Load into Ollydbg
Find OEP (original entry point) -- pretty easy with Upack
Break at oep and dump file from memory to disk
Fixup IAT with ImpRec and write to dumped file
Rename fixed file and modify PE header back to dll
Load into IDA Pro 5.1 with the IDA Python plugin installed...

When we load this file into IDA Pro, the disassembler now can provide a listing that can be used to reverse engineer the component's functionality. Without properly unpacking the file and fixing up the imports, the disassembler cannot analyze the code.
However, the listing doesn't seem to immediately reveal much about the component's activity. But knowing that this component is a BHO helps identify key areas for reversing progress. We do see fundamental Win32 API calls like "AtlInternalQueryInterface" and "AtlComPtrAssign", leaving clues about COM programming within the component. The location of these calls can lead us further down the control flow to locations where COM calls can be further analyzed and easily understood. Joe Stewart published information about reversing OLE, but this code is more complex than a common SubmitHook trojan.
Frank Boldewin's Python scripts come in handy for walking through these COM calls -- the listing now reveals a section where the code obtains the "document" interface within the web browser and enumerates its connection points. We can set memory breakpoints on these sections for further analysis, and when we visit various banking web sites, we can see that the BHO is building an event sink:

















Once the event sink is set, GetKeyState is then called on "KEY_DOWN" events. The component can check on each individual keystroke as they are hit. And it appears that the only keystrokes being checked are the ones emanating from the userid and pass input fields.

So, we've got a dll that identifies Urls of banks and other financial institutions and, after parsing and identifying an "interesting" Url, then constructs an event sink attached to very specific fields within the browser's web page -- namely, userid and password input fields. This ActiveX component will log these keystrokes and send them off the system. The component calls "HttpSendRequestA" to send off the banking usernames and passwords it just collected from these fields. I think that we've found an interesting piece of malware, quite possibly a password stealer for banking websites. We'll add more technical detail to this post as time permits.
It helps to be able to dump this file and modify it for static analysis.

Strategy and book review

A "Strategy" thread was started on the DailyDave mail list by Dave himself, criticizing information warfare papers:
"If you're reading an information warfare book or paper you'll invariably see a lot of:
1. Inane references to Sun Tzu (or, in some even more horrible cases, any two of Sun Tzu, Clausewitz, and John Boyd)
2. Declarations that information warfare is an "asymmetric attack"

Dave goes on to drop a couple product names and then describe the money saving mono-culture Microsoft technology implementations within the US .com and .mil communities, and describes it as poor strategy:
"Bad strategies like this result in flailing and moaning as you get defeated over and over by someone with better strategy, not because the battlefield is inherently asymmetric."

Unfortunately, this past year was a record year for data breaches, according to a couple of groups. (Although, I'm not sure that statement is completely true. It seems more to have been a record year for reporting breaches, due to a number of new factors. Incident reporting has always provided only a cloudy window into actual events.)
Any way you slice it, in light of the sheer volume of security breaches, Dave's statement about the mono-culture of .com and .mil communities is a troubling one -- in spite of a year of record profits for the .com community and record budgets for the .mil community, it seems that technology implementations still are not getting the budget or focus that they require when it comes to effectively addressing security needs.


Another poster on the list responded to Dave's complaints by posting a book review about "Spec Ops: Case Studies in Special Operations Warfare: Theory and Practice" by William McRaven, a U.S. Navy SEAL commanding officer. I got a chance to check it out this past week and the eight case studies McRaven analyzes really are fascinating (if you're a bit of a military history buff). The theory and principles at the beginning of the book (summarized on the DailyDave post) can be applied to analysis of the targeted attacks that have become much more commonplace on the net. It's a stimulating read for security enthusiasts, and applies well to the ongoing security breaches around the world:
"If you can't draw the parallels to general security practices from those principles then the book is not for you, otherwise you might find yourself ripping through the book and thinking in an entirely different light by the final chapter."

Bring in the New Year with a new Storm variant

What a generous way to bring in the new year. The Storm/Peacomm gang, the same group whose activities we presented at VB2007 and posted about previously, has not disappeared. The holidays brought a round of Christmas-themed spam, complete with a simple link to a njinx servers and the promise of a friendly xmas related message. In the past couple of days, they have turned towards a new year theme:
"Happy New Year!
Your download should begin shortly. If your download does not start in approximately 15 seconds, you can click here to launch the download and then press Run. Enjoy!"

Consistent with their past attacks, the executable name is themed as well. We have seen "happynewyear2008.exe", "happy_2008.exe" located on servers in Poland and multiple sites around the world. But in a small departure from using just unregistered ip addresses, these malware serving web hosts are now registered with cute, related DNS .com domains, like "newyearwithluv" or "hellosanta". The gang broke another trend and flashy graphics on the sites are not present either.

We are seeing a strong uptick in the number of users actually running these files (happy-2008.exe, happynewyear2008.exe, happy_2008.exe, happy_2008.exe, happynewyear.exe) on their systems. Please exercise caution when visiting links that were sent to you, update all of your system patches at the Microsoft Update site, and if using Quicktime or Firefox, update them as well.

Cheers to secure computing and happy New Year!

Corny arrest headlines

With one of the corniest titles you'll see (Pinch authors Pinched), the Kaspersky blog in Russia stated that the original authors of the Pinch trojan have been arrested:
"Today Nikolay Patrushev, head of the Federal Security Services, announced the results of the measures taken to combat cyber crime in 2007.
Among other information, it was announced that it had been established who was the author of the notorious Pinch Trojan - two Russian virus writers called Ermishkin and Farkhutdinov. The investigation will soon be completed and taken to court."

Maybe this focus by the Federal Security Services helps explain some of the motivations for the Russian Business Network's moves to China and Central America.

The arrest themselves are a pretty big deal, along the lines of the more recent Zotob author's and distributor's arrests. According to the KAV log:
"The arrest of the Pinch authors is on a level with the arrests of other well known virus writers such as the author of NetSky and Sasser, and the authors of the Chernobyl and Melissa viruses."

Interestingly, it seems that the author of the Pinch code and the distributors that use it to infect millions of computers are different people. Here is another take on the announcement:
"FSB Chief, Patrushev, reported that FSB has arrested Ermishkin and Farkhutdinov, who created and deployed the Pinch trojan into tens of millions of PCs around the world."
The assembly source that I've seen from version 1.0 contains a different name, "Alex". The two recently arrested most likely used the code to create and infect systems, and most likely were not the original author. We'll look for corrections in reports.

Cisco Annual Security Report

Joining the bandwagon of future tellers, Cisco recently read the collective palm of malcode writers and cybercriminals everywhere and released what they saw in their annual security report.

Seriously though, the report takes perspective on some pretty massive themes and is a worthwhile read for security managers and other interested users. It provides "an overview of the combined security intelligence of the entire Cisco organization", which is an interesting statement in itself, knowing that the company has over 60,000 full time employees and lots of contracted and outsourced staff.
I like its structure and layout, but you'll still find a lot of questionable statements in its details, so end users might be pretty well confused by some of the key statements.
Malware activity gets stuffed under the Vulnerability section. Their crystal ball tells us What to Expect in 2008, partly based on what they have not seen in the past (disregarding the golden rule that absence of evidence is not evidence of absence in the security arena):
"More malware may execute in system memory, not on hard drives."
Huh? I can't remember the last time a piece of malware, or any code for that matter, executed on the hard drive, instead of in the CPU and memory. And what about caching or paging?

Ok, we can get past that statement. The point seems to be that "more" malcode may run on systems without ever touching users' hard drives: "Malware attacking rootkits that executed entirely in system memory emerged in 2007. As average RAM size continues to increase in the coming year, these strategies will likely grow in popularity".
Imho, not exactly. These strategies have been around for a long time in the underground and cybercriminal coding communities, but it hasn't been a money maker -- Aphex's downloader circa 1999 is an example. The key feature was that it downloaded any content to memory from a remote location (like a web server) and executed the content in memory without the content ever touching the disk. I am sure his was not the first, but he was one of the first from the shadier side of the underground to develop and publicly release a reliable loading technique like this one on his website. The downloader, and its scanner evasion techniques, just weren't needed at the time. Problems from using the technique had nothing to do with the size of physical memory on the victim system. But there were easier methods of detection evasion.
Kinda confusing.

Anyways, enough of my nitpicking, it is an interesting read with a fine list of key recommendations, predictions, and some exposure to their collected data from 2007. I'll get through more of the malware section and update this post with notes about what I really like in the report.

Shellcode analysis -- download n' exec

In a previous post, I mentioned that we could use c code to analyze some shellcode currently being posted in the wild by malicious web site operators.

These malicious websites are delivering malware by exploiting several Windows based vulnerabilities. The websites attack visitors by targeting vulnerabilities in .ani file parsing, .wmf file parsing, and rtsp content-type string parsing in the QuickTime plugin.

In our labs, we visit these web sites with vulnerable systems, allowing the pages to compromise the systems. We then analyze the techniques being used. Let's take a quick look at a major part of the attack -- the shellcode within the delivered malformed wmf file. We'll take a look at the low level data content of the malformed file itself:





















After seeing a lot of these malformed files, you can spot the shellcode right away. I did in the above image after a quick visual scan, but sometimes details of the file format need to be known to find the shellcode on the first try.
We copy out the string of shellcode hex data into a c-style string, like this one:
"\x83\xec\x10\xd9\xee\xd9\x74\x24\xf4\x58\x33\xc9\xb1\xdb..."

I copy it into the buffer in the c file from the previous post, and the assignment will look like this:
unsigned char shellcode[] = "\x83\xec\x10\xd9\xee\xd9\x74\x24\xf4\x58\x33\xc9\xb1..."

I compile it using gcc, but you can use the cl.exe Microsoft compiler if you would like -- whatever c compiler should be fine. I've never seen a problem with substituting one for another:
C:\sh\>gcc sh3ll.c -o sh3ll.exe

The compiler emits an expected warning that can be ignored, and now we have an executable to work with. We'll run it in Olly to its entry point, and then search for the beginning of the shellcode string in memory. When we find it, we'll set a memory access break point on that memory location and then let the process run to that point by hitting f9.
When the debugger arrives at this starting point for the shellcode, the debugger shows us a very strange listing -- "jno" instruction followed by a bunch of "cnq" instructions? The listing looks very strange:


















We hit f7 a few times and notice "xor byte ptr ds:[eax+12], 99", followed by a loopd instruction that takes us back to a few lines prior. This loop is an xor decoder loop, implemented in this shellcode because we are exploiting BoF, and usually that means we are attacking a string handling flaw. Any "00" or null bytes in the code will likely crash the code, as explained in chaps 3, 7, 9.
We also notice that ecx is set to "0xdbh" at 0040200e, meaning that this loop will decode the subsequent 219 bytes of data:










We can continue stepping through the code with f7, watching the decoding taking place, until ecx decrements to zero. When it finishes, we step through a bit more slowly.
Stepping into the instructions with f7 now reveals the code searching for kernel32's location in the process space using the common and reliable technique of parsing the PEB and its module initialization linked lists. It then searches for LoadLibraryA, ExitThread, and WinExec win32 api calls. It loads urlmon and finds URLDownloadToFileA. These calls all tell us that this shellcode's functionality is download and execute -- and we can observe the url strings that the code is communicating with.
Download and execute shellcode like this happens to be some of the most prevalent shellcode that we see served up by malicious web sites.

Hope that you learned a few things about the sorts of techniques we can use to analyze shellcode and its behaviors. Let me know what you think of it!

Merriam Webster w00t w00t

Ok, this one is a bit late, but I don't stop by the Merriam Webster dictionary every day:
W00t is the official word of the year

We have heard the w00ting that goes along with 0day and additional exploit releases from around the world -- it's been tossed around by the haxor crowd for years.
You can get a hold of metasploit exploit developers y0 and mc at w00t-shell. d4rkgr3y from SecurityLab and m00 security even named his PoC release code "m00-apache-w00t.c" back in 2003. Defcon monitors, alongside the wall of sheep, are filled with the stuff every year in Vegas. A Linksys hack cheers a VMware virtual machine escape technique (see if you can find the w00t!). An entire w00tbot family has been crawling around the internet. Wezzer they suxxored or not, Merriam Webster just might pwn all you n00bs next year.
Oh brother. I'm guessing we'll see a lot less of this lingo in the underground chat rooms and forums now.

Interestingly, #2 on the list was "facebook", another sexy term and hangout for all the l337 kidz.

Tool for shellcode analysis

Here's some favorite c that I use to reverse engineer shellcode that I collect from malicious files, malicious web sites and attacking network traffic:


unsigned char shellcode[] = "";

int main()
{
void (*c)();
printf("Shellcode it is!\n");
*(int*)&c = shellcode;
c();
}


Basically, the code creates a buffer that stores your collected shellcode, creates a pointer to a void function empty of instruction, points the function to the beginning of the buffer and transfers control to it, just like an attacker's exploit. Drop the hex into the array as a c-style string, compile it, and toss it into Olly for stepping and analysis!
We'll look at a current example from a site in the wild in an upcoming post.

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.

Online game password stealing worm

We are seeing a strong surge in the spread of a game password-stealing worm. A number of reports online have described the infection occurring when the user was copying files over a usb drive.

The files that we are seeing drop an executable in the windows\system32 directory by varying names: "avpo.exe" and "niedeiect.com" are common. This nasty little thing copies itself to various locations on your drive, drops driver files possessing unstable rootkit techniques to hide its own files, and steals the passwords of your favorite games. If you see "avpo" or "amvo0.exe" performing strange behaviors alongside "niedeiect.com" on your drive, like writing to the explorer.exe process, quarantine them.

Dave's inflight thoughts

Dave Aitel, founder of ImmunitySec, sometimes comments on Halvar Flake's and Sabre security (oops, I mean zynamics) projects. They speak at a lot of the same conferences.

He just happened to be flying back from jfk when a few deep thoughts came to mind about evading the holy grail of automatic malware classification that he posted on DailyDave:
"Given that avoiding "behavioral signatures" is a matter of calling random NOP-like API calls (i.e. CreateFile + CloseHandle == 1 NOP), Halvar's program classification techniques involve a structural differencing engine. This has advantages (see his talk for details) in that program structure closely reflects the semantic meaning of a program, as interpreted by a compiler.
So the obvious way, from what I can tell, to defeat a structural differencing algorithm would be to do a static or dynamic analysis of your target program, and for each CALL opcode, change the destination to a dispatcher function. This dispatcher function can then be built to do a O(1) table lookup to find the true destination of the call."

I like the way Dave thinks. Unfortunately, other folks do too, and all sorts of evasive techniques are commercially available. That means the techniques are available to the bot herders, and it appears in our labs that the herders are distributing most of their bots packed with this stuff now.

SecurityCompass ExploitMe and community pen-testing

SecurityCompass just released a couple of open source Firefox plugins, currently in beta, that examine web site pages for XSS and SQL injection vulnerabilities:
"Currently in their beta release stage, these open source (GPL v3) FireFox plug-ins search through web applications for vulnerable visible and hidden form fields to perform input validation attacks. "
A video of the vulnerabilities that they are targeting is posted there as well.

Botnet arrests and indictments around the world from Bot Roast II

Two teen botnet herders that went by the aliases Akill and Digerati were arrested by the fbi and New Zealand authorities.
"The FBI estimates that more than one million computers have been infected and puts the combined economic losses at more than $20 million."
The arrests are a part of the Fbi's ongoing 'Bot Roast II'.

The arrest and past behavior of the Penn State student Ryan Brett Goldstein that went by the handle "Digerati" also is being discussed on the underground forums where he shared advice and code since around 2000. Rumors surrounding his bot herding and bot update techniques, his activities of accidental university server DoS attacks, and intentional DDoS'ing groups of other underground coders continue to circulate.


Update: Bot Roast II resulted in another guilty plea. This time from Gregory King, indicted at the same time as "Digerati". His deal includes a two year prison term.

High level of activity continues to originate in China

The folks at spamhouse.org have done a commendable job over the years trying to make the internet a better place for everyone. They provide interesting weekly statistics and information on the world's worst Spam Kings and sources of spam in general. If you're a network admin, you've heard of these guys.

Over the past year, while malicious servers continue to be set up all over the world, more activity is taking place in China. The servers that were a part of the recent google poisoning that we looked at first were in located in China. Many of the redirected pages from other compromised servers link to exploit pages, downloaders and more malware served in China.

Not surprisingly, this week China is the number two source of spam, according to spamhaus (keep in mind that these numbers do change on their site):


























But of their weekly top 10 list of Spam Kings, the top 6 continue to be Russian or Ukranian. Only two are of Hong Kong or Chinese origin:



























Also along those lines, the whole Russian Business Network or RBN (a huge network well known for its malicious activity over the past few years), was tracked by iDefense as shutting down and moving from St. Petersburg to China and Central and Southern Amercian region like Panama and Belize.

And from what we are seeing at our user base and in our labs, it looks like this trend is one that will continue.


UPDATE (12.13.2007): The Sydney Morning Herald published a fine article (it appears to be from someone at The Guardian) this morning about the RBN network's activities.

More Security Built into the Browser

There may be some copyright issues with this spoof, but it's nice to see that they are putting security first:

Unpacking a suspicious dll -- top to bottom

Fyi, this writeup is geared to satisfy curiosities about technical stuff, to start responding to some of the interest expressed over at our forum. You have been warned...

We use Ollydbg for all sorts of things around here. It's an outstanding tool. In fact, Olly himself found some spare time and is releasing a new version soon. He's got the pre-alpha version 2 code available on his website.

His debugger is a very useful tool for reversing user-mode software. When we're looking to get to the bottom of a suspicious component, one way is to fire up olly and get started. Unfortunately, there are challenges to that approach. Sometimes, we need to understand what a dll or other component is doing as well, and sometimes those dlls and other components are packed.
There are other tools that we use, and this post will survey the steps for using them while unpacking a dll...you can find this sort of information all over the web, but the writing styles sometimes make understanding the content very difficult.
Some of the fine reverse engineering tools available are
Ollydbg
LordPE
Import Reconstructor
IDA Pro

In our labs, we have a suspicious dll to examine. Apparently, it was installed as a bho into Internet Explorer:





















When you load this dll into Olly, the tool reports that its listing of the binary's instructions are most likely inaccurate. IDA Pro can't disassemble the binary either.
So we can use a couple of tools to help identify if this executable has been tampered with. One popular tool is PEiD. PEiD detects "Upack" as the packer used here, and usually is pretty accurate. You can also take a peek with ProtectionID.
Upack is a very simple packer, used to compress executables, and can make file examination only somewhat difficult. There are no antidebugging tricks that it employs to be concerned with. Here is PEiD in action, identifying the file as packed with UPack by Dwing:























If we want to load it into olly and dump it for full unpacking, one way to start the unpacking process is to simply rename the file extension to "exe" and modify a flag in its PE header so that windows loads the file as an exe, not a dll. You can take a course from a reverser like Jason Geffner on deobfuscation and read all the PE documents, then perform the math, pop open Ultraedit or hexedit and manually edit the file's PE header. Or you can run LordPE on the file and simply deselect the "Dll" checkbox under its file characteristics:
























After you save your modification, load up the file into Olly and identify the program's original entry point, or OEP. This work can be time consuming when learning about a new packer. But Upack is a simple packer. It's much like UPX, the industry standard, but it uses the LZMA compression algorithm. A reverser might notice that the first instruction of the unpacker is "pushad", followed by a call instruction:

















The easiest thing to do would be to scan the rest of this section for a matching "popad" instruction followed by a jmp to the beginning of the lzma decompressed code. When we do that, we find a popad (a restore of all the register values that were pushed onto the stack at the beginning of the unpacker stub) followed immediately by a jmp to the .Upack section that was previously empty:























At this point, we can hit "F7" to step into this new code section, use Olly's "Analyse" function and voila, we see
push ebp
mov ebp, esp
and we are most likely at the dll's original entry point (OEP):






















Great! Now, using LordPE again we can dump the file to disk and fix up the Imports with ImpRec. Here's a view of LordPE options for attaching to a process and dumping an individual module to disk:











Now that we have the image dumped to disk, we can use Import Reconstructor to attach to the dll's process as it is suspended at its OEP, find the import address table in memory and then fixup the dumped image on disk:























We have to provide ImpRec with the OEP. Hopefully it then can find the Import Directory and IAT for us, and with UPack, it reliably completes the fixup for us. Clicking on "Fix dump" and selecting the image dumped by LordPE will provide us with an unpacked file that we can next throw into IDA Pro for disassembly and analysis, which will be another post:























Hope that satisfies some of the curiosities of our forum readers, next we'll take a look at some of the malicious behaviors this dll performs.


Note- This example worked through one of the simplest packers out there, Upack. For more information on unpacking tricks, you can find a couple of awesome lists of tips and tricks related to anti-debugging/anti-reversing and at openrce and Mark Vincent Yason's Blackhat paper.

Surge in IM worm activity -- don't look at that cute puppy

We're seeing a surge in IM-worm activity today. We've been seeing a higher level of activity for this type of attack for the past couple of weeks now.

If you receive a file over Yahoo! or MSN Live Messenger service that looks like image021.zip, DO NOT download it. It drops what appears to be a keystroke/vpad scraping bot that phones home to an ip address in Turkey. It also downloads more components from servers in Shanghai and New Zealand.

Here is a screenshot of the MSN Live Messenger client handling the incoming message. The incoming message arrives from one of your contacts as image021.zip, or something close to that name. It arrives alongside a cute message listed below. In our lab, the zip file arrived underneath
"hey look @ my cute new puppy :-D"
























These lines of text are being changed by the authors/distributors. They maintain a "chat.txt" file that is downloaded by the bot from a server in Austria containing all the comments that the worm may chat. Here are the current cute comments the message might arrive as:
hey look @ this picture of me, when I was a kid
I just took this picture with my webcam, like it?
hey look @ my cute new puppy :-D
hey man, did you take this picture?
holly cow this picture is nasty check it
check it, i shaved my head
have u seen my new hair?
what the ____, did you see this?
hey I'm sending you a profile pic tell me if its nice k?
haha lets hope your parents dont see this picture of you :D
hey did i ever show you this picture of me?
is it ok if I add this picture of us to my new slideshow?
can i upload some of these pics of you to my myspace profile?
you care if i put this pictuer of you in my new album?
I cant believe they wanted me to upload this picture to facebook lol.
Lmfao hey im sending my new pictures! Check em out!
is it alright if I upload this picture of us to myspace?
is it alright if I upload this picture of us to facebook?
do you see anything strange in this picture about me?
Wanna see my pics before i send em to facebook?
you mind if I upload this pic of us to my online album?
do you think this picture is too kinky for Myspace?
This picture isnt you... right?
Wow i think i found your pic on myspace!
do I look dumb in this picture? I want to put it on myspace.
sry about the messup i fixed the pic! Try it one more time pz
is this pic tooo sexy for photobucket??
my crazy sister wants u to see these pics for some reason... take a look
ohhhh myyy look at this pic haha!
wow! look at this old picture i found....
wanna see this pic of my Boobs?
haha, this guy up my street just slammed his $90k car into a telephone pole! I got a pic of it with my cellphone
dude i just got these pictures off my digital for you! Gimme a moment to find em and send
I think this picture is terrible. but my friends on myspace want to see it. please dont show noone.
Hey just finished new myspace album! :) theres a few kinky ones in there!
hey you got a myspace album? anyways heres my new myspace album :) accept k?
Dude i found your picture on hotornot.com! Take a look!


Note- you can observe the struggle that this poor soul went through after downloading, unzipping and running the "album1of42.zip" file they received over MSN Messenger. They unfortunately are seeking out volunteer advice for the time consuming steps of cleaning up a system infected with this worm.

Update: This same sort of IM-worm activity will surge in different parts of the world six months from now.

Cisco CSA BoF advisory fits the pattern away from the OS and deeper into the kernel

In yesterday's post, we noted that the Sans 2007 Top 20 list contains some obvious trends away from OS components targeted by network worms and more towards third party components.

Today's Cisco Security Agent Advisory is a casualty in that direction. CSA is Cisco's host-based security product (it would be installed on your system like any other piece of software) that makes for a juicy remote exploit target because it's remotely accessible. This vulnerability, unfortunately, also leads further down the path of complexity and into the kernel:
"A buffer overflow vulnerability exists in a system driver used by the Cisco Security Agent for Microsoft Windows. This buffer overflow can be exploited remotely and causes corruption of kernel memory, which leads to a Windows stop error (blue screen) or to arbitrary code execution."

Spy v. cyberspy

An unusually open statement about China's cyberattacks on British businesses from MI5:
"The Government has openly accused China of carrying out state-sponsored espionage against vital parts of Britain’s economy, including the computer systems of big banks and financial services firms."

It interestingly came out a week after the 11/21/2007 report in the American congress from the US-China Economic and Security Review Commission blasted the PRC's espionage activities: "Chinese espionage in the United States, which now comprises the single greatest threat to U.S. technology, is straining the U.S. counterintelligence establishment."
The report also discusses the PRC's DDoS capabilites and cyberwarfare capabilities. The word "cyber" appears over thirty times in that report, in relation to "attacks", "weapons" and "warfare".

Interesting statistics about cyber attacks on U.S. networks

While the usual yearly predictions are coming out from large av scanner vendors, here's an interesting article containing an ex-CIA official's statements on how many attacks occurred against the federal government in 2007 alone. The numbers are staggering, when considering it's only one year of successful criminal activity:

"America is under widespread attack in cyberspace," Palowitch said in citing Cartwright's statistics that there were 37,000 reported breaches of government and private systems in fiscal 2007. There were nearly 13,000 direct assaults on federal agencies then, and 80,000 attempted computer network attacks on Defense Department systems, he added.

Current quicktime and client side exploits

A long list of porn sites currently are attacking recent quicktime and some other older browser side vulnerabilties. Unfortunately, it looks like some of our users are getting hit with this stuff in the wild -- these exploits and malware are prevalent.

It looks as though the purpose is to download, install, and run a service that acts as a trojan clicker. Clickers like this one continue to fetch web pages from related porn sites and their banner ad links in the background, without the user noticing (although your network card and cpu might appear to be pretty busy!). This activity turns into revenue for the individuals hosting the sites that the clickers are fetching pages from. Here is what an infected system with the installed service looks like:


























We'll update the post with more info soon...patch your system and QuickTime, or just lay off the porn sites. Geesh.


UPDATE: The Quicktime rtsp streams appear to be down for the moment. But the CVE-2005-4560 wmf files targeting the Microsoft Gdi vulnerability of long ago continue to be delivered, as are the .ani files targeting Microsoft vulnerabilites as well.

UPDATE2: Threatfire continues to stop the component delivery. If your system isn't patched for the .ani and .wmf exploits that the sites deliver, TF stops the BoF exploit. If the exploit delivered components somehow end up on your system, TF detects the components as a Trojan clicker. These Trojan.Clicker.Syspose components are delivered from a couple web sites hosted in the Ukraine.

Sans Top 20 for 2007

The Sans Institute, a source of information security training, certification and research, released their Top 20 list -- security risks for 2007. They release this Top 20 annually, it's a popular read for security professionals and enthusiasts.

Not surprisingly, they noticed that operating system targets are not attacked by massively propagating worms anymore. They note that "Operating systems have fewer vulnerabilities that can lead to massive Internet worms...There have not been any new large-scale worms targeting Windows services since 2005."
I think that the vulnerabilities are still present in XP. They just are not researched or attacked as much anymore.
One might also notice that the decrease in the presence of network worms coincided with a major sea of change in the OS marketplace: the introduction and rampup of Windows systems running a host-based firewall. In late 2004, XP SP2 users were treated to a host based firewall that finally was delivered and enabled by default. Users also started looking for better host based firewalls once they understood what host based fw really were. Accordingly, the Sassers and Zotobs of the internet had no easy in. By the end of 2005, it just wasn't all that fruitful to try to remotely attack Windows services that were now closed off from the internet cloud. The activity did not stop, however, it just took a turn.

Reading through the list or press release, you might also notice a corresponding rise in methods attackers use to evade the Windows host based firewalls: "We have seen significant growth in the number of client-side vulnerabilities, including vulnerabilities in browsers, in office software, in media players and in other desktop applications. These vulnerabilities are being discovered on multiple operating systems and are being massively exploited in the wild, often to drive recruitment for botnets."
This arena of research has received the most attention, because these attacks are now the easiest to deliver.

Overall, it's an interesting read. Enjoy!

Sunbelt IeDefender/zoey zane find still up and running

Monday morning, Adam Thomas of the Sunbelt crew posted about a sick0 scheme to use the information from a shocking news story about the death of a girl to lure in new rogueware IeDefender victims. While we haven't seen a large spike in the downloads of this stuff, we've been monitoring the site -- it remains up.

In our lab, we saw closely related but slightly different results. The videomp3_setup_.exe file, when manually run, pops a couple of different and changing windows:
























Following the rogueware install, the software will open an Internet Explorer window, conveniently googling the term "sex" for you, and injecting its own html into the results, spoofing the google results. The first chunk of injected HTML is a warning posing as though it is from google: "Google Error! Your computer is infected!..."
The second chunk immediately follows the fraudulent claim. It inserts a pornographic image next to a phony link that claims to be on the youtube site (clicking on it directs you to a completely different porn domain, not youtube). You can see the (censored) fraudulent results here:





















Unfortunately, scanner results seemed to be spotty to non-existent for this threat:

We've distributed samples to the appropriate people for inclusion in other security products' protection.

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.