Scan of the Month Challenge 23 Analysis

The Honeynet Project Scan of the Month
Challenge 23 for September 2002
Analysis by Nick DeBaggis <lucky at ncounty dot net>
September 18, 2002

Summary

Tools

Methodology

Questions

References

Appendix

Thanks

Summary

Port scans are used to map out a network's or host's available services and may be a precursor to a more advanced attack. Using an Intrusion Detection System and/or Packet Capture software, the victim of a port scan can gather and analyze the evidence generated by an attacker. Although the scans in this challenge did not originate "in the wild", they will provide us an excellent view into the methodologies used in analyzing this type of reconnoissance.

Members of the South Florida Honeynet Project initiated five different port scans from the Internet to a single honeypot host using one of the most popular Open Source port scanners: Nmap. The libpcap binary log file contains all of the answers to this challenge; this is the evidence that will tell the attacker's story.

One of the port scanning methods chosen by the attacker was significant to answering the bonus question for this challenge. The assumption that we can determine the attacker's Operating System at all, gives us some information on at least one of the scans performed.  Because Nmap was used in this scan, we can assume at least one of the scans had to be a plain TCP connect scan (Nmap's default for unprivileged users).  Nmap does custom packet manipulation for stealth (privileged) scanning and OS detection. The packets from a stealth scan look unlike those created by the underlying OS, thus a stealth scan gives little indication of the attacker's OS. Using well known Open Source network analysis tools and custom Perl scripts, we will analyze the Beginner's Challenge and extract the information needed to answer the challenge questions.

The tools used to analyze the challenge consisted mainly of the well known network analysis tools suggested for the challenge. Several "on-the-fly" perl scripts were created for summarization of the scan traffic.

Tools

• snort
• ethereal
• tethereal
• nmap
• p0f

Scripts

• sumsrcdst
• sumports
• sumflags
• sump0f
• sumalerts
• sumtiming
• sumscanports
• dostats
• splitscans

Methodology

Copy the MD5 hash for this challenge from the Honeynet web site into a new text file named sotm23.tar.gz.md5 and rearrange it into a valid md5sum output:

9d28c5ee9ce7b77e3099a07ad303811f  sotm23.tar.gz

download the sotm23.tar.gz challenge archive into the same directory and verify the MD5 hash of the archive:

$ md5sum -c sotm23.tar.gz.md5

unpack the archive if it verified ok:

$ tar xzf sotm23.tar.gz

verify the unpacked binary log file based on the supplied MD5 hash that is packed with the log:

$ md5sum -c 0826\@19-snort.log.md5

If the archive and the binary log verify ok, then we are ready to start analyzing, otherwise there is a possibility that the archive or log has been tampered with.

Loading the binary log into Ethereal immediately reveals an ICMP echo request probe, a TCP port 80 ACK probe, and a stream of TCP SYN probes to the IP address 192.168.0.99; this is potentially the victim host. The ICMP echo request and TCP port 80 ack probe is indicative of an Nmap scan using the -PB option.  We can take a summarized look at the source to destination activity with a small perl script and tethereal as root:

# tethereal -nr 0826\@19-snort.log | ./sumsrcdst > traffic.stats

Note: the following tables are htmlized versions of the script output, see the appendix for the actual script output.

Protocol Statistics (traffic.stats)

Four different hosts are generating traffic to 192.168.0.99, but interestingly only 192.168.0.9 is responded to. Let's assume that 192.168.0.99 is indeed the victim host honeypot. Although the summary shows four IPs connecting to 192.168.0.99, let's assume all four as a single attacker for now; we make this assumption because the victim did not respond to the other hosts.  This is an indication of another of Nmap's scanning techniques: spoofed decoy scans.

Splitting the log into attacker and victim will allow us to better analyze both ends of the scan using the ethereal front end and other analysis tools:

# tethereal -nr 0826\@19-snort.log "ip.src != 192.168.0.99" -w attacker.log
# tethereal -nr 0826\@19-snort.log "ip.src == 192.168.0.99" -w victim.log

Let's summarize the different TCP flags based on attacker probes and victim responses, this may give a hint as to what scanning methods were used:

# tethereal -nr attacker.log | ./sumflags > flags.attacker
# tethereal -nr victim.log | ./sumflags > flags.victim

TCP Flags Statistics (flags.victim)

Starting with flags.victim, it is apparent that the victim machine responded correctly with SYN,ACK to some of the attacker's probes. SYN,ACK indicates that some service is listening on the victim because this is part two of the TCP initial three-way handshake for connection establishment.

We can summarize these flags as potential open ports on the victim by filtering and summarizing based on SYN,ACK:

# tethereal -nr victim.log "tcp.flags == 0x12" | ./sumports > openports.victim

Open Port Statistics (openports.victim)

There is a good chance this is what the attacker's scanner spit out for scanning results of open TCP ports on the victim.

Let's go ahead and run the original snort log through snort and see what comes up. Since snort has many port scanning signatures, we may get confirming proof of the tool used to perform the scan:

# snort -r 0826\@19-snort.log -c /etc/snort/snort.conf

Examining the resultant alert file in /var/log/snort shows that the nmap port scanner was used in this scan. We also have indications of the types of scans performed; namely, nmap XMAS scan and NULL scan. We can summarize the scans looking for nmap, null, and xmas:

# ./sumalerts /var/log/snort/alert > alerts.stats

The output shows us a summary for several of the scan types in the alert file:

Statistics
[**] [111:10:1] spp_stream4: STEALTH ACTIVITY (nmap XMAS scan) detection [**] - 22539
[**] [111:9:1] spp_stream4: STEALTH ACTIVITY (NULL scan) detection [**] - 3996
[**] [111:12:1] spp_stream4: NMAP FINGERPRINT (stateful) detection [**] - 9
[**] [1:628:1] SCAN nmap TCP [**] - 9

Moving on to flags.attacker (we generated this file earlier), we can match up the various flags combinations and summarized alerts with the scanning techniques from the nmap man page. This will help us determine exactly what scans were performed. Browsing with ethereal will allow us to see what order they were performed in.

TCP Flags Statistics (flags.attacker)

From the nmap man page and the nmap OS fingerprinting article, a table can be formed of the different possible scans:

Using the attacker.log we created previously, we can do some statistics on the time delta between attacker packets, this will help to understand the possible nmap timing options used during the scans:

# tethereal -nr attacker.log | ./sumtiming > timings.stats

From the output below we can see the vast majority of packets have a time delta of less than 0.1 seconds from the previous packet (rounding to the nearest 0.1 seconds), in fact, the bulk of these packets had a time delta of 0.000113 seconds or less. There's a good number of packets with a time delta of 0.3 seconds, this is significant; nmap's timing option "-T Insane" is described as having these attributes in the nmap man page. Most of the packets with delta 0.3 seconds were from scan 1, these were possibly from the heavy network load on the victim. These packets account for approximately 20 minutes of the total scan time.

(timings.stats):

Packet Delta Statistics

Delta                Count Percent
----------------------------------
  0.0                80053  94.89%
  0.1                   28   0.03%
  0.2                   29   0.03%
  0.3                 4172   4.95%
  0.4                    3   0.00%
  0.6                    8   0.01%
  0.7                    1   0.00%
  0.8                   23   0.03%
  1.1                    1   0.00%
  1.4                    1   0.00%
  1.5                    2   0.00%
  1.8                    6   0.01%
  1.9                    1   0.00%
  2.3                    1   0.00%
  2.4                    1   0.00%
  2.5                    2   0.00%
  2.8                    2   0.00%
  3.0                    7   0.01%
  3.8                    1   0.00%
  4.4                    2   0.00%
  5.2                    1   0.00%
  5.4                    1   0.00%
  6.1                    1   0.00%
  7.4                    1   0.00%
  7.9                    1   0.00%
  8.4                    2   0.00%
 10.3                    3   0.00%
 19.6                    1   0.00%
 20.2                    1   0.00%
 29.2                    1   0.00%
 37.7                    1   0.00%
 43.6                    1   0.00%

Examining the original snort log in ethereal, we can determine scan boundaries by examining the changes in packet flags, protocol, and time delta to determine the scan boundaries (there are some response packets from the victim that overlap scans). Taking note of the starting and ending frame numbers for each scan will allow us to summarize what ports the attacker was scanning for on each scan:

# tethereal -nr 0826\@19-snort.log \
  "frame.number < 148007 && tcp && ip.src != 192.168.0.99" \
  | ./sumscanports > scan1.ports

# tethereal -nr 0826\@19-snort.log \
  "frame.number > 148006 && frame.number < 150753 && tcp && ip.src != 192.168.0.99" \
  | ./sumscanports > scan2.ports

# tethereal -nr 0826\@19-snort.log \
  "frame.number > 150752 && frame.number < 153251 && tcp && ip.src != 192.168.0.99" \
  | ./sumscanports > scan3.ports

# tethereal -nr 0826\@19-snort.log \
  "frame.number > 153250 && frame.number < 155987 && tcp && ip.src != 192.168.0.99" \
  | ./sumscanports > scan4.ports

# tethereal -nr 0826\@19-snort.log \
  "frame.number > 155986 && tcp && ip.src != 192.168.0.99" \
  | ./sumscanports > scan5.ports

The results show that scan1 was a full port sweep from 1-65535, scan3 was a well-known port sweep from 1-1024, and the remainder are fast scans using nmap's supplied services file.

Scanned ports results:

scan1.ports

scan2.ports

scan3.ports

scan4.ports

scan5.ports

Finally, we can construct some potential nmap command lines used by the attacker.  These are based on all the above data and a healthy dose of manual log examination using the ethereal front end.

Scan 1: syn stealth, ping both, ports 1-65535, insane timing - packets 1 - 148006. Scan time: 21 minutes, 45 seconds.

# nmap -sS -PB -p 1-65535 -T Insane 192.168.0.99

Scan 2: null scan, ping both, fast ports, os detect, insane timing - packets 148007 - 150752. Scan time: 2 minutes, 12 seconds.

# nmap -sN -PB -F -O -T Insane 192.168.0.99

Scan 3: xmas scan, ping both, ports 1-1024, os detect, insane timing - packets 150753 - 153250. Scan time: 1 minute, 24 seconds.

# nmap -sX -PB -p 1-1024 -O -T Insane 192.168.0.99

Scan 4: connect scan, no ping, fast ports, os detect, insane timing - packets 153251 - 155986. Scan time: 1 minute, 38 seconds.

# nmap -sT -P0 -F -O -T Insane 192.168.0.99

Scan 5: xmas scan, ping both, fast ports, insane timing, spoofed decoy IPs - packets 155987 - 163832. Scan time: 59 seconds.

# nmap -sX -PB -F -T Insane -D 192.168.0.1,192.168.0.254,192.168.0.199 192.168.0.99

or using the ME option:

# nmap -sX -PB -F -T Insane -D 192.168.0.1,192.168.0.254,ME,192.168.0.199 192.168.0.99

The fourth scan is a plain TCP connect scan.  The packets in this scan have certain attributes set that are specific to the underlying OS.  The Project Honeynet's passive os fingerprinting article gives us excellent information on how to determine the attacker's OS. Examining the packets from this scan segment gives us several key values:

window size: 5840

time to live: 64

maximum segment size: 1460

window scaling: 0

SACK flag: on

with these flags and the p0f passive OS fingerprint identifier, we can determine the remote attacker's OS with a fairly high probability.  Since it is easiest to just run the attacker.log capture through p0f let's do that and summarize the output as well:

# p0f -s ./attacker.log | ./sump0f > attacker.os

this results in the answer to the bonus question (attacker.os):

Statistics
192.168.0.9 [12 hops]: NMAP scan (distance inaccurate) (7) 73958
192.168.0.9 [1 hops]: Linux 2.4.2 - 2.4.14 (1) 1283
192.168.0.9 [17 hops]: NMAP scan (distance inaccurate) (2) 9
192.168.0.9 [26 hops]: NMAP scan (distance inaccurate) (11) 9
192.168.0.9 [21 hops]: NMAP scan (distance inaccurate) (2) 9

It appears the attacker is running a Linux box with kernel version 2.4.2 - 2.4.14.  Although the TCP connect scan that generated these packets is the default for non root users, the user who initiated this scan was running as root because OS detection was turned on for this scan and thus required root privileges.

Questions

What is a binary log file and how is one created?

The snort binary log file was created using the Snort Intrusion Detection System.  The log is a snapshot of the network traffic passing through some interface on the host machine, or perhaps on some promiscuous mode interface on the same network hub.  The traffic is parsed by snort and can be acted on in many ways: logged, alerted, captured, etc.  Libpcap supplies the underlying function libraries and data structures to allow for this type of network traffic capture.  Tcpdump and Ethereal can create and read these binary log files as well.  Having a standard log file format and function library allows us to use many different tools to analyze a single log capture.

What is MD5 and what value does it provide?

The MD5 hashing algorithm is a cryptographically secure, one-way hash function which computes a 128 bit hash (or fingerprint) of some arbitrary length message, or data stream. The hash is stored securely, the message or data is then transmitted and later hashed again to determine if it is indeed identical to the original message.  The comparison of hashes allows us to determine the integrity of the message since no two unique messages will hash to the same value and a message can not be computed from the hash; if the hashes are the same, the data must be the same as well. Thus, the integrity of our snort binary capture is based on the security of the Honeynet web site since this is where the initial MD5 hash is stored. Md5sum is used to create and verify hashes of data based on this algorithm.

What is the attacker's IP address?

The attacker uses the IP address 192.168.0.9 as well as three spoofed decoy addresses: 192.168.0.1, 192.168.0.199, and 192.168.0.254.

What is the destination IP address?

The victim uses the IP address 192.168.0.99.

We scanned the honeypot using five different methods. Can you identify the five different scanning methods, and describe how each of the five works?

Syn stealth scan - sends TCP SYN packets to the target and resets the connection immediately to avoid detection.  Tearing down the connection right away helps to avoid logging of the traffic so that detection may be minimized.  At the minimum, it will obscure the attacker's OS.

Null scan with OS detection - sends TCP packets with no flags set hoping to bypass firewalls.  OS detection sends seven tests with various flags and options set to determine OS type and version based on response or non-response from the host.

Xmas scan with OS detection - sends TCP packets with FIN, URG, and PUSH set hoping to bypass firewalls.  Basically the same as null scan but with flags set.

Connect scan with OS detection - OS sends TCP connect packets. The underlying OS creates these packets, hence our ability to passive-fingerprint the attacker. Nmap creates the OS detection packets.

Xmas scan with spoofed decoys - sends the Xmas scan with decoy IP addresses to obscure the real attacker's source.  The decoy scan randomly places the real IP within the decoy IPs unless the ME option is used to statically choose the position relative to the decoy IPs. (see nmap command lines at the end of Methodology).

Which scanning tool was used to scan our honeypot? How were you able to determine this?

Fyodor's Nmap port scanner was used.  Nmap has a distinct scanning signature and scanning options which made it stand out in the packet capture.  Snort and p0f were able to identify the attacker's packets as being created with nmap.

What is the purpose of port scanning?

Port scanning is often used to map out a host's or network's available services. An attacker can use the results of a port scan to narrow down the potential exploitation paths on some host. Port scanning is also used to determine the remote OS type and version using tcp fingerprinting techniques . Having the open ports and OS type of a system gives the attacker a very specific target to concentrate on, thus making it much easier to identify a vulnerable exploit path. System / Security Professionals often use port scanning to assist in securing the systems they maintain.  Naturally, having detailed knowledge of your network and its resources is one of the first steps you should take to securing it properly.

What ports were found open on our honeypot?

Based on SYN,ACK responses from the victim, it appears that the following ports are open:

TCP 22 - ssh

TCP 53 - named

TCP 80 - http

TCP 111 - sunrpc

TCP 443 - https

TCP 32768 - ?

Bonus Question: What operating system was the attacker using?

The attacker is running a Linux box with kernel version 2.4.2 - 2.4.14

References & Resources

Nmap man page

Ethereal man page

Snort man page

Nmap OS fingerprinting article

Passive OS fingerprinting article

MD5 hashing algorithm

Perl

Protocols.com - TCP/IP

TCP RFC

IP RFC

ICMP RFC

Appendix

File listing for the challenge entry

Scripts
-------
scripts/dostats                     bash, create all output files.
scripts/sumsrcdst                   perl, summarize src -> dst traffic
scripts/sumalerts                   perl, summarize snort alerts
scripts/sumflags                    perl, summarize TCP flags
scripts/sumports                    perl, summarize open ports
scripts/sumscanports                perl, summarize scanned ports
scripts/sumtiming                   perl, summarize packet timings
scripts/sump0f                      perl, summarize reverse OS detection
scripts/splitscans                  bash, split scans to sep. files

Output files
------------
scripts/traffic.stats               src -> dst traffic summary
scripts/flags.attacker              TCP flags found in attacker's traffic
scripts/flags.victim                TCP flags found in victim's traffic
scripts/openports.victim            open ports on the victim
scripts/alerts.stats                snort alerts summary
scripts/timings.stats               attacker packet timing summary
scripts/scan1.ports                 ports scanned for scan 1
scripts/scan2.ports                 ports scanned for scan 2
scripts/scan3.ports                 ports scanned for scan 3
scripts/scan4.ports                 ports scanned for scan 4
scripts/scan5.ports                 ports scanned for scan 5
scripts/attacker.os                 attacker's OS
scripts/attacker.os.packet.txt      single packet showing OS specific flags
scripts/nmap-commandlines.txt       commandlines used by attacker

Thanks

Thanks to all of the Honeynet Project members and the Open Source community. This was a great challenge for us to learn from and experiment with.

N. DeBaggis