Abusing Signed Windows Drivers
The Problem
We all know the “Driver Signature Enforcement” feature in windows. This security feature won’t allow you to load unsigned drivers into the windows kernel. To bypass this protection, many attackers use vulnerable signed drivers like turla. They try to find vulnerabilities in these drivers and exploit them. What people don’t think about is the fact that it’s way simpler than finding an exploitable memory corruption bug in a software driver - sometimes the driver just exposes the functionality via DeviceIoControl and this can be used to perform malicious operations in kernel mode. the Autochk Rootkit is one example (note that it’s not signed by MS), but there are many examples. (This problem is well known, still interesting to talk about)
This problem is not really a security problem or something, it’s just a weird corner case that can be abused to do fun stuff in kernel mode without loading your own driver.
WinDivert
The WinDivert library allows developers from user mode to “capture/modify/drop network packets sent to/from the Windows network stack”. It works by installing a driver and this driver exposes an interface to do all these operations from user mode.
The Divergent payload loads this driver and uses this mechanism to block AVs from getting updates. This is really easy because the interface to the driver is documented and wrapped for your use.
Process Hacker
Another example of such a driver is the process hacker driver. This driver exposes an IOCTL interface that looks very promising.
Process hacker can be used to open a handle to a process from kernel mode or call ZwTerminateProcess. Another cool functionality is: Process hacker has an IOCTL for reading the memory of other processes. This can be abused to read the memory of processes like lsass.exe to dump credentials. This of course, can be used to bypass protections like NtReadVirtualMemory hooks and the threat intelligence ETW…
Just take an interesting product that has a driver and try to hack with it - I’m sure you start collecting them (like me;))
Prevent this?
I thought about it: Is there anything driver developers can do to prevent this abuse?
Well, a naive developer would check that the process that communicates with the driver is signed by the company. The thing is, malware developers can easily inject code into a signed process - this will bypass this check.
I thought there’s no solution to this, But then I had this idea:
- Do not allow dynamic code to be executed from the caller process (using the new windows 10 mitigation policy)
- When a request comes to your driver, check that the process does not contain injected code. (by checking that the process contains only MEM_IMAGE executable sections) and that the process contains only a list of known images.
- Existing images may be patched: hash executable sections to check if they were patched.
Sounds perfect right? - (Ignoring many other ways to inject code into a process) The attacker cannot inject code into our signed process, so he won’t be able to call the DeviceIoControl!
Think about it for a second..
Ahhh.. The attacker can do many things to bypass this protection:
- Use WriteProcessMemory to write the DeviceIoControl parameters into the address space of the target process, then use SetThreadContext() to call to DeviceIoControl. The attacker can even fake it so it looks like the actual user mode process called DeviceIoControl (by faking call stacks, we control RSP)
- Use WriteProcessMemory() to prepare a ROP chain on the stack of the user mode process. Use SetThreadContext to execute the ROP chain will call DeviceIoControl with the expected values.
Wait, what about using ObRegisterCallbacks and limiting process handle access to PROCESS_QUERY_LIMITED_INFORMATION?
Don’t be so happy, remember the attacker can utilize the power of any other signed kernel driver;
The problem is: trying to protect code that runs at the same level as you can be very hard, sometimes impossible - it’s just like playing a cat and mouse game.
If you have suggestions for other things that can prevent this abuse I will be happy to hear! 😊
Summary
Just give up, as long as you’re admin, windows is broken dudes.
The main takeaway of this article is that attackers can abuse the functionality of any signed driver as long as the attacker can control this functionality from user mode.
If you find any problem in the article I will be happy to hear, hope you enjoyed!:)
Read More: