|
|
| Previous | Table of Contents | Next |
Before looking at common attacks, it is useful to characterize the attack. Attacks can be made against a particular system or a particular organization.
When attacking an organization, attacks can be oriented to look for mistakes due to the distributed control of the systems. An intruder needs only a single window of opportunity to enter the network. Such attacks focus on breadth rather than innovation. For example, if I wanted to attack the U.S.’s DoD MILNET network, it would probably be most expedient to search all the MILNET gateway systems for one that ran old versions of sendmail, offered unrestricted NFS exports, or ran an NIS server, rather than trying to find a new vulnerability in the HTTP protocol.
Attacks against single hosts might take advantage of weaknesses in that host as well as vulnerabilities in “nearby” systems, that is, systems that are trusted by the target system, systems that are connected to the same physical network, or systems that have the same users. In the first case, attackers can try to masquerade as the trusted system or user using IP spoofing and DNS cache corruption. In the second case, attackers can try to install packet sniffers that will capture traffic going to and from the target system. In the final case, attackers can try to find user passwords and try them on the target system.
Note: For more information on spoofing and sniffing, see Chapter 5.
In general, most attacks follow three phases:
Phase One: Get a Login Account
The first goal of any attack on a Unix system is to get a login account and a password. The attacker wants to get a copy of the encrypted passwords stored in /etc/passwd or an NIS map. Once they have the passwd file, they can run Crack on it and probably guess at least one password. Even though policy guidelines and system software try to enforce good password selection, it rarely happens.
Note: Crack is a program originally created by Alec Muffett of Sun Microsystems. It tries to guess passwords, encrypt these guesses, and compare the encrypted guesses to the encrypted fields of each user account in a password file. By using some intelligent rules, such as permutations on the login name, and a user-provided dictionary of words and names, which can be as large as the user specifies, Crack can be surprisingly effective at quickly guessing passwords. With even a simple dictionary of a few hundred common passwords, Crack has a good likelihood of cracking an account in minutes. With a megabyte dictionary, Crack may run for a few days, but it has a high chance of finding even obscure passwords. See Appendix B, “Internet Security References,” for the FTP location of Crack.
How does an attacker get a login to a target Unix system? First, the hacker gathers information about security holes that exist in different Unix products and ways to exploit these holes. Second, the hacker gathers information about a target organization’s computer systems and networks. Finally, the hacker matches the opportunities with the vulnerability information and attempts to gain a login into the system.
It is true that other attacks can occur, most notably the denial of service attack (described in detail later in this chapter); however, the attempt at gaining login access appears to be the most dangerous and frequent.
SATAN specifically addresses remote vulnerabilities. This chapter demonstrates a step-by-step procedure of how an intruder would implement the first phase of an attack.
Warning: Absurd as this may sound, the legal implications of running a program such as Crack may be quite severe. In early 1995, Randall Schwartz, author of several books on PERL, was convicted in Oregon, along with other charges, of running Crack against the /etc/passwd file of an Intel Corporation system. Even though he was working for Intel as a security consultant, Intel had not authorized him to run Crack. Be certain that your company permits you to run Crack before attempting to do so.
Phase Two: Get Root Access
The second phase of an attack is not necessarily a network problem. The intruder will try to exploit existing holes on a particular Unix system, such as trying to find a set-uid root script, in order to gain the ability to run as root. Some network problems, such as unrestricted NFS access with root permissions for reading and writing, can be used to gain root access. SATAN really does not specifically investigate this area of an attack—instead, SATAN scans for phase one problems that permit a remote user to gain access to the system at either a user or root level. A better tool for this second phase might be COPS program COPS, another program from the makers of SATAN (see Appendix B for details on getting COPS).
The appropriate way for a system administrator to protect a system from this attack is to closely follow security advisories from vendors, CIAC, and CERT, and install patches as they become available. Careful configuration and setup can help to minimize potential vulnerabilities. If a hole exists that permits the user to act as root, the intruder can possibly still be caught by tracks left in utmp/wtmp. (All currently logged in users are listed in the utmp file. A history of all logins and logouts are transferred from the utmp file to the wtmp file. The “last” command will format the wtmp file and provide a complete listing of all logins, including information on the source of the login and the duration of the login.) However, not all programs leave entries in the utmp/wtmp files: remsh/rsh execute commands on the remote system without making any entry into the utmp/wtmp file. The syslog files are also extremely useful in monitoring system activity. Security monitoring programs exist that offer additional tracking capabilities.
Programs that permit users to gain superuser access, such as sudo, .do, !, sys, or osh, should be offered to users on a time-limited basis, such as an automatic 24-hour limit, to minimize root exposure. Some of these programs, such as osh, provide for control over what root actions are permitted, decreasing the scope of damage that could occur. Regardless, the root password should be changed frequently, and control on login locations for root (console only) should be considered. (This is described in detail in the “Passwords” section of this chapter.)
| Previous | Table of Contents | Next |