StrikePack 17714 Released
StrikePack 17714 is now available to BreakingPoint customers. This StrikePack adds three new strikes covering three vulnerabilities.
StrikePack 17363 Released
StrikePack 17363 is now available to BreakingPoint customers. This StrikePack adds seven new strikes covering five vulnerabilities, six new fuzzers, and renames seven strikes in the tree.
StrikePack 17057 Released
StrikePack 17057 is now available to BreakingPoint customers. This StrikePack includes thirteen new strikes covering three vulnerabilities.
MS07-061
Another Microsoft Patch Tuesday has arrived with another set of bugs, however this Tuesday we only had one which was ranked critical and as it turns out it's the bug that I was working on last week. The advisory, given the MSB number MS07-061, refers to the issue with the way Windows XP and 2003 improperly handle URIs. The attack vector that was being used to leverage this vulnerability in the wild was a behavioral issue with Adobe Acrobat, which could be made to silently instruct the OS to resolve a "mailto" URI from within a PDF document. Incidentally, resolving a URI this way required no user intervention, which made it a perfect attack vector since many browsers will use the Adobe Reader plug-in to render PDF documents directly in the browser. I began working on reproducing the attack using this pair of bugs last week due to finding out that they were actively being exploited in the wild, thus making them fairly interesting to me. You can read my summary in a previous post of mine, Adobe Acrobat and IE7 are the Best of Friends for the full details. At the time of that analysis, Adobe had patched Acrobat so that it would no longer resolve mailto URIs silently, but of course that was only half of the problem; finding other methods of having the OS resolve malicious URIs was entirely possible. Microsoft, however, has now patched their half of the problem via today's patch.
StrikePack 16735 Released
StrikePack 16735 is now available to BreakingPoint customers. This StrikePack adds six new strikes covering six vulnerabilities.
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.]