Windows 2000 Professional Terminal Services Client connecting to a vulnerable Windows 7 RDP Server:
win2k-client-target.pcap Captured on the Win 7 RDP server
win2k-client-attacker.pcap Captured on the Win 2k Terminal Services client
Windows 7 Professional Terminal Services Client connecting to a vulnerable Windows 7 RDP Server:
win7-rdp-client-target.pcap Captured on the Win 7 RDP server
win7-rdp-client-attacker.pcap Captured on the Win 7 Terminal Services client
Windows 2000 Professional Terminal Services Client connecting to a patched Windows 7 RDP Server:
win2k-client-targetp.pcap Captured on the Win 7 RDP server
win2k-client-attackerp.pcap Captured on the Win 2k Terminal Services client
Windows 7 Professional Terminal Services Client connecting to a patched Windows 7 RDP Server:
win7-rdp-client-targetp.pcap Captured on the Win 7 RDP server
win7-rdp-client-attackerp.pcap Captured on the Win 7 Terminal Services client
If you run it with a SYN scan, "-sC 3389", it FAILS:
The scan failed to detect the vulnerability, as shown:
The packet captures show the nmap port scan SYN packet receiving a SYN/ACK, as it should, but the SYN packets sent by the ms12-020-rev.nse script are all rejected with RST packets:
Here are the raw packet captures:
But if you run it with a CONNECT scan "-sT 3389", it works, finding the vulnerability reliably:
Here are the raw packet captures:
Here are the raw packet captures:
And now the scan correctly reports that the target is vulnerable again:
Here are the raw packet captures:
RT @dakami: @sambowne @ea_foundation Does this script safely detect the vuln w/o crashing the box, on multiple OSs?
RT @ea_foundation: @dakami @sambowne no one reported that it crashed the machine, but i would recommend torrough testing, before running it on production sys
RT @dakami: @sambowne @ea_foundation Sigh. That script is not actually safe. It's a "best effort prevent a BSoD".
RT @dakami: @ea_foundation @sambowne You basically create the vulnerable state and then hopefully close it.
RT @dakami: @ea_foundation @sambowne Is *anything* else before that request correlated with post-patch? That second message from RDP is a doozy...
Here is the script correctly detecting a vulnerable Windows 7 target from Backtrack 5 R1:
@ea_foundation has given permission to post the script here!
I downloaded the script from this link:
http://pastie.org/private/kmp5xvhwmpvjkqkahtwq
In case that link is down, you can download my copy from this link:
However, when I tried it again, it failed the same way (broken pipe). I tried from Windows with the new script and it also failed.
So this is very unreliable, at least with VMware Fusion virtual machines. The problem may well be VMware network adapters--they have caused many problems for me in the past.
Here is a common sort of failure: the Windows target rejects all SYN packets after the first one, replying with RST packets, which thwarts the ms12-010 test.
Strangely, it always accepts nmap's port scan SYN, but often rejects the SYNs from the script. There must be some difference between them.
I got this result on a patched target machine--the script correctly doesn't report the existence of the vulnerability.
I went into Control Panel and removed the
MS12-020 patch.
But I still get the same result:
@DustySTS recommended capturing the packets, which is a good idea, so here's what I found:
Here is the "X.224 Connection Request" packet that opens the RDP session in detail:
Here is the "X.224 Connection Request" packet nmap sends, which provokes a RST from the Windows RDP server, which I think is the reason it fails:
It looks to me like the nmap script is not properly constructing that "X.224 Connection Request" packet.
The difference is at layer 4. The "X.224 Connection Request" packet from nmap contains 12 bytes of TCP Options:
In the real RDP connection request from Windows, those options are absent.
I think this is a bug in nmap. The script specifies the layer 7 payload, but does not appear to deliberately add TCP options to the request packet.
RT @DustySTS: @sambowne try explicitly specifying the port. E.g: nmap -p 3389 --script=rdp-ms12-020.nse. It's the only way I got it to work.
But it still doesn't work.
Here's what I see:
root@bt:/usr/local/share/nmap/scripts# nmap -p 3389 -sC --script=rdp-ms12-020.nse -vv --script-trace 192.168.198.129
Starting Nmap 5.61TEST4 ( http://nmap.org ) at 2012-03-27 13:03 PDT
NSE: Loaded 1 scripts for scanning.
NSE: Script Pre-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Initiating ARP Ping Scan at 13:03
Scanning 192.168.198.129 [1 port]
Completed ARP Ping Scan at 13:03, 0.01s elapsed (1 total hosts)
Initiating Parallel DNS resolution of 1 host. at 13:03
Completed Parallel DNS resolution of 1 host. at 13:03, 0.09s elapsed
Initiating SYN Stealth Scan at 13:03
Scanning 192.168.198.129 [1 port]
Discovered open port 3389/tcp on 192.168.198.129
Completed SYN Stealth Scan at 13:03, 0.00s elapsed (1 total ports)
NSE: Script scanning 192.168.198.129.
NSE: Starting runlevel 1 (of 1) scan.
Initiating NSE at 13:03
NSOCK (0.1790s) TCP connection requested to 192.168.198.129:3389 (IOD #1) EID 8
NSOCK (0.1790s) Callback: CONNECT ERROR [Connection refused (111)] for EID 8 [192.168.198.129:3389]
NSE: TCP 192.168.198.136:51678 > 192.168.198.129:3389 | CONNECT
NSE: TCP 192.168.198.136:51678 > 192.168.198.129:3389 | 00000000: 03 00 00 13 0e e0 00 00 00 00 00 01 00 08 00 00
00000010: 00 00 00
NSOCK (0.1790s) Write request for 19 bytes to IOD #1 EID 19 [192.168.198.129:3389]: ...................
NSOCK (0.1800s) Callback: WRITE ERROR [Broken pipe (32)] for EID 19 [192.168.198.129:3389]
NSE: TCP 192.168.198.136:51678 > 192.168.198.129:3389 | SEND
NSOCK (0.1800s) Read request for 0 bytes from IOD #1 [192.168.198.129:3389] EID 26
NSOCK (0.1800s) Callback: READ EOF for EID 26 [192.168.198.129:3389]
NSE: TCP 192.168.198.136:51678 > 192.168.198.129:3389 | CLOSE
Completed NSE at 13:03, 0.00s elapsed
Nmap scan report for 192.168.198.129
Host is up (0.00040s latency).
Scanned at 2012-03-27 13:03:43 PDT for 0s
PORT STATE SERVICE
3389/tcp open ms-term-serv
MAC Address: 00:0C:29:8A:55:E8 (VMware)
NSE: Script Post-scanning.
NSE: Starting runlevel 1 (of 1) scan.
Read data files from: /usr/local/bin/../share/nmap
Nmap done: 1 IP address (1 host up) scanned in 0.20 seconds
Raw packets sent: 2 (72B) | Rcvd: 2 (72B)
root@bt:/usr/local/share/nmap/scripts#
In each case, I needed to update to the latest version of nmap first.
Then I downloaded this file to the nmap scripts folder:
http://seclists.org/nmap-dev/2012/q1/att-662/rdp-ms12-020.nse
Then I executed this command to update the database:
nmap --script-updatedb
I executed this command to scan my vulnerable target:
nmap -sC --script rdp-ms12-020.nse -vv 192.168.198.129
The script runs, but no output appears, as shown below:
But it really is vulnerable. Here is the BSoD test:
If anyone can see what I am doing wrong, please tell me on Twitter @sambowne.
Thanks!
Sam Bowne 6:25 pm 4-7-12