Auditing an Oracle database for security issues is very important. PeteFinnigan.com provides all of the information and tools that you will need Click here for details of PeteFinnigan.com Limited's detailed Oracle database security audit service Click here for details of PeteFinnigan.com Limited's Oracle Security Training Courses
There are 58 visitors online    
Cookie Policy:We only use essential cookies on small sections of this website. For details see here.

Pete Finnigan's Oracle security weblog


Home » Archives » June 2010 » Leaking information about your database to help a hacker!

[Previous entry: "New Public Oracle Security Training Class Dates announced"] [Next entry: "V3rity has released a redo log mining tool to extract DDL from redo logs"]

Leaking information about your database to help a hacker!

June 24th, 2010 by Pete


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!

There has been 5 Comments posted on this article


June 24th, 2010 at 01:08 pm

Marcel-Jan Krijgsman says:

Mildly related, but that made me think of another example of information leakage I found. In an error message:
http://mjsoracleblog.wordpress.com/2010/02/24/what-an-error-message-reveals/
(my brave attempt to start blogging about Oracle security)

I've informed the owners of the site in december, asked them again in march, but they have yet done nothing about it.



June 24th, 2010 at 03:23 pm

Mike Ault says:

Another big leak is the posting of a statspack or AWR report to an open forum.



June 25th, 2010 at 03:42 am

Ron Reidy says:

In this same line is OCM. It is a giant covert channel that dumps a lot of information about your organization and database instances and eventually uploads it to Oracle. This is installed even when you do not want it installed. As far as I have been able to discern, there is no privacy statement about your data, and no auditing of access to this data. Sweet - let's give it up now!



June 25th, 2010 at 10:27 am

Pete says:

Thanks for the comments guys.

Mike:I was aware of the statspack/AWR thing already and its something I ask as part of my security audit.

Thanks for your comment Marcel-Jan, I have imortalised you and added your blog feed to my blogs aggregator!

Ron: you make a good point and its something I have dealt with with a client where we tried to negotiate privacy for their future posts and bug reports to limit the number of people within the vendors organisation who could view the clients data (if reported in the future).

cheers

Pete



June 28th, 2010 at 11:18 pm

joel garry says:

It seems you get higher priority for your SR's if you have an OCM config attached. At least, there is a community posting by a support person that says "In August, we introduced priority handling to all Oracle Database customers. By attaching a configuration when creating a database service request (SR) your request moves to the front of the resolution queue and will be addressed before SRs submitted without configurations. "

I found it slightly ambiguous, but that's probably just me. I do find it supports the paranoia that support is ignoring me on purpose, just because I've turned off OCM. crazy


June 2010
SMTWTFS
  12345
6789101112
13141516171819
20212223242526
27282930   

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.

Weblog Home
Weblog Archives


Home
Oracle Security Tools page
Oracle security papers
Oracle Security alerts

Web Development
SQL Server Security

RSS 1.0 FEED
RSS 2.0 FEED
Atom 0.3 FEED
Powered by gm-rss 2.0.0


Valid XHTML 1.0!