RDP and the Critical Server Attack Surface
MS12-020, a use-after-free discovered by Luigi Auriemma, is roiling the Information Security community something fierce. That’s somewhat to be expected — this is a genuinely nasty bug. But if there’s one thing that’s not acceptable, it’s the victim shaming.
As people who know me, know well, nothing really gets my hackles up like blaming the victims of the cybersecurity crisis. “Who could possibly be so stupid as to put RDP on the open Internet”, they ask. Well, here’s some actual data:
On 16-Mar-2012, I initiated a scan across approximately 8.3% of the Internet (300M IPs were probed; the scan is ongoing). 415K of ~300M IP addresses showed evidence of speaking the RDP protocol (about twice as many had listeners on 3389/tcp — always be sure to speak a bit of the protocol before citing connectivity!)
Extrapolating from this sample, we can see that there’s approximately five million RDP endpoints on the Internet today.
Now, some subset of these endpoints are patched, and some (very small) subset of these endpoints aren’t actually the Microsoft Terminal Services code at all. But it’s pretty clear that, yes, RDP is actually an enormously deployed service, across most networks in the world (21767 of 57344 /16’s, at 8.3% coverage).
There’s something larger going on, and it’s the relevance of a bug on what can be possibly called the Critical Server Attack Surface. Not all bugs are equally dangerous because not all code is equally deployed. Some flaws are simply more accessible than others, and RDP — as the primary mechanism by which Windows systems are remotely administered — is a lot more accessible than a lot of people were aware of.
I think, if I had to enumerate the CSAS for the global Internet, it would look something like (in no particular order — thanks Chris Eng, The Grugq!):
- HTTP (Apache, Apache2, IIS, maybe nginx)
- Web Languages (ASPX, ASP, PHP, maybe some parts of Perl/Python. Maybe rails.)
- TCP/IP (Windows 2000/2003/2008 Server, Linux, FreeBSD, IOS)
- XML (libxml, MSXML3/4/6)
- SSL (OpenSSL, CryptoAPI, maybe NSS)
- SSH (OpenSSH, maybe dropbear)
telnet (bsd telnet, linux telnet)(not enough endpoints)- RDP (Terminal Services)
- DNS (BIND9, maybe BIND8, MSDNS, Unbound, NSD)
- SNMP
- SMTP (Sendmail, Postfix, Exchange, Qmail, whatever GMail/Hotmail/Yahoo run)
I haven’t exactly figured out where the line is — certainly we might want to consider web frameworks like Drupal and WordPress, FTP daemons, printers, VoIP endpoints and SMB daemons, not to mention the bouillabaisse that is the pitiful state of VPNs all the way into 2012 — but the combination of “unfirewalled from the Internet” and “more than 1M endpoints” is a decent rule of thumb. Where people are maybe blind, is in the dramatic underestimation of just how many Microsoft shops there really are out there.
We actually had the opposite situation a little while ago, with this widely discussed bug in telnet. Telnet was the old way Unix servers were maintained on the Internet. SSH rather completely supplanted it, however — the actual data revealed only 180K servers left, with but 20K even potentially vulnerable.
RDP’s just on a different scale.
I’ve got more to say about this, but for now it’s important to get these numbers out there. There’s a very good chance that your network is exposing some RDP surface. If you have any sort of crisis response policy, and you aren’t completely sure you’re safe from the RDP vulnerability, I advise you to invoke it as soon as possible.
(Disclosure: I do some work with Microsoft from time to time. This is obviously being written in my personal context.)
Dan Kaminsky's Blog 
Thanks, this is a really good post with some great information (which is what I’d expect from you).
It’s been hard to get a real grip on how serious this is. All the “Conficker 2.0” stories are overhyping and, in doing so, creating a risk around failing to understand the true severity of it. I admit I’ve been skeptical about the severity of this, but this really helps me to gauge it better.
Reblogged this on lava kafle kathmandu nepal.
Hey Dan,
Nice post, but I do have to ask you about the “Who could possibly be so stupid as to put RDP on the open Internet” statement.
In my cases, I do have a firewall+IDS in front of the RDP/TS sever, and it is intelligent enough to block brute force attacks. I do need to run RDP/TS because of the amount of remote workers we have, but simply, can’t implement a VPN solution on wich the can VPN in and then RDP into the RDP/TS console for reasons I can’t disclose 😦
I believe that is the case of many many many professionals out there.
And, as far as my knowledge of the issue goes, based on microsoft recommendation ( http://support.microsoft.com/kb/925876 ), there was no clear indication that RDP should not be exposed to the internet (expect when it was blocked, so you should be using TS gateway).
So, in your opinion, should we now go back to IT admins and tell them “You should no open 3389 do iNet anyways, so you are d*mb ass prick… and that’s why we got hacked” or should be say “Sh*t happens, use VPN from now on, because RDP+AD+NLA ( http://technet.microsoft.com/en-us/library/cc732713.aspx ) it’s not secure by itself?
Look forward to your reply….
Hello Douglas,
First, to be very clear, I’m not calling any IT professionals stupid. Some people were assuming this problem only affected a few sites that were badly administered, when as you know all too well, it’s a much bigger issue.
My immediate guidance is to apply the patch. I’m not sure about long term guidance, yet. Come back in a few days.
What we have been advising is to apply the patch to all at risk assets, review the status of all at risk assets (are they patched, do they have AV, are they being pen and/or vulnerability tested, are there other issues like out of date backup software, etc….), minimize the attack surface, apply a second layer of security controls and monitor the logs and access of any at risk systems.
Do you have any additional guidance?
Hello Dan
Have You scanned just 3389 port, or all port range, while looking for RDP listhener?
thx
Send SYN to all IPs.
Log all SYN|ACKs.
To any IP I received a SYN|ACK from, three way handshake, and send the RDP hello.
If I get a reasonable RDP response, it’s counted.
Great post Dan – what about sites who have 3389 open but restricted to specific source addresses, presumably these are ‘safe’ except for attacks originating from those sources? *Not me by the way* – Also what this highlights is the importance of locking down from install, NLA is not new but how many people are only just turning it on?
Cheers!
Restricting sites to specific source IPs shouldn’t be that effective, but in practice it does help. Note that if any one node in your cluster gets hit, everything — including stuff 100% behind the firewall — is smashed.
I have no visibility into NLA vs. non NLA deployment rates, alas.
Great initial survey work Dan. In order of bang-for-buck: #1 block in-bound RDP to desktops at firewall. #2 Make exceptions for those who then complain based on source IP. #3 Turn off RDP access on machines. #4. Patch.
I wonder the breakdown of your survey on home machines vs enterprise networks. I’m going to venture a guess home machines pre-dominate, but I’ve stopped being surprised on lack of security for enterprise network. For an enterprise network, any access to desktops should be via VPN in any case.
Thanks! Yeah, I had lots of interpretation I was going to throw onto to this data, and may yet still, but I wanted to get the raw survey data out ASAP.
I actually suspect that there’s a lot of enterprise RDP, in the same way there’s lots of enterprise SSH. It’s just the default mechanism for Microsoft shops, for those not deploying TS Gateway at least…
Check out http://www.rdpcheck.com to test your IP address
Very nice passive technique to scan especially if you are in a country which might consider scanning IP ranges (ore any IP) “hacking”.
Hey Dan, I know it’s crazy, but have you considered scanning for hosts listening on RDP on non-standard ports like 80/tcp and 443/tcp? We recently implemented egress filtering in my organization only allow these ports outbound. So some of our “IT guys” complained to me because they had to change their home RDP listeners to 80 or 443 😦
Interesting idea.
Note there’s a non-standard port of Windows Home Server and Windows Small Business server – http://social.technet.microsoft.com/wiki/contents/articles/922.windows-home-server-router-setup.aspx#Manual_Router_Configuration has it on 4125 and WHS/SBS will happy use uPNP to open that port on your router and forward it to the exposed service.
So true of Joe Gatt’s reply. There is another point on using PAT on external firewalls later then translate to respective 3389/tcp hosts. While Dan’s research gave us brief overview on how vulnerable RDP on internet, we still have to know there are always more underlying issues.
It’s a base of 5M or so. I wouldn’t be surprised if there’s a hundred thousand RDP listeners on 443, not to mention TSG, but I’d be surprised if there were another 1-2M.
My data isn’t showing how vulnerable RDP, just that it’s exposed. Specifically it doesn’t show what is and isn’t patched.