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.
This entry was posted in Database, Security and tagged , , , , , , , , , , , , , , , , , , , , , , , . Bookmark the permalink.

12 Responses to Cryptographic flaws in Oracle Database authentication protocol

  1. pat says:

    Hi marcel,

    Can you publish the source code of your brute-force program?

    • marcel says:

      Hi, I won’t publish the code or the executable. I want to give companies the time to take countermeasures before it’s becomming available to the mass. It is giving enough problems already for lots of Oracle shops.

  2. Pingback: ZALABIT Zalaegerszegi Honlap és Webáruház Készítő Műhely » Professzionális Weboldal és Webshop Készítés Zalaegerszegen

  3. Pingback: BITLOG infotech hírek » Csendesen rúgjuk be az Oracle ajtaját

  4. Paul Breniuc says:

    Well, I think the credit goes to more names like Balázs Boda, Lajos Antal and Pete Finnigan and especially László Tóth for coding but indeed, the one who was exposed that publically in a security conference was Esteban in 2010. It was a constant hard work to put the information together, to test that across versions – and note that the simple authentication part was the only publically exposed for now. There are more aspects that should remain in shadow, researching vulnerabilities is intended to prevent exposures and not intended to expose legitimate candid users…

    (PS: sadly, more comments on security sites sounds like requests for exploits ?! – the advised oracle pentester is probably owning already such a tool… btw: in order to test also the missing audit part you’ll need to code yourself a proxy capable to intercept and play with the last part of O5Logon starting from 4th stage) or a complete “in-house” client. Try to do not release or “leak” such arround is a very good (legal) advice…

    Best regards – Paul.

    • marcel says:

      Hi Paul,

      thanks for your reply and mentioning the names of other (well known) people that have (and are) constantly working hard on finding these kind of vulnerabilities.

      The only reason for me to write this article (and POC code) was because I just couldn’t believe such an flaw would exist and more important, for such a long time. I’m not trying to release code (or the actual “key “to the problem) that is going to harm companies using Oracle databases. I know how much time it takes to implement a workaround for this problem.

      What worries me more is the lack of response of how Oracle is going to fix the problem. They only say that they are going to fix “it” in the CPU patch of October 2012, but they do not tell what needs to be patched (the MOS note tells otherwise then Oracle support btw). But you security guys are probably more used to these kind of responses (or the lack of) from big companies like Oracle.

  5. Paul Breniuc says:

    Thank you for your kind message above.
    Well, honestly… as the 11.1 (a 2008 year product) is frozen now and in Extended Support (this since Aug2012 – ES means “support for select Oracle software and operating systems for an additional fee >> so you can effectively manage your upgrade strategy<<") and few workarounds on the issue exists and already mentioned in the note 1492721.1 … I personally do not expect to be fixed.
    This situation is somehow the same like in the TNS Listener Poison issue where the exposure (known and tolerated over years) will never be fixed for older versions and similar to other industries (never saw a car manufacturer calling back for service older products, out of guarantee – even so parts might be still produced – and in software the 3y support "backwarded" by development is more than enough considering the speed of changes, now we're all expecting the 12c new features and… vulnerabilities).
    All the best – Paul.

  6. badoracle says:

    o5logon cracker (JtR patch) is now public along with Ettercap plug-in to sniff data.


  7. Matteo says:

    Hi Marcel,
    thank you for your article, i need a quick help. I installed a Oracle11g on a Centos 6.2 machine. Now i need to enable the O5LOGON authentication protocol for testing, how can i do that?
    I tried to SQLNET.ALLOWED_LOGON_VERSION variable in sqlnet.ora file, but i don’t have any sqlnet.ora file in my $ORACLE_HOME/network/admin directory.
    Thank you again.

    Best regards.

    • marcel says:

      Hi Matteo,

      If you are using an 11g (actually client or higher) client and database (and didn’t patch it with the latest CPU/PSU patch), it will automatically use the O5LOGON protocol (make sure the parameter sec_case_sensitive_logon is set to TRUE) even if you don’t have an sqlnet.ora.



  8. Pingback: Gregory Smith

Leave a Reply to pat Cancel reply

Your email address will not be published. Required fields are marked *

Blue Captcha Image