[Previous entry: "Nice SQL Injection cheat sheet"] [Next entry: "The fastest Oracle password cracker in the world is released!!!"]
Weakness in Oracles new 11g authentication protocol
October 8th, 2007 by Pete
Post to del.icio.us
Post to Furl
Laszlo Toth has released a paper analysing the new 11g authentication protocol used to authenticate users to the database. The paper is titled "Initial analysis of Oracle native authentication version 11g" and it describes the authentication mechanism. The O5Logon protocol is a changed/Improved? version of the O3Logon protocol used in 10g and earlier. Laszlo also includes some proof of concept code written in C to decrypt the database password if the Server session key, Client session key, new 11g password hash and the AUTH_PASSWORD are known. Laszlo includes an example session using his proof of concept code to show that a password can be retrieved.
This means that the same weakness that existed in earlier versions of the authentication are still in evidence; that if the password hash is known (Oracle have made some efforts to better secure the hash by removing it from DBA_USERS for instance) then the password can be retrieved from session sniffing. Of course as Laszlo points out the simple solution would be to use network encryption to prevent session sniffing and of course the key issue is to not let password hashes fall into a hackers hands. As Laszlo also points out because the password algorithm is known a brute force attack is also possible. I have used this type of attack during Oracle database security audits if i find SQL*Net traces that include the relevant keys and AUTH_PASSWORD.
One key observation that is not included in Laszlo's paper but we have discussed off-line is the fact that the database server also sends the SALT in the AUTH_VFR_DATA field. This in my opinion decreases the value of the SALT. OK, the database now has hashed passwords that are different (Not withstanding the fact that the old hash is also stored in the database!!) for each time you assign the same password to the same user and also different password hashes across different databases for the same user/password combination but if the SALT is available remotely just for the asking then where is its value? - any connection attempt to the database for any particular user results in the SALT being sent to the client. The SALT can then be used in the new 11g password algorithm to dictionary attack or brute force attack the password. This lessens the value of the SALT in my opinion as its readilly available. Quite obviously the same solution of using network encryption will be useful to prevent sniffing of the SALT (and the rest of the values) from the wire BUT this wont prevent anyone with nefarious reasons to connect or used a client to the Oracle database with no knowledge of the password and use SQL*Net trace level 16 (support) to get the SQL*Net packet contents. Of course they need physical access to connect and also if encryption is used the means to use that but nowadays a larger number of incidents and attacks are internal.
This is, as usual a nice paper from Laszlo.
