Scanning the Network - Cyber Operations: Building, Defending, and Attacking Modern Computer Networks (2015)

Cyber Operations: Building, Defending, and Attacking Modern Computer Networks (2015)

5. Scanning the Network

Mike O’Leary1

(1)

Department of Mathematics, Towson University, Towson, MD, US

Introduction

The web browser attacks of Chapter 2 require the victim to visit a web site controlled by the attacker. In more realistic scenarios, the attacker needs to know some details of the target network before being able to launch attacks that have a reasonable chance of success.

This chapter introduces NMap, the premier tool for host detection and network scanning. When launched, NMap sends packets to one or more targets and awaits the response. This allows NMap to determine if the target systems are responsive to network traffic, and on which ports. By examining the traffic characteristics in detail, NMap is able to guess the operating system of the target and probe for the versions of any running services it finds. NMap’s functionality has been extended with more than 450 scripts run through the NMap scripting engine.

NMap can be run from within Metasploit and uses the Metasploit internal database to organize and store scan results in a searchable format. Metasploit has other scanning tools, including a scanning module that checks DNS servers for DNS amplification attacks. Custom Metasploit modules can be developed and integrated into Metasploit.

NMap

NMap comes preinstalled on Kali systems. It is available for most Linux distributions, including CentOS, OpenSuSE, Ubuntu and Mint and can be installed with native tools (yum, zypper, apt-get). A Windows port of NMap is available online at http://nmap.org/download.html .

As a simple example, from a Kali system run NMap against a small group of hosts

root@kali:∼# nmap 10.0.4.8-13

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 13:44 EDT

Nmap scan report for Coalsack.nebula.example (10.0.4.10)

Host is up (0.00012s latency).

Not shown: 997 closed ports

PORT STATE SERVICE

53/tcp open domain

139/tcp open netbios-ssn

445/tcp open microsoft-ds

MAC Address: 08:00:27:84:84:7A (Cadmus Computer Systems)

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up (0.000094s latency).

Not shown: 997 closed ports

PORT STATE SERVICE

53/tcp open domain

139/tcp open netbios-ssn

445/tcp open microsoft-ds

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

Nmap scan report for Pipe.nebula.example (10.0.4.12)

Host is up (0.00029s latency).

Not shown: 999 filtered ports

PORT STATE SERVICE

53/tcp open domain

MAC Address: 08:00:27:F4:74:F8 (Cadmus Computer Systems)

Nmap scan report for Snake.nebula.example (10.0.4.13)

Host is up (0.00033s latency).

Not shown: 998 filtered ports

PORT STATE SERVICE

53/tcp open domain

5357/tcp open wsdapi

MAC Address: 08:00:27:67:42:B2 (Cadmus Computer Systems)

Nmap done: 6 IP addresses (4 hosts up) scanned in 5.69 seconds

The report shows that four of the six scanned hosts responded to network traffic, including 10.0.4.10, 10.0.4.11, 10.0.4.12, and 10.0.4.13. NMap reports some of the open TCP ports. NMap does not scan every port by default. For each target, NMap reported 997, 998, or 999 filtered ports; these ports did not respond to NMap packets. The remaining ports were not scanned by NMap. Because these hosts are all on the same local network as the scanning system, NMap returns the MAC address of the target.

NMap provides a number of different ways to select the target(s) of a scan, including

· Host name: nmap cone.nebula.example

· CIDR notation: nmap 10.0.4.0/24

· CIDR with a name: nmap cone.nebula.example/28

· A range of IP addresses: nmap 10.0.4.8-13

· Mixed IP ranges: nmap 10.0.0,2,3,4.1-254

· Combined ranges: nmap 192.168.1.0/24 10.0.1.2,3,4.1-254

· Contained in a file: nmap -iL hostnames.txt

One of the first tasks of an attacker is to determine which hosts are alive and on the network. To check only whether a host is alive, run an NMap scan with the -sP flag.

root@kali:∼# nmap -sP 10.0.4.0/28

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-15 13:30 EDT

Nmap scan report for Coalsack.nebula.example (10.0.4.10)

Host is up (0.000099s latency).

MAC Address: 08:00:27:84:84:7A (Cadmus Computer Systems)

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up (0.00013s latency).

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

Nmap scan report for Pipe.nebula.example (10.0.4.12)

Host is up (0.00016s latency).

MAC Address: 08:00:27:F4:74:F8 (Cadmus Computer Systems)

Nmap scan report for Snake.nebula.example (10.0.4.13)

Host is up (0.00014s latency).

MAC Address: 08:00:27:67:42:B2 (Cadmus Computer Systems)

Nmap scan report for Horsehead.nebula.example (10.0.4.14)

Host is up (0.00021s latency).

MAC Address: 08:00:27:F0:23:B0 (Cadmus Computer Systems)

Nmap scan report for Boomerang.nebula.example (10.0.4.15)

Host is up (0.00028s latency).

MAC Address: 08:00:27:C5:9B:A3 (Cadmus Computer Systems)

Nmap done: 16 IP addresses (6 hosts up) scanned in 0.22 seconds

NMap reports that 6 of the 16 hosts responded to traffic.

When checking to see if a system not on the local network is alive, NMap sends four packets- a ping request, a SYN packet to TCP/443, an ACK packet to TCP/80 and a timestamp request. This can be observed in a packet capture; here is a scan of the Google DNS server at 8.8.8.8

No. Time Source Destination Protocol Length Info

1 0.000000000 10.0.4.252 8.8.8.8 ICMP 42 Echo (ping) request id=0x1048, seq=0/0, ttl=53 (reply in 5)

2 0.000098000 10.0.4.252 8.8.8.8 TCP 58 41414 > https [SYN] Seq=0 Win=1024 Len=0 MSS=1460

3 0.000176000 10.0.4.252 8.8.8.8 TCP 54 41414 > http [ACK] Seq=1 Ack=1 Win=1024 Len=0

4 0.000233000 10.0.4.252 8.8.8.8 ICMP 54 Timestamp request id=0xb584, seq=0/0, ttl=54

5 0.033515000 8.8.8.8 10.0.4.252 ICMP 60 Echo (ping) reply id=0x1048, seq=0/0, ttl=41 (request in 1)

Because 8.8.8.8 responds to ping, NMap reports that host as up, even though the host did not respond to the other three packets.

For targets on the local network, NMap makes an ARP request, and may follow that up with a DNS query to get the name of the system.

No. Time Source Destination Protocol Length Info

1 0.000000000 CadmusCo_5c:13:b7 Broadcast ARP 42 Who has 10.0.4.14? Tell 10.0.4.252

2 0.000454000 CadmusCo_f0:23:b0 CadmusCo_5c:13:b7 ARP 60 10.0.4.14 is at 08:00:27:f0:23:b0

3 0.000751000 10.0.4.252 10.0.4.11 DNS 82 Standard query 0x9992 PTR 14.4.0.10.in-addr.arpa

4 0.001155000 10.0.4.11 10.0.4.252 DNS 194 Standard query response 0x9992 PTR Horsehead.nebula.example

Notice that the target system did not receive any IP packets from the scanning system as the target responded to a broadcast ARP request.

Another way to avoid sending packets directly to the targets is to use a list scan, -sL. In a list scan, NMap performs reverse DNS lookups, so the only traffic is between the attacker and the DNS server.

root@kali:∼# nmap -sL cone.nebula.example/28

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-15 13:30 EDT

Nmap scan report for 10.0.4.0

Nmap scan report for 10.0.4.1

Nmap scan report for 10.0.4.2

Nmap scan report for 10.0.4.3

Nmap scan report for 10.0.4.4

Nmap scan report for 10.0.4.5

Nmap scan report for 10.0.4.6

Nmap scan report for 10.0.4.7

Nmap scan report for 10.0.4.8

Nmap scan report for 10.0.4.9

Nmap scan report for Coalsack.nebula.example (10.0.4.10)

Nmap scan report for cone.nebula.example (10.0.4.11)

rDNS record for 10.0.4.11: Cone.nebula.example

Nmap scan report for Pipe.nebula.example (10.0.4.12)

Nmap scan report for Snake.nebula.example (10.0.4.13)

Nmap scan report for Horsehead.nebula.example (10.0.4.14)

Nmap scan report for Boomerang.nebula.example (10.0.4.15)

Nmap done: 16 IP addresses (0 hosts up) scanned in 0.00 seconds

Here NMap reports the DNS names of six hosts; however it did not report whether these hosts were up.

The real value of NMap comes from its ability to determine the port(s) that the target has open. NMap provides a number of different ways to do so. The simplest type of scan is a SYN stealth scan. This is the default, but can be specified on the command line with the option -sS. In a stealth scan, NMap reports TCP ports to be in one of three states depending on the observed behavior.

· Open Port: Scanner sends SYN. Target responds SYN/ACK.

· Closed Port: Scanner sends SYN. Target responds RST.

· Filtered Port: Scanner sends SYN. No response, or ICMP unreachable.

This is called a stealth scan because the scanner does not complete the three-way TCP handshake.

When run with the option -reason Nmap returns the reason it classified the port. Here is a sample scan of a Windows 2008 R2 Server running BIND.

root@kali:∼# nmap -reason 10.0.4.11

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-15 16:08 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.00011s latency).

Not shown: 997 closed ports

Reason: 997 resets

PORT STATE SERVICE REASON

53/tcp open domain syn-ack

139/tcp open netbios-ssn syn-ack

445/tcp open microsoft-ds syn-ack

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

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

By default, NMap selects the top 1000 ports for a scan, determined by a surveyed frequency of their use. On a Kali system, these results are contained in the file /usr/share/nmap/nmap-services. To change the number of ports scanned, the --top-ports option can be used to specify how many of the top ports should be scanned. The precise list of scanned ports can be specified with the -p flag. To scan all TCP ports, use the command

root@kali:∼# nmap –p 1-65535 -reason 10.0.4.11

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 14:37 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.00011s latency).

Not shown: 65532 closed ports

Reason: 65532 resets

PORT STATE SERVICE REASON

53/tcp open domain syn-ack

139/tcp open netbios-ssn syn-ack

445/tcp open microsoft-ds syn-ack

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

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

This scan took more than 45 times as long at the original; this is important when scanning large networks.

A louder type of scan is the TCP connect scan. It is similar to the stealth scan and classifies ports in the same way. If the scanner receives a SYN/ACK packet from the target, it responds with SYN/ACK to complete the three-way handshake. The option -sT is used to specify a TCP connect scan.

root@kali:∼# nmap -sT -reason 10.0.4.11

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 15:06 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.0020s latency).

Not shown: 997 closed ports

Reason: 997 conn-refused

PORT STATE SERVICE REASON

53/tcp open domain syn-ack

139/tcp open netbios-ssn syn-ack

445/tcp open microsoft-ds syn-ack

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

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

Neither the stealth nor the TCP connect scan examine UDP ports. Scans of UDP ports are handled somewhat differently, as even an open UDP port might not respond to any particular received UDP packet. UDP ports are reported to be in one of four states depending on the traffic received.

· Open Port: Scanner sends UDP packet to target, target responds.

· Open | Filtered Port: Scanner sends UDP packet to target, target fails to respond, even after retransmission.

· Closed Port: Scanner sends UDP packet, target responds with an ICMP port unreachable packet.

· Filtered Port: Scanner sends UDP packet, Target responds with a different ICMP error message.

UDP scans are launched with the -sU option. Like TCP scans, by default these scan the top 1000 (UDP) ports. To specify ports manually, use the -p option. To specify the number of top ports to scan, use the --top-ports option.

root@kali:∼# nmap -sU -reason 10.0.4.11

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 15:15 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.00018s latency).

Not shown: 996 closed ports

Reason: 996 port-unreaches

PORT STATE SERVICE REASON

53/udp open domain udp-response

137/udp open netbios-ns udp-response

138/udp open|filtered netbios-dgm no-response

5353/udp open zeroconf udp-response

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

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

Note the time needed for the UDP scan: roughly 18 minutes for 1000 UDP ports. Here both the scanning Kali system and the target are VirtualBox systems on the same physical host.

Nmap has a wide range of additional, esoteric scan types, including XMAS, FIN, ACK, NULL, and idle scans.

NMap allows users to adjust the speed of the scan with timing options. These cover a wide range of settings that can be overridden individually.

· -T0 (paranoid) Wait 5 minutes between probes.

· -T1 (sneaky) Wait 15 seconds between probes.

· -T2 (polite) As low as 1/10 speed of -T3.

· -T3 (normal) Default speed.

· -T4 (aggressive)

· -T5 (insane)

In general, -T4 is appropriate on a fast connection; -T5 may be too fast for reliable results.

The result of the scan is stored in a named text file when the -oN option is used with a file name. The option -oX with a file name stores the result in a file in .xml format.

When NMap is used with the -O option, it guesses the operating system version. In the earlier scans of 10.0.4.10–13, NMap reported that 10.0.4.11 had TCP/53, TCP/139 and TCP/445 open, while 10.0.4.12 had only TCP/53 open. Scanning these two hosts with the -O option yields

root@kali:∼# nmap -O -reason 10.0.4.11-12

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 15:38 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.00012s latency).

Not shown: 997 closed ports

Reason: 997 resets

PORT STATE SERVICE REASON

53/tcp open domain syn-ack

139/tcp open netbios-ssn syn-ack

445/tcp open microsoft-ds syn-ack

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

Device type: general purpose

Running: Linux 2.6.X|3.X

OS CPE: cpe:/o:linux:linux_kernel:2.6 cpe:/o:linux:linux_kernel:3

OS details: Linux 2.6.32 - 3.9

Network Distance: 1 hop

Nmap scan report for Pipe.nebula.example (10.0.4.12)

Host is up, received arp-response (0.00020s latency).

Not shown: 999 filtered ports

Reason: 999 no-responses

PORT STATE SERVICE REASON

53/tcp open domain syn-ack

MAC Address: 08:00:27:F4:74:F8 (Cadmus Computer Systems)

Warning: OSScan results may be unreliable because we could not find at least 1 open and 1 closed port

Device type: general purpose|phone

Running (JUST GUESSING): Microsoft Windows 7|Phone|2008|Vista (93%)

OS CPE: cpe:/o:microsoft:windows_7::-:professional cpe:/o:microsoft:windows cpe:/o:microsoft:windows_server_2008::beta3 cpe:/o:microsoft:windows_vista::- cpe:/o:microsoft:windows_vista::sp1

Aggressive OS guesses: Microsoft Windows 7 Professional (93%), Microsoft Windows Phone 7.5 (92%), Microsoft Windows Server 2008 Beta 3 (92%), Microsoft Windows Vista SP0 or SP1, Windows Server 2008 SP1, or Windows 7 (92%), Microsoft Windows Vista SP2, Windows 7 SP1, or Windows Server 2008 (92%), Microsoft Windows Server 2008 SP1 (89%), Microsoft Windows Vista Home Premium SP1 (89%), Microsoft Windows 7 SP1 (86%), Microsoft Windows Vista SP0 - SP1 (86%)

No exact OS matches for host (test conditions non-ideal).

Network Distance: 1 hop

OS detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 2 IP addresses (2 hosts up) scanned in 9.33 seconds

NMap is not always correct with its guesses for the operating system. Here it concluded that the system with TCP/139 and TCP/445 open is a Linux system, and the system with these ports closed is a Windows system. In fact, this is correct. The 10.0.4.11 system (cone.nebula.example) is running Mint 15, while the 10.0.4.12 system (pipe.nebula.example) is running Windows Server 2012 – which is not one of NMap’s guesses.

NMap guesses the version of the services running on the target when it is run with the -sV option.

root@kali:∼# nmap -sV -reason 10.0.4.11-12

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 15:40 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.00011s latency).

Not shown: 997 closed ports

Reason: 997 resets

PORT STATE SERVICE REASON VERSION

53/tcp open domain syn-ack ISC BIND 9.9.2-P1

139/tcp open netbios-ssn syn-ack Samba smbd 3.X (workgroup: WORKGROUP)

445/tcp open netbios-ssn syn-ack Samba smbd 3.X (workgroup: WORKGROUP)

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

Nmap scan report for Pipe.nebula.example (10.0.4.12)

Host is up, received arp-response (0.00056s latency).

Not shown: 999 filtered ports

Reason: 999 no-responses

PORT STATE SERVICE REASON VERSION

53/tcp open domain syn-ack ISC BIND 9.7.1

MAC Address: 08:00:27:F4:74:F8 (Cadmus Computer Systems)

Service detection performed. Please report any incorrect results at http://nmap.org/submit/ .

Nmap done: 2 IP addresses (2 hosts up) scanned in 15.98 seconds

NMap comes with more than 450 scripts that extend its functionality. Each script is classified into one or more categories, including “default,” “safe,” “discovery,” “version,” “intrusive,” and “malware.” On a Kali system, these scripts are located in the directory /usr/share/nmap/scripts. When run with the option -sC, NMap runs 100 default scripts in the scan. Not all of these scripts are considered “safe” though, and many are intrusive. To run just the safe default ones, the command is

root@kali:∼# nmap -reason --script "default and safe" 10.0.4.11

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 15:44 EDT

Nmap scan report for Cone.nebula.example (10.0.4.11)

Host is up, received arp-response (0.000097s latency).

Not shown: 997 closed ports

Reason: 997 resets

PORT STATE SERVICE REASON

53/tcp open domain syn-ack

139/tcp open netbios-ssn syn-ack

445/tcp open microsoft-ds syn-ack

MAC Address: 08:00:27:C8:10:4D (Cadmus Computer Systems)

Host script results:

|_nbstat: NetBIOS name: CONE, NetBIOS user: <unknown>, NetBIOS MAC: <unknown> (unknown)

| smb-os-discovery:

| OS: Unix (Samba 3.6.9)

| Computer name: Cone

| NetBIOS computer name:

| Domain name:

| FQDN: Cone

|_ System time: 2014-08-17T15:44:54-04:00

| smb-security-mode:

| Account that was used for smb scripts: guest

| User-level authentication

| SMB Security: Challenge/response passwords supported

|_ Message signing disabled (dangerous, but default)

|_smbv2-enabled: Server doesn’t support SMBv2 protocol

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

In this example, NMap reports the results from four additional scripts (nbstat, smb-os-discovery, smb-security-mode, and smbv2-enabled).

Additional information about any script is available from the command line

root@kali:/usr/share/nmap/scripts# nmap --script-help nbstat

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 16:11 EDT

nbstat

Categories: default discovery safe

http://nmap.org/nsedoc/scripts/nbstat.html

Attempts to retrieve the target’s NetBIOS names and MAC address.

By default, the script displays the name of the computer and the logged-in

user; if the verbosity is turned up, it displays all names the system thinks it

owns.

More information about each script is available in the online documentation at http://nmap.org/nsedoc/ . This includes the script’s arguments, an example use case for the script, and a sample set of output.

The nmap option -A (aggressive scan) combines operating system scan (-O), version scanning (-sV) script scanning (-sC) and runs traceroute.

Zenmap (Figure 5-1) is a graphical front end for NMap. On a Kali system, it can be found by navigating the main menu through Applications ➤ Kali Linux ➤ Information Gathering ➤ Live Host Identification ➤ zenmap. It can also be launched from the terminal via zenmap.

A333712_1_En_5_Fig1_HTML.jpg

Figure 5-1.

Zenmap

Network Scanning and Metasploit

NMap can be run from within Metasploit

msf > nmap 10.0.4.10

[*] exec: nmap 10.0.4.10

Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-16 13:29 EDT

Nmap scan report for Coalsack.nebula.example (10.0.4.10)

Host is up (0.000093s latency).

Not shown: 997 closed ports

PORT STATE SERVICE

53/tcp open domain

139/tcp open netbios-ssn

445/tcp open microsoft-ds

MAC Address: 08:00:27:84:84:7A (Cadmus Computer Systems)

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

However, all this does is call NMap as an external tool, run it, and display the results on the screen.

Metasploit saves its results in a database organized into workspaces. The Metasploit command workspace lists all of the available workspaces. Unless a new workspace is specified, results are stored in the default workspace. New workspaces are created by using workspace command with the -a option; workspaces are deleted with the -d option. If the default workspace is deleted, it will be recreated as an empty workspace, allowing the user an easy way to clear it. Create the workspace named nebula with the Metasploit command

msf > workspace -a nebula

[*] Added workspace: nebula

This becomes the current running workspace.

It is possible to store the result of an NMap scan using -oX and then import it into Metasploit through the db_import command. The command db_nmap runs an NMap scan, but also stores the results in the database for future use without the hassle of creating and loading a temporary intermediate file. Here is the same scan run earlier, but now run within Metasploit.

msf > db_nmap -O -sV --script "default and safe" 10.0.4.10-15

[*] Nmap: Starting Nmap 6.46 ( http://nmap.org ) at 2014-08-17 17:52 EDT

[*] Nmap: Nmap scan report for Coalsack.nebula.example (10.0.4.10)

[*] Nmap: Host is up (0.00013s latency).

[*] Nmap: Not shown: 997 closed ports

[*] Nmap: PORT STATE SERVICE VERSION

[*] Nmap: 53/tcp open domain

[*] Nmap: 139/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)

[*] Nmap: 445/tcp open netbios-ssn Samba smbd 3.X (workgroup: WORKGROUP)

... Output Deleted ...

Once the scan is complete, the hosts command can be used to query the database. For example, to list the address, hostname, operating system name, version and service pack, along with the state of the system of any known system, run

msf > hosts -c address,name,os_name,os_flavor,os_sp,state

Hosts

=====

address name os_name os_flavor os_sp state

------- ---- ------- --------- ----- -----

10.0.4.10 Coalsack.nebula.example Linux 2.6.X alive

10.0.4.11 Cone.nebula.example Linux 2.6.X alive

10.0.4.12 Pipe.nebula.example Microsoft Windows 7 alive

10.0.4.13 Snake.nebula.example Microsoft Windows 2008 alive

10.0.4.15 Boomerang.nebula.example Linux 2.6.X alive

The list of known services is found with the services command

msf > services

Services

========

host port proto name state info

---- ---- ----- ---- ----- ----

10.0.4.10 53 tcp domain open

10.0.4.10 139 tcp netbios-ssn open Samba smbd 3.X workgroup: WORKGROUP

10.0.4.10 445 tcp netbios-ssn open Samba smbd 3.X workgroup: WORKGROUP

10.0.4.11 53 tcp domain open ISC BIND 9.9.2-P1

10.0.4.11 139 tcp netbios-ssn open Samba smbd 3.X workgroup: WORKGROUP

10.0.4.11 445 tcp netbios-ssn open Samba smbd 3.X workgroup: WORKGROUP

10.0.4.12 53 tcp domain open ISC BIND 9.7.1

10.0.4.13 53 tcp domain open ISC BIND 9.8.0

10.0.4.13 5357 tcp http open Microsoft HTTPAPI httpd 2.0 SSDP/UPnP

10.0.4.15 22 tcp ssh open OpenSSH 5.3 protocol 2.0

Additional options for both the hosts and services command can be found by running either with the -h option. One very useful option is -S, which searches the database for the provided keywords. If coupled with the -R option, the list of all IP addresses matching the search criterion are automatically stored in the variable RHOSTS. For example, to search the database for all hosts running a DNS server and store the results in the RHOSTS variable, run the command:

msf > services -S domain -R

Services

========

host port proto name state info

---- ---- ----- ---- ----- ----

10.0.4.10 53 tcp domain open

10.0.4.11 53 tcp domain open ISC BIND 9.9.2-P1

10.0.4.12 53 tcp domain open ISC BIND 9.7.1

10.0.4.13 53 tcp domain open ISC BIND 9.8.0

RHOSTS => 10.0.4.10 10.0.4.11 10.0.4.12 10.0.4.13

Metasploit Scanning Modules

In addition to NMap integration, Metasploit also provides a number of stand-alone port-scanning modules located under auxiliary/scanner/portscan. These include auxiliary/scanner/portscan/tcp, which acts much like an NMap TCP connect scan. Other choices include an ack scan, an ftp bounce scan, and a XMAS scan.

Metasploit has additional modules for specialized scanning. For example, Metasploit has a scanner module to search for targets for DNS amplification attacks, named auxiliary/scanner/dns/dns_amp. Run it, and notice how the list of DNS servers found earlier through the database search already populates the RHOSTS variable.

msf > use auxiliary/scanner/dns/dns_amp

msf auxiliary(dns_amp) > info

Name: DNS Amplification Scanner

Module: auxiliary/scanner/dns/dns_amp

License: Metasploit Framework License (BSD)

Rank: Normal

Provided by:

xistence <xistence@0x90.nl>

Basic options:

Name Current Setting Required Description

---- --------------- -------- -----------

BATCHSIZE 256 yes The number of hosts to probe in each set

CHOST no The local client address

DOMAINNAME isc.org yes Domain to use for the DNS request

QUERYTYPE ANY yes Query type(A, NS, SOA, MX, TXT, AAAA, RRSIG, DNSKEY, ANY)

RHOSTS 10.0.4.10 10.0.4.11 10.0.4.12 10.0.4.13 yes The target address range or CIDR identifier

RPORT 53 yes The target port

THREADS 1 yes The number of concurrent threads

Description:

This module can be used to discover DNS servers which expose

recursive name lookups which can be used in an amplication attack

against a third party.

msf auxiliary(dns_amp) > set domainname google.com

domainname => google.com

msf auxiliary(dns_amp) > exploit

[*] Sending DNS probes to 10.0.4.10->10.0.4.13 (4 hosts)

[*] Sending 70 bytes to each host using the IN ANY google.com request

[+] 10.0.4.11:53 - Response is 551 bytes [7.87x Amplification]

[+] 10.0.4.12:53 - Response is 551 bytes [7.87x Amplification]

[+] 10.0.4.10:53 - Response is 551 bytes [7.87x Amplification]

[+] 10.0.4.13:53 - Response is 551 bytes [7.87x Amplification]

[*] Scanned 4 of 4 hosts (100% complete)

[*] Auxiliary module execution completed

This scan shows that each of these four nameservers can be used in a DNS amplification attack, resulting in a more than seven-fold increase in the amount of data transferred. Clearly someone needs to reread Chapter 4 and adjust their recursion settings!

Skill in cyber operations is about more than being able to use existing tools; practitioners need to be able to write customized tools to fit particular needs. Metasploit is written in Ruby, and can be expanded with new features.

Chapter 4 showed how to use DNS queries to determine the version of a BIND server. To build a custom Metasploit module that implements this feature, begin with the following Ruby script.

Script 5-1. Ruby code bind_ver.rb; this is a Metasploit module to scan a BIND DNS server for its version

require ’msf/core’

require ’net/dns/resolver’

class Metasploit3 < Msf::Auxiliary

include Msf::Auxiliary::Report

def initialize

super(

’Name’ => ’Simple BIND Version Scanner’,

’Version’ => ’$Revision: 1 $’,

’Description’ => ’Queries a BIND server for its version’,

’Author’ => ’Student’,

’License’ => MSF_LICENSE

)

register_options(

[

OptAddress.new(’RHOST’, [ true, "Specify the target nameserver" ])

], self.class)

end

def run

print_status("Running Scan against #{datastore[’RHOST’]}")

@res = Net::DNS::Resolver.new()

@res.nameserver=(datastore[’RHOST’])

query = @res.send("version.bind","TXT","CH")

if(query)

query.answer.each do |rr|

print_good("Reported BIND version = #{rr.txt}")

end

end

end

end

The script begins by loading some core Metasploit functions and a DNS library. The class structure follows Metasploit designs and the documentation at http://www.offensive-security.com/metasploit-unleashed/Writing_Your_Own_Scanner . The only option is the IP address of the target nameserver, and this data is required.

The run method begins by letting the user know the module has started. Next, it creates an instance of the Resolver class then passes the IP address of the target nameserver. The Resolver class is one of the Metasploit libraries, and its source code can be found on their GitHub repository at https://github.com/rapid7/metasploit-framework/blob/master/lib/net/dns/resolver.rb . A query is constructed and sent; the query sent is of class CH (rather than IN), and looks for the TXT information labeled version.bind. This is the same query used in Chapter 4 in the discussion of dig. The module reports back to the user each record returned in the query.

Store the script in the directory /usr/share/metasploit-framework/modules/auxiliary/scanner/dns/bind_ver.rb; this places it within the collection of Metasploit scripts. Provided it is in place when Metasploit is started, it can be used like any other Metasploit module.

root@kali:∼# msfconsole -q

msf > use auxiliary/scanner/dns/bind_ver

msf auxiliary(bind_ver) > info

Name: Simple BIND Version Scanner

Module: auxiliary/scanner/dns/bind_ver

License: Metasploit Framework License (BSD)

Rank: Normal

Provided by:

Student

Basic options:

Name Current Setting Required Description

---- --------------- -------- -----------

RHOST yes Specify the target nameserver

Description:

Queries a BIND server for its version

msf auxiliary(bind_ver) > set rhost 10.0.4.11

rhost => 10.0.4.11

msf auxiliary(bind_ver) > exploit

[*] Running Scan against 10.0.4.11

[+] Reported BIND version = 9.9.2-P1

EXERCISES

1.

Start a packet capture, and run nslookup from a Windows host and from a Linux host. What is the TTL in the IPv4 header from the packet sent from the Windows system? From the Linux system? This is just one component of the method NMap uses to identify a remote operating system. See http://nmap.org/book/osdetect-methods.html for more details.

2.

Run an NMap stealth scan against a target, specifying two TCP ports: one known open and one known closed. Capture the traffic between scanner and target. Identify the sequence of packets for the open and closed ports.

3.

Run an NMap connect scan against a target, specifying two TCP ports: one known open and one known closed. Capture the traffic between scanner and target. Identify the sequence of packets for the open and closed ports.

4.

Read the file /usr/share/nmap/nmap-services (from a Kali system). Sort the result to determine the top 100 TCP ports. Run a default stealth scan against a target using the fast (-F) option. Verify that the TCP ports in the top 100 are scanned, but those outside are not. Repeat the process with a UDP scan (-sU).

5.

Run a Metasploit scan using auxiliary/scanner/portscan/tcp specifying two TCP ports: one known open and one known closed. Capture the traffic between scanner and target. Identify the sequence of packets for the open and closed ports. Compare the results to an NMap stealth scan and an NMap connect scan.

6.

Compare the Metasploit module auxiliary/scanner/portscan/syn with auxiliary/scanner/portscan/tcp. Which is more reliable? A network packet capture is helpful.

7.

Compare an NMap ARP scan (-PR) to the Metasploit module auxiliary/scanner/discovery/arp_sweep to the Kali tool arping.

8.

Run the Metasploit module auxiliary/gather/dns_info against the DNS servers built in Chapter 4. Is it better than manual tools?

9.

Run the Metasploit module auxiliary/gather/dns_reverse_lookup against the DNS servers built in Chapter 4. How does it compare to a simple zone transfer?

10.

Run the Metasploit module auxiliary/gather/dns_bruteforce against the DNS servers built in Chapter 4. The wordlist used in the brute-force search is located at /opt/metasploit/apps/pro/msf3/data/wordlists/namelist.txt. Be sure that a host has a name in this wordlist, or modify the wordlist.

11.

Run the Metasploit module auxiliary/server/fakedns. How might it be useful?

12.

Modify the Metasploit module auxiliary/scanner/dns/bind_ver so that it reports the service to the database. Save the version of BIND in the info field.

Notes and References

The online documentation for NMap at http://nmap.org/ is excellent. Even so, the book

· Nmap Network Scanning: The Official Nmap Project Guide to Network Discovery and Security Scanning, Gordon “Fyodor” Lyon. The NMap Project, January 2009.

is a must-have book.

Another useful book is

· Nmap Cookbook: The Fat-free Guide to Network Scanning, Nicholas Marsh. CreateSpace Independent Publishing Platform (January 27, 2010).

This is a little bit more like a cookbook (hence the title) with recipes for a number of common activities. Though less detailed than Fyodor’s text, it is valuable.

The InfoSec Institute has an online three-part series on NMap that is also well worth reading.

· http://resources.infosecinstitute.com/nmap-cheat-sheet/

· http://resources.infosecinstitute.com/nmap-cheat-sheet-discovery-exploits-part-2-advance-port-scanning-nmap-custom-idle-scan/

· http://resources.infosecinstitute.com/nmap-cheat-sheet-discovery-exploits-part-3-gathering-additional-information-host-network-2/

For more information on how to create a custom Metasploit module, try Chapter 3 of the book

· Metasploit: The Penetration Tester’s Guide, David Kennedy, Gorman, Devon Kearns, and Mati Aharoni. No Starch Press, July 2011.

The documentation on the Metasploit GitHub at https://github.com/rapid7/metasploit-framework/wiki/How-to-get-started-with-writing-an-auxiliary-module is also helpful.

© Mike O'Leary 2015

Mike O'LearyCyber Operations10.1007/978-1-4842-0457-3_6