Analysis provided by Kris Jehaes
for the Honeynet
Project
The
Challenge:
Intro: A man with a plan. What the logs told me.
The Scan of the Month for Scan 15 was to recover a deleted rootkit. Since then, people have asked us a variety of questions about the attack, such as how did the attackers get in, who were they, and where did they come from. Instead of us presenting the answers, we challenge you to determine the answers yourself. You are presented with the binary snort capture for the day of March 15. Armed with this log file, and the knowledge that the system in question is 172.16.1.108, you should be able to answer the following. (Note, the Honeynet Project has been quoted as saying "The expected life expectancy of a default RedHat 6.2 server is less then 72 hours. The last time we attempted to confirm that the system was compromised in less then 8 hours". This is the system that was compromised in under 8 hours.
1. The attackers used rpc.statd attack to get into the system. What modifications did they make to the break in process to both automate and make the process faster?
2. What system/country did the badguys come in from?
3. What nationality are the badguys, and how were you able to determine this?
4. What do the answers to questions #1 and #2 tell us about the tactics the badguys are using?
5. What did you learn from this challenge?
6. How long did this challenge take you?
Bonus Question:
Can you recover the blackhat's rootkit from the Snort binary log file? If so, how?
What follows is a brief explanation of the tool I have used to be able to read and dissect the binary snort logfile. The tool is called ethereal and can be freely downloaded at www.ethereal.com. It is available for a lot of different OS's. A friend told me I could use this tool to read the binary logfile. It was thus the first time I worked with this tool. It has two very interesting features that I will use throughout my explanation, so I will briefly discuss them now.
The first feature is filtering. It is possible to filter packets on the IP address and port numbers they contain. The second feature is what ethereal calls a TCP stream. If you right click a packet in ethereal and select TCP stream from the popup menu, it will automatically filter all the related packages of the same TCP/IP connection. It will also display a screen with all the application data in it, which is a great feature of this software, as we will see later. So if I use filtering and TCP stream in my discussion I automatically mean these features in relation to ethereal.
In next part I will discuss the whole logfile, and explain what I think happened. After that I will briefly answer the questions. Let's go!
The compromise was all done from one IP address, namely 211.185.125.124. I did a lookup on several whois servers, and on www.arin.net there was a message saying that it belongs to 'Asia-pacific users', and that more contact info could be found on www.apnic.net ,which stands for Asia Pacific Network Information Center. When I entered the IP address on that site, I found that this address belongs to the 'Korea Network Information Center'.
The results I got on both sites can be found in the next two links:
From this IP the blackhat first used an rpc.statd attack to get into his victim. To do this first a 'V2 GETPORT Call XID 0x412695da' is done (packet 114-115) from his source port 730 to his victims rpc (111) port. The victim replies with port 931 as the port that is mapped for the STAT service. Then, only 2 seconds later a 'V1 STAT Call XID 0x1acf13bc dup XID 0x1acf13bc' call is made to port 913 of the victim (packet 124-125). This packet is 1118 bytes long and contains a special crafted String that starts like "%8x%8x%8x ... %236x%n%137x%n%10x%n%192x%n", which indicates some string formatting codes. A little bit further in the packet one can also read something that looks like "bin/sh", so giving away that someone tried to gain access to a shell through some sort of buffer overflow. Because of the short time interval between the two calls (2 secs), my guess is that the blackhat used some automated tool to do the attack. Also because there are several RPC calls logged from this IP to a range of IP's (172.16.1.101 - 172.16.1.108) in just a few seconds, mixed with the packets where the buffer overflow occurs. I have also found a nice pdf on the Internet from a guy called John Kristoff. He explains how he has put up a honeypot and monitors what happens in order to learn more about the blackhat community. Pages 10-14 explain the exact same attack that that was used here.
Once access was gained to the shell, he downloaded a rootkit called lk.tgz from ftp.home.ro or 193.231.236.41 or s1.home.ro) to the honeynet pc. The username/password he used was "soane/i2ttgcj1d". It still works now, so I took the liberty of taking a look in his private ftp stash. I was not the first one that was there I saw, because someone added an OOPS.txt file. So the rootkit was downloaded to the honeynet, and in the logfile there is a big part where the honeynet makes a connection to ftp.home.ro. If a filter is placed on the snort logfile that looks like this: " (ip.addr eq 211.185.125.124 and ip.addr eq 172.16.1.108) and (tcp.port eq 4450 and tcp.port eq 39168)", then only the packets are displayed that contain the rootkit installation. The rootkit was installed on 16/03/2001 between 2 and 3 o'clock. A text file of the result of TCP stream functionality on the filtered packets can be found here:
This concludes my analysis. Let's take a look at the questions now.
1. The attackers used rpc.statd attack to get into the system. What modifications did they make to the break in process to both automate and make the process faster?
He used V2 GETPORT Call, and V1 STAT Call with a special crafted string to get a shell prompt via a buffer overflow. As I already explained some sort of automated tool was used for making this process go easier and faster. The scanning of a range of IP's and their RPC services available was automated, and also the exploiting of a vulnerability when the scanning found something. So, I guess this was all done with the same tool. After that he downloaded and installed a root kit from the obtained shell to cover up the compromise of the system.
2. What system/country did the badguys come in from?
They came in from an IP address registered to Korea Networks Information Center. This IP was probably also compromised and used for the attack. The Nmap scan revealed that it is most likely a Linux 2.1.19 - 2.2.17, Linux kernel 2.2.13
3. What nationality are the badguys, and how were you able to determine this?
Because a connection was made to an FTP server registered in Bucharest - Romania, my guess is that the badguys come from there. Also because of the mp3 of a song in the Romanian language was found on the server.
4. What do the answers to questions #1 and #2 tell us about the tactics the badguys are using?
They definitely don't look like script kiddies. They are also using automated tools to scan for vulnerabilities and to exploit them when they are found. Also the installation of the root kit indicates that these guy(s) know what they are doing.
They also managed to stay completely anonymous for the honeynet by attacking from an already compromised system. So the blackhat probably has some other systems that he has compromised to do some attacks. Because Romania and Korea are completely different territories, he won't have to worry too much about getting caught. He probably also makes sure that the attacking pc and the victim are located far away from each other. This way it is much more difficult for administrators to get a trace back to his IP.
5. What did you learn from this challenge?
Well, a lot! It was my first confrontation with ethereal, and binary logfiles. Packets and logfiles are not new to me though, but I don't have much practical experience with it yet, this has surely changed now. I learned about these rpc calls, which I knew almost nothing about before. I've red some books on security, like 'Hacking exposed' and 'TCP/IP illustrated' and it was nice to use all this knowledge in a real situation.
I found this challenge really interesting, and I enjoyed working on it very much. So keep up the good work there at Honeynet!
6. How long did this challenge take you?
I spend a lot of time on it. Basically because I had to rewrite things several times, because my first thoughts were not always right. I have been working on it during 2 weeks, and gradually I found better answers. So, I spend the most of my time on the writing, also because I wanted to make a nice html version.
Well, lets say:
1 Hour to find, install and learn to use ethereal
3 Hours to go through the logfile itself
7 Hours to write things down
1 Hour searching on the net for things about rpc.statd vulnerabilities
____________________
Which makes a total of 12 hours that were scattered over 2 weeks. Maybe it was even longer, but I didn't have a stopwatch with me all the time, so this is just a rough estimation.
Bonus Question:
Can you recover the blackhat's rootkit from the Snort binary log file? If so, how?
Yes, I can. Or I should better say, ethereal can. If you put a filter that looks like this: (ip.addr eq 172.16.1.108 and ip.addr eq 193.231.236.41) and (tcp.port eq 1027 and tcp.port eq 20), then all the packets will be displayed that were logged during the FTP data transfer and thus contain the actual rootkit. If a TCP stream is done on one of these packets then you get a screen with all the data that was transferred during the connection, which is exactly 520333 bytes big. This is completely non-readable data for a human, but if it is saved as a *.tgz file then the data makes sense to for instance Winzip, and you can find a .tar file in there and look at the files in the tar file. Pretty simple actually. I was amazed that this could work so fast and easy.
Comments are always welcome. Greetzzz
Kris Jehaes
krisjehaes@yahoo.com