IEPeers – A New Internet Explorer Zero Day Vulnerability
We posted an aside yesterday citing Microsoft’s recent blog post for new security advisory 981374 referencing a new zero day vulnerability in Internet Explorer versions 6 and 7. New details have emerged since, and the exploit has moved from being what was described as part of “limited targeted attacks” to being widely accessible and available as a new module for the Metasploit framework.
The major concern as always with vulnerabilities like this one is that the user needs only to visit a web site hosting the exploit to have their computer infected (there is no visible sign of a download or other user interaction required).
The vulnerability is a use after free vulnerability (memory is deallocated but then later accessed causing unexpected results such as a crash or arbitrary code execution) where an invalid reference is made to a freed pointer in the file iepeers.dll. This type of code error is fairly common, this is the second major instance of this type of error in Internet Explorer recently (with the well publicized ‘Google Aurora’ attack being associated with a similar type of code defect in the popular browser).
In terms of impact, together these two versions of IE account for approximately 20% of the browser market share. Microsoft has referenced protected mode, enabling Data Execution Prevention (DEP), and not running as a high privilege user (admin) as possible mitigating steps. While always a good idea, we’ve seen in the past methods that allow both DEP and protected mode to be bypassed. In terms of user privileges, its never a good idea to browse the Internet as a high privilege user, however user escalation vulnerabilities can be employed by the attacker once access is gained to the computer. The net of this is that the most effective mitigations available are to, if you are very concerned, temporarily use a different browser and that a patch be made available in a timely manner by Microsoft.
The Exploit
As provided by Trancer (Moshe Ben Abu) with modifications to the original that unobfusticate portions of code and remove the malware payload:
The Attack
The specific attack noticed on a web site (now down) called Topix21century.com occurs as follows:
- A user visits the web site, and a file called notes.exe or svohost.exe is downloaded and executed (drive by download).
- This executable creates two copies of itself in the /temp directory and drops a .dll file which is then injected into the process for Internet Explorer, providing back door remote access to the computer for the attacker.
- Once the attacker is in the system, he or she can perform actions as the user including attempting to escalate privileges, downloading files, etc..
- Activity was noted by McAfee where the infected system attempts to create an SSL connection to communicate with the domain: notes.topix21century.com.
Topix21century.com
The only references to this topix21century.com site we noted are links in Japanese language forums referencing pictures of women in the Japanese Self-Defense Force.
The site is hosted on ISP GoDaddy, a geolocation lookup on the IP (68.178.232.100) shows a location of Scottsdale, Arizona.
The whois for the site hosting the exploit is as follows:
Registrant:
jack lee
13block
LA, California 55462
United States
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: TOPIX21CENTURY.COM
Created on: 06-Mar-10
Expires on: 06-Mar-11
Last Updated on: 06-Mar-10
Administrative Contact:
lee, jack robertwanger@aol.com
13block
LA, California 55462
United States
(818) 581-6872 Fax --
Technical Contact:
lee, jack robertwanger@aol.com
13block
LA, California 55462
United States
(818) 581-6872 Fax --
Domain servers in listed order:
NS17.DOMAINCONTROL.COM
NS18.DOMAINCONTROL.COM
A similar registrar entry is listed for the domain hotgreenlight.com, currently a parked domain:
Registrant:
thomason lee
12block
LA, California 95512
United States
Registered through: GoDaddy.com, Inc. (http://www.godaddy.com)
Domain Name: HOTGREENLIGHT.COM
Created on: 18-Dec-09
Expires on: 18-Dec-10
Last Updated on: 18-Dec-09
Administrative Contact:
lee, thomason robert.wanger@hotmail.com
12block
LA, California 95512
United States
(626) 395-6544 Fax --
Technical Contact:
lee, thomason robert.wanger@hotmail.com
12block
LA, California 95512
United States
(626) 395-6544 Fax --
Domain servers in listed order:
NS61.DOMAINCONTROL.COM
NS62.DOMAINCONTROL.COM
McAfee and Blame? (Update 03/11)
For some silly reason, McAfee Labs is eating some blame over being transparent and informative in their Avert Labs post on Tuesday. When Israeli security researcher Moshe Ben Abu (who is a legitimate security researcher not some shadowy underworld black hat) noticed the post had a URL reference to Topix21century.com, he went and had a look at the site, analyzed how the exploit worked, and made a contribution to the Metasploit project detailing how the exploit functions.
Or put another way, he analyzed an existing exploit being used by attackers and took the time to explain it. He didn’t invent it, use it to compromise computers, or any other related black hat activity. Some will argue that he amplified its effect, something that would require an entire blog post to dispute, so we won’t get into it here.
Ryan Naraine highlights this flow, but passes no judgment on it in an article on ZD Net. Unfortunately fellow CNET journalist Elinor Mills takes it a step further, suggesting by inference (by asking McAfee to “respond”) that the anti-virus company has some culpability here, to which McAfee responded:
“McAfee Labs does not support the release of exploit code, particularly in advance of a security patch being made available. We regularly sanitize blog content to prevent providing information that might assist attackers, while at the same time providing a service to customers and the security community to help improve protection levels,” the spokesman said in a statement via e-mail. “The post in question did not contain enough information to directly lead anyone to exploit code. However, we regret that in this unique situation the post did contain details that may have given exploit writers a starting point to hunt for exploit code. Future blog posts will be subject to additional sanitization.”
Such “sanitization”, a great Orwellian word, means that blog posts will be slower to publish (going through further ‘review’ cycles) and contain a less complete picture of what has happened. Interestingly, since McAfee does not have the Amazing Kreskin working for them, they get information like everyone else, by having customers or related parties share it with them (presumably in un-sanitized form).
For anyone who hangs around in black/gray hat discussion forums, you don’t see Plato’s dialogues going on in there, but you do note that the yin side of the information security paradigm is pretty good at disseminating vulnerability information post discovery.
Worse yet, the response is contradictory, stating on one hand that the information in the post was appropriate and did not assist “attackers” (Abu is still not an attacker, so assuming they mean groups working off the Metasploit module), but then reverses itself and says they regret the post and will ’sanitize’ more in the future.
The problem is that the analysis of the exploit had a lot more to do with the analytical talent of Abu and not a whole lot to do with the somewhat refreshing transparency that has marked McAfee’s blogs since the Google Aurora incident. Unfortunately, looking at the response above, this period of valuable content may be at this corporate censored end.
Further, as Abu himself points out, he would have found the exploit code anyway regardless of any McAfee post.
Finally
The timing of this could be better for Microsoft, in that this closely follows the Aurora incident with Google that played out so publicly, and the defect is a nearly identical type of problem. That said, the saving grace for Microsoft in the retail market is that the IE 8 code is stated to not be affected, and Redmond would prefer you upgrade to the latest and greatest anyway.
The anti-virus vendors largely have the original payload on this one figured out, but unfortunately the payload can be changed as the infection vector is the thing to worry about. For that to be corrected, Microsoft will have to issue a patch. You do have the option of temporarily using another browser, or alternatively upgrading to IE version 8, which is currently reported to not be affected.
This advice is reasonable for the home user, however upgrading the browser on a large corporate network is no small thing. For that reason we advise waiting for the patch, and applying it within a shortened cycle, as in terms of vulnerabilities, remote browser exploits that require no user interaction are somewhat critical problems. As always, users should avoid links to sites they’re not familiar with, but in practice this is very difficult as almost everyone is susceptible to some form of an effective social engineering trick (a targeted phishing e-mail or IM seemingly from a friend and so forth).
Regarding the tempest in a teapot around the the McAfee Avert Labs blog post by Craig Schmugar and the responses of a tired drumbeat of worn out points around responsible disclosure, its time for some in the security industry to grow up a little bit. Transparency and the near free flow of shared information are the only way the defensive side of information security can hope to catch up to the attackers.
References
- CVE-2010-0806
- OSVDB 62810
- MSFT Security Advisory 981374
- Targeted Internet Explorer Zero-Day – McAfee Labs
- Microsoft Internet Explorer iepeers.dll use-after-free exploit
Related Posts:
- Press F1 for Help, pwned.
- The “Aurora” IE Exploit Used Against Google in Action
- Windows 7 SMB Kernel Crash Video
- Juniper Kernel Crash – scapy Code
- JUNOS (Juniper) Kernel Crash Video
Filed Under: Remote Exploit



[...] more here: IEPeers – A New Internet Explorer Zero Day Vulnerability Posted in Security News Tags: aurora, internet, internet explorer, metasploit, microsoft, [...]
[...] Praetorianprefect has written about it, the article also contains the code for the exploit, happy reading. Filed under: Cyber-Security Tags: 0day, fail, Internet Explorer, Microsoft, zero day, zeroday [...]
Does this exploit function properly on a win-98 system with IE6-SP1?
I’ve taken the example code on this page and saved it to an .htm file and tried to have FireFox and IE6 open it. Firefox does nothing, and IE6 complains that it can’t open some file. Is this what the code is supposed to do?
The code above cuts out portions and translates some of the Base64 encoding for demonstration, its not provided to be operational.
For testing you’re much better going with the Metasploit module for which a link is provided above and where you can control the payload.
Regarding Windows 98, we have no idea, it is not a platform we test on for blog articles as Microsoft ended support back in July of 2006.
Why is it a necessary condition that Microsoft continue support of win-98 as a proviso for testing exploits?
Are you aware that all IE6 rollup patches and fixes that microsoft has released for win-2k are functional on win-98? Even if Microsoft officially says they no longer support win-98, most of the patches that Microsoft releases for win-2K function just fine on win-98.
There is a continuous debate among those that still run win-98 (and there are many) regarding the functionality and vulnerability of win-98 to current malware and exploits. It would be nice if someone actually could test these exploits against win-98 and settle these arguments.
Fascinating stuff! The Romans would be amazed at how efficient their Praetorians are 2000 years past! :-)
Ok, thanks for this information.
Yes right this article is good information