Pete Finnigan's Oracle Security Weblog

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!