Internet Explorer - 2012 Last Minute 0-Day
Using Zero Days attacks at end of the year are not the most considerate thing to do for the security industry…. needless to say that the recent discovery of the attack, that was using Internet Explorer 0-day (CVE-2012-4792) found on the Council Foreign Relations (CFR) portal, has interrupted the holiday vacation of many people in the industry that had to quickly respond to the new
security threat.
Probably one of the reasons for launching new attacks during holiday periods is because of the belief that IT administrators and the security industry will be slower to respond.
The attackers have put lots of effort to evade detection and make the attack successful– first, of course, by using the zero-day (an unpatched and unknown security flow) and secondly by using evasion techniques to avoid detection by security tools. On this post I will highlight some interesting measures taken by the attackers.
From the samples we received, the html page that executes the attack didn't include the exploit code of CVE-2012-4792 itself but instead it uses AJAX to retrieve an obfuscated java script string from a file:
Figure1: Retrieving the exploit code using AJAX, deobfuscating it and executing the code using eval
This technique is mainly used for evading security tools that statically scan pages. For more details about evasion technique using AJAX please read this post.
Another interesting thing to pay attention for is the name of the file that includes the obfuscated string: "robots.txt". This file is usually used by web server owners to give instructions to web robots/crawlers about theirs sites. I assume that using a file that no one suspects and that possibly is not scanned by some security tools could be another way of evading detection.
The attackers have also used a flash file (today.SWF) to JIT-spray the memory with a shellcode. They use several techniques to circumvent ASLR and DEP protections according to the spec of the victim's machine (browser and plugins combo). They bypass ASLR, for example, using java6 MSVC71.DLL or Office hxdx.dll. The ActionScript within the flash file refers to the parent html page in order to get the data about the victim and then executes the relevant spray. This DOM-to-ActionScript interaction potentially makes some security engines lose orientation and probably fail detection.
Figure 2: ActionScript code snippet referring to the parent html page.
Microsoft has released on December 31st a fix-it tool to prevent the vulnerability from being exploited.
Customers of Trustwave Secure Web Gateway are protected against the attack used in CFR by blocking the flash file that is using the heap spray and also against the Metasploit module that was recently developed by blocking the the html page that is also spraying the memory.
I would like to thank to Arseny Levin and Moshe Basanchig for their assistance with analyzing this threat.