Cryptographic flaws in Oracle Database authentication protocol
Recently a security researcher (Esteban Martinez Fayo) made the world aware of a problem with the O5LOGON Oracle database authentication protocol (used in 11g – 11.1 & 11.2). This problem, known as CVE-2012-3137, makes it relatively simple for attackers to get hold of passwords using a brute-force attack on the encrypted (AES -192 bit) session key that is returned by the Oracle database when connecting. This means you don’t need the password hash (SHA-1 hash as of 11g) to brute force the password anymore. The information (the encrypted session key – AUTH_SESSKEY – and the password SALT value – AUTH_VFR_DATA) returned by the server at an very early state of the authentication process if enough.
This article is gives more information about the actual problem and the steps you can take to protect your databases from leaking password information.
Within Oracle databases passwords get hashed. When, for example, you create a new account or change the password of an account, the specified clear-text password gets hashed. This hash value is stored in the database with the account. Once hashed it is not possible to get the original clear-text password from the hash value (one-way hash algorithms) again. The case-insentive passwords (still generated in Oracle 11g) gets hashed by Oracle using the 3DES (Triple-DES) encryption algorithm, while the case-sensitive passwords (as of 11g Release 1) get hashed using the SHA1 hashing algorithm. This means that for each account there are two different password hashes available as of Oracle 11g (in pre 11g databases there is only one password hash available per account).
Note: the case-insensitive hash (pre 11g and 11g) is actually not a hash but an encrypted username/password combination, which becomes a one-way hash by encrypting the result of the first run (after removing some bytes) again.
How does a case-insensitive password hash look like (pre 11g and 11g)?
How does a case-sensitive password hash look like (as of 11g Release 1)?
Unwrapping wrapped PLSQL in 10g, 11g and 12c
There are circumstances where you whish to have a look at the source of an wrapped PL/SQL package, procedure or function. The circumstances I want to have peek at the source is when some PL/SQL code becomes invalidated because an object the code depends on disapears or grants on such objects gets lost. It would/should of course be nice if the support department of an software company have a direct answer on what the dependencies exactly are, but I have found that in a lot of cases they don’t know and it will cost a lot of time to get things sorted out.
Wouldn’t it be nice that you actually can take a wrappped piece of PL/SQL and take a look at the line of code where Oracle is complaning about when you try to recompile?
This post will show the way wrapped PLSQL is wrapped and describes the method to unwrap wrapped PLSQL code in 10g and 11g Oracle databases.