Scan of the Month September

Ralf Spenneberg
ralf@spenneberg.net

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

A binary log file stores the captured packets in the pcap format. This format can be read and written by almost all applications using the libpcap packet capture library.

Two applications to create the binary log file are tcpdump and snort:

  tcpdump -w binary.log
  snort -b -L binary.log

The log files can then be read either using tcpdump or snort. The later cited packets have been read using snort:

  tcpdump -r binary.log
  snort -r binary.log

What is MD5 and what value does it provide?

MD5 is a message digest. It takes an input of an variable length and creates an output of fixed length (128 bit). It can be used to ensure the integrity of a file. The MD5 is calculated when the file is created and can be compared at any time with the file. To create the MD5 use the command:

md5sum file

To create the md5sum for the sotm file enter:

$ md5sum sotm23.tar.gz 
9d28c5ee9ce7b77e3099a07ad303811f  sotm23.tar.gz

What is the attacker's IP address?

The attackers IP address is 192.168.0.9. This IP is the client IP in all attempted connections. In all connection this IP uses the high port.

What is the destination IP address?

The destination IP address is 192.168.0.99. This IP receives all attempted connections. In all connections this IP is associated with the well-known privileged port.

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

Half-Open TCP-SYN Scan. The attacker sends SYN packets at all or some ports of the victim. When the port on the victim is closed, the victim responds using an RST/ACK packet. If it is open, the victim will send a SYN/ACK packet. Thus the attacker knows, whether the port is open or closed. To avoid logging on the victim the attacker then sends a RST packet at the open port to tear the connection down again.
```
08/27-02:00:00.596850 192.168.0.9:52198 -> 192.168.0.99:52156
TCP TTL:53 TOS:0x0 ID:27184 IpLen:20 DgmLen:40
******S* Seq: 0x40E6DA2  Ack: 0x0  Win: 0x800  TcpLen: 20
```
TCP-ACK Scan. The attacker sends ACK packets at all or some ports of the victim. When the port on the victim is reachable the victim always response with RST packet. This scan tries to find out which ports on the victim are reachable and not blocked by a firewall.
Closer Examination shows that the attacker did not do a full ACK scan, but the found ACK packets are part of the OS detection mentioned below.
When a firewall is installed this scan allows to decide if the firewall is stateful (no ACK may pass) or not (all ACKs have to pass).
```
08/27-02:23:17.506900 192.168.0.9:58183 -> 192.168.0.99:80
TCP TTL:48 TOS:0x0 ID:19829 IpLen:20 DgmLen:40
***A**** Seq: 0x90300003  Ack: 0xD7F52EDF  Win: 0x400  TcpLen: 20
```
XMAS Scan. The attacker sends TCP packets which have the FIN, URG and PSH flag set. This was thought as a stealth scan, although today all firewalls and ids pick up this signature. Open ports on the victim discard the packet while closed ports have to send a RST. Combined with the ACK scan the open ports can be determined even if there is a firewall in place. All ports that responded to the ACK scan but did not respond to the XMAS Scan are open ports.
```
08/27-02:23:27.821464 192.168.0.9:58163 -> 192.168.0.99:231
TCP TTL:48 TOS:0x0 ID:60132 IpLen:20 DgmLen:40
**U*P**F Seq: 0x0  Ack: 0x0  Win: 0x400  TcpLen: 20  UrgPtr: 0x0
```

Decoy Scan. The attacker sends packets not just from his own IP address but from several additional spoofed IP addresses. The victim cannot determine which IP address is the attacker's real address. The chosen IPs 192.168.0.254, 192.168.0.1 and 192.168.0.199 are probably not alive. The victim only answers the packet with the source address 192.168.0.9. That probably means, it does not get an ARP reply for the rest of the IP addresses. The decoy can easily be noticed when looking at the port numbers which match in all 4 packets.

08/27-02:26:42.655912 192.168.0.1:35964 -> 192.168.0.99:1542
TCP TTL:38 TOS:0x0 ID:46742 IpLen:20 DgmLen:40
**U*P**F Seq: 0x0  Ack: 0x0  Win: 0xC00  TcpLen: 20  UrgPtr: 0x0

08/27-02:26:42.655918 192.168.0.254:35964 -> 192.168.0.99:1542
TCP TTL:38 TOS:0x0 ID:10801 IpLen:20 DgmLen:40
**U*P**F Seq: 0x0  Ack: 0x0  Win: 0xC00  TcpLen: 20  UrgPtr: 0x0

08/27-02:26:42.655980 192.168.0.9:35964 -> 192.168.0.99:1542
TCP TTL:38 TOS:0x0 ID:16786 IpLen:20 DgmLen:40
**U*P**F Seq: 0x0  Ack: 0x0  Win: 0xC00  TcpLen: 20  UrgPtr: 0x0

08/27-02:26:42.655995 192.168.0.199:35964 -> 192.168.0.99:1542
TCP TTL:38 TOS:0x0 ID:19352 IpLen:20 DgmLen:40
**U*P**F Seq: 0x0  Ack: 0x0  Win: 0xC00  TcpLen: 20  UrgPtr: 0x0

Null Scan. The null scan serves the same purpose as the XMAS scan. Closed ports are required to respond using a RST/ACK packet while open ports may not respond.

08/27-02:21:15.175196 192.168.0.9:42294 -> 192.168.0.99:495
TCP TTL:39 TOS:0x0 ID:4711 IpLen:20 DgmLen:40
******** Seq: 0x0  Ack: 0x0  Win: 0x1000  TcpLen: 20

Fingerprinting. The attacker tried to fingerprint the victim 3 times. The packets with reserved bits set and the SYN/FIN/URG/PSH packets are good indicators.

08/27-02:21:38.723005 192.168.0.9:42301 -> 192.168.0.99:22
TCP TTL:39 TOS:0x0 ID:25184 IpLen:20 DgmLen:60
*2****S* Seq: 0x2DC1139F  Ack: 0x0  Win: 0x1000  TcpLen: 40
TCP Options (5) => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL

08/27-02:21:38.723076 192.168.0.9:42303 -> 192.168.0.99:22
TCP TTL:39 TOS:0x0 ID:20688 IpLen:20 DgmLen:60
**U*P*SF Seq: 0x2DC1139F  Ack: 0x0  Win: 0x1000  TcpLen: 40  UrgPtr: 0x0
TCP Options (5) => WS: 10 NOP MSS: 265 TS: 1061109567 0 EOL

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

Because of the different scans and the fingerprinting capability, I think that nmap was used for the scanning. Nmap supports all noted scans. To test this nmap was used to fingerprint a host and the generated packets were identical on the client side. A further indicator for nmap is the fact that each scan starts with an echo-request packet. Nmap first pings the host to test if the host is alive.

What is the purpose of port scanning?

Port scanning is used in the information gathering step by the attacker. The attacker uses this technique to find out which services are running on the host and are available. In detail the following results may be collected by the attacker:

Which service is running on the host?
Is the host protected by a firewall?
Which services are available through the firewall?
Is the firewall stateful? (unsolicited ACK, FIN, XMAS and NULL packets should not pass a stateful firewall; ACK and FIN have to be allowed through a stateless firewall.)
Which operating system is used on the host using fingerprinting?
Uptime of the host (using the newest version of nmap)

What ports were found open on our honeypot?

TCP 22, 53, 80, 111, 443, 32768
This correspond to the following services:
22 - ssh
53 - dns
80 - http
111 - rpc.portmapper
443 - https
32768 - ?
All of these service had at least one vulnerability during the last few years. An attacker would have a vast collection of exploits to try against this machine.

Bonus Question: What operating system was the attacker using?

Using the tool p0f (http://www.stearns.org/p0f) to do passive fingerprinting the attackers operating systems was determined to be a Linux kernel 2.4.2-2.4.14. This might not be fully correct, since the p0f fingerprinting database stops at Linux kernel 2.4.14. So it might have been a newer Linux kernel. The signature used by p0f for this OS is:

5840:64:1460:1:0:1:1:60:Linux 2.4.2 - 2.4.14 (1)

The description of the format is:

# wwww:ttt:mmm:D:W:S:N:I:OS Description
# wwww - window size
# ttt  - time to live
# mmm  - maximum segment size
# D    - don't fragment flag  (0=unset, 1=set) 
# W    - window scaling (-1=not present, other=value)
# S    - sackOK flag (0=unset, 1=set)
# N    - nop flag (0=unset, 1=set)
# I    - packet size (-1 = irrevelant)

A packet that fits this description is :

08/27-02:24:50.120277 192.168.0.9:34032 -> 192.168.0.99:52
TCP TTL:64 TOS:0x0 ID:41431 IpLen:20 DgmLen:60 DF
******S* Seq: 0x110982AC  Ack: 0x0  Win: 0x16D0  TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 16917371 0 NOP WS: 0

The window size is 0x16D0 which is 5840 decimal
The ttl is 64
The mss (maximum segment size) is 1460
The DF (do not fragment) Bit is set
The window scaling is set to 0
The SackOK (Selective Acknowledgments Allowed Flag) is set
The packet has a NOP in the options
The datagram length of the packet is 60 bytes.

Therefore the packet fits the description.

Not asked Question: What operating system was scanned?

The target system send the following packet:

08/27-02:24:50.337273 192.168.0.99:111 -> 192.168.0.9:34203
TCP TTL:64 TOS:0x0 ID:0 IpLen:20 DgmLen:60 DF
***A**S* Seq: 0x4CC898B9  Ack: 0x10F689B7  Win: 0x16A0  TcpLen: 40
TCP Options (5) => MSS: 1460 SackOK TS: 14921528 16917393 NOP
TCP Options => WS: 0

Using passive fingerprinting the following facts can be extracted:

TTL=64
WindowSize=0x16D0=5840
DF set
ToS not set (but set in ICMP-port unreachable messages, not shown)
SackOK set
Window scaling set to 0
NOP used
MSS (maximum segment size) set to 1460
Datagram length set to 60 bytes.

Comparing these results with the results from the last question, I deduct that the scanned victim system used a Linux kernel 2.4.2-2.4.14, too.