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

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.

.

Quantcast