July 27th, 2010 by Pete
I wrote about the first IOUG joint security survey with Oracle two years ago here in my blog in a post titled "
An Oracle Security Survey by The IOUG and Oracle" and I encouraged participation on the survey. The second survey is now available now. The survey is worth while as its your chance to influence the security assurance team within Oracle and also to help get some idea of whats going on in the community. The offiial text for the survey is:
Oracle and the Independent Oracle User Group (IOUG) are launching a new security assurance survey. The purpose of this survey is to gather feedback from as many organizations as possible about their security patching practices and to identify which security assurance topics are most relevant to Oracle customers.
The IOUG participates in Oracle’s Secure Customer Advisory Council and has worked with Oracle Global Product Security on this survey which will provide meaningful feedback to Oracle about its security programs. For example, the current survey provides respondents with a chance to give feedback about Patch Set Updates (PSUs) and the CPU documentation. Survey responses will be kept confidential, and the results will be analyzed jointly by Oracle and IOUG to evaluate Oracle’s security assurance practices The survey is located here http://enterprisesig.oracle.ioug.org/ (free SIG membership is required to access the survey).
As I did two years ago I encourage everyone to take part and add some influence to the security patching process. Thanks!
[
No Comments]
July 14th, 2010 by Pete
Oracle yesterday released the latest in its series of quarterly security patches known as CPU's Critical Patch Updates.
Oracle released an advisory detailing the fixes. The patch set contains 59 new security fixes. For me the interesting part are the fixes for the database; 13 in all, 6 of which are for the database server itself and 4 of which may be expolited remotely without authentication. The other interesting thing is the amount of names credited on the advisory. i have not counted but its probably the most i can remember. what does this actually mean?, on the simplest level it means many more people are now interested in and doing someting about database security which has to be a good thing. As always Oracle recommend that you apply this as soon as you can. With remotely exploitable bugs / vulnerabilities this should be obvious.
[
4 Comments]
July 7th, 2010 by Pete
I have just added another public training date to my upcoming Oracle security trainings calendar. This is for November 4th and 5th in Tallinn, Estonia which I am really looking forwards to.
I have also just agreed to do two 45 minute presentations at the up-coming UKOUG Unix Sig at Oracle in Readings Thames Valley park on September 8th 2010. The talk will be based on two major areas; the first is understanding the true risk to your data, where the data is and how easy it is to steal in the real world. The second is looking at how to assess the access to your data. The talk is also split into two sections so should be fun. There will be lots of demos and real world experience.
[
No Comments]
July 1st, 2010 by Pete
I did a session at the Logica Guru4Pro event a few weeks ago and posted the slides to my site on my
Oracle security white papers page. I also talked about this in my blog in a post titled "
New Oracle Security presentation available".
After that post Alex skyped me to ask me what I meant in slide 33 where i said "11gR1 has broken this with the default sid/service name feature". In slide 33 i am talking about what i call the "Access Issue", i.e. to access a database at the TNS level, say through SQL*Plus you need certain information; IP Address/Hostname, port, service name/SID, usrername/password. In real life most sites make this information available simply by
shipping some of this information to the desktop. Most sites I have been to, usernames and passwords are guessable so in most cases its easy (if you try) to connect to a database.
If one of the peices of information; the service name is no longer necessary then in my opinion that reduces the security of the database in that it makes it easier for anyone to attempt access. When Alex skyped me i described the meaning of this to him but couldnt find a link. Alex skyped me again last night to say he had found a link. The
DEFAULT_SERVICE_{listener name} expects a fully qualified service name. This parameter of the listener.ora file is not turned on by default. So by default 11g security is not weakened. If you use this new parameter you are weakening security of your database as you are allowing people to attempt to connect without finding out one of the key peieces of information necessary to do so.
[
5 Comments]
June 29th, 2010 by Pete
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
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}
|
[
No Comments]
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!
[
5 Comments]
June 17th, 2010 by Pete
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.
[
2 Comments]
