11.7 References

12.1 Local Attacks

In this section, we discuss what an attacker can do if he already has some level of access to your Unix machine. This might happen on a machine with legitimate public shell access (a rare happening nowadays, unless you are at a university) or if an attacker gains the ability to run commands via some network service such as web, email, or FTP servers. It might happen through a bug, a misconfigured server, or a bad design decision on the part of the server programmers (such as a poorly designed web application or CGI script). This section presumes that the attacker already has a foothold on your system and is able to run commands more or less freely .

As we know from Chapter 11, a well- hardened Unix system should effectively resist attackers . Similarly, the system should be configured so that it is even more difficult to gain root privileges if the attacker somehow manages to penetrate the network's defenses and obtain nonprivileged access.

12.1.1 Physical Abuses

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.

12.1.2 Boot Prompt Attacks

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.

12.1.3 Boot Interrupt

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.

12.1.4 Screensaver Attacks

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.

12.1.5 Path Abuse

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 .

12.1.6 Password Attacks

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:

~/. netrc

This is used for " passwordless " logins via FTP and telnet. The file format is shown below:

machine ftpserv.example.edu login anton password r7w7/R12

You can clearly see the login and password for the machine ftpserv.example.edu .

~/.fetchmailrc

This is used for the mail transfer program fetchmail, which downloads email via POP3/IMAP from a mail server. Here's the file format:

set nobouncemail

set daemon 100

defaults

            user anton is anton

poll mailserv.example.edu with protocol pop3 and port 110:

password r7w7/R12;

Just as with .netrc , the passwords are exposed.

Older versions of the popauth program (called APOP)

This is used to store passwords for secure POP3 in clear text. The program needs a clear-text password to generate the challenge response protocol and is not able to use an encrypted password from standard Unix /etc/passwd files.

Some proprietary software products

Products such as databases can also expose passwords. The attacker just needs to look for them in the user's home directory (providing he has read access to those files, which is not always the case).

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.

12.1.7 SUID Abuse

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.

12.1.8 /tmp and Symlink /Hardlink Abuse

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.

12.1.9 Breaking Out of chroot Jail

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.

Example 12-1. Sample code for breaking out of chroot

#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);

}

Compile Example 12-1 statically (using gcc -static ) and run it within the chrooted directory (after entering chroot or similar from the shell prompt) to escape.

chdir("/home/safedir");

chroot("/home/safedir");

setuid(500);