Pete Finnigan's Oracle Security Weblog

I saw today that NGS have released a paper "Oracle Passwords and OraBrute" that talks about various weaknesses in Oracle passwords. Most of this is not new and is covered elsewhere. The first issue covers the fact that Oracle passwords can include most of the character map with passwords encased in quotes, i.e. the password is more complex and harder to crack with a crackre like orabf or by rainbow cracking. There was a good post about this on my forum over a year ago titled "Valid characters for Oracle passwords?..." that discussed the issues around the character map. The second area is around the fact that passwords can be grabbed off the wire if the hash is know. I talked about this here recently in a post titled "Stealing Oracle passwords from the wire" that talks about David Litchfields work in this area. The main thrust of the new paper is around the fact that the AS SYSDBA connections cannot be locked out using password management or account locking. I talked about this on my site (prior to the blog) on 02 April 2004 in a paper titled "can SYS be locked out by a failed_login_attempts setting".

All of that said the paper is worth reading, the advice from me is prevemnt remote AS SYSDBA connections by setting remote_login_passwordfile to the recommended value of "none" - this can be an issue if OEM is used as it needs EXCLUSIVE. Also set listener logging and parse the log file for brute forcing of AS SYSDBA connections. Also parse and manage the trace files created in $ORACLE_HOME/rdbms/audit - a seperate trace file per pid will be created. on Windows the records are written to the event log. All AS SYSDBA connections are logged to these trace files. If audit_file_dest is set then the location will not be the default. The paper includes a brute force tool that I dont see much use in an audit situation. A cracker like orabf is better and faster to test hashes in SYS.USER$ and also in the password file and a check for remote_login_passwordfile is quicker and more effective. Also check which users have been granted SYSDBA as they would alwo be affected in the same way. Their passwords for AS SYSDBA connections can be read from the password file as well.