Beginners Scan of the Month Challenge
Richard La Bella, South Florida Honeynet Project
SotM #23
September 30, 2002

 

 

Introduction

This was the first beginner scan of the month challenge. This challenge took place during the month of September 2002. The South Florida Honeynet team manually generated five different types of portscans from the Internet to a single honeypot. The portscans were captured to a binary log file in tcpdump format. The challenge was to answer eight questions plus a bonus question by decoding the analyzing the binary file. The South Florida Honeynet Project and the Honeynet Research Alliance congratulate everyone who took a stab at this challenge. You all did great.

 

Our Analysis

We used the following tools and binaries to help us analyze the binary log file on a Red Hat Linux 7.3 system running kernel 2.4.18-3.

 

Step 1

Before we can answer any of the Challenge questions we must first download the binary log file to our system using the "wget" command:

# wget http://www.honeynet.org/scans/scan23/sotm23.tar.gz

 

Step 2

Next, we must verify the integrity of the sotm23.tar.gz file we just downloaded by running a command known as "md5sum" on Red Hat Linux to verify the hash.

# md5sum sotm23.tar.gz
 

The resulting output returned back to us looks like so:

# 9d28c5ee9ce7b77e3099a07ad303811f sotm23.tar.gz

 

Now let's compare the md5sum from the Challenge page where we downloaded the file from to our output above. We go back to http://www.honeynet.org/scans/scan23 to check if  the results match. They do. So far everything looks good.

 

Step 3

At this point, we can unpack and verify the archive.

# tar zxvf sotm23.tar.gz

Two files were successfully unpacked. They are:

1. 0826@19-snort.log
2. 0826@19-snort.log.md5

The first one is the binary log file we are going to use during our analysis. The second one is an md5 hash of the binary log file.

 

Step 4

Let's verify the checksum of the snort.log binary file. Remember, we do this to check the integrity of files. Specifically the 0826@19-snort.log file just like we did with the archive file in Step 2.

# md5sum 0826@19-snort.log
# 0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log

 

Let's compare our output with the md5 hash file-0826@19-snort.log.md5-created by the South Florida Honeynet Project.

# cat 0826@19-snort.log.md5
# 0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log

As we can see from our work above the integrity of the snort binary file is in good standing. Now, we can get started with our analysis and begin the Challenge.

 

 

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

A binary log file is a file capture of binary data 1's and 0's. Binary logging is sometimes referred to as "raw" traffic capture because we are capturing packets in their most raw form (ones and zeros). For network intrusion detection systems placed in high traffic areas of a network, binary capture is much more beneficial. (1) We are in a better position not to lose packets during the capture phase, and (2) binary files are lower in size than say, an ASCII text file. Traffic can be captured in binary form using a promiscuous mode interface, a hub, a tap, or from a span port off a router or switch. The underlying functionality used to capture traffic off the wire is a packet capture library known as the Libpcap library. Libpcap is a standard library used for sniffing traffic on a network segment using tcpdump, snort, and ethereal. A windows version of the libpacp library is winpcap. This allows us to run tools like Ethereal and Snort  in a Windows environment as well.

To create a binary log file using Snort:

# snort -l /var/log/snort -b

To read the file back:

# snort -vde -r snort.log

 

To create a binary log file using tcpdump:

# tcpdump -w ./log

To read the file back:

# tcpdump -r log

 

To create a binary log file using Ethereal at the command line:

# tethereal -w log

To read the file back on the command line:

# tethereal -r log

You can use Ethereal's GUI to read binary log files as well. Just type ethereal at the command line to run the GUI version of Ethereal.

 

 

2. What is MD5 and what value does it provide?

Taken from RFC1321:
The MD5 algorithm takes as input a message of arbitrary length and produces as output a 128-bit "fingerprint" or "message digest" of the input. It is conjectured that it is computationally infeasible to produce two messages having the same message digest, or to produce any message having a given prespecified target message digest. The MD5 algorithm is intended for digital signature applications, where a large file must be "compressed" in a secure manner before being encrypted with a private (secret) key under a public-key cryptosystem such as RSA.

The value MD5 provides is one-way hashing used to cryptographically secure the integrity and authenticity of a message, data, a file, etc.

 

 

3. What is the attacker's IP address?

To figure out what the attacker IP address is we opened up the binary log file into Ethereal. We can see right away the source IP of our attacker is 192.168.0.9 due to the ICMP ECHO request, HTTP ACK, and SYN flag scans sent to the victim, 192.168.0.99. Ping's or ICMP ECHO Requests are common tactics used to test if a host is up or responding to ICMP. 192.168.0.9 is our attacker.

 

 

4. What is the destination IP address?

The destination IP address is 192.168.0.99. By still observing the first five scans in Ethereal we can confirm the destination IP.

 

 

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

Scan #1- SYN Scan
# nmap -sS -p 1-65535 192.168.0.99
Resource: http://www.nmap.org


TCP SYN scan: This technique is often  referred  to as  "half-open"  scanning, because you don't open a full TCP connection. You send a SYN packet,  as  if you  are  going  to  open a real connection and you wait for a response. A SYN|ACK indicates  the  port is  listening.  A  RST  is indicative of a non-listener.  If a SYN|ACK is received, a RST is  immediately  sent  to  tear down the connection (actuallyour OS kernel does this for us). The primary advantage to this scanning technique is that fewer sites will log it.  Unfortunately you  need  root  privileges  to  build these custom SYN packets.  This is the default scan type for privileged users.

 

Scan #2- NULL Scan with O/S Detection
# nmap -sN -F -O 192.168.0.99
Resource: http://www.nmap.org

Scan #3-XMAS Scan with O/S Detection
# nmap -sX -p 1-1024 -O 192.168.0.99
Resource: http://www.nmap.org


Stealth FIN, Xmas Tree, or Null scan  modes:  There are  times when even SYN scanning isn't clandestine enough. Some firewalls and packet filters watch for SYNs to restricted ports, and programs like Synlogger and Courtney  are  available  to  detect  these scans. These advanced scans, on the other hand, may be able to pass through unmolested.

The idea is that closed ports are required to reply to  your probe packet with an RST, while open ports must ignore the packets in question (see RFC 79364).   The  FIN  scan  uses  a  bare (surprise) FIN packet as the probe, while the Xmas tree scan turns on  the  FIN,  URG,  and PUSH flags.  The Null scan turns off all flags.  Unfortunately Microsoft (like usual)  decided  to  completely ignore the standard and do things their own way.  Thus this  scan  type will not work against systems running Windows95/NT. On the positive side, this is a good way to distinguish between the two platforms.  If the scan finds open ports, you know the machine is not  a  Windows box.   If  a  -sF,-sX,or  -sN  scan shows all portsvclosed, yet a SYN  (-sS)  scan  shows  ports  being opened,  you are probably looking at a Windows box. This is less useful now that  nmap  has  proper  OS detection  built  in.   There  are also a few other systems that are broken in the same way Windows is. They  include  Cisco,  BSDI,  HP/UX, MVS, and IRIX. All of the above send resets from  the  open  ports when they should just drop the packet.
 

Scan #4-TCP Connect Scan with O/S Detection
# nmap -sT -PT -F -O 192.168.0.99
Resource: http://www.nmap.org

 

TCP connect() scan: This is the most basic form  of TCP scanning. The connect() system call provided by your operating system is used to open a  connection to  every  interesting  port on the machine. If the port is listening, connect() will  succeed,  otherwise the port isn't reachable. One strong advantage to this technique is that you don't need  any  special  privileges.  Any  user  on most UNIX boxes is free to use this call. This sort of scan is easily  detectable  as  target host logs will show a bunch of connection and error messages for the services which accept()  the  connection just to have it immediately shutdown.  This is the default scan type for unprivileged users.
 

The -O  option used in Scan #2, Scan #3, and Scan #4 are used for remote host identification via TCP/IP fingerprinting.  In other words, it uses a  bunch  of techniques to detect subtleties in the underlying operating system network  stack  of  the computers  you are scanning.  It uses this information to create a ´fingerprint´  which  it  compares with  its  database  of  known OS fingerprints (the nmap-os-fingerprints file) to decide what  type  of system you are scanning.

 

Scan #5-XMAS Scan with Spoofed Decoys
# nmap -sX -F -D 192.168.0.1, 192.168.0.254, 192.168.0.199 192.168.0.99
Resource: http://www.nmap.org

 

-D Causes  a decoy scan to be performed which makes it appear to the remote  host  that  the  host(s)  you specify  as  decoys are scanning the target network too.  Thus their IDS might report 5-10  port  scans from unique IP addresses, but they won't know which IP  was  scanning  them  and  which  were  innocent decoys.   While this can be defeated through router path tracing, response-dropping, and other "active" mechanisms,  it is generally an extremely effective technique for hiding your IP address.

 

 

6. What scanning tool was used to scan our honeypot?

I made this part easy for myself. I ran the snort.log binary file through our Snort NIDS using the ACID console database. This way the snort.conf file would know exactly what to do with the alerts. In our case the snort.conf file was configued to log all alerts to our snort MySQL database where could view the file through ACID. ACID is known as the Analysis Console for Intrusion Databases.

# snort -vde -r 0826@19-snort.log -c /usr/local/snort/eth3/snort.conf

After searching the database for a while, I clicked on "unique alerts". Unique alerts showed me a total of six (spp_stream4) NMAP FINGERPRINT (stateful) detection signatures, and six SCAN nmap TCP attempted-recon. At this point I could be very confident the tool used was Nmap.

 

 

7. What is the purpose of port scanning?

The purpose for port scanning is to identify listening ports on a target system. This can be done for both good and evil. The good guys and girls will portscan a system to find unnecessary listening ports that don't need to be listening. Those ports can be closed to help protect the system from unneccessary compromise or enumeration. The evil guys and gals will port scan thousands of systems until they find a port that is exploitable then try to take over that system.

 

 

8. What ports were found open on our honeypot?

Simply by running a filter in Ethereal we could view which ports were open on our honeypot. The following filter shows all the SYN | ACK's sent back to our attacker from the victim machine.

The filter is:

tcp.flags = = 18

 

The following ports that answer with a SYN | ACK back to the attacking machine are as follows:
 

 

 

9. Bonus Question: What Operating system was the attacker using?

The attacker is running Linux with kernel version 2.4.2 - 2.4.14. We were able to figure this out after reading the Honeynet Projects paper, Know Your Enemy: Passive Fingerprinting and then examining the database of a passive fingerprinting tool known as p0f. In Know Your Enemy: Passive Fingerprinting the Honeynet Project points out the following parameters as being key for discovering our enemy's O/S.

After looking at p0f's passive fingerprinting database, p0f.fp we collected the following information until we could make a match. For example:

TTL                    64
Window Size       5840
MSS                   1460
DF                      1 = on
Window Scaling  0
sackOK             Permitted
nop                    1
declared packet "? only one we could not find"

Next, we compared the parameters from our enemy's packets to the p0f.fp database and found that the signature above is that of Linux 2.4.2 - 2.4.14 (1).

 

 

For questions, comments and suggestions please send correspondences to richard@sfhn.net.