Example Sins

There are lots of examples of password systems with serious risks in them. These problems are so frequent that were somewhat used to them, and are often willing to overlook the risks. For this reason, a lot of applications that may technically violate a security policy (for example, in the financial space, where there are many requirements on password quality, password changes, and so on) wont get cited as being broken in the disclosure community.

Yet, there are still some problems that get raised there and make it into the Common Vulnerabilities and Exposures (CVE) database, http://cve.mitre.org. Well look at a couple of those problems, and then well also look at a couple of examples we consider classic, which illustrate real risks.

CVE-2005-1505

In the mail client that comes with Mac OS X Version 10.4, theres a wizard for setting up new accounts. If you add an Internet Message Access Protocol (IMAP) account this way, it will prompt you to see if you want to use SSL/TLS for securing the connection. However, even if you do, the program has already collected your login information, and logged you in, all without using SSL/TLS. An attacker can eavesdrop on this initial communication and recover the password.

While this is only a risk once, it illustrates the fact that most of the core protocols on the Net were built without any serious security for passwords. Its perfectly acceptable as far as any mail client in the world is concerned to send IMAP or Post Office Protocol (POP) passwords over the network without any encryption. Even if youre using encryption, its acceptable for the receiver to view and handle the unencrypted password. The protocols used are all poorly done, and theyre only remotely reasonable if the user actually uses the SSL/TLS connection, which many environments wont support. In some cases, the password may be stored in the clear, and there will rarely be any effort made to ensure quality passwords by default.

The Internet was certainly designed in more trusting times. Passwords are a huge vector for gaining unauthorized access to resources, so please dont be as cavalier about your designs as our Internet forefathers were about theirs.

CVE-2005-0432

This is a simple, documented example of a common problem. BEA WebLogic Versions 7 and 8 would give different error messages for getting the username wrong than for getting the password wrong. As a result, an attacker who didnt know much about a particular user base could still identify valid accounts, and then start brute-force guessing passwords for those accounts.

The TENEX Bug

A far more famous information leakage occurred with the TENEX operating system. When a user sat down to log in, the system would collect a username and password. Then, it would try to validate the password using an algorithm like this:

 for i from 0 to len(typed_password):  if i >= len(actual_password) then return fail  if typed_password[i] != actual_password[i] then return fail if i < len(actual_password) then return fail return success! 

The problem was that an attacker could put candidate passwords in memory overlapping page boundaries. If the attacker wanted to see if the password started with an a, he could put a on one page and xxx on another. If the password started with an a, there would be a page fault while the next page was loaded, but if the guess was wrong, there wouldnt be. Normally the delay would be slight enough that it would require statistics and many trials to measure. But a clever attacker could lay candidate passwords on page boundaries. In this case, when a character right before a boundary was guessed correctly, the virtual memory manager would cause a page fault when seeking the next character, and the resulting time delay was incredibly obvious. This took the attack from the realm of those who understand statistics to being easy for anyone who knew the trick.

Even without the page fault problem, one could have used timing and statistics to do the same kind of thing, though it would take some automation to break. This attack is one of the many reasons why respectable login systems use cryptographic one-way functions to process passwords.

The Paris Hilton Hijacking

In early 2005, it was major news when someone hacked Paris Hiltons T-Mobile Sidekick cell phone, releasing its contents to the Internet, including contact information for a number of celebrities . In reality, it wasnt her phone that got hacked. The Sidekick architecture stores copies of a lot of data server side, largely so it can be available to the subscriber over the Web and via phone. The attacker was able to get onto her online account and download information through the web interface.

How did this happen? Apparently, the attacker somehow figured out what her user- name was, and then went to the web site, claiming to be that user, and also claiming to have forgotten the password to the account. The system handled resets by asking a personal question, where the answer is set when you create the account. If you get the answer correct, it lets you change the password on the spot.

Hiltons reset question supposedly was, What is the name of your favorite pet? Apparently, she has been on TV with her dog Tinkerbell, and the attacker knew this. It was the right answer, and thats probably how he got into her account. The lesson here is that the personal information used in password resets is often easy to obtain. Its better just to e-mail the person a new password, or, in this case, send the new password to the users phone via a text message. While e-mail isnt a very secure medium, it adds another hurdle for attackers , as they also need to get in a position to eavesdrop on someones e-mail. That may be a possibility when the attacker has access to the local area network from which someone reads e-mail, but it would still have helped Hilton.