Skip navigation
All Places > Metasploit > Blog > 2010 > September

Originally Posted by jduck



On Friday night, I committed our exploit module which takes advantage of the vulnerability fixed in MS10-061. If you haven't seen it yet, you can find it here.


In its most egregious form, this bug allowed a guest user with print access to write arbitrary content to arbitrary files with SYSTEM privileges. That's pretty bad. However, the problem is, what should one write to to achieve code execution?


There haven't been a great deal of these types of vulnerabilities in the past. There are some ActiveX bugs where you could write a file, but the methods used to exploit those don't fit this situation. Most of those were exploited in ways that required user interaction (ie, writing to the "Startup" directory). One even takes advantage of an IE specific feature (hcp:// URI handling). However, these methods either won't work or will take a undetermined amount of time to complete :-/


We discussed writing directly to the Tasks directory, but decided against it early on. The number of fields in the job file format, especially the job signature, scared us away.


After some brainstorming, crowd-sourcing, and intense discussion, HD came up with the a very interesting technique. He found that you could, thanks to a Windows-ism, connect to a local named pipe and send data. Most RPC calls require reading a policy handle and passing it in another call. However, after a bit of MSDN searching, HD found the NetrJobAdd RPC call. This call doesn't require a policy handle, only job parameters. A successful call to it schedules a command to be executed at a specified time. Turns out, the hardest part is picking the right time. Of course, we could brute force it, but... we don't have to!  SMB, the protocol over which the printer is accessed, conveniently provides the "SystemTime" and "ServerTimeZone" during negotiation! Perfect!


We whipped up the code, gave it a test, and it worked! All this impersonation stuff got me reminiscing of the olden days. A vague memory of a bug where one Sun RPC service was used to access a vulnerability in another. Ahh, memories..


So there you have it. Now let's see the module in action.


First, prepare the target by sharing a printer. Here you can see I have shared the default "XPS Document Writer" printer.



NOTE: If the target isn't using "Simple File Sharing", a valid user account will be required to access the printer. The setting can be easily changed in Windows XP via the "Folder Options" dialog seen below.








Next, we start Metasploit and configure the necessary settings.


To the right, you can see the module launcher as seen from within the upcoming Metasploit Pro. The only thing I changed on this form was the target address. The defaults should work fine.













Clicking the "Launch Attack" button starts a new task and takes you to a view of the task as it progresses.

















At this point, you can run "at" or "schtasks" on the target machine to see if it worked. You should see something like this:










undefinedOnce the clock rolls to the scheduled time, you will be presented with that which you desire, a shiny new SYSTEM privileged session.














PS. Thanks and kudos go to troulouliou for fixing my bug with time zones! Who knew timezones could be so challenging?!

Originally Posted by jduck



The last two days have been pretty busy. I have been analyzing the latest Adobe vulnerability. It all began when HD alerted me to a post on Mila Parkour's "contagio malware dump" blog. After giving the blog post a once over, it was pretty clear that she had discovered a live sample of a previously unpublished and currently unpatched vulnerability. The clearest indicator was the screen shot of the Adobe Reader "About" dialog with dropped files showing. Great image! This most definitely piqued my interest.


As a technical person, I then re-scanned to glean the technical details. One awesome piece of information was:

--Accorinding to *REDACTED*, it is "vuln func in cooltype.dll 0x0803dcf9 due 2 incorrect parsing of TTF font and heapspray is done in JS with ROP code (bypasses DEP)"

From this single line, *REDACTED* pretty much laid it all out on the table. Opening CoolType.dll from 9.3.4 up in IDA Pro showed a function where indeed "strcat" was being used. However, I didn't have much more detail at this point, so I asked Mila for the sample via DM and went back to my previous task (working on [r]opcodedb).

An hour or so later, I noticed that Mila had responded and emailed the sample over. With the sample in hand, I proceeded to set a breakpoint and run Reader 9.3.4 with the sample as input. Sure enough, just as *REDACTED* had said, the call was strcat(stack_buf256, user_input). Knowing now just how bad the situation was, I proceeded to do a deeper inspection of the sample.

The File Itself

It appeared to be two PDF files concatenated with a commented 32-bit xor encoded PE. Further investigation showed that the two PDF files were identical except for the "%SIGNATURE: " portion appended to the second one. This could be the indication of some sort of mistake, but we'll likely never know. Since I wasn't interested in the malware portion of this sample, I only briefly glanced at the DLL and moved on.

The PDF Guts

All further analysis took place on only the first PDF within the file (the only PDF). The PDF contains 109 PDF objects, 15 pages, and around 15 fonts. It was also pointed out by @vicheck earlier in the day that the PDF contained JavaScript. Interested in what was in there, I looked closer.

The AcroJS

The document contained an AcroForm JS. That is, JavaScript that executes once a form is loaded.

After pulling the JavaScript object out and doing some fixups, I ended up with a much cleaner version as you can see here. There are several interesting points of which to take notice.

First, the exploit uses AcroJS to detect which version of Adobe Reader is being used to view the document. Which version determines which block of code will be executed next.

Second, a heap spray is used to place ROP data into memory at a guessable address. In this case the author appears to have tried for 0x0d0d0d0d, but I haven't confirmed that just yet. It prefixes the heap spray with a large "ret" sled, similar to a NOP sled, most likely in an attempt to improve reliability when transitioning between the stack bof and the ROP payload. The actual contents of the heap spray differ from one version to the next.

Third, the author uses the nice little page switch trick to navigate to a specific page within the document depending on the Adobe Reader version. This is great for exploitation, since fonts do not get parsed until a page that references them is rendered. The document contains one page for each major version that is "supported".

One odd thing I noticed, which I suspect isn't to uncommon with PDF exploits, is that there were a couple of non-obfuscated strings, some unused variables, and apparent dev/debug stubs for version 6.x and 7.x.

Finally, it is worth mentioning that if the version is too old, or the exploit fails to trigger, a message, "Please update your PDF viewer software." is presented to the user.

The Fonts

Thankfully, @vicheck had pointed out that the problem was in parsing data within the "SING" table of a TrueType font. Further investigation revealed that it was the "uniqueName" field within the SING table structure that was being used in the strcat.

I was a bit curious, so I decided to check the fonts contents for hints about where this font may have came from. I found that this was just a modified copy of the "Vera.ttf" bitstream font, which you can find all over the place. The interesting thing was that the "name" table record had been changed to "SING" and data at the specified offset had been replaced with a specially crafted "SING" table structure.

The Good (Scary?) Part

What I haven't mentioned yet, is that this exploit document does something that I haven't seen in the wild yet. This exploit works on Windows Vista and Windows 7. Unlike the previous exploits, it is not dependent on a hardcoded Windows XP syscall. Additionally, it uses a previously unpublished technique to bypass ASLR.

The gadgets that are used for this ROP payload come from a module named "icucnv36.dll". This module does not support ASLR (nor does it opt in to DEP, although that is largely irrelevant).

NOTE: The author of the exploit had to jump through some hoops to get this module loaded. I haven't determined what those hoops are at this point, but it is on my immediate TODO. I will update our exploit in SVN with that technique once I get it working.

You can protect yourself from exploits using the "icucnv36.dll" technique by using cacls to deny all access to the module. Unfortunately, there are two problems with this workaround. First, it won't prevent exploitation completely. Second, Adobe Reader may have issues opening PDF documents that legitimately need this module.


So here we are, around 24-48 hours later. Adobe has already confirmed the issue and released an advisory.

SANS released a blog. Please note that I don't believe that this is a "loud exploit". Contrary to their blog, there doesn't appear to be any good news here. Standard precautions do apply though, so don't open those PDFs!

It sure seems like the attackers are feeling the pressure of Adobe's upcoming sandbox.

Here is a summary of what I've found:

  • Vulnerability Type: Stack Buffer Overflow
  • Bypasses DEP: Yes
  • Bypasses ASLR: Yes
  • Exploit Requires JS: Yes
  • Vulnerability Requires JS: No

Filter Blog

By date: By tag: