Remote Code Execution vulnerability in RDP without NLA enabled (soon to be) in the wild.

Two vulnerabilities have been discovered in Microsoft RDP with allow for Remote Code Execution. These vulnerabilities were privately reported and are not in the wild yet  but due to the attractiveness of this vulnerability to attackers, Microsoft anticipates that an exploit for code execution will be developed in the next 30 days.

Security Update MS12-020 addresses two vulnerabilities in Microsoft’s implementation of the Remote Desktop Protocol (RDP). One of the two, CVE-2012-002, is a Critical, remote code execution vulnerability affecting all versions of Windows. This blog post shares additional information with the following goals:

• To strongly encourage you to make a special priority of applying this particular update;
• To give you an option to harden your environment until the update can be applied.

Note that CVE-2012-0002 was privately reported and we are not aware of any attacks in the wild. Additionally, the remote desktop protocol is disabled by default. However, due to the attractiveness of this vulnerability to attackers, we anticipate that an exploit for code execution will be developed in the next 30 days.

We understand and appreciate that our customers often need time to evaluate and install bulletins as appropriate for their environment. For systems running RDP without Network-Level Authentication (NLA) enabled, this post includes information on a mitigation that may be applied in advance of the bulletin.

Pre-auth, network accessible, service running as SYSTEM

This issue is potentially reachable over the network by an attacker before authentication is required. RDP is commonly allowed through firewalls due to its utility. The service runs in kernel-mode as SYSTEM by default on nearly all platforms (except for one exception described below). During our investigation, we determined that this vulnerability is directly exploitable for code execution. Developing a working exploit will not be trivial – 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.

The good news is that the Remote Desktop Protocol is disabled by default, so a majority of workstations are unaffected by this issue. However, we highly encourage you to apply the update right away on any systems where you have enabled Remote Desktop.

Workaround option: Enable Network Level Authentication (NLA) on Windows Vista and later platforms

There is something you can do to substantially reduce the risk on Windows Vista and later systems where RDP is enabled: You can enable Remote Desktop’s Network Level Authentication (NLA) to require authentication before a remote desktop session is established to the remote desktop server. On systems with NLA enabled, the vulnerable code is still present and could potentially be exploited for code execution. However, NLA would require an attacker to first authenticate to the server before attempting to exploit the vulnerability.

You can find instructions to enable NLA interactively or via group policy at http://technet.microsoft.com/en-us/library/cc732713.aspx. We’ve prepared a one-click “Fix it” solution that takes a registry-based approach to enable NLA. It is a simple MSI package that enumerates each of the “listener” registry subkeys under HKLM\System\CurrentControlSet\Control\Terminal Server\WinStations and sets the “UserAuthentication” REG_DWORD to 1. The links below enable and disable NLA:

Enable NLA
Disable NLA

Microsoft Fix it 50844

Microsoft Fix it 50845

Enabling NLA will prevent older clients (including Windows XP and Windows Server 2003) from connecting, by default. NLA will not disrupt remote desktop connections initiated by Windows Vista and later versions of Windows because they support NLA by default. If you need to initiate a remote desktop protocol connection to an NLA-enabled server from a Windows XP client, you can install support for Credential Security Support Provider (CredSSP) on each connecting Windows XP client. Instructions for doing so can be found here: http://support.microsoft.com/kb/951608. You can also use this one-click Fix it solution on Windows XP SP3 clients to enable support for NLA:

Platforms and scenarios at reduced risk

Just to reiterate, remote desktop is not enabled by default and is not commonly enabled on client workstations. Additionally, there are two common scenarios where remote desktop services could be enabled but on which the vulnerability poses reduced risk.

First, servers providing Terminal Services Gateway service are not directly vulnerable to this issue. The reason is that external users connect to the TS Gateway by using RDP encapsulated in RPC over HTTPS via port 443. The TS gateway computer removes the SSL encryption from the RDP traffic and then forwards the traffic to port 3389 of the destination computer on the internal network. The Terminal Services session is then established with that destination computer, not with the TS Gateway system.

The second scenario at reduced risk is Windows Server 2008 R2 SP1 servers using the Remote Desktop feature called RemoteFX. This is a common scenario in virtualized environments. This scenario is at reduced risk because the vulnerable code is running in user-mode (not kernel-mode) with NetworkService rights (not SYSTEM rights). While NetworkService privileges are less severe than executing code as SYSTEM, it would still grant attackers an unfortunate foothold in the network – so it would be a mistake to allow this reduced risk discussion to slow your rate of bulletin application.

We are actively engaged with our MAPP partners to build network-based detection and protection signatures for this issue. The nature of this particular vulnerability should allow for strong IDS and IPS protection. So an additional scenario leading to reduced risk is to have one’s systems behind a protection product from one of our MAPP partners who has built strong detection for this issue.

Conclusion

We urge you to promptly apply this security update. We also encourage you to consider how you might harden your environment against unauthenticated, attacker-initiated RDP connections. Please let us know if you have any questions that can help you speed your deployment. You can reach out to us at switech –at- microsoft –dot- com.

Source and more: http://blogs.technet.com/b/srd/archive/2012/03/13/cve-2012-0002-a-closer-look-at-ms12-020-s-critical-issue.aspx

Similar Posts:

• Recommended antivirus or antimalware exclusions when troubleshooting Application Virtualization (App-V) client issues
• Important 2008 R2 SP1 Hyper-V Hotfix
• Vrtual Computer announced NxTop 4.
• Hyper-V 3.0 virtual machine deep-dive
• Mac-to-Windows Remote Desktop and remote command connection