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 thenan 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 heapusing the heapLib library and includes a shellcode:

The pagealso includes an iframe:

The iframe includes thesecond half of the exploit code. First it defines some html element, say <div>aaa </div>, and after the page finishes to upload the following threesteps are triggered:

This step destroys thehtml 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 firstpage:

This HTML sequence istriggering the vulnerability causing the shellcode to be executed in thecontext of the logged on user.

Unfortunately, attackershave started exploiting this vulnerability in the wild, and they use someadditional evasion techniques which complicates detection. From the live sampleswe have collected, the flow is a bit different than the one on Metasploit:

• Instead of calling theiframe from the parent page, the parent page loads a flash file:
  
  
  
  
• The Flash file is quitenasty. The hackers went out their way to make researchers' lives a living hell:
  
  The Flash file isloading an embedded Flash file (represented in bytecodes) using LoadBytes()method.
  
  
  
  The embedded Flash fileis responsible for generating an iframe – the same iframe we saw in theMetasploit code:
  
  
  
  
• The embedded Flash fileis also responsible for the heap spray and for the shellcode.
  
  
• As if all the above isnot enough, the "parent" Flash file is also obfuscated using DoSWF. Fun, fun…

Trustwave'sSecure Web Gateway, with its multiple layers of defense, blocks Metasploit'sPOC with its default policy, by identifying the heap spray, the shell code andthe fact that the payload is not digitally signed. SWG also blocks thecurrently known attacks.

In addition, Trustwave's IDS/IPS also detects and blocks malicious trafficrelated to this zero day.

For otherswho surf the web with Microsoft Internet Explorer – We recommend to disableAdobe Flash add-on or to install the Microsoft Fix it solution, until a patch is available (expectedtomorrow).

Credits go to my colleagues who helped with theresearch of this threat: Moshe Basanchig, Anat Davidi, Arseny Levin and RodrigoMontoro.