Tag Archives: reconnaissance

Vulnerability analysis part 3: Port scanning techniques

Over in Kali, I’ll use nmap to scout out the target. At first I’ll try to be stealthy to avoid tripping the Suricata IDS I set up in part 1.

Nmap can report that a port is either open, closed, filtered, or unfiltered. Open ports means that some service is listening on that port. Closed ports mean that there is nothing listening. Filtered ports mean that firewall is blocking the scanning packets, so the scan cannot determine if it is open or closed. Unfiltered ports means nmap cannot tell what is listening on the port, but there was a response.

Let’s do a default scan. The -F is a port specifier flag, which tells nmap to only scan the top 100 most used ports.

If no scan technique is specified, nmap will use the -sS scanning technique. This stealthy scan sends a TCP SYN packet to the host. Once you receive the TCP SYN ACK packet, it closes the connection with a RST packet (the TCP handshake never finishes). This is the least intrusive scan. It crafts a raw packet instead of using the operating system’s networking stack.

# nmap -F 192.168.238.137
Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-01 19:51 EDT
Nmap scan report for 192.168.238.137
Host is up (0.0012s latency).
Not shown: 82 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
513/tcp open login
514/tcp open shell
2049/tcp open nfs
2121/tcp open ccproxy-ftp
3306/tcp open mysql
5432/tcp open postgresql
5900/tcp open vnc
6000/tcp open X11
8009/tcp open ajp13
MAC Address: 00:0C:29:54:6E:48 (VMware)

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

The Suricata log did not show any entries for the SYN scan. Let’s be a little more noisy. The -sT scan technique performs a TCP connect scan. It will complete all three steps of the TCP handshake. This scan will use the operating system’s networking capabilities to open TCP connection. As soon as the connection is established, the it immediately closes the connection. This is easier for an IDS to see, as there will be completed connection. Why would we choose to use this scan? The RST packet causes problems on some networking stacks. Using the specially crafted packets of the SYN scan may require additional privileges on a machine. TCP connect scanning require no such privileges.

# nmap -F -sT 192.168.238.137

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-06 17:52 EDT
Nmap scan report for 192.168.238.137
Host is up (0.0013s latency).
Not shown: 82 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
513/tcp open login
514/tcp open shell
2049/tcp open nfs
2121/tcp open ccproxy-ftp
3306/tcp open mysql
5432/tcp open postgresql
5900/tcp open vnc
6000/tcp open X11
8009/tcp open ajp13
MAC Address: 00:0C:29:54:6E:48 (VMware)

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

Suricata gives us an alert for each open port that was scanned, telling us there was a TCP packet with an invalid timestamp coming from our Kali box’s IP address.

UDP scanning is also possible using nmap. Using the -sU flag, you can send UDP packets to the machine on a range of ports. Since UDP is connectionless, the scan sends out multiple UDP packets in hopes that they get through. If no response is recorded, the scan assumes the port is open. If the port is closed, you will receive an ICMP port unreachable message. This scan can give false positives, as some firewalls filter out the ICMP port unreachable message, and it will tell you a UDP port is open when in reality it is closed.

You might choose to use a UDP scan if looking for DNS or DHCP services.

Notice how long it took for this scan to complete, while only scanning the most common ports with the -F flag.

# nmap -sU -F 192.168.238.137

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-06 18:09 EDT
Nmap scan report for 192.168.238.137
Host is up (0.00049s latency).
Not shown: 93 closed ports
PORT STATE SERVICE
53/udp open domain
68/udp open|filtered dhcpc
69/udp open|filtered tftp
111/udp open rpcbind
137/udp open netbios-ns
138/udp open|filtered netbios-dgm
2049/udp open nfs
MAC Address: 00:0C:29:54:6E:48 (VMware)

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

This UDP scan did not set off Suricata.

Let’s be louder.

SERVICE/VERSION/OS DETECTION

These types of scans can tell you what OS is running on a host, and which service/version number of the service is running on a port on a host. This can allow you search for an exploit for the service on the host.

The -sV flag will return what service/version is running on a specified ports. The -O flag will tell us what OS is running on a given host.

# nmap -sV -O 192.168.238.137

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-06 20:32 EDT
Nmap scan report for 192.168.238.137
Host is up (0.00030s latency).
Not shown: 977 closed ports
PORT STATE SERVICE VERSION
21/tcp open ftp vsftpd 2.3.4
22/tcp open ssh OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0)
23/tcp open telnet Linux telnetd
25/tcp open smtp Postfix smtpd
53/tcp open domain ISC BIND 9.4.2
80/tcp open http Apache httpd 2.2.8 ((Ubuntu) DAV/2)
111/tcp open rpcbind 2 (RPC #100000)
139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)
512/tcp open exec netkit-rsh rexecd
513/tcp open login?
514/tcp open tcpwrapped
1099/tcp open rmiregistry GNU Classpath grmiregistry
1524/tcp open shell Metasploitable root shell
2049/tcp open nfs 2-4 (RPC #100003)
2121/tcp open ftp ProFTPD 1.3.1
3306/tcp open mysql MySQL 5.0.51a-3ubuntu5
5432/tcp open postgresql PostgreSQL DB 8.3.0 - 8.3.7
5900/tcp open vnc VNC (protocol 3.3)
6000/tcp open X11 (access denied)
6667/tcp open irc Unreal ircd
8009/tcp open ajp13 Apache Jserv (Protocol v1.3)
8180/tcp open http Apache Tomcat/Coyote JSP engine 1.1
MAC Address: 00:0C:29:54:6E:48 (VMware)
Device type: general purpose
Running: Linux 2.6.X
OS CPE: cpe:/o:linux:linux_kernel:2.6
OS details: Linux 2.6.9 - 2.6.33
Network Distance: 1 hop
Service Info: Hosts: metasploitable.localdomain, localhost, irc.Metasploitable.LAN; OSs: Unix, Linux; CPE: cpe:/o:linux:linux_kernel

OS and Service detection performed. Please report any incorrect results at https://nmap.org/submit/ .
Nmap done: 1 IP address (1 host up) scanned in 18.25 seconds

This scan alerted Suricata of unknown ICMPv4 codes.

We can perform this in depth scan with some additional flags to make it a little quieter. The -T flag allows you to set a parameter of 0 to 5 to adjust the timing of the scan. -T0 (paranoid template) is very slow and depending on the IDS configuration, might not set off an alarm. -T5 (insane) uses a lot of network bandwidth and can quickly train the target host’s resources.

ACK scans will send a special packet with the ACK flag set to 1. If you receive a RST packet in response, the port is parked as unfiltered. No response might indicate the port is being filtered by a firewall. This scan is commonly used to look for firewalls and attempt to determine the firewall’s ruleset.

# nmap -sT 192.168.238.137

Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-09 18:02 EDT
Nmap scan report for 192.168.238.137
Host is up (0.0017s latency).
Not shown: 977 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
512/tcp open exec
513/tcp open login
514/tcp open shell
1099/tcp open rmiregistry
1524/tcp open ingreslock
2049/tcp open nfs
2121/tcp open ccproxy-ftp
3306/tcp open mysql
5432/tcp open postgresql
5900/tcp open vnc
6000/tcp open X11
6667/tcp open irc
8009/tcp open ajp13
8180/tcp open unknown
MAC Address: 00:0C:29:54:6E:48 (VMware)

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

The ACK scan will alert Suricata that a scan took place on the open ports.

PORT SCANNING WITH NETCAT

You can also do port scans similar to nmap with Netcat netcat (nc). Netcat does not require root privileges. Netcat is also a much smaller package than nmap, and can run on lower-end machines.

The basic scan on port 80:

# nc -vz 192.168.238.137 80
192.168.238.137: inverse host lookup failed: Unknown host
(UNKNOWN) [192.168.238.137] 80 (http) open

Netcat is trying to do a DNS lookup on the IP address. We can disable this with the -n flag.

With a little bit of bash scripting, we can look at multiple ports:

# for i in {21,25}; do nc -vnz 192.168.238.137 $i; done
(UNKNOWN) [192.168.238.137] 21 (ftp) open
(UNKNOWN) [192.168.238.137] 25 (smtp) open

We can scan a range of ports:

# for i in {25..30}; do nc -vnz 192.168.238.137 $i; done
(UNKNOWN) [192.168.238.137] 25 (smtp) open
(UNKNOWN) [192.168.238.137] 26 (?) : Connection refused
(UNKNOWN) [192.168.238.137] 27 (?) : Connection refused
(UNKNOWN) [192.168.238.137] 28 (?) : Connection refused
(UNKNOWN) [192.168.238.137] 29 (?) : Connection refused
(UNKNOWN) [192.168.238.137] 30 (?) : Connection refused

Using Netcat did not alert Suricata.

Next up, we’ll try and look at some of these scans in Wireshark.

Vulnerability analysis part 2: Host discovery using nmap

I know IP address on my attacking machine is 192.168.238.137, and I know the subnet mask is 255.255.255.0. In CIDR notation, this means the subnet is /24. This tells me which part of my IP address is the network prefix (192.168.238), and which part is the host number (.137).

We can list out all the IP addresses in this range by using a list scan (-sP). This scan sends no packets to listed IP addresses, but it will attempt a reverse DNS resolution on each host.

# nmap -sL 192.168.238.0/24

Since there are 256 addresses outputted by this command, I will not paste them here.

Let’s explore other machines with ping sweep. This scan does not scan any ports, but only reports on which hosts are up by pinging them. Older versions of nmap us -sP. Newer versions will use -sn

# nmap -sn 192.168.238.0/24
Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-06 18:49 EDT
Nmap scan report for 192.168.238.1
Host is up (0.00039s latency).
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 192.168.238.2
Host is up (0.00012s latency).
MAC Address: 00:50:56:EA:8D:7F (VMware)
Nmap scan report for 192.168.238.137
Host is up (-0.10s latency).
MAC Address: 00:0C:29:54:6E:48 (VMware)
Nmap scan report for 192.168.238.254
Host is up (0.00011s latency).
MAC Address: 00:50:56:EF:B0:9E (VMware)
Nmap scan report for 192.168.238.136
Host is up.
Nmap done: 256 IP addresses (5 hosts up) scanned in 2.28 seconds

I know the 192.168.238.2 addresses is my default gateway, and 192.168.238.136 is my local machine. What are those other three addresses? One of them is the Metasploitable machine. I’m not sure what the other two are.

A little digging, and I find out what these addresses are.

192.168.238.1: Host machines
192.168.238.2: Default gateway
192.168.238.254: VMware DHCP server
192.168.238.136: Kali machine
192.168.238.137 must be our Metasploitable VM.

The ping scan will ping the host, send a TCP SYN, a TCP ACK, and request an ICMP timestamp. If any of these requests receive a response, we know the host is alive. If there was a firewall or other device blocking these requests, the ping scan might show that no host is up at an IP address, and you will need to use a different method of host discovery. The -Pn scan will attempt a port scan on every IP address in the given range. We’ll speed it up with the -F flag to only scan 100 ports.

# nmap -F -Pn 192.168.238.0/24
Starting Nmap 6.49BETA4 ( https://nmap.org ) at 2015-09-07 17:12 EDT
Nmap scan report for 192.168.238.1
Host is up (0.00032s latency).
Not shown: 97 filtered ports
PORT STATE SERVICE
135/tcp open msrpc
139/tcp open netbios-ssn
445/tcp open microsoft-ds
MAC Address: 00:50:56:C0:00:08 (VMware)
Nmap scan report for 192.168.238.2
Host is up (0.00011s latency).
Not shown: 99 closed ports
PORT STATE SERVICE
53/tcp open domain
MAC Address: 00:50:56:EA:8D:7F (VMware)
Nmap scan report for 192.168.238.137
Host is up (0.00018s latency).
Not shown: 82 closed ports
PORT STATE SERVICE
21/tcp open ftp
22/tcp open ssh
23/tcp open telnet
25/tcp open smtp
53/tcp open domain
80/tcp open http
111/tcp open rpcbind
139/tcp open netbios-ssn
445/tcp open microsoft-ds
513/tcp open login
514/tcp open shell
2049/tcp open nfs
2121/tcp open ccproxy-ftp
3306/tcp open mysql
5432/tcp open postgresql
5900/tcp open vnc
6000/tcp open X11
8009/tcp open ajp13
MAC Address: 00:0C:29:54:6E:48 (VMware)
Nmap scan report for 192.168.238.254
Host is up (-0.10s latency).
All 100 scanned ports on 192.168.238.254 are filtered
MAC Address: 00:50:56:F7:A6:AC (VMware)
Nmap scan report for 192.168.238.136
Host is up (0.0000020s latency).
All 100 scanned ports on 192.168.238.136 are closed
Nmap done: 256 IP addresses (5 hosts up) scanned in 16.43 seconds

Some additional scan types:

TCP SYN pings initiate the first step in the TCP handshake on a given port. If the host responds with TCP ACK, we know the host is alive, and we close the handshake with a RST packet.

TCP ACK pings send the ACK to a host, making the host think a handshake was initiated. Since the host knows it didn’t send a SYN, it will respond with a RST packet to stop the handshake, letting us know the host is alive.

UDP pings send a UDP packet to a certain port. It receives an ICMP port unreachable packet if the port is closed, but that lets us know the host is alive.

Up next: Port scanning