Chapter 8. Attacks And Defenses

At a Glance

Many techniques have been developed to attack workstations and servers. These techniques can be broadly divided into three categories:

Denial of service attacks and remote exploits

Vulnerabilities exist in many computers that make it possible for an attacker to disable the system without otherwise compromising it. In many cases, denials of service can be performed over the network without actually logging into the system. In other cases, attackers use network access to compromise and penetrate vulnerable systems.

Programmed threats

Another way for an attacker to compromise a system is to provide the system’s users with a hostile program and wait for them to run the program. Some programs install hidden services that give attackers remote access; others replicate themselves and travel between computers.

Social engineering

In a social engineering attack, the attacker takes advantage of the natural helpfulness of your users or administrators to cause them to reveal secrets or take inappropriate actions.

Each of these classes of attacks is covered in greater detail in this chapter, along with recommended defense practices.

Denial of Service Attacks

A denial of service attack is an attack in which one user takes up so much of a shared resource that none of the resource is left for other users. Denial of service attacks compromise the availability of the resources. Those resources can be processes, disk space, processor time, printer paper, modems, or the time of a harried system administrator. The result is degradation or loss of service.

Broadly speaking, there are two types of denial of service attacks:

Destructive attacks

Such attacks damage or destroy resources so you can’t use them. Examples range from causing a disk crash that halts your system to deleting critical system files.

Overload attacks

Such attacks overload some system service or exhaust some resource (either deliberately by an attacker, or accidentally as the result of a user’s mistake), thus preventing others from using that service. This simplest type of overload involves filling up a disk partition so users and system programs can’t create new files. A network-based overload attack could bombard a network server with so many requests that it is unable to service them, or it could flood an organization’s Internet connection so that there would be no bandwidth remaining to send desired information.

Many modern operating systems provide many mechanisms for protecting against denial of service. You may be able to limit the maximum number of files or processes that a user is allowed, the amount of disk space that each user is allotted, and even the amount of CPU time that each user process may consume. Network services can be limited

in terms of CPU time and rate. Nevertheless, many systems in the field remain vulnerable to denial of service attacks because the protective measures are typically not enabled nor properly set.

Destructive Attacks

There are a number of ways to destroy or damage information in a fashion that denies service. Almost all of the known attacks can be prevented by restricting access to critical accounts and files, and protecting them from unauthorized users. If you follow good security practices to protect the integrity of your system, you will also prevent destructive denial of service attacks.

Overload Attacks

In an overload attack, a shared resource or service is overloaded with requests to such a point that it is unable to satisfy requests from other users. For example, if one user spawns enough processes, other users won’t be able to run processes of their own. If one user fills up the disks, other users won’t be able to create new files. You can partially protect against overload attacks through the use of quotas and other techniques that limit the amount of resources that a single user can consume. You can use physical limitations as a kind of quota — for example, you can partition your computer’s resources, and then limit each user to a single partition. Finally, you can set up systems for automatically detecting overloads and restarting your computer — although giving an attacker the capability to restart your computer at will can create other problems.

Process, CPU, and Memory Overload Problems

One of the simplest denial of service attacks is a process attack. In a process attack, one user makes a computer unusable for others who happen to be using the computer at the same time. Another common process-based denial of service occurs when a user spawns many processes that consume large amounts of CPU or disk bandwidth. Yet another is when a user’s programs use up all of the system’s memory (physical and virtual). Such programs are sometimes called bacteria or rabbits, in tribute to their rapid spawning.

These attacks are generally of concern only with shared computers: the fact that a user incapacitates his or her own workstation is of no interest if nobody else is using the machine. For suggestions on recovering from a processbased attack, see (PUIS, Chapter 24).

The best way to deal with overload problems is to educate your users about how to share the system fairly. If CPUintensive jobs are common and you have a network of similar machines, you may wish to investigate a distributed task scheduling system. Quotas and limits, if supported by the operating system, can also be helpful.

Disk Attacks

Another way of overwhelming a system is to fill a disk partition. If one user fills up the disk, other users won’t be able to create files or do other useful work. Sometimes disks fill up suddenly when an application program or a user erroneously creates too many files (or a few files that are too large). Other times, disks fill up because many users are slowly increasing their disk usage.

Most operating systems provide commands to help the administrator examine disk space usage by device and user and make decisions about files to delete to recover more space. An effective way to protect your system from disk attacks is to use your operating system’s disk quota feature (usually available on POSIX-based systems). With disk quotas, each user can be limited in their disk use. Disk quotas typically need to be specified for each disk partition or filesystem that users can access – don’t forget about the partitions that store e-mail boxes, or that provide temporary filespace to processes.

You can also help protect your system from disk attacks and accidents by dividing your hard disk into several smaller partitions. Place different users’ home directories on different partitions. If one user fills up one partition, users on other partitions won’t be affected. Drawbacks of this approach include needing to move directories to different partitions if they require more space, and an inability to hard-link files between some user directories on systems that support hard links.

If you run network services that have the potential to allow outsiders to use up significant disk space (e.g., incoming mail or an anonymous FTP site that allows uploads), consider isolating them on separate partitions to protect your other partitions from overflows. Temporarily losing the ability to receive mail or files is an annoyance, but losing access to the entire server is much more frustrating.

Some filesystems, particularly those used on Unix systems, automatically reserve a portion of the disk that can only be used by superuser processes. This feature can help protect the system when the disk is full by allowing the superuser to log in and administer the system. On filesystems that don’t provide this feature, you can simulate it by creating a large dummy file on the disk that you can later delete if you need to recover space in an emergency.

Network Denial of Service Attacks

Networks are also vulnerable to denial of service attacks. In attacks of this kind, someone prevents legitimate users from using the network. Network denials of service come in several flavors.

Service Overloading

Service overloading occurs when floods of network requests are made to a server daemon on a single computer. These requests can be initiated in a number of ways, both accidental and intentional.

Service overloading can cause the system to be so busy servicing network interrupt requests that it can’t perform any other tasks in a timely fashion. Many requests will be thrown away as there is no room to queue them. Invariably, the legitimate requests will be resent, further adding to your computer’s load. If a service that causes a daemon to start a new process is under attack, your system may spawn so many new processes that it has no process table entries remaining to perform useful work. Similarly, the attack may cause the service may consume too much memory, CPU, or disk space.

The overload caused by the attack may be the ultimate goal of the attacker. Alternatively, the attack may be planned to mask an attack somewhere else. For example, a machine that records audit records may be attacked to prevent a login or logout from being logged in a timely manner. The overloading attack may be staged merely to distract attention or clog communications lines while something else, such as a car bombing, is taking place.

You can use a network monitor to reveal the type, and sometimes the origin, of overload attacks. If you have a list of machines and their hardware addresses (i.e., Ethernet board-level address, not IP address) this may help you track the source of the problem if it is local to your network. Isolating your local subnet or network while finding the problem may also help. If you have logging on your firewall or router, you can quickly determine if the attack is coming from outside your network or inside—you cannot depend on the source IP address in the packet being correct.

Although you cannot prevent overload attacks, there are many measures that you can take to limit their damage or make your system more robust against them.

Prepare for the attack

Install monitoring, logging, and other analysis systems, so that if an attack takes place, you will be able to rapidly diagnose the type of attack and, hopefully, the source. Have (protected) spare taps on your subnet so you can quickly hook up and monitor network traffic. Have printed lists of machine hardware and IP addresses available so you can determine the source of the overload by observing packet flow.

Partition your network into multiple subnets

This way, if one subnet gets flooded as part of an attack or accident, not all of your machines are disabled.

Provide for multiple Internet connections to your organization

These connections may include some that are not advertised but are kept in reserve.

Use “throttle” controls in your applications

Some applications have a “throttle” built in. If too many requests are received in too short a time, they will start rejecting requests and log a message that the service is failing. This is done under the assumption that some bug has been triggered to cause all the traffic. This has the side-effect of disabling your service as surely as if all the requests were accepted for processing. However, it may prevent the server itself from failing, and it results in an audit record showing when the problem occurred.

Make sure the limits specified in your configuration file are reasonable

For example, if you are running the Apache web server, a sudden increase in the number of requests to your server can cause a large number of http processes to be fork()’ed off. The total number of simultaneous connections is controlled by the parameter MaxClients in the Apache configuration file httpd.conf.

Many Apache distributions have MaxClients set at the value of 200, meaning that a maximum of 200 separate http processes might exist. If each httpd process has a memory of 8 megabytes, that could conceivably take 1.6 gigabytes of swap space. On the other hand, if each http process is taking 20 megabytes, then you would need 40 gigabytes of swap space — probably more than your system has.

Message Flooding

Message flooding occurs when a user slows down the processing of a system on the network, to prevent the system from processing its normal workload, by “flooding” the machine with network messages addressed to it. These may be requests for file service or login, or they may be simple echo-back requests. Whatever the form, the flood of messages overwhelms the target so it spends most of its resources responding to the messages. In extreme cases, this flood may cause the machine to crash with errors or lack of memory to buffer the incoming packets. This attack denies access to a network server.

A server that is being flooded may not be able to respond to network requests in a timely manner. An attacker can take advantage of this behavior by writing a program that answers network requests in the server’s place. For example, an attacker could flood an NIS server and then issue his own replies for NIS requests—specifically, requests for passwords.

A similar type of attack is a broadcast storm. By careful crafting of network messages, you can create a special message that instructs every computer receiving the message to reply or retransmit it. The result is that the network becomes saturated and unusable. Prior to the late 1990s, broadcast storms almost always resulted from failing hardware or from software that is under development, buggy, or improperly installed. However, it is possible to craft an intentional broadcast storm, and the so-called smurf and fraggle attacks were examples of such storms.

Broadcasting incorrectly formatted messages can also bring a network of machines to a grinding halt. If each machine is configured to log the reception of bad messages to disk or console, storms can generate so many messages that the clients can do nothing but process the errors and log them to disk or console.

Once again, preparing ahead with a monitor and breaking your network into subnets will help you prevent and deal with this kind of problem, although such planning will not eliminate the problem completely. In addition, some packet-filtering firewalls (external or host-based) can perform connection-rate-throttling to reduce the impact of these kinds of attacks. The Linux 2.4 kernel’s netfilter component is particularly notable in this regard.

It is important that all routers and firewalls be correctly configured to prevent forwarding of broadcast packets other than from authorized hosts. Check your vendor documentation for information on how to do this. CERT/CC advisory CA-1998-01, available from their WWW site, provides details on how to configure many common systems to stop such forwarding.

Most attack software that initiates denial-of-service attacks uses randomly-generated source addresses to decrease the likelihood that they will be intercepted. As a result, egress filters on borer routers will frequently stop computers within your network from participating in distributed denial of service attacks — and if they are still involved, it will make it much easier to trace them, because the attack packets will have proper return addresses.

Clogging (SYN Flood Attacks)

The implementation of the TCP/IP protocols on some operating systems allow them to be abused in various ways. One way to deny service is to use up the limit of partially open connections. TCP connections open on a multi-way handshake to open a connection and set parameters. If an attacker sends multiple requests to initiate a connection (“SYN” packets) but then fails to follow through with the subsequent parts of the connection, the recipient will be left with multiple half-open connections that are occupying limited resources. Usually, these connection requests have forged source addresses that specify nonexistent or unreachable hosts that cannot be contacted. Thus, there is also no way to trace the connections back. They remain until they time out (or until they are reset by the intruder). Such attacks are often called SYN flood attacks or, more simply, clogging.

There are many solutions to the problems of SYN floods. Some operating systems will automatically detect when they are being subjected to a SYN flood attack and will lower the timeout for SYN packets. Alternatively, if the table of half-opened connections is filled, the operating system can choose to randomly drop one of the entries from the table. As the table usually only fills up when the system is under attack, the odds are overwhelming that one of the attacker’s SYN packets will be dropped.

Finally, the server can use SYN cookies. When SYN cookies are in use, the SYN+ACK that is sent from the TCP server to the TCP client contains enough information for the server to reconstruct its half of the TCP connection, allowing the server to flush the original SYN from its tables. When the ACK is received from the client, the server reconstructs the original SYN, the TCP three-way hand-shake connection is completed, and the connection starts up. This effectively makes TCP setup a stateless process. SYN cookies were invented by Daniel Bernstein and are described in detail at http://cr.yp.to/syncookies.html. A SYN cookies implementation is included with BSD and Linux systems (but must be specifically enabled on Linux systems).

Some operating systems allow you to change the queuing behavior for half-open connections. You can increase the size of the queue, and decrease the time before a half-open connection times out. Again, this is nonstandard in form, and some vendor versions require manipulation of kernel variables with a symbolic debugger. Check with your vendor for specifics.

Malformed traffic attacks

In the past, bugs in low-level network drivers have caused many systems to fail when presented with a single malformed packet or HTTP query. For example, the infamous “Ping of Death” caused both Windows and Unix systems to crash when they received an ICMP packet that was longer than a specific threshold value. Many networked devices, including printer servers, home firewalls, and even routers, have crashed when they are probed for IIS or Apache vulnerabilities.

In general, the only way to protect against malformed traffic is to use a proxy firewall and to be sure that your systems are properly updated.

Distributed denials of service

The most pernicious network attacks are distributed denials of service (DDoS) attacks. In a DDoS attack, the attacker overloads network services or floods the network with messages, but does so from a large number of different attack hosts distributed around the Internet. Because the attack packets do not come from a single system, it is difficult to block them with a packet filtering firewall without cutting your hosts off from the whole of the Internet.

DDoS attacks are usually coordinated through slave processes (zombies or Trojans) installed in compromised hosts that allow the attacker to remotely direct the hosts to attack a target. A key to preventing DDoS attacks (and potential liability) is keeping your systems protected from compromise so that they cannot be used as zombies in further attacks. At the network level, implementing ingress and egress filtering to prevent packets with bogus source addresses from leaving the local network can prevent local machines from participating in DDoS attacks. This strategy is discussed in RFC2827.

However, DDoS attacks do not require the use of special software. One form of DDoS attacks involves simply sending ICMP echo (“ping”) messages with forged source addresses to many computers around the Internet. The ICMP echo messages are returned to the victim computer. Another version simply initiates a number of TCP connection attempts from nonexistent IP addresses. The target machine consumes resources initiating and verifying the connection attempt, and this can paralyze a machine if enough requests come in.

Sometimes a DDoS attack can be defeated in progress by changing the IP address and hostname of the machine being attacked. If the attack software is using a hardcoded victim address or hostname, changing these can protect the victim host and packets directed at the old address can be filtered at the external router or by the organization’s ISP. For example, the Blaster worm in August 2003 was designed to initiate a DDoS attack against a hardcoded address for the Microsoft Windows Update service. Microsoft responded by insuring that Windows Update would use a different IP address.

One of the best known DDoS attacks took place in February 2000, and targeted web servers at high-profile companies like Amazon and Yahoo. An analysis of trinoo, the Trojan that was used to compromise and control the

zombies that participated in the attack, can be found at http://www.sans.org/newlook/resources/IDFAQ/trinoo.htm

Remote exploits

Because network server applications are designed to communicate with untrusted outsiders, and because many run with special privileges, bugs in network server applications can often lead to remote exploits.

Many remote exploits are based on the buffer overflow technique. This technique relies on the way that the C programming language lays out information inside the computer’s memory. The remote system might try to store 100 bytes into a buffer that is only set up to hold 30 or 40 bytes. The resulting information overwrites the C program’s stack frame and causes machine code specified by the attacker to be executed with the process’s privileges.242

The most important defense against remote exploits is care in choosing and configuring networking software. Some application programs have repeatedly proven vulnerable, while others have been designed from the outset with security in mind and have a much lower rate of compromise. This defense is covered in greater depth in the chapter on Server Security.

Programmed Threats

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, the instructions are malicious code, or a programmed threat. Some people use the term malware to describe malicious software.

These days, most programmed threats arrive via the Internet, in the form of either an e-mail message or a direct attack on a network-based server. A received e-mail message or direct attack may be the result of a random event — your organization’s web server might be randomly chosen — or it may be deliberate: you may have been specifically targeted by a adversary. It is easy to mistake a directed attack for a random one, and vice-versa. A directed attack is much more worrisome than a random one, as a motivated attacker may continue to assault your organization until the attacker is successful or is stopped.

Users may also be unwitting agents of transmission for viruses, worms, and other such threats. They may install new software from outside, and install embedded malicious code at the same time. They may run a “screen saver” or download a pornographic “viewer” from the Internet that contains a Trojan horse. Of course, most programs that are downloaded from the Internet do not contain any hostile code at all. However, the widespread practice of downloading and running code from untrusted sources makes it all the easier for hostile programs to be successful. You must therefore 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. This won’t necessarily protect you, but it will give you somebody to sue if things go wrong.

If possible, never download binary files. Instead, 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. Accept software only from trusted sources.

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; others have been known to

242 This form of attack is at least 35 years old and well known. It is astonishing that vendors are still building software that can be exploited this way.

distribute privacy-invading “spyware” with their software. As long as customers 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, although it has the advantage of providing source code that you can read for yourself. 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 backdoors 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!

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 pre-compiled binaries. There is no way to assure that the binaries being download actually match the source code from which that were reportedly produced.

As an alternative to inspection, only run programs that other people have tested before you. This method isn’t failsafe, 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.

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! And never, ever run anything as the superuser or administrator unless you absolutely must.

If you are targeted by a knowledgeable insider, that insider may write back doors, logic bombs, Trojan horses, and bacteria directly on the target system using readily-available tools. Your users and especially your staff pose a significant threat to your system’s overall security: these people understand the system, know its weaknesses, and know the auditing and control systems that are in place. Legitimate users often have access with sufficient privilege to write and introduce malicious code into the system. Especially ironic, perhaps, is the idea that at many companies the person responsible for security and control is also the person who could cause the most damage if he wished to issue the appropriate commands. Frequently, there is no technical auditing or other checks-and-balances for senior system management.

Security tools and toolkits

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 also 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 written 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.

Rootkits are a special case: these are prepackaged attack toolkits that also install backdoors into your system once they have penetrated superuser account security.

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. Obtaining the tools and running them yourself has some merit, but there are also 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 for problems. Don’t rush to use security scanners yourself unless you are very certain that you understand what they do and how they might help you secure your own system.

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.

Sometimes, an attacker inserts a back door in a system after he successfully penetrates that system. The back door gives the cracker a way to get back into the system or to gain administrative privileges at a later time.

Protecting against backdoors is complicated. The foremost defense is to routinely check the integrity of important files (see chapter 5-3). In addition to checking your files, you should routinely scan the system for privileged 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.

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, such as paying a license fee. Time-outs 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.

Trojan Horses

Analogous to their namesake, modern-day Trojan horses resemble a program that the user wishes to run—a login process, 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 posting confidential documents to a web site across the globe. Trojan horses are, unfortunately, as common as jokes within some environments. They are often planted as cruel tricks on hacker web sites and circulated among individuals as shared software.

Trojan horses have been found in installation programs and scripts. Shell files (especially shar files), VBS, awk, Perl, and sed scripts, TeX files, PostScript files, MIME-encoded mail, and web pages can all contain commands that can cause you unexpected problems. Even text files can be dangerous. Some 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 (see the documentation for your own editor to see how to disable this feature).

If you are unpacking files or executing scripts for the first time, you might wish to do so on a secondary machine or use a restricted environment to prevent the package from accessing files or directories outside its work area (Unix provides this feature via the chroot() system call).

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 (and that are emulated by many terminal emulation programs written since, including Microsoft’s HyperTerminal). Many brands of terminals have 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 embedded in mail may direct the terminal to send a “delete all files and log out” command to the operating system, followed by a “clear screen” sequence to the terminal. Avoid or disable this feature on your terminal or emulator.

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

Nearly all viruses target personal computers running popular operating systems. such as Microsoft 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; virus authors have even created cross-platform viruses that can infect both Windows and Unix-based system. Viruses that target PC boot sectors can infect systems running BSD or Linux as easily as Windows if an infected floppy disk is booted (although they often cannot spread further).

Viruses are a powerful tool for attackers. While any task that can be accomplished by a virus 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 that the attacker cannot personally reach.

You can protect yourself against viruses using the same techniques you use to protect your system against back doors and crackers. On Intel-based PCs, it’s also important not to boot from untrusted disks. Anti-virus software is now considered a basic requirement for corporate and home PCs. Despite this, more machines lack anti-virus software than have it. Almost as unfortunate is the fact that many people who have purchased anti-virus software have failed to update the virus signatures recently, thus rendering the software largely useless against current threats.

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). There have been dozens of network worms that have targeted many different operating systems. Perhaps the most common propagate by e-mail, often extracting e-mail addresses from the infected system’s e-mail application’s address book and sending itself to those users claiming to be an important message from the infected system’s owner (or from other users whose address is in the owner’s address book.)

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.

If you suspect that your machine is under attack by a worm program across the network, call one of the computerincident response centers 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. Consider severing 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.

Blended Threats

Most of the newer and more dangerous programmed threats are blended threats. A blended threat is a programmed attack that combines the features of several other kinds of attacks and propagates through multiple vectors. A typical blended threat might be a network worm that propagates by e-mailing copies of itself to addresses in the infected computer’s address book or through file sharing with other connected systems; once infected, the worm installs a back door, a zombie for coordinating a future distributed denial of service attack, and a logic bomb. Defending against blended threats is like defending against single-vector attacks, but requires that you consider all of the vectors. A layered defense is the best practice for avoiding blended threats.

Social Engineering

On many computer systems it is possible to exploit bugs or other vulnerabilities to parlay ordinary access granted to normal users into “superuser” or “administrative” access that is granted to system operators. Thus, with a stolen username and password, a moderately skilled attacker can gain full run of many systems.

One of the most common ways for an attacker to get a username and password is social engineering. Social engineering is one of the simplest and most effective means of gaining unauthorized access to a computer system. For a social engineering attack, an attacker basically telephones the target organization and tries to socially extract information. For example, the attacker might pretend to be a new employee who has forgotten the password for his or her account and needs to have the password “reset.” Or the attacker might pretend to be a service representative, claiming that the Administrator account needs to have its password changed so that routine maintenance can be performed. Social engineering attacks are effective because people generally want to be helpful – they are the computer equivalent of confidence games.

Social engineering can also be automated. There are many so-called phishing programs that will send social engineering e-mails to thousands or tens of thousands of users at a time. Some programs solicit usernames and passwords. Others try for valid credit cards.

The most effective defense against social engineering is a vigorous user education program. Users should be taught (and reminded frequently) not to divulge any security-related information to anyone they do not know already to be an authentic organization security employee, and then only in person. Users should be told that security personnel will never ask them to divulge their passwords, credit card numbers, or other authenticators, and anyone or any message that does should be immediately reported to the computer staff.