MS12-020 RDP vulnerabilities: Patch, Mitigate, Detect

Published: 2012-03-16
Last Updated: 2012-03-17 23:46:10 UTC
by Russ McRee (Version: 1)
4 comment(s)

As a follow up to the fact the we've raised the INFOCON level to yellow for MS12-020, a step not taken lightly, it was suggested that we offer a few simple things folks can do to ensure that they're patched appropriately, as well as employ possible mitigations and detection.

Specifically, MS12-020 includes KB2671387 (Remote Code Execution - CVE-2012-0002) and KB2667402 (Denial of Service - CVE-2012-0152) or KB2621440
The reference for the update you'll see on a Windows system, when installed, depends on the version of the OS you're running. For Windows 7 you'll likely note KB2667402, whereas you should only expect KB2621440 on a Windows XP host.
Confusing, I know, but it matters. Read the full MS12-020 bulletin to confirm.
 
The simplest step to determine if you're properly updated, using Window 7 x64 as an example is: 
Start -> All Programs -> Windows Update -> View Update History and look for reference to KB2667402 as seen in Figure 1.
 
Update History
Figure 1 
 
If on a Windows XP host, using Microsoft Update, you can opt for Start -> Microsoft Update -> Review your update history and ensure KB2621440 is installed.
 
Additionally, at the command prompt, you can use Windows Management Instrumentation Command-line (WMIC) and issue:
wmic qfe | find "KB2667402" or wmic qfe | find "KB2621440"
If patched you'll note results as seen in Figure 2.
 
Figure 2
 
Mitigation
Per the bulletins, "systems that do not have RDP enabled are not at risk."
Your privileges on a given system (enterprise GPOs may prevent changes) may dictate your level of success.
Options include, aside from the obvious (PATCH):
1) Don't run RDP if you don't really need it.
Start -> Run -> services.msc -> Stop and/or disable Remote Desktop Services (Figure 3) or disable it via Control Panel
Figure 3
 
2) Use Windows Firewall (where applicable and if enabled) to prevent access to RDP (Figure 4)at the host level
Figure 4
 
3) Ensure your network security configurations don't unnecessarily allow RDP (TCP 3389) from the Internet. If you absolutely, positively must do so, restrict it to approved hosts.
 
4) Enable Network Level Authentication (NLA) on Vista and later systems. Per the SRD blog: "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."
  
Detection
Snort users can keep an eye on the likes of Emerging Threats. A rule (SID 2014384) has been included to identify a possible RDP DoS attack as described in KB2667402/CVE-2012-0152. I'm certain additional rules and detection logic are being added across the spectrum of detection options; check in with your vendor/provider accordingly.
 
Feel free to comment with methodology related to the above that works for you and thus may help others.
 
4 comment(s)

Comments

Please note on Windows 7/2k8r2 you'll see KB2667402 - and - KB2621440 offered up for this. You show both in your screen shot.
Vista/2k8 and lower only get (KB2621440).
Emerging Threats SID 2014383 detects exploit attempts against the RDP remote code execution vulnerability. At least, it will detect the PoC code that's floating around.
My servers are patched but one thing to consider is changing the listening port used for RDP (and then change firewall settings appropriately). The RDP listening port is changeable in the Registry: HKLM>System>CurrrentControlSet>Control>Terminal Server>WinStations>RDP-Tcp - change the PortNumber from 3389 to whatever TCP port you wish to use. You'll need to remember the port when you launch an RD session and put a ":whatever port number you use now" after the hostname.
Snort rules to detect ms12-020 RDP DoS attempt
http://blog.chackraview.net/2012/03/19/nids-signature-for-ms12-020-rdp-dos/

Diary Archives