Defeating EMET 5.2

[Nytro]

Defeating EMET 5.2

Since my last post, i thought if Malware Bytes Anti Exploit can be bypassed in a targetted attack why not work on bypassing EMET using rop chains. But truth be told EMET has tons of good protections which render a lot of methods useless and this form of bypass was only because of my lack of focus/ability to find a combined loophole in all current epxloit mitigations.

Idea is, If an exploit author gets to study a system before making his move he/she can defeat the protections. Reading up on articles which claim to bypass EMET before, i came to conclusion that most of the bypasses revolve around the nature of current exploit.

If its a flash exploit people can use the already existing bromium suggested stack switching mechanism to thwart stack pivot mitigation. Then do something else to bypass other checks.

If its a flash exploit people can use a public sample to jump into a call VirtualProtect ... retn gadget to thwart caller checks of EMET. Then do something to bypass other checks.

These checks can be bypassed individually but combined, they are a force to be reckoned with.

Although we have seen exploits like 2014-0515 being used to bypass earlier versions of EMET, these exploits come but once in time.

TLDR: EMET 5.2 can be bypassed with ease by jumping past its hooks using simple ROP

19th March 2015 Addition: I've bypassed EMET's protections with generic ROP too, no need to specifically target now. However i am not releasing the POC.

Only effective bypass up until now for EMET was the one which offensive security guys did.

offsec EMET 5.1

While ryujin did some serious roppery, he studied the system. Got the offsets and fucked EMET to its core. I was trying the same approach before, but since the arrival of EMET 5.2 it was only a matter of time before someone reverse engineered EMET's internal structures and found out a bypass. My time was both limited and valuable, So i jumped right into it. Upon watching ollydbg's memory mapping, i saw TONS of page guards in memory.

Something told me this approach would only end in sophistication.

and i changed my approach thus manually began browsing EMET's hook handler.

While what i did cannot be constituted as a disarm, frankly even i dont know what to call it. As long as it gets my exploit in EMET running without any consequences i am good.

WinExec routine

Hook handler for WinExec

Notice the handler routine and 0x26 bytes after that?

Yep thats WinExec's replaced bytes.

jumping to

I found this was generic in my windows 8.1 x64, 7 x64. Frankly speaking i didn't check this in 32bit OS versions, Since EMET didn't work on my xp sp3 VM.

Neither did i study how EMET is doing its trampoline. The point is, we can hop these hooks with ease. Not at all difficult.

Although i figured the idea, it was not easy to develop a POC from scratch, when I am not a regular developer. I just scrutinize, borrow code chunks and get my way.

So i took offensive security's last EMET 5.1 bypass POC and ran it on a base Windows 7 x64 VM.

It didn't work because it was built for a different mshtml.dll version than the base which windows 7 comes with. I removed their rop chains and included my own which would work for base windows 7.

Exploit used is CVE-2012-1876 developed by sickness.

Rop chains as follows

Chain of command

1. we find GetModuleHandleW from IAT of mshtml.dll

2. use it to find base address of ntdll

3. add 0x1ffd8 offset for ZwProtectVirtualMemory *

4. inc register by 1 containing address of ZwProtectVirtualMemory

5. get DWORD at ZwProtectVirtualMemory + 1 in a different register

6. add these two registers. (we arrive at hook handler)

7. add 10 twice and increase this address 6 times by 1

8. jump to that while keeping stack proper aligned for its params and return address pointing to nopsled

*

First things first, i used ZwProtectVirtualMemory because if we try this on VirtualProtect, Its possible we will get burned when it calls ntdll's syscalls while doing a reverse stack walking. Since i didnt had time to check this theory out, i chose for the fastest option and fought for ZwProtectVirtualMemory which is last call from usermode to kernelmode. Since kernel32.VirtualProtect is simply a trampoline to kernelbase.VirtualProtect and msthml doesn't have pointers for kernelbase.dll i couldn't follow that lineup. I chose ntdll.

Result, It Works!

Now onto a bigger question, Why static offset for ZwProtectVirtualMemory when it will change across different OS versions.

1. you can craft this specific offset (not rop) for different targets for x86 and 64 by querying window.navigator.cpuClass from javascript. it should be undefined for win32 and x86 for win64

2. ZwProtectVirtualMemory is not present in IAT, so i had to get syscall's address somehow.

3. If i use GetProcAddress, HW breakpoint at ntdll will get triggered and for some unknown reason IE stops responding. No logs in EMET. This should work perfectly but wasn't running.

Although there are innumerable methods for replacing this hardcoded static offset and achieving reliable exploitation for all different flavours of windows running EMET 5.2. I dont think i have to give one such method in a POC so as to prevent giving out an already weaponized exploit, moreover this exploit is very specific to mshtml version as most exploits with memory leaks do.

In essence, as long as we have a reliable rop chain. We can defeat EMET using common gadgets.

Now onto the last part, we have made our shellcode RWX, only thing is changing the shellcode to make it work.

When i used Ryujin's shellcode for bind shell, it was stopped by stackpivot. I realized, since i simply skipped the hooks, i have to restore stack.

so i went ahead and did this

__asm

{

mov esp,fs:[0]

sub esp,0x1000

}

We also have to bypass EAF because shellcode will trigger that if it contains locating Exports from PEB.

so i used my previous EAF bypass Mechanism [here]

putting this stackpivot and EAF bypass together, i executed ryujin's shellcode

But it didn't work again due to caller checks.

Apparently the shellcode was from metasploit and a normal API call in metasploit goes through a handler which will resolve addresses and call the function.

So the api call was like this

__asm

{

push 0

push "calc\0"

push hash_rol_0xd_WinExec

call ebp

}

and ebp contains the address of a handler which will resolve the api address from hash and jump to it while setting up stack perfectly

jupm gadget in this handler is

__asm

{

jmp eax

}

Now get hold of this, when hook from EMET reads the return address backwards it encounters call ebp. Which is a valid api call according to the caller check.

But it also checks if ebp contains the address from where this hook was placed upon. Since ebp contains metasploit api resolution handler, and eax contains WinExec address. Caller check will fail.

So i had to craft my own shellcode which would return api address in a register rather than call api by hash.

And it worked.

POC

EMET 5.2 bypass POC

Conclusion

EMET fights tough, more than any public exploit mitigation solution out there. A lot tougher than MBAE and enterprise exploit detection products.

But if we get to study the system, its only a matter of time.

Addition: On March 19th 2015, i managed to bypass EMET's protections using GENERIC rop. So even if emet exists or not in the system the exploit works fully. However due to its more negative use than positive, i am not releasing the code. Icing on the top, this bypasses all of the enterprise exploit mitigation toolkits i've got my hands on.

Posted by r41p41 at 08:16

Sursa: http://casual-scrutiny.blogspot.in/2015_03_01_archive.html