In early September this year Microsoft released their Enhanced Mitigation Experience Toolkit v2.0 (EMET), which includes a new “pseudo”-mitigation called Export address table Address Filter (EAF). I decided to have a look at how this mitigation attempts to prevent exploits from succeeding and how an attacker might bypass it. For people that suffer from tl;dr syndrome, I’ve put my conclusion up front:
It is my conclusion that EAF should be effective at preventing most current shellcode from executing and therefore a useful mitigation. However, it is relatively simple to bypass. Proof of concept code to do this can be found here. I expect that if EAF becomes a common mitigation, attackers will update their shellcodes to bypass it. I cannot think of any effective way in which EAF can be updated that would not be relatively simple to bypass as well.
-------------------------------------------------------------------------------------------------------------------------------
As SkyLined indicates the post was released and then pulled back...but it stayed in Google's cache and was accessible to anyone that looked for it last week. Thanks to @shazzzam for the heads up on it last week.
This bypass was all but expect by Microsoft....as stated in Page 10 of the EMET 2.0 User Guide.
Please note this is a pseudo mitigation designed to break current exploit techniques. It is not designed to break future exploits as well. As exploit techniques continue to evolve, so will EMET.EAF is just another hoop that the attacker has to jump through, just like the Heapspray Allocation migitation provided by EMET. Can they be bypassed? Sure. But you have to plan to bypass them first.
In my view, the Mandarotry ASLR feature of EMET is one of the most useful mitigations provided by the tool....but sadly, Windows XP doesn't support ASLR, so you will have to be on Windows Vista, Windows 2008 or Windows 7 to get the benefits.
No comments:
Post a Comment