If you don't know neither the enemy
nor yourself, you will sucumb in every battle.
If you know yourself but not the enemy, for every victory gained you will also suffer a defeat.
But if you know the enemy and know yourself you need not fear the result of a hundred battles.
The art of war (Sun Tzu)
Initial analysis of Oracle native authentication version 11g
Oracle released 11g version of its database server software. Several papers were published about the weaknesses of the previous versions of the native authentication protocol (.e.g:. [1.][2.][3.][4.]) The authentication protocol in the OCI driver was changed in 9i, 10g and changed again in 11g. This article shows at least two problems still there in the newest version of the protocol:
The password hash generation is very simple and it is already known [5.]. Oracle generates 10 bytes salt. The password and the salt are concatenated and SHA1 hash is generated from the concatenated value. The result is stored in the spare4 column of the sys.user$ table where the salt is concatenated to the hash:
11g native authentication protocol As you can see below the protocol is a challenge response protocol as in the previous versions. After the client sends its username, the server responds with the AUTH_SESSKEY and AUTH_VFR_DATA:
The AUTH_SESSKEY length was changed it is 48 bytes long. The AUTH_VFR_DATA is the new password hash salt value. The client then sends the AUTH_PASSWORD and its AUTH_SESSKEY value:
The client’s AUTH_SESSKEY is 48 bytes long. It is sent in two parts. Every string in the packets begins with its length. The first part is 32 bytes long the second is 16 bytes. In the above packets the length bytes of the AUTH_PASSWORD is in red. The algorithm is the following:
The client decrypts the server’s AUTH_SESSKEY. The algorithm is AES with 192 bits key length. The key is the new hash of the user’s password. That’s why the server sends the salt of the stored password hash. The hash is only 160 bits long, but four 0 bytes is added at the end of the hash. The client generates its AUTH_SESSKEY and encrypts it with AES192 and key is the new hash of the user password. The two AUTH_SESSKEYs is combined by the client to generate the key for the password encryption. The combination pseudo code is the following:
The client sends the encrypted AUTH_SESSKEY and the encrypted password as AUTH_PASSWORD.
From the description above the most interesting point is that, the longer AUTH_SESSKEY is encrypted with password hash (the new one of course) as in the previous version, which means if you have the password hash you can also get the clear text password from the sniffed authentication. A proof of concept code can be downloaded from here. If you do not have the password hash you can initiate an off-line brute-force attack, because the new Oracle password hash generation is already known [5.].
Solution The solution is not a rocket science and if you have a database with sensitive data you may have already implemented it. You should use encryption in the communication channel that means you need either Oracle Advanced Security [6.] or there are other alternative solutions with SSH [7.] or stunnel [8.].
Against a brute-force attack a strong password policy is the best protection. Oracle supports it through profiles.
[1.] Marlene T.; Aaron N. Oracle Security Handbook
Special thanks go for Balázs Boda, Lajos Antal and Pete Finnigan.
APPENDIX – I
The views, opinions and thoughts in this homepage are the views, opinions and thoughts of the writer of this homepage and do not represent the views, opinions or thoughts of any past or current employer of the writer or any other third person. The content is provided 'as is' without warranty of any kind. Use at your own responsibility. Laszlo may be contacted on firstname.lastname@example.org.