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.

Risk

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
Comments
Newest First  |  Oldest First  |  Threaded View
YMOM100
50%
50%
YMOM100,
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
50%
50%
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
COVID-19: Latest Security News & Commentary
Dark Reading Staff 5/28/2020
Stay-at-Home Orders Coincide With Massive DNS Surge
Robert Lemos, Contributing Writer,  5/27/2020
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Write a Caption, Win a Starbucks Card! Click Here
Latest Comment: Can you smell me now?
Current Issue
How Cybersecurity Incident Response Programs Work (and Why Some Don't)
This Tech Digest takes a look at the vital role cybersecurity incident response (IR) plays in managing cyber-risk within organizations. Download the Tech Digest today to find out how well-planned IR programs can detect intrusions, contain breaches, and help an organization restore normal operations.
Flash Poll
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2020-11844
PUBLISHED: 2020-05-29
There is an Incorrect Authorization vulnerability in Micro Focus Service Management Automation (SMA) product affecting version 2018.05 to 2020.02. The vulnerability could be exploited to provide unauthorized access to the Container Deployment Foundation.
CVE-2020-6937
PUBLISHED: 2020-05-29
A Denial of Service vulnerability in MuleSoft Mule CE/EE 3.8.x, 3.9.x, and 4.x released before April 7, 2020, could allow remote attackers to submit data which can lead to resource exhaustion.
CVE-2020-7648
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.72.2 are vulnerable to Arbitrary File Read. It allows arbitrary file reads for users who have access to Snyk's internal network by appending the URL with a fragment identifier and a whitelisted path e.g. `#package.json`
CVE-2020-7650
PUBLISHED: 2020-05-29
All versions of snyk-broker after 4.72.0 including and before 4.73.1 are vulnerable to Arbitrary File Read. It allows arbitrary file reads to users with access to Snyk's internal network of any files ending in the following extensions: yaml, yml or json.
CVE-2020-7654
PUBLISHED: 2020-05-29
All versions of snyk-broker before 4.73.1 are vulnerable to Information Exposure. It logs private keys if logging level is set to DEBUG.