February 23, 2016 at 22:55Vulnerability detected in EMET
FireEye specialists found a serious security flaw in the EMET tool [ 1 , 2 , 3 , 4 , 5 , 6 , 7 ], which allows you to simply disable its process protection mechanisms using its own built-in functions. The vulnerability is present in previous versions of EMET, i.e., in versions prior to current 5.5. Users of these versions are advised to upgrade EMET to the latest version.
EMET itself supports an internal mechanism for removing interceptions from the API functions of system libraries in protected processes. This function is used when it is necessary to quickly disable the process protection, the dynamic library emet.dll is responsible for its implementation. A complete protection shutdown is implemented by the DllMain handler with the unload code DLL_PROCESS_DETACH. Due to the fact that emet.dll does not intercept the kernel32! GetModuleHandleW function and does not control its behavior, it is enough for the shell code to call GetModuleHandleW to get the DLL loading address in memory and call DllMain , passing this value and unload constant to the functions.
In fact, the following call is enough to exploit the vulnerability.
BOOL WINAPI DllMain (GetModuleHandleW ("EMET.dll"), DLL_PROCESS_DETACH, NULL);
The DllMain function is the entry point to the library and, like any entry point, the DLL handles various events when it is loaded into the process and unloaded from it. The first argument is passed to it the base address of the library load, the second is an event, and the third is not used.
As a demonstration of the vulnerability, FireEye specialists took an outdated RCE exploit for CVE-2012-1876 vulnerability and added shellcode to it to disable process protection using the above call. The exploit uses ROP techniques to bypass DEP. After disabling EMET, the exploit can safely perform its functions.
www.us-cert.gov/ncas/current-activity/2016/02/23/Microsoft-Releases-Update-EMET
EMET itself supports an internal mechanism for removing interceptions from the API functions of system libraries in protected processes. This function is used when it is necessary to quickly disable the process protection, the dynamic library emet.dll is responsible for its implementation. A complete protection shutdown is implemented by the DllMain handler with the unload code DLL_PROCESS_DETACH. Due to the fact that emet.dll does not intercept the kernel32! GetModuleHandleW function and does not control its behavior, it is enough for the shell code to call GetModuleHandleW to get the DLL loading address in memory and call DllMain , passing this value and unload constant to the functions.
In fact, the following call is enough to exploit the vulnerability.
BOOL WINAPI DllMain (GetModuleHandleW ("EMET.dll"), DLL_PROCESS_DETACH, NULL);
The DllMain function is the entry point to the library and, like any entry point, the DLL handles various events when it is loaded into the process and unloaded from it. The first argument is passed to it the base address of the library load, the second is an event, and the third is not used.
As a demonstration of the vulnerability, FireEye specialists took an outdated RCE exploit for CVE-2012-1876 vulnerability and added shellcode to it to disable process protection using the above call. The exploit uses ROP techniques to bypass DEP. After disabling EMET, the exploit can safely perform its functions.
US-CERT is aware of a vulnerability in Microsoft Enhanced Mitigation Experience Toolkit (EMET) versions prior to 5.5. Exploitation of this vulnerability may allow a remote attacker to bypass or disable EMET to take control of an affected system.
US-CERT recommends users and administrators visit the Microsoft Security TechCenter (link is external) and upgrade to EMET version 5.5. For additional information, please review the FireEye threat research blog (link is external)
www.us-cert.gov/ncas/current-activity/2016/02/23/Microsoft-Releases-Update-EMET