Overview

This document contains the analysis of the September scan. This is the first ever "beginners" Scan of The Month challenge.
 

Tools used

* nmap (http://www.insecure.org/nmap/)
* ethereal (http://www.ethereal.com/)
* ettercap (http://ettercap.sourceforge.net)

Before starting ...

Analysis was performed on a RedHat 7.2 machine.To begin the analysis, first it was necessary to download the gzipped archive, verify data integrity, then extract from the compressed archive:

1)Download and check md5 with web site

[bob@bob ~/reverse]$ md5sum sotm23.tar.gz
9d28c5ee9ce7b77e3099a07ad303811f  sotm23.tar.gz
The web site project.honeynet.org pages have the same MD5 (sotm23.tar.gz) = 9d28c5ee9ce7b77e3099a07ad303811f checksum. This means that gzipped tar archive that we downloaded was not modified during transmission and that will analyze the correct data (data integrity). This checksum doesn' t prove that the data is really coming from the honeynet project.  For this we would require a signed binary issued by a certificate authority that we can trust, i.e Verisign. Of course is possible that someone has modified the binary log file and the web page pages.

2) Verify archive

Before extracting any archive, I always check the content of the archive. I don't want to extract have archived with a full qualified path and overwrite some other files. 
[bob@bob ~/reverse]$ tar tvf sotm23.tar
-rw------- root/root  11998444 2002-08-27 02:27:32 0826@19-snort.log
-rw-r--r-- root/root        52 2002-08-27 02:30:58 0826@19-snort.log.md5
OK we can extract !

3) Extract and check archive

[bob@bob ~/reverse]$ tar xvf sotm23.tar
[bob@bob ~/reverse]$ cat 0826@19-snort.log.md5
0ce142f18c23d9ab00f992a57ad097d4  0826@19-snort.log
[bob@bob ~/reverse]$ md5sum 0826@19-snort.log
0ce142f18c23d9ab00f992a57ad097d4  0826@19-snort.log
This proves us that the data integrity of the file is not compromised or altered by someone.

Questions

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

The binary log file is a file that contains log informations and is saved in a binary format. The content of a binary log file can't be read with a normal editor, but with a program that can read the format. In our special case the binary log file is a tcpdump binary log.

We can probe this by entering following command: 

file 0826@19-snort.log
0826@19-snort.log: tcpdump capture file (little-endian) - version 2.4 (Ethernet, capture length 1514)
We can create the tcpdump capture file in different ways, for example directly listening on your network interface (tcpdump -w /tmp/output) or with the snort -r option (or snort.conf output log_tcpdump: snort.log).

Snort or tcpdump are the programs used for creating the 63832 packet log file and the best way to analyze them is by using Snort or ethereal. For this log I personally prefer ethereal, because we'll have an easily overview of scans. With Snort we could analyze the content as follow

snort -r 0826@19-snort.log -v -X -l . The command with ethereal is 

ethreal 0826@19-snort.log

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

An MD5 checksum that can probe the data integrity of the file. It's not possible, as far as I know, to modify the content or the attributes of a file without modifying the MD5 checksum.

From Cert: UNIX Security Checklist v2.0 (http://www.cert.org/tech_tips/usc20_full.html)
MD5 is a message digest algorithm. Tools to verify MD5 checksums are included with many current operating systems, for example md5(1) (FreeBSD) or md5sum (Linux). Otherwise, an implementation of MD5 is available via anonymous FTP from: ftp://coast.cs.purdue.edu/pub/tools/unix/crypto/md5/

3.What is the attacker's IP address?

IP: 192.168.0.9
MAC: 00:10:a4:c5:7c:38 Xircom NIC
The MAC address contains the value of the latest hub that the packet traversed. Generally you can't use this information, but in this simple binary log I think that this is the real MAC address of the attacked/attacker

4.What is the destination IP address?

IP: 192.168.0.99
MAC: 00:60:08:a8:61:24  3Com NIC

Both are RFC 1918 private address range. The Internet Assigned Numbers Authority (IANA) has reserved the following three blocks of the IP address space for private networks: 

10.0.0.0        -   10.255.255.255  (10/8 prefix)
172.16.0.0      -   172.31.255.255  (172.16/12 prefix)
192.168.0.0     -   192.168.255.255 (192.168/16 prefix)

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?

Sometimes the scan sequence is started with following 4 packets:

192.168.0.9 > 192.168.0.99: icmp: echo request
192.168.0.99 > 192.168.0.9: icmp: echo reply
192.168.0.9.42314 > 192.168.0.99.http: . ack 2866936176 win 4096
192.168.0.99.http > 192.168.0.9.42314: R 2866936176:2866936176(0) win 0 (DF)

You can insert the icmp filter in the ethereal field and then you'll find out some beginning and the end of the some types of  scans:

Ethereal filter icmp

Packet number
1         192.168.0.9 > 192.168.0.99: icmp: echo request
2         192.168.0.99 > 192.168.0.9: icmp: echo reply
148007    192.168.0.9 > 192.168.0.99: icmp: echo request
148008    192.168.0.99 > 192.168.0.9: icmp: echo reply
150655    192.168.0.99 > 192.168.0.9: icmp: 192.168.0.99 udp port tcpmux unreachable [tos 0xc0]
150753    192.168.0.9 > 192.168.0.99: icmp: echo request
150754    192.168.0.99 > 192.168.0.9: icmp: echo reply
153165    192.168.0.99 > 192.168.0.9: icmp: 192.168.0.99 udp port tcpmux unreachable [tos 0xc0]
155847    192.168.0.99 > 192.168.0.9: icmp: 192.168.0.99 udp port tcpmux unreachable [tos 0xc0]
155987    192.168.0.1 > 192.168.0.99: icmp: echo request
155988    192.168.0.254 > 192.168.0.99: icmp: echo request
155989    192.168.0.199 > 192.168.0.99: icmp: echo request
155990    192.168.0.199 > 192.168.0.99: icmp: echo request
 

5.1 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.If a SYN|ACK is received, a RST is immediately sent to tear down the connection.
Example packet #: 18331

For checking this the best way is to create an Ethereal filter: 

(ip.addr eq 192.168.0.9 and ip.addr eq 192.168.0.99) and (tcp.port eq 52198)
and (tcp.flags.syn==1) and (tcp.flags.ack==1)
5.2 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
Example packet #:150383

5.3 The Null scan turns off all flags, Sequence number 0 , Ack 0  and all TCP flags = 0
This scan is starting from packet  148007
Example packet :148011

5.4 Stealth  FIN  scan  uses  a bare (surprise) FIN packet as the probe
Example packet #:150639

5.5 Xmas Tree scan modes turns on the FIN, URG, and PUSH flags
Example packet #:158068

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

Nmap (http://www.insecure.org/nmap/) and ping scanning:
If you check the first four packets you'll see a ICMP ping request and a TCP ack packet to port 80. If we get an RST back, that machine is  up. This is the default behavior of nmap and ping scanning. (s. man pages).
Other sign of the usage of nmap, is the behavior of some TCP/IP settings: no default TTL, window size,...
 

7.What is the purpose of port scanning?

The purpose of a port scanning is to determine which hosts are up and what services they are offering. This is generally speaking the first step for an attacker (information gathering). After you'll found out what services and  versions you're running you download the correct exploits and you probably get in the server sooner or later ...
 

8.What ports were found open on our honeypot?

Is used following filter in ethereal (TCP)

(ip.src eq 192.168.0.99) and (tcp.flags.syn eq 1) and (tcp.flags.ack eq 1)

OPEN PORTS  (tcp)
ssh (22)
sunrpc (111 portmapper)
32768 (generally rpc.stad)
http (80)
https (443)
domain (53)

Is used following filter in ethereal (UDP)

(ip.src eq 192.168.0.99) and (ip.proto eq 17)

OPEN PORTS  (udp)   : NONE

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

This is probably the most difficult question, because nmap spoof the TCP/IP settings. I supposed from the start that the attacker was a Linux box., but I could not found a 100% certitude of my assumptions.
Interesting reading about this subject are:

* http://www.insecure.org/nmap/nmap-fingerprinting-article.txt (for active OS fingerprint)
* http://www.stearns.org/p0f/index.html (for passive OS fingerprint)

One can can suppose that we have a Linux server after the first SYN/ACK packet received (example packet number 18332)

IP header
-------------
TTL = 64

TCP header
---------------
Window size = 5840
Maximum Segment Size = 1460
Options= set MSS,timestamps sack OK Wscale and 1 NOP
Packet length = 60

I also used the ettercap (http://ettercap.sourceforge.net) tool with option -T

ettercap -T 0826@19-snort.log

and suggestion is Linux 2.4.0 - Linux 2.4.18 for the attacker and the the same for the attacked server.

Boris Bellorini; Dipl. Inf; Consultant; eSecurity
http://www.honeynet.ch
 _____    _             _ _        _   ___
|_   _| _(_)_ ____ _ __| (_)___   /_\ / __|
  | || '_| \ V / _` / _` | (_-<  / _ \ (_ |
  |_||_| |_|\_/\__,_\__,_|_/__/ /_/ \_\___|