Call: +44 (0)7759 277220 Call
Blog

Pete Finnigan's Oracle Security Weblog

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.

Talking, Training and statistics

I added some code to my site quite a while ago that indicates the number of visitors on-line at the current moment in time. It was for a bit of fun partly and also so that I could guage the response to new posts and to see basically longer term where my time on the site is best spent as lately I don't have much spare time to spend on the site. It is not fantastically accurate for one reason - This is because not all pages of the site are instrumented. There are indeed quite a lot that are not and because of this the figures are not accurate. They are not incorrect (i.e. false positive) in terms of a false high as those visitors on-line are accurate for the ones captured, its just that the true number will always be higher simply because not all pages have the code on them. Anyway I saw a new "high" by chance yesterday and saved a screen dump. It's here:

Number of visitors on-line at PeteFinnigan.com

It's fun to see a lot of people interested to read something i have written.

I have also updated my Oracle Security site front page section to include new upcoming talks that i will be giving. I am going to be in London on the 17th June, Newcastle on the 19th June, London again at a special archive and purge event on July 15th and also in Iceland on September the 12th.

I have also made some updates to my Oracle Security Audit 2 day training class page to include a list of the currently agreed public training days for this class. Normally I sell this class to companies and go and give the training to their staff at their site. These public dates are great as anyone can sign up and come and get the training. The course detailed agenda is on the page also as are details of the course structure and contents.

Every delegate gets a certificate to signify that they have attended the class.

The public dates are:



  • July 22nd to 23rd - London - With Delaney Consulting

  • August 26th to 27th - London - With Siemens Insight Consulting - Please mention PeteFinnigan.com Ltd when booking directly

  • November 3rd to 4th - Holland - With Oracle University

  • November 19th to 20th - Sweden - With Oracle University

  • December 9th to 10th - Germany - With Oracle University

  • December 15th to 16th - Norway - With Oracle University




If anyone is interested to attend any of these training dates then please don't hesitate to get in touch with me in the first instance. Email address is on the training page.

Read only Tables or Read only users

I saw a post by Richard Foote a few days ago and made a comment on the blog entry and also made a note to chat about it here. Richards post is titled "Read-Only Table Before 11g (A Day In The Life)" and is quite an interesting post related to an attempt to create a read only table in a database. This is something I have spoken about here a number of times in the past and I have also spoken about the creation of read only users (in the same area as read only tables). There is a link shortly in my comment below that takes you to most of my own past posts, here is the comment, repeated here:

"Interesting post. I had a number of posts on my blog over the years about read only tables. Some of which linked to no longer existing HJR posts/articles. I won’t go into the details of methods of making “read-only” tables but I do have a couple of important points to make.

The first is the need for so-called read only tables, why? - these are often created to allow developers into production or for support people (slightly better but not much) to allow analyis of issues in the database against prod data. Your example above would not support this anyway as it involves dropping the original data. I don’t recommend access in these cases.

The second issue is that if you create a so called “read-only” users - lots of details here - http://www.petefinnigan.com/weblog/archives/00000166.htm. the big issue is that even if you create a user with just CREATE SESSION and maybe select privileges (or some ideas like above) on certain production data (tables) then because of the PUBLIC issue in 10gR2 they have 21,000 other privileges, in 11gR1 27,000 other privileges. In this sense there is no such thing as a read only user or indeed read only table (because of this). disallow access is the best option."


I liked Richard's post but wrote the comment because the major point i wanted to make is "WHY", OK, there are plenty of potential how's and Oracle are even helping in 11g but WHY, Why does anyone need read-only access? If we limit the question to production databases I am often told that developers dont have access to a particular production database that i am performing an Oracle database security audit on but I then find evidence that this is not the case and developers are indeed given access. When questioning the client, I often get a response of

"Ahhh, that account is for "" who is our super special employee / developer / tester who is able to fix every issue we have."


hmmmm... I often say. That means developers do have access to production and they often have sweeping access to system privileges, database objects and more. This implies a complete lack of change control and access controls. Even when this type of sweeping access is not there, often there is a token role or account (often shared amongst many people) who has "read-only" access to the customer schemas and data. There is the major issue I raised about that in 11g at least for a so-called "Read-only" user he also has approximately 27,000 other privileges because of grants to PUBLIC. This is the killer issue as because of this it is in fact not possible to create a read-only user.

The second issue around developer or indeed anyone else getting access to the production data is the fact that at least in most businesses in the UK (and othe countries) they should not have access to the data in the first place, i.e. in simple terms peoples data should be accessed and used only by those who need to use it. Bug fixing and problem resolution is a grey/sticky area, do they need to see it or not? - my view is always to try and resolve bugs out of production and not using production data. That is another thorny subject! - moving data from production to development and test systems without any obfuscation of any sort..

data protect

Oracle Authentication Process and password algorithm

I found a useful paper on a site a few weeks ago when looking for new sources of Oracle default passwords as this paper had a link to my Oracle default password list in it. The upshot is I made a note of it and to talk about it here and today I noticed Paul had also found it. smile

The paper is titled Oracle Authentication and it includes a detailed discussion of the Oracle password algortithm including an implementation in python. I am not sure how fast that would be (haven't tested it against tools such as woraauthbf which is written in C and includes the source code and is extremely fast. A new version on woraauthbf is due out soon with some new features, I have been testing it for Laszlo, watch this space for an announcement of when its available.

Back to the paper; this paper explains the algorithm and also delves into the TNS packets that are sent to the server as part of the O3Logon process. The paper concludes with some details of attacks against the protocol including version divulgeing and also user enumeration.

I have talked here about the 11g password algorithm, including a simple PL/SQL script that implements the 11g password algorithm and also a discussion of weaknesses in the 11g password algorithm. There are plenty more discussions here around the Oracle password algorithm, use a simple query on google for site:www.petefinnigan.com Oracle password algorithm to locate some of them.

Howard's DORIS script is available again - some security comments from me

I noticed today that Howard's Dizwell-Oracle Reliable Installation Script (DORIS) version 1.0a shell script is available again for download. This is a useful script and great for installing Oracle on Linux without resorting to reading loads of "how-to" sites.

Howard also made some brief notes available in his blof entry titled "Doris redux" and includes there a note that the reader/user of the script can edit themselves to change the default DBNAME used of lin10 or lin11. I posted some further comments that may be useful to anyone that should download the script if they are particularly interested in security. This is repeated here as for completeness

"I see in your brief notes that the user of the script is advised to change the default database name assigned by the script, i.e. lin10 or lin11. This is important as there are a number of "guesser" tools out there and it wont be long before lin10 and lin11 are added to their dictionaries, they are in mine already.

Also worth pointing out for your readers is the usefulness of changing the software owner name from "oracle" - this would require editing of the doris script of course by the reader. This is importnat. I do a lot of database security audits for clients and I am seeing an increasing number of attempts to connect to servers by guessing the OS username of "oracle". Default names give attackers a head start, unfortunately.

The same, but to a much lesser extent applies to the default name "dba", obviously it cannot be an advantage to guess it, but the script could be improved to allow the segregation of duties afforded by the creation of an OSDBA and OSOPER Unix/Linux group. I have to say I never see any database where this is done, having the OSOPER group/alias allows the creation of an OS account that can be assigned this group, who can then stop and start the database but is actually only connected as PUBLIC not SYS. Its easy to fix after the fact also by editing the $ORACLE_HOME/rdbms/lib/config.c or .s (Real Unix) and relinking."

License Plate scanners and SQL Injection

I posted a couple of days ago a link to an almost certain hoax of a license plate of a red mini that had been altered to include SQL Injection. This was in a post titled License Plate SQL Injection.

It was interesting to see that Bruce Schneier's crypo-gram newsletter also included reference to the same license plate SQL Injection hoax but also it included a link to an article by Bruce titled "City Cops' Plate Scanner is a License to Snoop" which starts:

"New Haven police have a new law enforcement tool: a license-plate scanner. Similar to a radar gun, it reads the license plates of moving or parked cars and links with remote police databases, immediately providing information about the car and owner. Right now the police check if there are any taxes owed on the car, if the car or license plate is stolen, and if the car is unregistered or uninsured. A car that comes up positive is towed."


Interesting!

Oracle Application Server 10g ORA_DAV basic authentication bypass

I would recommend anyone that is interested in securing their Oracle database to subscribe to some of the major security lists such as the bugtraq list at securityfocus.com or the full disclosure list. There are plent more besides these, but these are the major ones.

Why subscribe? - well its important for two reasons (BTW, I am not suggesting in any way that you should read every post - well unless you want to); the first is that these lists get Oracle vulnerabilities listed on a reasonably regular basis. Its worth understanding the sorts of bugs, vulnerabilities and exploits that are out there. The proliferation of lists like these and also of exploit sites like Milw0rm that can be searched for exploits by vendor and type means that many other people who want to steal from you also look at these sites and download exploits and other details. In order to secure an Oracle database you have to understand the types of attack that can occur against it. The second reason is more general, in that these lists contain a huge array of all types of exploits and bugs, not just for Oracle. In general you should understand all sorts of different types of attacks against Oracle. If we went back a few years and looked at bugtraq for instance "in general" and took differnt types of attack against other software we will be able to find attack types that are now found against Oracle. Keep up to date with security in general and apply that knowledge to securing Oracle.

If you are a DBA then subscribe, surf some posts and learn at a high level what the current issues are. It needn't take a huge amount of time, obviously this depends on what and how much you read.

As an example a couple of days ago Deniz Cevik posted an authentication bypass for Oracle Application server in a post titled "Oracle Application Server 10G ORA_DAV Basic Authentication Bypass Vulnerability".

A sample request is shown as:

Make a special http request first by visiting
"http:/site/pls/portal/%0A" url.

This request adds special session id into cookie. Subsequent connection attempts to
"http://site/dav_portal/portal/" will reveal the contents of directory
without any authentication.

wink

License plate SQL Injection

Wow, its been a while since I posted, I have been travelling all over the world over the last month or so, teaching my Oracle security class and also speaking at conferences and performing Oracle security audits. It's been a hectic few weeks. Hopefully I can do some blogging again soon.

I came across a post on my Oracle Security forum today posted by Marcel-Jan in a post title SQL Injection in license plate scanners the original source is quoted in the post. This is a cool idea, SQL injection as part of a license plate to fool the license plate reader software. As the original source states, its likely to be a hoax but the idea is great, it reminds me of the scam to add SQL Injection strings to forms with a pen that are read in by computer, the governments of the world love to use these. Also it reminds me of a bar code SQL Injection attack. Fun anyway wink

Slides from OUG Scotland DBA SIG on Oracle Forensics available

I have posted the slides to my talk from yesterday at the OUG Scotland SIG to my Oracle Security white papers page. They are the first entries in the page. The talk was 45 minutes about Oracle Forensics. This was an interesting discussion and I had some good discussions afterwards with various people on the same subject.

The presentation is based on the one I did for the UKOUG conference last year but it has had quite a few small edits done to it so if you have the old version its certainly worth downloading the new one from yesterday.

Oracle forensics certainly seems to generate a lot of interest and should be a key area very soon as knowledge builds.

On a related subject I finally received my copy of Paul Wright's book about Oracle Forensics a couple of weeks ago. This has taken some time since ordering (some 5 months) to delivery even though the published date still seems to be early 2007, this is a pity as there is clearly a big interest in this area. I have not read it all yet but have skimmed it. The content looks interesting and I will give some comments here at some point when i have some time to read it cover to cover, not much spare time at the moment..:-(

Conditionally firing triggers

I saw a post on the BAR Solutions blog today titled "Triggers…" that was very interesting as I have had the same issue in the past for different reasons. The blog post was around an issue where triggers became disabled, or rather not re-enabled after an upgrade script that turned them off didnt successfully complete and therefore the triggers didnt get re-enabled.

The author presents a solution based on a semaphore flag that conditionally allows the trigger to fire based on whether the semaphore is set or not.

I posted a comment to the blog which is repeated here:

"nice post and interesting. I have come across the same issue but from a security angle. I wanted to have triggers that would conditionally fire based on certain circumstances (user, group of users (role), time..). I came up with a similar solution but simpler. I used the “when” clause of the trigger to detect which user/role fired the trigger. in this way it was possible to control when the triggers fired. This meant triggers could always remain enabled but not fire for certain cionditions. I did some extensive testing and the performance “loss” due to the when clause was much less than executing checks in the body of the trigger. Running a trace shows that a loss less background work is done in the trigger. The losses i saw were shown at a high level in as a 3% impact for executing the when clause compared to 37% for executing the body. I wrote a presentation that is called “does vpd, fga and audit really cause a performance impact” - there is a link on my Oracle security white papers page including some sample code.

Other areas we looked at were the OF clause as well."


I thought it worth a mention here as this is a common issue where for security reasons triggers are used as part of an audit trail but need to fire conditionally based on user, role, time.... These are facilities that are available for other Oracle audit solutions such as FGA but not out of the box for triggers. Nice post though and useful.