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 67 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 » March 2010 » Blocking Tools from using the database

[Previous entry: "Pete Finnigan Webinar on Oracle Security"] [Next entry: "A paper on Sentrigo Hedgehog and Pete Finnigan webinar slides"]

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.

There has been 3 Comments posted on this article


March 12th, 2010 at 02:43 pm

Donat Callens says:

Should this not be solved by defining privileges?

You could allow anyone to connect with any tool, but... only do what you think he should be doing. If the user can only access the data through specific packages and only read/write the data you allow him to access, you are secured.

He will not have much fun connecting with Toad if he cannot see anything in the database anyhow



March 12th, 2010 at 04:35 pm

Pete says:

Thanks for your comment. yes in the real world you are right but we dont live in the real world and most users in the database have far too many privileges so when users manage to get direct access to the database with a tool such as TOAD they have much better options than when they use their account through an application. The issue is really about preventing the inevitable

cheers

Pete



March 22nd, 2010 at 06:43 pm

joel garry says:

I assume you meant "modicum of determination," though the apparent typo does bring up an interesting point. Most worms and techniques of securing systems are deterministic, following a set of rules to secure or attack - and we could add to your comment, it is inevitable that the offense rule set will outpace the defensive. I'm thinking the reason for that is the brightest hackers are non-deterministic, making semi-random jumps in method to go around existing rules. Con-artists have done this for years - determine the assumptions of the victim and react in a way that turns those assumptions on their heads. System technically well-secured? Use social engineering.

TV show called "White Collar" had a scene where one FBI agent gets caught red-handed downloading files from anothers laptop onto a USB - and explains "I'm from IT" and gets away with it. laugh out loud


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


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!