The New Zero-Day in Internet Exploder (Oops… Explorer)
The ride on the rollercoaster called the web security world never stops and keeps providing us, the security researches, with new challenges. Blackhole v2 that just came out last week and which was in headlines seems like a distant history since the emergence of the new zero-day in Internet Explorer at the beginning of this week (CVE-2012-4969).
Enough with the poetic mood and let's drill into the details of the zero-day:
Microsoft IE(version 9 and lower) suffers from a use-after-free vulnerability. The vulnerability is triggered when the DOM (Document Object Model) of an iframe is dynamically destroyed, for example with a "document.write()" command, and then an array of images that was created in the parent page, is referenced.
Let's have a look at some code snippets from Metasploit that were posted shortly after the zero day disclosure. The first page creates an array of images:
It also sprays the heap using the heap Lib library and includes a shellcode:
The page also includes an iframe:
The iframe includes the second half of the exploit code. First it defines some html element, say <div>aaa </div>, and after the page finishes to upload the following three steps are triggered:
This step destroys the html DOM that included the element, such as <div> in the last example. The last step references the array of images which was created on the first page:
This HTML sequence is triggering the vulnerability causing the shellcode to be executed in the context of the logged on user.
Unfortunately, attackers have started exploiting this vulnerability in the wild, and they use some additional evasion techniques which complicates detection. From the live samples we have collected, the flow is a bit different than the one on Metasploit:
- Instead of calling the iframe from the parent page, the parent page loads a flash file:
- The Flash file is quite nasty. The hackers went out their way to make researchers' lives a living hell:
The Flash file is loading an embedded Flash file (represented in bytecodes) using Load Bytes()method.
The embedded Flash file is responsible for generating an iframe – the same iframe we saw in the Metasploit code:
- The embedded Flash file is also responsible for the heap spray and for the shellcode.
- As if all the above is not enough, the "parent" Flash file is also obfuscated using Do SWF. Fun, fun…
Trustwave's Secure Web Gateway, with its multiple layers of defense, blocks Metasploit's POC with its default policy, by identifying the heap spray, the shell code and the fact that the payload is not digitally signed. SWG also blocks the currently known attacks.
In addition, Trustwave's IDS/IPS also detects and blocks malicious traffic related to this zero day.
For others who surf the web with Microsoft Internet Explorer – We recommend to disable Adobe Flash add-on or to install the Microsoft Fix it solution, until a patch is available (expected tomorrow).
Credits go to my colleagues who helped with there search of this threat: Moshe Basanchig, Anat Davidi, Arseny Levin and Rodrigo Montoro.