If an attacker has access to a machine itself but not to any account on it, physical attacks can be very effective. We classify these as local attacks, since they require local access to the machine console rather than access via a network protocol.

Trivial local attacks such as stealing a machine or a hard drive with sensitive information will not be considered. These are valid attacks, but most theft countermeasures involve administrative and legal policies, rather than technical measures. In addition, stealing the computer hardly qualifies as hacking.

Shoulder surfing is another trivial attack, one that can be lumped together with social engineering attacks. In this case, a malicious intruder glances over the shoulder of a typing user to obtain a login password combination or other secrets.

Suppose the intruder does not steal a machine, but rather tries to reboot it by power-cycling it or by pressing the Reset button. Although such a strategy is damaging to Unix machines, most nevertheless survive the hit and try to boot Unix again.

However, if the machine is set to boot off a floppy or a CD-ROM (as many Intel i386 computers are), we have our first attack scenario. By changing the boot media, a hacker can boot the machine into another operating system, such as DOS, that does not respect standard Unix file permissions. Utilities such as the ltools kit (for access to Linux disks from Windows) can be used to access the drives and compromise sensitive information. An attacker can then locate and steal a password file located on a disk, even if /etc/shadow is used and is only readable by a user account.

Similarly, if single-user mode is not secured or if the attacker possesses the Unix/Linux boot media, she can boot to single-user mode and snoop around unrestricted. Note that if a machine is not set to boot from a floppy or CD-ROM, the BIOS/PROM may also be reset to accomplish the same thing.

Fortunately for many Unix systems there is no second OS that can be used in this manner. Sun, SGI, and HP Unix hardware do not run DOS, and the above attack will fail. In the case of those platforms, however, a smart attacker might use another Unix OS (such as NetBSD, which supports most of the above hardware) and boot into her own Unix as root. Linux now supports SPARC hardware (Sun) and some other proprietary Unix-based platforms as well.

Another potential attack during the initial boot process involves the system boot loader. For example, the Linux boot loader (LILO or GRUB) allows you to enter commands to control the boot—for example, in order to boot into single-user mode.

Interrupting the boot sequence also provides opportunities for hackers. Indeed, some Unix variants allow you to skip the startup of some daemons for debugging purposes. Skipping the startup of, say, a host-based firewall might be helpful for an attacker.

Upon noticing a machine locked by a screensaver, a skilled attacker still has options. While most tricks only apply to breaking Windows screensavers, Unix screensavers can sometime be bypassed as well. One well-known trick using a boot CD-ROM can sometimes be used for Unix as well as Windows, since some Unix machines can automount CD-ROMs and then autostart the specified application. If this application is a short shell script that runs killall xlock, the screensaver defense is easily pierced. In the worst case, if stealth of access is not a requirement, the machine can simply be rebooted and then attacked during the boot phase as described above.

One of the easiest local attacks is path abuse. However, it only works on systems run by deeply inexperienced or truly careless administrators. If the root environment has a “.” (current directory) in the path, root can be tricked into running the malicious executable file. The chances of this working are slim; not all modern Unix systems have “.” in the path before other commands. In addition, most best practices guides for Unix security suggest avoiding “.” in the path altogether.

In any case, if you can convince your local root to run something with root privileges (i.e., “Please help me, my little program does not have permission to get to such and such system library. Maybe you can run it as root so that it compiles and then I can just use the binary for my purposes.”), the system security is toast.

In this age of ubiquitous strong encryption, you might think that getting a hold of encrypted passwords wouldn’t help an attacker all that much. Nothing is further from the truth. Uneducated users commonly undermine the most sophisticated encryption schemes.

The computational complexity of classic password encryption algorithms, such as DES, and the power of modern computers allows for the brute forcing of the less effective passwords. Users choosing passwords such as “password”, “secret”, or their last names easily defeat higher security provided by MD5. Basic security best practices—such as not choosing a dictionary word for a password, or at least adding several nonalphabetic characters—are often neglected.

In almost all old Unix versions, encrypted passwords were stored in the file /etc/passwd. As we discussed earlier, they are not really encrypted passwords, but rather a blocks of data encrypted with the password used as a key (in the case of DES). A typical attack involves one of two methods. The attacker can get a dictionary, encrypt it, and then compare the result with the scrambled string obtained from /etc/passwd. Another approach is to try a random combination of ASCII characters likely to be seen in passwords, such as numbers or letters. More intelligent programs use a combination approach: take a dictionary word and then add a couple of random characters, such as numbers. This method will discover the passwords of those “smart” people who replaced “root” with “root1” and thought they were safe.

Even if you use several dictionaries, it takes much less time to crack a password using a dictionary set than using a random search. Many dictionaries are available online for most major languages and even for Klingon, which is useful for cracking Unix (since Unix and Star Trek are merely transformations of the same reality).

Obtaining passwords from password files became much more complicated when password shadowing became widespread. Password shadowing (described in Chapter 11) makes the files containing the encrypted passwords readable only by root. Thus, ordinary users cannot obtain passwords for cracking attempts. They can still try random combinations, though.

Here are some other methods for recovering user passwords (encrypted and unencrypted) on modern Unix systems. Passwords can be found in user files such as:

Finding encrypted passwords to crack may also be performed as follows. If an application refers to standard Unix password files for access control, the passwords can be recovered from an application crash dump. For example, users were able to crash the Solaris FTP daemon with a command (CWD ~) without being logged in (see the Bugtraq vulnerability database, bugtraq id 2601). This resulted in a core dump. If you were to investigate the resulting dump file, you would find the fragments of /etc/shadow (the Unix strings command is ideal for this).

Several methods may be used to defeat the attack. First, some applications (such as the Secure Shell daemon, sshd) disable core dumps completely, so that nothing may be recovered. Some Unix flavors apply restrictive permissions (only readable by root) to such files. System owners might also disable the generation of such files (system-wide or on a per-user basis), however helpful they might be for application debugging.

Crashing POP3/IMAP daemons, login programs, telnet, Secure Shell, and other networked programs has a good chance of resulting in a crash dump, with tasty bits of otherwise inaccessible /etc/shadow.

What are the chances of finding a valid Unix password in a system logfile? Imagine that the root user has made an error (say, by accidentally typing the password in the space for username). In this case, the password might end up in the logfile. The same mistake might cause passwords to appear in shell history files (such as .history for the bash shell).

Where else can passwords be found? If /etc/passwd is almost empty and the system is active, it might actually be using NIS (Network Information Services, formerly known as Yellow Pages by Sun Microsystems). If NIS is deployed, typing ypcat passwd produces a list of usernames together with encrypted passwords.

Set-user-ID abuses are a good way to elevate privileges on a Unix system. Many binaries are deployed SUID root, sometimes to get the needed system privileges and sometimes to cover mistakes in sloppy programming.

A nice example of SUID abuse is an efax vulnerability in which the program typically used to send and receive fax messages from a Unix machine is installed SUID root (in order to access the modem device /dev/modem, which is sometimes created with restricted permissions):

-rwsr-xr-x    1 root     root        96689 Aug 16 10:23 efax

Run the vulnerable version of the program (0.9a is shown as an example) as follows:

$efax -d /etc/shadow

The contents of the /etc/shadow file are revealed. The program simply produces an error message using the pieces of the misread file (in this case, /etc/shadow). The same program can also be used to obtain a root shell. The mitigation is simple: the program should not be SUID root; instead, the more relaxed permission on a modem device should be in place. Programming errors in SUID binaries produce the lion’s share of all such remote and local exploits.

Almost every Unix system has an area writable by all system users: /tmp. This area is used for storing temporary files from various applications. If people without a secure programming background write these applications, it is likely that some abuses will be possible. Let us examine the notorious /tmp symbolic link (symlink) abuse. If an attacker knows or can guess the filename of the temporary file created by the root application, she can create a symlink with the same name and point it to, say, /etc/shadow. When the root application starts up, the attacker might write some system information to the temporary file, effectively overwriting the Unix password file and creating a denial-of-service condition. No one can log in to the system if the password file is corrupted. More insidious attacks that overwrite the password file with custom content are also possible.

While other local attacks are covered extensively in other places, breaking out of chroot() on Unix has not received the attention it deserves. The chroot command and chroot system call might sound like a good security measure—you execute one command, and plain old Unix cd / no longer transports you to a root directory of the system. Instead, you are bound to the restricted part of the filesystem, surrounded only by files chosen by a paranoid system administrator. In fact, that is how it should be.

Is it possible to break out of chroot solitary confinement? Yes, if certain conditions are met. We’ll analyze what chroot is good for and also what it’s bad for.

First, how does chroot work? After you type /sbin/chroot directory_name on the Unix system command line, you can see that the new root is now “directory_name” (the /bin/ls / command produces the listing of files from “directory_name”, presuming you have an ls command located within your new root). The chroot shell command changes the root directory for a process, goes into this directory, and starts a shell or runs a user-specified command. If there is no shell binary within the new directory, and no user command is specified, the chroot command fails, as follows:

[root@anton anton]#chroot Test
chroot: cannot execute /bin/bash: No such file or directory

The chroot command uses a chroot( ) system call. The command and the system call have an important difference: unlike the shell command, the chroot( ) call does not change your working directory to the one inside a chrooted jail. The source of chroot.c (a shell command in the Linux part of the sh-utils package) shows the following sequence of system calls:

chroot (argv[1]);
chdir ("/");

As we will demonstrate, it allows for easy chroot jailbreaking.

chroot is often used as a security measure. If you have ever logged into an anonymous FTP server, you have used chroot. The FTP server chroots itself into a special directory upon the anonymous FTP login. The DNS daemon BIND is often chrooted as well. Some people also suggest chrooting telnet/SSH remote shell users into their corresponding home directories, so they can only update their own web pages. Web servers can be run chrooted as well. smap, the secure email wrapper from the FWTK firewall toolkit, runs chrooted to the mail spool directory. When chroot is implemented, programs running inside cannot access any system resources on the outside. Thus, all system libraries, configuration files, and even device files should be recreated within the chroot jail.

What daemons can be chrooted? If a daemon has to access files that are not easily collectible in one place, chrooting it will be difficult. For example, sendmail needs the mail spool (/var/spool/mail), other files in the spool (such as mqueue), user home directories (to check for .forward files) and system configuration files in /etc. There is no place on the filesystem where sendmail can effectively be confined. Of course, a makeshift solution is possible, but it’s not clear that such a thing adds to security. However, if sendmail functionality is separated into a spool daemon and mail transfer program (as done in FWTK’s smap and smapd), then chrooting is entirely possible.

chrooting shell users is possible if there is a business need to keep them in some particular directory. However, it involves copying multiple system libraries and files needed for the login and for the user-required functionality.

Many other network daemons—such as BIND (DNS), Apache (WWW), and Squid (web caching)—can be chrooted, but sometimes the benefits are unclear, especially for daemons that run as root. In this case, chroot only provides security by obscurity.

“What daemon should be chrooted?” is an entirely different question from “What daemons can be chrooted?” Before we cover this issue, let’s analyze how attackers break out of chroot.

First, the larger the number of software applications that are deployed within the chroot environment, the more dangerous things become, since it is difficult to keep track of all of the programs that the attacker can use to elevate permission and escape.

Second, there are a vast number of ways that a root user can break out of chroot. These methods range from the simple use of a chroot() call with no chdir( ) (see Example 12-1) to esoteric methods such as the creation of your own /dev/had (for hard drive) or /dev/kmem (for memory) devices, injection of code into the running kernel, using open directory handles outside chroot, or using chroot-breaking buffer overflow shell codes. While adjusting system capabilities or other tricks can be used to render many of these methods inoperable, new ones will likely be found by smart attackers, since root is simply too powerful on the Unix system.

#include <stdlib.h>
#include <stdio.h>
#include <unistd.h>
#include <sys/stat.h>
#include <sys/types.h>

int main(void)
{
    int i;
    mkdir("breakout", 0700);
    chroot("breakout");

    for (i = 0; i < 255; i++)
      chdir("..") ;

    chroot(".");
    execl("/bin/sh", "/bin/sh",NULL);
}

If there is no root user defined within the chroot environment, there are no SUID binaries or devices, and the daemon itself has dropped root privileges right after calling chroot( ) (like in the code below), breaking out of chroot becomes very difficult, if not impossible. Most secure coding practices emphasize dropping all unneeded privileges, but unfortunately (for the defender) or fortunately (for the attacker) most programmers do not heed such advice.

In other words, if there is no way to gain a root shell or to perform root-level actions (i.e., create devices or access raw memory), breaking chroot will be difficult. Ideally, if the custom software uses chroot for security, the sequence of calls should be as follows:

chdir("/home/safedir");
chroot("/home/safedir");
setuid(500);

In some cases, attackers might not be able to break out (i.e., run processes outside of the chrooted directory), but instead will be able to have a partial affect on such processes. For example, if BIND is chrooted, several devices should be created. One of them is /dev/log, which is necessary for logging BIND messages into the regular system logs. By crafting a malicious log message and sending it into /dev/log from within the chrooted directory, the attacker influences the behavior of the syslog daemon running outside of the chroot jail. If there is a buffer overflow in syslog (which runs as root), the attacker can obtain additional privileges.

What daemons can be chrooted, yet provide no security benefit? chrooting programs that do not drop root privileges while running or programs that provide root shell access (i.e., sshd or telnet with a root account within a chrooted directory) does not provide extra security.

For the defensive side, chroot is a good way to increase the security of software, provided secure programming guidelines are followed and chroot( ) system call limitations are taken into account. Chrooting prevents an attacker from reading files outside the chroot jail and prevents many local Unix attacks (such as SUID abuse and /tmp race conditions). However, improperly implemented chroots (such as when privileges were dropped too late, so that the attack will still yield “root”) will help the attacker to gain access to the target machine.

This section covers attacks against popular Unix TCP services. This is not an exhaustive treatise on Unix network attacks, as they are too numerous to be covered here. Also, the attack landscape changes with blinding speed.

The section covers attacks against some of the Unix UDP services. Although it is not exhaustive, this list emphasizes some classic and recent attacks.

The above lists describe some commonly attacked Unix ports. They are not exhaustive, though, and many other ports are being used by custom applications that are just as vulnerable.

How close to real life are the examples in the lists? What ports are being exploited (even as you read this) on the systems deployed on the Internet?

Let’s analyze some publicly reported data from SANS (SysAdmin, Audit, Network, Security) Institute (http://www.sans.org) from the last several years. SANS is a nonprofit security research and education organization that conducts conferences and training classes, administers popular security certifications (such as GCIA and GCIH), and also organizes members of the security community to work on various projects of value to everybody.

SANS now compiles a list of “The Twenty Most Critical Internet Security Vulnerabilities,” published once a year. SANS collects the most dangerous and commonly attacked vulnerabilities from a worldwide group of contributors (one of the authors of this book included) and then lets them vote on what are the 20 most critical. Nowadays, the list is split into two parts, for Unix and Windows. We will be focusing on a Unix list here. Here is how the recent “Top 20” lists looked.

The top vulnerabilities in Unix Systems in 2003 included:

And the top vulnerabilities to Unix Systems in 2002 included:

In 2001, the list was called “Top 10” and combined Unix and Windows. Here are the Unix entries (we have cut out the WIndows entry, leaving only those that are Unix- related):

Now, at this point, the reader might ask what this has to do with our discussion on Unix attacks categorized by port. The following table demonstrates the relation. Table 12-1 summarizes the entries from the SANS top attack lists by port to show the commonly attacked Unix ports. It will be obvious that some of the ports are true attackers’ favorites, while others become important or fade away as a target.

Table 12-1 shows the recently attacked Unix ports. Indeed, as indicated by the Unix honeynet research conducted by one of the authors, the observed attack activity closely matches the above table. For example, FTP attacks were subsiding in 2003, while RPC is as popular as ever (due to recent vulnerabilities in Linux systems).

To conclude, it is important to be aware of attacks on various ports on Unix systems—and some ports are more important for both attackers (better availability of attack tools) and defenders (more bang for the buck for the protection measures).

This section covers local DoS attacks requiring the attacker’s presence at the system console or a working remote shell connection (via telnet, ssh, rlogin, etc.).

:(  ){ :|:&};:
    int main(  )
{
while(1)
{
fork(  );
}
}
while : ;
mkdir .xxx
cd .xxx
done

The field of network DoS is extremely rich and varied, ranging from the now common SYN floods to sophisticated distributed denial-of-service attacks. Since examples of classic network DoS attacks are covered extensively elsewhere in the security literature, we concentrate on the mechanics of the attacks themselves.

Network attacks can be loosely categorized as application crashing or resource consumption . However, in the case of network attacks, the attacker can consume both host and network resources. SYN flooding is an example of the former, while UDP or ICMP flooding is an example of the latter.

Consuming network resources simply involves flooding the network pipe; i.e., sending the victim so much extra traffic that normal traffic cannot get through. Any kind of IP packet can be used to fill the pipe. In addition, the source addresses of the packets are often spoofed. Sometimes third parties also add to the flood—below, we consider reflexive DoS attacks in which the attacker sends traffic to some systems that in turn flood the victim (usually without violating any TCP/IP standards). The smurf or ICMP broadcast attack is the simplest example of a reflexive DoS attack.

Consuming host resources sometimes requires more ingenuity than just sending enough traffic. A SYN flood sent over a relatively slow line can bring the victim system to a crawl. Host resources can rapidly be consumed if the system has to perform an expensive operation for each connection or even for each arriving packet, i.e., an operation that requires a lot of CPU, memory, or some kernel data structure resources). SYN flooding, for instance, requires the system to keep a table entry for each arrived SYN packet, since it potentially indicates the beginning of a new connection. Unix OS vendors currently use various tricks to mitigate the effects of SYN floods, such as Linux’s SYN-cookies.

Reassembling packet fragments is another operation that puts a heavy load on the victim computer. If IP datagrams are sent in fragmented form, the system has to reassemble them before passing them on to higher levels in the stack (such as to the TCP or UDP layer). Another group of resource consumption attacks works due to a particular quirk in certain TCP/IP stack implementations. Some systems, especially those with substandard networking, have been known to crash or overload upon receiving abnormal network packets.

The majority of DoS attacks are in the category of remote OS or application crashing. Application-level network DoS attacks could involve mail bombing or web flooding. The former consists simply of sending many large email messages to the target email address, thus overloading email servers, storage, and network pipes. Web flooding is a relative newcomer to the DoS party. Recently, the World Economic Forum web site was brought down by hacktivists who simultaneously reloaded web pages using their browsers, running one version of a malicious applet. On the other side of the DoS spectrum, remotely sending spoofed syslog messages can cause a disk overflow and (for a badly configured systems) a subsequent crash.

In the rest of this section, we’ll briefly outline some of the popular network DoS attacks seen on the Internet.

Smurfing saturates the network connection of a victim by recruiting the help of multiple machines willing to respond to a broadcast. To successfully smurf, one has to find a network willing to amplify the attack through misconfiguration. However, similar attacks are possible via any network system that can send a response larger than a request (i.e., can work as an amplifier). Acting as an amplifier involves trusting the IP address of the sending party to send a request back—i.e., to be vulnerable to IP spoofing.

Even DNS queries are reported to cause denial-of-service conditions if the requests are spoofed with a victim’s address. The intermediate DNS server happily responds to the victim, thereby flooding it. If many DNS servers are queried, the result is a reflexive DoS attack, a relatively new breed that is extremely difficult to defend against. More information on those and other attacks are provided in the next section.

The land attack, which is only of historic interest, consists of sending a packet with an identical source and destination. It used to crash many TCP/IP stacks, especially in early Windows versions.

IP fragmentation abuse is represented by the teardrop attack. Fragments with a corrupted offset sent by the attacker are used to crash Linux and Windows machines. A variety of DoS attacks with names such as bonk, boink, and newtear also use improper fragmentation handling.

The ping of death is the granddaddy of many network DoS attacks. The ping of death is simply an oversized ping packet (65,536 bytes instead of the normal 28 bytes) that used to crash very old Unix TCP stack implementations. A buffer overflow in the stack source code was to blame for this once lethal attack.

Many other DoS tools exist, from plain TCP flooders to more exotic ones such as puke (which sends ICMP unreachable packets, thus attempting to reset connections of the target host) and jolt (which kills windows machines by sending deformed and fragmented packets). Even peaceful Internet Gateway Message Protocol (IGMP) packets have been recruited for network warfare; tools exist to send oversized IGMP packets that can crash Windows.

The ultimate creations of the point-to-point (i.e., nondistributed) DoS are the multiDoS kits such as spike, 7plagues, targa, or datapool. A kit combines various DoS attacks that can be launched against multiple addresses in random order. The datapool tool (with 106 attacks packaged together) actually remembers which attacks worked against a host and next time only runs those, saving some bandwidth for the attacker.

Network DoS attacks are by no means a thing of the past; there are still enough vulnerable machines deployed on the Internet for the attackers to have their share of “fun,” and new exploits arise every day.

The road to fame for distributed denial-of-service (DDoS) attacks started in 1999, when the first rumors of massive “attack zombie” deployments appeared. However, it was not until February 2000 that DDoS became a household word. On February 6 and 7 of 2000, floods of packets from multiple sources hit many popular sites such as Yahoo!, eBay, Amazon, and CNN. The floods overloaded the sites and they either became unavailable or slowed to a crawl.

Dave Dittrich from Washington University has analyzed most of the DDoS tools that have surfaced so far. Here we present a short overview of DDoS toolkits seen in the “wide wild web.”

Trinoo is an early DDoS kit that consists of a set of zombies that are deployed on multiple machines, usually hacked via some exploit. A master program controlled by an attacker commands the zombies. The master sends commands to the zombies in order to start flooding the victim with (in the case of Trinoo) UDP packets. Trinoo did not used source spoofing; thus, the zombies are easy to find.

TFN (Tribal Flood Network) is a similar tool that can flood in UDP and TCP SYN (causing a SYN flood, which is more damaging to the victim than a UDP flood) or ICMP echo flood (also dangerous). Its ICMPs can also send to broadcast addresses, thus enhancing the attack with smurf amplification. The kit does have some bugs that limit its control functionality. However, the tools use spoofed source addresses. Thus, the zombies are relatively safe, since the UDP packets seem to originate elsewhere.

TFN2K (a newer version of TFN) sends all the above attacks at once, with spoofed sources. In this toolkit, the authors first implemented an encrypted control channel that uses TCP, UDP, or ICMP to give commands to the zombies. While the commands were found to have a unique signature that simplified detection, the encrypted communication is more stable than the plain-text one.

Stacheldraht (German for barbed wire) is another tool with features similar to TFN2K. Newer versions have added several more attacks, such as TCP ACK flood (only the ACK bit is set, so it might pass through a badly configured firewall), TCP NUL flag (no flags set), and improved ICMP flooding with smurf support. Also, the author has worked on quality control and the software has fewer bugs than its predecessors. It also uses spoofed packets in all protocols. However, by the time the tool appeared, the techniques to trace spoofed floods had been perfected and the zombies could be found quickly. Such tracing usually involves hop-by-hop tracing from ISP to higher-level ISP, until the source is found.

Several other tools have been found as well. Shaft , for example, can send a mix of UDP, TCP SYN, and ICMP floods. Mstream is designed to send an ACK flood with spoofed addresses. The reason that ACK floods are more effective than, say, UDP floods is that they elicit multiple responses, thus increasing bandwidth consumption and stress on the host resources.