ORASEC ~ Oracle Security by Paul Wright , London Borough of Sutton

http://www.oracleforensics.com

2007-03-05T04:07:00.000-08:00

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

2007-03-04T15:28:00.001-08:00

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.

2007-03-04T15:26:00.001-08:00

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

2007-02-26T01:10:00.000-08:00

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

2007-02-18T15:17:00.000-08:00

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

2007-01-15T01:19:00.003-08:00

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

2006-12-28T04:49:00.000-08:00

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

2006-12-25T17:26:00.000-08:00

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.