Scan 23 Thorsten Zachmann T.Zachmann@zagge.de Analysis -------------------------------------------------------------------------------- First of all I downloaded the file sotm23.tar.gz and checked the md5sum of the file with > md5sum sotm23.tar.gz 9d28c5ee9ce7b77e3099a07ad303811f sotm23.tar.gz as this is the same as on the web page I continued with un-zipping it, with > tar xzf sotm23.tar.gz which gave me the files 0826@19-snort.log and 0826@19-snort.log.md5. So I once more checked the md5sum of the file > md5sum 0826\@19-snort.log 0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log > cat 0826\@19-snort.log.md5 0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log As both are the same the file 0826@19-snort.log is ok. then I opened the file in ethereal > ethereal 0826@19-snort.log After half an hour later the file was finally loaded and I could start to look at the trace. First I tried to identify the five different scans so I could separate them in separate files. The first scan started with ICMP Echo request which was answered and a TCP packages to port 80 with ACK flack set, which was answered by a TCP package with RST flag set. This looks like a probe to see if the host is up. As both get answered the scanning host knows that the scanned host is up. Here also the IP address of the attacker: 192.168.0.9 and the scanned host: 192.168.0.99 can be seen. Then at 10.346901 (all times are relative to the first package) the scanning host started to send TCP packages with the SYN flag set. If the port is closed this packages will be answered by a packages with RST/ACK flags set. So I set up the colourizing for TCP packages with the SYN, RST/ACK set. The filter rules in ethereal are the following tcp.flags == 2 (SYN) tcp.flags == 20 (RST/ACK) With this colour scheme it is very easy to see when the pattern of the scan changes. The scheme changed at 1274.602300. The first scan was done from 0 to 1245.354017. The second scan started at 1274.602300. Again a ICMP and TCP probing was done. Then at 1284.924394 the attacker started to send TCP packages with no flag set. So to get again a visual pattern, I created another colour for packages that have no flags set. The display filter syntax for that is tcp.flags == 0 (no flags set) Again at 1308.472246 the colour pattern changed. But only port 22 and port 1 where scanned. At that moment I didn't know what this was but I found out later. The scan was finished 1407.268574 with the last RST for port 22. The 3th scan started at 1407.256096 again with by ICMP and TCP probing. At 1417.570462 a new pattern started. The scanning host sends packages with FIN, PSH and the URG flag set. To get the visual feed back I created a new colour for such packages with the filter tcp.flags == 41 (FIN/PSH/URG) At 1441.428462 the same pattern as at the end of scan 2 started. Port 22 and port 1 where scanned. The scan ended at 1491.468691 Scan 4 started at 1489.554550 only with a probe on port 80. No ping was done this time. Again at 1499.868961 a new pattern similar to the first one started SYN followed by RTS/ACK. At 1504.127174 again the same pattern as after scan 2 and 3 started. The scan finished at 1604.486573. Scan 5 started at 1602.084879 with ICMP and TCP probing. A new pattern was found that showed scanning with FIN,PSH and the URG flag set like in scan 3. But this time the scans were done from 4 different hosts: 192.168.0.1, 192.168.0.254, 192.168.0.9 and 192.168.0.99. This scan lasted until the end of the file. To analyse the different scans better I used tcpslice to split the trace in 5 different files. > tcpslice -w scan1.log +0 +1260 0826\@19-snort.log > tcpslice -w scan2.log +1270 +138 0826\@19-snort.log > tcpslice -w scan3.log +1407 +85 0826\@19-snort.log > tcpslice -w scan4.log +1489 +114 0826\@19-snort.log > tcpslice -w scan5.log +1602 +100 0826\@19-snort.log To find out which ports where scanned I used the following command: > i=1; while [ $i -le 5 ]; do /usr/sbin/snort -r scan$i.log | grep ".99:" | sed -e 's/.*99:\(\w\{1,5\}\).*/\1/' | sort -gu > scan$i.ports;i=$(($i+1)); done which gave me the following five files >ls *.ports -rw-r--r-- 1 tz users 382104 Sep 16 12:35 scan1.ports -rw-r--r-- 1 tz users 5165 Sep 16 12:35 scan2.ports -rw-r--r-- 1 tz users 4013 Sep 16 12:35 scan3.ports -rw-r--r-- 1 tz users 5165 Sep 16 12:35 scan4.ports -rw-r--r-- 1 tz users 5165 Sep 16 12:35 scan5.ports The following commands > diff scan2.ports scan4.ports > diff scan2.ports scan5.ports showed that in scan 2, 4 and 5 the same ports were scanned SCAN 1 ---------- To find out which ports are found on scan1.log I opened the file in ethereal > ethereal scan1.log As the attacker is sending TCP SYN packages a open port should answer with a TCP package with SYN/ACK flags set. All other ports should answer with a TCP package with RST/ACK flags set. To find all open ports I created a display filter to show these packages tcp.flags.syn == 1 && tcp.flags.ack == 1 This showed the following ports as open 22 (ssh), 111(sunrpc), 32768(filenet-tms), 80 (http), 443(https) and 53 (domain). To get all packages which belong to the connection of the first package I used the function "Follow TCP Stream" on this package. This showed the following: attacker attacked SYN ---> <--- SYN/ACK RST ---> The scanning technic used here is SYN scanning, as not full connection gets established. The connection is terminated (RST) from the attacker after he receives the TCP package with SYN/ACK flags set. With this the attacker knows that the port is open. A look in the file scan1.ports showed that all ports (1-65535) where scanned. SCAN 2 ---------- After that I had an look on scan2.log. > ethereal scan2.log Here the attacker sends packages with no flag set. If a port is closed the attacked host should send a tcp package with the RST flag set. If the port is open the package should be dropped by the scanned host. So the attacker can see if a port is open when no tcp package with RST flag is send as answer. This scanning technic is call Null scan. I than hat a look at the trace where the pattern changed again. Here only packages to port 22 with different flags set and port 1 (including 1 UDP and 1 ICMP package) is seen. This looks like getting information about the scanned host. nmap has such a function build in (invoked with the -O parameter). A nmap -O test again a host at home with a tcpdump running at the same time > tcpdump -i eth0 -nn -w scanown.log > nmap -O 192.168.100.1 showed the same type of packages at the end of the trace (port 22 and 1) scanned. Without the -O parameter this packages did not occur. This looks like nmap was used for scanning and OS detection was turned on at this scan. To find out which ports where open (did not send a RST package) I used the following commands. First I had to remove the probing and the OS detection which has nothing to do with the scan. To do this I used the following command. > tcpslice -w scan2off.log +10 +33.56 scan2.log To get all ports that where closed: > /usr/sbin/tcpdump -nn -r scan2off.log src 192.168.0.99 | grep ': R' | awk '{print $2}' | awk -F . '{print $5}' | sort -ug >scan2.closed And at last to get the list of the open ports > diff scan2.closed scan2.ports | grep '>' | awk '{print $2}' 22 53 80 111 443 The look into scan2.ports showed that ports over the hole port range where scanned. As nmap was used and nmap has its on port list in nmap-services I compared the ports of nmap-services and scan2.ports To get the TCP port number out of the nmap-services I used the following command > cat /usr/share/nmap/nmap-services | awk '{print $2}' | grep tcp | awk -F '/' '{print $1} '| sort -ug >nmap-2.54BETA30.ports To show the differences I used > diff nmap-2.54BETA30.ports scan2.ports | grep \> | wc -l 58 which gave 58 differences. So I downloaded nmap-2.54BETA35.tgz nmap-2.54BETA36.tgz nmap-2.54BETA37.tgz nmap-2.99RC1.tgz nmap-2.99RC2.tgz nmap-3.00.tgz nmap-3.10ALPHA1.tgz form www.nmap.org and extracted the nmap-services file form each. > for i in *.tgz;do tar xvzf $i `echo $i | sed -e 's/\.tgz//'`\/nmap-services; done and extracted the nmap-services files with > for i in nmap*/nmap-services; do cat $i| awk '{print $2}' | grep tcp | awk -F '/' '{print $1} '| sort -ug>$i.ports; done > for i in nmap*/*.ports; do echo $i; diff $i scan2.ports | grep [\>\|\<] | wc -l ; done nmap-2.54BETA35/nmap-services.ports 48 nmap-2.54BETA36/nmap-services.ports 48 nmap-2.54BETA37/nmap-services.ports 3 nmap-2.99RC1/nmap-services.ports 2 nmap-2.99RC2/nmap-services.ports 2 nmap-3.00/nmap-services.ports 2 nmap-3.10ALPHA1/nmap-services.ports 3 nmap 2.99RC1 - nmap-3.00 have the least differences between the scanned ports and the ports in nmap-services the the nmap files of these releases are the same. The ports which were scanned and were not in nmap-services are > diff nmap-3.00/nmap-services.ports scan2.ports | grep \> | awk '{print $2}' 6663 12999 This ports where most likely added to the namp-service file by hand. So scan 2, 3 and 5 where done with the default ports of nmap. SCAN 3 ---------- Now to scan 3 > ethereal scan3.log Here the attacker sends TCP packages with FIN, PSH and URG flag set. The scan works like scan 2. Closed ports should send a TCP Package with RST flag set, open ports should drop the package. This technic is known as Xmas scanning. To get the ports found open by the attacker I used the same commands at in SCAN 2. > tcpslice -w scan3off.log +10 +23.87 scan3.log > /usr/sbin/tcpdump -nn -r scan3off.log src 192.168.0.99 | grep ': R' | awk '{print $2}' | awk -F . '{print $5}' | sort -ug >scan3.closed > diff scan3.closed scan3.ports | grep '>' | awk '{print $2}' 22 53 80 111 443 A look in the file scan3.ports showed that all ports for 1-1024 where scanned. SCAN 4 ---------- And go on with scan 4 > ethereal scan4.log Here the attacker send again TCP packages with SYN flag send. Open ports will answer with a TCP package with SYN/ACK flags set, closed with set RST/ACK flags. To get all open ports I again created a display filter tcp.flags.syn == 1 && tcp.flags.ack == 1 This showed the following ports as open: 111, 80, 443, 22, 53. A "Follow TCP Stream" on the package at 10.531964 showed the following package flow: attacker attacked SYN ---> <--- SYN/ACK ACK ---> RST/ACK ---> Here a hole connection is established and then reseted. This scan also can be done if the user has on root rights. This scanning technic is known as Connect scan. SCAN 5 ---------- And on to scan 5 > ethereal scan5.log Here the same scanning technic as in scan 2 was used, but this time the scans were done from 4 different hosts. A look into the nmap man page revealed that a decoy scan was done here. This means that the scanning host also sends packages with spoofed IP addresses. Here a decoy Xmas scan is used. To get the ports found open by the attacker the same commands as in SCAN 2 +3 were used. > tcpslice -w scan5off.log +10 +50 scan5.log > /usr/sbin/tcpdump -nn -r scan5off.log src 192.168.0.99 | grep ': R' | awk '{print $2}' | awk -F . '{print $5}' | sort -ug >scan5.close > diff scan5.closed scan5.ports | grep '>' | awk '{print $2}' 22 53 80 111 443 In scan 5 no OS detection is done To find out which Operating System the attacker used, I used the following commands. > ./p0f -s smto23-4.log 'port 80' p0f: passive os fingerprinting utility, version 1.8.2.2 (C) Michal Zalewski , William Stearns p0f: file: 'p0f.fp', 150 fprints, iface: 'eth0', rule: 'port 80'. 192.168.0.9 [1 hops]: Linux 2.4.2 - 2.4.14 (1) 192.168.0.9 [1 hops]: Linux 2.4.2 - 2.4.14 (1) 192.168.0.9 [1 hops]: Linux 2.4.2 - 2.4.14 (1) Answer to the questions: -------------------------------------------------------------------------------- 1. What is a binary log file and how is one created? A binary log file is a file where in which the data is stored in binary, as the packages are transported over the network. A binary log file also contains some information about the arrival time, the length on the wire and the captured length. A binary log file can be created e.g by tcpdump with the option -w. 2. What is MD5 and what value does it provide? MD5 is a message-digest algorithm. It creates a 128-bit fingerprint of the input. If you download a file and then check if the file has the same MD5 value you can see if the file was corrupted during the download. It the MD5 value is signed by a public key, you even know that the file is from the person who signed it. If you like to get more information on MD5, you can have a look in RFC 1321. 3. What is the attacker's IP address? 192.168.0.9 4. What is the destination IP address? 192.168.0.99 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: TCP SYN scan In a TCP SYN scan the scanning host sends a SYN package. When the port on the scanned host is open the response is a SYN/ACK package. When the port is closed the response is a RST package. In case of a SYN/ACK package the attacker sends a RST package to close the connection. So no complete connection is established. The scan was most likely run by the command > nmap -sS -p 1-65535 192.168.0.9 Scan 2: Null scan with TCP fingerprinting In a Null scan the scanning host sends TCP packages with no flags set. If a port is open on the scanned host he should drop those packages. If the port is closed he should respond by sending a RST package. So the attacker knows that a port is open when no response was received. The scan was most likely run by the command > nmap -sN -O 192.168.0.9 Scan 3: Xmas scan with TCP fingerprinting In an Xmas scan the attacker sends packages with the flags FIN, PSH and URG set. Here again a closed port should send a RST package while a open port should drop this package. The attacker knows that the port is open when no response was received. The scan was most likely run by the command > nmap -sX -O -p 1-1024 192.168.0.9 Scan 4: TCP connect scan with TCP fingerprinting In a TCP connect scan a TCP connection to the scanned host is established. The attacker sends a SYN package. If the port is open the scanned host sends a SYN/ACK package which is acknowledged by a ACK package of the scanning host. Now a connection is established between the two hosts. The attacker closes this connection by sending a RST package. Closed ports response with a RST package. These scan be done without special privileges. The scan was most likely run by the command > nmap -sT -pT -O 192.168.0.9 Scan 5: Xmas decoy scan In a decoy scan the attacker scans every port from more that one IP address. This is done by spoofing these packages. So for the scanned host it is not so easy to see which host is scanning. Here also a Xmas scan like in scan 3 was used. The scan was most likely run by the command > nmap -sX -D 192.168.0.1,192.168.0.254,ME,192.168.199 192.168.0.99 6. Which scanning tool was used to scan our honeypot? How were you able to determine this? nmap between 2.99rc1 and 3.00 - By running a nmap attack in the local system with TCP fingerprinting. The sent packages where the same, as in scan 2, 3 and 4. The version I found by the ports that were scanned in scan 2, 3 and 5. The ports scanned there are nearly the one in the nmap-services file of this nmap versions. The ports 6663 and 12999 where most likely added to this file. 7. What is the purpose of port scanning? To find out which ports are open on a system. This give you hints on what services the host is offering. 8. What ports were found open on our honeypot? Open ports: 22 (ssh) 53 (domain) 80 (http) 111 (sunrpc) 443 (https) 32768 (filenet-tms) All scans found the ports 22, 53, 80, 111 and 443 open. The port 32768 were only found by scan 1 as here the hole port range was scanned. 9. Bonus Question: What operating system was the attacker using? Linux 2.4.2 - 2.4.14 Used tools -------------------------------------------------------------------------------- tcpslice - http://www.tcpdump.org/other/tcpslice.tar.Z p0f - http://www.stearns.org/p0f/