Critical Microsoft RDP Vulnerability

Microsoft released a patch this past “Super Tuesday” (3/13/2012) for a remotely exploitable bug in the remote desktop protocol (RDP), which is commonly used for remote access and administration of Windows operating systems. All unpatched versions of Microsoft Windows are reportedly affected. Within days of the release of the patch, proof-of-concept exploit code has been released and working exploit code is likely to follow soon. Microsoft has actually indicated that they expect working exploit code to be circulating within the next 30 days in a blog post here.

Due to the nature of this vulnerability, more press and internet buzz relating to the bug have been generated than with any Microsoft vulnerability than I can remember – perhaps even more than the “Aurora” vulnerability in Internet Explorer back in 2010 that was released as a zero-day and remained unpatched for several weeks. The biggest difference between this vulnerability and Aurora and the vast majority of other security bugs identified in Microsoft systems is that this vulnerability is remotely exploitable by an attacker without requiring the target to actually do anything such as open a malicious file or visit a malicious webpage.

It is generally considered a poor security practice to have any RDP host visible to the internet even prior to the discovery of such a vulnerability – brute-force login tools such as TSGrinder have been available for years to exploit weak passwords on RDP-enabled operating systems. An unauthenticated remote code execution vulnerability discovered in the service means that unpatched systems that are accessible from the internet will likely soon become the equivalent of putting your server out in your parking lot with a big flashing sign that says “come on and log in.” The risk does not stop with internet-facing terminal servers, either. Another logical exploit of the vulnerability would be to use it to propogate a worm throughout a networked environment a’ la NIMDA.

The good news is that patches have already been released and workstations with automatic updates enabled should be patched automatically. The bad news is that many machines rely on users to install the updates (“Remind me later” button). Servers frequently are patched manually in an enterprise environment to prevent automatic reboots and mitigate the risk of a patch taking down a mission-critical server.

The following steps can be taken to keep from getting pantsed by this bug:

  1. Patch management – if you are using a patch management solution such as WSUS (if you’re in an enterprise environment and you’re not, then you should), verify that the MS12-020 patch has been approved for distribution and check the patch status of all machines in your environment.
  2. Identify your targets – a quick nmap scan of both your internet and external IP ranges for machines listening on TCP port 3389 will narrow down the list of machines that may have the service running (nmap -sT -sV -p 3389 <IP RANGE>). Verify patching of these machines, particularly those that are accessible from the internet.
  3. Disable RDP – if you don’t need it then disable it (if you haven’t guessed by now, this is a recurring theme in my posts). In an Active Directory environment, use group policy to centrally administer which machines have RDP enabled and disabled.
  4. Secure access – even after patching the bug, it is still best practice not to have RDP directly visible through your firewall. If you must use it remotely, consider disabling direct access to the server and connect to the service through a VPN tunnel or RDP Gateway proxy.

References & Resources:
Microsoft Security Bulletin MS012-020
Technet Blog Post RE: MS12-020
Exploit proof of concept code