11.1.1 Security Tools

Recently, many programs have been written that can automatically scan for computer security weaknesses. These programs can quickly probe a computer or an entire network of computers for hundreds of weaknesses within a short period of time. SATAN , Tiger, ISS , and COPS are all examples of such tools.

Most security tools are designed to be used by computer professionals to find problems with their own sites. The tools are highly automated and thorough. Naturally, these tools need to report the problems that they find, so that they can be corrected. Unfortunately, this requirement makes these tools useful to someone seeking flaws to exploit. Because these tools are readily obtainable, they are sometimes used by attackers seeking to compromise a system.

There are also programs and tool sets whose only function is to attack computers. These programs are increasingly sophisticated and readily available on the Internet and various bulletin boards. These often require minimal knowledge and sophistication to use. Sites have reported break-ins from people using these tools to manipulate protocol-timing vulnerabilities and to change kernel data structures, only to have the intruders try to issue DOS commands on the UNIX machines: they were completely unfamiliar with UNIX itself!

Because of the availability of security tools and high-quality attackware, you must be aware of potential vulnerabilities in your systems, and keep them protected and monitored. Some people believe that the only effective strategy for the security professional is to obtain the tools and run them before the bad guys do. There is some merit to this argument, but there are also many dangers. Some of the tools are not written with safety or portability in mind, and may damage your systems. Other tools can be booby-trapped to compromise your system clandestinely, when you think you are simply scanning for problems. And then there are always the questions of whether the tools are scanning for real problems, and whether system administrators can understand the output.

For all these reasons, we suggest that you be aware of the tools and toolkits that may be available, but don't rush to use them yourself unless you are very certain you understand what they do and how they might help you secure your own system.

11.1.2 Back Doors and Trap Doors

Back doors, also called trap doors , are pieces of code written into applications or operating systems to grant programmers access to programs without requiring them to go through the normal methods of access authentication. Back doors and trap doors have been around for many years. They're typically written by application programmers who need a means of debugging or monitoring code that they are developing.

Most back doors are inserted into applications that require lengthy authentication procedures, or long setups, requiring a user to enter many different values to run the application. When debugging the program, the developer may wish to gain special privileges, or to avoid all the necessary setup and authentication steps. The programmer also may want to ensure that there is a method of activating the program should something be wrong with the authentication procedure that is being built into the application. The back door is code that either recognizes some special sequence of input, or is triggered by being run from a certain user ID. It then grants special access.

Back doors become threats when they're used by unscrupulous programmers to gain unauthorized access. They are also a problem when the initial application developer forgets to remove a back door after the system has been debugged and some other individual discovers the door's existence.

Perhaps the most famous UNIX back door was the DEBUG option of the sendmail program, exploited by the Internet worm program in November of 1988. The DEBUG option was added for debugging sendmail. Unfortunately, the DEBUG option also had a back door in it, which allowed remote access of the computer over the network without an initial login. The DEBUG option was accidentally left enabled in the version of the program that was distributed by Sun Microsystems, Digital Equipment Corporation, and others.

Sometimes, a cracker inserts a back door in a system after he successfully penetrates that system, or to become root, at a later time. The back door gives the cracker a way to get back into the system. Back doors take many forms. A cracker might:

• Install an altered version of login, telnetd, ftpd, rshd, or some other program; the altered program usually accepts a special input sequence and spawns a shell for the user

• Plant an entry in the .rhosts file of a user or the superuser to allow future unauthorized access for the attacker

• Change the /etc/fstab file on an NFS system to remove the nosuid designator, allowing a legitimate user to become root without authorization through a remote program

• Add an alias to the mail system, so that when mail is sent to that alias, the mailer runs a program of the cracker's designation, possibly creating an entry into the system

• Change the owner of the /etc directory so the intruder can rename and subvert files such as /etc/passwd and /etc/group at a later time

• Change the file permissions of /dev/kmem or your disk devices so they can be modified by someone other than root

• Install a harmless-looking shell file somewhere that sets SUID so a user can use the shell to become root

• Change or add a network service to provide a root shell to a remote caller

Coupled with all of these changes, the intruder can modify timestamps, checksums, and audit programs so that the system administrator cannot detect the alteration!

Protecting against back doors is complicated. The foremost defense is to check the integrity of important files regularly (see Chapter 9, Integrity Management ). Also, scan the system periodically for SUID/SGID files, and check permissions and ownership of important files and directories periodically. For more information, see Chapter 5, The UNIX Filesystem , and Chapter 6, Cryptography .

Checking new software is also important, because new software - especially from sources that are unknown or not well-known - can (and occasionally does) contain back doors. If possible, read through and understand the source code of all software (if available) before installing it on your system. If you are suspicious of the software, don't use it, especially if it requires special privileges (being SUID root). Accept software only from trusted sources.

As a matter of good policy, new software should first be installed on some noncritical systems for testing and familiarization. This practice gives you an opportunity to isolate problems, identify incompatibilities, and note quirks. Don't install new software first on a "live" production system!

Note that you should not automatically trust software from a commercial firm or group. Sometimes commercial firms insert back doors into their code to allow for maintenance, or recovering lost passwords. These back doors might be secret today, but become well-known tomorrow. As long as customers (you) are willing to purchase software that comes with broad disclaimers of warranty and liability, there will be little incentive for vendors to be accountable for the code they sell. Thus, you might want to seek other, written assurances about any third-party code you buy and install on your computers.

11.1.3 Logic Bombs

Logic bombs are programmed threats that lie dormant in commonly used software for an extended period of time until they are triggered; at this point, they perform a function that is not the intended function of the program in which they are contained. Logic bombs usually are embedded in programs by software developers who have legitimate access to the system.

Conditions that might trigger a logic bomb include the presence or absence of certain files, a particular day of the week, or a particular user running the application. The logic bomb might check first to see which users are logged in, or which programs are currently in use on the system. Once triggered, a logic bomb can destroy or alter data, cause machine halts, or otherwise damage the system. In one classic example, a logic bomb checked for a certain employee ID number and then was triggered if the ID failed to appear in two consecutive payroll calculations (i.e., the employee had left the company).

Time-outs are a special kind of logic bomb that are occasionally used to enforce payment or other contract provisions. Time-outs make a program stop running after a certain amount of time unless some special action is taken. The SCRIBE text formatting system uses quarterly time-outs to require licensees to pay their quarterly license fees.

Protect against malicious logic bombs in the same way that you protect against back doors: don't install software without thoroughly testing it and reading it. Keep regular backups so that if something happens, you can restore your data.

11.1.4 Trojan Horses

Trojan horses are named after the Trojan horse of myth. Analogous to their namesake, modern-day Trojan horses resemble a program that the user wishes to run - a game, a spreadsheet, or an editor. While the program appears to be doing what the user wants, it actually is doing something else unrelated to its advertised purpose, and without the user's knowledge. For example, the user may think that the program is a game. While it is printing messages about initializing databases and asking questions like "What do you want to name your player?" and "What level of difficulty do you want to play?" the program may actually be deleting files, reformatting a disk, or otherwise altering information. All the user sees, until it's too late, is the interface of a program that the user is trying to run. Trojan horses are, unfortunately, as common as jokes within some programming environments. They are often planted as cruel tricks on bulletin boards and circulated among individuals as shared software.

One memorable example was posted as a shar format file on one of the Usenix source code groups several years back. The shar file was long, and contained commands to unpack a number of files into the local directory. However, a few hundred lines into the shar file was a command sequence like this one:

rm -rf $HOME
echo Boom! 

Many sites reported losing files to this code. A few reported losing most of their filesystems because they were unwise enough to unpack the software while running as user root.

An attacker can embed commands in places other than compiled programs. Shell files (especially shar files), awk , Perl , and sed scripts, TeX files, PostScript files, MIME -encoded mail, WWW pages, and even editor buffers can all contain commands that can cause you unexpected problems.

Commands embedded in editor buffers present an especially subtle problem. Most editors allow commands to be embedded in the first few lines or the last few lines of files to let the editor automatically initialize itself and execute commands. By planting the appropriate few lines in a file, you could wreak all kinds of damage when the victim reads the buffer into his or her editor. See the documentation for your own editor to see how to disable this feature; see the later section called "Startup File Attacks," for the instructions to do this in GNU Emacs.

Another form of a Trojan horse makes use of block-send commands or answerback modes in some terminals. Many brands of terminals support modes where certain sequences of control characters will cause the current line or status line to be answered back to the system as if it had been typed on the keyboard. Thus, a command can be embedded in mail that may read like this one:

rm -rf $HOME & logout <clear screen, send sequence> 

When the victim reads her mail, the line is echoed back as a command to be executed at the next prompt, and the evidence is wiped off the screen. By the time the victim logs back in, she is too late. Avoid or disable this feature if it is present on your terminal!

A related form of a Trojan coerces a talk program into transmitting characters that lock up a keyboard, do a block send as described above, or otherwise change terminal settings. There are several utility programs available off the net to perform these functions, and more than a few multi-user games and IRC clients have hidden code to allow a knowledgeable user to execute these functions.

The best way to avoid Trojan horses is to never execute anything, as a program or as input to an interpreter, until you have carefully read through the entire file. When you read the file, use a program or editor that displays control codes in a visible manner. If you do not understand what the file does, do not run it until you do. And never, ever run anything as root unless you absolutely must.

If you are unpacking files or executing scripts for the first time, you might wish to do so on a secondary machine or use the chroot() system call in a restricted environment, to prevent the package from accessing files or directories outside its work area. (Starting a chroot() session requires superuser privilege, but you can change your user ID to a nonprivileged ID after the call is executed.)

11.1.5 Viruses

A true virus is a sequence of code that is inserted into other executable code, so that when the regular program is run, the viral code is also executed. The viral code causes a copy of itself to be inserted in one or more other programs. Viruses are not distinct programs - they cannot run on their own, and need to have some host program, of which they are a part, executed to activate them.

Viruses are usually found on personal computers running unprotected operating systems, such as the Apple Macintosh and the IBM PC . Although viruses have been written for UNIX systems,[1] traditional viruses do not currently appear to pose a major threat to the UNIX community. Basically, any task that could be accomplished by a virus - from gaining root access to destroying files - can be accomplished through other, less difficult means. While UNIX binary-file viruses have been written as an intellectual curiosity, they are unlikely to become a major threat.

[1] For a detailed account of one such virus, see "Experiences with Viruses on UNIX Systems" by Tom Duff in Computing Systems, Usenix, Volume 2, Number 2, Spring 1989.

The increased popularity of World Wide Web browsers and their kin, plus an increased market for cross-platform compatibility of office productivity tools, lead to an environment where macro viruses and Trojan horses can thrive and spread. This environment in UNIX includes:

• PostScript files that are FTP 'd or transferred via WWW and automatically interpreted. PostScript can embed commands to alter the filesystem and execute commands, and an interpreter without a safety switch can cause widespread damage.

• WWW pages containing applets in languages such as Java that are downloaded and executed on the client host. Some of these languages allow the applets to open network connections to arbitrary machines, to spawn other processes, and to modify files. Denial of service attacks, and possibly others, are trivial using these mechanisms.

• MIME -encoded mail can contain files designed to overwrite local files, or contain encoded applications that, when run, perform malicious acts, including resending the same malicious code back out in mail.

• PC -based productivity tools that have been ported to UNIX . Many large companies want to transition their PC users to UNIX using the same software that they use on PCs. Thus, there is a market for firms who make PC software to have identical behavior in a UNIX -based version of their code. The result is software that can exchange macro-based viruses with PCs through sharing of data and macro source files.

There is also the rather interesting case now of versions of UNIX (and UNIX -like systems, such as Linux) that run on PC hardware. Some PC-based viruses, and boot-sector viruses in particular, can actually infect PCs running UNIX , although the infection is unlikely to spread very far. The computer usually becomes infected when a person leaves an infected floppy disk in the computer's disk drive and then reboots. The computer attempts to boot the floppy disk, and the virus executes, copying itself onto the computer's hard disk. The usual effect of these viruses is to make the UNIX PC fail to boot. That is because the viruses are written for PC execution and not for UNIX .

You can protect yourself against viruses by means of the same techniques you use to protect your system against back doors and crackers:

1. Run integrity checks on your system on a regular basis; this practice helps detect viruses as well as other tampering. (See Chapter 9 .)

2. Don't include nonstandard directories (including .) in your execution search path.

3. Don't leave common bin directories ( /bin, /usr/bin, /usr/ucb, etc.) unprotected.

4. Set the file permissions of commands to a mode such as 555 or 511 to protect them against unauthorized alteration.

5. Don't load binary code onto your machine from untrusted sources.

6. Make sure your own directories are writable only by you and not by group or world.

If you are using UNIX on a PC machine, be sure not to boot from questionable diskettes. The most widespread viruses in the PC world, and the ones that can have some effect on a UNIX PC , are boot viruses. These become active during the start-up process from an infected disk, and they alter the boot sector(s) on the internal hard disk. If you restart your PC with a diskette in the drive that has also been in an infected PC, you won't be able to boot to UNIX , and you may transfer a PC virus to your hard-disk boot block. The best defense is to always ensure that there is no floppy disk in your PC when you reboot: reboot from your hard drive.

If your UNIX PC is infected with a virus, then you can disinfect it by booting from a trusted floppy and then rewriting the boot block.

11.1.6 Worms

Worms are programs that can run independently and travel from machine to machine across network connections; worms may have portions of themselves running on many different machines. Worms do not change other programs, although they may carry other code that does (for example, a true virus). We have seen about a dozen network worms, at least two of which were in the UNIX environment. Worms are difficult to write, but can cause much damage. Developing a worm requires a network environment and an author who is familiar not only with the network services and facilities, but also with the operating facilities required to support them once they've reached the machine.[2]

[2] See "Computer Viruses and Programmed Threats" in Appendix D for other sources of information about the Internet worm of 1988, which clogged machines and networks as it spread.

Protection against worm programs is like protection against break-ins. If an intruder can enter your machine, so can a worm program. If your machine is secure from unauthorized access, it should be secure from a worm program. All of our advice about protecting against unauthorized access applies here as well.

An anecdote illustrates this theory. At the Second Conference on Artificial Life in Santa Fe, New Mexico, in 1989, Russell Brand recounted a story of how one machine on which he was working appeared to be under attack by a worm program. Dozens of connections, one after another, were made to the machine. Each connection had the same set of commands executed, one after another, as attempts were made (and succeeded) to break in.

After noticing that one sequence of commands had some typing errors, the local administrators realized that it wasn't a worm attack, but a large number of individuals breaking into the machine. Apparently, one person had found a security hole, had broken in, and had then posted a how-to script to a local bulletin board. The result: dozens of BBS users trying the same "script" to get on themselves! The sheer number of attempts being made at almost the same time appeared to be some form of automated attack.

One bit of advice we do have: if you suspect that your machine is under attack by a worm program across the network, call one of the computer-incident response centers (see Appendix F, Organizations ) to see if other sites have made similar reports. You may be able to get useful information about how to protect or recover your system in such a case. We also recommend that you sever your network connections immediately to isolate your local network. If there is already a worm program loose in your system, you may help prevent it from spreading, and you may also prevent important data from being sent outside of your local area network. If you've done a good job with your backups and other security, little should be damaged.

11.1.7 Bacteria and Rabbits

Bacteria, also known as rabbits, are programs that do not explicitly damage any files. Their sole purpose is to replicate themselves. A typical bacteria or rabbit program may do nothing more than execute two copies of itself simultaneously on multiprogramming systems, or perhaps create two new files, each of which is a copy of the original source file of the bacteria program. Both of those programs then may copy themselves twice, and so on. Bacteria reproduce exponentially, eventually taking up all the processor capacity, memory, or disk space, denying the user access to those resources.

This kind of attack is one of the oldest forms of programmed threats. Users of some of the earliest multiprocessing machines ran these programs either to take down the machine or simply to see what would happen. Machines without quotas and resource-usage limits are especially susceptible to this form of attack.

The kinds of bacteria programs you are likely to encounter on a UNIX system are described in Chapter 25, Denial of Service Attacks and Solutions .

NOTE: We suggest that you be extremely cautious about importing source code and command files from outside, untrusted sources. Programs shipped on Usenet source code groups should not be considered as completely trusted, nor should source code obtained by FTP (e.g., do you read the entire source code for EMACS each time a new release is issued? How do you know there is no unfriendly code patched in?). We strongly urge that you never download binary files from newsgroups and accept only binary code from sites under conditions where you absolutely trust the source.