In the most recent of Oracles security woes, Joshua Wright of the SANS Institute and Carlos Cid of the Information Security Group at the University of Londons Royal Holloway college on Wednesday gave a presentation on their findings at the SANS Network Security conference in Los Angeles.
The duos paper, "An Assessment of the Oracle Password Hashing Algorithm," calls for Oracle to bolster its password hashing mechanism.
As it now stands, malicious users can recover even strong, well-constructed passwords within minutes, the researchers have found.
It is only the most recent of a long run of security embarrassments for the database company that cooked up the marketing tag "unbreakable"—a brag that it has quietly stepped back from ever since its inception.
In the past few years, security researchers have complained that Oracle has sat on vulnerabilities for unforgivably long stretches of time; that Oracles opatch utility is misleading enterprises regarding their patch levels; and that its quarterly CPUs (Critical Patch Updates) have consistently failed to fix the problems they were meant to fix.
Oracle on Friday evening e-mailed a statement saying that "Security is a matter we take seriously at Oracle and, while we stand firmly behind the inherent security of our products, we are always working to do better."
The statement went on to give details on the password hash weakness and to stress that access to a table containing password hashes should be strictly controlled.
"The paper published by SANS exposes the location in the Oracle data dictionary where the Oracle password hashes are stored," the statement reads. "By default, access to this table is restricted to a limited number of highly privileged database users. As recommended by Oracle, access to the Oracle DBA role; the SELECT ANY TABLE privilege; and the SELECT ANY DICTIONARY privilege should be tightly controlled."
Oracle also said that the weaknesses can be mitigated by good password management. "We feel strongly that the issues noted in the paper can be addressed through good password policy management, which dramatically reduces the inherent security risks associated with any password-based authentication system, and through use of security features included with the Oracle database, such as facilities to enforce password complexity, account lockout after multiple login failures and password expiration," the statement said.
"Good enterprise password policies will dramatically reduce the inherent security risks associated with any password-based authentication system," Oracle said.
Wright and Cids research has revealed that Oracles password handling has multiple weaknesses: weak password salt selection, lack of alphabetic case preservation and a weak hashing algorithm.
Salt is a small, usually random value used in conjunction with a password to generate whats called a password hash. Salted passwords that are long enough work to gum up attacks that use automated lookup with password dictionaries, since it becomes impractical to compute a large table of hashes that correspond to possible passwords and salt value combinations in advance.
Oracles password hashes join user names to passwords before calculating the hash—a non-conventional method for salt selection. The researchers found a number of weaknesses with this unorthodox method.
One such weakness is that its possible to crack a user password thats based on a hash value and another users known credentials. By inspecting password hash values from the dba_users table, the method of salt generation is quite easy to ascertain, as the researchers demonstrated in an example, partially recreated here:
SQL> create user Oracle identified by password;
SQL>create user Oracl identified by epassword;
SQL>select username, password from dba_users where username like ORACL%;
The researchers discovered another salt weakness in the use of non-random salt values. While the salt can still slow down a precomputed dictionary attack against a large password hash table, an attacker is still capable of precomputing a table of possible passwords using a common username, such as SYSTEM.
Oracles password protection hashing also lacks alphabetic case preservation. Before it calculates a password hash, the hashing mechanism converts a users password to all uppercase, regardless of how it is input.
This weakness reduces the number of possible passwords an attacker has to sift through in order to find an effective one. It also means that enterprises are less secure than they might assume when it comes to the quality of their passwords, the researchers said.
When it comes to Oracles hashing algorithm, which Oracle doesnt openly document, the researchers nonetheless found ample online and printed references to enable them to reproduce it.
For example, they found a 1993 post on the comp.databases.oracle newsgroup that described the algorithm in detail, identifying an unknown fixed key as an input parameter. That unknown key value was later published in the book "Special Ops."
The researchers go on to describe the algorithm in their paper.
Although they didnt discover cryptographic weaknesses in the algorithm, the researchers identified what they call a "significant computational weakness" in that Oracles one-way algorithm requires a scant amount of DES encryptions to compute a hash value.
Passwords have several options to obtain password hashes, the researchers said. They can capture unencrypted Oracle TNS (transport network substrate) traffic, or they can exploit vulnerabilities in applications that permit SQL injection.
If an attacker has local access to the databases operating system, he or she can also examine the SYSTEM tablespace file or the oraPW file with a tool such as the Unix strings utility to locate password hashes and associated user names.
Once an attacker discovers one or more user names and password hashes, they can then use the hashing algorithm to mount an attack to recover user passwords.
To protect Oracle databases, the researchers recommend strong password selection policy and appropriate restriction of access privilege.
Beyond that, enterprises should use non-privileged users for Web applications, giving only minimum privileges to run the application. Users that are members of the DBA group shouldnt be allowed to run Web applications exposed to public or less-privileged users, they said.
The researchers also recommend using a tool to help identify users who have access to tables in which password hashes are stored. They recommend one such as who_can_access.sql, created by Pete Finnigan, a noted security researcher.
They also suggest auditing the SELECT statements in the DBA_USERS view that can be used to obtain password hashes. Encrypting TNS traffic—an option included in the Oracle Advanced Security package for Oracle Enterprise Edition—is also a good idea, they said. Those who are running other editions can still use SSL tunneling features with tools such as OpenSSH or stunnel.
Wright and Cid also recommend enforcing a minimum password length—the length of which is dependent on whether attackers have resources such as optimized DES-cracking hardware—and a password expiration date that lapses at or before 60 days.
Editors Note: This story was updated to include Oracles statement.