Pete Finnigan's Oracle Security Weblog

I was at the UKOUG UNIX SIG in Thames Valley park - Oracle's UK headquarters a couple of days ago, wednesday the 8th September to do a two part talk for the SIG. Of course my two talks were on Oracle Security and i felt went down really well. there was some good feedback and lots of discussions after the first part and all through lunch and I met a lot of nice people. I had to shoot off straight away after the second talk to a meeting so no time for questions/chat afterwards but all attendees are welcome to email with any further questions.

The two talks were around my favourite hobby horse, which is securing data - note I said securing data and not the database software - this is a very important as its impossible to secure your data unless you know where it is. That means all copies, all access paths to it and also you must know how it leaves the database. If someone wants to steal your credit card details and you have hardened your production database BUT you copy that data to test or dev or you print out reports and leave them on unsecured desks or you send reports to your suppliers or.... you get the picture. You must know where all copies of the data are and then you must know who (job descriptions, processes and people) can access that data. Armed with that knowledge you can start to secure the data.

The talk included quite a few demos that started with a basic exploit typical of that you can download. The point being that its easy to download and easy to execute BUT, if the exploiter has little knowledge of techie things (Oracle or the application) for instance then what does he/ she do next? This really says that your internal people who have technical knowledge pose a bigger threat than those that dont. I then did a demo that is more realistic, i.e. use your existing user account or guess an account and take advantage of bad design and access the data. This is the reality in real life. I then did a demo discussing what evidence was left by these two simple attacks. The bottom line is that unless you have pre-thought out your audit strategy then either you will have little or no audit trail or you will not be auditing whats needed to capture the attack. The second part to this is that unless there is some trigger to tell you that you have a security problem you dont even know what to look for.

Evidence trails are even more powerful for the attacker as he will guess you dont know who does what and he will check out what you can log and where the data really is and take a route to the data that doesnt log anything meaningful. Also he could spoof some or most of his identity. I demonstarted a simple stealth exploit by showing current connected users details in the database and then showing a simple Java JDBC client that I have created that spoofs identity in the database on demand. We also looked at reviewing data access to find out how the data has been copied and also to identify the access paths to the same data. Finally we looked at reviewing user accounts in the database and assessing the privilege levels.

The two part Oracle Security presentations are available on my Oracle Security white papers page. Also because last time i did a demo based talk someone asked me if it had been video'd or if anything else was available. This time i have written down the steps I took with names of scripts etc. Not all detailed steps mind you! but its better than nothing. The document is also included in the download in the Oracle Security white papers page.