Uso de las TIC en la educación media, de la IE Pablo Sexto

In most organizations, the assets on a network that could be of any use to an intruder are typically protected using combinations of userIDs and passwords. An intruder is therefore going to be forced to try and guess or deduce a useful combination. However, not all userID/password combinations are created equal; some are more useful than others. An intruder would ideally like to capture the account of an administrator, allowing him or her to do pretty much anything he or she wants on any machine that the captured account has administrative rights on. If the administrator's account proves to be unobtainable but a lower privileged account is susceptible, an experienced attacker may still be able to manipulate an improperly configured operating system into granting administrative privileges, a technique often referred to as account escalation. Care should therefore be taken to ensure that not only are the administrators' userIDs and passwords sufficiently protected, but also any lower-level accounts.

WEAK PASSWORD PROTECTION EXAMPLE

Some Web servers provide the Webmaster with the ability to require client authentication (such as the .htaccess and .htgroup files that can be placed inside an Apache Web server directory) before displaying the contents of a directory. Upon requesting a protected directory, the Web server sends a request to the browser, which results in the browser displaying a simple userID/password pop-up window. Unfortunately, the data sent back to the server using this method isn't encrypted (it uses a base 64 conversion algorithm to encode the data) and is therefore extremely easy for an eavesdropper to decode. Web server client authentication should therefore not be relied upon to protect the contents of a directory.

Some system software products use weak or no encryption to store and/or transmit their userIDs and passwords from the client to the server component of the product, affording an eavesdropper with the chance to capture unencrypted or easily decipherable passwords. If the same password used for this service is the same as the password used for an administrative-level account, learning these weak passwords may not only allow an intruder to manipulate the service, but also compromise additional resources.

Although an attacker would like to compromise a single machine, compromising several machines is definitely more desirable. This can happen relatively quickly if other machines (or even entire networks) have previously been configured to trust the compromised administrator account. Alternatively, the LAN administrator may have used the same password for several administrative accounts, thereby making network administration easier, but also increasing the probability that if the password on one machine is deduced, the entire network may be compromised.

Even if different userIDs and passwords are used for each local administrative account and these accounts are granted limited trusts, an entire network may still be compromised if an intruder can get past the security of the machine used by the network for network security authentication, that is, the network controller. Capturing the network controller (or backup controller) allows an intruder complete access to the entire network and possibly any other

and (where possible) enforces a password policy. When defining such a policy, an organization should consider the trade-off between the relative increase in security of using a hard-to-crack password with the probable increase in inconvenience. Policies that are difficult to follow can actually end up reducing security. For example, requiring users to use a long, cryptic password may result in users writing down their passwords (sometimes even putting it on a post-it note on their monitor), making it readily available to a potential attacker walking by. Requiring users to frequently change their password may result in some users using unimaginative (and therefore easily predictable) password sequences, such as password1, password2, and password3. Even if the access control system is smart enough to deduce blatant sequences, users may still be able to craft a sequence that is easy for them to remember but still acceptable to the access control system, such as passjanword, passfebword, and passmarword. As the following sections demonstrate, an intruder could acquire a userID/password combination in several distinct ways.

SINGLE SIGN-ON

Single sign-on (SSO) is a user authentication technique that permits a user to access multiple resources using only one name and password. Although SSO is certainly more user-friendly than requiring users to remember multiple userID's and passwords, from a security perspective it is a double-edged sword. Requiring users to only remember one userID and password should mean that they are more willing to use a stronger and hence more secure (albeit harder to remember) password, but on the other hand, should this single password be cracked, an intruder would have complete access to all the resources available to the compromised user account, a potentially disastrous scenario for a highly privileged account.

Manual Guessing of UserIDs and Passwords

Typically easy to attempt, attackers simply guess at userID/password combinations until they either get lucky or give up. This approach can be made much more successful if the intruder is able to first deduce a legitimate userID.

Obtaining a legitimate userID may not be as hard as you might think. When constructing a userID, many organizations use a variation of an employee's first name and last name. A sample userID format can be obtained, for example, by viewing an email address posted on the organization's Web site. Discovering the real name of a LAN administrator may be all that is needed to construct a valid userID, and that information is easily obtained by acquiring a copy of the organization's internal telephone directory. Or perhaps an intruder could look up the technical support contact posted by a domain name registrar to find a domain name owned by the organization.

Many system software products are initially configured with default userIDs and passwords; it goes without saying that these commonly known combinations should be changed immediately (www.securityparadigm.com even maintains a database of such accounts). What is less well known is that some vendors include userIDs and passwords designed to enable the vendor to log in remotely in order to perform routine maintenance, or in some cases the organization's own testing team may have created test accounts intended to help diagnose problems remotely. If any of the products installed at an organization, such as firewalls, payroll packages, customer relationship management systems, and so on, use this feature, the organization should consider whether or not this remote access feature should be disabled, or at the very least the remote access password changed.

Enforceable Guidelines

ƒ Minimum length of x characters

ƒ Must not contain any part of userID or user's name

ƒ Must contain at least one character from at least four of the following categories:

o Uppercase o Lowercase o Numeral

o Nonalphanumeric, such as !@#$%^&*()

o Nonvisual, such as control characters like carriage return <CR>

ƒ Must be changed every X number of weeks

ƒ Must not be the same as a password used in the last X generations

ƒ Account is locked out for X minutes after Y failed password attempts within Z period of time

Hard-to-Enforce Guidelines

ƒ Do not use words found in an English (or another language) dictionary

ƒ Do not use names of family, friends, or pets (information often known by coworkers) ƒ Do not use easy-to-obtain personal information such as parts of a

o Mailing address

o Social security number o Telephone number o Driving license number o Car license plate number o Cubical number

USERID ADVERTISEMENTS

In an effort to improve customer relations, many organizations have started to advertise the email address of a senior employee, such as "Please email the branch manager, Jon Medlin, at <[email protected]> with any complaints or suggestions for improvement." Although providing direct access to senior management may help improve customer communications, if the format used for the email address is the same as the format used for the user's ID, the organization may also be inadvertently providing a potential attacker with userIDs for accounts with significant privileges.

If an intruder is truly just guessing at passwords, then perhaps the easiest way to thwart this approach is to configure the system to lock out the account under attack after a small number of failed login attempts. Typically, lockout periods range from 30 minutes to several hours, or in some cases even require the password to be reset.

THE NULL PASSWORD

Some organizations have adopted an easy-to-administer policy of not assigning a password to a user account until the first time it is used, the password being assigned by the first person to log in to the account.

Automated Guessing of UserIDs and Passwords

Several tools now exist that can be used to systematically guess passwords; these tools typically employ one (or both) of two basic guessing strategies. The quickest strategy is to simply try a list of commonly used passwords. Most of the tools come with lists that can be added to or replaced (particularly useful if the passwords are expected to be non-English words). Hackersclub (www.hackersclub.com) maintains a directory of alternative wordlists. The second approach is to use a brute-force strategy. As the name implies, a brute-force approach does not try to get lucky by only trying a comparative handful of passwords; instead, it attempts every single possible combination of permissible characters until it cracks the password. The biggest drawback with a brute-force approach is time. The better the password, the longer it will take a brute-force algorithm to crack the password. Table 4.16 lists some sample password-cracking tools.

Table 4.16: Sample List of Password-Deciphering/Guessing/Assessment Tools

NAME ASSOCIATED WEB SITE

Brutus www.antifork.org/hoobie.net Cerberus Internet Scanner www.cerberus-infosec.co.uk

Crack www.users.dircon.co.uk/~crypto

CyberCop Scanner[a] www.nai.com

(dot)Security www.bindview.com Inactive Account Scanner www.waveset.com

Legion and NetBIOS Auditing Tool (NAT) www.hackersclub.com

LOphtcrack www.securitysoftwaretech.com John the Ripper, SAMDump, PWDump,

PWDump2, PWDump3 www.nmrc.org SecurityAnalyst www.intrusion.com TeeNet www.phenoelit.de WebCrack www.packetstorm.decepticons.org [a]

Effective July 1, 2002, Network Associates has transitioned the CyberCop product line into maintenance mode.

Suppose the intruder intends to use an automated password tool remotely—and this approach is thwarted by locking out the account after a small number of failed attempts. To get in, the intruder would need to obtain a copy of the password file. But once that was in hand, the intruder could then run a brute-force attack against the file. Using only modest hardware resources, some tools can crack weak passwords within a few hours, while stronger passwords will take much longer. Skoudis (2001) provides additional details on how to attack password files for the purpose of determining just how secure sets of passwords are.

In theory, no matter how strong a password is, if the file that contains the password can be acquired, it can eventually be cracked by a brute-force attack. However, in practice, using long passwords that utilize a wide variety of characters can require an intruder to spend

several weeks (or even months) trying to crack a file, a fruitless effort, if the passwords are routinely changed every week.

One approach to evaluating the effectiveness of the passwords being selected is to ask the LAN administrator to provide you with legitimate copies of all the password files being used on the production system. From a standalone PC (that is not left unattended), an attempt is made to crack each of these passwords using a password-guessing tool that uses as input a list of commonly used words (this file is obviously language specific). Any accounts that are guessed should be immediately changed.

A second time-consuming test would be to run a brute-force attack against each of these files, since in theory any password could be deciphered given enough time; this test should be time-boxed. For example, any password that can be cracked within 24 hours using modest hardware resources should be deemed unacceptable.

PASSWORD FILE NAMES

Password files on UNIX systems are generally named after some variation of the word password, such as passwd. The Windows NT/2000 family of systems name their password files SAM (short for Service Account Manager).

Particular care should be taken to destroy all traces of the copied password files, temporary files, and generated reports once the testing is complete, least these files fall into the wrong hands.

Even if only strong passwords are used, it still makes sense to try and ensure that these password files are not readily available to an intruder. An organization should therefore consider designing a test to see if an unauthorized person can acquire a copy of these files. Although security may be quite tight on the production version of these files, it's quite possible that backup files either located on the machine itself or offsite are quite easily accessible. For example, the file used by Windows NT/2000 to store its passwords is protected by the operating system while it is running. However, the operating system also automatically creates a backup copy of this file, which may be accessible. A simple search of a machine's hard drive using *sam*.* should locate the production and backup version(s) of this file.

A less obvious place to find clues to valid passwords is in the log files that some system software products use to store failed login attempts. For example, knowing that user Tim Walker failed to login with a password of margarey may be all an intruder needs to know in order to deduce the valid password is margaret. Such log files, if used, should therefore be checked to ensure that the failed password is also encrypted to stop an intruder from viewing these useful clues.

Gaining Information via Social Engineering

Covered in more detail in Chapter 7, social engineering refers to techniques used by intruders to trick unsuspecting individuals into divulging useful information. A classic

topic covered in more detail in Chapter 7), others chose to ignore this possibility. Obvious precautions include ensuring that employees are only granted access to resources they absolutely need, and accounts used by former employees are deactivated as soon as (or before) they leave.

Table 4.17 summarizes some of the checks that should be considered when evaluating the protection afforded to a system's userIDs and passwords.

Table 4.17: System Software UserIDs and Passwords Checklist YES NO DESCRIPTION

□ □ Is there a documented policy in place that describes how userIDs and passwords are assigned, maintained, and removed?

□ □ When an employee leaves (voluntarily or involuntarily), are his or her personal user accounts deactivated and are the passwords changed in a timely manner for any shared accounts that he or she had knowledge of?

□ □ Are the procedures for handling forgotten and compromised passwords always followed?

□ □ Are security access logs monitored for failed logins? For instance, how long or how many tries does it take before someone responds to a legitimate account using invalid passwords?

□ □ Does the system lock out an account for X minutes after Y failed password attempts within Z period of time?

□ □ Are different administrative userIDs and/or passwords used for each machine?

□ □ Have all default accounts been removed, disabled, or renamed, especially any guest accounts?

□ □ Have all remote access accounts been disabled? Or at least have their passwords been changed?

□ □ Are variations of people's names not used when assigning userIDs? □ □ Do none of the critical accounts use common (and therefore easily

guessable) words for passwords?

□ □ Are hard-to-guess or decipher passwords (as defined by the organization's password policy) used for all critical accounts?

□ □ Are the details of any failed login attempts sufficiently protected from unauthorized access?