Monday, December 29, 2008

The vuln before Christmas

  • T'was the night before Christmas, and all through the net,
  • not a hacker was stirring, not even FX,
  • the servers all hummed in post-purchase daze,
  • to await the deluge of gift-card traffic craze,

  • The VRT was drinking, three sheets to the wind,
  • in order to escape both family and friend,
  • Matt, Shong, and Ryan had all left for sushi,
  • while somewhere some script kiddy was being real douchey,

  • When on Milw0rm was released remote pwn,
  • Patrick sprang to his laptop, picked up his cell phone,
  • we put down our egg nog, relinquished our tumblers,
  • busted out hex editors, checked all the numbers,

  • A file template built, Pat now had the vision,
  • To find oddness in song tempo, and time division,
  • and what in my windbg window should appear,
  • but a #DE error, no int overflow here!

  • Now checking in IDA, and tweaking edx,
  • no memory moved, no additional wrecks,
  • not a vuln at all here! Not nearly the same,
  • I can't believe we stopped drinking for something so lame!

  • The problem's control of four high order bytes,
  • when in simple division the quotient's not right,
  • the value produced must fit inside a DWORD,
  • if the value's too big the proc flips you the bird

  • So we've penned you this poem to put you at ease,
  • and save you the folly, the stress, (or the tease!),
  • so before we get plastered real good and right,
  • Merry Christmas to all and to all a good night!

(* In relation to the Windows Media Player "Integer Overflow" posted to milw0rm on Christmas eve.)

Wednesday, December 24, 2008

MS-SQL Quickie update

Hey folks,

Since MS chose today to speak on this issue (see

We wanted to remind you that we released coverage for this rule on the 9th of December. The following SIDs address this issue:

15127, 15128, 15129, 15130, 15131, 15132, 15133, 15134, 15135, 15136,15137, 15138, 15139, 15140, 15141, 15142, 15143, 15144

With that out of the way, our best wishes to you and yours (both your real family and your work family).

Sourcefire's VRT

Tuesday, December 23, 2008

Rule release for today - December 23 2008

Mostly a maintenance release this one, some new rules in web-activex, web-client, backdoor and specific-threats.

Check out the information here:

Thursday, December 18, 2008

Snort Rule Coverage for MS08-078

A critical vulnerability in Microsoft Internet Explorer outlined in Microsoft Security Bulletin MS08-078, is covered by a previously released rule.

The rule to detect attacks targeting this vulnerability was included in the release on 2008-12-11 and is identified with GID 1, SID 15126. Future revisions of this rule will contain the appropriate reference information.

Details on the rules from the release on 2008-12-11 are here

Ur Welcom.

Rootkit takes advantage of MS08-078 vulnerability

On December 17 2008, Microsoft released security update MS08-078 to patch a vulnerability found in several versions of Microsoft Internet Explorer. The root cause for this vulnerability was found to be the incorrect handling of certain XML tags in Internet Explorer that references already freed memory in mshtml.dll. Attacks using this vector trigger prior coverage on our CVE-2008-4844 Snort rules.

An example of a payload downloaded through this vulnerability is a file called explore.exe. This executable is surreptitiously pushed to a victim's computer via an exploit at one time found at (most exploits are taken down within hours). The file is packed with UPX to make it more difficult to analyze. Dynamic analysis techniques in a controlled environment provide the information below:

Upon execution, explore.exe creates many services:


It is worth noting that services NsPsDk0{1..4} point to %system%\NsPsDk0{1..4}.sys which are rootkits. These rootkits create %system%\appmgmts.dll, a Trojan capable of disabling many security software.

Appmgmts.dll modifies the host file. The host file is a file usually found in %System%\drivers\etc and is used as a supplement to DNS to help map host names to IP addresses. The large number of .cn domains and computer security related websites being redirected to leads to believe that this sample is trying to prevent users (mainly Chinese speaking users) from accessing websites that could provide some help in the remediation the infection.

Hijacked host file
Pic.1: Hijacked host file

With appmgmts.dll, the person behind this executable takes advantage of a rarely used registry key to make sure that malicious code is run when other files are invoked. The registry key in question is HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options. The original purpose of this registry key is to allow a user to specify a debugger that will be launched when a program is run. For example, in order to call WinDBG and have WinDBG load Windows Media Player every time Windows Media Player is executed, the following key can be added to the registry:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Image File Execution Options\wmplayer.exe\\Debugger\\\”C:\Program Files\Debugging Tools for Windows (x86)\windbg.exe”.

The “debugger” specified in all of the numerous “Image File Execution Options” registry keys is “svchost.exe”. Having the workstation run svchost.exe instead of the wanted executable will effectively prevent the desired program from running, since svchost.exe will not in turn call the desired program. Here's a subset of the the programs that are disabled through the use of this registry key:

Some programs disabled by malware
Pic.2: Some programs disabled by malware

Some notable programs are:


Explore.exe loads the module appwinproc.dll in the address space of other processes and has for goal to make sure that McAfee and NOD32 antivirus software are disabled:

Appwinproc.dll hooks into other processes
Pic.3: Appwinproc.dll hooks into other processes

An online game password stealer is also set to run at system startup, as shown by the following registry key that was created:


System.exe is located in %System%. Two browser helper objects (BHO) are installed as well:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{72C7B634-DEB3-48BD-90C1-6BBBFE171C75}]

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Explorer\Browser Helper Objects\{AAB6C1A0-F3A4-4DAC-A922-F82E601E73A8}

By referring to the keys below, we can see that these two BHOs are malware:
HKLM\SOFTWARE\Classes\CLSID\{AAB6C1A0-F3A4-4DAC-A922-F82E601E73A8}\InprocServer32 @="C:\\Documents and Settings\\All Users\\Application Data\\Microsoft\\OFFICE\\USERDATA\\webbrowser_2234.dll"

@="C:\\Program Files\\Internet Explorer\\JetnNt64.987"

Webbrowser_2234.dll is a Trojan designed to artificially click on advertisement on certain websites in order to generate traffic and revenue for those sites. JetnNt64.987 is yet another online game password stealer.

The online music discovery service Yiqilai is also installed on the infected system.

Yiqilai Music Assistant
Pic.4: Yiqilai Music Assistant

The “Yiqilai Music Assistant” is a Windows Media Player plugin that is used for matching song lyrics. Yiqilai is being forced onto the machine of the infected user through dubious tactics. This is evidenced by the following registry entries found on the target system:

HKCU\Software\Microsoft\Internet Explorer\SearchScopes\{7DBC6ADB-5788-4FB9-AEC3-B40A58AC11DF}


"foobar"="C:\\Program Files\\foobar2000\\components\\foo_ui_yqllyrics.dll"

"instdir"="C:\\Program Files\\Yiqilai"

"kmplayer"="C:\\Program Files\\The KMPlayer\\PlugIns"

"realplayer"="C:\\Program Files\\Common Files\\Real\\visualizations\\RealYQLyrics.rpv"

"winamp"="C:\\Program Files\\winamp\\Plugins"

The original malware explore.exe was installed via a vulnerability in Microsoft Internet Explorer 7, exploited via an exploit found at The exploit was removed fairly rapidly (most of these exploits have a TTL of less than 3 hours). Over the course of this analysis more than 40 files were downloaded and executed on the infected host. Most of the files were pulled from the following URLs:

As usual, extreme caution is needed if visiting these sites.

ClamAV has released updated DAT files to detect the Trojans mentioned above:

System.exe Trojan.Starter-12

The VRT is monitoring this evolving situation and is updating ClamAV signatures as new payloads are discovered in the wild.

Tuesday, December 16, 2008

SPAN, The Heap, and esoteric memory buggery…

Have you ever heard someone say they needed a pointer that pointed to itself and was also a nop? Maybe one they could write to? No? Where are you hanging out?

For the rest of you, I'll explain why this set of properties can be useful, and when you might want to make use of it. Now is a great time. The IE 0-day that's prancing around is a heap corruption bug which HD Moore explains here. The vulnerability allows you to overwrite an object pointer with four arbitrary bytes. In this case we don't get the true write-what-where you often end up with when you toast a chunk header, but that's okay – what you do get is just as useful. The object we control the pointer to contains within it a function pointer which is eventually called. Great. Ostensibly what we need to do is make a fake data structure in memory with a pointer to our shellcode in the place of the function pointer, then point the controlled pointer at this fake data structure.

Sadly, this is easier said than done when it comes to guessing where a 200 byte data structure might be in the heap of a crazy multi-threaded program like IE. It'd be easier if we could have kind of a NOP-sled to get to the data structure, and just aim for a general area. Obviously, this is impossible; we can't "slide" into our data structure because we're not executing, we have to hit it right on. Don't we?

Let's evaluate our goals. We'd like to be able to create:

  1. an arbitrary data structure that is simple to guess the address of reliably, and
  2. some chunk of shellcode we can also guess the address of and point the function pointer in #1 to

Another thing we could do is create our data structure in such a way that it needn't be aligned to work in the manner we'd like it to. If we could manage this, we'd only need to know approximately where it lives in memory. For this to be the case though, alignment can't matter – just like in a NOP-sled. One of the simpler ways this is accomplished is to find a single byte NOP (such as 0x90) and repeat it over and over. For this to be a valid solution to our problem, we'd have to be able to ensure that the address at which we stored our structure could also be used to store our shellcode, and additionally that returning into the pile of bytes which comprise the structure would not cause a fault. The later is necessary because the function pointer will point to nearly the same address as object itself. Thus, we will need a self referential pointer, which is also a NOP, is writable and executable, and is in a place we can write to arbitrarily. Quite a set of requirements!

Luckily, due to the grand work of others in the field this set of requirements is simple to check off in a web browser. Using javascript, we can force the allocation of an arbitrary amount of memory, filled with whatever we like simply by creating strings. This method, known as heap-spray will allow us to create a large area of memory filled with our fakey structure, as well as a place to store our shellcode.

Now, we can begin to look at what addresses are filled with our heap-spray to determine likely values to overwrite the object pointer. The values we're interested in will have the same value for all four bytes, ie. 0x01010101, 0x02020202 etc. such that we are not required to adhere to an alignment. They will also be NOPs in our particular case. Two common values used in IE heap exploitation are 0x0a0a0a0a and 0x0c0c0c0c which are easily allocated, and disassemble to or cl, [edx] and or al, 0xC respectively. (Note that for the 0x0a0a0a0a address to be viable, the edx register must contain a readable address at the time you take control.)

The live exploit makes use of the 0x0a0a0a0a address, filling it with 0x0a. At the end of a large chunk of these bytes, the shellcode is placed. The object pointer (ObjPtr) is overwritten with 0x0a0a0a0a. When its function pointer (FuncPtr) is called in the code, it too points to 0x0a0a0a0a. Since this byte was confirmed to be a NOP, execution continues merrily along until it runs head long into our shellcode.


    |0a0a0a0a|0a0a0a0a|0a0a0a0a|0a0a0a0a|0x0a0a0a0a … SHELLCODE

    ^ObjPtr         ^FuncPtr    

Right now I'm being berated for not having a conclusion here, because apparently hitting shellcode isn't the conclusion for everyone that it is for me. Therefore, (.)(.)


Rule release for today

Today's VRT Certified Rule release has coverage for a vulnerability in Oracle Internet Directory and CUPS. There are also a few new rules added in chat.rules and others.

Oracle Internet Directory Denial of Service (CVE-2008-2595):
Oracle Internet Directory contains a programming error that may allow a remote attacker to cause a Denial of Service (DoS) against the application. This issue does not require authentication.

CUPS Integer Overflow (CVE-2008-5286):
A vulnerability in the _cupsImageReadPNG function in CUPS may allow a remote attacker to execute code on a vulnerable system.

Here's the link to today's release:

Thursday, December 11, 2008

Out of band Microsoft Security Advisory for Internet Explorer CVE-2008-4844 and SQL Server vulnerability CVE-2008-5416

Today, Microsoft released a security advisory for Internet Explorer. Microsoft SQL server also has a problem with a stored procedure. In response, we released some new rules to detect attacks against these two products. Details on the rules are here

MS08-067 In The Wild

While sifting through my e-mail this morning, I saw a note from one of Sourcefire's European employees, asking if the VRT could take a look at some PCAPs pulled from a customer sensor - they'd triggered the rules for MS08-067, and our guy didn't think that they were false positives. Always eager to get real-world feedback on how our rules were functioning, I agreed; a cursory look at them convinced me that they were in need of more in-depth analysis by someone who knew the vulnerability better than I did, so I sent them over to Lurene Grenier and Matt Olney, who were the primary analysts on that vulnerability (and who, along with Alain Zidouemba, produced the VRT whitepaper on the subject

After verifying that the PCAPs did in fact have all of the triggering conditions for the vulnerability, Lurene dumped out the RPC stub data for examination - since, if this was an exploit, that's where the payload would live. Examining the raw hex of the payload, she noticed what appeared to be a simple decoder routine, so she took the data and put it into IDA Pro to confirm her theory. For those wishing to follow along at home, the process is simple:

  • Select a new file for disassembly using "File -> New"

  • Choose "Unknown File" from the "Various Files" tab, and then select the dump file

  • Stick with IDA's default options, and choose 32-bit disassembly mode

  • Move your cursor to the start of the area you want to examine, and then press "C" to begin disassembly

With this done, Lurene's theory was immediately confirmed, as the first three lines of the disassembly were an XOR loop:

0040A005 xor byte ptr [ebx+0Eh], 85h
0040A009 inc ebx
0040A00A loop test+0xA005 (0040A005)

This simple XOR decoding routine is useful for defeating many automated malware-detection techniques, and at a cost of only seven bytes at the start of the shellcode, is a very practical technique that is commonly seen in live exploits in the wild.

Before running that loop to determine what the decoded payload contained, one additional bit of setup was necessary: the EBX register had to be populated with the data that was going to be XOR'd, since we didn't have the Windows Server Service populating it with the appropriate data for us. This was a fairly simple step - the offset was just the address immediately after the LOOP statement, minus the 0x0E that the XOR instruction used. With that calculated, a simple

mov ebx,offset test+0x9FFE (00409FFE)

populated the register nicely. For those who might be wondering about ECX - since the LOOP instruction uses it to determine when to halt operation and continue on to the next instruction - it wasn't necessary to set it explicitly, since our test environment happened populated it with a value large enough to decode the shellcode, and we really weren't interested in having those instructions executed on Lurene's system anyway.

Getting this to actually execute and do the decoding for us requires the following relatively simple C program:

char shellcode[] =

void main() {
int *ret;

_asm {
int 3

ret = &ret+2;
*ret = (int *) shellcode;

The shellcode portion above should be obvious, but the rest of the program is worth an overview. The simplest piece is the _asm statement, which tells the compiler that the data inside of the brackets is explicit Assembly code, to be inserted directly into the program at that point of execution. Here, the instruction int 3 is a breakpoint, which is handy for running this program in your debugger of choice.

The rest of the program becomes obvious once you think about the nature of the program's stack. At the time the breakpoint is hit, the stack looks like this (addresses approximate):

| Return pointer to caller (libc) | 0x00800010
| Saved EBP from caller | 0x0080000C
| local variable (*ret) | 0x00800008
| ... | 0x00800004

Thus, the line

ret = &ret+2;

initially sets the value of ret to 0x00800008 - i.e. the location of the variable ret on the stack - and then adds 2 to that value. Since ret is declared as a pointer to an int, and we're on a 32-bit platform, the compiler actually takes sizeof(int), otherwise known as 4, and multiplies that by 2 before doing the addition. This results in the value of ret being 0x00800010 - the location of the return pointer to libc. That allows the next line of the program:

*ret = (int *) shellcode;

to replace the return pointer with the address of the start of the shellcode (for anyone who's curious, as a global variable, char shellcode[] lives above the stack drawn above). By doing this, when the program returns out of main, the operating system will begin executing the instructions at the start of the shellcode block, and thus head directly into the decoder routine Lurene identified.

As you can see from the screenshots below, the decoder routine took what appeared to be a group of relatively random, harmless instructions:

and transformed them into a series of relative and register-based calls, one of the hallmarks of shellcode (such calls allow an attacker to call into code they control, instead of relying on fixed addresses within the operating system):

With this new knowledge in hand, I replied to my colleague who had sent over the PCAPs, and confirmed that these were indeed true positives, and malicious ones at that. My e-mail was apologetic, since I was the bearer of bad news - after all, who wants to tell someone they've been owned?

Much to my surprise, the e-mail I got in reply was extremely pleased. As it turns out, the customer - a large French manufacturing company - had seen an outbreak of this malicious traffic on their worldwide network that morning. However, the traffic was unable to penetrate inside of their core network in France, since they'd enabled the Sourcefire rules for MS08-067 in drop mode, and their IPS was busy blocking each and every attack attempt on segment of their network - like a modern-day Maginot Line that actually worked.

The whole thing was quite gratifying, since we always like to hear that our rules work in the wild as well as they do here in the VRT lab. That in mind, we're always eager to hear how people are actually using the VRT rules in production situations - it helps us prioritize our response to the threat landscape - so if you've got a story you're willing to share about how you're using our stuff, drop us a line at Depending on the quality and number of stories we get, Snort swag may be distributed to those who send us the best stuff.

Tuesday, December 9, 2008

OfficeCat Update

New advisories from Microsoft concerning Word. We've updated OfficeCat to provide coverage, more information on OfficeCat here:

Microsoft Tuesday Coverage for December

Today was a busy day, lots of new rules and coverage for the following MS advisories:


We have released rules for attack coverage and you can find details at vrt-rules-2008-12-09.html

Saturday, December 6, 2008

Twitter Feed Available

We now have a twitter account where we are going to be micro-blogging our rule updates and blog posts. The feed can be found here: