How to defeat the new RDP exploit — the easy way

Last Patch Tuesday, Microsoft released Security Update MS12-020 to close two recently discovered flaws in Microsoft’s implementation of RDP (Remote Desktop Protocol). One of them Microsoft labels as “critical” because it could allow hackers to obtain LocalSystem control on a Windows box with RDP enabled.

As you’ve probably heard by now, this is a high-risk situation — one that could result in an epidemic as serious as that caused by Code Red, Melissa, or SQL Slammer. Patch or remediate now!

Microsoft will help you do both. You can either install the patch or run an online Fix It script to mitigate the problem until the patch is applied. The script enables Network Level Authentication, which requires authentication before a remote system can connect.

But I have other advice. As I’ve been recommending for more than a decade, administrators should consider running Internet-connectable services on nondefault ports if possible. In this particular case, RDP should be run on some other port than port 3389.

This advice extends to other areas. Admin websites should not be run on port 80 or even 443. SSH shouldn’t be listening on port 22. Telnet hosts shouldn’t be listening on port 23. The only widespread common service I haven’t been able to get reliably working on a nondefault port is FTP: It uses ports 21 and 22 (in passive mode), and even its active mode (where you can indicate other ports) doesn’t work well through firewalls.

In RDP’s case, you can change the default port by following this guidance. When you change the default port, though, you have to indicate the nondefault port in the connection string (for example, mstsc.exe 192.168.1.12:50045).

My recommendation to change the default listening port on an enterprisewide service is often met with criticism. My central argument is this: In most cases, an enterprise can change the default listening port, which causes no problems beyond admin education and one-time reconfiguring some scripts and tools, and it significantly diminishes the risk of weaponized attack.

Although hackers and malware can use a port scanner like Nmap to find the new port, no weaponized exploits have ever done port scanning, though they easily could. That fact alone gives you a lot of protection.

Some people call this sort of recommendation “security by obscurity,” as if it were a bad thing. If you ask me, security by obscurity is one of the best defenses. Otherwise, each nation would publicize where its missiles and nuclear submarines were instead of keeping the information secret.

To me, the SQL Slammer worm is one of the best arguments for putting common services on nondefault ports. Released in 2003, it exploited nearly every possible unpatched and unprotected SQL server connected to the Internet in 10 minutes. It went off early on a Sunday morning, and by the time most admins had awakened, damage had been occurring for almost a full business day.

Basically, by the time we had wiped the crusty salt out of our eyes, it was over — then we spent the next 48 hours (or longer) trying to clean up the mess. It was a wake-up call.

No one who had enabled SQL on a nondefault port (that is, a port besides 1433 and 1434) had to do anything — other than calmly watching everyone else deal with their disasters. Those who switched ports didn’t have to clean up a huge mess. They didn’t have to rush out patches. They didn’t have exploited servers. One change with minimal operational impact and they were able to avoid tons of risk.

Certainly other mitigations work just as well, such as requiring a valid VPN connection before connecting to the service, requiring a combination of prior port contacts before enabling the service, or requiring successful authentication before the service responds (this is Microsoft’s Fix It solution), and anything else that might protect you against weaponized attacks.

But I can think of no other simple security solution that diminishes risk so effectively than changing the default port, when possible. If you follow this advice, move the port to a fairly high number, above 10,000 or 12,000, to avoid possible port conflicts with other existing services. Test all production equipment and update any needed firewalls or proxies. The readers who followed this advice in the past aren’t in a big hurry this week.