23.1 Programmed Threats: Definitions

Computers are designed to execute instructions one after another. These instructions usually do something useful—calculate values, maintain databases, and communicate with users and with other systems. Sometimes, however, the instructions executed can be damaging or malicious in nature. When the damage happens by accident, we call the code involved a software bug. Bugs are perhaps the most common cause of unexpected program behavior.

But if the source of the damaging instructions is an individual who intended that the abnormal behavior occur, we call the instructions malicious code, or a programmed threat. Some people use the term malware to describe malicious software.

There are many different kinds of programmed threats. Experts classify threats by the way they behave, how they are triggered, and how they spread. In recent years, occurrences of these programmed threats have been described almost uniformly by the media as computer viruses and (in the more technical media) worms. However, viruses and worms make up only a small fraction of the malicious code that has been devised. Saying that all programmed data loss is caused by viruses is as inaccurate as saying that all human diseases are caused by viruses.

Experts who work in this area have formal definitions of all of these types of software. However, not all the experts agree on common definitions. Thus, we'll consider the following practical definitions of malicious software:

Security tools and toolkits

Usually designed to be used by security professionals to protect their sites, these can also be used by unauthorized individuals to probe for weaknesses. rootkits are a special case: these are prepackaged attack toolkits that also install back doors into your system once they have penetrated superuser account security.

Back doors

Sometimes called trap doors, these allow unauthorized access to your system.

Logic bombs

Hidden features in programs that go off after certain conditions are met.

Trojan horses

Programs that appear to have one function but actually perform another function (like the Greek horse that was given to the city of Troy near the end of the Trojan War—a horse that appeared to be an idol, but was actually a troop carrier).

Viruses

Programs that modify other programs on a computer, inserting copies of themselves.

Worms

Programs that propagate from computer to computer on a network, without necessarily modifying other programs on the target machines.

Bacteria or rabbit programs

Programs that make copies of themselves to overwhelm a computer system's resources.

Some of the threats mentioned above also have nondestructive uses. For example, worms can be used to do distributed computation on idle processors, back doors are useful for debugging programs, and viruses can be written to update source code and patch bugs. The purpose, not the approach, makes a programmed threat threatening.

This chapter provides a general description of each threat, explains how it can affect your Unix system, and describes how you can protect yourself against it. For more detailed information, refer to the books mentioned in Appendix C.

We suggest that you be extremely cautious about importing source code and command files from outside sources. High-security sites should avoid software that is not cryptographically signed by a trusted author. We strongly urge you to never download binary files. If you intend to rely on software that is "open source," you should obtain the software in source code form, inspect it, test it, and compile it yourself. This is the only way to be reasonably sure of the behavior of the software that you are using.

23.1.1 Security Scanners and Other Tools

Many programs have been written that can automatically scan for computer security weaknesses. Some of these programs quickly probe the computer on which they are running for system vulnerabilities, while others scan over a network for vulnerabilities that can be exploited remotely. These programs are sometimes called security scanners or, more generally, security tools.

Scanners and other tools are double-edged programs. On the one hand, they can be used by professionals for the purpose of securing computer systems: if you can rapidly scan a system for known vulnerabilities, you can use that list of vulnerabilities as a checklist that tells you what to fix. On the other hand, these tools can be used by perpetrators intent on penetrating computer systems; security scanners give these individuals and organizations a roadmap of how to break into systems.

Some security tools are sold commercially for professional use. Other tools are made freely available over the Internet and are designed for professional use, although they can obviously be used by attackers as well. Still more tools are distributed over the Internet exclusively for malicious use. Ironically, the code quality of some malicious tools is very high—so high that these tools have been taken up by security professionals. The nmap network-mapping tool is an example of a tool that was developed by the computer underground and is now widely used by professionals.

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 may be booby-trapped to compromise your system clandestinely, when you think you are simply scanning remote systems 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 do not rush to use them yourself unless you are very certain that you understand what they do and how they might help you secure your own system.

23.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 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 go 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.

More recently, in July 2002, a back door was inserted into the OpenSSH system distributed by the OpenBSD group. This back door was not in the OpenSSH program itself, but in the program's build environment. When OpenSSH was first built, a back door was installed on the computer used to build the binary. This was a remarkably effective attack because most people who build Unix programs do their compilations as the superuser, rather than as an untrusted normal user. Apparently, this attack was inserted without the knowledge of the OpenBSD group itself; when the attack was detected, an announcement was made, and the subverted code was removed.

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

• Install an altered version of login, telnetd, ftpd, rshd, inetd, 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, .shosts, or .ssh/authorized_keys file of a user or the superuser to allow future unauthorized access.

• 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 attacker's designation, possibly creating an entry into the system.

• Change the owner of the /etc directory so the attacker 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.

• Change a shared library or loadable module to add a system call option to allow a change to superuser status when using a seemingly innocuous program.

• 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 user.

• Add a back door to the sshd binary so that a specific username and password is always accepted for login, whether or not the username exists in the accounts database. Alternatively, the sshd binary might log all accepted usernames and passwords to a third-party machine.

Coupled with all of these changes, the attacker 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 routinely check the integrity of important files (see Chapter 20). In addition to checking your files, you should routinely scan the system for SUID/SGID files, scan your system for open TCP/IP ports, and periodically check permissions and ownership of important files and directories. Unfortunately, it is now possible to hide the existence, the function, and the triggers of hostile software with great subtlety. As a result, if you allow your system to become compromised, you may not be able to detect that changes have taken place.

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 a new package on your system. If you are suspicious of the software, don't use it, especially if it requires special privileges (such as 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.

Free software is no safer. Most freeware (and open source) project software is written and maintained by multiple programmers. Contributions are often accepted without careful screening by other members of the group. Thus, a small addition can be made without being observed by others. Furthermore, even if the code is scanned, subtle dependencies and back doors may not be recognized—few people know how to carefully review software, and if they are not particularly interested in understanding every nuance, they may easily miss something nasty. Even an "independent" review may not be sufficient: besides lack of training, people can make mistakes, and sometimes there will even be collusion between the reviewer and the coder!

23.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 which 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).

Timeouts are a special kind of logic bomb that are occasionally used to enforce payment or other contract provisions. They stop a program after a certain amount of time unless some special action is taken, such as paying a license fee. Timeouts are regularly included in beta test software so that users upgrade to newer builds or to the formal release.

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.

23.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—e.g., login, 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 such as "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 posting confidential documents to a web site in Argentina. 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, sometimes used as jokes within some environments. They are often planted as cruel tricks on hacker web sites and circulated among individuals as shared software.

23.1.4.1 Trojan horses in mobile code

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; web pages; and even text files can all contain commands that can cause you unexpected problems.

Commands embedded in text files for editors 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 editor. See the documentation for your own editor to see how to disable this feature; see Section 23.5.2 for instructions on how to do this in GNU Emacs.

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.)

23.1.4.2 Terminal-based Trojan horses

Another form of a Trojan horse makes use of block/send commands or answerback modes in some serial terminals that were developed in the 1970s and 1980s. Many brands of terminals supported modes in which certain sequences of control characters caused 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.

Some readers may wonder why in 2003 we are including information about block mode terminals! The reason is simple: there are still many such devices in general use around the world. What's more, many terminal emulators and programs may include support for such features, even if they are no longer documented! Our experience has shown us (and others) that flaws of a historical nature are often still lurking in the background, waiting to be rediscovered or reimplemented.

Annoyingly, even though the age of serial terminals has long since passed, many terminal emulator programs have mindlessly retained block/send and answerback functionality in the interest of compatibility! Avoid or disable this feature if it is present on your terminal emulator! (For example, this feature is present in Hilgrave's HyperTerm, Microsoft's HyperTerminal, and VanDyke Software's SecureCRT; SecureCRT allows answerback to be disabled and, in fact, disables this feature by default.)

A related form of a Trojan uses the write or talk program to transmit characters that lock up a keyboard, do a block/send as described above, or otherwise change terminal settings. There are several utility programs available on the Internet to perform these functions, and more than a few multiuser games and IRC clients have hidden code to allow a knowledgeable user to execute these functions.

23.1.4.3 Avoiding Trojan horses

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 source code to 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.

Unfortunately, many programs that are downloaded and run are simply too big to read through on a routine basis. What's more, even though many programs are available for download in source code form, many people download precompiled binaries. There is no way to ensure that the binaries being download actually match the source code from which they were reportedly produced.

As an alternative to inspection, run only programs that other people have tested before you. This method isn't fail-safe because it's possible that the program has an attack that won't trigger for other people but will trigger for you. Or it's possible that the program triggers for many people, but nobody else notices the attack.

You can also try to restrict yourself to software that is distributed by major corporations—ideally with a digital signature. This won't necessarily protect you, but it will give you somebody to sue if things go wrong.

And never, ever run anything as root unless you absolutely must.

23.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 some host program, of which they are a part, must be executed to activate them.

Viruses are usually found on personal computers running popular operating systems such as DOS, Microsoft Windows, and Apple MacOS. Viruses can propagate on operating systems that offer relatively little protection, such as DOS and MacOS versions prior to 10, and those that offer high degrees of protection, such as Microsoft Windows NT and XP. Viruses have also been written for Unix systems;^[1] virus authors have even created cross-platform viruses that can infect both Windows and Unix-based systems.

^[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.

Viruses are a powerful tool for attackers. While any task that can be accomplished by a virus—from gaining root access to destroying files—can be accomplished through other means, viruses are able to spread without the involvement or direction of the attacker. They can also spread to areas where the attacker cannot personally reach.

Unix systems face many virus threats, some which are common to other operating systems, some which are unique:

• Viruses can be hidden in source code or build environments that are downloaded over the Internet and then compiled. These viruses can then attach themselves to other source code or build environments that are resident on the developer's computer.

• Viruses can be hidden in pre-compiled binary distribution archives, such as Linux RPMs, FreeBSD packages, or Solaris patches. The use of digital signatures for cryptographically signing these distribution archives can reduce the chances of viruses propagating in this manner, assuming that there is no carelessness on the part of those who build and digitally sign the packages.

• Network-based viruses (and worms) can penetrate vulnerable network servers and then use the compromised systems for finding other vulnerable systems.

• Environments that let Windows-based software run on Unix can simultaneously open up the Unix system to Windows viruses.

• Web pages containing applets written in Java or other programming languages can contain viruses and other kinds of hostile code that exploit bugs in a browser's security implementation or that spread to local software.

• PostScript files can contain embedded commands to alter the filesystem and execute commands. While the popular GhostScript PostScript viewer is normally configured so that the PostScript commands for accessing files are disabled, these commands can be enabled. Other formats (e.g., Flash) may also contain executable commands.

• 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.

Unix systems running on PC hardware are also susceptible to PC boot-sector viruses, although the infection is unlikely to spread very far. The computer usually becomes infected when a person leaves an infected 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 such a virus is to make the Unix system fail to boot. This is because the virus is written for PC execution and not for Unix.

You can protect yourself against viruses using the same techniques you use to protect your system against back doors and attackers:

23.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. They do not change other programs, although they may carry other code that does (for example, a true virus). We have seen dozens of network worms, several of which were developed specifically to infect Unix-based systems (usually systems running Linux).^[2] Worms can cause significant damage.

^[2] During the production of the third edition of this book, the Slapper worm was attacking Unix hosts running Apache web servers using the mod_ssl module in combination with certain versions of OpenSSL. A successful penetration by this worm turned the victim host into a zombie that could be remote-controlled to perform a variety of scans and attacks on other systems. The vulnerability in OpenSSL had been announced (and patched) at least a month before the exploit was coded into a worm; nevertheless, Slapper spread to more than 10,000 hosts.

Protecting against worm programs requires the same techniques as protecting against break-ins. If an intruder can enter your machine, so can a worm. If your machine is secure from unauthorized access, it should be secure from the worm as well. All of our advice about protecting against unauthorized access applies here.

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 to break in (some were successful).

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 E) 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, this 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.

23.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, 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, and 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 24.