http://project.honeynet.org/ Scan 23 - Analysis by Michael Csulits [maniac@geisberger.com] Questions 1. What is a binary log file and how is one created? 2. What is MD5 and what value does it provide? 3. What is the attacker's IP address? 4. What is the destination IP address? 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? 6. Which scanning tool was used to scan our honeypot? How were you able to determine this? 7. What is the purpose of port scanning? 8. What ports were found open on our honeypot? 1. Bonus Question: What operating system was the attacker using? 1. What is a binary log file and how is one created? The binary log file contains data captured from a network in raw form. It contains the complete packages with all headers. This is done by the use of libpcap, a network packet capture library. Most of the time such log files are created by tools like tcpdump, a textmode sniffer, or snort, an open source intrusion detection system. The log file can be easily analyzed by using ethereal, a gui sniffer or tcpdump, a text-mode only sniffer. 2. What is MD5 and what value does it provide? Md5 is an algorithm to create fingerprints of data with an arbitrary length. Its output is an 128 bit fingerprint of its input data. Md5 was designed to make it hard to create the input data for a given md5 sum or to create two different inputs which have the same md5 sum. It is often used for digital signatures for example to verify the integrity of your downloads. It is much easier to compare two 128 bit checksum instead of comparing two 600MB files. 3. What is the attacker's IP address? 4. What is the destination IP address? After downloading and unpacking the log file i've checked its md5 sum. ghost@ghost /home/ghost/scan# ls 0826@19-snort.log 0826@19-snort.log.md5 ghost@ghost /home/ghost/scan# cat 0826\@19-snort.log.md5 0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log ghost@ghost /home/ghost/scan# md5sum 0826\@19-snort.log 0ce142f18c23d9ab00f992a57ad097d4 0826@19-snort.log As you can see it is correct. After that I've opened it with ethereal. This took some time because the log files size is almost 12MB. The first two packets captured look very interesting. Someone send an ping from 192.168.0.9 to 192.168.0.99 and gets an reply. Ping is used to check if a remote host is on the net. That could be the attacker. A few packets later we see clearly what is going on: 192.168.0.9 sends packets with the syn bit set to different ports at 192.168.0.99. The syn bit in the tcp header is used to request a tcp connection. A normal tcp connection is established like that: Client Server Comment [SYN] -> connection request by the client <- [SYN, ACK] connection request accepted by the server [ACK] -> client confirms answer -> connection is established In this case the server accepted the connection request. If the server doesn't accept a connection request it replys with [RST, ACK] instead of [SYN, ACK] which will stop the communication. After scrolling down many many pages and having a look at those packets with [SYN] and [RST, ACK] set there is no doubt for me that 192.168.0.9 is the attacker and 192.168.0.99 is the target host. 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? To identify the different methods I had a look at http://insecure.org/nmap/nmap_doc.html which describes the commonly used scanning methods used today in detail. The first scan (packet 0 - 148006) is a syn scan. It starts with a ping packet. The attacker sends packets with the syn bit set to the port he is interested in. The target host sends a packet with the answer back. This packet has the syn and the ack bit set if the according port is open. If the port is closed it sends a packet with the rst bit set. This looks like an ordinary connection request for the target host expect that it doesn't receive a reply to his packet anymore. The [ACK] packet is missing. Thats why it is called syn scan. The attacker sends only one [SYN] packet. This is method is more silent than an normal tcp connect but not undetectable. Many tools like scanlogd have been developed to detect this method. Looking at the captured packets in etheral you can see the bits which are set in the packet info on the right side of the screen. The second scan starts with packet 148007. Again the victim host gets pinged. A few packets later you can see something strange. The attacker sends packets where no bit is set. What's that ??? It looks like a null scan. In a null scan the attacker sends packets with no bit set to the target system. Basically it works much like a syn scan. A packet is send, the answer is received and based on the answer packet the attacker knows if the remote port is open or closed. If the remote port is closed he receives a [RST, ACK] packet. If it is open he doesn't receive an answer at all. Around packet 150642 we see some strange packets. What's their purpose ??? They are used for remote os detection. Each os has its own tcp\ip stack. Thats why each os will react different if it receives special packets. Using the replys the attacker can easily find out which os is used on the remote system. The third scan starts with packet 150753. This is a ping packet again. After the ping we can see that it is a xmas scan. It is called xmas scan because all "lights"(bits) in the packets are set. The attacker sends packets with all bits set to the victim and gets the remote ports state because of the answer. If the remote port is open the attacker doesn't get an answer. If it is closed he receives a [RST, ACK] packet. The last packets before 153251 are again used for remote os fingerprinting. The fourth scan looks different. It starts with packet 153251 but this time there is no ping before the real scan starts. I know that the scan starts here because of the bits set in the packet headers. This time it is a tcp connct scan. This means that a the attacker tries to establish a full tcp connection to the victim. A normal tcp connection is created by sending a syn packet to the remote host. The remote host answers with a [RST, ACK] if the port is closed. If it is open it answers mit a [SYN ,ACK] packet. Then the attacker sends a [ACK] packet. I know that it is a tcp connect scan because of packet 154805 and its replys. It is send to port 22 (ssh). Because its open on the remote host it replys with [SYN, ACK]. If the scan would be a syn scan no more packets would have been send but the attacker sends an [ACk] to finish the handshake and establish the connection. This scanning method is very fast and reliable but easy to detect. Like before the last packets of the scan are used to detect the remote os by sending special packets. The fifth scan starts with packet 155987. This time it starts with pings again. But what's that ??? There are four pings from three different hosts. After scrolling down to packet 156008 we see something similar to the third scan. It is an xmas scan again. But it looks like there are three attackers scanning the host at the same time. It is not very realistic that those three attackers would send their packets at the same time. How do our attackers achieve this ??? It is only on attacker who spoofs packets. Spoofing means to change the source address of packets in the header of ip packets to hide the real source. He sends each packet three times. Each time with another source adress. Only one of these adresses is his real one. This is needed to get a reply. Otherwise the scan would be senseless. If the attacker could sniff the packets from and to the victim he could simply spoof all his packets because he would get the answer nevertheless. Such a scan can be done with nmap and its -D option. 6. Which scanning tool was used to scan our honeypot? How were you able to determine this? The first programme when I think of portscanning is nmap. (http://insecure.org/nmap) Nmap gives you the possibility to do all the scans that were used to scan the honeypot. To make sure nmap was really used I made a test scan on my linux box which I analyzed using ethereal. The first thing I've noticed again is the ping that is send before the real scan starts. In the forth scan the -P0 option was used. It tells nmap not to test if the victim is reachable. The next thing I noticed was the window size which changed in every scan. I made some test scans again. The fin scan of the honeypot had a window size of 3072. My test scan produced the same result. While I looked at my test scans I saw something else that I've seen before. The first packet in the scan was an [ACK] to port 80 of the target. The packets following 148009 look similar.The attacker sends an [ACK] packet and receives an [RST] packet. That's why I think the attacker used nmap. 7. What is the purpose of port scanning? Port scanning is used to gather information on a system. An attacker scans to check which services are available on a host. It is often the beginning of an attack. If the attacker knows which services are available he can search for common vulnerablities of those services and exploit them. Portscanning isn't only used for attacking systems. An administrator can portscan his systems to look for running services he has forgotten to disable or to find backdoors installed after a compromise. Portscanners are also useful to check firewall configurations or test intrusion detection systems. 8. What ports were found open on our honeypot? While describing the different scanning methods I've told you how to decide if a remote port is open or closed. Using this information we can easily find the open ports by using the filter in ethereal. First I used the following filter: ip.src == 192.168.0.9 && ip.dst == 192.168.0.99 && tcp.flags == 0x0010 It will only show me packets which were send from the attacker to the victim to finish the handshake and establish a full connection. This gave me the following open ports: 1 tcpmux 53 domain 22 ssh 80 http 111 sunrpc 443 https To verify this I used another filter which shows only packets with syn and ack bit set. These are packets which have been send by the victim as a reply if the port is open. ip.src == 192.168.0.99 && ip.dst == 192.168.0.9 && tcp.flags == 0x0012 This gave me the following open ports: 1 tcpmux 22 ssh 53 domain 80 http 111 sunrpc 443 https 32768 unknown This is the final list of open ports. 1. Bonus Question: What operating system was the attacker using? As I described earlier the attacker used nmap which is a portscanner that normally runs under unix-like operating systems but there is also a windows port available. Nmap uses normal sockets for a tcp connect scan thats why I will have a look at the packets from this scan to get more information because they are created by the os not by nmap itself. http://www.incidents.org/papers/OSfingerprinting.php provides some nice information which helped me a lot. The attacker used a system based on linux (kernel 2.4). All the values in the [SYN] packets match the defaults for linux 2.4: TTL = 64 Window size = 5840 Packet length = 60 It is also possible that the attacker did not use linux 2.4 . He could have generated the packets to look like they were send from a linux 2.4 box. But thats not very common. So I think the attackers system was linux 2.4 . Summary The complete analysis took around six hours. After downloading the archive I extracted it and checked its md5 sum. I opened it with nmap und looked around. After locating things like the pings and syn scans I knew what I had to look for and started to find some information on portscanning online. To check which scanning tool was used I did some test scans on my linux box which I sniffed using ethereal. I compared them to the scans from the honeypot. That's it. Sorry for my poor english, it isn't my native language. Links: ethereal - http://www.ethereal.com/ snort - http://www.snort.org/ tcpdump - http://www.tcpdump.org/ scanlogd - http://www.openwall.com/scanlogd/ nmap - http://www.insecure.org/nmap/ Passive OS Fingerprinting: Details and Techniques - http://www.incidents.org/papers/OSfingerprinting.php By: Toby Miller The Art of Port Scanning - http://insecure.org/nmap/nmap_doc.html by Fyodor