Oracle Password Security and OraBrute ~ New Paper

Oracle Password Security paper and OraBrute ~ SYS AS SYSDBA brute forcing tool
http://www.ngssoftware.com/research/papers/oraclepasswords.pdf
http://www.ngssoftware.com/research/papers/oraclepasswords.zip

Executive Summary of Oracle Paper
------------------------------------------------------------
Three main points to the paper:

1.Can use a greater variety of characters in Oracle password by
"quoting" them and therefore defend against password crackers/rainbow
tables.

2.If you can get password hash and network capture of authentication
then you can calculate the clear text password as per David's new Oracle Hackers Handbook from Wiley. (This is quite serious from a defense perspective imo, as, how do you
know your being hacked if the attacker is using the correct password?).

3.Most powerful Oracle account SYS should be locked and usually is.
**DBA's may not update/strengthen the password on a locked
account**....and...
a)Even when locked, an attacker could still remotely access the SYS account in Oracle by using "SYS AS SYSDBA". This can not be locked out by failed login attempts which is the standard mechanism Oracle use for protecting from brute force in their default accounts.
b)The REMOTE_LOGIN_PASSWORDFILE configuration setting which prevents remote logging on as SYS AS SYSDBA is set to EXCLUSIVE by default which allows remote logging on as SYS AS SYSDBA. i.e. insecure by default.
c)The Oracle Listener allows very quick repeated failed login attempts as SYS AS SYSDBA with differing passwords from different IPs for days without complaining, as I have discovered.

a,b and c mean that an attacker could brute force a typical SYS AS SYSDBA account in a relatively short amount of time especially if the attack is automated from multiple machines using a remote bruteforcing tool.

OraBrute will try about a million attempts from a normal (2GHZ processor) laptop per day.Testing with two laptops resulted in about 2 million in a day. How many attempts the listener will take is flexible depending on how good the server being attacked is, but given that OraBrute can just keep going the attacker would eventually break in IF the DBA has not implemented the securing measures at the end of paper.

Security measures:
I.Long "quoted" password using the extra characters on locked SYS account
II. Test the SYS password using OraBrute as part of the Security Audit.
III. Set REMOTE_LOGIN_PASSWORDFILE configuration parameter setting to
NONE to disallow remote login for SYS AS SYSDBA.

All of the above is tested on 10gr2 Unbreakable Linux default installation which is Oracle's standard now (as well as Solaris 10gR1).
Fix ..
SQL> select value from v$parameter where name='remote_login_passwordfile';

VALUE
--------------------------------------------------------------------------------
EXCLUSIVE

SQL> alter system set remote_login_passwordfile = NONE scope = spfile
--this works on restart.

SQL> select value from v$parameter where name='remote_login_passwordfile';

VALUE
--------------------------------------------------------------------------------
NONE

SYS AS SYSDBA cannot login remotely now so login via OS.

More details in my Oracle Security Course
http://www.sans.org/mentor/details.php?nid=1218
and book
http://www.rampant-books.com/book_2007_1_oracle_forensics.htm

ALTER SESSION BUG DEMONSTRATION

Hey all,
If you would like to see a demonstration of how to GRANT DBA TO PUBLIC as a low privileged user, I have written a short paper which shows you exactly how to do so. It is based on imperva's bug finding and a demonstration I have seen by Alex Kornbrust. You can read the paper here www.orasec.com
Paul

Oracle Password security

On the 27th of November a posting to the DBSEC list at freelists showed
how to gain a users password from a combination of their password hash and a packet capture of their authentication.
http://www.freelists.org/archives/dbsec/11-2006/msg00005.html

There are a significant amount of DBA's in the field who rely on the fact that a high security complex password will make
their Oracle DB secure. Current thinking about rainbow tables
has been that simple passwords on known user names are
beatable but complex passwords with special characters are safe. This is not the case.

There have been a number of ways of gaining access to the password hashes.
Not least of these is the DBSNMP account. Also orapwd utility and many files at the operating system level that are unsecured by default
give access to the hashes.

Having to think about defending against some one with the DBA's
legitimate password is going to be a big change for a lot of peoples
security strategies.

This is going to require closer attention to securing SYS.USER$ table and network communications meaning that privileged SQL*PLUS connections will
now require SSH.

In short, the hashes in user$ should now be regarded as being plain text
when devising a defense plan.