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 :-/
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:
Once the clock rolls to the scheduled time, you will be presented with that which you desire, a shiny new SYSTEM privileged session.