When two public exploits become a bad combo

Triple Helix · Dec 29, 2010

Posted by: Marco Giuliani

Happy holiday season from Prevx Research Labs!

We're seeing off the last days of this year, with 2010 ending a brand new year is almost upon us.

This year has been a very busy one from the perspective of security vendors: Aurora exploit, new variants of MBR rootkit, the Stuxnet earthquake along with all the 0day exploits used, TDL rootkit hitting 64 bit versions of Microsoft Windows and still there is much more to be listed.

Microsoft ended up the 2010 with an impressive December Patch Day, fixing all the 0day exploits used by Stuxnet malware along with other open vulnerabilities.

In fact, the situation at the end of 2010 can still be considered worrying, because of two 0day exploits which have been released online and have not been fixed by Microsoft yet. Furthermore both exploits, if used together, could potentially turn a happy holiday season to a nightmarish one, especially for corporate customers.

We are talking about a remote code execution and a elevation of privilege exploits, definitely a frightening combo.

The remote code execution hits Internet Explorer 6/7/8 and it is caused by a use-after-free error within the mshtml.dll library when a malformed CSS file is parsed by the browser.

The exploit code has been published on the famous Metasploit framework, making it easily available to everyone.

While on Windows Vista/7 the attack should be theoritecally mitigated by the ASLR and DEP technology, sadly this time could be different.

The exploit code is able to bypass ASLR due to the fact that it is utilizing a library exported by .NET 2.0 framework. Version 2.0 of the .NET framework is installed by default on Windows Vista and Windows 7 and the library mscorie.dll - Microsoft .NET IE MIME filter - is not marked as Dynamic Base compatible.

This means that this library is always loaded at the same base address inside Internet Explorer process (0x63F00000), providing a helping hand to the exploit to bypass ASLR technology and execute its payload.

Anyway, whether or not the exploit is able to execute its payload code, it has been executed in Microsoft Protected Mode, which means the code is running at low integrity level. Microsoft Internet Explorer 7/8 in Windows Vista/7 run by default in Protected Mode, a technology we have talked about many times in our blog posts and it is well explained by Microsoft here. If the code gets executed in Protected Mode, then the system should be mostly safe because of the limitations set by the integrity level.

So, even if the remote code execution exploit is successfully run, the payload shouldn't be able to trigger the elevation of privilege exploit we have talked about last month, because it hasn't got access to the specific registry key needed to trigger the EoP exploit.

Now the problem is escaping from Internet Explorer Protected Mode, something that shouldn't be so trivial. While at the moment there isn't any official documented way to escape from protected mode, and thus the system should be safe even if Internet Explorer is exploited, this month a team of researchers publicly released an interesting paper explaining how it could be possible to escape from Internet Explorer protected mode.

Among all the techniques exposed, some of them were already known though not publicly disclosed. Especially the one that exploits Internet Explorer Zones.

Internet Explorer organizes visited websites mainly in four zones: Internet, Intranet, Trusted Sites, Untrusted Sites. All the websites coming from internet are rendered in protected mode as well as untrusted sites, while the websites located in the intranet are not rendered in protected mode, thus the Internet Explorer process is set to medium integrity level when intranet websites are surfed.

To exploit this behavior, the local intranet zone must be enabled - which is the most common scenario in corporate clients where PCs are usually joined to a domain.

The first remote code execution exploit is run and the payload code is executed at a low integrity level, then the same payload code could set up a simple local webserver and redirects Internet Explorer to its own local website served by the webserver itself. The webserver will use the same remote code execution exploit to get executed again, this time outside the Internet Explorer Protected Mode because the webpage is being rendered as an Intranet webpage.

In a corporate scenario the malware could be now run at medium integrity level, bad enough to steal sensitive data or compromise user's data. The worst is that it could even exploit the second Elevation of Privilege exploit to elevate its privileges and gain administrative rights.

This not a such an uncommon scenario, corporate systems and network administrators should consider such kind of attacks, moreover because security policies are usually lowered during holiday season - Conficker is just one of most recent examples of how easy could be hitting corporate networks during holiday season.

How could people protect from these two exploits? There are a couple different ways that allow customers to be safe from them.

It is possible to block at the source the remote code execution exploit by installing Microsoft free tool called EMET 2.0. This security tool will tune up Microsoft Windows's security settings. ASLR will be set as mandatory, thus every library will be loaded at random base address no matter if it's marked as Dynamic Base compatible or not. This should prevent the exploit from working, because the mscorie.dll library used to bypass ASLR will be loaded at a random base address.

Moreover to protect the system against the Internet Explorer zone escalation it is possible to activate the protected mode even when rendering intranet contents. It is possible to set it up from Internet Explorer's Options, Security Tab and enable "Enable Protected Mode" check to all the security zones.

To protect the system against the elevation of privilege exploit, it's possible to download and install Prevx for free which will protect Windows by preventing the vulnerable registry key from being set.
Again, we wish you a very good and safe holiday season; we are working to make 2011 as safe as possible!
Click to expand...

http://www.prevx.com/blog/166/When-two-public-exploits-become-a-bad-combo.html

TH

trismegistos · Jan 1, 2011

Stuxnet has set a bad precedence. With its two zero day arbitrary code executions and its two zero day privilege escalation exploits.

Log in or Sign up

When two public exploits become a bad combo

Triple Helix Specialist

trismegistos Registered Member

Log in or Sign up

When two public exploits become a bad combo

Triple Helix Specialist

trismegistos Registered Member

Useful Searches