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 45 visitors online    

Pete Finnigan's Oracle security weblog


A paper on Sentrigo Hedgehog and Pete Finnigan webinar slides

March 12th, 2010 by Pete

I did two webinars this week with Sentrigo titled "The right way to Secure Oracle", these went well. The slides for the talks have been added to my Oracle Security white papers page.

I have also written a short article about the Sentrigo HedgeHog Enterprise Database activity monitoring and Intrusion prevention product. The article is around 30 pages long and covers install, why I like the product and also how to use the built in vPatch rules and also how to set up custom rules. The article includes plenty of examples and also shows examples of testing the rules with exploits. The paper is in pdf only and is available from my Oracle Security white papers page, please have a look!

[No Comments]


Blocking Tools from using the database

March 10th, 2010 by Pete

I saw Charles Hoopers post titled "Why Doesn’t This Trigger Work " No Developer Tools Allowed in the Database" via my Oracle blogs aggregator and read it with interest as its related to issues i come across with clients often. That is they ask me how to stop various groups of people in their organisations connecting to the database using various tools; sometimes this is developers, sometimes power users with Excel (as Charles showed) and many more examples.

I started to write this in a comment to Charles post but it was getting bigger and I also felt its a good subject to talk about so i decided to move it here to a blog post.

First, I realise the post is about posting code that doesnt work and people posting other peoples code but i cannot resist just talking about the actual problem highlighted; that is to stop people connecting to a database with certain tools, no matter what those tools are. There are two major issues:

1) You dont know what tools people may try and use to connect to your database
2) You dont know from where they will connect and with what user account

The problem of stopping them is clearly not easily solved. If you try and block Excel, SQL*Plus, TOAD or anything else its futile. The application name may change because the application vendor changes it, the name can be spoofed easily via Oracle provided API's or via a proxy to another name, the name can be changed by renaming the binary.

I discussed this issue a very long time ago (7 years ago to be exact) for SQL*Plus showing some protections and including use of a trigger which is not Franks code of course.:-) The article is here but the conclusion is of course that tools such as PUP tables, triggers et al are only any use against the casual hacker but not someone who has any modicum of determinism.

The issue of spoofing has been discussed here a few times in the past - Can application names be changed to spoof logon triggers? and Spoofing users and programs and presenting at OWASP has a good discussion and a set of links to other posts that cover spoofing at various levels. Basically spoofing is quite easy if you have some gumption to try it.

This all comes back to point 1 and point 2. If you doint know what applications people will use or even from where they will connect then a better approach (if it will work) is to use a white list approach. White list the people whoi are allowed to connect and from where; this should include applications, people, IP addresses etc. This is sometimes hard to do as most sites dont know currently who is connecting so need to investigate. Also DHCP throws a spanner into the works. Use a real firewall if possible, if not use a simple solution such as valid node checking.

Then limit the users who can connect by protecting password leakage. Limit the privileges users can have when they connect. Disable all default roles and have then turned on via secure application roles when connecting (bear in mind what I have said about spoofing!)

The problem is complex to solve and a trigger is not suitable as a complete solution; also enable audit or use an external solution such as Sentrigo Hedgehog. A good trick also is to have your applications generate a unique ID when connecting, this can make spoofing harder to acheive.

[2 Comments]


Pete Finnigan Webinar on Oracle Security

March 8th, 2010 by Pete

It has been quite a while since my last blog post; i keep promising to post more often and even worse I have a long list of things to blog about but I don't seem to get enough time recently, so I should probably stop promising. I have spent hardly any time in my office over the last three to four weeks having been out teaching my class "How to perform a security audit of an Oracle database" on public trainings and also on quite a lot of private trainings for clients - (I am going to be in Bratislava next week teaching the next public class) and some more public dates are going to added to my calendar very soon - watch out for those.

We have also just added the dates for the class in Denver Collorado in June. I have also spent quite a lot of time on short consulting engagements around Oracle security reviews, audits and also recently quite a lot of design reviews and design work - again all around Oracle security. Things have been quite mad for me which is a pity for you guys as I have not had time to blog.....

Tomorrow 9th March at 10am UK time and also this coming Thursday, 11th March at 1pm EST (6pm UK time) I am giving a webinar hosted by Sentrigo. The talk is focused on the The right way to secure your data in an Oracle database; this is about starting at the right place and concentrating on the access models implemented in your database, relating these models to real people or job titles or processes and then to the actual data (all of it). If you would like to hear me talk about the methodologies I use to secure Oracle (and hear my voice if you are over the pond, as I don't speak in the US/Canada very often) or even ask me a question via the Q&A at the end then you can register at these two URL's:

Tuesday, March 9 10-11am GMT (England Time)
Thursday, March 11 01-02pm EST (NA Eastern Time)

On the subject of Sentrigo, I am also writing a short article about using Sentrigo's Hedgehog IDS/IPS product that will follow on from the detailed article i did in 2008 - "Sentrigo Hedgehog". This article is going to cover some example uses of the product. Watch out for it; coming soon!

I also came across Simon Fletchers blog a week or so ago whilst on the train when i was looking for something in google for a client and then today I noticed that Paul also mentioned Simons blog in his. Simon has started a blog about Oracle security called "Fifteen Twenty One". I have of course added his blog feed to my Oracle blogs aggregator. There are not many posts there yet (3 as i write this) but what is there is good so its going to be worth following.

I actually found one of his blog posts when searching but went for a look and found that his most recent post is about something I was dicussing recently with a client. This discussion was about the issue of the SQL92_SECURITY parameter and why it doesn't seem to work in some circumstances. OK, doesnt seem to work is unfair, it is not a bug but there is a couple of issues that you should be aware of if you think of using it.

I have been checking this parameter for many years and wrote a script in 2003 that tests for tables that have delete, update privileges and no select privilege so that I could advise clients to change this parameter as part of our security audits. I found that if you have sql92_security set to TRUE





SQL> sho parameter sql92

NAME TYPE VALUE
------------------------------------ ----------- --------
sql92_security boolean TRUE
SQL>





Then if I have a table that has just DELETE privilege granted to it as follows:




SQL> @who_can_access

who_can_access: Release 1.0.3.0.0 - Production on Mon Mar 08 13:23:02 2010
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

NAME OF OBJECT TO CHECK [USER_OBJECTS]: CB1
OWNER OF THE OBJECT TO CHECK [USER]: ORABLOG
OUTPUT METHOD Screen/File [S]: S
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]:
EXCLUDE CERTAIN USERS [N]:
USER TO SKIP [TEST%]:

Checking object => ORABLOG.CB1
====================================================================


Object type is => VIEW (TAB)
Privilege => DELETE is granted to =>
User => SQL92 (ADM = NO)

PL/SQL procedure successfully completed.


For updates please visit http://www.petefinnigan.com/tools.htm

SQL>




As you can see the user SQL92 can DELETE but nothing else; then i cannot DELETE:




SQL> sho user
USER is "SQL92"
SQL> delete from orablog.cb1
2 where name_on_card like '%Pete%';
delete from orablog.cb1
*
ERROR at line 1:
ORA-01031: insufficient privileges


SQL>




OK, so sql92_security does what it says on the tin but it does now stop DELETE grants from totally working, i.e. I can still delete but not specific records:




SQL> delete from orablog.cb1;

6 rows deleted.

SQL> rollback;

Rollback complete.

SQL>




OK, if we now look at all the details for the sql92_security parameter via my check_parameter.sql is a one way to do it:




SQL> @check_parameter

check_parameter: Release 1.0.2.0.0 - Production on Mon Mar 08 13:28:43 2010
Copyright (c) 2004 PeteFinnigan.com Limited. All rights reserved.

PARAMETER TO CHECK [utl_file_dir]: sql92_security
CORRECT VALUE [null]: TRUE
OUTPUT METHOD Screen/File [S]: S
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]:

Investigating parameter => sql92_security
====================================================================
Name : sql92_security
Value : TRUE
Type : BOOLEAN
Is Default : ***SPECIFIED IN INIT.ORA
Is Session modifiable : FALSE
Is System modifiable : FALSE
Is Modified : FALSE
Is Adjusted : FALSE
Description : require select privilege for searched update/delete
Update Comment :
-------------------------------------------------------------------------
value is correct

PL/SQL procedure successfully completed.

For updates please visit http://www.petefinnigan.com/tools.htm

SQL>




OK, so Oracle explains this in the comment, SELECT privileges are required only for searched update or delete. So being able to delete all rows is allowed. What Simon showed in his blog post to locate records via inference is not possible (which is the intended use of this parameter) but deleteing is not totally stopped. You should be aware of this.

A more subtle issue is the fact that sql92_security prohibits a DELETE or UPDATE from working if there is no read privileges .... what if there is a read privilege but via a different route....




SQL> @get_data

get_data: Release 1.0.0.0.0 - Production on Mon Mar 08 13:48:30 2010
Copyright (c) 2004,2010, PeteFinnigan.com Limited. All rights reserved.

OBJECT TO CHECK [XXX_XXXX]: CREDIT_CARD
SCHEMA/OWNER OF THE OBJECT TO CHECK [USER]: ORABLOG
OUTPUT MODE [All,Equal] [E]: E
OUTPUT METHOD Screen/File [S]: S
FILE NAME FOR OUTPUT [priv.lst]:
OUTPUT DIRECTORY [DIRECTORY or file (/tmp)]:

Access to object, copies and children [ORABLOG.CREDIT_CARD]
===================================================================


Tables to analyse [IMPORTER.C23]
==>
IMPORTER.C45
---------------------------------------------
Tables to analyse [ORABLOG.CREDIT_CARD]
==>
ORABLOG.CB1
ORABLOG.CC1
ORABLOG.C67
ORABLOG.CC87
ORABLOG.CCNAME
---------------------------------------------


Main Table [IMPORTER.C23]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
IMPORTER BD X


Child [IMPORTER.C45]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
IMPORTER BD X
--------------------------------------------------------------


Main Table [ORABLOG.CREDIT_CARD]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
ORABLOG BA X
ORABLOG IMPORTER X
ORABLOG SYSTEM X X X [A,D][ORABLOG_CREDIT]
ORABLOG HH X X X [,D][ORABLOG_CREDIT]
ORABLOG PUBLIC X


Child [ORABLOG.CB1]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
ORABLOG SQL92 X


Child [ORABLOG.CC1]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
ORABLOG BB X


Child [ORABLOG.C67]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -


Child [ORABLOG.CC87]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -


Child [ORABLOG.CCNAME]
GRANTOR GRANTEE S I U D A F D I R Q C E
------------- -------------- - - - - - - - - - - - -
ORABLOG BC X X
--------------------------------------------------------------

PL/SQL procedure successfully completed.


For updates please visit http://www.petefinnigan.com/tools.htm

SQL>




The above output shows that the user SQL92 has the DELETE privilege against the view CB1 but also inherits the PUBLIC SELECT against the base table CREDIT_CARD.

Would you (as a designer of the application) want DELETE to then work instead of being blocked? As it stands its clearly not a bug as the parameter stops a DELETE without a READ on the SAME VIEW or TABLE it should work this way in my view. But if you have enforced this sql92_security parameter to TRUE expecting that it will stop deletes with no select - then fine - but if you expect reverse logic then beware.

For my sample view CB1 I have read privileges on the table its a CTAS on, so i can read the data but not read via the view and i have only DELETE privileges on the view. If I wanted to turn on SQL92_SECURITY and I checked the privileges I would find CB1 has only DELETE and would think about adding SELECT privileges to this view (increasing the privilege count), I would not find that I can see the data via ORABLOG.CREDIT_CARD (the base table) simply by searching for tables/views that do not have SELECT. I guess what I am getting at is maybe the solution isn't (in this example) to grant SELECT to SQL92 on ORABLOG.CB1 but maybe to remove SELECT on ORABLOG.CREDIT_CARD as well or maybe to add DELETE to ORABLOG.CREDIT_CARD for SQL92 and remove it from CB1 - bearing in mind we must know which columns are exposed and also how the tables and views are used in the application....

Finally there is the subtle problem of potential privilege. When I do an audit I also check for potential privileges and in the case of suggesting to a client to turn on sql92_security we must be also aware of the potential for issues in the future by analysing who may grant privileges that may break because of this parameter.

[No Comments]


SANS 2010 CWE/SANS Top 25 Most Dangerous Programming Errors

February 23rd, 2010 by Pete

SANS, Mitre and a lot of security experts have just completed the top 25 most dangerous programming errors list. This is a really useful resource and anyone developing code not just against Oracle but in general should be concerned to read this. This is not a simple document. There is a HTML version of "2010 CWE/SANS Top 25 Most Dangerous Programming Errors" and also a pdf version for download. There is a huge amount of information and particularly there are a lot of improvements over the 2009 version.

Take a look!

[No Comments]


SQL Injection and Java exploits

February 17th, 2010 by Pete

It has been a while since my last blog post as I have been extremely busy over the last weeks and this blog post is being posted straight after finishing a customer training session using the clients internet connection (with permission!) before i disapear off site.

If you would like to book my how to perform a security audit of an Oracle database training class at your site, please drop me an email (see my contacts page), it is very popular at present and providing benefits to a lot of people on both public classes and also private classes. We do fixed prices for up to 2 people, up to 4 people and up to 8 people. We can of course accomodate more people but this is unusual for private classes but not for public ones.

I was emailed by Mike Smithers last week to let me know about his very nice article about SQL injection posted to his blog and titled "Self-Inflicted SQL Injection " don’t quote me !". Mike kindly let me know but I have had little time to read it until i finally did so this lunch time. The article is very nice and concentrates on the issue of objects created in the database that are themselves injection payloads. This can be an object or a user (which of course is still an object in the dictionary). This idea has been around for quite a while but its nice to see a paper on it.

Also David released a new idea on exploiting Java at Blackhat which included a 0-Day exploit against Oracle. The exploit is shown in Sumit Siddarths blog in a post titled "Hacking Oracle 11g" which also includes a link to Davids blackhat presentation video. Paul has written a short paper titled "Securing Java in Oracle" that gives some details of the vulnerability and also some ideas on securing against in in the absense of a patch. Its nice to see that Paul has included some of the ideas on checking in depth (i.e. packages that use packages ect and ad-infinitum) that i have been talking about in presentations for a few years at places such as the UKOUG and also in my training classes. I will also be covering these ideas and more in two webinars for Sentrigo in a few weeks time (see the links on my home page to register for the talks. One is on European time and one on US time. Nice paper Paul!

[No Comments]


Turkey, Germany, York, Holland and the Oak Table book

February 2nd, 2010 by Pete

I was away most of last week to teach my class How to perform a security audit of an Oracle database in Istanbul, Turkey including the travel out and back. It was a good class, very well attended and some good discussions and questions from the attendees. The weather was the biggest surprise as it was cold, very cold, minus 8 and also snow everywhere. I had expected that the weather would have been warmer there than in the UK, but it wasn't.

I am speaking in Germany on Thursday the 4th February at the IT-Defense 2010 conference in Cologne Germany. The link is on the PeteFinnigan.com Limited sites home page.

We are also one week away from our two day Oracle security training here in York, England. If anyone wants to make a last minute registration thats fine we will be able to accomodate you.

I have also updated our public training dates page to include the registration details for the new public class in Utrecht to be held on the 26th and 27th of May 2010. I would love to see people there as well!

Finally the new Oak Table book, Expert Oracle Practices is out. I had my copy waiting for me when i returned from Turkey and I am looking forward now to read the other authors chapters. I wrote two chapters; the first about user security and the second about data security. I found that one of my co-authors Charles Hooper has written an excellent summary of the book on his blog in a post titled - "Expert Oracle Practices: Oracle Database Administration from the Oak Table” Book"

[No Comments]


The Oracle listener password algorithm

February 1st, 2010 by Pete

There has been a thread on my forum for a couple of years discussing the Oracle listener password algorithm. The thread is titled "Key and algo for encrypting the listener password". This thread discussed the issue of being able in some versions of Oracle to pass the hash to log in. This is a technique used by security people to discover weaknesses in authentication mechanisms and was evident in the listener because the listener in 9i and lower supported two authentication mechanisms where one was to test the password that was added in clear text to the listener.ora file. This had a flaw as the hashed password could also be used. The listener password algorithm in 9i and lower was the same as the database password algorithm except that the listener doesnt use a username so an arbitrary user was used instead. The listener is authenticated via local authentication in 10g and 11g but its still possible to enable a password for remote authentication although not recommended. The password authentication mechanism is different in 10g and 11g. I was aware of how it worked but usefully now Marcell Major has now released a short paper describing the algorithm. This is in a paper titled "Oracle listener password encryption". There is also a demo program written in python available to download.

[No Comments]


March 2010
SMTWTFS
 123456
78910111213
14151617181920
21222324252627
28293031   

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

Oracle Security Step-by-Step (Version 2.0)

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




View Pete Finnigan's profile on LinkedIn

Pete Finnigan

Create Your Badge



Valid XHTML 1.0!