Why We Rated the MS12-020 Issue with RDP "Patch Now"
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
zeltser.com
@lennyzeltser
Comments
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 ;)
John
John
Mar 13th 2012
1 decade ago
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.
JJ
Mar 13th 2012
1 decade ago
Chris
Mar 14th 2012
1 decade ago
SysAdmin1138
Mar 14th 2012
1 decade ago
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.
JJ
Mar 14th 2012
1 decade ago
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.
John
John
Mar 14th 2012
1 decade ago
Kyle
Mar 14th 2012
1 decade ago
Al of Your Data Center
Mar 14th 2012
1 decade ago
Kevin
Mar 14th 2012
1 decade ago
Kevin
Mar 14th 2012
1 decade ago