Internet Storm Center
Training
Certification
Cyber Security Graduate School
Security Awareness Training
Computer Forensics
Penetration Testing
IT Audit
Software Security
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)
Last Updated: 2012-03-13 20:17:26 UTC
by Lenny Zeltser (Version: 1)
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
Keywords:
17 comment(s)Comments
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.
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.
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.
John
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
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.
Securing SSH to only allow certain logins and IP addresses is a fairly easy task - but I cannot find a way to lock down RDP via IP addresses internally when the firewall is disabled via a GPO. I can, however, limit to certain users - but that point is fairly moot without locking down IPs as well. And there is no way I'd allow RDP to be opened up to the outside world.
I've always wondered about - based on the available tools out there - why you find Windows servers with RDP enabled and available to anyone over the Internet.
Anytime I have had a requirement to access any of my machines over the Intenet I have found it much easier to use a single port (SSH) with port forwarding to access every single device - under my control - within the data center / area. And with SSH, not only can I limit who can log on, I can limit how they can log on (with key rather than password) and set features to boot people out if the connection is inactive for a specified period of time. Additionally, securing one machine facing the Internet (the SSH gateway) is significantly easier than trying to secure EVERY machine and this also results in simpler rules within the firewall. For less tech savvy users VPN is a fine solution is a well.
Anytime I have had a requirement to access any of my machines over the Intenet I have found it much easier to use a single port (SSH) with port forwarding to access every single device - under my control - within the data center / area. And with SSH, not only can I limit who can log on, I can limit how they can log on (with key rather than password) and set features to boot people out if the connection is inactive for a specified period of time. Additionally, securing one machine facing the Internet (the SSH gateway) is significantly easier than trying to secure EVERY machine and this also results in simpler rules within the firewall. For less tech savvy users VPN is a fine solution is a well.
Does this not warrant the ISC going to yellow? I'm concerned that a lot of companies without professional infosec analysts will overlook this issue, thinking that it's just another Microsoft patch or that they're safe if 3389 is blocked at the firewall. Just because we don't see worms like Nimda, SQL Slammer and MS Blaster these days, doesn't mean it's not possible. In fact, I would argue that such a worm could be a very effective delivery mechanism for a compound threat.
If you want to lock down RDP on the machine, not a firewall, then the only solution is to install a 3rd party firewall on the windows box. Let's face it.. if you opened up remote desktop to any security connection and programmed a router, now you should be able to install a firewall on the PC if needed as well. The best practice of course is to allow RDP or any connection that can get to a command prompt only after getting in via a well encrypted certificate based VPN which can also be locked down to certain IP addresses. That is presumably secure. Again if someone wants in they'll find a way so never assume you are locked down 100%. Assume you need a good off-site backup :-)
As Phil said, a lot of companies without professional infosec help are going to be in trouble when a real exploit shows up. Having worked with a lot of small businesses in the past, I see three immediate areas this is going to impact:
1) Windows Small Business users - opens RDP by default to the net
2) Windows Home Server - yup, same deal
3) Web hosting providers - renting a Windows instance.. yup RDP is your access method
While enterprise level security should not have as much exposure (we all know many will though) this could be a huge impact for SMBs and home users.
1) Windows Small Business users - opens RDP by default to the net
2) Windows Home Server - yup, same deal
3) Web hosting providers - renting a Windows instance.. yup RDP is your access method
While enterprise level security should not have as much exposure (we all know many will though) this could be a huge impact for SMBs and home users.
Clarification of DP's comment:
SBS and Home server do not have 3389 open by default. They use rdp over RDgateway in the newer versions, and over a 443/4125 in the older. Thus neither platform by default open up straight RDP.
SBS and Home server do not have 3389 open by default. They use rdp over RDgateway in the newer versions, and over a 443/4125 in the older. Thus neither platform by default open up straight RDP.
Thanks for the correction Susan. I went back and looked at the port charts and 3389 was listed on the SBS 2003 list, which meant a lot of people opened it because they didn't understand the difference between remote web workplace and direct RDP connection. I haven't worked in the small business sector since 2006, but remember seeing that a lot.
The web hosting providers could still be a problem. RDP is used for connecting to hosted servers just as much as SSH on the Linux providers.
The web hosting providers could still be a problem. RDP is used for connecting to hosted servers just as much as SSH on the Linux providers.
New Comments closed for all Diaries older than two(2) weeks
Please send your comments to our Contact Form
Diary Archives
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