Oracle native authentication version 9i and 10g

Introduction

In the recent years several papers were published about Oracle’s native authentication protocol and its weaknesses (e.g.: [1.] or [2.]). Those papers covered the 8i version of the protocol which is used by the thin driver in 9i and 10g. Programs have been released to exploit some of these weaknesses (e.g. [2.] or [3.]). The most detailed description can be found in [3.]. The excellent book explains the details of version 8.1.7.4 and says “the genereal process is the same on other oracle versions”.

The authentication protocol in the OCI driver was changed in 9i and changed again in 10g. There is not too much information available about these new protocols. This article shows at least two problems exist in the new protocols:

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

I did not analyze the cryptography used in the new versions, just used the Oracle’s own DLLs to prove the existing problems.

9i version

In the 9i version the AUTH_SESSKEY and AUTH_PASSWORD are twice as long as in 8i. They are 128bit long as you can see below:

0000050A  00 87 00 00 06 00 00 00  00 00 08 01 00 0c 00 00 ........ ........
0000051A  00 0c 41 55 54 48 5f 53  45 53 53 4b 45 59 20 00 ..AUTH_S ESSKEY .
0000052A  00 00 20 45 42 43 42 43  42 31 43 31 37 30 46 36 .. EBCBC B1C170F6
0000053A  36 34 45 30 38 31 33 39  37 46 30 37 43 34 43 30 64E08139 7F07C4C0
0000054A  39 32 30 00 00 00 00 04  01 00 00 00 00 00 00 00 920..... ........
0000055A  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00 ........ ........
000007D4  03 de 00 00 06 00 00 00  00 00 03 73 03 4c e0 dd ........ ...s.L..
000007E4  00 05 00 00 00 01 01 00  00 34 ef 12 00 0c 00 00 ........ .4......
000007F4  00 dc eb 12 00 c4 fb 12  00 05 74 65 73 74 31 0d ........ ..test1.
00000804  00 00 00 0d 41 55 54 48  5f 50 41 53 53 57 4f 52 ....AUTH _PASSWOR
00000814  44 20 00 00 00 20 32 36  43 35 35 39 35 33 44 31 D ... 26 C55953D1
00000824  44 30 43 38 36 35 33 44  46 39 38 45 41 33 43 41 D0C8653D F98EA3CA
00000834  37 41 44 43 30 43 00 00  00 00 08 00 00 00 08 41 7ADC0C.. .......A
00000844  55 54 48 5f 52 54 54 05  00 00 00 05 34 34 39 31 UTH_RTT. ....4491

The protocol is a typical challenge response protocol as in 8i but with longer key lengths. There is another interesting change. If we replace the AUTH_SESSKEY to a former one the client sends different AUTH_PASSWORD. Let’s see what happens when a 10g client connects to 9i server (every function is exported by oran10.dll):

The client sends the username and receives the AUTH_SESSKEY and decrypts it with ztvo5kd function. It uses the Oracle password hash.
Then the client with the decrypted key and clear text password calls the ztvo5pe function to encrypt the password. The ztvo5pe function generates random bytes with ztcr2rnd and after a couple of transformations extends the clear text password with it. That is why the client sends different AUTH_PASSWORD for the same AUTH_SESSEKEY.
The server calls ztvopd function to decrypt the AUTH_PASSWORD.

From the description above the most interesting point is that, the longer AUTH_SESSKEY is encrypted with password hash as in 8i, 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 that uses the oran10.dll’s exported functions and an example running can be found in the appendix. If you do not have the password hash you can initiate an off-line brute-force attack, because the Oracle password hash generation is already well known and several tools are available (e.g.: [4.]) which can do it for you.

10g version

In the 10g version the AUTH_SESSKEY and AUTH_PASSWORD are even longer and the client sends another AUTH_SESSKEY to the server as you can see below:

00000265  00 e1 00 00 06 00 00 00  00 00 08 02 00 0c 00 00 ........ ........
00000275  00 0c 41 55 54 48 5f 53  45 53 53 4b 45 59 40 00 ..AUTH_S ESSKEY@.
00000285  00 00 40 43 32 39 33 34  33 34 42 30 35 37 34 45 ..@C2934 34B0574E
00000295  39 45 30 33 41 39 35 44  35 36 43 31 42 46 42 36 9E03A95D 56C1BFB6
000002A5  32 43 31 38 32 38 35 34  33 46 37 39 36 42 44 33 2C182854 3F796BD3
000002B5  41 32 41 32 31 37 32 39  37 31 34 42 45 36 42 30 A2A21729 714BE6B0
000002C5  39 36 45 00 00 00 00 0d  00 00 00 0d 41 55 54 48 96E..... ....AUTH
000002D5  5f 56 46 52 5f 44 41 54  41 00 00 00 00 39 09 00 _VFR_DAT A....9..
000002E5  00 04 01 00 00 00 02 00  01 00 00 00 00 00 00 00 ........ ........
000005C2  04 53 00 00 06 00 00 00  00 00 03 73 03 4c d0 dd .S...... ...s.L..
000005D2  00 05 00 00 00 01 01 00  00 34 ef 12 00 0d 00 00 ........ .4......
000005E2  00 dc eb 12 00 c4 fb 12  00 05 74 65 73 74 31 0c ........ ..test1.
000005F2  00 00 00 0c 41 55 54 48  5f 53 45 53 53 4b 45 59 ....AUTH _SESSKEY
00000602  40 00 00 00 40 35 30 30  36 41 44 37 41 35 46 43 @...@500 6AD7A5FC
00000612  46 35 32 45 30 30 31 33  33 43 44 44 34 30 37 35 F52E0013 3CDD4075
00000622  45 31 30 37 32 33 30 37  37 42 31 30 33 38 38 32 E1072307 7B103882
00000632  37 43 38 41 35 36 30 30  43 44 41 38 34 46 45 32 7C8A5600 CDA84FE2
00000642  34 35 46 33 37 01 00 00  00 0d 00 00 00 0d 41 55 45F37... ......AU
00000652  54 48 5f 50 41 53 53 57  4f 52 44 40 00 00 00 40 TH_PASSW ORD@...@
00000662  42 34 35 44 32 33 37 36  34 37 33 33 45 46 42 30 B45D2376 4733EFB0
00000672  43 36 33 41 43 44 45 45  35 38 36 31 42 45 39 33 C63ACDEE 5861BE93
00000682  43 36 34 36 35 33 43 43  43 33 39 43 43 41 37 42 C64653CC C39CCA7B
00000692  35 30 36 45 37 30 45 44  32 30 44 43 32 41 30 43 506E70ED 20DC2A0C
000006A2  00 00 00 00 08 00 00 00  08 41 55 54 48 5f 52 54 ........ .AUTH_RT
000006B2  54 06 00 00 00 06 31 32  30 35 34 31 00 00 00 00 T.....12 0541....

Let’s see what happens when a 10g client connects to a 10g server (every function is exported by oran10.dll):

The client sends the username and receives the AUTH_SESSKEY and decrypts it with ztvo5kd function. It uses the Oracle password hash.
Then the client calls the ztvo5kcs to combine the decrypted AUTH_SESSKEY from the server and a generated key. The two keys are XORed and the final key will be the MD5 hash of the XOR result.
Then the client calls ztvo5ke to encrypt its generated key with password hash. The result will be sent as the AUTH_SESSKEY of the client.
The next step is the password encryption with the result of the ztvo5kcs (because of the MD5 it is 128bit long). The called function is the ztvo5pe.
The server receives the AUTH_SESSKEY of the client and the AUTH_PASSWORD.
The AUTH_SESSKEY of the client is decrypted using the password hash with the ztvo5kd function.
Then the server combines the decrypted value with its generated key (decrypted AUTH_SESSKEY of the server) with ztvo5kcs.
With the result, it decrypts the AUTH_PASSWORD. (ztvotpd)

So we can say the situation is the same as with 9i version. The AUTH_SESSKEYs are encrypted with password hash as in 8i, 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 that uses the oran10.dll’s exported functions and an example running can be found in the appendix. If you do not have the password hash you can initiate an off-line brute-force attack, because the Oracle password hash generation is already well known and several tools are available (e.g.: [4.]) which can do it for you.

Password change in SQLPLUS

In sqlplus the password command can be used to change the password. It should be used instead of the ALTER USER, because the password command sends the password in encrypted form ([8.]). Below you can see the beginning of a packet that changes the password of the test2 user (the command was issued by a DBA):

00001329  03 54 00 00 06 00 00 00  00 00 11 6b 21 82 00 00 .T...... ...k!...
00001339  00 02 01 00 00 01 00 00  00 03 73 22 58 f7 db 00 ........ ..s"X...
00001349  05 00 00 00 12 01 00 00  e8 db 12 00 07 00 00 00 ........ ........
00001359  90 d8 12 00 f0 dd 12 00  05 74 65 73 74 32 10 00 ........ .test2..
00001369  00 00 10 41 55 54 48 5f  4e 45 57 50 41 53 53 57 ...AUTH_ NEWPASSW
00001379  4f 52 44 40 00 00 00 40  34 45 37 31 38 32 33 33 ORD@...@ 4E718233
00001389  45 45 32 30 44 41 38 31  42 34 37 36 46 45 43 34 EE20DA81 B476FEC4
00001399  36 30 37 42 35 46 43 44  36 46 45 46 46 46 35 35 607B5FCD 6FEFFF55
000013A9  45 37 35 34 37 44 45 36  37 41 44 35 42 33 31 34 E7547DE6 7AD5B314
000013B9  43 37 46 45 33 33 38 33  00 00 00 00 0d 00 00 00 C7FE3383 ........
000013C9  0d 41 55 54 48 5f 54 45  52 4d 49 4e 41 4c 09 00 .AUTH_TE RMINAL..

The servers (9i and 10g) use the same functions to decrypt the new password as with the authentication and the key is the same. Therefore if you have the sniffed authentication data and you have the password hash you can decrypt the new password (and of course the brute force attack is feasible too). You can use the same proof of concept codes as with the authentication just use the AUTH_NEWPASSWORD as the AUTH_PASSWORD.

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 on the communication channel that means you need either Oracle Advanced Security [5.] or there are other alternative solutions with SSH [6.] 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://www.toolcrypt.org/index.html?t2bf
[5.] Red-Database-Security GmbH Fact sheet about Oracle database passwords http://www.red-database-security.com/whitepaper/oracle_passwords.html
[6.] Oracle Advanced Security http://www.oracle.com/technology/deploy/security/database-security/advanced-security/index.html
[7.] Securing Oracle Network Traffic http://www.dbspecialists.com/presentations/net8_security.html
[8.] Stunnel http://www.stunnel.org/examples/oracle.html
[9.] Passwords transmitted in clear text on SQL*Net http://www.petefinnigan.com/ramblings/passwords_in_clear_text.htm

Credits

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

APPENDIX – I

Example PoC running

	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 Presentations Articles	Oracle native authentication version 9i and 10g Introduction In the recent years several papers were published about Oracle’s native authentication protocol and its weaknesses (e.g.: [1.] or [2.]). Those papers covered the 8i version of the protocol which is used by the thin driver in 9i and 10g. Programs have been released to exploit some of these weaknesses (e.g. [2.] or [3.]). The most detailed description can be found in [3.]. The excellent book explains the details of version 8.1.7.4 and says “the genereal process is the same on other oracle versions”. The authentication protocol in the OCI driver was changed in 9i and changed again in 10g. There is not too much information available about these new protocols. This article shows at least two problems exist in the new protocols: * if you have the password hash you can decrypt the password from the captured authentication data, * therefore off-line brute forcing is possible I did not analyze the cryptography used in the new versions, just used the Oracle’s own DLLs to prove the existing problems. 9i version In the 9i version the AUTH_SESSKEY and AUTH_PASSWORD are twice as long as in 8i. They are 128bit long as you can see below: 0000050A 00 87 00 00 06 00 00 00 00 00 08 01 00 0c 00 00 ........ ........ 0000051A 00 0c 41 55 54 48 5f 53 45 53 53 4b 45 59 20 00 ..AUTH_S ESSKEY . 0000052A 00 00 20 45 42 43 42 43 42 31 43 31 37 30 46 36 .. EBCBC B1C170F6 0000053A 36 34 45 30 38 31 33 39 37 46 30 37 43 34 43 30 64E08139 7F07C4C0 0000054A 39 32 30 00 00 00 00 04 01 00 00 00 00 00 00 00 920..... ........ 0000055A 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 ........ ........ 000007D4 03 de 00 00 06 00 00 00 00 00 03 73 03 4c e0 dd ........ ...s.L.. 000007E4 00 05 00 00 00 01 01 00 00 34 ef 12 00 0c 00 00 ........ .4...... 000007F4 00 dc eb 12 00 c4 fb 12 00 05 74 65 73 74 31 0d ........ ..test1. 00000804 00 00 00 0d 41 55 54 48 5f 50 41 53 53 57 4f 52 ....AUTH _PASSWOR 00000814 44 20 00 00 00 20 32 36 43 35 35 39 35 33 44 31 D ... 26 C55953D1 00000824 44 30 43 38 36 35 33 44 46 39 38 45 41 33 43 41 D0C8653D F98EA3CA 00000834 37 41 44 43 30 43 00 00 00 00 08 00 00 00 08 41 7ADC0C.. .......A 00000844 55 54 48 5f 52 54 54 05 00 00 00 05 34 34 39 31 UTH_RTT. ....4491 The protocol is a typical challenge response protocol as in 8i but with longer key lengths. There is another interesting change. If we replace the AUTH_SESSKEY to a former one the client sends different AUTH_PASSWORD. Let’s see what happens when a 10g client connects to 9i server (every function is exported by oran10.dll): The client sends the username and receives the AUTH_SESSKEY and decrypts it with ztvo5kd function. It uses the Oracle password hash. Then the client with the decrypted key and clear text password calls the ztvo5pe function to encrypt the password. The ztvo5pe function generates random bytes with ztcr2rnd and after a couple of transformations extends the clear text password with it. That is why the client sends different AUTH_PASSWORD for the same AUTH_SESSEKEY. The server calls ztvopd function to decrypt the AUTH_PASSWORD. From the description above the most interesting point is that, the longer AUTH_SESSKEY is encrypted with password hash as in 8i, 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 that uses the oran10.dll’s exported functions and an example running can be found in the appendix. If you do not have the password hash you can initiate an off-line brute-force attack, because the Oracle password hash generation is already well known and several tools are available (e.g.: [4.]) which can do it for you. 10g version In the 10g version the AUTH_SESSKEY and AUTH_PASSWORD are even longer and the client sends another AUTH_SESSKEY to the server as you can see below: 00000265 00 e1 00 00 06 00 00 00 00 00 08 02 00 0c 00 00 ........ ........ 00000275 00 0c 41 55 54 48 5f 53 45 53 53 4b 45 59 40 00 ..AUTH_S ESSKEY@. 00000285 00 00 40 43 32 39 33 34 33 34 42 30 35 37 34 45 ..@C2934 34B0574E 00000295 39 45 30 33 41 39 35 44 35 36 43 31 42 46 42 36 9E03A95D 56C1BFB6 000002A5 32 43 31 38 32 38 35 34 33 46 37 39 36 42 44 33 2C182854 3F796BD3 000002B5 41 32 41 32 31 37 32 39 37 31 34 42 45 36 42 30 A2A21729 714BE6B0 000002C5 39 36 45 00 00 00 00 0d 00 00 00 0d 41 55 54 48 96E..... ....AUTH 000002D5 5f 56 46 52 5f 44 41 54 41 00 00 00 00 39 09 00 _VFR_DAT A....9.. 000002E5 00 04 01 00 00 00 02 00 01 00 00 00 00 00 00 00 ........ ........ 000005C2 04 53 00 00 06 00 00 00 00 00 03 73 03 4c d0 dd .S...... ...s.L.. 000005D2 00 05 00 00 00 01 01 00 00 34 ef 12 00 0d 00 00 ........ .4...... 000005E2 00 dc eb 12 00 c4 fb 12 00 05 74 65 73 74 31 0c ........ ..test1. 000005F2 00 00 00 0c 41 55 54 48 5f 53 45 53 53 4b 45 59 ....AUTH _SESSKEY 00000602 40 00 00 00 40 35 30 30 36 41 44 37 41 35 46 43 @...@500 6AD7A5FC 00000612 46 35 32 45 30 30 31 33 33 43 44 44 34 30 37 35 F52E0013 3CDD4075 00000622 45 31 30 37 32 33 30 37 37 42 31 30 33 38 38 32 E1072307 7B103882 00000632 37 43 38 41 35 36 30 30 43 44 41 38 34 46 45 32 7C8A5600 CDA84FE2 00000642 34 35 46 33 37 01 00 00 00 0d 00 00 00 0d 41 55 45F37... ......AU 00000652 54 48 5f 50 41 53 53 57 4f 52 44 40 00 00 00 40 TH_PASSW ORD@...@ 00000662 42 34 35 44 32 33 37 36 34 37 33 33 45 46 42 30 B45D2376 4733EFB0 00000672 43 36 33 41 43 44 45 45 35 38 36 31 42 45 39 33 C63ACDEE 5861BE93 00000682 43 36 34 36 35 33 43 43 43 33 39 43 43 41 37 42 C64653CC C39CCA7B 00000692 35 30 36 45 37 30 45 44 32 30 44 43 32 41 30 43 506E70ED 20DC2A0C 000006A2 00 00 00 00 08 00 00 00 08 41 55 54 48 5f 52 54 ........ .AUTH_RT 000006B2 54 06 00 00 00 06 31 32 30 35 34 31 00 00 00 00 T.....12 0541.... Let’s see what happens when a 10g client connects to a 10g server (every function is exported by oran10.dll): The client sends the username and receives the AUTH_SESSKEY and decrypts it with ztvo5kd function. It uses the Oracle password hash. Then the client calls the ztvo5kcs to combine the decrypted AUTH_SESSKEY from the server and a generated key. The two keys are XORed and the final key will be the MD5 hash of the XOR result. Then the client calls ztvo5ke to encrypt its generated key with password hash. The result will be sent as the AUTH_SESSKEY of the client. The next step is the password encryption with the result of the ztvo5kcs (because of the MD5 it is 128bit long). The called function is the ztvo5pe. The server receives the AUTH_SESSKEY of the client and the AUTH_PASSWORD. The AUTH_SESSKEY of the client is decrypted using the password hash with the ztvo5kd function. Then the server combines the decrypted value with its generated key (decrypted AUTH_SESSKEY of the server) with ztvo5kcs. With the result, it decrypts the AUTH_PASSWORD. (ztvotpd) So we can say the situation is the same as with 9i version. The AUTH_SESSKEYs are encrypted with password hash as in 8i, 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 that uses the oran10.dll’s exported functions and an example running can be found in the appendix. If you do not have the password hash you can initiate an off-line brute-force attack, because the Oracle password hash generation is already well known and several tools are available (e.g.: [4.]) which can do it for you. Password change in SQLPLUS In sqlplus the password command can be used to change the password. It should be used instead of the ALTER USER, because the password command sends the password in encrypted form ([8.]). Below you can see the beginning of a packet that changes the password of the test2 user (the command was issued by a DBA): 00001329 03 54 00 00 06 00 00 00 00 00 11 6b 21 82 00 00 .T...... ...k!... 00001339 00 02 01 00 00 01 00 00 00 03 73 22 58 f7 db 00 ........ ..s"X... 00001349 05 00 00 00 12 01 00 00 e8 db 12 00 07 00 00 00 ........ ........ 00001359 90 d8 12 00 f0 dd 12 00 05 74 65 73 74 32 10 00 ........ .test2.. 00001369 00 00 10 41 55 54 48 5f 4e 45 57 50 41 53 53 57 ...AUTH_ NEWPASSW 00001379 4f 52 44 40 00 00 00 40 34 45 37 31 38 32 33 33 ORD@...@ 4E718233 00001389 45 45 32 30 44 41 38 31 42 34 37 36 46 45 43 34 EE20DA81 B476FEC4 00001399 36 30 37 42 35 46 43 44 36 46 45 46 46 46 35 35 607B5FCD 6FEFFF55 000013A9 45 37 35 34 37 44 45 36 37 41 44 35 42 33 31 34 E7547DE6 7AD5B314 000013B9 43 37 46 45 33 33 38 33 00 00 00 00 0d 00 00 00 C7FE3383 ........ 000013C9 0d 41 55 54 48 5f 54 45 52 4d 49 4e 41 4c 09 00 .AUTH_TE RMINAL.. The servers (9i and 10g) use the same functions to decrypt the new password as with the authentication and the key is the same. Therefore if you have the sniffed authentication data and you have the password hash you can decrypt the new password (and of course the brute force attack is feasible too). You can use the same proof of concept codes as with the authentication just use the AUTH_NEWPASSWORD as the AUTH_PASSWORD. 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 on the communication channel that means you need either Oracle Advanced Security [5.] or there are other alternative solutions with SSH [6.] 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://www.toolcrypt.org/index.html?t2bf [5.] Red-Database-Security GmbH Fact sheet about Oracle database passwords http://www.red-database-security.com/whitepaper/oracle_passwords.html [6.] Oracle Advanced Security http://www.oracle.com/technology/deploy/security/database-security/advanced-security/index.html [7.] Securing Oracle Network Traffic http://www.dbspecialists.com/presentations/net8_security.html [8.] Stunnel http://www.stunnel.org/examples/oracle.html [9.] Passwords transmitted in clear text on SQL*Net http://www.petefinnigan.com/ramblings/passwords_in_clear_text.htm Credits Special thanks go for Balázs Boda, Lajos Antal and Pete Finnigan. APPENDIX – I


	Disclaimer 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 donctl@gmail.com.