Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Usenet -> c.d.o.server -> Researcher: Oracle Passwords Crack in Mere Minutes: break the unbreakable?

Researcher: Oracle Passwords Crack in Mere Minutes: break the unbreakable?

From: <teraknowledgesystems_at_hotmail.com>
Date: 30 Oct 2005 01:38:09 -0800
Message-ID: <1130665089.878687.239220@g49g2000cwa.googlegroups.com>


Researcher: Oracle Passwords Crack in Mere Minutes

By Lisa Vaas
October 28, 2005

 Attackers can easily crack even strong Oracle database passwords and gain access to critical enterprise data because of weak password protection mechanisms, researchers have warned.

In the most recent of Oracle's security woes, Joshua Wright of the SANS Institute and Carlos Cid of the Information Security Group at the University of London's Royal Holloway college on Wednesday gave a presentation on their findings at the SANS Network Security conference in Los Angeles.

The duo's 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 Oracle's 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 had not responded to a request for comment by the time this story was posted.

Wright and Cid's research has revealed that Oracle's 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 what's 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.

Oracle's 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 it's possible to crack a user password that's based on a hash value and another user's 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; User created.
SQL>create user Oracl identified by epassword; User created.
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.

Oracle's password protection hashing also lacks alphabetic case preservation. Before it calculates a password hash, the hashing mechanism converts a user's 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 Oracle's hashing algorithm, which Oracle doesn't 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 didn't discover cryptographic weaknesses in the algorithm, the researchers identified what they call a "significant computational weakness" in that Oracle's 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 database's 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 shouldn't 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. Received on Sun Oct 30 2005 - 03:38:09 CST

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US