http://www.oracleforensics.com

Please see http://www.oracleforensics.com for future posts

Database forensics used to handle the increasing volume of data in an investigation

webmaster March 4th, 2007

(SELECT * FROM ORACLE_SECURITY) INTERSECT (SELECT * FROM COMPUTER_FORENSICS)

I am interested in forensics applied to Oracle databases but also in Oracle databases applied to forensics which is the other half of the INTERSECTION.

Digital investigations are increasingly having to handle very large datasets as confirmed by a recent posting at security focus below.

http://www.securityfocus.com/brief/448

Additionally Advances in Digital Forensics has a great first chapter on dealing with Terabyte Data Sets in Digital Investigations.

http://www.amazon.com/Advances-Digital-Forensics-International-Information/dp/0387300120

The ability of databases like Oracle to handle very large amounts of data is going to be increasingly useful in digital investigations.

Oracle forensics applied to vulnerability detection

webmaster February 28th, 2007

SANS/GIAC have published my new GSOC on using computer forensics concepts applied to vulnerability detection in Oracle databases and it has gained a place in their Reading Room which is quite an honour.
This is the URL for the GSOC and http://www.giac.org/certified_professionals/listing/gsoc.php

and for the Reading Room http://www.sans.org/reading_room/whitepapers/application/

It gives a taste of what to expect from my book that is due out in a couple of months.

http://www.rampant-books.com/book_2007_1_oracle_forensics.htm

David has an interesting new paper that shows how PLSQL injection techniques now only require the CREATE SESSION privilege. Get it here. http://www.databasesecurity.com/dbsec/cursor-injection.pdf

I am now blogging from www.oracleforensics.com which accompanies my new book that is now completed.
http://www.rampant-books.com/book_2007_1_oracle_forensics.htm

All future entries will be made at that URL.

Interesting Payload to PLSQL exploit at Milw0rm

Interesting exploit payload below.

http://www.milw0rm.com/exploits/3177

——————————–

v_commands := 'insert into sys.sysauth$ ' ||
' values' ||
'(' || v_user_id || ',4,' ||
'999,null)';

——————————-

Instead of grant dba to scott the exploit payload inserts the values into sysauth$.

This will bypass many IDS signatures. David mentioned this to me quite a while ago and it is now public so better update those IDS rules.

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