Why We Rated the MS12-020 Issue with RDP "Patch Now"

Published: 2012-03-13
Last Updated: 2012-03-13 20:17:26 UTC
by Lenny Zeltser (Version: 1)
17 comment(s)

Microsoft's March 2012 "Black Tuesday" announcement included the MS12-020 patch, which fixes a vulnerability in Microsoft's implementation of RDP. This vulnerability (CVE-2012-0002) could allow a remote unauthenticated attacker to execute arbitrary code on the affected system. Microsoft labeled this issue "Critical" and we assigned it our highest severity label "Patch Now" for servers. Here's why:

  • The CVE-2012-0002 vulnerability applies to most flavors of Microsoft Windows.
  • It can be exploited over the network.
  • Companies often make RDP accessible on the standard TCP port 3389 from the Internet for remote access to servers and sometimes workstations.

These factors make it very attractive for attackers to attempt reverse-engineering Microsoft's MS12-020 patch to, understand the details of the bug and craft an exploit. This will likely happen sooner than 30 days. The universal applicability of the exploit and its targetability over the Internet and internal networks might motivate the creation auto-propagating worms to capture systems quickly and efficiently.

For these reasons, we recommend applying the MS12-020 patch as quickly as practical in your environment. Until you install the patch, consider moving your RDP listeners to non-standard ports. You should also explore the applicability of Microsoft's advice to enable Remote Desktop’s Network Level Authentication (NLA). This will mitigate the problem: "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."

Lenny Zeltser

17 comment(s)


Are companies really so cheap that they would allow access to anything direct from the internet (excluding http/https/vpn/smtp/ssh; and these need their own type of protections)? I really don’t understand in this day and age anyone allowing direct access to this unless in a VPN. If they do allow that access then changing to a nonstandard port is useless… really just sit back and wait to be compromised and don’t bother doing patches.
I just don’t understand why this even has to be mentioned let alone make believe you are protecting it in the ways suggested. Just don’t do things that are so insane ;)
Would that the rest of the world thought that way. When we're looking at a possible new vendor I always wander around their public sites to see how they operate. My theory is that if you see a house with a trashed front yard, gutters hanging down and the paint peeling off, there's a real good chance the inside is taken care of the same way. So here's what the last one turned up, three weeks ago. Keep in mind this is a very large vendor to banks and other financial institutions.

An SSL certificate on a login page that expired a week earlier. Two links to a login page, one HTTP and one HTTPS but both with "Secured by VeriSign" logos. A site search engine where inputting a colon : threw a SQL error. Three different sites running Windows 2000 web servers. DNS servers that allowed zone transfers which allowed me to find their B2B systems, the ones running Windows 2000 front ends. Directory browsing enabled on one B2B web server. A domain name that expires in two days, which will fix most of their exposures. :-)

And the best? RDP exposed to the Internet revealing that the web servers are joined to a domain named CORPHQ.
naive question from a Linux (read: not Windows) guy: Is running internet-accessible RDP significantly worse than running ssh with password authentication? If so, why?
The big problem for many corporate networks is that this particular exploit is guaranteed to make it into malware exploit payloads. Once a network-internal Windows machine is compromised through the usual methods, scanning for vulnerable RDP servers is extremely easy. This affects not just internet-accessible RDP, but anything visible from the corporate network itself. This will impact networks that require VPN for RDP access, not just naked-RDP networks. q:
On a single server basis, no. However since Windows servers are typically joined to a domain or have other trust relationships or could even be a domain controller, the pivot possibilities may be a lot higher.

While Server 2008 uses a self-signed certificate for RDP, earlier ones did not so it's not exactly the same as SSH on older Windows systems.

In the example I gave, the logon dialog box told me immediately that the server was joined to a domain and probably not an isolated DMZ domain. That makes it a higher value target.
I don’t see it as a problem “The big problem for many corporate networks is that this particular exploit is guaranteed to make it into malware exploit payloads “.
My point of having proper perimeter protection and not allowing access like this “RDP” you would also have proper protection on the inside. The big problem is that in most places I have seen ignorance is bliss. Firewalls do not just protect from the outside world connecting in, it should also restrict the bad stuff INSIDE from reaching to the outside world. You need a working up to date AV system on all PCs/servers.; Web filtering for all clients. The VPN clients that you allow into your company have to be managed and monitored the same as the equipment behind the firewall. If you do allow VPN connections from external sites into your network then you restrict to specific IP destinations and services. The firewall rules from inside-> out should almost be as strict as outside->in. Definitely the default outbound (just as inbound) needs to be to deny connections. I have a nice example of a compromised company that passed the numerous audits (including PCI audits) while having been compromised. They even thought that the clients PCs were protected… leading AV vendor with protections set as advised by AV company (over 60 distinct things on one PC and actively connecting to an IRC channel for commands.). And that PC was corporate user connected through VPN, the traffic was coming in over VPN and going back out that companies main firewall to IRC. Needless to say that network admin did not keep his job very long.
Rule 1: LEARN to USE SNORT! If you think you are fine in your company… you will be surprised when you see what is actually happening.
Chris asked about SSH. If you are in any company environment no servers of any type should be outside of a firewall. If you allow anything from the outside it should be VPN, when not HTTP/HTTPS/SMTP/FTP. If you do allow any of those then they have to be to machines isolated in a DMZ. The firewall should be able to enforce SSH V2 or higher access.
In the environments I designed if you allowed VPN access then authentication has to be Certificate based or better. Forget userID/Password. Start looking at Snort output and server logs to see how many brute force attacks are happening.
You also have plenty of your at home and small business support users who will go the easiest route to access something with little, if any, consideration for security. Some have even argued that they cannot maintain/protect the environment if they cannot access it conveniently. How they do not see that argument also holding for making it more difficult for others to attack that same environment is beyond me.
I have set up systems where two firewalls are deployed and a machine sitting between them is used as bait. It will pretend to be many machines in a network using ATM connections or other means such as multiple network cards and varying services. If someone gets in they at the very least will probe the machine or one of it's false sisters, and that is how to protect your network. Expect a visitor, and greet them accordingly :-) Of course anything can be exploited but at least make it a fun game for both you and your uninvited guest. And SSH is just as vulnerable as anything else for those of you who feel safe. If someone wants in, they will get in. There is no safe.. just safer. Best, Al
There's an exploit out: http://g33ks.nl/b/2012/03/14/ms12-020-proof-of-concept/
Correction - that exploit looks suspect.

Diary Archives