Category Archives: Project 1 – Improve Pwnypot

Improvement of Pwnypot – Week 5 and 6

Progress of Week 5 and 6:

I kept working on the PwnypotDrv all through the week 5, however, Shahriyar told me that I shouldn’t consider a kernel-related solution, as it’s hard to deploy and it cannot be loaded without being signed on Win x64. And it cannot truly mitigate the bypassing approach, as the attacker could switch stack pointer to a normal range before calling the critical function, and then switch it back to his newly-allocated stack afterwards[1]. Honestly, I had to agree Shahriyar was right. But that means most of my work in past three weeks are not meaningful… well… I guess Shahriyar has never read my original plan or the weekly posts :p Anyway I should be more active in contacting mentors.

So here are my ‘real’ progress over the last two weeks:

# Port the syscall hooking from PwnypotDrv to Ring 3. Now I know we can hook KiFastSystemCall() in user mode to hook all syscall of a specified process. So there’s no point in using a driver.

# Finished the implementation of call validation. It includes several features like checking whether returning address in executable or not, whether the critical function is called by a legitimate caller, whether it is called or retn’ed to, etc.

# Implemented a simple forward execution engine. I used to use the codes from libem before, but I found it’s too complicated and a little too heavy for our use. Therefore I wrote a simple execution engine with a fixed stack and no shadow memory support. It works in mitigating exploitation approach like [1].

# Initialized the Git repo for my project and pushed everything onto it. It locates at https://github.com/ltfish/Pwnypot and https://github.com/ltfish/PwnypotDrv (deprecated).

# Performed several tests against my codes to make it more robust.

I’ll wait for further comments from my mentor before setting the plan for next week.

[1] http://vulnfactory.org/blog/2011/09/21/defeating-windows-8-rop-mitigation

Improvement of Pwnypot – Week 4

Progress of Week 4:

# I tried hard to integrate SSDT hooks into Pwnypot, and almost succeeded. The following things are done.
- Some bugs are solved inside the driver.
- A reimplementation of the ValidateCallAgainstRop() function in my driver under Windows 7 32-bit.
- A daemon that handles bi-directional communication between driver and the program monitored. It will be discussed later in this post.

In this way, the exploit here is mitigated. A sample output in DbgView looks like:
ROP detected by STACK_MONITOR. Esp [0c0c0c28] out of bound stack.

# Most of the exploits are tested, and ROP chains are analyzed. mscoree.dll is a huge warehouse of gadgets! And I further tried implement the int 2eh bypassing approach in other exploits and succeeded. A big “thank you” to Shahriyar Jalayeri!

# I spent some time thinking of new bypassing approaches, but in vain. I’ll need to discuss that with my mentor later on.

The new daemon and driver communication model:

To integrate the new SSDT hooking mechanism into Pwnypot, an important step is handling the communication, which is bi-directional, between MCEDP.dll (which locates in memory space of the monitoring program) and our driver. A simple way would be, directly load the driver in our library, and communicate via DeviceIoControl. It’s a bad idea, as the target program should have enough privilege to load a driver, and we cannot really control which driver it loads. You don’t want to assign a privilege of SE_LOAD_DRIVER to your browser, do you?

Therefore I created a daemon which handles all communications between the library and our driver. The daemon provides a simple server based on named pipe, and a series of interfaces that allow our library to register a PID, revoke a PID, set different monitoring options, etc. All interfaces are synchronous to simplify the design. The communication between our daemon and driver is based on DeviceIoControl, which is pretty straight forward. Furthermore, the communication between daemon and the library as well as the one between daemon and our driver is encrypted in order to prevent unauthorized access.

Plan for Week 5:

# Tidy the codes, and finish the current implementation. Push it onto git repo.

# Discuss about new bypassing approaches with my mentor.

# Implement some other functions of ROPGuard:
- Checking the target address of returning and see if there is a call instruction preceeding to that address
- Conducting checks against other critical API calls and critical system calls besides existing ones.

Improvement of Pwnypot – Week 2 and 3

Progress of Week 2 and 3:

# I have finished the prototypes of system-call hooking under both Windows 7 32-bit and Windows 7 64-bit WOW64 mode. On Win7 32-bit I implemented a SSDT hooking driver, replacing service call entries in SSDT. There is still a few bugs inside the kernel driver, especially that I didn’t take multiple CPUs into consideration when rewriting the SSDT entry. I’ll fix that later on. On Win7 WOW64 mode, I completely reimplemented this article (thank you oxff :) ). It’s a Ring-3 intra-process hooking approach, but it’s enough for detecting any browser-related exploits – they cannot detect or restore the hooks without calling any API before, and we are already monitoring vital API calls. In this way, a bypassing method mentioned here is mitigated.

# A lot of time is spent in writing IE exploits. So it is… really difficult for me. I spent over three days in writing an exploit for CVE-2011-1260 (MS11-050) (on a clean Win7 SP1 system), but what I got eventually is just IE crashes. Countless tiny problems took me much time in debugging… Then I had to give up and flied to Seoul for SecuInside. ROP exploitation on Windows seems to be much harder than those in CTF games. Feeling really frustrated anyway.

Other things:

I met a lot of awesome guys at SecuInside Finals. Fionn from team 9447 promised to offer me some high-quality FireFox exploits with ROP payloads. So I don’t have to write and debug everything from scratch. Thanks a lot, Fionn!

By the way, I used to struggle in contacting Shahriyar Jalayeri - the original author of Pwnypot – and asking for working exploits. It seems like copying other’s homework, isn’t it? That’s why there is a great load of work in exploit development in my original version of plan. Luckily Shahriyar contacted me yesterday and eventually sent me a package of exploits. I’m more than grateful that I don’t need to write every exploit but focus more on the actual bypassing-approach implementation and project development. So I’m gonna set up corresponding environments, test those exploits in this week.

Plan for Week 4 (the current week):

# Solving the synchronization issue and fix some other bugs inside the driver.
# Integrate the two modules into Pwnypot.
# Set up the git repo and start pushing workable Pwnypot sources.
# Test the exploits, make sure they are working, and analyze how the control flow is hijacked (e.g. where the EIP is illegally modified, what the ROP chain is, etc.).

To be honest, spending five days at Seoul made me a little behind my original plan. That’s why I finish this report yesterday and post now. Sorry for that.

Improvement of Pwnypot – Week 1

I’m the guy working on improving the Pwnypot project (a.k.a MCEDP).

Progress of Week 1

# Learning how to debug and analyze IE-targeted exploits. Though I have done some work about ’gnireenigne’, I have never analyzed a browser-related exploit before. I picked MS09-002(CVE-2009-0075, exploit-db) as a start. It’s not that difficult as I thought before, but a lot of time was still wasted in getting familiar with the relations between real JavaScript objects and the assembly code. Anyway I’m almost done with the analysis.
# In progress: a prototype of Ring 3 System-Call-Hooking under Windows 7 32-bit.

Plan for Week 2

# Finish the debugging and analysis of MS06-057.
# Finish the System-Call-Hooking prototype under Windows 7 32-bit.
# Gather some known exploits of IE that have ROP involved and test them.

I’ll be away from work from July 1st to July 4th for the Secuinside CTF finals. Sorry for that, as I didn’t think we could make it to the finals when I applied the GSoC. Hope all my effort on IE exploit analysis could help me do better in those CTF exploits :D