News: H: suite et fin
- Détails
- Catégorie : News
- Publié le lundi 20 novembre 2017 21:30
- Écrit par Administrator
- Affichages : 61041
J’avais publié le 22 novembre 2015, l'article News: Problème de sécurité sur les passwords 12c sur la facilité à casser les mots de passe de type H: dans sys.user$. Les mots de passes y étaient stockés en MD5 avec un secret. Et le 22 janvier 2016 dans l'article News: Le secret du H:, j’expliquais que ce secret été simple à trouver. Je proposais aussi de faire un update dans sys.user$ pour sortir (effacer) le stockage du mot de passe en MD5 de la base, mais alors cela provoquerait une perte de support d’Oracle, et qu’il valait mieux ouvrir un support à Oracle avant. Quelque temps plus tard, j’ai donc ouvert un support à Oracle faisant suite à ces deux articles, et cela c’était conclu de la part du support : il n’y avait de contournement possible et qu’effectivement le hash MD5 du mot de passe était faible.
Cette faiblesse de stockage de mot de passe a été corrigé dans le patch sécurité d’octobre 2016. Mais attention le passage de ce patch ne corrige pas le problème sur les anciens comptes générés avant le patch, il y a une action manuelle à faire qui correspond, qui grossièrement correspond à faire un update dans sys.user$ mais en passant par une nouvelle procédure fournit par oracle. Tout ceci est expliqué dans le document 2194116.1 sous Oracle support. On y apprend que le mot de passe était stocké en MD5 pour permettre l’authentification avec XDB HTTP(S), et un peu sous forme de mea culpa, Oracle reconnait que ce n’est plus très bien de faire cela.
Suite au passage du CPU d’octobre 2016 donc, tous les nouveaux comptes n’auront plus par défaut leur mot de passe stocké en « H: » et donc ne seront pas compatibles avec une authentification XDB HTTP(S), et tous les comptes générés avant son passage resteront compatibles avec XDB HTTP(S).
Avec ce patch de sécurité, la colonne PASSWORD_VERSION des vues DBA/CDB_USERS c’est enrichi d’une nouvelle donnée possible :HTTP, en plus des 3 déjà existante en 12c : 10G, 11G et 12C.
Avant le passage du PSU 12.1.0.2.161018 :
SQL> select distinct PASSWORD_VERSIONS from dba_users;
PASSWORD_VERSIONS
------------------------------
10G
11G
10G 11G 12C
Après passage du PSU 12.1.0.2.161018 sur la même base :
SQL> select distinct PASSWORD_VERSIONS from dba_users;
PASSWORD_VERSIONS
------------------------------
10G
11G
10G 11G 12C HTTP
Pour vérifier si un compte (ici WINROC) a son mot de passe stocké en MD5, vous pouvez exécuter la requête suivante :
SQL> select d.username,u.password,u.spare4, d.password_versions from sys.user$ u, dba_users d where u.name=d.username and u.name= 'WINROC';
Dans le cas d’une base de données non patché avec ce correctif de sécurité on obtient :
USERNAME PASSWORD SPARE4 PASSWORD_VERSI
---------------- -------------------- -------------------------------------------------- ------------
WINROC 175CE7AD7F2AE8C3 S:79B385AEBE6890B11C1B57B1540AC98527DE47699F9AFAAE 10G 11G 12C
21A42D7E3DC6;H:D53268B5F65EDE23E382A7144E6E02F8;T:
7DDAFC9205899745504B825EC76DCEFB4CA20F9A71D8A556A2
576408EE2E32BAA9E7A0CE2B12592F76B0A69697BAD9899873
3A1B92427A040FB7DBBEA945CAA807F43E7833BF40A03CDF4F
On vient bien ici, qu’il y a bien une section H: dans la colonne spare4 mais que le mot de passe n’est flaggé pour XDB HTTP(S) dans la colonne password_versions.
Dans le cas d’une base de données non patché avec ce correctif de sécurité on obtient :
USERNAME PASSWORD SPARE4 PASSWORD_VERSI
-------------- -------------------- -------------------------------------------------- ------------
WINROC 175CE7AD7F2AE8C3 S:79B385AEBE6890B11C1B57B1540AC98527DE47699F9AFAAE 10G 11G 12C HTTP
21A42D7E3DC6;H:D53268B5F65EDE23E382A7144E6E02F8;T:
7DDAFC9205899745504B825EC76DCEFB4CA20F9A71D8A556A2
576408EE2E32BAA9E7A0CE2B12592F76B0A69697BAD9899873
3A1B92427A040FB7DBBEA945CAA807F43E7833BF40A03CDF4F
Cette fois-ci on retrouve toujours la section H: dans la colonne spare4, mais il y a bien le flag HTTP dans la colonne password_versions.
Pour retirer alors le stockage en MD5 du mot de passe du compte WINROC, il suffit d’exécuter :
SQL> EXEC dbms_xdb_http_digest.disable_http_digest('WINROC');
On peut alors vérifier :
SQL> elect u.spare4, d.password_versions from sys.user$ u, dba_users d where u.username=d.username and u.username=WINROC ;
USERNAME PASSWORD SPARE4 PASSWORD_VERSI
-------------- -------------------- -------------------------------------------------- ------------
WINROC 175CE7AD7F2AE8C3 S:79B385AEBE6890B11C1B57B1540AC98527DE47699F9AFAAE 10G 11G 12C
21A42D7E3DC6;T:7DDAFC9205899745504B825EC76DCEFB4CA
20F9A71D8A556A2576408EE2E32BAA9E7A0CE2B12592F76B0A
69697BAD98998733A1B92427A040FB7DBBEA945CAA807F43E7
833BF40A03CDF4FA881215CE0
Pour retirer à l’ensemble des comptes de la base les mots de passe stocké en MD5:
SQL> exec DBMS_XDB_HTTP_DIGEST.disable_all_http_digest;
Dans le cas d’une architecture CDB, il faut le faire pluggable par pluggable, la commande ne se propage pas à travers les pluggable database.
Maintenant si comme dans News: Problème de sécurité sur les passwords 12c, on veut que les mots de passe soient stockés uniquement dans la version la plus sécurisée, celle de la 12c, on peut mettre le paramètre ALLOWED_LOGON_VERSION_SERVER à 12a dans le sqlnet.ora, il ne cohabitera enfin plus avec la version stocké en MD5. Attention il faut tout de même renouveler les mot de passe des comptes après la modification du sqlnet.ora pour prise en compte :
SQL> password winroc
Changing password for winroc
New password:
Retype new password:
Password changed
SQL> Select d.username,u.password,u.spare4, d.password_versions from sys.user$ u, dba_users d where u.name=d.username and u.name= 'WINROC';
USERNAME PASSWORD SPARE4 PASSWORD_VERSI
-------------- -------------------- -------------------------------------------------- ------------
WINROC T:95C1644B2CB8E8C4974007309C4DFCEF4B231250032B76BB 12C
38150ECD2B6414B180BA4112EFECB081E6C9E213B91D09DFE7
4DCBFE7C254FF5B365D7CAD7C6B9857902B3D13EDAEFED9D34
983EE83F7AF3
Il n’y plus la version 10g, mot de passe hashé en DES dans la colonne password, il n’y a plus la version 11g, hashé en SHA1 dans la colonne spare4 section S:, il n’y a plus la vilaine « verrue » en MD5, section H: de la colonne spare4, et enfin il ne reste plus que la version du mot de passe en PBKDF/SHA512.
Et voilà il a fallut attendre 3 ans après la sortie de la 12c pour que Oracle corrige cela, et qu’enfin le mot de passe soit stocké uniquement en PBKDF/SHA512 à la condition évidement que l’application soit compatible avec un client 12c.
PS : Alors vous avez trouvé le mot de passe de WINROC ?
{jcomments on}