It helps in honeypot deployment and attack analysis if you understand the two major attack model types that hackers use: manual and automated.
The manual hacking model is slow, but it allows the hacker to change his attack based on what he learns. For example, the hacker may be looking for IIS 5.0, but he finds IIS 4.0 instead. He can then use tricks and exploits known to work against IIS 4.0. Finding IIS 4.0 versus 5.0 probably means the host OS is Windows NT 4.0 versus Windows 2000. Now the hacker can began to concentrate on attacks against NT 4.0, too. The vast majority of automated attack tools don’t have the necessary programming to switch exploits based on host differences.
The classic manual hacking model has the hacker looking for vulnerable hosts, followed by exploitation of a weak host. In this model, the hacker spends time looking for a particular type of host. This is usually because the hacker has expertise or tools applicable to particular OSs or applications. The hacker starts identifying the larger population of hosts to check with a tool like ping (ICMP echo) to identify active hosts on the network. The echo reply from the ping can be used to identify the OS and version. The hacker then tries to identify hosts with particular OSs or applications. This process is called fingerprinting.
Fingerprinting is the process of identifying particular OSs and applications. Fingerprinting becomes very important when we begin to discuss virtual honeypots like Honeyd because, in order to appear legitimate, they must pass fingerprinting tests initiated by remote attackers. Fingerprinting works by analyzing the network packets from a particular host in response to legitimate or malformed packets. Just like a human fingerprint identifies a particular person, the network packet response from a particular OS or application often identifies the OS or program. For example, Windows 95 responds differently to ICMP messages than Windows NT does. Fingerprinting usually involves more than one packet and may involve multiple protocols and queries before the hacker or the tool can identify the source.
The fingerprinting may be active, which means the fingerprinting mechanism initiates communications directly with the host and interprets information sent back. There are several active fingerprinting tools, including Nmap (http://www.insecure.org/nmap) and Xprobe2 (http://www.sys-security.com). Whereas Nmap uses TCP and UDP to fingerprint, Xprobe2 relies heavily on ICMP packets (http://www.sys-security.com/html/projects/icmp.html) and a few other mechanisms. Both utilities work by sending different types of TCP/IP packets, recording the results, and using the combination of all sent results to identify a particular host OS. They are often accurate enough to identify the OS version and service pack level. You can obtain a Windows-compatible version of Nmap, called nmapNT, at eEye Digital Security (http://www.eeye.com/html/Research/Tools/nmapNT.html).
NmapNT allows you to detect what services (application name and version) a network is offering, what OS and OS version it’s running, what type of packet filters/firewalls are in use, and dozens of other characteristics. If you haven’t already done so, you will need to install WinPcap (the Windows version of libpcap) first, which is included with nmapNT, and reboot. There is also a Windows GUI for nmapNT, called NMapWin (http://www.nmapwin.org).
OS fingerprinting is not a perfect science. Nmap often detects Windows XP systems as Windows 2000, or replies with a broad identifier indicating the tested machine is one of Windows XP, 2000, or NT. This is because Microsoft uses a similar IP stack source code base between most versions of Windows, and this isn’t unusual for other vendors either. If you want to manually test the fingerprinting process using nmapNT, try the following command:
nmapnt -vv -O [ipaddress]
The -vv parameter tells nmapNT to be very verbose about what it is doing, and the -O parameter tells it to fingerprint the destination host’s OS. Here’s what was reported when I used nmapNT to fingerprint one of my test systems:
Starting nmapNT V. 2.53 SP1 by ryan@eEye.com eEye Digital Security (http://www.eEye.com) based on nmap by email@example.com (www.insecure.org/nmap/) Host VLAB (192.168.168.203) appears to be up ... good. Initiating TCP connect() scan against VLAB (192.168.168.203) Adding TCP port 17 (state open). Adding TCP port 9 (state open). Adding TCP port 445 (state open). Adding TCP port 7 (state open). Adding TCP port 1025 (state open). Adding TCP port 13 (state open). Adding TCP port 135 (state open). Adding TCP port 19 (state open). Adding TCP port 139 (state open). The TCP connect scan took 39 seconds to scan 1523 ports. For OSScan assuming that port 7 is open and port 1 is closed and neither are firewalled Interesting ports on VLAB (192.168.168.203): (The 1514 ports scanned but not shown below are in state: closed) Port State Service 7/tcp open echo 9/tcp open discard 13/tcp open daytime 17/tcp open qotd 19/tcp open chargen 135/tcp open loc-srv 139/tcp open netbios-ssn 445/tcp open microsoft-ds 1025/tcp open listen TCP Sequence Prediction: Class=random positive increments Difficulty=6389 (Worthy challenge) Sequence numbers: CE5DB8E2 CE62A74D CE67E086 CE6CE70A CE7206AD CE77192B Remote operating system guess: Windows 2000 Professional, Build 2183 (RC3) OS Fingerprint: TSeq(Class=RI%gcd=1%SI=18F5) T1(Resp=Y%DF=Y%W=FAF0%ACK=S++%Flags=AS%Ops=MNWNNT) T2(Resp=Y%DF=N%W=0%ACK=S%Flags=AR%Ops=) T3(Resp=Y%DF=Y%W=FAF0%ACK=S++%Flags=AS%Ops=MNWNNT) T4(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T5(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) T6(Resp=Y%DF=N%W=0%ACK=O%Flags=R%Ops=) T7(Resp=Y%DF=N%W=0%ACK=S++%Flags=AR%Ops=) PU(Resp=N) Nmap run completed – 1 IP address (1 host up) scanned in 46 seconds
NmapNT was accurate in detecting the host as a Windows 2000 Professional machine.
Of the two fingerprinting technologies, Nmap and Xprobe2, the latter is the more accurate. It uses ICMP,TCP, UDP, port scanning,TTL, and a fuzzy logic signature database. Unfortunately, a Windows port of Xprobe did not exist at the time this book was written. Still, check out an excellent article on Xprobe2 and fingerprinting at http://www.sys-security.com/archive/papers/Present_and_Future_Xprobe2-v1.0.pdf.
Passive fingerprinting occurs when a fingerprinting tool does not directly interact with the remote machine. Instead, it captures (sniffs) packets returning from the destination machine off the wire headed elsewhere. Active fingerprinting can more quickly identify the host, but it also may alert the remote computer of the fingerprinting. The interrogated user could then track back the fingerprinting to the originating host and implement countermeasures. The passive fingerprinting software tool can be running on the honeypot or any machine that is capable of intercepting the remote machine’s network packets.
A common passive fingerprinting tool is P0f (http://lcamtuf.coredump.cx/p0f.shtml). It can passively fingerprint machines that connect to your computer or honeypot, find firewalls, and define the remote host’s Internet connection type. It doesn’t generate any network traffic of its own; it only listens.
Because passive fingerprinting never directly involves the fingerprinting computer in the communications to or from the target, it is difficult to trace a passive fingerprinting attack. If your honeypot is attacked, you may be tempted to ping the hacker’s computer in order to learn more information. However, hackers often have their own defenses and firewalls, and they might be alerted to a ping originating from a computer or network they attacked and go into hiding mode. Honeypot administrators can use passive fingerprinting to find out more information about the attacking machine without alerting attackers or without them knowing the fingerprinting is coming from the same network they are attacking. Passive fingerprinting is even used by security experts to trace malicious hackers.
To learn more about active and passive ICMP fingerprinting, read Ofir Arkin’s PowerPoint presentation “Active and Passive Fingerprinting of Microsoft Based Operating Systems Using the ICMP Protocol,” located at http://www.blackhat.com/presentations/win-usa-01/Arkin/Briefings/win-01-arkin.ppt.
Application fingerprinting involves discovering which application, service, or daemon is running at a particular port on a particular host. An application may be fingerprinted by something as simple as telnetting to a TCP/IP port on a host computer. For example, the hacker may be looking for IIS computers because her collection of malware tools and knowledge contains IIS exploits.
Often, a message indicating success or failure will include information identifying the application and version. The process of capturing the returned text is called banner grabbing. For example, telnetting to port 80 of an IIS server will return a message identifying the version of IIS. The following is an example of IIS 4.0 error message text that was returned by typing Telnet x.x.x.x 80 and pressing the Enter key twice, where x.x.x.x represents the IP address of the IIS server.
HTTP /1.1 400 Bad Request Server: Microsoft-IIS/4.0 Date: Sat, 07, Jun 2003 13:16:38 GMT Content-Type: text/html Content-Length: 87
Although the error message returned by IIS can be modified to prevent easy identification, most administrators do not take the time. If I were a malicious hacker and found this result, I would then try exploits known to compromise IIS 4.0 hosts.
In another example, I telnetted to port 25 of another Internet computer, an Exchange e-mail server, and here is the result:
220 ntserver.companyname.com ESMTP Server (Microsoft Exchange Internet Mail Service 5.5.2448.0) ready
In this case, I’ve found a publicly accessible Exchange Server 5.5 system. If I were a malicious hacker, I could research all the exploits known to work against Exchange Server 5.5, try to relay spam, or send an e-mail worm. In both examples, because of the application versions, I also know that the underlying OS is probably Windows NT 4.0, and I can try NT 4.0 exploits.
Manual attacks often result in the victim computer being compromised and the hacker gaining administrator access to the computer. This is known as being owned. After hackers have owned a box, they usually upload more hacking software. They will patch the holes that allowed them unauthorized access in the first place. If it is a web server, they may deface the web content and leave. Often, hackers will set up the newly compromised box as an instant messaging (IM) server and host chat channels dedicated to hacking. They might use the newly acquired hard drive space to serve as storage space for other illegal software. Frequently, compromised machines are used to attack other machines. In my experience, Unix honeypots tend to be exploited more by manual attacks, and Windows honeypots are more subject to automated attack programs.
Automated attack programs include computer viruses, network scanning worms, e-mail worms, trojans, and other sorts of malicious mobile code. Whereas, a hacker might try many different vulnerabilities to gain access to a box, automated programs are the exact opposite. Automated attacks, like the Code Red and Nimda worms, knock on every door trying the same exploits. They are so quick at attacking machines that they usually don’t take the time to check to see if the machine could ever be vulnerable to the particular type of exploit that they are trying. For example, Code Red attempts its IIS ida.dll buffer overflow against every computer that it finds. It doesn’t care that only unpatched versions of IIS 4 and 5 are vulnerable. It doesn’t care that a far greater percentage of computers attached to the Internet are not running IIS at all.
I used to wonder how successful an automated hacking program could be when it wastes precious CPU cycles attacking computers that will never be vulnerable to the exploit it is trying. The SQL Slammer worm erased any doubt I had. Although only unpatched Microsoft SQL Server servers and workstations were vulnerable, Slammer was able to scan and attack most of the Internet in a few hours. In ten minutes, it infected 90% of its potentially exploitable hosts and had brought down a major banking ATM network.
Automated attacks usually compromise the host, do their damage, and then move on. Most malicious mobile code doesn’t do any intentional damage beyond the initial compromise and subsequent replication. Occasionally, an automated malware program will go out of its way to damage files or do some other sort of mischief, but that behavior is more the exception than the rule.
Frequently, hackers will allow automated programs to gain the initial access to an exploited machine, and then they drop into manual manipulation mode, or vice versa. A hacker fingerprints a particular system and then deploys an automated tool against it. For instance, a hacker can find an IIS 4 server and then deploy the Code Red worm against it alone. Once the hacker has gained access to the web server, he can upload a rootkit to get further access and to hide malicious manipulations.
It is common for attackers to run scripts (usually written in Perl), containing dozens to hundreds of known exploits, against an Internet host. The idea is that a script can be run against multiple hosts, and if any of the scanned hosts are vulnerable to just a single exploit within the script, then the host is compromised.
IIS servers are frequent attack targets of scanning scripts. If logging is enabled on an IIS computer facing the Internet, it is very common for it to log scripted attacks designed for web servers. The telltale sign is that the log contains dozens of attempted connections using malicious commands, all in seconds. The scanning script usually contains exploits for IIS and Apache. It isn’t worried about creating a lot of entries in the web server’s log files. If it can be successful with just one exploit, the hacker can get in and clean up the log files.
A rootkit is a special type of malware designed to replace legitimate OS executables with trojaned versions. Once modified by a rootkit, an OS cannot be trusted to log or report any activity accurately. Rootkits are especially adept at hiding from prying eyes; that is, except from honeypot administrators.
The rootkit automates what might otherwise be thousands of keystrokes and a dozen different program uploads. Although rootkits used to be just a Unix problem, there are at least four Windows rootkit programs in existence (http://www.rootkit.com). For instance, the NT Rootkit (https://www.rootkit.com/vault/hoglund/rk_044.zip) disables logging when the hacker is logged in, patches the kernel to run rogue code in privileged mode, hides processes, hides Registry changes, hides malicious files, and allows the hacker to remotely access the machine. Also, students are taught how to make rootkits in classes around the world. A more popular cousin to the rootkit is the remote-access trojan.
Remote access trojans (RATs) are another type of blended attack. The automated RAT will open a backdoor into the computer to allow the remote hacker access after the initial compromise. It will e-mail or send a message over a private IM chat channel to its originator about the successful compromise. The message usually reveals the compromised computer’s IP address so that the hacker can connect to it. The hacker can then control the computer, upload and download files, capture keystrokes (looking for confidential information like passwords and credit card numbers), capture screen shots, and manipulate the computer. She can open and close the CD-ROM drive door, flip the screen image, send fake error messages to the screen, reboot the computer, or damage files. Some RATs are capable of recording conversations via the computer’s microphone, and if the PC has a web camera, some RATs can even take unauthorized pictures.
There is a classic picture floating around computer security circles of a guy with a very perplexed look on his face. The shot was taken by hackers using the guy’s web camera after they sent him a message telling him to get off the computer and go take care of his wife, seen lying down on the bed behind him. The guy couldn’t understand how the computer could know that his wife was on the bed behind him. As in the credit card commercial saying, the look was priceless. I’m sure it was not lost on him that the remote hackers could have been recording more intimate moments.
It’s important to understand the different attack models so that you can better understand the honeypot logs. When a honeypot is compromised, first see if you can discover whether the attack is from an automated program or from a manual hack.
Automated attacks happen very quickly and will contain commands, sent milliseconds apart, with some that may not seem to fit the exploited box. Manual hacking is slower, often contains typos, but it also tends to take longer to decipher because the attack path isn’t always logical. Have your forensic tools ready and be prepared to start researching when the clues come in.