Testing exploits against systems running Microsoft EMET

November 23, 2010

In this article we test Microsoft EMET 2.0 to see how well a Windows system with EMET enabled stands up to exploitation attempts.


Testing process

We used Metasploit and searched for various application vulnerabilities that we wanted to test, but making sure that the vulnerability was due to a memory overflow of sorts (e.g. buffer, stack, heap) or memory corruption, and not due to a "flawed" or insecure application feature. With the vulnerable version of the application installed, we employed Metasploit to see if we could successfully exploit the vulnerability in order to achieve anything other than a denial of service. In some cases the exploit would simply crash the application or cause a CPU or memory usage spike that rendered the computer unusable without successfully executing the payload. In those cases we did not bother trying to get the exploit to work properly, and instead simply moved on to testing a different vulnerability. If the exploit worked successfully, we then used Microsoft EMET and configured it to protect the targeted application and tried again. In all cases regardless of success or failure, we rebooted the Windows computer and repeated the process in reverse order to confirm the results.

In other words, we concluded that EMET protected the computer whenever the following sequence was observed:

1. Successful exploitation of vulnerability without EMET
2. (Configure EMET to add application protection)
3. Unsuccessful exploitation of vulnerability when protected with EMET
4. (Reboot Computer)
5. Unsuccessful exploitation of vulnerability when protected with EMET
6. (Configure EMET to remove application protection)

7. Successful exploitation of vulnerability without EMET

The vulnerabilities that we selected were for popular applications, and we tried to stay away from vulnerabilities that were very old (e.g. disclosed over 4 years ago). In some cases there were no viable exploits in Metasploit for an application that we wanted to test.


Test setup

The attacking system we used was a Linux computer running the latest version of Metasploit Framework. The victim was a fully patched (excluding the targeted applications) Windows XP SP3 desktop. All tests were ran using an account that has administrator privileges. When EMET was enabled, all application mitigations were enabled for the targeted application. DEP was configured for Application Opt In. Antivirus was disabled. All applications were left in their default configuration.


Results: Successfully protected by EMET:


Adobe Reader 9.4: adobe_flashplayer_button vulnerability (CVE 2010-3654): Opening of malicious PDF file crafted with the Adobe Flash Player "Button" Remote Code Execution vulnerability. With EMET enabled (protecting AcroRd32.exe), Adobe Reader process terminates with message "Adobe Reader 9.4 has encountered a problem and needs to close." Payload (Windows download exec) does not succeed.

Adobe Reader 9.3.4: adobe_cooltype_sing vulnerability (CVE 2010-2883): Opening of malicious PDF file crafted with the Adobe CoolType SING Table "uniqueName" Stack Buffer Overflow vulnerability. With EMET enabled, Adobe Reader process suddenly terminates. Payload (Windows arbitrary process execution) does not succeed.

Adobe Reader 9.1: adobe_flatedecode_predictor02 vulnerability (CVE 2009-3459): Opening of malicious PDF crafted with the Adobe FlateDecode Stream Predictor 02 Integer Overflow. With EMET enabled, a message window titled "Data Execution Prevention" appears with the text "To help protect your computer, Windows has closed this program" followed by "Adobe Reader 9.1 has encountered a problem and needs to close". Disabling DEP in the EMET system settings still protects Adobe, but eliminates the DEP protection message. Payload (Windows arbitrary process execution) does not succeed.

Adobe Reader 8.1.2: adobe_geticon vulnerability (CVE 2009-0927): Opening of malicious PDF file crafted with Adobe Reader Universal (JS Heap Spray) vulnerability. With EMET enabled, Adobe Reader process suddenly terminates. Payload (Windows arbitrary process execution) does not succeed.

Internet Explorer 6: ms10_018_ie_tabular_activex vulnerability (CVE 2010-0805): Using IE6 to access a malicious web page delivering Internet Explorer Tabular Data Control ActiveX Memory Corruption. With EMET enabled, iexplore.exe process terminates with the appearance of a message window titled "Data Execution Prevention" stating "To help protect your computer, Windows has closed this program". Payload (Windows Meterpreter Reverse TCP stager) does not succeed.

Internet Explorer 6: ms10_002_aurora vulnerability (CVE 2010-0249): Using IE6 to access a malicious web page delivering Internet Explorer "Aurora" Memory Corruption. With EMET enabled, Internet Explorer suddenly terminates. Payload (Windows shell reverse_tcp connection) does not succeed.

Internet Explorer 6: msvidctl_mpeg2 vulnerability (CVE 2008-0015): Using IE6 to access a malicious web page delivering Microsoft DirectShow (msvidctl.dll) MPEG-2 Memory Corruption. With EMET enabled, Internet Explorer terminates with message "Internet Explorer has encountered a problem and needs to close". Payload (Windows meterpreter reverse_tcp connection) does not succeed.

Windows XP Server Service: ms08_067_netapi vulnerability (CVE 2008-4250): Sending a specially crafted RPC request to a Windows host vulnerable to Microsoft Server Service Relative Path Stack Corruption. With EMET enabled (protecting svchost.exe), exploit is sent but payload does not succeed (we tested Windows meterpreter bind_tcp, and Windows arbitrary process execution). Note: Given the criticality of the svchost process, we do not recommend configuring EMET to protect svchost.exe without extensive testing. Although in our tests EMET protected the system from compromise (Sysinternals Process Explorer shows dumprep.exe being spawned from svchost), certain Windows commands were no longer processed properly and the system needed to be manually reset in order to shutdown.

Sun Java JRE 1.6 update 21: java_docbase_bof vulnerability (CVE 2010-3552): Using Internet Explorer 8 to access a malicious web page delivering Sun Java Runtime New Plugin docbase Buffer Overflow. With EMET enabled (protecting iexplore.exe), IE8 host process iexplore.exe terminates twice and re-appears with window title showing "Website restore error". Payload (Windows Meterpreter reverse_tcp connection) does not succeed.

Sun Java JRE 1.5 update 21: java_setdifficm_bof vulnerability (CVE 2009-3869): Using Internet Explorer 6 (exploit did not work properly with IE8) to access a malicious Java applet within a web page exploiting the Sun Java JRE AWT setDiffICM Buffer Overflow. With EMET enabled, Internet Explorer process suddenly terminates. Payload (Windows messagebox) does not succeed. Note: Results were inconsistent. Although the exploit never worked when EMET was protecting iexplore.exe (java.dll is loaded within this process), after repeated attempts within the same session the exploit would stop working altogether even with EMET disabled.

VLC 0.9.4: videolan_tivo vulnerability (CVE 2008-4654): Using VLC to access a network resource delivering the VideoLAN VLC TiVo Buffer Overflow. With EMET enabled, produces a "VLC media player has encountered a problem and needs to close" error report pop-up, and the vlc.exe process terminates. Payload (Windows shell reverse_tcp connection) does not succeed.

Winamp 5.2.4: winamp_ultravox vulnerability (CVE 2008-0065): Using winamp to access a URL delivering the Winamp Ultravox Streaming Metadata (in_mp3.dll) Buffer Overflow. With EMET enabled, produces a "Winamp has encountered a problem and needs to close" error message, and the winamp.exe process terminates. Payload (Windows shell reverse_tcp connection) does not succeed.

mIRC 6.34: mirc_privmsg_server vulnerability (CVE 2008-4449): Using mIRC to access IRC server delivering PRIVMSG Handling Stack Buffer Overflow. With EMET enabled, mIRC process terminates with the appearance of a message window titled "Data Execution Prevention" stating "To help protect your computer, Windows has closed this program". Payload (Windows Meterpreter Reverse Ordinal TCP Stager) does not succeed.


Results: Not protected by EMET:


(None discovered yet through the testing process listed above. Please read conclusion below.)


Conclusion

Based on the small sample that we have tested so far (we have added more to this list since this article was first published, and may continue to do so), EMET seems to successfully protect applications that have memory overflow or memory corruption vulnerabilities. In all cases that we have tested, the application is terminated and the exploit does not succeed in compromising the computer. Windows Vista, Windows 7, and Windows server 2008 systems should receive superior protection with their support for ASLR and SEHOP.

It is important for all readers to understand that EMET will not protect you in all scenarios. For example an application that has an undocumented backdoor, or due to lack of input sanitization has cross-site scripting or directory traversal vulnerabilities, or that has a built-in insecure "feature" that can be abused to escalate privileges will not be protected through EMET, and will realistically only be properly mitigated through a vendor patch or by restricting access to the vulnerable service. It is worth repeating again that in some cases there were no viable exploits that met our testing criteria for an application that we wanted to test. That being said, EMET is an excellent component to add in a defence-in-depth model, we highly encourage all Windows users to install and use EMET, and we commend the EMET team at Microsoft for releasing such a tool.

Microsoft probably best summarized the purpose and limitations of EMET in their FAQ for Microsoft Security Advisory (2458511) - Vulnerability in Internet Explorer Could Allow Remote Code Execution - in which they write: "[The] security mitigation technologies [of EMET] do not guarantee that vulnerabilities cannot be exploited, but work to make exploitation as difficult to accomplish as possible. In many instances, a fully functional exploit that can bypass EMET may never be developed."1


Originally posted October 14, 2010


1. "Microsoft Security Advisory (2458511)", Microsoft, November 3, 2010