The following hacker scenario was created by Ed Skoudis, author of "Counter Hack" and SearchSecurity expert. The solution was written by SearchWebManagement user "Thomas NG," an IT manager.
HACKER SCENARIO: Michael Roesoft worked on the Computer Incident Response Team for a software development company. On a Sunday evening, while watching the thrilling John Travolta / Nicholas Cage DVD, Face/Off, Mike received an urgent page from his network-based Intrusion Detection System (IDS) on the DeMilitarized Zone (DMZ). The IDS had detected various backdoor commands being sent to one of the company's web servers. Due to the nature of the commands being sent to the Web server, Mike nearly wet his pants when he got the page. Clearly, Travolta and Cage would have to wait while Mike solved this case.
The Web server in question was a Windows 2000 machine, running Microsoft's IIS product. IIS has had more than its fair share of vulnerabilities in the past, so Mike quickly assumed that the Web server was taken over by the attacker who had installed a backdoor. The Web server sat on the same DMZ as a Windows NT DNS server, a Linux-based FTP server, and a Windows XP Mail server. The DMZ was constructed using a simple layer-2 switch connecting all of these machines, as well as a firewall, together on a single LAN.
According to the particular alert from the IDS, the attacker had viewed the /etc/passwd and /etc/shadow files on the Web server machine. Additionally, the attacker had altered the /etc/hosts.equiv file on the machine to extend its trust relationships. Mike carefully reviewed some sniffer logs from the DMZ, and observed that commands to view and edit these files were going to and from the IP address of the Windows-based Web server.
Mike conducted a port scan of the Web server, and found no ports open, other than the expected TCP ports 80 and 443 for HTTP and HTTPS. He also scanned the rest of the DMZ, and found no suspicious port usage on any of the boxes.
Mike also ran Tripwire, the file integrity checking tool, on the Windows Web server, and found no alterations of any system files. The Web server looked clean. Curiously, though, when Mike viewed the ARP cache on the firewall connecting the DMZ to the rest of the world, he noticed that the IP address-to-MAC address mapping for the Web server was messed up. The Web server's IP address was mapped to the MAC address of another machine on the DMZ.
1) Where should Mike look for the real backdoor?
Mike should look for the real backdoor in the ftp server.
2)What kind of backdoor tool was the attacker using and how did the backdoor receive its commands?
Backdoor is something that can redirect traffic on the ftp server. Probably IPTABLE because it is very common that comes as default with many linux installations. The attacker configured the IPTABLE to do NAT. Dest IP www and port 80 and 443, redirect to the real www server. In this case, all public users will still be able to access the Web site. Dest IP FTP and port 80 and 443 was blocked, so when the scanner scanned the ftp server, port 80 and 443 didn't turn up because IPTABLE blocked it. How did the attacker access the ftp server through its port 80? Well, he did an additional check for source IP address(attacker IP). So when the source IP is from this predetermined value and the destination IP is WWW and port 80, instead of redirecting to the WWW server, allow it into the ftp server and give it a command prompt without passwords.
3) What mistakes did the attacker made?
He allowed his traffic to be in the clear. He should have installed a secure shell or something on port 80 of the ftp server.
4) What types of tools should Mike use to look for the back door?
Netstat -na on the ftp server should turn up what ports are listening. Or he can run his own netstat off of a disk with a trusted binary or something. Tripwire on the ftp server as well in case the attacker changed the kernel to give misleading data. Also check to see what are the modules loaded.
For more hacker scenarios from Ed Skoudis, visit our Challenge of the Month forum.