A New Breed of Hacker Tools and Defenses

Ed Skoudis, CISSP

The state-of-the-art in computer attack tools and techniques is rapidly advancing. Yes, we still face the tried-and-true, decades-old arsenal of traditional computer attack tools, including denial-of-service attacks, password crackers, port scanners, sniffers, and RootKits. However, many of these basic tools and techniques have seen a renaissance in the past couple of years, with new features and underlying architectures that make them more powerful than ever. Attackers are delving deep into widely used protocols and the very hearts of our operating systems. In addition to their growing capabilities, computer attack tools are becoming increasingly easy to use. Just when you think you have seen it all, a new and easy-to-use attack tool is publicly released with a feature that blows your socks off. With this constant increase in the sophistication and ease of use in attack tools, as well as the widespread deployment of weak targets on the Internet, we now live in the golden age of hacking.

The purpose of this chapter is to describe recent events in this evolution of computer attack tools. To create the best defenses for our computers, one must understand the capabilities and tactics of one’s adversaries. To achieve this goal, this chapter describes several areas of advance among attack tools, including distributed attacks, active snif?ng, and kernel-level RootKits, along with defensive techniques for each type of attack.

Distributed Attacks

One of the primary trends in the evolution of computer attack tools is the movement toward distributed attack architectures. Essentially, attackers are harnessing the distributed power of the Internet itself to improve their attack capabilities. The strategy here is pretty straightforward, perhaps deceptively so given the power of some of these distributed attack tools. The attacker takes a conventional computer attack and splits the work among many systems. With more and more systems collaborating in the attack, the attacker’s chances for success increase. These distributed attacks offer several advantages to attackers, including:

• They may be more dif?cult to detect.

• They usually make things more dif?cult to trace back to the attacker.

• They may speed up the attack, lowering the time necessary to achieve a given result.

• They allow an attacker to consume more resources on a target.

So, where does an attacker get all of the machines to launch a distributed attack? Unfortunately, enormous numbers of very weak machines are readily available on the Internet. The administrators and owners of such systems do not apply security patches from the vendors, nor do they con?gure their machines securely, often just using the default con?guration right out of the box. Poorly secured computers at universities, companies of all sizes, government institutions, homes with always-on Internet connectivity, and elsewhere are easy prey for an attacker. Even lowly skilled attackers can take over hundreds or thousands of systems around the globe with ease. These attackers use automated vulnerability scanning tools, including homegrown scripts and freeware tools such as the Nessus vulnerability scanner (http://www.nessus.org), among many others, to scan large swaths of the Internet. They scan indiscriminately, day in and day out, looking to take over vulnerable systems. After taking over a suitable number of systems, the attackers will use these victim machines as part of the distributed attack against another target.

Attackers have adapted many classic computer attack tools to a distributed paradigm. This chapter explores many of the most popular distributed attack tools, including distributed denial-of-service attacks, distributed password cracking, distributed port scanning, and relay attacks.

Distributed Denial-of-Service Attacks

One of the most popular and widely used distributed attack techniques is the distributed denial-of-service (DDoS) attack. In a DDoS attack, the attacker takes over a large number of systems and installs a remotely controlled program called a zombie on each system. The zombies silently run in the background awaiting commands. An attacker controls these zombie systems using a specialized client program running on one machine. The attacker uses one client machine to send commands to the multitude of zombies, telling them to simultaneously conduct some action. In a DDoS attack, the most common action is to ?ood a victim with packets. When all the zombies are simultaneously launching packet ?oods, the victim machine will be suddenly awash in bogus traf?c. Once all capacity of the victim’s communication link is exhausted, no legitimate user traf?c will be able to reach the system, resulting in a denial of service.

The DDoS attack methodology was in the spotlight in February 2000 when several high-pro?le Internet sites were hit with the attack. DDoS tools have continued to evolve, with new features that make them even nastier. The latest generation of DDoS attacks includes extensive spoo?ng capabilities, so that all traf?c from the client to the zombies and from the zombies to the target has a decoy source address. Therefore, when a ?ood begins, the investigators must trace the onslaught back, router hop by router hop, from the victim to the zombies. After rounding up some of the zombies, the investigators must still trace from the zombies to the client, across numerous hops and multiple Internet service providers (ISPs). Furthermore, DDoS tools are employing encryption to mask the location of the zombies. In early generations of DDoS tools, most of the client software included a ?le with a list of network addresses for the zombies. By discovering such a client, an investigation team could quickly locate and eradicate the zombies. With the latest generation of DDoS tools, the list of network addresses at the client is strongly encrypted so that the client does not give away the location of the zombies.

Defenses against Distributed Denial-of-Service Attacks

To defend against any packet ?ood, including DDoS attacks, one must ensure that critical network connections have suf?cient bandwidth and redundancy to eliminate simple attacks. If a network connection is mission critical, one should have at least a redundant T1 connection because all lower connection speeds can easily be ?ooded by an attacker.

While this baseline of bandwidth eliminates the lowest levels of attackers, one must face the fact that one will not be able to buy enough bandwidth to keep up with attackers who have installed zombies on a hundred or thousand systems and pointed them at your system as a target. If one’s system’s availability on the Internet is critical to the business, one must employ additional techniques for handling DDoS attacks. From a techno-logical perspective, one may want to consider traf?c shaping tools, which can help manage the number of incoming sessions so that one’s servers are not overwhelmed. Of course, a large enough cadre of zombies ?ooding one’s connection could even overwhelm traf?c shapers. Therefore, one should employ intrusion detection systems (IDSs) to determine when an attack is underway. These IDSs act as network burglar alarms, listening to the network for traf?c that matches common attack signatures stored in the IDS database. From a procedural perspective, one should have an incident response team on stand-by for such alarms from the IDS. For mission-critical Internet connections, one must have the cell phone and pager numbers for one’s ISP’s own incident response team. When a DDoS attack begins, one’s incident response team must be able to quickly and ef?ciently marshal the forces of the ISP’s incident response team. Once alerted, the ISP can deploy ?lters in their network to block an active DDoS attack upstream.

Distributed Password Cracking

Password cracking is another technique that has been around for many years and is now being leveraged in distributed attacks. The technique is based on the fact that most modern computing systems (such as UNIX and Windows NT) have a database containing encrypted passwords used for authentication. In Windows NT, the passwords are stored in the SAM database. On UNIX systems, the passwords are located in the /etc/passwd or /etc/shadow ?les. When a user logs on to the system, the machine asks the user for a password, encrypts the value entered by the user, and compares the encrypted version of what the user typed with the stored encrypted password. If they match, the user is allowed to log in.

The idea behind password cracking is simple: steal an encrypted password ?le, guess a password, encrypt the guess, and compare the result to the value in the stolen encrypted password ?le. If the encrypted guess matches the encrypted password, the attacker has determined the password. If the two values do not match, the attacker makes another guess. Because user passwords are often predictable combinations of user IDs, dictionary words, and other characters, this technique is often very successful in determining passwords.

Traditional password cracking tools automate the guess-encrypt-compare loop to help determine passwords quickly and ef?ciently. These tools use variations of the user ID, dictionary terms, and brute-force guessing of all possible character combinations to create their guesses for passwords. The better password-cracking tools can conduct hybrid attacks, appending and prepending characters in a brute-force fashion to standard dictio-nary words. Because most passwords are simply a dictionary term with a few special characters tacked on at the beginning or end, the hybrid technique is extremely useful. Some of the best traditional password-cracking tools are L0phtCrack for Windows NT passwords (available at http://www.l0pht.com) and John the Ripper for a variety of password types, including UNIX and Windows NT (available at http://www.openwall.com).

When cracking passwords, speed rules. Tools that can create and check more password guesses in less time will result in more passwords recovered by the attacker. Traditional password cracking tools address this speed issue by optimizing the implementation of the encryption algorithm used to encrypt the guesses. Attackers can gain even more speed by distributing the password-cracking load across numerous computers. To more rapidly crack passwords, attackers will simultaneously harness hundreds or thousands of systems located all over the Internet to churn through an encrypted password ?le.

To implement distributed password cracking, an attacker can use a traditional password-cracking tool in a distributed fashion by simply dividing up the work manually. For example, consider a scenario in which an attacker wants to crack a password ?le with ten encrypted passwords. The attacker could break the ?le into ten parts, each part containing one encrypted password, and then distribute each part to one of ten machines. Each machine runs a traditional password-cracking tool to crack the one encrypted password assigned to that system. Alternatively, the attacker could load all ten encrypted passwords on each of the machines and con?gure each traditional password-cracking tool to guess a different set of passwords, focusing on a different part of a dictionary or certain characters in a brute-force attack.

Beyond manually splitting up the work and using a traditional password-cracking tool, several native distributed password-cracking tools have been released. These tools help to automate the spreading of the workload across several machines and coordinate the computing resources as the attack progresses. Two of the most popular distributed password-cracking tools are Mio-Star and Saltine Cracker, both available at http://packet-storm.securify.com/distributed

Defenses against Distributed Password Cracking

The defenses against distributed password cracking are really the same as those employed for traditional password cracking: eliminate weak passwords from your systems. Because distributed password cracking speeds up the cracking process, passwords need to be even more dif?cult to guess than in the days when nondistributed password cracking ruled. One must start with a policy that mandates users to establish passwords that are greater than a minimum length (such as greater than nine characters) and include numbers, letters, and special characters in each password. Users must be aware of the policy; thus, an awareness program emphasizing the importance of dif?cult-to-guess passwords is key. Furthermore, to help enforce a password policy, one may want to deploy password-?ltering tools on one’s authentication servers. When a user establishes a new password, these tools check the password to make sure it conforms to the password policy. If the password is too short, or does not include numbers, letters, and special characters, the user will be asked to select another password. The pass?lt.dll program included in the Windows NT Resource Kit and the passwd+ program on UNIX systems implement this type of feature, as do several third-party add-on authentication products. One also may want to consider the elimination of standard passwords from very sensitive environments, using token-based access technologies.

Finally, security personnel should periodically run a password-cracking tool against one’s own users’ pass-words to identify the weak ones before an attacker does. When weak passwords are found, there should be a de?ned and approved process for informing users that that they should select a better password. Be sure to get appropriate permissions before conducting in-house password-cracking projects to ensure that manage-ment understands and supports this important security program. Not getting management approval could negatively impact one’s career.

Distributed Port Scanning

Another attack technique that lends itself well to a distributed approach is the port scan. A port is an important concept in the Transmission Control Protocol (TCP) and the User Datagram Protocol (UDP), two protocols used by the vast majority of Internet services. Every server that receives TCP or UDP traf?c from a network listens on one or more ports. These ports are like little virtual doors on a machine, where packets can go in or come out. The port numbers serve as addresses on a system where the packets should be directed. While an administrator can con?gure a network service to listen on any port, the most common services listen on well-known ports, so that client software knows where to send the packets. Web servers usually listen on TCP port 80, while Internet mail servers listen on TCP port 25. Domain Name Servers listen for queries on UDP port 53. Hundreds of other ports are assigned to various services in RFC 1700, a document available at http:/ /www.ietf.org/rfc.html.

Port scanning is the process of sending packets to various ports on a target system to determine which ports have listening services. It is similar to knocking on the doors of the target system to see which ones are open. By knowing which ports are open on the target system, the attacker has a good idea of the services running on the machine. The attacker can then focus an attack on the services associated with these open ports. Furthermore, each open port on a target system indicates a possible entry point for an attacker. The attacker can scan the machine and determine that TCP port 25 and UDP port 53 are open. This result tells the attacker that the machine is likely a mail server and a DNS server. While there are a large number of traditional port-scanning tools available, one of the most powerful (by far) is the Nmap tool, available at http://www.inse-cure.org.

Because a port scan is often the precursor to a more in-depth attack, security personnel often use IDS tools to detect port scans as an early-warning indicator. Most IDSs include speci?c capabilities to recognize port scans. If a packet arrives from a given source going to one port, followed by another packet from the same source going to another port, followed by yet another packet for another port, the IDS can quickly correlate these packets to detect the scan. This traf?c pattern is shown on the left-hand side of Exhibit 11.1, where port numbers are plotted against source network address. IDSs can easily spot such a scan, and ring bells and whistles (or send an e-mail to an administrator).

Now consider what happens when an attacker uses a distributed approach for conducting the scan. Instead of a barrage of packets coming from a single address, the attacker will con?gure many systems to participate in the scan. Each scanning machine will send only one or two packets and receive the results. By working together, the scanning machines can check all of the interesting ports on the target system and send their result to be correlated by the attacker. An IDS looking for the familiar pattern of the traditional port scan will not detect the attack. Instead, the pattern of incoming packets will appear more random, as shown on the right side of Exhibit 11.1. In this way, distributed scanning makes detection of attacks more dif?cult.

Of course, an IDS system can still detect the distributed port scan by focusing on the destination address (i.e., the place where the packets are going) rather than the source address. If a number of systems suddenly sends packets to several ports on a single machine, an IDS can deduce that a port scan is underway. But the attacker has raised the bar for detection by conducting a distributed scan. If the distributed scan is conducted over a longer period of time (e.g., a week or a month), the chances of evading an IDS are quite good for an attacker. Distributed port scans are also much more dif?cult to trace back to an attacker because the scan comes from so many different systems, none of which are owned by the attacker.

Several distributed port-scanning tools are available. An attacker can use the descriptively named Phpdis-tributedportscanner, which is a small script that can be placed on Web servers to conduct a scan. Whenever attackers take over a PHP-enabled Web server, they can place the script on the server and use it to scan other systems. The attacker interacts with the individual scanning scripts running on the various Web servers using HTTP requests. Because everything is Web based, distributed port scans are quite simple to run. This scanning tool is available at http://www.digitaloffense.net:8000/phpDistributedPortScanner/. Other distributed port scanners tend to be based on a client/server architecture, such as Dscan (available at http://packet-storm.securify.com/distributed) and SIDEN (available at http://siden.sourceforge.net).

Defenses against Distributed Scanning

The best defense against distributed port scanning is to shut off all unneeded services on one’s systems. If a machine’s only purpose is to run a Web server that communicates via HTTP and HTTPS, the system should have only TCP port 80 and TCP port 443 open. If one does not need a mail server running on the same machine as the Web server, one should con?gure the system so that the mail server is deactivated. If the X Window system is not needed on the machine, turn it off. All other services should be shut off, which would close all other ports. One should develop a secure con?guration document that provides a step-by-step process for all system administrators in an organization for building secure servers.

Additionally, one must ensure that IDS probes are kept up-to-date. Most IDS vendors distribute new attack signatures on a regular basis — usually once a month. When a new set of attack signatures is available, one should quickly test it and deploy it on the IDS probes so they can detect the latest batch of attacks.

Relay Attacks

A ?nal distributed attack technique involves relaying information from machine to machine across the Internet to obscure the true source of the attack. As one can expect, most attackers do not want to get caught. By setting up extra layers of indirection between an attacker and the target, the attacker can avoid being apprehended. Suppose an attacker takes over half a dozen Internet-accessible machines located all over the world and wants to attack a new system. The attacker can set up packet redirector programs on the six systems. The ?rst machine will forward any packets received on a given port to the second system. The second system would then forward them to the third system, and so on, until the new target is reached. Each system acts as a link in a relay chain for the attacker’s traf?c. If and when the attack is detected, the investigation team will have to trace the attack back through each relay point before ?nding the attacker.

Attackers often set up relay chains consisting of numerous systems around the globe. Additionally, to further foil investigators, attackers often try to make sure there is a great change in human language and geopolitical relations between the countries where the links of the relay chain reside. For example, the ?rst relay may be in the United States, while the second may be in China. The third could be in India, while the fourth is in Pakistan. Finally, the chain ends in Iran for an attack against a machine back in the United States. At each stage of the relay chain, the investigators would have to contend with dramatic shifts in human language, less-than-friendly relations between countries, and huge law enforcement jurisdictional issues.

Relay attacks are often implemented using a very ?exible tool called Netcat, which is available for UNIX at http://www.l0pht.com/users/10pht/ nc110.tgz, and for Windows NT at http://www.l0pht.com/~weld/netcat/. Another popular tool for creating relays is Redir, located at http:// oh.verio.com/~sammy/hacks.

Defenses against Relay Attacks

Because most of the action in a relay attack occurs outside an organization’s own network, there is little one can do to prevent such attacks. One cannot really stop attackers from bouncing their packets through a bunch of machines before being attacked. One’s best bet is to make sure that systems are secure by applying  security patches and shutting down all unneeded services. Additionally, it is important to cooperate with law enforce-ment of?cials in their investigations of such attacks.

Active Snif?ng

Snif?ng is another, older technique that is being rapidly expanded with new capabilities. Traditional sniffers are simple tools that gather traf?c from a network. The user installs a sniffer program on a computer that captures all data passing by the computer’s network interface, whether it is destined for that machine or another system. When used by network administrators, sniffers can capture errant packets to help troubleshoot the network. When used by attackers, sniffers can grab sensitive data from the network, such as passwords, ?les, e-mail, or anything else transmitted across the network.

Traditional Snif?ng

Traditional snif?ng tools are passive; they wait patiently for traf?c to pass by on the network and gather the data when it arrives. This passive technique works well for some network types. Traditional Ethernet, a popular tech-nology used to create a large number of local area networks (LANs), is a broadcast medium. Ethernet hubs are devices used to create traditional Ethernet LANs. All traf?c sent to any one system on the LAN is broadcast to all machines on the LAN. A traditional sniffer can therefore snag any data going between other systems on the same LAN. In a traditional snif?ng attack, the attacker takes over one system on the LAN, installs a sniffer, and gathers traf?c destined for other machines on the same LAN. Some of the best traditional sniffers include Snort (available at http://www.snort.org) and Snif?t (available at http://reptile.rug.ac.be/~coder/snif?t/snif?t.html).

One of the commonly used defenses against traditional sniffers is a switched LAN. Contrary to an Ethernet hub, which acts as a broadcast medium, an Ethernet switch only sends data to its intended destination on the LAN. No other system on the LAN is able to see the data because the Ethernet switch sends the data to its appropriate destination and nowhere else. Another commonly employed technique to foil traditional sniffers is to encrypt data in transit. If the attackers do not have the encryption keys, they will not be able to determine the contents of the data sniffed from the network. Two of the most popular encryption protocols are the Secure Socket Layer (SSL), which is most often used to secure Web traf?c, and Secure Shell (SSH), which is most often used to protect command-line shell access to systems.

Raising the Ante with Active Snif?ng

While the defenses against passive sniffers are effective and useful to deploy, attackers have developed a variety of techniques for foiling them. These techniques, collectively known as active snif?ng, involve injecting traf?c into the network to allow an attacker to grab data that should otherwise be unsniffable. One of the most capable active snif?ng programs available is Dsniff, available at http://www.monkey.org/~dugsong/dsniff/. One can explore Dsniff ’s various methods for snif?ng by injecting traf?c into a network, including MAC address ?ooding, spurious ARP traf?c, fake DNS responses, and person-in-the-middle attacks against SSL.

MAC Addresses Flooding

An Ethernet switch determines where to send traf?c on a LAN based on its media access control (MAC) address. The MAC address is a unique 48-bit number assigned to each Ethernet card in the world. The MAC address indicates the unique network interface hardware for each system connected to the LAN. An Ethernet switch monitors the traf?c on a LAN to learn which plugs on the switch are associated with which MAC addresses. For example, the switch will see traf?c arriving from MAC address AA:BB:CC:DD:EE:FF on plug number one. The switch will remember this information and send data destined for this MAC address only to the ?rst plug on the switch. Likewise, the switch will autodetect the MAC addresses associated with the other network interfaces on the LAN and send the appropriate data to them.

One of the simplest, active snif?ng techniques involves ?ooding the LAN with traf?c that has bogus MAC addresses. The attacker uses a program installed on a machine on the LAN to generate packets with random MAC addresses and feed them into the switch. The switch will attempt to remember all of the MAC addresses as they arrive. Eventually, the switch’s memory capacity will be exhausted with bogus MAC addresses. When their memory ?lls up, some switches fail into a mode where traf?c is sent to all machines connected to the LAN. By using MAC ?ooding, therefore, an attacker can bombard a switch so that the switch will send all traf?c to all machines on the LAN. The attacker can then utilize a traditional sniffer to grab the data from the LAN.

Spurious ARP Traf?c

While some switches fail under a MAC ?ood in a mode where they send all traf?c to all systems on the LAN, other switches do not. During a ?ood, these switches remember the initial set of MAC addresses that were autodetected on the LAN, and utilize those addresses throughout the duration of the ?ood. The attacker cannot launch a MAC ?ood to overwhelm the switch. However, an attacker can still undermine such a LAN by injecting another type of traf?c based on the Address Resolution Protocol (ARP).

ARP is used to map Internet Protocol (IP) addresses into MAC addresses on a LAN. When one machine has data to send to another system on the LAN, it formulates a packet for the destination’s IP address; however, the IP address is just a con?guration setting on the destination machine. How does the sending machine with the packet to deliver determine which hardware device on the LAN to send the packet to? ARP is the answer. Suppose a machine on the LAN has a packet that is destined for IP address 10.1.2.3. The machine with the packet will send an ARP request on the LAN, asking which network interface is associated with IP address

10.1.2.3. The machine with this IP address will transmit an ARP response, saying, in essence, “IP Address

10.1.2.3 is associated with MAC address AA:BB:CC:DD:EE:FF.” When a system receives an ARP response, it stores the mapping of IP address to MAC address in a local table, called the ARP table, for future reference. The packet will then be delivered to the network interface with this MAC address. In this way, ARP is used to convert IP addresses into MAC addresses so that packets can be delivered to the appropriate network interface on the LAN. The results are stored in a system’s ARP table to minimize the need for additional ARP traf?c on the LAN.

ARP includes support for a capability called the “gratuitous ARP.” With a gratuitous ARP, a machine can send an ARP response although no machine sent an ARP request. Most systems are thirsty for ARP entries in their ARP tables, to help improve performance on the LAN. In another form of active snif?ng, an attacker utilizes faked gratuitous ARP messages to redirect traf?c for snif?ng a switched LAN, as shown in Exhibit 11.2. For the exhibit, the attacker’s machine on the LAN is indicated by a black hat.

The steps of this attack, shown in Exhibit 11.2, are:

1. The attacker activates IP forwarding on the attacker’s machine on the LAN. Any packets directed by the switch to the black-hat machine will be redirected to the default router for the LAN.

2. The attacker sends a gratuitous ARP message to the target machine. The attacker wants to sniff traf?c sent from this machine to the outside world. The gratuitous ARP message will map the IP address of the default router for the LAN to the MAC address of the attacker’s own machine. The target machine accepts this bogus ARP message and enters it into its ARP table. The target’s ARP table is now poisoned with the false entry.

3. The target machine sends traf?c destined for the outside world. It consults its ARP table to determine the MAC address associated with the default router for the LAN. The MAC address it ?nds in the ARP table is the attacker’s address. All data for the outside world is sent to the attacker’s machine.

4. The attacker sniffs the traf?c from the line.

5. The IP forwarding activated in Step 1 redirects all traf?c from the attacker’s machine to the default router for the LAN. The default router forwards the traf?c to the outside world. In this way, the victim will be able to send traf?c to the outside world, but it will pass through the attacker’s machine to be sniffed on its way out.

This sequence of steps allows the attacker to view all traf?c to the outside world from the target system. Note that, for this technique, the attacker does not modify the switch at all. The attacker is able to sniff the switched LAN by manipulating the ARP table of the victim. Because ARP traf?c and the associated MAC address information are only transmitted across a LAN, this technique only works if the attacker controls a machine on the same LAN as the target system.

Fake DNS Responses

A technique for injecting packets into a network to sniff traf?c beyond a LAN involves manipulating the Domain Name System (DNS). While ARP is used on a LAN to map IP addresses to MAC addresses on a LAN, DNS is used across a network to map domain names into IP addresses. When a user types a domain name into some client software, such as entering www.skoudisstuff.com into a Web browser, the user’s system sends out a query to a DNS server. The DNS server is usually located across the network on a different LAN. Upon receiving the query, the DNS server looks up the appropriate information in its con?guration ?les and sends a DNS response to the user’s machine that includes an IP address, such as 10.22.12.41. The DNS server maps the domain name to IP address for the user.

Attackers can redirect traf?c by sending spurious DNS responses to a client. While there is no such thing as a gratuitous DNS response, an attacker that sits on any network between the target system and the DNS server can sniff DNS queries from the line. Upon seeing a DNS query from a client, the attacker can send a fake DNS response to the client, containing an IP address of the attacker’s machine. The client software on the users’ machine will send packets to this IP address, thinking that it is communicating with the desired server. Instead, the information is sent to the attacker’s machine. The attacker can view the information using a traditional sniffer, and relay the traf?c to its intended destination.

Person-in-the-Middle Attacks against SSL

Injecting fake DNS responses into a network is a particularly powerful technique when it is used to set up a person-in-the-middle attack against cryptographic protocols such as SSL, which is commonly used for secure Web access. Essentially, the attacker sends a fake DNS response to the target so that a new SSL session is established through the attacker’s machine. As highlighted in Exhibit 11.3, the attacker uses a specialized relay tool to set up two cryptographic sessions: one between the client and the attacker, and the other between the attacker and the server. While the data moves between these sessions, the attacker can view it in cleartext.

The steps shown in Exhibit 11.3 include:

1. The attacker activates Dsniff ’s dnsspoof program, a tool that sends fake DNS responses. Additionally, the attacker activates another Dsniff tool called “webmitm,” an abbreviation for Web Monkey-in-the-Middle. This tool implements a specialized SSL relay.

2. The attacker observes a DNS query from the victim machine and sends a fake DNS response. The fake DNS response contains the IP address of the attacker’s machine.

3. The victim receives the DNS response and establishes an SSL session with the IP address included in the response.

4. The webmitm tool running on the attacker’s machine established an SSL session with the victim machine, and another SSL session with the actual Web server that the client wants to access.

5. The victim sends data across the SSL connection. The webmitm tool decrypts the traf?c from the SSL connection with the victim, displays it for the attacker, and encrypts the traf?c for transit to the external Web server. The external Web server receives the traf?c, not realizing that a person-in-the-middle attack is occurring.

While this technique is quite effective, it does have one limitation from the attacker’s point of view. When establishing the SSL connection between the victim and the attacker’s machine, the attacker must send the victim an SSL digital certi?cate that belongs to the attacker. To decrypt all data sent from the target, the attacker must use his or her own digital certi?cate, and not the certi?cate from the actual destination Web server. When the victim’s Web browser receives the bogus certi?cate from the attacker, it will display a warning message to the user. The browser will indicate that the certi?cate it was presented by the server was signed by a certi?cate authority that is not trusted by the browser. The browser then gives the user the option of establishing the connection by simply clicking on a button labeled “OK” or “Connect.” Most users do not understand the warning messages from their browsers and will continue the connection without a second thought. The browser will be satis?ed that it has established a secure connection because the user told it to accept the attacker’s certi?cate. After continuing the connection, the attacker will be able to gather all traf?c from the SSL session. In essence, the attacker relies on the fact that trust decisions about SSL certi?cates are left in the hands of the user.

The same basic technique works against the Secure Shell (SSH) protocol used for remote command-shell access. Dsniff includes a tool called sshmitm that can be used to set up a person-in-the-middle attack against SSH. Similar to the SSL attack, Dsniff establishes two SSH connections: one between the victim and the attacker, and another between the attacker and the destination server. Also, just as the Web browser complained about the modi?ed SSL certi?cate, the SSH client will complain that it does not recognize the public key used by the SSH server. The SSH client will still allow the user, however, to override the warning and establish the SSH session so the attacker can view all traf?c.

Defenses against Active Snif?ng Techniques

Having seen how an attacker can grab all kinds of useful information from a network using snif?ng tools, how can one defend against these attacks? First, whenever possible, encrypt data that gets transmitted across the network. Use secure protocols such as SSL for Web traf?c, SSH for encrypted log-in sessions and ?le transfer, S/MIME for encrypted e-mail, and IPSec for network-layer encryption. Users must be equipped to apply these tools to protect sensitive information, both from a technology and an awareness perspective.

It is especially important that system administrators, network managers, and security personnel understand and use secure protocols to conduct their job activities. Never telnet to ?rewall, routers, sensitive servers, or public key infrastructure (PKI) systems! It is just too easy for an attacker to intercept one’s password, which telnet transmits in cleartext. Additionally, pay attention to those warning messages from the browser and SSH client. Do not send any sensitive information across the network using an SSL session created with an untrusted certi?cate. If the SSH client warns that the server public key mysteriously changed, there is need to investigate.

Additionally, one really should consider getting rid of hubs because they are just too easy to sniff through. Although the cost may be higher than hubs, switches not only improve security, but also improve performance. If a complete migration to a switched network is impossible, at least consider using switched Ethernet on critical network segments, particularly the DMZ.

Finally, for networks containing very sensitive systems and data, enable port-level security on your switches by con?guring each switch port with the speci?c MAC address of the machine using that port to prevent MAC ?ooding problems and fake ARP messages. Furthermore, for extremely sensitive networks, such as Internet DMZs, use static ARP tables on the end machines, hard coding the MAC addresses for all systems on the LAN. Port security on a switch and hard-coded ARP tables can be very dif?cult to manage because swapping components or even Ethernet cards requires updating the MAC addresses stored in several systems. For very sensitive networks such as Internet DMZs, this level of security is required and should be implemented.

The Proliferation of Kernel-Level RootKits

Just as attackers are targeting key protocols such as ARP and DNS at a very fundamental level, so too are they exploiting the heart of our operating systems. In particular, a great deal of development is underway on kernel-level RootKits. To gain a better understanding of kernel-level RootKits, one should ?rst analyze their evolu-tionary ancestors, traditional RootKits.

Traditional RootKits

A traditional RootKit is a suite of tools that allows an attacker to maintain superuser access on a system. Once an attacker gets root-level control on a machine, the RootKit lets the attacker maintain that access. Traditional RootKits usually include a backdoor so the attacker can access the system, bypassing normal security controls. They also include various programs to let the attacker hide on the system. Some of the most fully functional traditional RootKits include Linux RootKit 5 (lrk5) and T0rnkit, which runs on Solaris and Linux. Both of these RootKits, as well as many others, are located at http://packetstorm.securify.com/UNIX/penetration/ rootkits.

Traditional RootKits implement backdoors and hiding mechanisms by replacing critical executable programs included in the operating system. For example, most traditional RootKits include a replacement for the /bin/ login program, which is used to authenticate users logging into a UNIX system. A RootKit version of /bin/ login usually includes a backdoor password, known by the attacker, that can be used for root-level access of the machine. The attacker will write the new version of /bin/login over the earlier version, and modify the timestamps and ?le size to match the previous version.

Just as the /bin/login program is replaced to implement a backdoor, most RootKits include Trojan horse replacement programs for other UNIX tools used by system administrators to analyze the system. Many traditional RootKits include Trojan horse replacements for the ls command (which normally shows the contents of a directory). Modi?ed versions of ls will hide the attacker’s tools, never displaying their presence. Similarly, the attackers will replace netstat, a tool that shows which TCP and UDP ports are in use, with a modi?ed version that lies about the ports used by an attacker. Likewise, many other system programs will be replaced, including ifcon?g, du, and ps. All of these programs act like the eyes and ears of a system administrator. The attacker utilizes a traditional RootKit to replace these eyes and ears with new versions that lie about the attacker’s presence on the system.

To detect traditional RootKits, many system administrators employ ?le system integrity checking tools, such as the venerable Tripwire program available at http://www.tripwire.com. These tools calculate cryptographically strong hashes of critical system ?les (such as /bin/login, ls, netstat, ifcon?g, du, and ps) and store these digital ?ngerprints on a safe medium such as a write-protected ?oppy disk. Then, on a periodic basis (usually daily or weekly), the integrity-checking tool recalculates the hashes of the executables on the system and compares them with the stored values. If there is a change, the program has been altered, and the system administrator is alerted.

Kernel-Level RootKits

While traditional RootKits replace critical system executables, attackers have gone even further by implementing kernel-level RootKits. The kernel is the heart of most operating systems, controlling access to all resources,

System with Traditional RootKit System with Kernel-Level RootKit

good	good	good		good
login	ps	ifconfig		tripwire
Kernel			Trojan Kernel Module

such as the disk, system processor, and memory. Kernel-level RootKits modify the kernel itself, rather than manipulating application-level programs like traditional RootKits. As shown on the left side of Exhibit 11.4, a traditional RootKit can be detected because a ?le system integrity tool such as Tripwire can rely on the kernel to let it check the integrity of application programs. When the application programs are modi?ed, the good Tripwire program utilizes the good kernel to detect the Trojan horse replacement programs.

A kernel-level RootKit is shown on the right-hand side of Exhibit 11.4. While all of the application programs are intact, the kernel itself is rotten, facilitating backdoor access by the attacker and lying to the administrator about the attacker’s presence on the system. Some of the most powerful kernel-level RootKits include Knark for Linux available at http://packetstorm. securify.com/UNIX/penetration/rootkits, Plasmoid’s Solaris kernel-level RootKit available at http://www.infowar.co.uk/thc/slkm-1.0.html, and a Windows NT kernel-level RootKit available at http://www.rootkit.com.

While a large number of kernel-level RootKits have been released with a variety of features, the most popular capabilities of these tools include:

• Execution redirection. This capability intercepts a call to run a certain application and maps that call to run another application of the attacker’s choosing. Consider a scenario involving the UNIX /bin/login routine. The attacker will install a kernel-level RootKit and leave the /bin/login ?le unaltered. All execution requests for /bin/login (which occur when anyone logs in to the system) will be mapped to the hidden ?le /bin/backdoorlog in. When a user tries to login, the /bin/backdoorlogin program will be executed, containing a backdoor password allowing for root-level access. However, when the system administrator runs a ?le integrity checker such as Tripwire, the standard /bin/login routine is analyzed. Only execution is redirected; one can look at the original ?le /bin/login and verify its integrity. This original routine is unaltered, so the Tripwire hash will remain the same.

• File hiding. Many kernel-level RootKits let an attacker hide any ?le in the ?le system. If any user or application looks for the ?le, the kernel will lie and say that the ?le is not present on the machine. Of course, the ?le is still on the system, and the attacker can access it when required.

• Process hiding. In addition to hiding ?les, the attacker can use the kernel-level RootKit to hide a running process on the machine.

Each of these capabilities is quite powerful by itself. Taken together, they offer an attacker the ability to completely transform the machine at the attacker’s whim. The system administrator will have a view of the system created by the attacker, with everything looking intact. But in actuality, the system will be rotten to the core, quite literally. Furthermore, detection of kernel-level RootKits is often rather dif?cult because all access to the system relies on the attacker-modi?ed kernel.

Kernel-Level RootKit Defenses

To stop attackers from installing kernel-level RootKits (or traditional RootKits, for that matter), one must prevent the attackers from gaining superuser access on one’s systems in the ?rst place. Without superuser access, an attacker cannot install a kernel-level RootKit. One must con?gure systems securely, disabling all unneeded services and applying all relevant security patches. Hardening systems and keeping them patched are the best preventative means for dealing with kernel-level RootKits.

Another defense involves deploying kernels that do not support loadable kernel modules (LKMs), a feature of some operating systems that allows the kernel to be dynamically modi?ed. LKMs are often used to implement kernel-level RootKits. Linux kernels can be built without support for kernel modules. Unfortunately, Solaris systems up through and including Solaris 8 do not have the ability to disable kernel modules. For critical Linux systems, such as Internet-accessible Web, mail, DNS, and FTP servers, one should build the kernels of such systems without the ability to accept LKMs. One will have eliminated the vast majority of these types of attacks by creating nonmodular kernels.

Conclusions

The arms race between computer defenders and computer attackers continues to accelerate. As attackers devise methods for widely distributed attacks and burrow deeper into our protocols and operating systems, we must work even more diligently to secure our systems. Do not lose heart, however. Sure, the defensive techniques covered in this chapter can be a lot of work. However, by carefully designing and maintaining systems, one can maintain a secure infrastructure.

Tagged as: Information Security