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:

Friday, November 21, 2008

Fun with SSDT Hooks and DEP

My favorite part of work here at the VRT is how much you can learn from a project that, in the end, doesn’t achieve what you set out to do. This past week, I was looking at the possibility of watching, in the Windows kernel, for attempts to bypass DEP protection. Briefly, DEP is Microsoft’s term for a combination of hardware and software techniques to prevent code execution on memory pages that contain data. You can get a more through description here and here. In this case, I’m looking just at the hardware protection (NX) parts of DEP.

I started by looking at the bypass address used in Metasploit’s English XPsp2 attack over the MS08-067 attack in acgeneral.dll. The code looks like this:

.text:6F8916E2 push 4
.text:6F8916E4 lea eax, [ebp+arg_0]
.text:6F8916E7 push eax
.text:6F8916E8 push 22h
.text:6F8916EA push 0FFFFFFFFh
.text:6F8916EC mov [ebp+arg_0], 2
.text:6F8916F3 call ds:__imp__NtSetInformationProcess@16 ;NtSetInformationProcess(x,x,x,x)
The function is setting up the arguments to NTSeteInformationProcess, which are:
0x4 (Length of the arguments field)
*ptr args (Pointer to the arguments for the ProcessInformationClass, in this case “ExecuteFlags”)
0x22h (ProcessInformationClass, with 0x22 meaning “ProcessExecuteFlags”)
0xFFFFFFFF (Handle, with FFFFFFFF meaning “This Thread”)
Here is the code for the SetInformationProcess call:
.text:7C90E62D mov eax, 0E4h ; NtSetInformationProcess
.text:7C90E632 mov edx, 7FFE0300h
.text:7C90E637 call dword ptr [edx]
.text:7C90E639 retn 10h
7FFE0300 is a pointer to a data structure that contains the address of the KiFastSystemCall (syscall) function. 0E4 is the offset in the System Service Dispatch Table (SSDT) which contains the address for the system call handler for NtSetInformationProcess calls. The SSDT is in kernel land, which means you need to feed the call to Ring0. For completeness, here is the code that ntdll.dll uses to call SSDT entries:
.text:7C90EB8B mov edx, esp
.text:7C90EB8D sysenter
By definition, EDX holds a pointer to the arguments to syscalls, in this case ESP, but it doesn’t have to be, the address just needs to be in EDX when the sysenter call is made.

So at this point, I know that from userland, one major way to turn off DEP ends up with a call to the SSDT at offset 0xe4h, with the “ProcessExecuteFlags” opnum. Now I needed to find a description of these flags; which I found in, of all places, the source code for Chrome. Here is their enumeration for ExecuteFlags:
So my idea was this…if I can trap the SSDT call to NtSetInformationProcess, then I should be able to watch for calls to ProcessExecuteFlags, check the ExecuteFlags field and then call them out in an attached debugger (or a userland app that grabs DbgPrint calls). My end hope was that we could use this at some of our test points to try and catch exploits that used the syscall method (either through DLL or through custom stack creation and passing control to NtSetInformation process in ntdll, or if they are mighty clever directly calling the KiFastSystemCall function directly, you’d need control of EDX, or have it point to a place you can control) to bypass DEP.

So I wrote a hook into the SSDT that would call a function of my choosing when the NtSetInformationProcess call was made. For the moment, all the hook does is check to see if the call is a ProcessExecuteFlags call (0x22) and then if the flags field attempts to turn off DEP. If it matches these parameters, a DbgPrint call is made, and I check on the client side to see what process is called. Note: In kernel land it is possible, but not straightforward to get the process name, so it was just quicker this way.

The test box is a VMWare install of Windows XP at SP2. The processor I’m on doesn’t support NX, so for the moment, I just have to trust what I’m seeing and not monkey with the calls to prevent DEP from changing. While more testing is required, here is a list of things I’ve seen turn off the DEP bit:
  • VMWareService.exe
  • wscntfy.exe
  • msmsgs.exe
  • msimn.exe
  • VMwareTray.exe
  • VMwareUser.exe
  • UpdNotifier.exe
  • firefox.exe
  • Impact.exe
So…pending some more investigation (Vista, should be interesting trying to get the hooks in..., XPsp3, checking output on a NX capable processor…) it looks like what you would think is a bad idea (enabling code execution on data pages) happens a fair amount. I was initially suspicious that this might be because I was “Opt In”, so I changed the XP system to “Opt Out”, so that only programs I specify don’t have NX on. But that didn’t change the results. I’m going to update the system, and try to track down an NX capable box, and then see if that changes anything. Either way, I’ve got the framework for hooking SSDT and I’m sure I can come up with some interesting things to do with that :).

Hit us up with some comments, information, testing thoughts etc...

OpenSSH Plaintext Recovery Attack - nothing to panic about

So, somebody pointed this out to me the other day: which talks about the probability of recovering some plain text from an ssh session. Having seen nothing at all from OpenSSH about this, my first reaction was "OH NO!" because it looked like they had released information without patches or a fix being available, then I looked a little closer at what was actually being talked about here.

1. Vulnerability was verified against OpenSSH 4.7p1 on Debian

ok, good, I checked my versions of OpenSSH and none of them are that old. Maybe I have some breathing room here, could be a problem that is already taken care of.

2. The attack can possibly recover 32 bits of plaintext from an arbitrary block of ciphertext from an ssh session

ok, that's 32 bits of information, not bytes, bits so not a lot, that's 4 ascii characters.

3. The probability of success is 2^{-18}

ok, so that's 1/2^18 or 1/262144, not zero, but a pretty small number, I'm feeling better.

4. The configuration must be in the default state as the attack works against CBC mode ciphers

AHA, I see the word configuration and I run to a terminal and type man sshd_config. I then search for Ciphers and lo and behold, I see I can change the configuration easily to not use CBC mode. Nice. Time to edit sshd_config and ssh_config. Here's what I added to each file:
Ciphers aes128-ctr,aes192-ctr,aes256-ctr,arcfour128,arcfour256
Restart the daemon. Done. No need to panic. I then take a little time to look around for an OpenSSH advisory on it and I came across this looks like the awesome people at OpenSSH came to the same conclusion as I did, nothing to panic about.

Tuesday, November 18, 2008

New rule groups and new rules for SCADA

Today's VRT Certified Rule release sees the introduction of two new rule groupings, scada.rules and web-activex.rules.

SCADA Rules:
This group contains rules that pertain to the Supervisory Control and Data Acquisition (SCADA) protocol used for computer controlled system monitoring and process control.

Web-ActiveX Rules:
This group contains rule that were formerly in the web-client.rules group. It has been created to better manage the large number of ActiveX rules now in the VRT certified rule set.

These groups would of course need to be added to snort.conf as appropriate if you wanted to use them. Feedback is always welcome and we'd particularly like to hear about your experiences with the SCADA rule set.

Here's the link to today's release:

Wednesday, November 12, 2008

VRT Rule Release Feed

We have added a news feed for our rule release advisories, you can get it here:

It is very basic, but it will help keep track of new snort rule releases.

Tuesday, November 11, 2008

Microsoft Tuesday Coverage for November

Not a huge month for Microsoft problems this time around. There are two interesting sets vulnerabilities though, one in XML Core Services (MS08-069) and the other in SMB (MS08-068). We have released rules for attack coverage and you can find details at vrt-rules-2008-11-11.html

Also included is detection for attacks targeting a buffer overflow in Adobe Acrobat Reader (CVE-2008-2992).

Monday, November 10, 2008

Advanced Windows Buffer Overflow 5

Time for more pain.

I like this one. It'll be different than the last few, and might involve a bit of a brain stretch for those not familiar with exploit techniques that differ from the norm. It'll hurt. There's a bit of basic reversing, but that's not the problem.

Win2k please.


"This is very important" --Olney
"If I were your husband I would take it." -- Winston Churchill, hon VRT

All the AWBO exercises are available at

Thursday, October 30, 2008

White Paper on the MS08-067 vulnerability and the associated malware

Matt Olney, Alain Zidouemba and Lurene Grenier of the Sourcefire VRT have collated their analysis of the DCE/RPC vulnerability announced in Microsoft Security Bulletin MS08-067. A white paper that discusses this issue is now available on at the following address:

As always, we do not require any kind of form to be filled in, nor do we ask for a login to get our white papers. Enjoy.

Tuesday, October 28, 2008

Update on Snort and ClamAV for ms08-067

There's been a lot of action on the MS08-067 front over the weekend, so we thought we'd bring you up to date on the bug in general, and how Snort and ClamAV are providing specific detection. Interestingly, things are rolling out about the way we expected them to. We happened to be visiting a Snort class here in Columbia to field some questions last Thursday, and one of the students asked about how long it takes to move from binary patching to a POC. Our answer was as little as two hours. As it turns out, one private research organization reported EIP a little over two hours after patching for MS08-67 was released. That patch window is getting pretty small.

Snort Update

Of course, when you're dealing with 0-day, the patch window is an invalid concept. The VRT just finished up working through the actual pre-patch attack worm. We're pretty pleased with the outcome of our testing. After doing some reverse engineering and writing a quick DLL loader, Alain Zidouemba and Lurene Grenier were able to trigger the original, 0day attack in a controlled environment. We were able to get a pcap of the attack, and here are the test results from an all-rules load of Snort against that pcap:

[0-Day attack]

122:3:0 (portscan) TCP Portsweep Alerts: 1
1:7218:8 NETBIOS SMB srvsvc NetrPathCanonicalize WriteAndX little endian overflow attempt Alerts: 3
3:14809:1 NETBIOS SMB srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 3
1:7238:8 NETBIOS SMB srvsvc NetrPathCanonicalize little endian overflow attempt Alerts: 3
1:1394:8 SHELLCODE x86 NOOP Alerts: 42
122:1:0 (portscan) TCP Portscan Alerts: 5
3:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 3

We're happy to see that our newly published rules: SID 14809 and SID 14783. But there are a couple of more important things to notice here. We see plenty of evidence of "bad", with 42 alerts from the x86 NOOP rule from SHELLCODE. This would certainly give a skilled analyst a shot of detecting the 0-day attack. But the most important alerts are SID 7218 and SID 7238. These are from our detection set for MS06-040, a vulnerability from the same function as MS08-067. Because the attackers chose to use the same string that provided the overflow to also deliver the payload, they tripped the overlly long string check in our MS06-040 detection. So customers who had protection enabled from either SID 1394 or SID 7238 and SID 7218 had 0-day protection from this attack.

After the release of the binary patch, it can take a while to make a reliable exploit, and it wasn't until this weekend that public exploits began to appear. The first PoC up on Milw0rm was interesting. From a quick look at the source code, and in looking at how it behaves against our sensors, we actually believe that this POC is triggering the ms06-040 vulnerability, as opposed to the MS08-067 one. The PoC was actually up on Thursday, 10/23, and the first Milw0rm remote entry didn't show up until the 26th. Here is the testing output from the PoC and the

[Milw0rm PoC]

3:14817:1 NETBIOS SMB srvsvc NetrpPathCononicalize unicode little endian path cononicalization stack overflow attempt Alerts: 1
1:1923:9 RPC portmap proxy attempt UDP Alerts: 2
1:7224:8 NETBIOS SMB-DS srvsvc NetrPathCanonicalize unicode little endian overflow attempt Alerts: 1
3:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 1

[Milw0rm Remote]

3:14817:1 NETBIOS SMB srvsvc NetrpPathCononicalize unicode little endian path cononicalization stack overflow attempt Alerts: 1
1:7209:8 NETBIOS SMB srvsvc NetrPathCanonicalize unicode little endian overflow attempt Alerts: 1
3:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 1

Again, we detect both on the MS06-040 rules and our newly provided MS08-067 rules. Because the attackers chose to put payload in the same string as the attack, they trigger the overflow check in our prior MS06-040 rules. This won't always be the case, as payload can be placed outside the stub, but we would still alert on the "path cononicalization stack overflow attempt" rules.

We've also verified coverage against Core Security Technologies' Core Impact module that exploits this vulnerability. Not surprisingly, this was a reliable attack mechanism against machines that are shown by Microsoft's documentation to be vulnerable to this attack. Again, it triggers prior coverage on our MS06-040 rules:

[Core Impact]

1:1390:6 SHELLCODE x86 inc ebx NOOP Alerts: 2
3:14809:1 NETBIOS SMB srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 2
1:7235:8 NETBIOS SMB-DS srvsvc NetrPathCanonicalize little endian overflow attempt Alerts: 2
1:1923:9 RPC portmap proxy attempt UDP Alerts: 10
1:648:9 SHELLCODE x86 NOOP Alerts: 2
3:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 2

Because this is a well formed attack, we see a couple of additional things in this detection. The RPC portmap alert is triggered as the attack determines the attack vectors available to it. We also see indications of NOP sleds through SID 1390 and SID 648. Depending on how the attacker chooses to lay out the attack, NOP sleds can be an important component of attack detection, particularly in 0-day cases. I would strongly recommend that you leave active as many SHELLCODE rules as you can, to give your analysts a chance in 0-day cases. In this case though, we have solid detection, both in the form of SID 7235, our MS06-040 detection, and our MS08-67 specific set of detection.

Finally, we just finished up coverage testing for HD Moore's ms08-067 module for Metasploit. There is a lot of interesting things going on here, which we'll be covering in an upcoming white paper release. But for now, here is the Snort detection output:


3:14793:1 NETBIOS SMB srvsvc NetrpPathCononicalize WriteAndX little endian path cononicalization stack overflow attempt Alerts: 1
1:7250:8 NETBIOS SMB-DS srvsvc NetrPathCanonicalize WriteAndX little endian overflow attempt Alerts: 2
3:14783:1 NETBIOS DCERPC NCACN-IP-TCP srvsvc NetrpPathCononicalize little endian path cononicalization stack overflow attempt Alerts: 1

Again...ms06-040 coverage plus our update coverage. Note the absence of other identifying traffic (shellcode, scanning, etc...) without targeted coverage, you would miss this attack.

As a final take away, notice that in three attacks, we have several different alerts. Because of the time Brian Caswell and the VRT have put towards handling a variety of NetBIOS attack vectors, Snort is able to provide broad, comprehensive detection for attacks. This leads to a larger number of rules to provide this coverage, so I strongly encourage you to upgrade to at least Snort 2.8.2, when we introduced the binary tree structure to the rule parsing process. This provides a significant performance increase to the large, but well formed for a binary tree, NetBIOS ruleset.

ClamAV Update (Courtesy of Alain Zidouemba)

A number of files by the name of n[x].exe (where [x] denotes a integer number) have been observed to be a payload as a result of the MS08-067 vulnerability. The Trojans are usually 388KB in size. Once executed, n[x] starts off by trying to ping the server A whois of this IP address reveals that the machine is on a Chinese domain.
n[x].exe then drops the file %SYSTEMROOT%\system32\wbem\sysmgr.dll on the hard drive and registers the service “System Maintenance Service” that points to sysmgr.dll.
The following registry keys are created as well:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\sysmgr\ParametersServicedll = %SystemDir%\wbem\sysmgr.dllServicemain = servicemainfunc

The file attempts to ping which is a computer part of the domain. The Trojan very likely pings to verify network connectivity. The assembly code for sysmgr.dll reveals that the Trojan then checks the registry for the presence of the following registry keys:

HKLM\Software\Microsoft\OneCare Protection

All these registry keys are related to prevalent desktop security solutions.

Upon receiving a reply to its PING packet from, the Trojan has the confirmation it needs to say that it has access to the Internet, it then proceeds to try to download more malware from, a server located in Japan. In fact, an HTTP GET request is sent to with the following request URI:


with value1 being information on the antivirus software installed on the host and value2 being operating system information.
The Trojan also sends a cookie named ac to the server along with the GET request. The cookie is contains AES encrypted data about the user. Here is an example of the type of data it attempts to capture:

Outlook Express credentials
Protected Storage credentials
MSN Passport.Net credentials

As a result of a successful GET request, %SystemDir%\ is downloaded to the infected machine. This .cab file contains the following files:


After extraction from the .cab file, the batch file install.bat, copies all the files that were contained in the .cab to the folder %SystemDir%\wbem.
WinbaseInst.exe is then run which creates another service called "Windows NT Baseline" that points to basesvc.dll. The following registry keys are created in conjunction with the service:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BaseSvc\ParametersServicedll = %SystemDir%\wbem\ basesvc.dllServicemain = servicemainfunc

WinbaseInst.exe is thereafter deleted by install.bat.

We took a look at basesvc.dll in a disassembler and recognized in the .text section of this PE file, the following strings:

l 4b324fc8-1670-01d3-1278-5a47bf6ee188 is the Universally Unique Identifier, or UUID, that the vulnerable server service registers

l is the IP address for a computer belong to the company TransCanada Pipeline. It's on the domain

l 139 is the TCP port for Netbios Session Service. This is the port that is used to connect file shares

What we have is an attempt by this piece of malware to exploit the computer at IP address by sending it malformed DCE-RPC requests and relying on the vulnerable server service that is registered with UUID 4b324fc8-1670-01d3-1278-5a47bf6ee188. However, we were not seeing on the network traffic that showed that the routine above was actually called.
The .dll file exports the following 3 functions:


Towards the end of the function ServiceMainFunc, a subroutine is invoked. This subroutine pauses the execution of the program for a long period of time. This is usually done to make reverse engineering difficult but also so that the Trojan will not attract attention immediately upon being executed.

Armed with these pieces of information, we edited this .dll file to change the sleep time to 1 ms and to change the target of this attack to an internal IP address. Finally, in order to call the desired function in basesvc.dll, we wrote a small loader. We edited ServiceMainFunc in our slightly modified .dll (we do not want to attack the computer system for TransCanada Pipeline) this function then seeks out potentially vulnerable Windows machines on our local network. Upon finding a vulnerable Windows machine, shellcode that is embedded in the Trojan is executed on the target machine. This shellcode instructs the newly compromised machine to contact IP address in order to download a sample or variant of the Trojan.Gimmiv.

ClamAV detects these malcious files under the Trojan.Gimmiv (Trojan.Gimmiv-{1...7}) family.

It is worth nothing that none of the files associated with this Trojan are packed in any shape or form. Was this written by an inexperience coder or is this a deliberate taunt of the security community? The verdict is out on this one. Packing is a technique widely used by malware authors to prevent antimalware researchers from easily reversing malware binaries.

Friday, October 24, 2008

Why 114 rules for MS08-067?

With the release of Sourcefire's coverage for MS08-067, I've heard the same question repeatedly. "Why 114 rules? They were able to do it with just one." Since I wrote these rules, I'm the best to explain my solution.

I will not be going over the explicit nature of the vulnerability, but I will cover the protocol details that lead up to the vulnerability that make up my solution. The end goal of all of the rules is to detect attack traffic, while not alerting on benign traffic.

Detecting the underlying attack isn't that hard, in fact its pretty easy. While I could write one rule that looks for the basic information used in the attack, that basic information shows up all over the place. Printing to file transfers all include traffic that would set off the basic attack.

The hard part is making sure the detection only detects attacks, not benign traffic. My solution attempts to handle all of the potential methods for getting to the field that can be abused to exploit this vulnerability, and only do the detection of the attack on that field. The rules must handle all of the differences and neuances of the underlying protocols to limit detection to just the field in question. To that end, here are the primary neuancies that show up in nearly every DCERPC vulnerability.

First, the vulnerability is in a DCERPC service. DCERPC is accessable by a number of different methods:
  • netbios-ssn (139)
  • netbios-ds (445)
  • netbios-dgm (138)
  • NCACN-IP-TCP, direct DCERPC via TCP. (135, 593, or 1024 and above)
DCERPC over netbios has a number of protocol variations that need to be accounted for in the rules. Netbios has multiple common ways to get to DCERPC:
  • WriteAndX
  • Trans
Multiple SMB commands allow additional commands to be done after the original command in a single request. These commands have the nomeclaiture of "AndX". Examples of this would be:
  • WriteAndX with DCERPC
  • Trans with DCERPC
  • OpenAndX followed by Trans with DCERPC
  • OpenAndX followed by WriteAndX with DCERPC
  • OpenAndX followed by ReadAndX followed by WriteAndX with DCERPC
  • etc
SMB allows for normal and unicode string types, both of which are different at the packet level.

At the DCERPC layer, there even more differences. There are versions that differ greatly on the packet level:
  • v4 (request based)
  • v5 (session based)
Integers can be represented on the wire as big endian or as little endian. In addition, there is a 16 byte object identifier that may or may not be set in a given request.

Handling all of these permutations combines to a set of 114 rules. If you think I wrote all of these permutations by hand, you are nuts. I am firmly in the code-generation camp. Some time ago, I wrote a code generator that handles all of the permutations for me, allowing me to focus on the specifics of the attack, not the specifics of the protocol.

Thursday, October 23, 2008

Out of Band Microsoft Security Advisory MS08-067

Today, Microsoft released an out of band patch for a vulnerability concerning DCE/RPC that is being actively exploited by a Trojan.

We were busy today :D

Details on what we were busy with are available here:

More details on the Trojan are available here:

Here's a link to the Microsoft bulletin:

Monday, October 20, 2008

Introduction to Network Penetration Testing


In an effort to broaden the audience and topic base for the VRT blog, this week we are going to take a very high level view of what a network penetration test looks like from the tester's perspective. Some of the techniques and ideas behind a high-level network penetration test will be described. This entry is not intended to be create a world of savvy pentesters out there, as nothing can replace knowledge and experience gained from previous tests, but it should at least get people started down the road toward successful penetration testing. Also, knowing what a network pentester does during their assessment will also help the pentester's customers have a better understanding of the process.

This overview is written with an interest in ease of use with no regard for stealth.


A network penetration test, in its most simple form, can be described as multiple iterations of three steps -- reconnaissance, exploitation, and penetration. Each step leads to the next as well as back to the previous, providing more data for subsequent tests and attacks. Penetration adds new targets as more and more resources become available from new attack positions.


The first step of any penetration test is to become familiar with your target. For this discussion, we will assume the IP addresses for the target are known. The two most obvious steps for getting a high level view of your target are to find what ports are listening by using nmap and to get a basic understanding of your target's security posture by using a vulnerability scanner such as Nessus. Nmap will provide a list of all ports that are open (and are therefore potential attack vectors) and Nessus will attempt to provide a list of vulnerabilities found on the target hosts. Nessus's results cannot be taken at face value due to the nature of its testing, but it does provide a fairly broad view of what services are available, what service banners were provided, and guesses as to what vulnerabilities are present.

Using the reports from nmap and Nessus, we can begin to focus our attacks on hosts and services that further our goals of getting into the network. Most tests from Nessus do not actually perform an exploit. To attempt to exploit a vulnerability, an exploitation framework such as Metasploit, sample exploits from or elsewhere on the 'Net, or a custom exploit needs to be used.


There are many types of exploits in the wild - denial of service, information leakage, arbitrary code execution, and escalation of privilege are but a few. Denial of service attacks are generally not very useful in penetration tests. If you DoS a machine, you cannot use that device to further your own attacks. This is, of course, unless that machine is preventing you from gaining deeper penetration into the network or provides logging functionality and stealth is desired. This is an advanced topic that won't be covered by this post. For now, we'll shuffle DoS attacks to the "store for the report" file and concentrate on vulnerabilities for which a working exploit that provides machine access is available.

Information leakage, which often does not get the credit its due when compared to the sexy arbitrary code execution, is an integral part of any pentest. Gaining additional information from a service, then feeding that new data through the complete penetration test cycle, is probably the single largest contributor to a successful pentest unless the network is widely vulnerable to a single code execution. For example, imagine a Web exploit that required knowledge of the valid Web root to work. Suddenly, a 404 Not Found that leaked the system path to the page is extremely useful.

Finally, the ultimate class of exploit, arbitrary code execution. With the ability to execute arbitrary code, anything is possible. This ability leads us to the next section, Penetration.


The goal of a network penetration test is to gain deep access into the network. This is different than a network vulnerability assessment, where the breadth of vulnerabilities is sought. By exploiting vulnerabilites in a penetration test, we attempt to access more and more systems as we get behind obstacles. The most obvious way to achieve this goal is to install our tools and agents on devices as we compromise them and then use those new hosts as launch points for further attacks. Once we have system level access on a device, we can connect to any other device available to that machine. Another means of achieving deeper access is by abusing a trust relationship where a deeper machine can be made to act inappropriately due to data put on a device we can reach directly. The cycle then repeats with reconnaissance, exploitation, and penetration using this new host as our starting point.


This discussion was of a high-level view of network penetration testing. Several components of a more advanced test were not covered, such as identifying target hosts, the large amount of research required for a successful penetration test, or how to actually do the exploitation. The key takeaway from this post should be that penetration tests are a very iterative process -- gather information, act upon that information, feed new information into the cycle, and repeat until the goal has been achieved.

Saturday, October 11, 2008

Mac Transitions - Fixing Files

In the transition from Linux to Mac, I also ran across a small problem with Mac formatted text files on remote Linux machines. Line endings. I had assumed (and we all know what that means) that the Mac running OS X, being as it's userland roots lie firmly in the BSD camp, would be nice with it's text files and I wouldn't see any nonsense like I do with text files from Windows machines. It's not that they don't work, it's just that they do not look good in my text editor, Vim my favored pager, less and a few other cli programs I use.

Fortunately it is easy to fix the files, either in Vim itself, or with a little script I cooked up to do the job on a bunch of files all at once, here it is...

# File name:
# Date: 2008/10/11 08:57
# Author: Nigel Houghton
# $Id: $
# Copyright: (c) Sourcefire Inc. 2008

if [ "$1" = "" ]
echo "Usage: $0 filename1 filename2...."


changeit () {
tr \\r \\n < $OLDNAME > $NEWNAME

for file in $FILES

Of course, this could be done in several different ways and it could be extended for other systems (Windows for example) that use other line ending schemes. I put this script in my $HOME/bin/ so I can use it from wherever I happen to be in the filesystem.

Thursday, October 2, 2008

Perl Snippet

Recently, I have been moving Perl scripts from BSD and Linux machines onto OS X. Mostly, things are pretty smooth but today I had to change a script slightly so that I could read data from /private/var/tmp/ on OS X. The scripts I had on the other systems would read from /var/tmp/, on OS X there is a symlink to /private/var in the root partition, but it seemed to me that relying on the existence of symlinks is not a particularly good idea. Especially if I would need to move the scripts onto another system in the future.

I searched around my trusty Perl documentation and of course, online at and I found I could use a special variable that contains the operating system name. Here's what I came up with:

my $infile = $ARGV[0];
my $os = $^O; # woohoo there's a special variable I can use for this


sub get_xmlpath
if ( $os eq "darwin" )
$xmlpath = '/private/var/tmp/xml-data/';
$xmlpath = '/var/tmp/xml-data/';
$infile = "$xmlpath$infile.xml";
print "Using XML file: " . $infile . "\n";
return ($infile);

Could it be done using less lines? Of course, but then I think Perl Golf is just plain dumb. Disclaimer: this will not work on Win32, fortunately I never have to use Perl on Win32.

Monday, September 29, 2008

Guide to AWBO Exercises

Over here at the VRT, we've thoroughly enjoyed sinking our teeth into the awbo exercises. Hopefully, readers who've had the chance to work through these are eagerly anticipating those to come.

On the other hand, there may still be some of you who are interested in giving these a shot, but either haven't ever worked with exploitation before or aren't sure how to set up their environment. For those who need a little extra nudge to get started, I've prepared a simple walk through outlining my personal preferred way of approaching these exercises.

If you've already completed any of the awbos, this guide will likely ring a tad redundant. If you haven't, but have a fairly good understanding of how the stack works, then read on. Given that spoiling any of the exercises would defeat the purpose of publishing them, I've written a short short, exploitable C program we'll be using as an example. The anatomy of the stack is a topic reserved for a later post.

read more here

Snort startup script for Ubuntu

Some folks just cannot write shell scripts, especially startup scripts, no matter what. They aren't just a collection of cli commands echoed into a file with a .sh extension and made executable. Ubuntu has a nice skeleton startup script that provides a good template for writing your own custom scripts. Here is one I made earlier for Snort:

#! /bin/sh
# Provides: Snort
# Required-Start: $local_fs $remote_fs $syslog $network mysql
# Required-Stop: $local_fs $remote_fs $syslog $network mysql
# Default-Start: 2 3 4 5
# Default-Stop: S 0 1 6
# Short-Description: Init script to start the Snort daemon
# Description: Provides Snort service on startup and terminates
# on shutdown. Snort is an IDS or IPS. This script
# assumes that snort is installed in /usr/sbin and
# that it's main snort.conf file is in /etc/snort.
# The service will be started as a daemon, listening
# on eth0 and will also start quietly. If you require
# something other than this, you will have to edit
# the script accordingly.
# License: GPLv2 see

# Author: Nigel Houghton <>

DESC="Snort service for IDS or IPS"

# Exit if the package is not installed
[ -x "$DAEMON" ] || exit 1

# Read configuration variable file if it is present
[ -r /etc/default/$NAME ] && . /etc/default/$NAME

# Load the VERBOSE setting and other rcS variables
[ -f /etc/default/rcS ] && . /etc/default/rcS

# Define LSB log_* functions.
# Depend on lsb-base (>= 3.0-6) to ensure that this file is present.
. /lib/lsb/init-functions

# Function that starts the daemon/service
# Return
# 0 if daemon has been started
# 1 if daemon was already running
# 2 if daemon could not be started
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON --test > /dev/null \
|| return 1
start-stop-daemon --start --quiet --pidfile $PIDFILE --exec $DAEMON -- \
|| return 2

# Function that stops the daemon/service
# Return
# 0 if daemon has been stopped
# 1 if daemon was already stopped
# 2 if daemon could not be stopped
# other if a failure occurred
start-stop-daemon --stop --quiet --retry=TERM/30/KILL/5 --pidfile $PIDFILE --name $NAME
[ "$RETVAL" = 2 ] && return 2
start-stop-daemon --stop --quiet --oknodo --retry=0/30/KILL/5 --exec $DAEMON
[ "$?" = 2 ] && return 2
# Many daemons don't delete their pidfiles when they exit.
if [ -f "$PIDFILE" ]; then
rm -f $PIDFILE
return "$RETVAL"

# Function that sends a SIGHUP to the daemon/service
do_reload() {
start-stop-daemon --stop --signal 1 --quiet --pidfile $PIDFILE --name $NAME
return 0

case "$1" in
[ "$VERBOSE" != no ] && log_daemon_msg "Starting $DESC" "$NAME"
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
[ "$VERBOSE" != no ] && log_daemon_msg "Stopping $DESC" "$NAME"
case "$?" in
0|1) [ "$VERBOSE" != no ] && log_end_msg 0 ;;
2) [ "$VERBOSE" != no ] && log_end_msg 1 ;;
log_daemon_msg "Restarting $DESC" "$NAME"
case "$?" in
case "$?" in
0) log_end_msg 0 ;;
1) log_end_msg 1 ;; # Old process is still running
*) log_end_msg 1 ;; # Failed to start
# Failed to stop
log_end_msg 1
echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
exit 3


You may use it at your own risk :D Some things may need to be changed before it will work for your system and you should use the update-rc.d command to put the links in the right places for you after installation into /etc/init.d/.

p.s. Don't forget to chmod 0700 /etc/init.d/snortstart after you install it.

Friday, September 19, 2008


Some of you tore through awbo3 pretty quickly, but I wanted to give others time to catch up before posting this one. We're going to start getting into some issues you'll see in live software when working on exploits. This one in particular might remind you of a certain back orifice parsing vulnerability you may be familiar with.

It was asserted that this one couldn't be done in XPSP2, only in Win2k, but it really depends on how cl orders the stack before tossing the cookie in. Later, you'll get a chance to work on this with a mocked up stack cookie (awbo6) so keep that in mind here. For now though, lets stick to Win2k. The same rules apply here: no NOP sleds, no static stack return addresses.

For those who are just joining us, shellcode is here, and the windbg cheatsheet is here.

Hang on folks, we're venturing into rough waters. AWBO4

"Most deadly errors arise from obsolete assumptions"

Tuesday, September 9, 2008

Logical signatures in ClamAV 0.94

On September 1, 2008 Sourcefire released an engine update for ClamAV. This latest version offers new and updated features that allow researchers to write better signatures to detect malware. A quick overview of the changes in ClamAV 0.94 can be found here.

Up until ClamAV 0.93, the following formats have been used the most to write signatures to detect malware:
  • a full MD5 checksum of a file inside .hdb files in the following format: MD5:FileSize:MalwareName
  • a MD5 for a specific section of PE file stored in .mdb files in the following format: PESectionSize:MD5:MalwareName
  • a signature in a .ndb file using the following format: MalwareName:TargetType:Offset:HexSignature[:MinEngineFunctionalityLevel:[Max]]
ClamAV 0.94 introdcues a key new feature: logical signatures. A logical signature employs Boolean operators to combine one of more .ndb-style signatures into a single one. The main benefit of this approach is that it allows for more flexible pattern matching. The format for these new logical signtures is:


Logical signatures should be stored in .ldb files.

Let us illustrate how logical signatures can be used by analyzing a mass-mailer worm. The code for this sample is in Visual Basic Script (VBS) and so is easily readable. Right away we can see that the worm can loosely be classified in the category "AV Killer" as well since it attempts to identify the presence of various AV tools in order to disable them.

After normalization, we can create 4 signatures to detect each attempt to disable AV tools as follows:

Kaspersky Antivirus Personal/Kaspersky Antivirus Personal Pro (0): 66696c656578697374732028{-25}202620225c6b6173706572736b79206c61625c6b6173706572736b7920616e7469766972757320706572736f6e616c

Antiviral Toolkit Pro (1): 66696c6565786973747328{-25}202620225c616e7469766972616c20746f6f6c6b69742070726f{-100}2e64656c65746566696c652028

AVPersonal (2): 66696c656578697374732028{-25}202620225c6176706572736f6e616c{-100}2e64656c65746566696c652028{-25}202620225c6176706572736f6e616c

Trend PC-cillin 98 (3): 66696c656578697374732028{-25}202620225c7472656e642070632d63696c6c696e{-100}2e64656c65746566696c652028

Another very important characteristic of this script is that this worm tries to use Outlook MAPI to send itself to the first 8000 contacts found in the address book.

A signature to detect this portion of the file could be (4):


With ClamAV 0.94 and the addition of logical signatures, we write this highly flexible signature:

Worm.Godog;Target:0;((0|1|2|3)& (4));(0);(1);(2);(3);(4)

With a successful match, this signature will return the malware name "Worm.Godog". A match will occur when signature (4) is detected as well as either signature (0), (1), (2) or (3). The signature will look like the signature below in a .ldb file:

Worm.Godog;Target:0;((0|1|2|3)& (4));66696c656578697374732028

In previous versions of ClamAV up to 0.93 included, one would have to write many signatures in order to match the flexibility of the signature above. In this malware sample, 3 different AV tools are disabled the worm tried to spread to the first 8,000 contacts of your Outlook address book. However, a variant could disable just one of the AV tools and still try to spread over the network. To detect the variant that just disables Kaspersky AV, a pre-0.94 signature would look like:


To detect the variant that just disables Antiviral Toolkit Pro, a pre-0.94 signature would look like:


More signatures can be written for the other cases.

This simple example shows how logical signatures can be very powerful in reducing the number of signatures written to detect variants within a malware famill. Logical signatures can also help detect malware samples that were previously tough to detect and reduce the number of false positive detections.

Friday, September 5, 2008

Webcast Teaser -- Basic Buffer Overflow Detection

Our next webcast, Performance Rules Creation: Rules Options and Techniques, is scheduled for 1pm EST on Wednesday, September 17th. We’ll be using actual published VRT rules to demonstrate common rule structures, rule options and some of the gotchas that you might run across when writing Snort rules. We will also be referring back to some information from our previous webcast, which concentrated on the architecture of the Snort engine and performance considerations in rule writing. If you didn’t catch it, you might want to review the material. It is archived here.

For example, we’ll be looking at a common buffer overflow detection technique using negative content matches and the isadataat rule option. We use SID 13916 to demonstrate:

alert tcp $EXTERNAL_NET any -> $HOME_NET 4000 (msg:"EXPLOIT Alt-N SecurityGateway username buffer overflow attempt"; flow:established, to_server; content:"username="; nocase; isdataat:450,relative; content:!"&"; within:450; content:!"|0A|"; within:450; metadata:policy balanced-ips drop, policy connectivity-ips drop, policy security-ips drop; reference:url,; classtype:attempted-admin; sid:13916; rev:2;)

For easier analysis, here is the core detection functionality of the rule, broken into a list:

  • flow:established, to_server;
  • content:"username=";
  • isdataat:450,relative;
  • content:!"&"; within:450;
  • content:!"|0A|"; within:450;

Because this is an attack on a server, we use the flow:established, to_server; rule option to tell Snort to only look at traffic that is headed towards a server (in this case, one listening on port TCP/4000). This both provide an increase in performance by not looking at server-response traffic, and will reduce false-positives by not looking at traffic that could not possibly trigger the vulnerability.

Next, we look to match the string “username=” in the packet. For those following along from last time, this will be the “first, longest” content match, and will be used in the fast-pattern matcher. This string is actually the beginning of the vulnerable field, so we will use it to anchor our upcoming detection. Also, note that we believe that “username=” could be upper or lowercase, or any combination, so we use the nocase keyword to modify the search to be case insensitive.

The attack appears to require at least 450 bytes of data to successfully overflow the buffer. Also, given the protocol we’re looking at, we know that both “&” and “\x0a” (also, \x0d\x0a, but we will just use \x0a for speed, since it works alone or paired with \x0d) are terminating characters that indicate the end of data for that key/value pair. Using this information we build the detection with the last three rule options.

We use a pair of negative content matches, content:!”&”; within: 450; and content:!”|0A|”; within: 450; to ensure that we do not see either terminating condition in the next 450 bytes of payload. Note that we use “within” as opposed to “depth”, because “within” sets the relative match flag and operates from the end of the previous match (username=). Depth would operate from the beginning of the payload (a non-relative search).

There is a problem with using negative content match. It will return as successful (that is, it did not see the provided pattern) even if it runs out of data to read before it reaches the end of our within: 450 requirement. This is bad for two reasons: One, we might false positive on an unreassembled TCP message (splitting the username= field across two packets), and two, if we don’t have enough data to create an overflow, we shouldn’t be doing a pair of content checks. To solve both these issues we use the isdataat: 450, relative; check to ensure that starting from the last match (username=), we have 450 bytes of data remaining in the payload buffer. If there isn’t enough data left, we won’t bother with the last two checks, avoiding a false-positive situation and the overhead of running two long, unnecessary content checks.

The detection is fairly simple, find “username=” and then see if the provided data is 450 or more bytes of data. If it is, we most likely have an attempted buffer overflow attack. But as you can see there are a number of factors we need to get right to ensure we have optimized detection that is both accurate and fast.

If you’re interested in more examples, catch the webcast on September 17th. Here are the details:

Date: Wednesday, September 17, 2008
Time: 1:00 PM US Eastern Daylight Time (GMT -4:00)

Wednesday, September 3, 2008

AWBO Part Deux

Since some people have been chomping at the bit for the next challenge, so here it is. The same rules apply as did last time. When we say no static stack return addresses, this also means of course that there's no need for NOP sleds, so I shouldn't see them in solutions. This time around you'll find a solution under Windows 2000 SP4, then you'll find a solution for Windows XPSP2. I've also included a windbg cheat sheet to save the poor soul who told us he had worked out a solution using only Dr. Watson...

"Please be advised that a noticeable taste of blood is not part of any test protocol"

awbo3.exe download and windbg cheatsheet

Friday, August 29, 2008

Checking Multiple Bits in a Flag Field

Sometimes, it is necessary to check a value in a flag field that is not a power of two (1, 2, 4, 8, etc.) and therefore requires multiple bits to be represented, yet other values in the byte are not part of that flag field. Such is the case for DNS where server status codes are represented as a four-bit value within the fourth byte of the DNS response packet (Reference 1). For the Kaminsky DNS bug (Reference 2), the Sourcefire VRT developed a rule to detect the "back scatter" of the attack in the form of excessive NXDOMAIN packets being sent by a DNS server.

The trouble with detecting NXDOMAIN packets is that the return code field is only four out of the eight bits in the byte. We cannot simply use a byte_test on the value 6 because if any of the other flags in that byte are set the byte_test will fail. Additionally, we cannot do a bit test for 6 in an attempt to ignore the top four bytes because decimal 6 requires two bits to be set in binary form and bitwise AND will return true if either bit is set, not just when both bits are set. For this reason, we must synthesize the value of 6 by checking each individual bit.

The decimal number 6 is represented in the following binary form:

0 1 1 0

This can be determined by using a calculator that will output in binary (Microsoft's XP Calculator in scientific mode will do), or by splitting the number 6 into its component powers of 2, which is 4 + 2. You also can read the binary representation above as (0 * 8) + (1 * 4) + (1 * 2) + (0 * 1). This is important to know, as we must test for each bit individually with its own byte_test.

To make this example line up directly with the DNS bug, we will now split these byte_tests exactly as they would be done for checking for NXDOMAIN packets.

The format of byte_test is the following -- byte_test: , [!], , [,relative] [,] [,] [,string];

  1. Make sure the highest bit is not set:

  2. Make sure the second highest bit is set:

  3. Make sure the third bit is set:

  4. Make sure the lowest bit is not set:

In the above operators, the '&' mean "bitwise AND," which returns true if the bit is set. Preceeding the '&' with '!' means "NOT bitwise AND," and returns true if the bit is not set, as expected.

Note that for the VRT's check for Kaminsky DNS back scatter, we only check the bits that are set, and ignore the most and least significant bits. This was done for performance reasons. It was decided that false positives would be at an acceptable level due to the values of the other rcodes not overlapping those two bits heavily and because the rule uses a threshold so a number of false positives would be required to trigger the alert.

We cannot simply do a single bitwise check for 6 as the bitwise check will return true if either bit in the value 6 is set. Due to the way bitwise AND works, there is no way to distinguish which bit was set or if both bits were set. By checking each individual bit, both the bits that are set and are not set, we have guaranteed the exact value of those four bits. Additionally, we have gotten around the problem where values in the top four bits would make a regular byte_test fail. The Snort rules language allows for the multiple byte tests to work because subsequent tests will only be run if the previous test succeeded. For this reason, it doesn't matter that we are essentially synthesizing the number based upon testing for its binary


  1. DNS, Domain Name System,

AUTHOR: Patrick Mullen, Senior Research Engineer, Sourcefire Vulnerability Research Team

Friday, August 22, 2008

Defcon, testing and exploiting

This year at Defcon Immunity trotted out the first iteration of their NOP cert test, and I had the pleasure of giving it a test run. I still think it's a great indicator of ability, despite the Immunity tools focus; I'm not a user of any of their tools generally, but I managed to pull off the hardest level test in a modest time. It got us thinking on the way home, where does one go from the bar set by the NOP to get to the next level in terms of exploit development skill? In this vein I've thrown together a few windows executables, and in a nod to Gera of Core, they're called Advanced Windows Buffer Overflows (AWBOs).

We've set up a few ground rules and a basic set up to keep things moving along:

1) All exploits are performed in Windows 2000 SP4 unless otherwise specified. Sometimes, otherwise will be specified.
2) Exploits will use the provided shellcode, or ret2lib.
3) You may not return to hard coded stack addresses.
4) No source code will be provided - just like the NOP cert.

Standard tools used are cygwin with perl, and windbg, installation in vmware a plus. The shellcode provided is the amazing windows exec shellcode from metasploit set up to run calc.exe.

I can say that all of these are exploitable, and they run through a progression, so try to do each of them in the most straight forward way possible. We'll be skipping awbo1.exe as it's very similar to one of immunity's tests (as far as my memory serves). They'll be released slowly over the next few months. Feel free to send in your solutions, or ask for tips. All of the examples have been play tested by the VRT analysts team, and are assured to be exploitable.

"This next test could take a very, very long time. If you become lightheaded from thirst, feel free to pass out. An intubation associate will be dispatched to revive you with peptic salve and adrenaline."

Awbo2.exe download and shellcode download

AUTHOR: Lurene Grenier, Analyst Team Lead, Sourcefire Vulnerability Resarch Team

Monday, August 11, 2008

DNS Vulnerability Paper

Now that Defcon is over and the Kaminsky DNS Vulnerability is completely out in the open, the Sourcefire VRT has a new whitepaper that discusses the issue and suggests detection methods using Snort rules. Download it here.

Friday, May 30, 2008

Flash Vulnerability Info

On 5-27-2008 Symantec issued a 0-day vulnerability alert pertaining to malicious flash (SWF) files circulating in the wild. The initial Symantec report stated that this issue was unknown and that it affected the latest version of flash player and several other Adobe products that processed SWF files. Further analysis of the exploit files determined that the initial categorization of this as 0-day was incorrect and that this was actually a working implementation of the vulnerability described by Mark Dowd of the IBM X-Force team.

For more details on this flash vulnerability (CVE-2007-0071) then take a look at our analysis here:


How to annoy co-workers taking a break

We have a Foozball table here at SF World Domination HQ. It sees a lot of action from various people in the company during lunchtimes. Unfortunately, it is located close to the VRT lair. So close in fact, that we are able to run wire to a speaker strategically placed in the ceiling above the table. Once the speaker had been placed into position and the wires run back to the lair, the other ends of the wire were attached to a pair of desktop speakers connected to a laptop containing mp3s of some of the most hideous music known to man.

All we had to do was wait for the first set of victims. Sure enough, right on time, luncheon arrived and so did the unsuspecting groovers. A dose of Abba's "Dancing Queen" was enough to send them scurrying out and back to their part of the building.

The results so far: VRT 3 - IT Staff 1.

UPDATE: VRT 1 - Martin Roesch, Sourcefire CTO 0

The next victims can expect to be "Rick-Rolled", yes, we are that evil. (we will get some pictures of the debacle soon, hopefully we can catch some folks dancing too)

Power over Ethernet and Snort

Lurene correctly points out that vulnerability research is often a series of failures, but that what you learn as you work through the failures will often come in useful in the future. Recently we had a strong desire to put a snort sensor in-line with a wireless access point. While in the end we were unable to achieve the desired result, we had to go through a series of iterations in order to get the snort sensor to be able to see the traffic and still have the access point working, and we picked up some useful information about power over Ethernet.

Power over Ethernet (PoE or Data Terminal Equipment (DTE) Power via Media Dependent Interface (MDI), as our IEEE overlords put it) can be provided in two different pinouts. Alternative A passes power over conductors 1, 2, 3 and 6. This means that power is passing over the same wires as the data is. This can also be called ‘phantom power’ and appears to be the standard way that Cisco chooses to supply power. Alternative B passes power over conductors 4, 5, 7 and 8, which are not used in 100Base-TX cabling, but are in Gigabit Ethernet and 100Base-T4 networks. As it turns out, certain devices only work with Alternative B power, and this comes in handy later.
The target wireless access point receives its power via PoE. We knew this would be an issue because the Snort sensor we were using did not have the means to supply power over Ethernet. Also, because the power was being sent across data line, not the free pairs, we couldn’t use any wiring tricks to route the current around the sensor. In a somewhat insane moment, we considered pulling the power off of the data lines and reintroducing it to the alternative B wires. This also wouldn’t have worked, because the 802.3af protocol requires a powered device check, in which the switch looks for 25K ohm resistance while passing DC over the powered pairs. The sensor would not pass this check, so no power would be placed on the data wire.

Now, skipping past some recon, luck and a small bit of social engineering, we find out that our VOIP phones don’t support phantom power and require that power be passed over the free pairs. In order to support this, each phone has a dongle that acts as an intermediary to the Cisco switches and moves the power from the data lines to the free pairs. Also, the dongle passes the 25k ohm test, so we don’t have to worry about that either. So now we can ensure that power is supplied, and that the power runs on non-data lines. All that is left is to route the power around the sensor.

We find an unused patch panel in the data center and Patrick runs out to get a seven dollar punch down tool. The idea is straightforward. We use four ports on the patch panel: Port one is in from the dongle, port two is out to the sensor, port three is in from the sensor’s second bridge port and port four is out to the access point. From port one we grab the free pairs that have the power on them, 4,5,7 and 8 or brown, brown/white, blue and blue/white and run them to port 4, bypassing the sensor. The data wires, 1, 2, 3 and 6 or green, green/white, orange and orange/white, are wired straight to port two. Port three patches the data lines straight to port four. See the diagram below:

PoE Bypass Diagram

Once the panel was ready, we could begin testing. The last remaining hurdle was to remember that the patched connection from the sensor’s second port to the access port requires a cross over cable (future implementations will take care of that in the punch-down). Once that was done we were where we wanted to be: The wireless access point was powered, the Ethernet cable from the wireless access point ran into an inline snort sensor where we could see all of the traffic.

There were several other solutions we looked at. One that would have worked would have been to use an inline PoE device that supplies 802.3af compliant power to an unpowered Ethernet line. We would have placed this between the sensor and the wireless access point. Another idea is drawn out on Patrick’s white board as a series of calculations that were being made in an attempt to supply power directly to the line, again on the access point side of the sensor. I’m not sure whether it would have worked, or how many Ethernet cards we would have ended before we got it right, but the whiteboard sure looks impressive.

We did some other interesting things, including NOPing out some checks in Snort to let us do an overly long content replace. More on that, and maybe some information on how the Muppets relate to the Rick Roll craze a bit later her on the VRT blog.

Catayst 6500 Series Switch Installation Guide – Transceivers, Module Connectors, and Cables Specifications, url:

PoE IEE 802.3af White Paper, url:

Tech Info – LAN Wiring and Pinouts, url:

Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) access method and physical layer specifications, url:

AUTHOR: Matthew Olney, Research Engineer, Sourcefire Vulnerability Research Team