OpenRCE: Blog

Windows Kernel Exploitation Papers

Wed, 11 Jun 2008 16:04:30 -0500

I can't remember where all I posted about this, but Kostya and I published a couple of papers today and you can find them

HERE

June 11, 2008: Exploiting Kernel Pool Overflows (Kostya Kortchinsky)

June 11, 2008: The I2OMGMT Driver Impersonation Attack (Justin Seitz)

Hope you enjoy!

Binary Protocol Dissector

Mon, 10 Dec 2007 12:58:47 -0600

Well today is the last day for the ID contest, and I am interested to see what kind of competition there is out there! Unfortunately, like a dummy, I wasn't regression testing my plugin over the past few releases. Although it was done months ago, it doesn't work now :(

Soooo.... I thought I might as well share what it is and what it does, and if by some Christmas miracle I get it working by midnight tonight it will be submitted.

The whole idea of the plugin is to be able to automate the task of reverse engineering a protocol so that you can easily translate it's structure to a block-based fuzzer (like Sulley or SPIKE).

Essentially, it has two components: mike.py and boo.py (for Monsters Inc. fans of course :))

mike.py - this hooks socket calls, and when a packet arrives it begins single-stepping and trapping all state information as the packet traverses through the process space. Using some simple heuristics, it is able to determine when the packet length and packet payload is being used by the process. A lot of logic was built in to output GDL graphs of all the information it has trapped. Using a threshold for each iteration it is able to graph deeper and deeper into the protocol.

boo.py - this is responsible for sending the packets themselves, and is to be extended so that when mike reports a hit on the packet payload (during a CMP instruction for example), boo will adjust its test packet to try to meet the protocol criteria.

So, since it's busted and I can't get some of the small niceties cleaned up I figured the minimum is to post some graphs.

Here is a graph of the first iteration against the Perforce source code repository server.

A bit anti-climactic isn't it! So let's zoom in a bit further:

Now you can see some more information! Yay! (if only I could get this bloody thing working again...ok I will stop complaining). Let's see what our second iteration looks like from a high level:

You can see the blocks that were covered previously are greyed out, so that you can drill down into your newly covered area:

So yeah, I will repost if I get it working, but that's it! A

ioctlizer 0.1 Beta Release

Fri, 07 Dec 2007 15:45:30 -0600

Hey All,

I have released a quick BETA version of my Win32 IOCTL fuzzer. A quick
overview:

ioctlizer is an attempt at fuzzing Windows IOCTL requests. It is split
into two separate tools, ioctltrap.py and ioctlizer.py.

ioctltrap - used to spawn or attach to a user-mode process that
interacts with a device (i.e. wireshark.exe). By hooking
the Win32 system calls that are required to interact with a device
driver, it builds a global test case list to be used
when fuzzing the device(s).

ioctlizer.py - used to import the trapped IOCTL/Read/Write test cases,
and begin mutating them. Easily extended mutators,
as only the most basic of mutations is included in the fuzzer itself.

A usage example is available in the source package's README. The tool is
available from Google Code:

http://code.google.com/p/ioctlizer/downloads/list

Send me some feedback, bugs, etc.

JS
jms@bughunter.ca

ps. Please be patient as I get everything checked into SVN, and do some
wiki pages.

Build Your Own Botnet with RDP

Mon, 03 Dec 2007 12:03:20 -0600

This might not be a novel thing, but I couldn't find any references to someone who had taken a look at this already. If there is prior art, then please send it to me!

So one day I was helping out a friend, let's call him Bob, and he was having a problem with a remote Windows machine. After watching him fire up his remote desktop client and enabling the sharing of "Disk Drives" (so that he could pull a log off the remote machine), I wondered what the implication was of actually setting up a file share between the two machines.

The question I had was: "What if someone owned the remote machine? What can they do from there?"

The first step was to see how the operating system reacts to a user connecting with this option enabled. The only noticeable difference between enabling the share and not enabling it was the "rdpclip.exe" process gets fired up when a share has been enabled. Let's start there.

I first attached to rdpclip.exe with a debugger, and trapped the CreateFileW() call exported from kernel32.dll. You can learn a lot about an application by just trapping this call, and monitoring the handles it returns (handles can be used for IOCTLs, files, named pipes, etc.). I then right clicked on a file on the remote machine's desktop, chose "Copy" and low and behold I got a hit in my hook.





0007EEBC   7C835B74  t[�|  /CALL to CreateFileW from kernel32.7C835B6F

0007EEC0   010100D2  Ò.  |FileName = "\\tsclient\C\DOCUME~1\Owner\LOCALS~1\Temp\_TS7.tmp\_TS1.tmp"

0007EEC4   80000000  ...�  |Access = GENERIC_READ

0007EEC8   00000000  ....  |ShareMode = 0

0007EECC   00000000  ....  |pSecurity = NULL

0007EED0   00000001|Mode = CREATE_NEW

0007EED4   00000080  �...  |Attributes = NORMAL

0007EED8   00000000  ....  \hTemplateFile = NULL

Hmmmm...what is "\\tsclient\"? On the remote machine, if you enter that path into Windows explorer, you will see ALL of the disk drives on the remote client machine. Not only that, you are able to write to the remote drive with the permissions of the logged in user. The other interesting thing is that it rides across on the established remote desktop connection, so it won't trip a firewall on the client-side when you connect back.

So what are some of the things we can do with this?

If the remote user (the RDP client) is "Administrator":

a) Overwrite anything in C:\WINDOWS\system32\ say the next time they fire up calc.exe they get compromised.
b) You could search the remote machine for vulnerable versions of say Adobe Acrobat, and then replace all of the pdf's on the filesystem with malformed files.

If the remote user is a limited account:

a) Parse all of their shortcuts on the Desktop, replace them to point to a binary that you push across the share.
c) Use the b) step above to change all of their "My Documents" to contain bad files that will ultimately compromise the system.

All of these things can easily be automated with CANVAS or other penetration testing frameworks, or even a Python interpreter and PyDbg for that matter can do this easily.

This is particularly troubling, if an attacker compromises a Windows server machine, they can lie in wait for an administrator to login and then ride back into the local administrators network without them really knowing.

So how can you build a botnet using this information?

Well, Google hackers for some time have known about people storing RDP connection files on a public webserver (bad idea). But we can leverage this; all you need to do is post a link to RDP connection file that points to a VMWare'd Windows machine that has the remote desktop service running. Everytime someone connects to your machine (presumably to steal stuff from you), you are able to ride back the channel to ultimately drop whatever binary you want on their machine. You could also easily social engineer someone into connecting to your machine, because psychologically if I am giving you access to my Windows server, I am showing you that I have some implied trust in you. It puts me in a position of vulnerability, and people will generally accept that they are the ones who hold the power, not really thinking about the implications of accessing my trusted environment.

Again maybe this is a lame hack, but HD Moore's (and Valsmith) recent works on hacking without exploits shows that these subtle architectual flaws can create useful attack vectors.

Mitigation: don't turn the option on :)

Visual Patterns for File Format Fuzzing

Fri, 02 Nov 2007 11:49:00 -0500

So, I am having a glance at Greg Conti's Book "Security Data Visualization" and I got to wondering: is there a way we could apply some of the visualization techniques to better understand how to fuzz a file?

Well I put together a Python script using PIL that essentially reads in a file, and then plots a red pixel for printable bytes and and leaves it white if its non-printable, rudimentary but works. Here are some of the results:

(This is a dll file loaded, you can see clearly the beginning structure of the dll)

(This is a MS Word document, you can clearly see the text position, as well the top and bottom portions where the best spots to fuzz are)

(This is a PDF document, because a lot of the PDF directives are plaintext you can see them clearly in this document at the top)

(This is a small MS Excel document, again its quite clear where the control structures would be located)

And here are two captures of a normal exe and the same exe that was UPX packed. Can you tell which is which?