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.

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.

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. 

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.

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.

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.

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.

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.

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.

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.

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