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.

This itself is a big problem, but Esteban also discovered that when you manipulate the TNS packages used during the O5LOGON authentication protocol, in practice disconnect just after you receive the encrypted session key and SALT value from the server, there is no trace of this (no audit record). When you have this information, you can start your offline brute-force password “guessing” with this information. This is why the problem is also referred to as the “Oracle 11g stealth password cracking” bug.

I have to say I did not believe that someone could get enough information from the AES (192 bit) encrypted session key to put a brute force attack on it. I started some investigation on the problem (there is not much information about it then all the articles that are telling the same story) and I have to say it shocked me that I too was able to find the flaw on the session key encryption. I was even able to write some small C program that can do a brute-force attack to find passwords.

Screendump o5logoncrack tool


So it is absolutely true that people are able to use this flaw to crack passwords without having access to the actual password hash! All it takes is network connection to the database server, a valid username (take SYS or SYSTEM for example) and time for executing an offline brute-force attack on the gathered encrypted session key and SALT value.

Unfortunately I haven’t been able to write some code to manipulate TNS packages to investigate the “stealth” part of the problem, but the information can be gathered easily with a normal Oracle client adding the following lines in your sqlnet.ora:

TRACE_FILE_CLIENT = HoustonWeHaveAProblem

You can do a login with the username for which you want to “get” the necessary information and specify a wrong password (otherwise you wouldn’t have to brute-force the password anyway). This of course could trigger an DBA that someone had a failed logon, but users specifying wrong passwords also happen in normal operations!
Anyway you now could use the generated trace file (in your diag directory) to get the session key and SALT value.

Oracle’s countermeasures

This is a big problem for Oracle which impacts a lot of companies using Oracle 11.1 and 11.2 databases. They solved the “problem” in version by allowing customers to use a “new” authentication protocol which is going to be used in Oracle 12c. This however has to be enabled  by adding the following line in the sqlnet.ora files of all client and server software:


Beware however that by using this new authentication protocol, any older clients won’t be able to connect (an perhaps older databases connecting through database links?)!! For a lot of companies I believe this will not be an option.

Oracle has released an note on My Oracle Support (MOS) – Mitigation steps for CVE-2012-3137 [ID 1492721.1] – that describes the countermeasures customers can take to mitigate the risk of this bug.


In short this note gives the following “solutions” for this problem:

  1. The problem will be fixed on all supported 10.2, 11.1 and 11.2 that implement the O5LOGON protocol with the next CPU patch (October 2012).
    The mentioned MOS note says this CPU patch will contain a fix for both databases software as “supported” clients. I raised an SR with Oracle support to get some more details about this “fix” and they were telling me that only the databases needs to be patched. At the end Oracle support came back on this, telling me that they are not sure about the “details” until the October CPU becomes available.
  2. Use the O3LOGON (pre 11g) protocol, disabling the usage of the 11g O5LOGON protocol on 11.1 and 11.2 databases by:
    – Change the instance parameter SEC_CASE_SENSITIVE_LOGON to FALSE
    Fortunately it is not necessary to restart your database instance!
    – Recreate all oracle password files with
    orapwd file=<password file>ignorecase=y
    – Regranting SYSDBA and SYSOPER privileges to required users
    Especially good testing around data guard configurations!
  3. Use long passwords (12 characters or more) using both lower-, uppercase letters and nummeric characters (if you start using the O3LOGON protocol again, all letters will be casted to uppercase letters).
  4. Use external authentication (but you will still have your internal accounts like SYS and SYSTEM with “normal” password authentication)


For disabling O5LOGON for ASM instances (which also can be reached from remote and also use this protocol and thus contain this flaw) you will have todo the following:

  1. Get a list of users defined in the ASM password file and the permissions for these users:
    SELECT * FROM v$pwfile_users; (or gv$pwfile_users for GI clusters)
    Example output:

    SQL> select * from v$pwfile_users;
    USERNAME                       SYSDB SYSOP SYSAS
    ------------------------------ ----- ----- -----
    SYS                            TRUE  TRUE  TRUE
    ASMSNMP                        TRUE  FALSE FALSE
  2. Recreate the ASM password file with ignorecase=y option:
    orapwd file=<ASM/GI home>/dbs/orapw+ASM ignorecase=y
  3. (Re)create the users (apart from SYS which is by default created) that you retrieved using the query on v$pwfile_users and grant the correct permissions. So in my example:
    CREATE USER asmsnmp IDENTIFIED BY zoujewillenweten;
    GRANT sysdba,sysoper,sysasm TO sys;
    GRANT sysdba TO asmsnmp;
  4. If your ASM instance is part of an Grid Infrastructure cluster (RAC) copy the orapw+ASM file to each node of the cluster.