Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


Microsoft Slams Windows Exploit Code Disclosure

Leaked proof-of-concept exploit code would give attackers remote-control access to an unpatched Windows PC.

Windows 8 Beta: Visual Tour
Windows 8 Beta: Visual Tour
(click image for larger view and for slideshow)
Who leaked proof-of-concept exploit code for a recently disclosed Microsoft Windows vulnerability?

Microsoft last Tuesday patched a "critical" vulnerability involving the Remote Desktop Protocol (RDP) in all versions of Windows. Since the bug could be used by attackers to remotely exploit code of their choosing on any vulnerable PC, Microsoft urged users to update their software as quickly as possible--or use a temporary mitigation tool--and warned that it was strongly likely that an exploit targeting the bug (labeled MS12-020) would hit the wild within 30 days.

Just two days later, however, proof-of-concept exploit code appeared in the wild. Already, there's a bounty--now up to $1,500--to see who can be the first to weaponize that code and add it to the popular penetration testing toolkit Metasploit. Sunday, furthermore, an anonymous user posted Metasploit plug-in code to Pastebin, though it's unclear yet whether the code works.

[ Assuming that you're already being attacked is the new mindset in the security industry. See Security's New Reality: Assume The Worst. ]

Last week, as news of the leaked proof-of-concept exploit code surfaced, accusations began flying over who had given would-be attackers a head start. Suspicion quickly fell on the HP TippingPoint Zero Day Initiative (ZDI), which offers bounties for bugs. Timing-wise, Italian security researcher Luigi Auriemma said in a blog post that he discovered the bug in May 2011 and then sold it to ZDI, which verified the flaw and notified Microsoft in August 2011. Auriemma said that he wasn't responsible for the leak.

Likewise, ZDI has been adamant that it didn't leak any information about the vulnerability. "We are 100% confident that the leaked info regarding MS12-020 did not come from the ZDI," said a Twitter post from the Zero Day Initiative. In response to follow-up criticism that there was no way the program could guarantee it hadn't been the source of the leak, ZDI said, "We have confirmation of where it did come from."

Auriemma also defended ZDI, noting that the proof-of-concept (PoC) exploit code that leaked--and which included code that he'd written--had been marked up by Microsoft. "The executable PoC was compiled in November 2011 and contains some debugging strings like MSRC11678 which is a clear reference to the Microsoft Security Response Center," he said. "In short it seems written by Microsoft for the internal tests and was leaked probably during its distribution to their 'partners' ... for the creation of antivirus signatures and so on. The other possible scenario is about a Microsoft employee as direct or indirect source of the leak. The hacker intrusion looks [to be] the less probable scenario at the moment."

By Friday, meanwhile, Microsoft said that it also suspected that the leak had involved the Microsoft Active Protections Program that shares information with security software makers. "The details of the proof-of-concept code appear to match the vulnerability information shared with [MAPP] partners," said Yunsun Wee, director of trustworthy computing for Microsoft, in a blog post. "Microsoft is actively investigating the disclosure of these details and will take the necessary actions to protect customers and ensure that confidential information we share is protected pursuant to our contracts and program requirements." In particular, he noted that anyone party to the information would have signed a non-disclosure agreement before being allowed to access the data, suggesting that there could be legal repercussions for whomever leaked the code.

Regardless of how the code leaked, patching the bug--which would give attackers full, remote access to a vulnerable PC--should now be a top IT priority. "Patch now. Now. If you can't, use the mitigation tool that Microsoft is offering--the tradeoff between requiring network authentication and the fairly high risk of RCE [remote-code execution] in the next couple of weeks is worth it," said Kurt Baumgartner, a security researcher at Kaspersky Lab, in a blog post.

The biggest threat to your company's most sensitive data may be the employee who has legitimate access to corporate databases but less-than-legitimate intentions. Follow our advice in our Defend Data From Malicious Insiders report to mitigate the risk. (Free registration required.)

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
User Rank: Apprentice
3/21/2012 | 10:24:31 PM
re: Microsoft Slams Windows Exploit Code Disclosure
This is what I consider the cost of doing business with Microsoft. Get exploited systems, reboot critical systems at least once a month, get 'enterprise' apps that crash and leak memory like there is no tomorrow - and pay dearly for it while Microsoft gives crap about it all. Dear IT managers, CIOs, and CTOs, why the heck to you keep buying Microsoft?
Andrew Hornback
Andrew Hornback,
User Rank: Apprentice
3/20/2012 | 2:00:09 AM
re: Microsoft Slams Windows Exploit Code Disclosure
Is anyone else here distressed about the timeline of these events?

Bug discovered in May 2011 (10 months ago)
Bug verified and notification delivered to Microsoft in August 2011 (7 months ago)
Microsoft develops an exploit of this bug to test with in Novermber 2011 (4 months ago)
Microsoft releases patch in March 2012.

So, for 10 months (or longer), it's possible that this bug could have been exploited without any form of remediation? Given the list of operating systems that are affected by this bug (anything you could find on a Wintel system since roughly 2002, and possibly before that since there's no mention of Windows 2000), and the criticality of this sort of bug if it were exploited, that's worrysome for me as an IT professional.

I think the big thing that a lot of CIOs out there that lean heavily on Microsoft's products in their organization are asking is "What needs to happen at Microsoft to accelerate the remediation process when a problem of this size gets put on their radar?"

Andrew Hornback
InformationWeek Contributor
Manchester United Suffers Cyberattack
Dark Reading Staff 11/23/2020
As 'Anywhere Work' Evolves, Security Will Be Key Challenge
Robert Lemos, Contributing Writer,  11/23/2020
Register for Dark Reading Newsletters
White Papers
Cartoon Contest
Write a Caption, Win an Amazon Gift Card! Click Here
Latest Comment: This comment is waiting for review by our moderators.
Current Issue
2021 Top Enterprise IT Trends
We've identified the key trends that are poised to impact the IT landscape in 2021. Find out why they're important and how they will affect you today!
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-11-27
In Ericsson BSCS iX R18 Billing & Rating iX R18, MX is a web base module in BSCS iX that is vulnerable to stored XSS via an Alert Dashboard comment. In most test cases, session hijacking was also possible by utilizing the XSS vulnerability. This potentially allows for full account takeover, or e...
PUBLISHED: 2020-11-27
In Ericsson BSCS iX R18 Billing & Rating iX R18, ADMX is a web base module in BSCS iX that is vulnerable to stored XSS via the name or description field to a solutionUnitServlet?SuName=UserReferenceDataSU Access Rights Group. In most test cases, session hijacking was also possible by utilizing t...
PUBLISHED: 2020-11-27
In cPanel before 90.0.17, 2FA can be bypassed via a brute-force approach (SEC-575).
PUBLISHED: 2020-11-27
cPanel before 90.0.17 allows self-XSS via the WHM Transfer Tool interface (SEC-577).
PUBLISHED: 2020-11-27
cPanel before 90.0.17 has multiple instances of URL parameter injection (SEC-567).