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 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 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:
- Oracle 9i TNS 3DES authentication details
- Oracle 10g TNS AES-128 authentication details
- 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 liboracleinternals.py that Joxean tells us just creates Oracle password files. This is interesting as this file doesn't exist in the distro but a file liborainternals.py 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.