• Home
• Presentations
• Articles

Initial analysis of Oracle native authentication version 11g

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..
000c 0000 000c 4155 5448 5f53 4553 534b  ......AUTH_SESSK

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.html?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