Evasion with OLE2 Fragmentation

Update: A bug was discovered in the public refragmenter script, after fixing this bug we updated the detection numbers to match the new results.

At BreakingPoint, we provide comprehensive coverage of Microsoft Tuesday patches. This Tuesday was no different and we released StrikePacks 45799 and 45800 to cover MS09-017 (the PowerPoint vulnerabilities). In addition to writing exploits for these flaws, we also research application-specific evasion methods. In the case of file format flaws, we support evasion at every level, including techniques like IP fragmentation, alternate MIME encodings, HTTP compression, and data randomization within the files themselves. While working on Strike coverage for MS09-017, we discovered a simple way to bypass mainstream anti-virus and IPS signatures for malicious Office documents. This post talks about the method we used and some of our test results against popular anti-virus products.

Microsoft Office documents have been abused by security researchers and malware writers for many years. In 1999, Melissa, one of the first email viruses, used Visual Basic macros to send itself to all addresses in the victim's address book. Since then, macro security has been greatly improved, and attackers have moved on to exploiting parsing flaws in the Office software itself. This month, Microsoft released patches to address 14 vulnerabilities in the PowerPoint document parsers. Unlike traditional network attacks, file format flaws are notoriously difficult for IPS vendors to identify accurately. To remedy this, the anti-virus industry has added file format exploit detection into both desktop and network gateway scanning products.

Office documents are some of the most convoluted file formats in wide-spread use. The basic structure of these files is based on the Compound Document Format (OLE2 Structured Storage). This format is essentially a block-based filesystem with specific files and directories for each type and version of Office document. The actual "file" entries within these documents are also proprietary and change based on the version and features of the Office software used to create them. In order to detect a file format exploit, the parsing software needs to understand OLE2, locate the correct entry containing the document contents, and parse through that content to locate the specific structure that triggers the exploit. This process is CPU intensive and requires the parsing software to have a deep understanding of the version-specific Office document data inside of the OLE2 container. Creating software to do this correctly is expensive and time consuming, so the easy solution is to ignore the document format entirely and just scan for exploit-specific signatures. This is what most anti-virus and IPS products do today.

Just like most block-based filesystems, the OLE2 format is susceptible to fragmentation. When the Office software wants to write data, it tries to consume any available free blocks before allocating new ones. The OLE2 format has two different block tables; one for small entries (normally set to be less than 4096 bytes), and another for larger contiguous segments. Although fragmentation can occur during normal editing of an Office document, it is rare for documents to be heavily fragmented.

It turns out that there is an excellent OLE library for Ruby, written by a developer who goes by aquasync. This library makes it easy to create and modify Compound Document files. With a little bit of scripting, we were able to create a tool (available below) to force heavy fragmentation of Office documents. Out first test of this tool used a Melissa variant as the base document. Uploading the raw Melissa Word document to VirusTotal.com resulted in 39 out of 40 AV products recognizing the document as malicious. After running this file through the refragmenter script, the results were 36 out of 40. This is pretty good, but keep in mind this malware was originally released in 1999.

Melissa may not be the best choice for testing modern anti-virus capabilities. Instead, lets look at a live sample of the Microsoft Word exploit for CVE-2007-0515 (MS07-014). The original, unmodified version of this document is detected by 25 out of 40 anti-virus products. Using the refragmenter script with 64 byte writes, only 4 out of 40 products detected the file as malicious.

IPS and IDS developers have a great excuse for poor Office document coverage - this type of analysis is difficult and processor intensive. However, this is precisely the area where anti-virus products are supposed to succeed. Its embarrassing that so many products fail to detect known threats that have the exact same byte stream, just reordered using a mechanism that occurs in real documents. In our testing, the only public tool that can accurately identify fragmented Office documents is Office Cat, written by Lurene Grenier of the Sourcefire VRT. This tool uses the Windows OLE API to parse each stream, regardless of fragmentation, and scans deep into the document format to detect individual exploits.

All BreakingPoint Strikes that target Office document flaws have been updated to support the OLE::RefragmentData option, which performs an operation similar to the refragmenter Ruby script below.

The refragmenter script can be downloaded here.

This script depends on the ruby-ole library, which can be found online at http://code.google.com/p/ruby-ole/

For more information about Office document flaws and exploitation methods, we recommend Bruce Dang's Black Hat USA 2008 presentation Methods for Understanding Targeted Attacks with Office Documents.

CanSec West 2009 Overview

The CanSecWest security conference just occurred in Vancouver last week. This three-day conference, preceded by two days of dojo training sessions, features a single track of mostly high-quality talks. Another feature of the conference is the third consecutive Pwn2Own contest, which gives researchers the chance to win hardware and cash awards for compromising various laptops and mobile phones. Three members of the BreakingPoint Labs team attended this year, HD Moore, Todd Manning and Sean Bradly, and we wanted to give our review of the talks presented.

Mobile technologies were the main focus of talks on the first day with iPhone, Android, Windows Mobile, Palm and Symbian mentioned in several talks. Sergio Alvarez started the mobile device theme with a presentation covering mobile platforms and finding and exploiting bugs in them. This talk ended with a demonstration of an iPhone exploit that didn't go completely smoothly, but the information presented was a great reference for attacking smartphones. This talk was the first mention of the meme of "No More Free Bugs," which was later expanded upon by Charlie Miller during Thursday's lightning talks.

The second day of the conference broke from mobile platforms, and was the most diverse of the conference. Anibal Sacco and Alfredo Ortega from Core presented a very interesting talk entitled Persistent BIOS Infection (link to slides). The presentation was full of great information, and the demo, which showed their infected BIOS patching binaries on both Windows and OpenBSD were really cool. They focused on the Phoenix BIOS, but their techniques should be fairly applicable to other BIOSes. Next up was Loíc Duflot presenting on abusing Intel System Management Mode when writing rootkits. We found this talk to be fascinating, but will definitely have to read the slides again and dig into our Intel manuals before fully understanding the techniques he presented.

Thursday's third talk was quite possibly the most entertaining talk of the conference. Andrea Barisani and Daniele Bianco presented two ways of remotely sniffing keystrokes with two very different methods. The first used a very simple and cheap circuit to analyze keystrokes leaked onto the buildings power wires. The second was a more intriguing approach involving yet another simple, cheap and homemade device, a laser microphone. This could let the attacker sit hundreds of meters away and listen in on the clicking sounds of a keyboard. Their signal analysis technique for the recorded keystrokes used some voice recognition algorithms and some letter pattern matching ("Wheel of Fortune" style) to determine which clicking sound corresponded to a specific key. Not to mention their hilariously well done video.

On the last day of CanSecWest, four Microsoft researchers presented on two exploit-related topics.

The first talk, by Matt Miller and Tim Burrell, provided an excellent rundown of the changes Microsoft has made to prevent exploitation of programming flaws. This talk covered /GS, /SafeSEH, and the upcoming SEHOP chain validation system. Their presentation covered not only the successes that Microsoft has had, but also the failures where existing methods were bypassed (MS08-068, MS07-017). More information from the presenters can be found on the Security Research and Defense blog.

The second talk that day, by Jason Shirk and Dave Weinstein, covered a WinDBG extension that handles the grunt work of determining whether a given crash is exploitable. This extension is valuable for anyone using fuzzers, since it provides an easy way to determine what bugs are worth investigating. Couple this extension with Byakugan and WinDBG becomes an end-to-end platform for vulnerability research and exploit development.

One of the bigger stories of the conference for the past three years has been the Pwn2Own competition, in which competitors stand to win both a laptop or mobile phone, and cash. Charlie Miller made a prediction that Safari would be the first browser to fall, and thanks to the random name draw, he had the first opportunity to attack one of the four browsers (Chrome, Firefox, IE8, and Safari). He'd obviously done his homework, and walked away with a MacBook and $5,000. As impressive as that is, the big story of Pwn2Own this year was Nils' "trifecta," in which he exploited IE8, Safari, and Firefox. Nils won a Sony Vaio, and $15,000 in prize money

Did you attend CanSecWest? What did you think?

MS09-008: Web Proxy Auto-Discovery (WPAD), Illustrated

It's not every day we get to talk about a ten year old vulnerability like it's new, but this week, Microsoft has given me just this opportunity with MS09-008, aka, "Vulnerabilities in DNS and WINS Server Could Allow Spoofing." A lot of people may not know about the role of WPAD in their desktop environment, so hopefully, this post will clear the air about what WPAD is and isn't, its sketchy security history, what MS09-008 proposes, and a quickie demo.

Amidst the global Y2k freakout in December of 1999, Microsoft released MS99-054, which purports to patch WPAD spoofing....

"Wait, what's WPAD?" you ask? Well, WPAD is a browser control protocol that allows network administrators let your browser figure out what proxy it ought to use to talk to the rest of the world. For IE, this functionality is on by default, and IE asks about WPAD with a DHCP request when it's first enabled. If it doesn't find one there, then it asks DNS.

Oh, and there's no cryptographic security at all built in to WPAD. DNS (or, more rarely, DHCP) tells your browser where to fetch the wpad.dat file... which is really just a series of Javascript directives to configure your browser for you... silently... without any real guarantee about where it came from aside from a DNS name.

Well, this is a bit of a problem, thanks to some built-in recursive searching. See, if your browser -- which is determined to reconfigure itself based on some unauthenticated guy's say-so -- couldn't find a machine called "wpad.site.yourcompany.com," it would ask about "wpad.yourcompany.com." Lucky for users of the time, it wouldn't automatically try to hit wpad.com, who could be anybody (but is in reality a nice guy named Duane Wessels). Unlucky for the fine people at haggisunlimited.co.uk, Internet Explorer thought that "co.uk" was still one step away from the world at large. Legend has it, Microsoft fixed that up in December of 1999. Also according to rumor and heresay, Microsoft fixed it again in 2005 (after some people got phished by wpad.org.uk), and later published a frank and useful KB article about the vagaries of DNS and WPAD around 2007.

So this week, the whole matter is finally behind us, right? Surely, the MS09-008 patch is going to be the end of this heady, devil-may-care decade of trusting DNS with auto-configuring proxy settings, right?

Sadly, not quite. MS09-008 does make it harder for a local attacker to sneak a new A record into your local DNS via a WINS registration, so that's good. But we're still relying on DNS to give us a trustworthy source for proxy configuration -- and that trust is really based on nothing. DNS spoofing and cache poisoning has been all the rage lately -- heck, MS09-008 also lumps in a couple more fixes to Windows DNS precisely for a couple spoofing attacks CVE-2009-0223 and CVE-2009-0224). Color me jaded, but I somehow doubt these are the last tricks we're going to pull out of DNS's hat.

Don't get me wrong; automatically configuring a proxy is not, in and of itself, a Bad Idea. It's plenty clever. It's just more clever when it's part of a DHCP request (which is baked in to Internet Explorer). At least that's somewhat more limited to a local(ish) network -- after all, if the adversary can compromise your local DHCP service, he can just hand you an evil gateway and monkey with all your traffic, not just web traffic. It would be more clever if the wpad.dat config file could be cryptographically signed in the same way that other critical paths are, like VPN connections. But for my money, it would be the cleverest of all if there was a way to force your browser to trust only WPAD information if and only if it's signed by some specific entity. At least, then, if something goes horribly, horribly wrong with DNS (ahem), users still will get a red button to ignore when they get an evil wpad.dat.

"Hey, where's my demo?" I hear you ask. Never fear, I didn't forget. So here we go, the magic of untrustable proxy configuration, just in case you're curious and haven't seen it in action. For this, you'll have to trust me... and some anonymous person in China who I've never met, since we're going to use his open proxy that he's advertising to the world. Hey, you can't back out now, you were the one rhetorically complaining in the first place. But, to make it fair, I won't give you screenshots of each button click -- honestly, performing the below without knowing what you're getting into is a Very Bad Idea. Oh, and since this whole problem isn't just Microsoft's bag, we'll do this thing with Firefox running on Windows XP.

First, you'll want to pretend to join my domain. Go to your Network Connections control panel, then navigate to TCP/IP Properties: Advanced, and add the domain "example.classself.com" to your DNS search order and as your DNS suffix. Hit OK, and close that out. Mind the spelling -- three es's.

Next, open up Firefox, and navigate to Edit: Preferences: Settings: Advanced: Network: Settings, and click on the "Auto-detect proxy settings." button. Hit okay, close that out.

Fire up Firefox again, and go to http://www.ipv6.org -- it should proudly tell you that you're visiting from "121.22.29.185," which is exactly the proxy that I just set for you. (I knew IPv6 was good for something!) If you don't believe me, you can go to http://wpad.example.classself.com/wpad.dat and see for yourself. It's text/plain javascript, so it shouldn't run in your browser.

Now, go log in to your PayPal account and ignore the warning about the invalid certificate... oh, I kid. That's the end of the demo. Please now, right away, uncheck your auto-proxy option, and forget that example.classself.com domain that you've pretended to join. This is a remarkably unwise networking state to be in.

Come to think of it, that last bit is good advice even if you were using WPAD legitimately before the demo. Seriously. You have no business asking strangers to proxy your web traffic for you, unless a) it's absolutely required by your local network, and b) you have a promise from your network administrator that you'll get the WPAD goods only by DHCP, or c) that he'll at least be very careful about how he implements DNS recursive queries, and he'll mind the wpad server like a hawk.

Security Evasions with the BreakingPoint TCL API

In the previous two posts on TCL, we've gone from running canned components like Routing Robot and Session Sender to running custom Attack Series with the Security component.

Today, I want to take a look at Security Evasions, explain what they are, and then show how users of the TCL API can apply evasions in their testing.

Evasions are ways an attacker modifies the traffic generated during an attack to cause network security devices to fail in the detection of the attack. They can be applied in different layers; for instance, you can perform layer-3 (IP) evasions by using IP fragmentation, setting your maximum fragment size to 64 bytes. Configuration for IP fragmentation can also accomodate changing the order the fragments are sent, overlapping the fragments in a variety of ways, having the Security component reassemble the frames according to the policy of a given operating system, and even having the client side fragments be a different size than those from the server side.

Of course, IP fragmentation isn't the only way an attacker can attempt evading detection. Evasions exist in each layer of the protocol stack, and they can be applied to Security attacks in the BreakingPoint products individually or in concert to help users find where their IPS fails to detect attacks.

Configuring IP Fragmentation in the Attack Manager

The full list of Security evasion options are available in a couple of ways. They are listed in the BreakingPoint User Guide, which is available from BreakingPoint Systems Documentation page on StrikeCenter (authentication required). Take a look at chapter 6 under Attack Group Options for further information. An alternate way is to use the Attack Manager in the BreakingPoint GUI. The options that are available depend on the specific strikes and strikesets that you have added to your Attack Series.

Getting Back to the Code

So, now's the time to fire up the latest version of harness.tcl to follow along. This is the script that performs the initial connection to your BreakingPoint device and puts you into the interactive TCL shell. Make sure that you're running the script from the directory in which you've extracted lib.tcl, which holds some utility functions that we will need in these examples.

As you have noticed, Security Evasions are grouped together according to what protocols they affect. We've already looked at IP fragmentation, but you can also set options for Ethernet, TCP, UDP, higher-level protocols like HTTP, and even HTML.

So, lets load up the TCL harness and get started:

Here, we've named our test, and selected to use an Attack Series that targets clientside vulnerabilities. If you want to run an existing Attack Series, but are unsure the name to use, you can get a listing with the following command:

When using TCL, we setup the evasion options using nested TCL dictionaries. Most other languages call this data type a hash. Conceptually, the options we will set in this example are hierarchically ordered like this:

• TCP
• DestinationPortType = Static
• DestinationPort = 9999
• HTTP
• ServerChunkedTransfer = true
• ServerChunkedTransferSize = 100

This configuration will cause all clientside connections to be made to the server's TCP port 9999, which is useful in testing that the IPS can detect HTTP attacks that are on a port other than the standard port 80. Further, the server's responses will use HTTP chunked encoding, with a chunk size of 100 bytes. This is a good test of the IPS normalization or reassembly engine.

In TCL, this configuration is done as follows:

The set params line is just the TCL way to define a dictionary, which are key/value pairs. Again, I'm nesting multiple dictionaries. You alternately could use the TCL construct dict create. The second line makes a call to a function I've defined in lib.tcl, _paramOverridesXml. This function generates the XML that we pass to the _execXml call.

Anything You Can Do, TCL Can Do Better

With the ability to automate tests, and now with the ability to automate evasions, you can really put an IPS through its paces. You can hone in on a particular filter, and test different evasion techniques to see when detection of a particular attack fails. If you see that a filter fails when non-standard ports are used for HTTP, and you have an HTTP server that listens on a non-standard port, it might make sense to reconfigure the applicable filters to match on that port, and rerun the test again to see how detection rates change. It also makes sense to add background traffic to your test to see how performance changes with the reconfiguration of your filters.

This post shows an API function we haven't used previously, namely the _execXml method. This method is in the TCL API to allow the TCL UI to take advantage of new features that did not exist at the time the TCL API was developed. The GUI communicates with the BreakingPoint device using XML messages. If you're the kind that likes to look at lower-level stuff like this, take your favorite copy of tcpdump and filter on port 8880. You can take XML messages sent from the client, save them in a string in TCL, and use _execXML. If there is some function of the BreakingPoint GUI that doesn't exist in the TCL API, you can extend your scripts using this method call and the appropriate XML.

The code archive for this post updates the previous examples by adding the ability to add evasions to either a single strike, or a set of strikes. Please download, experiment, and post back with questions or examples of your of TCL-fu!

Security Automation With BreakingPoint TCL API

If you're building an IPS, or are running one in your organization, IPS testing is important to ensure attacks are being blocked. In my first post on the BreakingPoint TCL API, I gave just enough detail to get users running default components in the TCL API. If you take a look at the code archive for the last post, you can see that there's not much customization going on. Today I will focus on using the BreakingPoint TCL API to create targeted tests using our Security testing component.

Finding Security Attacks

If you're following along, run the harness.tcl script we mentioned previously to get connected. Then take a look at the output of this command:

 

Assuming you are running StrikePack 36110 (BreakingPoint users head to the Member's Section above) or greater, you will see a list of strikes covering the MS08-067 NetpwPathCanonicalize bug patched by Microsoft in October 2008. Unsure of what StrikePack revision you're running? You can retrieve that via the TCL API:

 

As you're digging around in the APIs, remember that the interactive shell provides usage help for all commands. If you issue $bps listStrikes -help, you'll see that you can do searches for strikes by keyword, reference, or protocol, and you can limit your searches to a particular branch of the strike tree (e.g. /strikes/exploits/browser) or to a particular depth.

Targeted Attack Series

Now that we know how to search for specific strikes, we need to build an Attack Series. An Attack Series is one or more groups of strikes that can be saved outside of any given test. Each of these groups can have optional sets of Security evasions applied to them.

Creating an Attack Series is simple:

 

When a new Attack Series is created, a default group called 'Strikes' is created.

Again, take a look at the help by issuing $attacks -help. The main method we care about is addStrike. So, taking the example search above, we can add all the NetpwPathCanonicalize strikes to an Attack Series in a very simple loop:

 

Performing the Security Test

The last step we need to get those MS08-067 strikes running is to configure a test with a security component that's set to use our Attack Series. The main difference in running a targeted Attack Series versus just running a canned Security component is to call the configure method with the attackPlan option.

 

Looking Forward to Next Time

At this point we have run the test and we can get the results and see how our IPS did at blocking the MS08-067 attacks. You did run the test thru an actual security device, right? I did, and I can say that Brand-X usually blocks the attacks. There are some tests where not all strike attempts are blocked. If that IPS were protecting an actual network, it might be worthwhile to look into that after applying the MS08-067 patch. You have applied that patch, right? Let's hope so.

The code archive for this post includes several variations on the ideas presented here. One script lists all the strikes on the system. Another script will take a single strike path as an argument and run that strike out whichever test ports you specify (that particular script got me free sushi from a customer, so please realize that gifts ARE accepted!). Another script will take multiple strike paths on stdin and create an Attack Series and test. Please take a look at the examples and post back with any code examples of your own!

Next time, I'm going to go deeper on the Security component. We're going to take a look at BreakingPoint's Security Evasions and how to work with them in the TCL API.