News: Problème de sécurité sur les passwords 12c

  • Imprimer
Détails
Catégorie : News
Publié le dimanche 22 novembre 2015 19:57
Écrit par Administrator
Affichages : 58523

Dans l’article La sécurité des mots de passe de février 2013, j’expliquais qu’il était important d’avoir une gestion des mots de passe, car il était aisé de les casser et surtout en 10g car ils étaient chiffrés en DES et je conseillais de forcer la génération du mot de passe qu’au format 11g dans la base car il était généré en SHA1 et donc soit disant plus dur à casser. Hélas ce n’est pas/plus vrai. En lisant une présentation sur le bilan annuel des problèmes de sécurité sur Oracle rencontrés en 2015: Best of Oracle Security 2015 de red-database-security.com, j’ai découvert le projet hashCat. HashCat et oclHashCat est un casseur de mot de passe il supporte plein d’algorithme et j’ai testé et effectivement il fonctionne très bien.

HashCat n’utilise que le CPU mais oclHashCat utilise en plus les GPU de vos cartes graphiques (Nvidia ou AMD). Les mot de passe Oracle les plus rapide à casser avec oclHashCat (version Nvidia CudaHashCat) c’est le format SHA1 de la 11g suivi de de celui de la 10g en DES et enfin « logiquement » les mots de passe de la 12c au format PBKDF2/SHA512. Pour donner une idée, avec un monstre de seulement 18.500$ (8 Nvidia GTX Titan X et 2 Inel Xeon E5-2600V3) red-database-security.com met pour casse un mot de passe de 8 caractères (alphanumerique seulement):

  • 8 minutes pour la version 10g
  • 58 secondes !!! pour la version 11g
  • 60 jours pour la version 12c

Au la vue du résultat dans un premier temps, on peut se dire, il faut rapidement passer sur la 12c pour enfin sécuriser les mots de passe, la différence de temps de cracking est énorme entre la 11g et la 12c.

Mais hélas tout n’est pas aussi rose. C’est ce que nous allons voir.

Avant, un petit rappel, pour bien comprendre comment est stocké un mot de passe sous Oracle.

Il faut savoir :

  • que le chiffrage du mot de passe de la 7 à la 10gR2 est en DES et il est visible dans la vue dba_users (et table sys.user$) colonne password. Exemple : 5E6D5A131B65D193
  • que le chiffrage du mot de passe en 11gR1 et R2 est en SHA1, il est visible uniquement dans la table sys.user$ dans la colonne spare4. Exemple : S:30F89538ACC9A0539B50710C06FC4A5532406422F2E8EDDCB2954DFA2026
    • si la base est en 11.2.0.4 et  sqlnet.ALLOWED_LOGON_VERSION_SERVER <=11 alors le mot de passe est stocké dans sys.user$ dans la colonne password en DES et la colonne spare4 en SHA1
    •  si la base est en 11.2.0.4 et  sqlnet.ALLOWED_LOGON_VERSION_SERVER =12 alors le mot de passe est stocké dans sys.user$ et uniquement dans la colonne spare4 en SHA1
  • que le chiffrage du mot de passe en 12c (à partir de la 12.1.0.2) est en PBKDF2/SHA512, il est visible uniquement dans la table sys.user$ dans la colonne spare4 mais suivant le sqlnet. ALLOWED_LOGON_VERSION_SERVER il se partage la colonne avec celui en 11g. Exemple : S:30F89538ACC9A0539B50710C06FC4A5532406422F2E8EDDCB2954DFA2026;H:A6E9B61FDDA286EBCF62F99F7FEA9E7D;T:DE49BAB87D76ACEF0F0D76B
    406381A5B342AD420CCCC2BCD    80A47BEA0B5C0776659C14F285895AD85AEA8EA2C90FBAAE4D3A697F2FD099D0948943A5E1BBA86B902691E
    60E77D53E944A7D959A9B11DA.
    Ici il y a celui au format 11g c’est celui qui commence par S: et il y a la 12c celui qui commence  par T: , vous pouvez remarquer un qui commence par H: on en reparlera plus loin.
    • Si le paramètre ALLOWED_LOGON_VERSION_SERVER est à 11 (le défaut) alors le mot de passe est stocké en format 10g, 11g et 12c.
    • Si le paramètre ALLOWED_LOGON_VERSION_SERVER est à 12 alors le mot de passe est stocké en format  11g et 12c.
    • Si le paramètre ALLOWED_LOGON_VERSION_SERVER est à 12a alors le mot de passe est stocké en format  12c uniquement

 

Ce qui donne concrètement dans le cas d’un 12c :

[oracle@ora12cdb admin]$ cat sqlnet.ora    ### vide ou bien equivalent au defaut qui est
sqlnet.ALLOWED_LOGON_VERSION_SERVER=11

SQL> create user toto identified by "az%1T";

[oracle@ora12cdb admin]$ vi sqlnet.ora
sqlnet.ALLOWED_LOGON_VERSION_SERVER=12

SQL> create user TOTO_12 identified by "az%1T";

[oracle@ora12cdb admin]$ vi sqlnet.ora
sqlnet.ALLOWED_LOGON_VERSION_SERVER=12a

SQL> create user TOTO_12A identified by "az%1T";

SQL>col NAME format a10
SQL>col PASSWORD format a20
SQL>select name , nvl(password,'NULL') password , spare4 from user$ where name like 'TOTO%';

NAME      PASSWORD
---------- --------------------
SPARE4
--------------------------------------------------------------------------------
TOTO_10    973044B61026835C
S:0569CD726F085A25B4D8B880C0198EAECB9A4154AB9AA5E31D80E2EBE9A2;H:1E633A42B90A0AC
06138894E70ADEE74;T:A8334D1FB1793D8CB28473717D396B095F1EC1AD656242DAEBB5418963AE
787C96C3B30DFF39D61571A756DBF4FB4DA7C583C841611AD3A5A1426F3E4282AAF3848434A015E1
52756D442C303EB73D90

TOTO       2ADDF16B4E17123B
S:9B787E03E2A8AC6521FBF74BFE0DD200AB3B52D2053570318EBD74DA2F3F;H:990E4DEB457A00D
5C8E613D9AD525D7F;T:B587CEA6312ED069298096984D8B56344A5167397D97D524E5C4A4A20137
E326E48F96500BB8A4DCE935F993FA9BB0963DEBE52F7883AD8C9B558698ADE76F52E0768EE313D3
11227FF3ECFE9B2E7164

TOTO_12    NULL
S:4D64CE5C6963BCD6AB9E24D31034EEFCAB957B0DB6D0ABF7F61BDE1FCDCC;H:6C751E548031A96
4CC86FC96C1721403;T:1C168B40D6F9DD4191CEB9BDCFE2D6B8F01902E6CD149FFD3D2500EAAA6D
4402F54E750F7C9443F34B593326D5A7050112499CC62C4553164EEBF0D72398DE75D0384E7B2912
F477D6CD9296DD04EFC4

TOTO_12A   NULL
H:D807E39E93EA0F5D42A2B4A9A4888F63;T:99AC738D554ECDFBBE77660AE520AF649A5730078A0
B8E20C3CC2DC0894351D78BDAD3732D89C5376CBB5214E67380E9A87A1422A7C66E659411F824D5F
3534DAE80CF8441ACDCD851F60CB73B167DB

2 choses à retenir pour la suite

  • Dans tous les cas il y a le mot de passe au format 12c (le T: et aussi le H:)
  • Il est impossible de n’avoir que le format 10g ou bien que le format 11g.

 

Parlons maintenant de ce mot de passe H:. Le mot de passe H: c’est tout simplement le mot de passe hashé en MD5 sans sel (unsalted) !  Et il permet de casser encore plus rapidement le mot de passe que n’importe quel autre format généré dans la base de données, peut être aussi vite qu’en Oracle 6 ?

Si on reprend la même configuration  que décrite précédemment avec le même type de mot de passe (alphanum de 10 caractères) on obtient des temps de cracking de :

  • 8 minutes pour la version 10g
  • 58 secondes  pour la version 11g
  • 60 jours pour la version 12c  (avec  le T:)
  • 35 secondes pour la version 12c (avec le H:)

J’aurais souhaité faire fonctionner oclHashCat pour valider le différentiel de temps de craking sur mon PC, mais ma vielle carte graphique n’est pas compatible, elle est trop ancienne. Il y a HashCat que j’ai testé avec succès dans : Comment casser un mot de passe sans connexion à la base, mais il n’a pas, à priori pas, le brute force d’implémenté pour ce type.

Dans sa présentation Best of Oracle Security 2015 Red-database-security.com  conclut que le mot de passe 10g est encore le meilleur choix tant que le problème du mot de passe MD5 ne sera pas réglé. Oui mais il est impossible de demander à Oracle de ne générer que le mot de passe 10g comme vu précédemment.

Red-database-security.com propose aussi un workaround orginal : enlever le mot de passe  H: de la colonne spare4 et de voir avec Oracle si cela peut être supporté.

En tout cas le workaround semble très bien fonctionner …

select name , nvl(password,'NULL') password , spare4 from user$ where name = 'TOTO_12A';
NAME      PASSWORD
---------- --------------------
SPARE4
--------------------------------------------------------------------------------
TOTO_12A   NULL
H:D807E39E93EA0F5D42A2B4A9A4888F63;T:99AC738D554ECDFBBE77660AE520AF649A5730078A0
B8E20C3CC2DC0894351D78BDAD3732D89C5376CBB5214E67380E9A87A1422A7C66E659411F824D5F
3534DAE80CF8441ACDCD851F60CB73B167DB9

SQL>update user$ set SPARE4='T:99AC738D554ECDFBBE77660AE520AF649A5730078A0B8E20C3CC2DC0894351D78BDAD3732D89C
5376CBB5214E67380E9A87A1422A7C66E659411F824D5F3534DAE80CF8441ACDCD851F60CB73B167DB9'
where name='TOTO_12A';

SQL> connect TOTO_12A/az%1T@SHAKA
Connected.

… de là à le faire en production, oui il veut mieux demander au support Oracle. Mais en toute logique Oracle devrait corriger cela dans la prochaine PatchSet (12.1.0.3)… espérons-le !

 

{jcomments on}