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.