DPI Coverage Getting it Wrong
Over the past two days news has trickled out that NebuAd's CEO has resigned and the company is now suspending their web-monitoring plans. Blogs and mainstream media are not only calling this a win for online privacy, but a few have talked about how this will kill off deep packet inspection (DPI) as a technology. ZDnet's "Between the Lines" more specifically wrote:
"...it doesn’t sound like there’s a long prosperous future ahead for deep packet inspection..."
As Dennis commented on the ZDnet post, this is a bit of 'throwing the baby out with the bathwater'. DPI capabilities go way beyond marketing uses, including enhancing network security and data leak prevention. To collectively dismiss DPI because of the NebuAd example is short-sighted and a bit irresponsible.
To elaborate on these points, here are the DPI slides we shared a few weeks ago from Dennis' portion of the DPI webinar. These should be helpful for folks who are only looking at one angle of this story.
Adobe Acrobat and IE7 Are the Best of Friends
Last week, the body of a SPAM e-mail was fowarded to Full-Disclosure as evidence of a Trojan being spread via a SPAM campaign. It turns out the Trojan being downloaded and installed was the latest Gozi variant (Gozi.F), and the delivery mechanism was a recently patched bug in Adobe Acrobat wherein a PDF could instruct IE7 to resolve a URI which would leverage a bug in Windows XP and Server 2003's URI handler when using IE7 causing it to execute arbitrary commands rather than resolve a legitimate URI. The interesting bit here is that the "bug" in Adobe Acrobat appears to be expected functionality, just with a slightly different behavior for the particular URI being passed.
Within the PDF specification nearly every piece of data is an object. Among other objects such as page tree nodes and catalogs, you have objects which can describe actions to be taken. You also have triggers, which you can think of as analogous to HTML/Javascript functionality such as OnLoad, OnMouseOver, etc. All the Adobe side of this attack does is define a trigger for when a page is opened (usually the first page in the PDF document since it will be opened and displayed first by default), which when triggered calls an action. The action in question is a URI action, which simply tells the OS to resolve a URI. The exploits being found in the wild use a malformed "mailto:" URI, which is passed into Windows to handle it. This causes the URI to get resolved by the system's default "mailto:" URI handler, in this case IE7. What's also interesting about the PDF URI object is that when given a "mailto:" URI, it does not prompt the user in any way prior to attempting to resolve the URI, thus providing a convenient vector for forcing resolution of a URI without user intervention. Other PDF action types, such as "Launch", which simply launches an application, and other URI types when included in a URI action object, generally pass the user a note in class looking something like this:
The user gets no such warning when Acrobat goes to resolve a "mailto:" URI, and it passes it to the Windows shell32 function ShellExecute() to handle it, which causes it to be resolved with the system's default URI handler for the particular type of URI. I'm not going to explain in detail how XP and Server 2003 differ in their handling of URIs from other Windows OSs, as it's already been explained fairly well by Microsoft already. Instead I'll provide a short dramatization (imagine some hand puppets) depicting the exchange between the OS's ShellExecute() function (SE) and IE7 (IE7):
*** SE tries to execute the URI ***
SE: "Hi IE7, this is ShellExecute()... You're the default handler for "mailto:" URI's, so I've got a URI for you today!"
IE7: "Allright! I'll go ahead and resolve that for you. Oh but wait, it looks malformed! That's no good, I can't resolve this..."
SE: "Oh well crap... hrm. Let me try to fix that up for you."
*** SE does some majiks on the URI and tries to execute it again ***
*** SE accidentally executes arbitrary commands ***
As of this posting, the Microsoft side of this attack is currently un-patched. The advisory can be found here.
So, how does this happen you ask? Let's analyze the exploit I created in detail. Due to the way PDFs are structured, this was about the smallest PDF I could create (given some random components) that will exploit the bugs involved:
Toward the end of the file you'll find the EOF marker and just before that the offset for the Cross References table (xrefs), and before that the file trailer which indicates which object is the Root object (Object 1). The Cross References table simply provides offsets to the various objects found in the file. Chaining from the Root object (at offset 0x0013), the Root object indicates the object containing the Page Tree Root Node (Object 2), which in turn indicates that there is 1 page and which object contains that (Object 3). The Page object (offset 0x0097) is essentially a blank page with an "additional action" (the /AA indicator) which indicates the action to take is found in Object 4 and is triggered by a Page Open event (/O). Finally, Object 4 (offset 0x00d2) contains the malicious URI. The badness in this particular URI is the percent sign (%), which is what causes ShellExecture() to execute the commands following it after it tries to clean up the URI and re-resolve it after it was rejected by IE7. In most of the malicious PDF files being found in the wild, rather than just benignly executing calc.exe, they're executing cmd.exe and passing in shell commands to download additional code via FTP and then executing that. In most cases, this second stage of execution installs a Trojan, bot, or rootkit.
pdp from GNUCitizen is credited with originally finding and disclosing these bugs to the appropriate vendors. CVE-2007-5020 and BID 25748 have been assigned for tracking this vulnerability.
[EDIT: Apparently, there may now be a way to automate the opening of the PDF by simply browsing to it in IE.]