A vulnerability was found in EMET
FireEye specialists discovered 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 built-in functions. Vulnerability is present in previous versions of EMET, i.e. in versions prior to current 5.5. Users of these versions are encouraged to update EMET to the latest version.
EMET itself supports an internal mechanism for removing hooks from system library API functions in protected processes. This function is used in the case when you need to quickly disable the process protection, for the implementation of which the dynamic library emet.dll is responsible. A complete protection disable is implemented by the DllMain handler with the DLL_PROCESS_DETACH unloading code. Due to the fact that emet.dll does not intercept the kernel32! GetModuleHandleW function and does not control its behavior, the shell code only needs to call GetModuleHandleW to get the DLL loading address in memory and call DllMain , passing the function this constant and unloading constant.
')
In fact, the next 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 DLL entry point, handles various events when loading it into a process and unloading it. The first argument is the base address of the library load, the second is the 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 a shell code to it to disable process protection using the above-mentioned call. To bypass DEP, the exploit uses ROP techniques. 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 hooks from system library API functions in protected processes. This function is used in the case when you need to quickly disable the process protection, for the implementation of which the dynamic library emet.dll is responsible. A complete protection disable is implemented by the DllMain handler with the DLL_PROCESS_DETACH unloading code. Due to the fact that emet.dll does not intercept the kernel32! GetModuleHandleW function and does not control its behavior, the shell code only needs to call GetModuleHandleW to get the DLL loading address in memory and call DllMain , passing the function this constant and unloading constant.
')
In fact, the next 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 DLL entry point, handles various events when loading it into a process and unloading it. The first argument is the base address of the library load, the second is the 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 a shell code to it to disable process protection using the above-mentioned call. To bypass DEP, the exploit uses ROP techniques. After disabling EMET, the exploit can safely perform its functions.
US-CERT is aware of the Microsoft Enhanced Mitigation Experience Toolkit (EMET) prior to 5.5. If you want to be able to control it
Microsoft Security TechCenter (link is external) recommends users and administrators to 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
Source: https://habr.com/ru/post/277785/
All Articles