Password Cracking

One popular means of breaking into computers is to obtain legitimate users' passwords through illegitimate means. This task can be accomplished in several different ways:

Social Engineering Many social engineering attacks are aimed at acquiring a password. These attacks may not technically be password cracking, but they create the same effect—compromised accounts.

Network Password Interception Some types of network probes enable attackers to monitor traffic on a local network, as described in the next section, "Scanners and Sniffers." One of the features crackers look for is unencrypted passwords, as used by protocols such as Telnet and the File Transfer Protocol (FTP). One excellent defense against this threat is to use encrypted protocols, such as the Secure Shell (SSH), rather than unencrypted protocols. Another measure that can help, but that is less effective overall, is to use network switches rather than network hubs to connect computers. Switches don't echo data except to the target computer, so a miscreant must have compromised the sending or receiving computer to monitor data when the network uses a switch.

Dictionary Attacks The type of activity that's most commonly meant by the phrase password cracking is discovering the original password from an encrypted form. Linux stores encrypted passwords in /etc/shadow (older systems used /etc/passwd). If a miscreant obtains a copy of that file, it's often possible to extract a few passwords by using a dictionary attack— encrypting every word in a dictionary using the same algorithm Linux uses and looking for a match to a stored encrypted password. The upcoming section, "Choosing Good Passwords," describes how to create a password that's both resistant to a dictionary attack and memorable to the user.

Note Linux stores its passwords using what's known as a one-way hash, meaning that it's theoretically impossible to obtain the original input from the hashed (encrypted) form. When you type a password, Linux hashes it, and if the new hash matches the one it's stored, Linux gives you access. As a result, crackers can't technically decrypt passwords, but they can stumble upon them through a dictionary attack. On the other hand, encryption protocols such as SSH require that the data they transmit be recoverable at the other end. Therefore, if a cracker manages to decrypt such a data stream, a password sent via that stream could be recovered directly, without using a dictionary attack.

Crackers frequently try to obtain the passwords for ordinary user accounts. Many users think that such access isn't terribly important; "after all," a casual user might reason, "there's no sensitive data in my account!" Even if an account holds no sensitive data, crackers cherish such accounts because they can serve as launching points for further attacks. These attacks may be against the same computer—for instance, the cracker might exploit vulnerabilities in local software to acquire root privileges. Further attacks might also be against other computers—crackers often use network clients to attack third parties, using the compromised computers and accounts as shields to protect their identities. In fact, a small site is far more likely to be compromised to be used as a stepping stone in further attacks than to get at data on the site's computer itself. Crackers may also be interested in personal vendettas. A cracker who breaks into an individual's account can easily send offensive e-mail from that account, for instance, making the e-mails look very legitimate.

Many servers restrict network access directed at root. For instance, most Linux systems' Telnet server configurations don't permit direct logins as root. This practice reduces the odds of a successful breach of the root account; to break in via password cracking, the miscreant must have both an ordinary user password and the root password. Some servers do permit direct root logins, though. For instance, many distributions ship with their SSH servers configured to permit root logins. Whenever possible, you should change these configurations to be more restrictive. (In the case of SSH, check /etc/ssh/sshd_config and change the line that reads PermitRootLogin yes to read PermitRootLogin no, and be sure that line isn't commented out.)

0 0

Post a comment