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 80 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 » July 2013 » Oracle Security Loop hole from Steve Karam

[Previous entry: "Oracle Database 12c Security Auditing"] [Next entry: "Hacking Oracle 12c COMMON Users"]

Oracle Security Loop hole from Steve Karam

July 22nd, 2013 by Pete


I just saw a link to a post by Steve Karam on an ISACA list and went for a look. The post is titled "Password Verification Security Loophole". This is an interesting post discussing the fact that ALTER USER IDENTIFIED BY VALUES bypasses password management and specifically the password complexity function. Steves test shows this but to be honest I would say that this on balance is probably is not a security loophole and intended behaviour as it stands now as this is unsupported syntax so its hard to suggest that the password management should work when we are supposed to use the correct ALTER USER syntax or PASSWORD from SQL*Plus which uses the OCI function. It will be interesting to see if Oracle respond to Steves post and correct it or not. If we think about the logic of this, this is syntactic sugar for "update user$ set password='blah' where name='name'; should the password management also include this ALTER USER syntax and even UPDATE is another thing; for this second discussion "should" not "expected" is that it probably should include these two syntaxes also....but lets get to why it doesnt work....

To close the loop it may be possible to block this abuse with a DDL trigger, you could run the same veriifcation function in a DDL trigger that captures changes to the USER object but you would need the password first - i.e. the actual clear text password not the hash. This could work for simple passwords and my password cracker written in PL/SQL could help with this but it wont work for complex functions. Steve said:

"While Pete Finnigan has created a Password Audit tool to check for default passwords, I don’t believe there’s any method to check existing passwords for complexity."

The cracker doesn't just check default passwords, it aslo checks password=username, defaults (1475 defaults passwords known), a dictionary of words, brute force up to 2 characters and also it checks role passwords.

To be able to check an existing password for complexity you would need to crack that password first from its password hash so that you could analyse the clear text password. If the password were complex and 8 characters or longer that cannot be done with a simple password cracker written in PL/SQL or even in C in a reasonably short time - i.e. the time to run an ALTER USER IDENTIFIED BY VALUES command. This is why Oracle do not enforce the password management when this syntax is used; hence my statement that this is intended behaviour if not desirable. If the clear text password is known (which it is during a proper ALTER USER command to change clear text password) then a verification function can be used.

A program to test against complexity is only possible when you have the clear text password.

Interestingly there are two new password verification functions in 12c to choose from that are better than 11.2, one is more secure than the other. This is good but like 11.2 they are not enabled by default. Also it is interesting to think about a verify function that enforces complexity. This is worthless if the rest of the peofile is not set. i.e. a password complexity function where there is not life time is meaningless as the function may never fire. Or a user with a lifetime and no complexity function is also useless as when the password expires it can be reset to a weak value.

Nice post though Steve!

July 2013
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!