Oracle Database 11g stealth password cracking vulnerability in logon protocol

[Nytro]

[h=2]Oracle Database 11g stealth password cracking vulnerability in logon protocol (CVE-2012-3137)[/h]Posted February 20, 2013 by TeamSHATTER Admin

The vulnerability I will describe in this blog post has some aspects that make it especially noteworthy, which are derived from the fact that the issue lies in a critical portion of the authentication protocol. The vulnerability can be exploited in a stealth way, going undetectable because all the attacker needs is information that the Server sends freely as part of a normal authentication process. In addition, the vulnerability is so intimately part of the authentication protocol that it couldn’t be fixed without requiring an update of the client software, consequently fixing the vulnerability required to deprecate the affected protocol version and use older or newer versions.

There has been some back and forth with Oracle regarding the fix for this vulnerability from the moment I reported it on April 2010. In the second half of 2011, Oracle provided a fix in the latest patchset release 11.2.0.3 and closed the issue as the fix would be included in future releases. But there were some clear problems with this fix that concerned us. The fix was not enabled by default (it required configuration changes) and it was not going to be part of a Critical Patch Update, therefore there would be no fix for all existing supported affected releases. Fortunately, the story had a happy ending, when Oracle decided to include a proper fix in October 2012 CPU for all supported affected releases and with the fix being enforced without the need of a configuration change.

I will describe later how to protect a system from this vulnerability, by applying the fixes provided by Oracle and also a few workarounds for those that are not able to apply the fixes at this time, but first let’s go over the details of the vulnerability to understand where the problem lies and how risky it is.

Overview of the vulnerability

The Oracle Logon protocol is the native authentication mechanism that Oracle Database provides to authenticate its database users. As part of the initial process during the authentication, the client sends the username to be authenticated to the Server, which then responds with a random Session Key and the password salt of the user. There is a flaw in the way in which this Session Key, a critical component of the protocol, is protected. This flaw allows an attacker to apply password cracking techniques to guess the correct password of the user. All the attacker needs is a Session Key and the Salt which are freely sent by the Database server to anyone requesting a connection, prior to the authentication taking place. It is important to note that the attacker only needs to start the normal authentication process to obtain this Session Key, therefore the server can’t differentiate an attacker from a genuine user connection.

Who is vulnerable?

Oracle Database servers using logon protocol version 11 (i.e. based on SHA-1 password hashes). This includes releases 11.1.0.6, 11.1.0.7, 11.2.0.1, 11.2.0.2 and 11.2.0.3 (unless protocol version 12 is required) on all platforms. Releases 10.2.0.X are vulnerable only if Enterprise User Security (EUS) is used and the directory has SHA-1 password verifiers generated.

All database users that are authenticated by the Database (user identified by password) are susceptible to this attack. This excludes external users, such as OS users, which are not authenticated by the Database.

Specifically this vulnerability affects database user accounts using SHA-1-based password hashes for authentication. Accounts with SHA-1-based password verifiers appear as “11G” in the PASSWORD_VERSIONS column of DBA_USERS view. Database user accounts using exclusively a DES-based password verifier (“10G”) for authentication are unaffected.

Who can exploit the vulnerability?

Anyone who has network access to the database server can exploit the vulnerability, no authentication is required. The attacker only needs to know the Service name or SID of the database and a username that is authenticated using a password. For example, the highly privileged SYS user is a good attack target.

What can an attacker do?

A remote attacker can perform a stealth offline password brute force attack for a given username. No audit is trail left on the server for an invalid login attempt.

The time that it takes to crack the password depends on the strength of the password (length, complexity, character set used, etc.) and the processing power of the attacker. For example on current mainstream CPUs it is possible to crack an 8 character lower case alphabetic password in approximately 5 hours. For more complex passwords attackers can use dictionary or hybrid approaches with high end GPUs which have a lot more processing power to crack passwords than standard CPUs. The effort is equivalent to password brute forcing of a known password hash and salt.

Vulnerability Details

Now I would like to describe more in detail where the vulnerability resides. As I mentioned earlier, during the initial phase of the authentication sequence, the client sends the username of the authenticating user to the Server, which responds with a random Session Key and the password salt. This Session Key is a random value that will be used to protect the password that is sent by the Client. It is encrypted using an AES block cipher with the key being the password hash for the user (stored in the SYS.USER$ table or the password file) and using PKCS7 padding. The use of PKCS7 padding is the major design flaw in this implementation.

The encrypted Session Key that is sent by the Server is 48-bytes long but when decrypted (with the padding removed) it is 40-bytes long. This padding is a fixed sequence of bytes that are automatically removed when decrypted using the padding algorithm, a technique often used in conjunction with block ciphers like AES when the sequence of bytes to be encrypted is not a multiple of the block size (16-bytes for AES). If the Session Key is decrypted without removing the padding we find that all Session Keys end with a sequence of eight bytes with a value of 0×08 when the correct password hash is used as the key.

E_sk = AES_192_CBC (sk || {0x08}*8, key=Password Hash)

Sk (40 bytes long) = Session Key generated by the server.

E_sk (48 bytes long): The session key generated by the Server (sk) encrypted with AES cipher using the password hash as the key, adding PKCS7 padding. This is what the server sends to the client.

Knowing this, it is possible to verify any password and determine if it is the correct password by calculating the hash and using it to decrypt the Session Key. If the result ends with the above 8-byte padding, then the password is correct. To be precise, the probability that it is the correct password is 1-1/2^64 which means there may be 1 false positive in every 10^19 tries. This is a very large number and if we want to be sure that this is not a false positive we can double check with another Session Key. This effort decreases the chance of false positives to 1 in 10^38 which is negligible.

In short, the problem is the use of PKCS7 padding to protect the Session Key that is encrypted using the password hash. A proper implementation would have used random data for the remaining bytes of the block. This is the fix implemented in logon protocol version 12. This padding provides a way to link a Session Key with the password hash.

The attack is stealth because the Oracle Database server can’t differentiate a genuine authentication attempt with that of an attacker trying to get a Session Key for brute forcing. Also, as the attacker can stop the authentication process before sending a password, the authentication is never completed, therefore the native database auditing won’t record any trace of the intrusion.

How to protect

Limiting the network accessibility of the Oracle Database server is a good starting point to reduce exposure to potential attackers. This can be done using a network firewall or by setting node checking in SQLNET.ORA file (the settings are TCP.VALIDNODE_CHECKING, TCP.EXCLUDED_NODES and TCP.INVITED_NODES).

History of the fixes

TeamSHATTER reported this vulnerability to Oracle on April 21, 2010. One year and a half later, the vulnerability was fixed by releasing a new logon protocol version 12 as part of patchset 11.2.0.3 (both at client and server level). Logon protocol version 12 is no longer susceptible to this vulnerability because the padding in the Session Key is filled with random data instead of a fixed value, thus making impossible to determine if the password hash is correct or not when decrypting it.

The problem with this initial fix was that the server by default was still vulnerable because the older vulnerable version 11 of the logon protocol was still allowed, most probably for backward compatibility with clients older than 11.2.0.3. To stop being vulnerable it was required to set SQLNET.ALLOWED_LOGON_VERSION equal to 12. This way only logon protocol version 12 was allowed on the server. However, this configuration change required that all client software also be upgraded to 11.2.0.3, to support the new version of the protocol. This requirement to upgrade all client software was another problem with this fix that made it very difficult to implement.

Oracle closed the issue after providing this fix and told TeamSHATTER that the fix would not be included in a future Critical Patch Update. In this way the vulnerability would continue to be exploitable for most of the affected databases.

Fortunately Oracle changed their mind and decided to provide a proper fix in October 2012 Critical Patch Update for all supported affected releases (not only 11.2.0.3). This time the fix is enforced by default because logon protocol version 11 is no longer allowed on the server, without the need of a configuration change. Also the fix doesn’t require a client software upgrade (there are some exceptions noted in the following section) because protocol version 10 is also allowed and clients that don’t support version 12 are automatically downgraded to version 10.

In the following sections I will describe how to protect from this vulnerability. First I will explain what fixes can be installed to address the vulnerability and then I will go over some workarounds that can be applied for those that can’t install the patches right now.

IMPORTANT NOTE: Make sure to test any configuration change on a test environment before implementing it on production systems.

Apply October 2012 Critical Patch Update

The October 2012 CPU contains fixes for this vulnerability. Oracle fixed the vulnerability by forbidding the use of logon protocol version 11 in the Oracle Database server. After applying the CPU the server will exclusively use earlier versions of the protocol, like 10 or the new version 12.

It is important to understand that ending the use of logon protocol version 11, enforced by applying the CPU, could impact the ability of some clients to connect to the database server. Thus it is important to spend some time before applying the CPU to analyze if your database users or applications will be impacted by this or not.

First of all, if the CPU is going to be applied to all clients before applying the CPU to the server, or all clients are release 11.2.0.3, then there is nothing to worry about because those clients support protocol version 12. The compatibility issues arise when there is no way for a client to communicate using protocol versions other than 11, like 10 or 12. If the client does not support logon protocol version 12, then version 10 will be used.

If the Server does not have 10g verifiers (hashes), maybe because it is configured to only allow protocol version 11 (and above), then there is no way for the client to authenticate. If your sqlnet.ora file (located by default at {ORACLE_HOME}/network/admin) contains the line SQLNET.ALLOWED_LOGON_VERSION=11 then there is significant chance that users will be affected by applying the CPU. Running the following query will determine the user accounts that do not have 10g version verifiers:

SELECT username FROM dba_users WHERE nvl(PASSWORD,'X') <> 'EXTERNAL' AND nvl(PASSWORD,'X') <> 'GLOBAL' AND password_versions NOT LIKE '%10G%';

See the Patching for CVE-2012-3137 [iD 1493990.1] document available at Oracle Support for more information on how to determine if the clients will be affected by applying the CPU.

The use of logon protocol version 10 and consequently the use of DES-based password verifiers may not be adequate for some customer’s security compliance requirements. These customers may be forced to work exclusively with protocol version 12 that uses the SHA-1 passwords verifiers and contains a fix to the vulnerability described in this blog post. The following section explains this solution.

Exclusive use of the new logon protocol version 12 (only compatible with client software higher than 11.2.0.3 or that has October 2012 CPU applied)

This is the best way to fix this vulnerability, but it comes with some requirements that may be difficult to fulfill. This is the ideal solution because there is no need to fall back to logon protocol version 10 and lose all the security improvements introduced in version 11, like case sensitive passwords and SHA-1 salted password hashes.

Implementing this protection requires to have client software that supports logon protocol version 12. The clients that support this protocol version are release 11.2.0.3 (or higher) and also clients with October 2012 (or later) CPU applied.

Once the server and all clients have been upgraded, apply October 2012 CPU to the Oracle Database Server (not needed if the server is release 11.2.0.3 or higher) and configure the server to allow only logon protocol version 12:

Add (or edit) the following line in the sqlnet.ora file (located at ORACLE_HOME/network/admin):

SQLNET.ALLOWED_LOGON_VERSION=12

Oracle Database Server release 11.2.0.3 already has support for logon protocol version 12, even if the October 2012 CPU is not applied, but to stop being vulnerable it is required to set SQLNET.ALLOWED_LOGON_VERSION=12.

IMPORTANT NOTE: After this configuration change is implemented Oracle clients that don’t support logon protocol 12 (currently client version lower than 11.2.0.3 without the October 2012 CPU applied) will not be able to connect to the server.

The following sections contain information on workarounds to protect from this vulnerability for those who are unable to apply patches at this moment.

Workaround 1: Implement strong password policies

This workaround poses some difficult questions. How long and complex should a password be in order to be certain that no attacker can crack it in reasonable time? How long should the lifetime of a password be so that the attacker can’t crack it during that period?

These questions are difficult to answer because we don’t know the resources that the attacker possesses. Password cracking techniques are advancing quickly and what seems secure today can be insecure tomorrow. In general a password longer than 12 characters (using the full character set: numbers, lower and upper case and special characters) and not derived from a Dictionary word, is considered secure.

In addition to password complexity, it is also important that the password expiration is set to 90 days or less.

A strong password policy can be enforced by the use of Oracle Profiles. After the password policy is modified, organizations must require users to change passwords to conform to the new requirements.

Keep in mind that this workaround does not eliminate the vulnerability; instead the idea is to make an attack impractical by having passwords so difficult to crack that can’t be compromised during its restricted lifetime.

Workaround 2: Use external authentication

Users authenticated by external means (not by the Database) do not have a password hash stored in the database and consequently are not affected by this vulnerability. This includes users authenticated by the Operating System and the Network (SSL or third-parties like Kerberos).

See Configuring Authentication for more information on implementing these authentication methods.

Workaround 3: Disable protocol version 11 and use version 10 or lower (SEC_CASE_SENSITIVE_LOGON = FALSE)

Protocol version 10 or lower is not vulnerable to this attack. Oracle by default keeps two different hashes for each password, a DES based hash for version 10 and lower and the SHA-1 based hash for version 11.

This workaround has been divided into separate steps for better understanding. All steps are required. Step 2a must be completed first. Steps 2b and 2c can be completed subsequently in any order. Step 2b protects regular users. Step 2c protects administrative users (users granted SYSDBA , SYSOPER or SYSASM).

Step 2a)

Before implementing this workaround we must ensure that all users authenticated by passwords will be able to connect using protocol version 10. To verify this we need to make sure that SQLNET.ALLOWED_LOGON_VERSION setting in sqlnet.ora file is not present, or if it is present it is set to 10 or lower. We also need to make sure that all users authenticated by passwords have a version 10 password hash.

The following SQL query (when executed as SYS) lists all the users which are missing 10g hashes:

SELECT username FROM dba_users WHERE nvl(PASSWORD,'X') <> 'EXTERNAL' AND nvl(PASSWORD,'X') <> 'GLOBAL' AND password_versions NOT LIKE '%10G%';

If this query returns any rows, the users listed must change passwords in order to generate proper version 10 DES based hashes.

Step 2b)

The next step is to change SEC_CASE_SENSITIVE_LOGON initialization parameter to FALSE, so that 11g authentication is not available and 10g or lower is used (which is not vulnerable to this attack).

Execute the following SQL:

ALTER SYSTEM SET SEC_CASE_SENSITIVE_LOGON = FALSE;

Step 2c)

SYSDBA, SYSOPER and SYSASM users are authenticated remotely using the password file instead of the hash in the SYS.USER$ table, thus, the password file needs to be recreated.

After successfully recreating the password file, only the SYS user will be present, so for any other users with SYSDBA, SYSOPER or SYSASM privileges granted on the database, you must GRANT the SYSDBA/SYSOPER/ SYSASM privilege again to add them to the new password file.

To get the list of SYSDBA/SYSOPER/SYSASM users currently present in the password file execute the following query:

SELECT * FROM V$PWFILE_USERS;

Rename the current password file or move it to another location. The location of the password file is:

{ORACLE_HOME}/dbs/orapw{SID} for Unix/Linux , or

{ORACLE_HOME}\database\PWD{SID}.ora for Windows.

Next, use the orapwd utility to create a password file that uses 10g password hash. This can be done by specifying parameter ignorecase=y so that a version 10 case insensitive password is used. You will be asked for the SYS password.

orapwd file={password_file_location} ignorecase=y

After this only the SYS user will be present on the password file. If you want other users to have SYSDBA, SYSOPER or SYSASM privileges you need to grant them now by using GRANT SYSDBA/SYSOPER/SYSASM TO … statement.

Conclusion

After reading this blog post, I hope you will be convinced that this is a serious issue that requires immediate attention. If patching is not an option at this moment, one of the workarounds should be implemented to minimize the risk of exposure to this vulnerability.

Sursa: Oracle Database 11g stealth password cracking vulnerability in logon protocol (CVE-2012-3137) | TeamSHATTER