The leaked exploit for a critical Remote Desktop Protocol vulnerability originated with Microsoft, a researcher says

Luigi Auriemma, the researcher who discovered a recently patched critical vulnerability in Microsoft's Remote Desktop Protocol (RDP), published a proof-of-concept exploit for it after a separate working exploit, which he said possibly originated from Microsoft, was leaked online on Friday.

Identified as CVE-2012-0002 and patched by Microsoft on Tuesday, the critical vulnerability can be exploited remotely to execute arbitrary code on systems that accept RDP connections.

Security experts have expressed concern because exploiting this vulnerability does not require authentication, which means that it can be used to create a computer worm.

However, the fact that RDP is disabled by default on Windows workstations limits the number of potential targets, so we shouldn't worry about the next Conficker, said Carsten Eiram, chief security specialist at Danish vulnerability research firm Secunia.

Even so, the vulnerability still presents an interest for attackers because the RDP service is commonly used in enterprise environments and is usually accessible through firewalls.

"This is an attractive vulnerability from an exploitation standpoint and various parties are spending significant resources on developing reliable exploits for this," Eiram said.

Creating a working exploit for the CVE-2012-0002 vulnerability is not trivial, Microsoft security engineers Suha Can and Jonathan Ness said in a blog post on Tuesday. "We would be surprised to see one developed in the next few days. However, we expect to see working exploit code developed within the next 30 days."

However, an exploit appeared earlier Friday on a Chinese file hosting website, and its creator is most likely Microsoft itself, Auriemma said. "The executable PoC [proof-of-concept exploit] was compiled in November 2011 and contains some debugging strings like MSRC11678, which is a clear reference to the Microsoft Security Response Center (MSRC)."

Furthermore, the exploit sends a special packet that is identical to the one the researcher included in his report to ZDI (Zero Day Initiative), a program that pays researchers for vulnerability reports and later shares the details with the affected vendors. Auriemma is sure it's the same packet because it contains unique elements that he added to it.

The researcher believes that Microsoft created the exploit for internal testing and then shared it with other security vendors through its Microsoft Active Protections Program (MAPP) to enable them to create attack and malware signatures.

The file might have been leaked by one of those companies or by a Microsoft employee, either directly or indirectly, Auriemma said. There is also the possibility of a hacker stealing it from Microsoft, but that's unlikely, he added.

Microsoft confirmed that the published proof-of-concept code appears to match the one shared with its MAPP partners. "Microsoft is actively investigating the disclosure of shared Microsoft Active Protections Program (MAPP) vulnerability details and will take the necessary actions to protect customers," Yunsun Wee, director of Microsoft's Trustworthy Computing Group, said via email.

In light of the unusual leak, Auriemma decided to release his original PoC exploit together with an advisory that pinpoints the vulnerability's exact location. The PoC is pretty basic, but an experienced exploit writer can modify it to achieve remote code execution, the researcher said.

"The release of a PoC does not necessarily make it easy to exploit the vulnerability, but it does provide a solid starting point," Secunia's Eiram said. "Having access to the patches already makes it possible to deduce the vulnerability details via bindiffing (i.e. comparing the patched binaries to unpatched binaries), but concluding how to trigger the vulnerability is not always so straight-forward. Having a PoC available, obviously, makes this very clear."

System administrators who haven't installed the patch for CVE-2012-0002 are strongly advised to do so, or at least to deploy one of the workarounds described by Microsoft in its MS12-020 security bulletin.