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    
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 » December 2004 » Arup Nanda has a paper on Oracle Security Auditing part 1 on dbazine.com

[Previous entry: "sitemap added to PeteFinnigan.com"] [Next entry: "Frank has a nice post about improvements to web application security"]

Arup Nanda has a paper on Oracle Security Auditing part 1 on dbazine.com

December 14th, 2004 by Pete


I just found the first part of a series of papers written by Arup Nanda - It is entitled "Oracle Security and Auditing, Part 1: Securing Listener through a Password" and as its name suggests its about protecting the listener with a password.

Whilst this is an admirable thing to do the short article doesn't go far enough. The paper gives a thorough description of both methods of using passwords for the listener, the change_password command where the password is set dynamically and also the method by which the password is added to the configuration file listener.ora. The latter method of adding a password in clear text should not be used. This has a number of problems. The first is that the password is in clear text and because of this it can be read by anyone with permissions on the file. The paper does not discuss this fact or the need for file level security. Also this method is weaker in some versions of Oracle as it can be abused and connecting to the listener is still possible without the password. The key is to not use this method but if it is used then the configuration file must be protected at the operating system level. This is also the case with the change_password method as the hash should not be divulged either.

If the hash value is known it can be installed off line on another listener and be brute forced. This brings me to another issue with the listener which was not mentioned. The fact that the listener has no password management features, ageing, locking of the account etc.

I covered in a similar issue in my blog yesterday about listener passwords and the ADMIN_RESTRICTIONS_{listener_name} parameter. This parameter can also be used effectively to prevent changes to the listener configuration through the listener control utility. This is also a worthwhile addition to the things mentioned in Arups paper.

Arup also makes a statement in his article:

"This will make the work of the hacker impossible unless the password is known."

This is not true, the hacker can simply brute force the password if its not known because there are no protections built into the listener to prevent multiple failed login attempts. Also if itís possible to get the listener password hash then itís possible to brute force it off line.

This paper is the start of what looks likely to be a good series from Arup who is a good author. This is a good paper that covers its subject well but as I said I think it could have gone further and covered file permissions, password attacks and also restricting dynamic configuration of the listener.

December 2004
SMTWTFS
   1234
567891011
12131415161718
19202122232425
262728293031 

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!