In-Depth

Oracle Database Passwords Vulnerable to Attack

Using a password hash, attackers can crack a database in about four minutes

• By Mathew Schwartz
• 11/01/2005

Oracle database users, beware: Oracle databases are vulnerable to exploitation due to a password hashing algorithm weakness.

Those weaknesses are detailed in a new paper, “An Assessment of the Oracle Password Hashing Algorithm,” co-authored by two security researchers: Joshua Wright, the deputy directory of training for the SANS Institute, and Carlos Sid at the University of London. The paper also presents a tool for exploiting the vulnerabilities.

The newly disclosed Oracle database Achilles' heel includes a weak hashing algorithm, poor preservation of alphabetic case, and weak password salt selection. Salt refers to the Unix technique for associating a password hash with a “small, usually random value called salt,” note the authors. “The salt does not need to be kept secret, and it is used together with the password to generate the password hash.”

In general, using “salted passwords” doesn’t make it easier for attackers to break into databases by using offline, dictionary attacks. Even studying a sufficient number of salted passwords doesn’t allow attackers to reverse-engineer passwords, since even users with the same password would have different salts, and thus different password hashes. Therefore as long as the salt is of sufficient length, “it becomes impractical to compute a large table of hashes corresponding to possible passwords and salt values in advance,” they note.

Oracle database security suffers because “Oracle password hashes use a non-conventional technique for salt selection by pre-pending the username to the password before calculating the hash.” In other words, salts are not sufficiently random. Therefore, “it is quite possible to obtain information about a user password based solely on its hash value and the known credentials of another user.”

Furthermore, before calculating a password hash, Oracle databases first convert a user’s password to uppercase characters. “This behavior represents a significant weakness in the password hashing algorithm, as it reduces the number of possible passwords,” they say. “Another effect is that many organizations that require a mix of uppercase and lowercase characters in passwords may have a false sense of security regarding the quality of database passwords.”

Four-Minute Password Recovery

How vulnerable are Oracle databases? To exploit the vulnerability, attackers must first obtain an actual password hash from the database. “Obtaining this information can be done in a number of different ways, requiring access to the system or another attack vector,” such as accessing backup tapes, the host operating system, or conducting a SQL injection attack, notes SANS.

If an attacker is able to analyze a database offline—say, by using stolen backup tapes—then with a standard workstation, recovering the database’s plain-text password would take about 20 days. As researchers note, “this is especially problematic for organizations with a password expiration duration that is shorter than 20 days, since it is likely an attacker will be able to produce the plain-text password before the account password is changed.”

Once an attacker possesses a password hash from the database, however, drawn-out offline attacks aren’t the only option. That’s because the method Oracle databases use to create password hashes is publicly known. Therefore, attackers can conduct the time-consuming work of generating all possible hashes—and which plain-text password they equal—up front, then storing the results in files (known as rainbow tables) for later reference. (While using salts generally precludes this kind of attack, Oracle databases’ weak salts don’t qualify.)

Once an attacker obtains a password hash from a database, cracking it would be a matter of searching for the hash in the already generated rainbow tables. Using this technique, for 98 percent of Oracle database password hashes tested, the security researchers were able to recover a plain-text password in about four minutes.

Guarding Against Resulting Attacks

To guard against attacks exploiting these vulnerabilities, Wright and Sid recommend security managers “restrict access to password hashes.” Furthermore, audit who has permission to view the password hashes for local database accounts.

To defend against SQL injection attacks, give users of Web applications only the barest of access privileges, so if their account is exploited, attackers will be able to do less damage, and not gain administrator-level access.

Finally, require passwords of sufficient length to make these types of attacks difficult. As a starting point, they recommend 12-character passwords set to expire every 60 days.

Related Article:

Database Security Requires a Multi-Pronged Approach
http://www.esj.com/Security/article.aspx?EditorialsID=1347