WMF 0-day exploit & developing Snort sigs

Two days ago, the presence of a Windows Metafile / graphics processing engine vulnerability made itself known in the form of an exploit, first identified on the Full-Disclosure mailing list. If you're not already familiar with this, I recommend you read up on it now. This has the potential to cause a lot of problems, even though its current implementation is "only" the distribution of spyware. For starters, you can check out the ISC's announcement and Microsoft's advisory.

As part of my job is protecting a large company from junk like this, I immediately began searching for work-arounds. Having tested (and failed) all of the work-arounds mentioned on public websites, I turned to my IDS. "At least," I figured, "I can see when my systems are getting compromised." Unfortunately, all of the signatures I'd found on the WMF exploit seemed either a bit arbitrary, very specific to this vulnerability, or generally not well-formed. I therefore took it upon myself to develop one of our own. Here, I share the process I used and the resulting signature. It was a good exercise on proper signature building that I hadn't been through in awhile. If you develop IDS signatures for your organization, this may be worth a read. Oh, and one more thing: this is your fair warning that my [pre] tags may make some of the literal text a bit difficult to read. I tried to work around this, but there are still formatting problems - my bad.

So, my approach was to identify any WMF files that contained what looked like an overflow or exploit, rather than write the signature to the exploit I currently had in-hand. My first task was to get a handle on what WMF files looked like: their file structure, etc. I found a great sourceforge article describing this here.

From that article:

The standard Windows metafile header is 18 bytes in length and is
structured as follows:

typedef struct _WindowsMetaHeader
WORD FileType; /* Type of metafile (0=memory, 1=disk) */
WORD HeaderSize; /* Size of header in WORDS (always 9) */
WORD Version; /* Version of Microsoft Windows used */
DWORD FileSize; /* Total size of the metafile in WORDs */
WORD NumOfObjects; /* Number of objects in the file */
DWORD MaxRecordSize; /* The size of largest record in WORDs */
WORD NumOfParams; /* Not Used (always 0) */

FileType contains a value which indicates the location of the metafile
data. A value of 0 indicates that the metafile is stored in memory,
while a 1 indicates that it is stored on disk.

HeaderSize contains the size of the metafile header in 16-bit WORDs.
This value is always 9.

Version stores the version number of Microsoft Windows that created the
metafile. This value is always read in hexadecimal format. For example,
in a metafile created by Windows 3.0 and 3.1, this item would have the
value 0x0300.

FileSize specifies the total size of the metafile in 16-bit WORDs.

NumOfObjects specifies the number of objects that are in the metafile.

MaxRecordSize specifies the size of the largest record in the metafile
in WORDs.

NumOfParams is not used and is set to a value of 0.

The first 18 bytes of the captured exploit file (dont' try this at home, kids!) are:

[clopperm@orion wmf_vuln]$ hexdump -n 18 xpl.wmf
0000000 0001 0009 0300 1f52 0000 0006 003d 0000
0000010 0000

Remember, we're looking at this little-endian. This means we see...

WMFHEAD our_file = {
WORD FileType=1;/* won't change */
WORD HeaderSize=9; /* always 9 - won't change */
WORD Version=0x0300; /* doesn't matter, but is 0300 = windows 3.0/3.1 */
DWORD FileSize=8018; /* 8018 words=16036 bytes, checks out, but may change */
WORD NumOfObjects=6; /* 6 objects in file, may change */
DWORD MaxRecordSize=61;/* 61 word max size. Not sure how this impacts sig either */
WORD NumOfParams=0; /* Always = 0. */

So, we can say the typical WMF header looks like this:

0001 0009 ???? ???? ???? 0006 ???? ???? 0000

Translating this into a snort signature (remember, on the network, we need to translate to big-endian!), we get something like this:

alert tcp any any -> any any (msg: "INFORMATIONAL - Windows Metafile (WMF) detected"; content: "|01 00 09 00|"; content: "|06 00|"; distance:6; within:2; content: "|00 00|"; distance:4; within:2; sid:2000002; rev:1; )

Testing this signature on our exploit, it fires properly. MS Office comes with a large number of WMF files. I tested this signature's effectiveness by copying all of the files in the clear between two servers and validating that this identification signature fired on them, as well.

The WMF files in MS Office appear to be Aldus placeable metafiles, which means they have an additional header at the beginning of the file (see the sourceforge article). Since we didn't specify a depth, the signature fired anyway. This is good. While it would be nice to be able to specify an initial search depth to match the first pattern, HTML & such appearing before the file make this difficult to guess.

We know the Intel NOP opcode is 0x90. Looking for this repeated will identify a NOP slide. The exploit we have in-hand shows the NOP slide beginning at address 0x426 to address 0x15b0, but without more detailed knowledge of the vulnerability (and to make this more generic, covering ALL WMF overflows), we'll need to search the rest of the packet. We'll require 16 NOP's (an arbitrary number) to trigger. Our new signature looks like this:

alert tcp any any -> any any (msg: "SHELLCODE - Windows Metafile (WMF) with NOP Slide"; content: "|01 00 09 00|"; content: "|06 00|"; distance:6; within:2; content: "|00 00|"; distance:4; within:2; content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; distance:0; sid:2000002; rev:1; )

Testing this against our exploit, we have a winner! This should detect this and any other WMF files that include a NOP slide in them. Confirming we didn't just create a noisy signature, this didn't fire on traffic containing legitimate WMF file copies, the same one we used previously to validate the part of the rule that detects the WMF file format.

The "any" keywords for ports & IP's are dangerous. This is the one thing we'll modify specifically for this exploit, so we don't over-burden the ids:

alert tcp $EXTERNAL_NET $HTTP_PORTS -> $HOME_NET any (msg: "SHELLCODE - Windows Metafile (WMF) with NOP Slide"; flow: established,from_server; content: "|01 00 09 00|"; content: "|06 00|"; distance:6; within:2; content: "|00 00|"; distance:4; within:2; content: "|90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90 90|"; distance:0; classtype:attempted-user; reference:url,www.frsirt.com/english/advisories/2005/3086; sid:2000002; rev:1; )

This will catch any HTTP downloads of WMF files with NOP slides in them. You'll note that I also added the classtype and URL references. Of course, this was tested against the exploit flying over the wire, as well as legitimate WMF file copies, and passed with flying colors. Now,
all we need to worry about is if the attack vector changes. We don't have to worry about the specifics of the exploit!

Hope this is informative to everyone. It was yesterday's afternoon project for me :-)


InfoSec Podcast

As of yesterday morning, I've become a huge fan and experienced consumer of Podcasts. Okay, so I've listened to about 10, but really, who's counting?

In any case, a co-worker recommended the CyberSpeak podcast, hosted by former federal agents Bret Padre and Ovie Carroll. Listening to the previous two installments, I have to say this is an enjoyable 'cast with two guys who obviously know their stuff. While I'd already read about most of the news discussed, it was great to hear it discussed in an informal setting by two professionals. The perspective offered by witnessing such a dialogue is very informative, and helped me digest the news in a different way than simply reading about the stories on my favorite InfoSec news sites. I highly recommend listening in, especially if you don't have the time at work to discuss these types of events with other "birds of a feather;" or, as may be the case for some, there are no BoF's where you work. The tidbits of peripheral information they offer are often insightful, and not the kinds of things you pick up from simply reading the news. Their personalities also translate what could be boring, inane material into something that's genuinely fun to listen to -- well, for people in the industry, anyway (I wouldn't recommend it to someone like my father, the accountant).

(Entry updated 12/30 with the preferred URL for the podcast; thanks, Bret & Ovie!)


Some Casual Reading and 2006 Security Forecast

Interesting Articles
While I don't intend for this blog to become YANLS (Yet Another News Linking Site), I've come across a number of articles at work recently that have been very informative on a variety of subjects. Reader beware: these range in technical complexity from the most basic to the very complex.

I've been preaching to friends, family, co-workers, and anyone who will listen about the good, yes, good things that legislation like Sarbanes-Oxley, GLBA, and HIPAA have brought to the world. Most notably, pushing real security controls & technologies into companies previously too cheap to heed the advice of their security analysts. CSO Online recently published an article titled How To Love Sarbanes-Oxley, written by a security manager at Kennametal, that gets into the details of some of the good effects of the legislation, from a security perspective.

In the category of "blogging about blogging," we find the Security Monkey blog titled A day in the life of a security investigator. This is an entertaining read that illustrates some of the trials of being a security analyst. It's well-written, and a good read if you have some time on your hands. Writing about the specifics of my work is an employment gray area that I painstakingly avoid, but if I were to do so, it would many times read like this. For those of you who podcast, this may be of interest to you as well.

Finally, I ran across a very detailed and informative overview of both recovering data deleted off of magnetic media, as well as how to delete this data so that it's difficult to recover. The paper, from the University of Auckland, is titled Secure Deletion of Data from Magnetic and Solid-State Memory.

2006 Security Forecast
It's going to rain. But then again, since about 1999/2000, the security outlook for any given year has looked about like the weather forecast for Seattle: Rain, with a chance of more rain. I actually just wanted to note a few specifics in this section:
  1. Security configuration management software, also known as "Enterprise Configuration Management Software" and "Enterprise Risk Management Software" will get a lot of attention. This is software that will aggregate the configuration data from your network control devices (firewalls, routers, etc.) as well as your vulnerability assessment software. Based on this information, it can give you a view of your overall security risk (one host has a higher risk than another, because a vulnerability is not mitigated with a firewall rule), analyze access between nodes & sites, and evaluate the impact of network changes on the risk assumed by your organization. Skybox is, to my knowledge, the only COTS product that can deliver this. I will be writing about this software in more detail in the near future, hopefully.
  2. We will see more effective use of IM and P2P software to spread malware. These are the two vectors that offer the greatest amount of targets through the exploitation of a single technology, and to date have not been effectively attacked. Specifically, this makes for a great introduction into an otherwise-secure corporate network, since many users circumvent strong firewall egress controls by connecting to these services via weak HTTP proxy controls. A hybrid AIM / Microsoft vulnerability-du-jour attack could be especially damaging.
  3. Personal networking sites like Myspace and Friendster allow users to post HTML content without going to the pain of setting up their own website, DNS, etc. This is also a great way to launch phishing attacks, as well as host malicious code to be downloaded by bots, exploit the IE vulnerability du jour, and a variety of other bad things with minimal accountability. This has been rare to date, if it's happened at all, but the potential of these sites will soon be discovered by attackers. If administrators aren't proactive in filtering the content of their users' pages, this could mean trouble for the rest of us.


Tuning for Cryptographic Hashing Algorithms

The main reason I haven't written in awhile is that I've been working on a paper on performance tuning for cryptographic hashing algorithms, which is finally done. This paper investigates processor configurations optimal for RIPEMD-160, SHA-1, and MD5 algorithms. It provides detailed information on CPU design, cache organization, and compiler optimizations for each of the algorithms, and draws some conclusions on the cryptographic hashing application domain as a whole. The data is also available on my website. This information would be helpful to an engineer desinging an FPGA for hardware-accelerated hashing, and could also be of use in choosing a general-purpose CPU that would be performing intensive cryptographic hashing. There is certainly more to explore than what the paper covers, but it gives a good overview of the demands placed on hardware by these algorithms and opportunities for better efficiency.