Metasploit Module Released for IE Zero Day

A Metasploit exploit module has been released for the zero-day vulnerability in Internet Explorer. The flaw has been exploited in attacks against Japanese targets, and expert think the availability of a Metasploit exploit could accelerate attacks.

It’s been 14 days since Microsoft issued an advisory and temporary mitigation for a zero-day vulnerability in Internet Explorer, one being actively exploited in the wild and called by some experts as severe a browser bug as you can have.

Yet users have since had little more to shield them from these active attacks than a Fix It tool released by Microsoft on Sept. 17. In the meantime, exploits have already taken down a number of Japanese media sites in a watering hole attack targeting government agencies and manufacturers in Japan, and have been implicated in other attacks in Asia going back further than first thought. Microsoft has yet to issue an out-of-band patch for the bug, and with Patch Tuesday a week away, it’s increasingly likely users will continue to be exposed for at least another seven days.

That approach has worked to date because known attacks have been relatively targeted and on a small scale. Yesterday, however, things may have been accelerated with the release of a Metasploit exploit module for CVE-2013-3893. If you’re a believer in HD Moore’s Law, a theory proposed by Josh Corman of Akamai that mirrors Moore’s Law of computing in that casual attacker power grows at the rate of Metasploit, then one could expect an uptick in attacks using this IE bug.

Microsoft did not respond to a request for comment, but last week in response to the attacks against the Japanese media sites, Microsoft said it was continuing to work on developing and testing a security update and urged customers to install the Fix It.

Metasploit engineer Wei Chen wrote in a blogpost that while the exploit currently being seen in the wild targets IE 8 on Windows XP and IE 9 on Windows 7, the vulnerability is found in IE all the way back to IE 6 and the Metasploit module could be tweaked for a broader swath of targets.

Microsoft wrote in its advisory that the remote execution vulnerability is a use-after-free bug in the Microsoft HTML rendering engine in IE, and the exploit in the wild is done in javascript. It was also dependent on a Microsoft Office DLL that was not compiled with Address Space Layout Randomization (ASLR) enabled. The exploit, therefore, bypasses the ASLR memory protection by providing executable code at a known address in memory, Microsoft said. An attacker could use a hardcoded Return Oriented Programming chain to mark the pages containing shell code as executable.

Attackers could infect victims by luring them to a website hosting the malicious javascript exploit, or spike an online ad with the exploit.

According to Chen, the IE8 on XP version of the exploit targets only English, Chinese, Japanese and Korean users, unlike the Windows 7 targets.

“Instead, the exploit would try against any Windows 7 machines (IE8/IE9) as long as Office 2007 or Office 2010 is installed,” he said. “This is because the Microsoft Office Help Data Services Module (hxds.dll) can be loaded in IE, and is required to leverage Return-Oriented Programming in order to bypass DEP and ASLR, and gain arbitrary code execution.”

A number of popular Japanese media sites were compromised and were hosting the javascript exploit. IE users visiting those sites were redirected to sites hosting a version of the McRAT remote access malware, researchers at FireEye said on Sept. 23. The malware is used to exfiltrate data from a victim’s computer, and reports were that government officials and workers in high tech and manufacturing organizations had been infected.

FireEye’s Darien Kindlund told Threatpost that the javascript exploit will first determine system and browser details before serving up the correct exploit. “In this case, because the exploit covers so many versions of IE, the attackers don’t need to set up precursor logic like that in the javascript. They can deliver the same exploit (over and over) and be confident it will work,” he said.

FireEye said infected computers connect to a command and control server in South Korea over port 443; the callback traffic is unencrypted, despite its use of port 443, FireEye said, adding that a second sample it collected also connected to the same South Korean IP address. FireEye said it also discovered a handful of malicious domains also pointing to the IP in South Korea, which allowed them to make the connection to an attack against security company Bit9 this year. The same email address that registered the South Korean server also registered a domain used in the attack on the security company.

Suggested articles

biggest headlines 2020

The 5 Most-Wanted Threatpost Stories of 2020

A look back at what was hot with readers — offering a snapshot of the security stories that were most top-of-mind for security professionals and consumers throughout the year.