Tag Archives: nmap

Vulnerability analysis part 4: Analyzing packets with Wireshark

Here is the given scenario: I’m a consultant for the security firm AllSafe. Our biggest client, E-Corp, suspects that an AllSafe employee did something to their network, and they need proof. All I have to work with is the packet capture file from our IDS.

A quick note about running Wireshark: To capture packets, Wireshark must be started as root. A quick search of the exploit database shows how many exploits there are for Wireshark. Obviously, I don’t want to be running Wireshark as root.

To capture packets, it’s safest use Wireshark’s CLI version, tshark.

# sudo tshark -i eth0 -w /tmp/packet_capture1.pcap

This allows me to promiscuously capture packets on the eth0 interface.

Now if I want to examine the capture (or any other .pcap file I download from the internet) from Kali, I need to modify permissions and view the file as a non-root user.

# chmod ugo+rx /tmp/packet_capture1.pcap

(ugo means users, groups, others, +rx means read and execute privileges). I’ll create a non-root user:

# adduser user1

After logging into our standard account with the supplied password, I’ll get to work.

$ wireshark /tmp/packet_capture1.pcap

I look for any host discovery scans. Nmap will do these scans differently depending on two things:

1) Is the user root?
2) Is it a local address (i.e. on the same subnet)

Nmap performs the following requests when scanning for hosts on a different network:

1) ICMP echo request
2) TCP SYN to port 443
3) TCP ACK to port 80
4) ICMP timestamp request

Filtering ICMP traffic reveals nothing.

Nmap performs ARP requests when scanning for hosts on the same subnet. I’ll look for ARP requests:

Bingo, I found host 192.168.154.129 looking for hosts on our subnet. I’ll see if he was doing any port scans. I’m looking for TCP packets, specifically handshakes. I don’t know what kind of scan was performed, or which ports he scanned.

I’ll start by looking for traffic involving the suspicious machine to common ports. I expect the scan to be done first, so if I start seeing a lot of traffic on the port, I’ll just assume that he didn’t scan that port.

I look at ports for FTP, SSH, Telnet, and SMTP. They all start with:

This indicates that the suspicious host did an nmap stealth scan of the 192.168.154.131 machine. I look at a few more ports, and it appears that he scanned ports 1-30. I didn’t see any of the SYN, SYN ACK, or RST packets for any ports above 30.

I want to see what websites he visited. I can do this by adding a filter on DNS traffic involving our suspicious machine.

It looks like he visited the website “toplessrobot.com”. This page has a lot of images and scripts which I can see if I take a closer look at his web traffic by adding a filter to see HTTP traffic.

Scrolling through the various loading of various widgets, images, and ads, I see a few interesting packets.

It looks like the suspicious .129 address tried visiting ~/bjones. I can follow the TCP stream of the subsequent HTTP GET packets and see what it contains.

Bob Jones must have had an Apache web server running. If I look a little after this, I see something else interesting:

The suspect downloaded a .rar password list. I wonder what he’ll use password list for…

Looking for any FTP traffic.

Here I see the password list being used to try to brute force the password for bjones. To find out if he was successful, let’s find out what response the server gives if the login is successful. According to https://en.wikipedia.org/wiki/List_of_FTP_server_return_codes, a server response of 230 indicates the user has successfully logged in.

If I go to where these packets occurred, I can see the correct FTP password being accepted by .131

User bjones had a password of password1234. Following the TCP stream can show us what mischief he was up to.

It looks like after navigating to the folder called Documents, the suspect downloaded the files andrea-nude.jpg, password-email.txt, password-email.txt, passwords.ods, and proposed-email.txt.

Using a little magic, I can rebuild these files and see what they contained.

Changing the filter to include packets with the FTP-DATA protocol. Now find the FTP-DATA packet after the response for the request for the .jpg. Save the raw dump to a location (I saved my in /tmp/rawdumps).

This data is meaningless in it’s current form. But using the Linux tools file and foremost, I can determine the type of file and then reconstruct the file by looking at headers, footers, and data.

$ file andrea-nude 
andrea-nude: JPEG image data, JFIF standard 1.01, resolution (DPI), density 300x300, segment length 16, baseline, precision 8, 332x332, frames 3
$ foremost andrea-nude 
Processing: andrea-nude
|*|
$ cd output/
$ ls
audit.txt jpg
$ eog jpg
 

I’ll do the same on the other files. Not all streams require us to decode them with file and foremost.

The email:

The OpenOffice spreadsheet:

Another email:

I also see the user SSHd to the victim machine. Obviously I won’t be able to see details of encrypted traffic.

This is all I was able to find from this file.

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