Remote Desktop (RDP) Vulnerability

Recently, whilst I was having a chat with one of my long time friends (a couple of days just after New Year’s Day), it came to my attention that his Asset Management Business had gotten off to a bad start and wasn’t fully operational due to the fact that both his servers kept experiencing technical problems, well that’s what he told me! Due to the nature of his business he couldn’t readily access his client’s files when the need arose neither could he collaborate with them via email. This was partly because both servers hosted his clients’ files and emails and of late had been inaccessible most of the time!

Out of curiosity I decided to assist my frustrated friend. The thing that really caught my attention was the fact that he had two servers, each running Windows Server 2008 and both were not on the same network neither where they physically located on the same premises. He owned two domains from the same Internet Service Provider (ISP) and each server belonged to a separate domain. Due to the different locations he would singly access both servers via Remote Desktop (RDP).  I immediately ruled out any power related issues due to the separate physical locations. Fortunately enough, we happened to be at one of the premises (the busiest of the two) so I powered on the monitor that was already connected to the server so we could see what was happening and I was immediately greeted by a Blue Screen of Death (BSOD) error message! A BSOD is basically an error screen that appears when an operating system crashes.

See screenshot on the left. This particular server went offline the most as compared to the other one. As a self taught Penetration Tester something looked familiar, the system file in question, that had crashed in this instance had something to do with Remote Desktop “RDPWD.SYS.” I said to myself, “Wait let me not jump into any conclusions “, I had to log onto the server first to carry out further investigations, because the server had crashed I had to manually reboot it.  I logged in and went to check the System logs and of particular interest was the continuous bug check error messages that kept appearing from many different I.P Addresses. The I.P Addresses seemed to originate from Russia and China (confirmed via a DNS and Whois lookup). The error messages had been happening and appearing in the logs for more than three – four (3-4) weeks and happened randomly. Each time the error messages appeared the system would crash and just hang. See error message below:

Based on experience and my findings, my friend was a victim of the MS12-020 Microsoft Remote Desktop vulnerability. I have come across the vulnerability which was first reported early 2012. I must say it is an old vulnerability but you will be amused by how much or many systems are still vulnerable out there. The question is, how is it carried out? Below is my proof of concept.

It starts off by scanning for a machine with an open RDP Port via Nmap. In most cases, hackers run a script against multiple or a vast range of I.P Addresses and harvest all / log all systems whose Terminal Services running on Port 3389 (by default) are Open. 

Launch Nmap and proceed to follow the steps below:

 

Launch msfconsole and proceed to follow the steps below:

 

Once the module executes successfully one gets the BSOD shown earlier. Basically the machine in question, will crash! The vulnerable system will either crash and hang or crash and reboot. In our case, the earlier!

Mitigation

• Make sure your machines, that is, Computers and/or Servers have been patched against the MS12-020 Microsoft RDP vulnerability. A good starting point is Microsoft’s Security Bulletin release patch(es) – KB2621440
• Make sure your systems are configured to automatically update themselves be it directly by pulling updates from Microsoft’s website or WSUS Server. This way the latest updates are automatically downloaded, installed and hence any bugs, weaknesses or glitches that lead to the introduction of vulnerabilities are patched on time.
• If one does not need RDP to be accessible over the Internet or open to the external world, disable it!
• Change the listening port for Remote Desktop. This will help in the event that the port scanning scripts are only checking to see if the default Port 3389 is open.
• Tunnel your RDP Traffic over SSH or IPSec. By tunneling your traffic over SSH or IPSec it will help create an extra layer of encryption.
• Connect to your network via a VPN. Please note, VPNs can still be compromised but from my point of view VPNs are definitely more secure than RDP connections.  In this context I am assuming attacker is only targeting RDP.
• Use of RD Gateways is also recommended, this way you can tightly control and restrict access to RDP ports but at the same time support connections through a single gateway.
• If connecting from a fixed (source) I.P Address “allowing of specific Source I.P Address  / Address range(s)” firewall configuration can come in handy but then again assuming hacker does not spoof the traffic.

My friend was compromised partly due to the fact that he didn’t updated his Server at all. He disabled updates in the name of, “I am saving bandwidth!” a longtime ago. Ooh no!, there he goes again, this time around he mentioned the other reason he disabled updates is because “Windows updates are notorious for crippling systems!” I am not sure how he (coincidentally) had both his servers pointing to two different domains compromised continuously through the use of this vulnerability. He reckons, “Let’s just say someone was trying to sabotage his business!”.

The above vulnerability affects the following Windows versions, that is, Windows XP, Wndows 7, Windows Server 2003 and Windows Server 2008.  The MS12-020 flaw takes advantage of the maxChannelIDs field packet handling weakness, which eventually leads to a denial of service.  The vulnerability knocked Servers offline. The amount of bandwidth costs my friend saved by disabling automatic system updates is next to nothing compared to the losses he incurred due to this vulnerability. After patching up both servers and testing again, both server remained online and are still up and running. Up to this day, the servers (if they could talk) would confess that they are working overtime trying to make up for the bad festive season! Do like wise, always patch up your systems, there is no two ways about it, full stop!!!