Download System security Viruses and worms and more Study notes Network security in PDF only on Docsity!
INTRUDERS
20.1 Intruders Intruder Behavior Patterns Intrusion Techniques 20.2 Intrusion Detection Audit Records Statistical Anomaly Detection Rule-Based Intrusion Detection The Base-Rate Fallacy Distributed Intrusion Detection Honeypots Intrusion Detection Exchange Format 20.3 Password Management Password Protection Password Selection Strategies 20.4 Recommended Reading and Web Sites 20.5 Key Terms, Review Questions, and Problems Appendix 20A The Base-Rate Fallacy
CHAPTER
PART 6: SYSTEM SECURITY
20-2 CHAPTER 20 / INTRUDERS
They agreed that Graham should set the test for Charles Mabledene. It was nei- ther more nor less than that Dragon should get Stern’s code. If he had the ‘in’ at Utting which he claimed to have this should be possible, only loyalty to Moscow Centre would prevent it. If he got the key to the code he would prove his loyalty to London Central beyond a doubt. — Talking to Strange Men , Ruth Rendell
KEY POINTS
! Unauthorized intrusion into a computer system or network is one of the most serious threats to computer security. ! Intrusion detection systems have been developed to provide early warning of an intrusion so that defensive action can be taken to prevent or mini- mize damage. ! Intrusion detection involves detecting unusual patterns of activity or patterns of activity that are known to correlate with intrusions. ! One important element of intrusion prevention is password management, with the goal of preventing unauthorized users from having access to the passwords of others.
A significant security problem for networked systems is hostile, or at least unwanted, trespass by users or software. User trespass can take the form of unau- thorized logon to a machine or, in the case of an authorized user, acquisition of priv- ileges or performance of actions beyond those that have been authorized. Software trespass can take the form of a virus, worm, or Trojan horse. All these attacks relate to network security because system entry can be achieved by means of a network. However, these attacks are not confined to net- work-based attacks. A user with access to a local terminal may attempt trespass without using an intermediate network. A virus or Trojan horse may be introduced into a system by means of an optical disc. Only the worm is a uniquely network phe- nomenon. Thus, system trespass is an area in which the concerns of network security and computer security overlap. Because the focus of this book is network security, we do not attempt a com- prehensive analysis of either the attacks or the security countermeasures related to system trespass. Instead, in this Part we present a broad overview of these concerns. This chapter covers the subject of intruders. First, we examine the nature of the attack and then look at strategies intended for prevention and, failing that, detection. Next we examine the related topic of password management.
20-4 CHAPTER 20 / INTRUDERS
Table 20.1 Some Examples of Intruder Patterns of Behavior (a) Hacker
1. Select the target using IP lookup tools such as NSLookup, Dig, and others. 2. Map network for accessible services using tools such as NMAP. 3. Identify potentially vulnerable services (in this case, pcAnywhere). 4. Brute force (guess) pcAnywhere password. 5. Install remote administration tool called DameWare. 6. Wait for administrator to log on and capture his password. 7. Use that password to access remainder of network. (b) Criminal Enterprise 1. Act quickly and precisely to make their activities harder to detect. 2. Exploit perimeter through vulnerable ports. 3. Use Trojan horses (hidden software) to leave back doors for reentry. 4. Use sniffers to capture passwords. 5. Do not stick around until noticed. 6. Make few or no mistakes. (c) Internal Threat 1. Create network accounts for themselves and their friends. 2. Access accounts and applications they wouldn’t normally use for their daily jobs. 3. E-mail former and prospective employers. 4. Conduct furtive instant-messaging chats. 5. Visit Web sites that cater to disgruntled employees, such as f’dcompany.com. 6. Perform large downloads and file copying. 7. Access the network during off hours.
at three broad examples of intruder behavior patterns, to give the reader some feel for the challenge facing the security administrator. Table 20.1, based on [RADC04], summarizes the behavior. H ACKERS Traditionally, those who hack into computers do so for the thrill of it or for status. The hacking community is a strong meritocracy in which status is determined by level of competence. Thus, attackers often look for targets of opportunity and then share the information with others. A typical example is a break-in at a large financial institution reported in [RADC04]. The intruder took advantage of the fact that the corporate network was running unprotected services, some of which were not even needed. In this case, the key to the break-in was the pcAnywhere application. The manufacturer, Symantec, advertises this program as a remote control solution that enables secure connection to remote devices. But the attacker had an easy time gaining access to pcAnywhere; the administrator used the same three-letter username and password for the program. In this case, there was no intrusion detection system on the 700-node corporate network. The intruder was only discovered when a vice president walked into her office and saw the cursor moving files around on her Windows workstation.
20.1 / INTRUDERS 20-
Benign intruders might be tolerable, although they do consume resources and may slow performance for legitimate users. However, there is no way in advance to know whether an intruder will be benign or malign. Consequently, even for systems with no particularly sensitive resources, there is a motivation to control this problem. Intrusion detection systems (IDSs) and intrusion prevention systems (IPSs) are designed to counter this type of hacker threat. In addition to using such systems, organizations can consider restricting remote logons to specific IP addresses and/or use virtual private network technology. One of the results of the growing awareness of the intruder problem has been the establishment of a number of computer emergency response teams (CERTs). These cooperative ventures collect information about system vulnerabilities and disseminate it to systems managers. Hackers also routinely read CERT reports. Thus, it is important for system administrators to quickly insert all software patches to discovered vulnerabilities. Unfortunately, given the complexity of many IT systems, and the rate at which patches are released, this is increasingly difficult to achieve without automated updating. Even then, there are problems caused by incompatibilities resulting from the updated software. Hence the need for multiple layers of defense in managing security threats to IT systems.
C RIMINALS Organized groups of hackers have become a widespread and common threat to Internet-based systems. These groups can be in the employ of a corpo- ration or government but often are loosely affiliated gangs of hackers. Typically, these gangs are young, often Eastern European, Russian, or southeast Asian hackers who do business on the Web [ANTE06]. They meet in underground forums with names like DarkMarket.org and theftservices.com to trade tips and data and coordinate attacks. A common target is a credit card file at an e-commerce server. Attackers attempt to gain root access. The card numbers are used by organized crime gangs to purchase expensive items and are then posted to carder sites, where others can access and use the account numbers; this obscures usage patterns and complicates investigation. Whereas traditional hackers look for targets of opportunity, criminal hackers usually have specific targets, or at least classes of targets in mind. Once a site is pene- trated, the attacker acts quickly, scooping up as much valuable information as possi- ble and exiting. IDSs and IPSs can also be used for these types of attackers, but may be less effective because of the quick in-and-out nature of the attack. For e-commerce sites, database encryption should be used for sensitive customer information, espe- cially credit cards. For hosted e-commerce sites (provided by an outsider service), the e-commerce organization should make use of a dedicated server (not used to support multiple customers) and closely monitor the provider’s security services.
I NSIDER ATTACKS Insider attacks are among the most difficult to detect and prevent. Employees already have access and knowledge about the structure and content of corporate databases. Insider attacks can be motivated by revenge or simply a feeling of entitlement. An example of the former is the case of Kenneth Patterson, fired from his position as data communications manager for American Eagle Outfitters. Patterson disabled the company’s ability to process credit card purchases during five days of the holiday season of 2002. As for a sense of entitlement, there have
20.1 / INTRUDERS 20-
interviews with a number of password crackers, [ALVA90] reports the following techniques for learning passwords:
1. Try default passwords used with standard accounts that are shipped with the system. Many administrators do not bother to change these defaults. 2. Exhaustively try all short passwords (those of one to three characters). 3. Try words in the system’s online dictionary or a list of likely passwords. Examples of the latter are readily available on hacker bulletin boards. 4. Collect information about users, such as their full names, the names of their spouse and children, pictures in their office, and books in their office that are related to hobbies. 5. Try users’ phone numbers, Social Security numbers, and room numbers. 6. Try all legitimate license plate numbers for this state. 7. Use a Trojan horse (described in Chapter 21) to bypass restrictions on access. 8. Tap the line between a remote user and the host system.
The first six methods are various ways of guessing a password. If an intruder has to verify the guess by attempting to log in, it is a tedious and easily countered means of attack. For example, a system can simply reject any login after three password attempts, thus requiring the intruder to reconnect to the host to try again. Under these circum- stances, it is not practical to try more than a handful of passwords. However, the intruder is unlikely to try such crude methods. For example, if an intruder can gain access with a low level of privileges to an encrypted password file, then the strategy would be to capture that file and then use the encryption mechanism of that particular system at leisure until a valid password that provided greater privileges was discovered. Guessing attacks are feasible, and indeed highly effective, when a large num- ber of guesses can be attempted automatically and each guess verified, without the guessing process being detectable. Later in this chapter, we have much to say about thwarting guessing attacks. The seventh method of attack listed earlier, the Trojan horse, can be particularly difficult to counter. An example of a program that bypasses access controls was cited in [ALVA90]. A low-privilege user produced a game program and invited the system operator to use it in his or her spare time. The program did indeed play a game, but in the background it also contained code to copy the password file, which was unen- crypted but access protected, into the user’s file. Because the game was running under the operator’s high-privilege mode, it was able to gain access to the password file. The eighth attack listed, line tapping, is a matter of physical security. Other intrusion techniques do not require learning a password. Intruders can get access to a system by exploiting attacks such as buffer overflows on a program that runs with certain privileges. Privilege escalation can be done this way as well. We turn now to a discussion of the two principal countermeasures: detection and prevention. Detection is concerned with learning of an attack, either before or after its success. Prevention is a challenging security goal and an uphill battle at all times. The difficulty stems from the fact that the defender must attempt to thwart all possible attacks, whereas the attacker is free to try to find the weakest link in the defense chain and attack at that point.
20-8 CHAPTER 20 / INTRUDERS
20.2 INTRUSION DETECTION
Inevitably, the best intrusion prevention system will fail. A system’s second line of defense is intrusion detection, and this has been the focus of much research in recent years. This interest is motivated by a number of considerations, including the following:
1. If an intrusion is detected quickly enough, the intruder can be identified and ejected from the system before any damage is done or any data are compro- mised. Even if the detection is not sufficiently timely to preempt the intruder, the sooner that the intrusion is detected, the less the amount of damage and the more quickly that recovery can be achieved. 2. An effective intrusion detection system can serve as a deterrent, so acting to pre- vent intrusions. 3. Intrusion detection enables the collection of information about intrusion tech- niques that can be used to strengthen the intrusion prevention facility.
Intrusion detection is based on the assumption that the behavior of the intruder differs from that of a legitimate user in ways that can be quantified. Of course, we cannot expect that there will be a crisp, exact distinction between an attack by an intruder and the normal use of resources by an authorized user. Rather, we must expect that there will be some overlap. Figure 20.1 suggests, in very abstract terms, the nature of the task confronting the designer of an intrusion detection system. Although the typical behavior of an
Overlap in observed or expected behavior
Profile of intruder behavior
Profile of authorized user behavior
Measurable behavior parameter
Average behavior of intruder
Average behavior of authorized user
Probability density function
Figure 20.1 Profiles of Behavior of Intruders and Authorized Users
20-10 CHAPTER 20 / INTRUDERS
Audit Records
A fundamental tool for intrusion detection is the audit record. Some record of ongoing activity by users must be maintained as input to an intrusion detection system. Basically, two plans are used:
- Native audit records: Virtually all multiuser operating systems include accounting software that collects information on user activity. The advantage of using this information is that no additional collection software is needed. The disadvantage is that the native audit records may not contain the needed information or may not contain it in a convenient form.
- Detection-specific audit records: A collection facility can be implemented that generates audit records containing only that information required by the intrusion detection system. One advantage of such an approach is that it could be made vendor independent and ported to a variety of systems. The disad- vantage is the extra overhead involved in having, in effect, two accounting packages running on a machine. A good example of detection-specific audit records is one developed by Dorothy Denning [DENN87]. Each audit record contains the following fields:
- Subject: Initiators of actions. A subject is typically a terminal user but might also be a process acting on behalf of users or groups of users. All activity arises through commands issued by subjects. Subjects may be grouped into different access classes, and these classes may overlap.
- Action: Operation performed by the subject on or with an object; for example, login, read, perform I/O, execute.
- Object: Receptors of actions. Examples include files, programs, messages, records, terminals, printers, and user- or program-created structures. When a subject is the recipient of an action, such as electronic mail, then that subject is considered an object. Objects may be grouped by type. Object granularity may vary by object type and by environment. For example, database actions may be audited for the database as a whole or at the record level.
- Exception-Condition: Denotes which, if any, exception condition is raised on return.
- Resource-Usage: A list of quantitative elements in which each element gives the amount used of some resource (e.g., number of lines printed or displayed, number of records read or written, processor time, I/O units used, session elapsed time).
- Time-Stamp: Unique time-and-date stamp identifying when the action took place. Most user operations are made up of a number of elementary actions. For example, a file copy involves the execution of the user command, which includes doing access validation and setting up the copy, plus the read from one file, plus the write to another file. Consider the command
COPY GAME.EXE TO GAME.EXE
20.2 / INTRUSION DETECTION 20-
issued by Smith to copy an executable file GAME from the current directory to the directory. The following audit records may be generated:
In this case, the copy is aborted because Smith does not have write permission to . The decomposition of a user operation into elementary actions has three advantages:
1. Because objects are the protectable entities in a system, the use of elementary actions enables an audit of all behavior affecting an object. Thus, the system can detect attempted subversions of access controls (by noting an abnormal- ity in the number of exception conditions returned) and can detect successful subversions by noting an abnormality in the set of objects accessible to the subject. 2. Single-object, single-action audit records simplify the model and the implemen- tation. 3. Because of the simple, uniform structure of the detection-specific audit records, it may be relatively easy to obtain this information or at least part of it by a straightforward mapping from existing native audit records to the detection-specific audit records.
Statistical Anomaly Detection
As was mentioned, statistical anomaly detection techniques fall into two broad categories: threshold detection and profile-based systems. Threshold detection involves counting the number of occurrences of a specific event type over an inter- val of time. If the count surpasses what is considered a reasonable number that one might expect to occur, then intrusion is assumed. Threshold analysis, by itself, is a crude and ineffective detector of even moder- ately sophisticated attacks. Both the threshold and the time interval must be deter- mined. Because of the variability across users, such thresholds are likely to generate either a lot of false positives or a lot of false negatives. However, simple threshold detectors may be useful in conjunction with more sophisticated techniques. Profile-based anomaly detection focuses on characterizing the past behavior of individual users or related groups of users and then detecting significant devia- tions. A profile may consist of a set of parameters, so that deviation on just a single parameter may not be sufficient in itself to signal an alert. The foundation of this approach is an analysis of audit records. The audit records provide input to the intrusion detection function in two ways. First, the designer must decide on a number of quantitative metrics that can be used to mea- sure user behavior. An analysis of audit records over a period of time can be used to
Smith execute COPY.EXE^0 CPU = 00002 11058721678
Smith read GAME.EXE^0 RECORDS = 0 11058721679
Smith execute COPY.EXE^ write-viol RECORDS = 0 11058721680
20.2 / INTRUSION DETECTION 20-
A time series model focuses on time intervals, looking for sequences of events that happen too rapidly or too slowly. A variety of statistical tests can be applied to characterize abnormal timing. Finally, an operational model is based on a judgment of what is considered abnormal, rather than an automated analysis of past audit records. Typically, fixed limits are defined and intrusion is suspected for an observation that is outside the limits. This type of approach works best where intruder behavior can be deduced from certain types of activities. For example, a large number of login attempts over a short period suggests an attempted intrusion. As an example of the use of these various metrics and models, Table 20. shows various measures considered or tested for the Stanford Research Institute (SRI) intrusion detection system (IDES) [DENN87, JAVI91, LUNT88]. The main advantage of the use of statistical profiles is that a prior knowledge of security flaws is not required.The detector program learns what is “normal” behavior and then looks for deviations. The approach is not based on system-dependent characteristics and vulnerabilities. Thus, it should be readily portable among a variety of systems.
Rule-Based Intrusion Detection
Rule-based techniques detect intrusion by observing events in the system and applying a set of rules that lead to a decision regarding whether a given pattern of activity is or is not suspicious. In very general terms, we can characterize all approaches as focusing on either anomaly detection or penetration identification, although there is some overlap in these approaches. Rule-based anomaly detection is similar in terms of its approach and strengths to statistical anomaly detection. With the rule-based approach, historical audit records are analyzed to identify usage patterns and to generate automatically rules that describe those patterns. Rules may represent past behavior patterns of users, programs, privileges, time slots, terminals, and so on. Current behavior is then observed, and each transaction is matched against the set of rules to determine if it conforms to any historically observed pattern of behavior. As with statistical anomaly detection, rule-based anomaly detection does not require knowledge of security vulnerabilities within the system. Rather, the scheme is based on observing past behavior and, in effect, assuming that the future will be like the past. In order for this approach to be effective, a rather large database of rules will be needed. For example, a scheme described in [VACC89] contains any- where from 10^4 to 10^6 rules. Rule-based penetration identification takes a very different approach to intru- sion detection. The key feature of such systems is the use of rules for identifying known penetrations or penetrations that would exploit known weaknesses. Rules can also be defined that identify suspicious behavior, even when the behavior is within the bounds of established patterns of usage. Typically, the rules used in these systems are specific to the machine and operating system. The most fruitful approach to developing such rules is to analyze attack tools and scripts collected on the Internet. These rules can be supplemented with rules generated by knowledge- able security personnel. In this latter case, the normal procedure is to interview
Table 20.2 Measures That May Be Used for Intrusion Detection
Measure Model Type of Intrusion Detected Login and Session Activity Login frequency by day and time
Mean and standard deviation
Intruders may be likely to log in during off-hours.
Frequency of login at different locations
Mean and standard deviation
Intruders may log in from a location that a particu- lar user rarely or never uses. Time since last login Operational Break-in on a “dead” account. Elapsed time per session Mean and standard deviation
Significant deviations might indicate masquerader.
Quantity of output to location Mean and standard deviation
Excessive amounts of data transmitted to remote locations could signify leakage of sensitive data. Session resource utilization Mean and standard deviation
Unusual processor or I/O levels could signal an intruder. Password failures at login Operational Attempted break-in by password guessing.
Failures to login from specified terminals
Operational Attempted break-in.
Command or Program Execution Activity Execution frequency Mean and standard deviation
May detect intruders, who are likely to use different commands, or a successful penetration by a legiti- mate user, who has gained access to privileged commands. Program resource utilization Mean and standard deviation
An abnormal value might suggest injection of a virus or Trojan horse, which performs side-effects that increase I/O or processor utilization. Execution denials Operational model May detect penetration attempt by individual user who seeks higher privileges. File Access Activity Read, write, create, delete frequency
Mean and standard deviation
Abnormalities for read and write access for individ- ual users may signify masquerading or browsing. Records read, written Mean and standard deviation
Abnormality could signify an attempt to obtain sen- sitive data by inference and aggregation. Failure count for read, write, create, delete
Operational May detect users who persistently attempt to access unauthorized files.
20-14 CHAPTER 20 / INTRUDERS
system administrators and security analysts to collect a suite of known penetration scenarios and key events that threaten the security of the target system. A simple example of the type of rules that can be used is found in NIDX, an early system that used heuristic rules that can be used to assign degrees of suspicion to activities [BAUE88]. Example heuristics are the following:
1. Users should not read files in other users’ personal directories. 2. Users must not write other users’ files.
20-16 CHAPTER 20 / INTRUDERS
The Base-Rate Fallacy
To be of practical use, an intrusion detection system should detect a substantial percentage of intrusions while keeping the false alarm rate at an acceptable level. If only a modest percentage of actual intrusions are detected, the system provides a false sense of security. On the other hand, if the system frequently triggers an alert when there is no intrusion (a false alarm), then either system managers will begin to ignore the alarms, or much time will be wasted analyzing the false alarms. Unfortunately, because of the nature of the probabilities involved, it is very difficult to meet the standard of high rate of detections with a low rate of false alarms. In general, if the actual numbers of intrusions is low compared to the number of legitimate uses of a system, then the false alarm rate will be high unless the test is extremely discriminating. A study of existing intrusion detection systems, reported in [AXEL00], indicated that current systems have not overcome the prob- lem of the base-rate fallacy. See Appendix 20A for a brief background on the math- ematics of this problem.
Distributed Intrusion Detection
Until recently, work on intrusion detection systems focused on single-system stand- alone facilities. The typical organization, however, needs to defend a distributed collection of hosts supported by a LAN or internetwork. Although it is possible to mount a defense by using stand-alone intrusion detection systems on each host, a more effective defense can be achieved by coordination and cooperation among intrusion detection systems across the network. Porras points out the following major issues in the design of a distributed intrusion detection system [PORR92]:
- A distributed intrusion detection system may need to deal with different audit record formats. In a heterogeneous environment, different systems will employ different native audit collection systems and, if using intrusion detec- tion, may employ different formats for security-related audit records.
- One or more nodes in the network will serve as collection and analysis points for the data from the systems on the network. Thus, either raw audit data or summary data must be transmitted across the network. Therefore, there is a requirement to assure the integrity and confidentiality of these data. Integrity is required to prevent an intruder from masking his or her activities by altering the transmitted audit information. Confidentiality is required because the transmitted audit information could be valuable.
- Either a centralized or decentralized architecture can be used. With a central- ized architecture, there is a single central point of collection and analysis of all audit data. This eases the task of correlating incoming reports but creates a potential bottleneck and single point of failure. With a decentralized architec- ture, there are more than one analysis centers, but these must coordinate their activities and exchange information.
20.2 / INTRUSION DETECTION 20-
Central manager
LAN monitor (^) Host Host
Agent module
Router
WAN
Manager module
Figure 20.2 Architecture for Distributed Intrusion Detection
A good example of a distributed intrusion detection system is one developed at the University of California at Davis [HEBE92, SNAP91]. Figure 20.2 shows the overall architecture, which consists of three main components:
- Host agent module: An audit collection module operating as a background process on a monitored system. Its purpose is to collect data on security- related events on the host and transmit these to the central manager.
- LAN monitor agent module: Operates in the same fashion as a host agent module except that it analyzes LAN traffic and reports the results to the central manager.
- Central manager module: Receives reports from LAN monitor and host agents and processes and correlates these reports to detect intrusion.
The scheme is designed to be independent of any operating system or system auditing implementation. Figure 20.3 [SNAP91] shows the general approach that is taken. The agent captures each audit record produced by the native audit collection system. A filter is applied that retains only those records that are of security interest. These records are then reformatted into a standardized format referred to as the host audit record (HAR). Next, a template-driven logic module analyzes the records for suspicious activity. At the lowest level, the agent scans for notable events that are of interest independent of any past events. Examples include failed file accesses, accessing system files, and changing a file’s access control. At the next higher level, the agent looks for sequences of events, such as known attack patterns (signatures). Finally, the agent looks for anomalous behavior of an individual user based on a historical profile of that user, such as number of programs executed, number of files accessed, and the like.
20.3 / PASSWORD MANAGEMENT 20-
These systems are filled with fabricated information designed to appear valu- able but that a legitimate user of the system wouldn’t access. Thus, any access to the honeypot is suspect. The system is instrumented with sensitive monitors and event loggers that detect these accesses and collect information about the attacker’s activ- ities. Because any attack against the honeypot is made to seem successful, adminis- trators have time to mobilize and log and track the attacker without ever exposing productive systems. Initial efforts involved a single honeypot computer with IP addresses designed to attract hackers. More recent research has focused on building entire honeypot networks that emulate an enterprise, possibly with actual or simulated traffic and data. Once hackers are within the network, administrators can observe their behav- ior in detail and figure out defenses.
Intrusion Detection Exchange Format
To facilitate the development of distributed intrusion detection systems that can function across a wide range of platforms and environments, standards are needed to support interoperability. Such standards are the focus of the IETF Intrusion Detection Working Group. The purpose of the working group is to define data for- mats and exchange procedures for sharing information of interest to intrusion detection and response systems and to management systems that may need to inter- act with them. The outputs of this working group include:
1. A requirements document, which describes the high-level functional require- ments for communication between intrusion detection systems and requirements for communication between intrusion detection systems and with management systems, including the rationale for those requirements. Scenarios will be used to illustrate the requirements. 2. A common intrusion language specification, which describes data formats that satisfy the requirements. 3. A framework document, which identifies existing protocols best used for com- munication between intrusion detection systems, and describes how the devised data formats relate to them. As of this writing, all of these documents are in an Internet-draft document stage.
20.3 PASSWORD MANAGEMENT
Password Protection
The front line of defense against intruders is the password system. Virtually all multiuser systems require that a user provide not only a name or identifier (ID) but also a password. The password serves to authenticate the ID of the individual log- ging on to the system. In turn, the ID provides security in the following ways:
- The ID determines whether the user is authorized to gain access to a system. In some systems, only those who already have an ID filed on the system are allowed to gain access.
20-20 CHAPTER 20 / INTRUDERS
- The ID determines the privileges accorded to the user. A few users may have supervisory or “superuser” status that enables them to read files and perform functions that are especially protected by the operating system. Some systems have guest or anonymous accounts, and users of these accounts have more limited privileges than others.
- The ID is used in what is referred to as discretionary access control. For exam- ple, by listing the IDs of the other users, a user may grant permission to them to read files owned by that user.
T HE V ULNERABILITY OF PASSWORDS To understand the nature of the threat to password-based systems, let us consider a scheme that is widely used on UNIX, in which passwords are never stored in the clear. Rather, the following procedure is employed (Figure 20.4a). Each user selects a password of up to eight printable characters in length. This is converted into a 56-bit value (using 7-bit ASCII) that serves as the key input to an encryption routine. The encryption routine, known as crypt(3), is based on DES. The DES algorithm is modified using a 12-bit “salt” value. Typically, this value is related to the time at which the password is assigned to the user. The modified DES algorithm is exercised with a data input consisting of a 64-bit block of zeros. The output of the algorithm then serves as input for a second encryption. This process is repeated for a total of 25 encryptions. The resulting 64-bit output is then translated into an 11-character sequence. The hashed password is then stored, together with a plaintext copy of the salt, in the password file for the corresponding user ID. This method has been shown to be secure against a variety of cryptanalytic attacks [WAGN00]. The salt serves three purposes:
- It prevents duplicate passwords from being visible in the password file. Even if two users choose the same password, those passwords will be assigned at dif- ferent times. Hence, the “extended” passwords of the two users will differ.
- It effectively increases the length of the password without requiring the user to remember two additional characters. Hence, the number of possible pass- words is increased by a factor of 4096, increasing the difficulty of guessing a password.
- It prevents the use of a hardware implementation of DES, which would ease the difficulty of a brute-force guessing attack.
When a user attempts to log on to a UNIX system, the user provides an ID and a password. The operating system uses the ID to index into the password file and retrieve the plaintext salt and the encrypted password. The salt and user-supplied password are used as input to the encryption routine. If the result matches the stored value, the password is accepted. The encryption routine is designed to discourage guessing attacks. Software implementations of DES are slow compared to hardware versions, and the use of 25 iterations multiplies the time required by 25. However, since the original design of this algorithm, two changes have occurred. First, newer implementations of the algorithm itself have resulted in speedups. For example, the Morris worm described in Chapter 21 was able to do online password guessing of a few hundred passwords
