EMET (Enhanced Mitigation Experience Toolkit) is intended to find and block software exploits. The API has 12 different mitigation profiles inside that it uses to do its job (keep your system secure). These profiles (called mitigations) prevent many of the more common techniques used by exploit developers who are looking to execute their malicious code on your system using vulnerable areas in applications. Typically these vulnerabilities are memory related and when properly used can drop malicious code into predefined memory spaces for execution. Because of this commonly used attack vector, Microsoft came up with a system that would protect the OS even if an application had this type of flaw.
The question is: what happens when a malicious application is using a non-common method of attack? Security research firm Bromium asked this question and the answer they came up with it not good news. It seems that there are a ways to bypass all of the security offered by EMET. According to Bromium one of the big issues with EMET is that it runs at the user level instead of kernel level. This makes the tool fairly ineffective at blocking a determined attack (or anyone that knows what they are doing).
One technique that can be used is as simple as modifying preexisting code that the attacker knows will pass the caller check (VirtualProtect/VirtualAlloc). For example using a known good DLL to make the call, using this simple trick gets you past all 12 mitigations. However, its function is far too limited for any advanced attack. It does show that the system can be subverted in a fairly simple way and led researchers to look a little deeper into the system. In the end they found multiple flaws that will allow truly malicious payloads to bypass EMET with very simple changes to their structure. They were able to get a Metasploit payload to work by simply rewriting it to CALL rather than JMP. By calling functions that already exist in good code (i.e. user32.dll) they can get to those locations without setting off the alarms.
In short Microsoft’s simplistic protections are only good if the attacker is using common techniques. If they push out something that uses existing system dlls, or they change the way the exploit operates, it is almost no use. End users will find themselves exposed to exploits just as if they did not have the tool installed. Bromium sent the details of their findings to Microsoft along with some suggestions on how to correct this flaw. Although Microsoft has not made any public statements we do expect them to at least try to address this issue in the near future. You can read he full white paper from Bromium here.
Tell us what you think about this in our Forum
