File Format Vulnerabilities and Dynamic Exploit Generators

File format vulnerabilities make for very interesting network security device test cases. Due to their nature and how they're transported within network traffic, there are generally multiple layers of data structure, formatting, encoding, and potential obfuscation in play. Not only must you consider the file format in question's own internal structure, but quite frequently there is further embedded content within that structure. This entire file object, being it's own self-contained entity, is then potentially being sent over any number of various network transports. Because the vulnerabilities usually lie in some anomalous use of the file format's internal structure, a bad value contained within that structure, or embedded content within the file, a network security device that intends to detect this maliciousness not only needs to be able to recognize it wherever in the network packet flow it may be, but also be able to reconstruct potentially fragmented data, decode potentially encoded data, and then identify the malicious bit itself.

To better illustrate this dilemma, let's take a look at the recent ms08-033 AVI/MJPG vulnerability. AVI is essentially a RIFF file with some particular AVI-specific FourCC tagged LISTs and chunks. The vulnerability here lies in the value of the "biHeight" field within the BITMAPINFOHEADER structure, which is essentially the AVI "stream format" ("strf") chunk. This chunk is part of a "strl" LIST that describes an individual video stream contained within the file, which, along with other "strl" LISTs generally follow the main AVI header ("strh") chunk. By populating the "biHeight" field with a negative value (I had success with values -1 through -31), you can trigger the vulnerability described in the advisory and cause Windows Media Player to crash. Windows Media Player also doesn't seem to care too much about what Codec you indicate that the video stream should be processed with ("fccHandler") in the AVISTREAMHEADER. Either Windows Media Player defaults unrecognized handlers to the MJPG Codec, or it determines where to send stream data with an unrecognized handler value based on recognizing the encoding method applied to the stream data itself. Further explanation of the vulnerability can be found in a post by Mark Dowd over at ISS's Frequency X blog.

The strikes that are included in the Security component of the BreakingPoint product generally draw upon a back-end code-base that is capable of generating the various bits of data that are used during the strike's attack. For file format vulnerabilities, this back-end is usually a dynamic file generator that can generate randomized, but still valid, files of the type in question. This back-end is then coupled with individual strike descriptions which describe the parts of the attack such as various meta-data, the network connections involved, and what actual data is sent across the wire within those connections. For file format vulnerabilities, the possibilities here are endless. Due to the file being a self-contained unit, it can be sent from attacker to victim over any number of transports such as HTTP, FTP, POP3, SMTP, IMAP, peer-to-peer applications, tunneled protocols, embedded within other files, and so forth. Many of these available transports also provide for multiple types of data encoding during transport, such as SMTP's Base64, Quoted-Printable, and UUEncoded variations.

For the ms08-033 example given above, we have developed 8 different transport-and-encoding-based strikes, each of which plug into the RIFF(AVI/MJPG)-generating back-end to dynamically generate the malicious file being transferred. When you do the math on all of the permutations of the bits of data that a network security device either MUST (to properly detect the badness) or SHOULD (to avoid false positives) be included in a signature or filter for this vulnerability, not including everything else that is randomized by our RIFF-generating back-end, you end up with 1,065,151,889,408 (yes, that's just over one trillion) attack permutations, or malicious, vulnerability-triggering attacks. These attacks can be produced via the eight ms08-033 strikes that will be included in our next StrikePack. Any network security device's filters or signatures must be able to match on all of these permutations, do it reliably, and not false positive on legitimate AVI/MJPG files in order to legitimately claim coverage for this vulnerability. A daunting task indeed.

0 comments
Tags:
Post a Comment
  1. Leave this field empty

Required Field

Videos

More >


Interact





LinkedIn

YouTube

Newsletter


Subscribe to BreakingPoint Labs blog by email:

Type in your email, hit submit and quickly verify your address.