ora11g

Initial analysis of Oracle native authentication version 11g

László Tóth

September, 21. 2007

Introduction

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:

• if you have the password hash you can decrypt the password from the captured authentication data,
• therefore off-line brute forcing is possible

Password hash

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:

memcpy(data,pwd,strlen((char*)pwd));

memcpy(data+strlen((char*)pwd),salt,10);

SHA1(data,strlen((char*)pwd)+10,md);

for(i=0;i<20;i++){

printf("%X",md[i]);

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:

000c 0000 000c 4155 5448 5f53 4553 534b  ......AUTH_SESSK

4559 6000 0000 6045 4439 3142 3937 4130  EY`...`ED91B97A0

3430 3030 4633 3236 4631 3734 3330 4136  4000F326F17430A6

3544 4143 4233 3043 4431 4546 3738 3845  5DACB30CD1EF788E

3645 4333 3130 3734 3242 3831 3145 3332  6EC310742B811E32

3131 3243 3043 3943 4333 3935 3534 4339  112C0C9CC39554C9

4330 3141 3039 3043 4239 3545 3935 4339  C01A090CB95E95C9

3431 3430 4332 3800 0000 000d 0000 000d  4140C28.........

4155 5448 5f56 4652 5f44 4154 4114 0000  AUTH_VFR_DATA...

0014 3746 4435 3242 4338 3041 4135 3833  ..7FD52BC80AA583

3636 3935 4434 251b 0000 1a00 0000 1a41  6695D4%........A

5554 485f 474c 4f42 414c 4c59 5f55 4e49  UTH_GLOBALLY_UNI

5155 455f 4442 4944 0020 0000 0020 3245  QUE_DBID......2E

3031 3334 3242 3139 3532 3139 4645 3345  01342B195219FE3E

3931 4245 4436 3432 3942 4339 4534 0000  91BED6429BC9E4..

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:

ff12 0000 00fe ffff fffe ffff ff05 7465  ..............te

7374 310c 0000 000c 4155 5448 5f53 4553  st1.....AUTH_SES

534b 4559 6000 0000 fe40 3430 4537 4238  SKEY`....@40E7B8

3643 3939 4634 4246 3144 3046 3137 3533  6C99F4BF1D0F1753

3843 3232 4542 4345 3035 3446 3546 3637  8C22EBCE054F5F67

3745 3242 3532 3134 3830 4631 4635 3631  7E2B521480F1F561

3433 4430 3437 4330 3034 2036 3941 3837  43D047C004.69A87

3034 3944 4531 4239 4341 4444 4338 4541  049DE1B9CADDC8EA

3731 3339 3241 4436 4533 4100 0100 0000  71392AD6E3A.....

0d00 0000 0d41 5554 485f 5041 5353 574f  .....AUTH_PASSWO

5244 4000 0000 4032 4434 4644 3937 3043  RD@...@2D4FD970C

3132 4439 3631 3837 3432 4534 3532 3543  12D9618742E4525C

3531 3431 3035 4530 4245 3234 4445 3735  514105E0BE24DE75

4330 3441 3043 3442 4636 4444 3436 4245  C04A0C4BF6DD46BE

3838 4133 3339 4500 0000 0008 0000 0008  88A339E.........

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:

for(int m=0; m<24; m++){

csk[m]=decr_srv_authsk[m+16] ^ decr_cl_authsk[m+16];

MD5(csk, 16, md1);

MD5(csk+16,8,md2);

memcpy(csk,md1,16);

memcpy(csk+16,md2,8);

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.

Bibliography
[1.]    Marlene T.; Aaron N. Oracle Security Handbook
[2.]    http://www.freelists.org/archives/dbsec/11-2006/msg00005.html
[3.]    David Litchfield The Oracle Hacker’s Handbook
[4.]    http://soonerorlater.hu/index.khtml?article_id=511
[5.]    http://www.petefinnigan.com/weblog/archives/00001097.htm
[6.]    Oracle Advanced Security
[7.]    Securing Oracle Network Traffic
[8.]    Stunnel

Credits

Special thanks go for Balázs Boda, Lajos Antal and Pete Finnigan.

APPENDIX – I

Figure 1 Example running of the proof of concept code

Disclaimer

The views expressed in this article are my own and not necessarily the views of my current, past or future employers.

	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)

Home Databases Advisories Contact	ora11g Initial analysis of Oracle native authentication version 11g László Tóth September, 21. 2007 Introduction 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: • if you have the password hash you can decrypt the password from the captured authentication data, • therefore off-line brute forcing is possible Password hash 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: memcpy(data,pwd,strlen((char)pwd)); memcpy(data+strlen((char)pwd),salt,10); SHA1(data,strlen((char*)pwd)+10,md); for(i=0;i<20;i++){ printf("%X",md[i]); } 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: 000c 0000 000c 4155 5448 5f53 4553 534b ......AUTH_SESSK 4559 6000 0000 6045 4439 3142 3937 4130 EY`...`ED91B97A0 3430 3030 4633 3236 4631 3734 3330 4136 4000F326F17430A6 3544 4143 4233 3043 4431 4546 3738 3845 5DACB30CD1EF788E 3645 4333 3130 3734 3242 3831 3145 3332 6EC310742B811E32 3131 3243 3043 3943 4333 3935 3534 4339 112C0C9CC39554C9 4330 3141 3039 3043 4239 3545 3935 4339 C01A090CB95E95C9 3431 3430 4332 3800 0000 000d 0000 000d 4140C28......... 4155 5448 5f56 4652 5f44 4154 4114 0000 AUTH_VFR_DATA... 0014 3746 4435 3242 4338 3041 4135 3833 ..7FD52BC80AA583 3636 3935 4434 251b 0000 1a00 0000 1a41 6695D4%........A 5554 485f 474c 4f42 414c 4c59 5f55 4e49 UTH_GLOBALLY_UNI 5155 455f 4442 4944 0020 0000 0020 3245 QUE_DBID......2E 3031 3334 3242 3139 3532 3139 4645 3345 01342B195219FE3E 3931 4245 4436 3432 3942 4339 4534 0000 91BED6429BC9E4.. 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: ff12 0000 00fe ffff fffe ffff ff05 7465 ..............te 7374 310c 0000 000c 4155 5448 5f53 4553 st1.....AUTH_SES 534b 4559 6000 0000 fe40 3430 4537 4238 SKEY`....@40E7B8 3643 3939 4634 4246 3144 3046 3137 3533 6C99F4BF1D0F1753 3843 3232 4542 4345 3035 3446 3546 3637 8C22EBCE054F5F67 3745 3242 3532 3134 3830 4631 4635 3631 7E2B521480F1F561 3433 4430 3437 4330 3034 2036 3941 3837 43D047C004.69A87 3034 3944 4531 4239 4341 4444 4338 4541 049DE1B9CADDC8EA 3731 3339 3241 4436 4533 4100 0100 0000 71392AD6E3A..... 0d00 0000 0d41 5554 485f 5041 5353 574f .....AUTH_PASSWO 5244 4000 0000 4032 4434 4644 3937 3043 RD@...@2D4FD970C 3132 4439 3631 3837 3432 4534 3532 3543 12D9618742E4525C 3531 3431 3035 4530 4245 3234 4445 3735 514105E0BE24DE75 4330 3441 3043 3442 4636 4444 3436 4245 C04A0C4BF6DD46BE 3838 4133 3339 4500 0000 0008 0000 0008 88A339E......... 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: for(int m=0; m<24; m++){ csk[m]=decr_srv_authsk[m+16] ^ decr_cl_authsk[m+16]; } MD5(csk, 16, md1); MD5(csk+16,8,md2); memcpy(csk,md1,16); memcpy(csk+16,md2,8); 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. Bibliography [1.] Marlene T.; Aaron N. Oracle Security Handbook [2.] http://www.freelists.org/archives/dbsec/11-2006/msg00005.html [3.] David Litchfield The Oracle Hacker’s Handbook [4.] http://soonerorlater.hu/index.khtml?article_id=511 [5.] http://www.petefinnigan.com/weblog/archives/00001097.htm [6.] Oracle Advanced Security [7.] Securing Oracle Network Traffic [8.] Stunnel Credits Special thanks go for Balázs Boda, Lajos Antal and Pete Finnigan. APPENDIX – I Figure 1 Example running of the proof of concept code Disclaimer The views expressed in this article are my own and not necessarily the views of my current, past or future employers.