Call: +44 (0)1904 557620 Call

Pete Finnigan's Oracle Security Weblog

This is the weblog for Pete Finnigan. Pete works in the area of Oracle security and he specialises in auditing Oracle databases for security issues. This weblog is aimed squarely at those interested in the security of their Oracle databases.

[Previous entry: "Pete Finnigan's presentation slides available from UKOUG conference"] [Next entry: "January 2009 CPU is out"]

New Year Oracle Security

First of all I would like to wish everyone a belated happy Christmas and a (not belated) very happy and successful new year. Blog entries and writing with a pen have been limited recently as I travelled a lot before christmas not allowing time to write on this blog and then much worse I managed to break my hand falling on ice; suffice to say it will cause me some hassles for some weeks yet whilst it mends (properly!) and typing is painful and writing with a pen hurts.

I wanted to get out a blog entry before the year end as there has been a lot of things happening recently. The UKOUG conference brought a few talks on Oracle security. I mentioned mine in my last post where I posted up the slides on my Oracle Security white papers page. Paul Wright also gave a talk as did Slavik Markovich. Slavik also mentioned his new PL/SQL fuzzer in his talk; Slavik kindly sent me the code a few weeks ago but due to time and now my hand I have not had a chance to play with it yet. Slavik will release it from his blog soon.

There is also a new version of the excellent tool - (broken link) Cain and Abel from Massimiliano Montoro; as an interesting aside, when Patrik Karlsson and 0rm (orabf) in Stockholm recently they picked me up at my hotel and I noticed that there was a cafe/shop next door called Oxid - the same name as the Cain and Abel URL..:-). The new Cain and Abel version has added an 11g password cracker and also AES and DES TNS hash sniffer and decryptors. The changes are listed on the - (broken link) sites main page for version 4.9.25, i guess they won't stay there forever. There are also three papers on the TNS authentication building on Laszlo's work. The links taken from Oxid's topics pages and are:

  • - (broken link) Oracle 9i TNS 3DES authentication details

  • - (broken link) Oracle 10g TNS AES-128 authentication details

  • - (broken link) Oracle 11g TNS AES-192 authentication details

There is also a new version of Inguma written by Joxean Koret, this is the Inguma 0.1.0 (R1) release. From the release notes the only change for Oracle (This is a pentesting toolkit that doesnt just target Oracle but indeed targets a whole range of... well... targets...) is a new library called that Joxean tells us just creates Oracle password files. This is interesting as this file doesn't exist in the distro but a file does exist. I havent tested yet but it seems to be based on the ideas put forward by Paul to write a new password file including a new user added by the attack. Inguma is becoming a big tool and worth watching from the Oracle perspective. As I understood from Slavik, his new fuzzer written in PL/SQL is also based on (loosely I guess) the PL/SQL fuzzer from Joxean.

DannyBoy also sent me a copy of GsAuditor a few weeks ago but due to travel and my hand I have not tested it yet. Dannyboy says that it does around 6 million hashes a second and is not yet multi-core so it should get even quicker.

Alex also recently released a number of presentations recently, “Best of Oracle Security 2008”, A paper from the "Polish Oracle User Group" conference, "DeepSec" in Vienna on reverse engineering applications and a paper from the "iSafe" conference in Dubai.

Finally Paul has an interesting post on Data Leak Prevention. This is an interesting post that simply uses a profile to limit CPU and I/O, whilst this is a good idea this whole area is traditionally fraught with error. The first thing to note is that the initialisation parameter "resource_limit" must be turned on first to allow kernel profile parameters to work. This is awkward as its off by default and confusing as the password paremeters work out of the box without turning this on. Also Pauls statement:

"It is usually the case that DB users do not need to select more than 100 rows in a single statement."

Is simply that; Pauls statement, there is not way we can say that this is true across the board, who knows; I agree with Paul that it sounds logical and common sense but who ever said that vendors or internal projects build logical applications. Also "power users" tend to have access (I dont agree with this sort of access) to production that is often sweeping and all inclusive; This sort of profile would be good to control these people but i think that they should simply be blocked!.

I have worked with a number of clients on profiles that include kernel settings and these have always needed extensive testing in a large number of scenarios often over extended time periods to ensure that no issues arise. BUT, I agree with Paul, a profile limiting CPU and I/O is useful from a security perspective; for me in the cases where a "user" in the database should not exist in my view, but is retained, then profiles provide a good layer in security in depth. As always an interesting idea Paul.

There has been 1 Comment posted on this article

January 11th, 2009 at 02:06 pm

Pete Finnigan says:

Thank you Pete.Your posts are really helpful.