Pete Finnigan's Oracle Security Weblog

V3rity is the new company founded by David Litchfield in March 2010 since he left NGS and until recently his site had little on it. I suspected that his new company would focus on Database forensics and I am glad to see my intuition was right!

David wrote a number of papers on Database Forensics in the past that were very interesting and it was clear thart this area has some passion for him. Some of his papers focused on analysing redo and data files for evidence of wrong doing and its clear from David's announcement today that he is developing a product around this space to help people do post breach analysis as he says nothing exists - which to my knowledge, also is true.

Analysing the redo and / or data files - is a good idea if its done out side of the Oracle software as any "use" of the Oracle software to perform breach analysis will also affect the database/data and and in-memory view of the database, in otherwords it ends up like heisenbergs uncertaintly principal. The more you measure the more you will affect the result.

There are some downsides. Reading is not normally recorded in the database other than transiently in memory and also possibly on disk if its captured as part of workload/Statspack type events. The problem for me is that a breach does not necessarily change data or structure. If you want to steal credit cards then read them and write them down. In reality reading credit cards (or indeed any other data) leaves a lot of transient evidence.

As an aside some of what David may be doing can be done with the Oracle software (but certainly not all), for instance LogMiner is a great tool to read archive logs and redo logs as is CDC. The only stipulation would be the need to do the reading and analysys on another database so the primary is not affected.

David announced the tool DDLDUMP on the Oracle-l list today. The post is titled "ddldump" and the tool is closed source and available from http://www.v3rity.com/ddldump.php - (broken link) v3rity. A simple sample run is here:

C:\app\Pete\oradata\ora11gpe>set path=c:\00_v3rity;%PATH% C:\app\Pete\oradata\ora11gpe>ddldump *********************** * * * v3rity for Oracle * * * *********************** Forensically examine Oracle transactions log file (redologs) C:\>v3rity redologfilename action where action is one of: DDL INS DEL UPD Please send comments/bugs to david@v3rity.com {XML output here}

How many of you reading this are DBA's? how many have issues to solve and you turn to the web to find answers or ask and write questions? - quite a few I suspect. When you post to the web do you think about what you are posting? would, what you post make it easier for someone who wants to steal from you do so?

These are important points and are part (in a small way) of what i cover when I perform a security audit of an Oracle database. I was surfing the internet for a specific peice of information last week and came across a post on a web site by someone who had simply listed the contents of V$SESSION BUT this person had taken some steps to conceal some of the details of the result of this query but not enough as it turned out.

I am not going to say whose site it was or give you a link. There are plenty of other sites out there with similar postings that you can review and see what you can learn about their database. What is really important though is the message. Don't post details of your database (or worse your employers database) to the internet or indeed any forum. Someone who wants to steal from you can then get details of your architecture, users, etc without ever logging into your database. This would make it easier to steal from you. In my example, i wrote an email to the person who responded and changed the data to obscure it.

In this particular example, I wanted to point out some of the mistakes this poster made:

1) Her biggest mistake was to identify the company. This really is bad as it gives real value to the rest of the leakages of data that were made. This was done because the person didnt obscure the PROGRAM column output and the output included a full URI including this companies name. I should also point out this person didn't post from a company email address so this was not otherwise available

2) the URI also included an element that could have been the Service name or SID of the database. I asked if this is the case and for this database no but for all their others the answer was yes so this information was also usefull to anyone intent on stealing

3) Some of the Unix accounts were deducable in a number of ways. I knew the persons name from their post so i deduced the naming conventions of their Unix account names. There were others so I knew two things. The naming convention, so if i knew or were able to find a name through a google search I would know a Unix account (50% of the information needed to try and log in - assuming I had access to make a telnet or ssh connection). The second thing was I actually learned employees names from the listing. The person said the Unix names were obscured but only by some letters so if i was a real attacker I would know this after learning some employee names.

4) The Oracle software was installed as "oracle" - So i know also 50% of the information to try and log into the Oracle software account - again assuming I gain access to their buildings or network

5) I could also see a number of people connected as SYS, this was evedent from different OS names and also schemas used. So these connections could also be remote or local. This indicates a problem of password sharing that multiple people know the SYS password - the poster confirmed this was true to me in email. Also more fundamentally it indicates a lack of accountability as a number of people clearly used SYS on a daily basis for non essential purposes.

6) Some of the database users accounts had been obscured by changing the real letters of their accounts to another letter (the same letter). This means that whilst these accounts were long, in normal circumstances brute forcing them would be hard to do. The poster confirmed they have auditing against brute forcing but some knowledge could lead to a small number of attempts being needed to try it. The main pouint was the obscuring didnt work. One account was three letters so there is likely to be 1^26 + 2^26 + 3^26 possible usernames. We can create a dictionary and try these with tools like ora-userenum or simply by brute force connect attempts. The longer usernames were weakened by only obscuring some letters. I was also able to assume something else about their use from the name which was that some of them were for external employees. Some of this was not true as it turned out as the poster did obscure one other feature of the names but someone else may have not done so or may not have obscured at all, so the thinking and ideas are valid.

7) Another username was readable that indicated a certain feature was installed in ths database. This would aid an attackers thinking.

8) The poster didnt tell what the version of the database was but i was able to correctly guess it was 10gR2 simply because of the background processes that were running. This is easy to do in fact as Oracle changes those names with each version. It may not be 100% accurate as another database may not have features installed or processes enabled.

9) the same idea can be used to help determine features used, job scheduling in this case was a good example

I could go further with the analysis. The main issue is be very careful about what you post to the internet or public forums or even private forums. Dont let other people (any that could be fellow employees) know about the details of your database, your set up and your processes and practices. They may use this against you.

One final though that is relevant to this example is that withough connecting to the database I have learned settings I can use in my spoofable SQL*net client where I am able to change settings displayed in the SGA, V$SESSION, SYS_CONTEXT, AUD$ and FGA_LOG$ to spoof my identity and evade audit. Also if a site uses enhanced Oracle security such as VDP, OLS, Secure application roles or even third party audit products where identity is used as part of the rules to detect wrong doing this sort of detail should not be available.

have fun and be careful!

I have just agreed four new public Oracle Security classes to be taught this year. All of the new classes are our very popular two day class "How to perform a security audit of an Oracle database".

These are as follows:

Vienna, Austria - October 20th and 21st
Tirana, Albania - November 10th and 11th
Ljubljana, Slovenia - December 8th and 9th

I will be teaching the classes listed above and I will add the dates and registration links to my Oracle security training page as soon as they are available from the organisers.

The class we did have previously organised in Denver, CO in June 2010 was cancelled by the organiser.

We are now organising a new class in Denver, Collorado that will be taught by Ron Reidy of Reidy Database Consulting on August 19th and 20th and is now being organised directly with the instructors company, Reidy Database Consulting - If you would like to attend this training then please register with Reidy Database Consulting directly or alternately contect myself directly.

I was in Holland the week before last on June 2nd, to speak at the Logica Guro4Pro event at their offices close to Den Haag. This was a nice event with some really great questions and discussions during my talk and also afterwards. My presentation was really about two things, 1) how easy it is in reality to steal data and 2) what is the correct methodology to use to protect your data.

The presentation included 7 demos, some of which going on for up to 15 - 20 minutes. I wanted to demonstrate how exploits work but also how easy it is to steal data realistically or maybe more aptly described as opertunistically. I then showed how to find the true access paths to the data and then showed some stealth attacks against the database. These were based around avoiding audit, hiding your presence and also spoofing. The presentation went down very well indeed and it was fun to do demos that in general worked well!

The slides are available on my Oracle Security white papers page.