Skip to content

Defeating Driver Singing Enforcement, Not That Much Hard!

These days everybody talks about Driver Signing Enforcement, and the ways we can bypass it. J00ru talked about the hard way, and I tell you about the easy and very long know way. What we need is just a Singed Vulnerable X64 Driver. As we know, loading drivers require administrator privilege, but these days a normal user with default UAC setting can silently achieve Admin privilege without popping up a UAC dialog.

The driver I was talking about is DCR from DriveCrypt. The X64 version is singed and is vulnerable to a write4 bug.

the latest version is not anymore vulnerable but this version still has a valid signature and that’s enough.

I think it’s obvious that you can make the whole process of escalating privilege from normal user to Admin for loading vulnerable drive ( silently with one of UAC bypass methods) and exploitation pragmatically automatic.

You can find vulnerable version of drive along the exploit at “DriveCrypt\x64\Release“.

Introducing MCEDP HoneyClient

MCEDP is a High Interaction Client Honeypot. Despite other High-Interaction honeyClients which detect malicious servers based on system changes (file system and registery modifications, invoked/killed processes, …), MCEDP uses a new approach. To accomplish this, MCEDP uses exploit detection methods to detect drive-by downloads at exploitation stage and dump malware file. Using this approach, MCEDP eliminates some limitations of current HoneyClients and improves the detection speed of High-Interaction client Honeypots.

More Info plus donwload links…

Windows Kernel Intel x64 SYSRET Vulnerability + Code Signing Bypass Bonus

UPDATE : I’ve just tested the exploit on Windows 2008 R2 SP1 x64, exploit works like a charm without any modification.

Hi again,

This time I worked on Kernel-Land a little. Microsoft Windows Kernel Intel x64 SYSRET Vulnerability (MS12-042) was only exploited by VUPEN, apparently!, But no PoC or exploit publicly available. So I decided to work on this challenge just for fun.At first glance, it was difficult to get Code-Execution but after several times struggling with Windbg I finally succeeded on triggering the bug and get code-execution.

By the way, Windbg had stupid bug on executing SWAPGS by single-stepping! I don’t really know why, but the guest VM always reboots!
I managed to get it to work with IDA Pro + GDB remote Debugging plugin after all!

So, anyway, here is the demonstration:

The shellcode disables Code Signing and will grant NT SYSTEM privilege to specified Application or already running process (PID), After successfully running exploit, I demonstrated installing an unsigned Driver (which Dbgprints “Microsoft eats it own dog food – http://en.wikipedia.org/wiki/Eating_your_own_dog_food) and granting NT SYSTEM privilege to cmd.exe .

*** WARNING: This is only a proof-of-concept, Although its programmed to be very reliable, But I won’t take any responsibility of any damage or abuse. Sorry kids!

Here are source codes.

Bypassing EMET 3.5′s ROP Mitigations

UPDATE : It seems MS was aware of this kind of bypasses, so I bypassed EMET ROP mitigations using another EMET’s implementation mistake. EMET team forget about the KernelBase.dll and left all its functions unprotected. so I used @antic0de‘s method for finding base address of kernelbase.dll at run-time, then I used VirtualProtect inside the kernelbase.dll, not ntdll.dll or krenel32.dll. you can get new exploit at the end of this post.

I have managed to bypass EMET 3.5, which is recently released after Microsoft BlueHat Prize, and wrote full-functioning exploit for CVE-2011-1260 (I choosed this CVE randomly!) with all EMET’s ROP mitigation enabled.

http://support.microsoft.com/kb/2458544

Demo:

EMET’s ROP mitigation works around hooking certain APIs (Like VirtualProtect) with Shim Engine and monitors their initialization.I have used SHARED_USER_DATA which mapped at fixed address “0x7FFE0000″ to find KiFastSystemCall address (SystemCallStub at “0x7FFE0300″), So I could call any syscall by now!By calling ZwProtectVirtualMemory’s SYSCALL “0x0D7″, I made shellcode’s memory address RWX. After this step I could execute any instruction I wanted. But to execute actual shellcode (with hooked APIs like “WinExec”) I did patched EMET to be deactivated completely. BOOM! you can use both this methods for generally bypassing EMET ROP mitigations in other exploits, all you need is to bypass ASLR.

Here is the asm code which makes EMET 3.5 deactivated  And actual exploit.

Follow

Get every new post delivered to your Inbox.