Firefox et son trousseau de mot de passes

 druide

Firefox

Comme tous les navigateurs, Firefox nous proposent de stocker nos mots de passes d'accès aux différents sites que l'on visite. C'est une fonctionnalité bien pratique car au prochain passage sur le site, Firefox pré-remplira les champs « username » « password » pour nous. Plus besoin de se souvenir des mots de passes.

source:https://support.cdn.mozilla.net/

Mais où et comment Firefox stocke-t-il nos mots de passes ? Est-ce fiable ?

Le PATH

La première réponse est « dans notre profil utilisateur ». Sous Linux on le trouve dans
$HOME/.mozilla/firefox/xxxxxxxx.default
. La valeur des xxxxxxxx est à remplacer avec celle se trouvant dans le fichier profile.ini dans la clé Path

[General]
StartWithLastProfile=1

[Profile0]
Name=default
IsRelative=1
Path=zx12d1oo.default
Default=1

Soit dans mon cas
$HOME/.mozilla/firefox/zx12d1oo.default
. Dans ce répertoire, on trouve (entre autre) les fichiers key3.db, signons.sqlite ainsi que le fichier logins.json. Voilà pour le où ☑

signons.sqlite et logins.json

Pour le comment, l'affaire se corse un peu. Commençons par les fichiers signons.sqlite et logins.json.

C'est dans ces deux fichiers que se trouve les login/password sauvegardés. L'un se présente sous la forme d'une base de données SQLite3 et l'autre sous la forme d'un fichier JSON. Ça c'était plutôt facile à comprendre 😉. Dans les deux cas, Firefox stock les valeurs suivantes :

  • hostname (exemple: https://boutique.ed-diamond.com)
  • httpRealm (vide chez moi)
  • formSubmitURL (la valeur correspondant au champ « action » du formulaire)
  • usernameField (le nom du champ correspondant au username dans le formulaire)
  • passwordField (le nom du champ correspondant au password dans le formulaire)
  • encryptedUsername (le username crypté)
  • encryptedPassword (le password crypté)
  • ...


Les champs cryptés contiennent une valeur encodée en base64. C'est normale car il s'agit de valeurs étant passées à la moulinette du cryptage et donc, de valeurs contenants n'importe quel type d'octet, y.c. des octets non imprimables, voir non stockables sans avoir quelques soucis. La preuve, si on les dé-encodes, on obtient des choses tel que:


druide@druide:~$ echo MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECLydV29T/O24BBCa+6MtPQeunrXsqX57j+Sq | base64 -d
��WoS������-=�����~{�


Bon, ben comme ça on est pas plus avancé 😞, par contre, si on stock le résultat dans un fichier et qu'on demande à OpenSSL de le parser...


druide@druide:~$ echo MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECLydV29T/O24BBCa+6MtPQeunrXsqX57j+Sq | base64 -d > valeur.asn1
druide@druide:~$ openssl asn1parse -in valeur.asn1 -inform der
    0:d=0  hl=2 l=  58 cons: SEQUENCE          
    2:d=1  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:F8000000000000000000000000000001
   20:d=1  hl=2 l=  20 cons: SEQUENCE          
   22:d=2  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
   32:d=2  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:BC9D576F53FCEDB8
   42:d=1  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:9AFBA32D3D07AE9EB5ECA97E7B8FE4AA
C'est mieux! Il s'agit d'un encodage de type ASN1-DER. On apprend ainsi que nous avons affaire à un cryptage Triple DES en mode CBC ce qui demande donc de trouver 3 clés de 56bits chacune (3DES) et un vecteur d'initialisation IV de 8 octets (mode CBC).

key3.db

Demandons à file de quoi il retourne ?

druide@druide:~$ file .mozilla/firefox/zx12d1oo.default/key3.db 
key3.db: Berkeley DB 1.85 (Hash, version 2, native byte-order)
Il s'agit d'un base Berkeley version 1.85 dont on peut encore trouver le code source ICI. Dans l'archive, on trouve un dossier « hash » dans lequel figure le fichier hash.h.

Dans ce fichier, on trouve la structure de l'entête du fichier, soit:

/* Hash Table Information */
typedef struct hashhdr { /* Disk resident portion */
int magic; /* Magic NO for hash tables */
int version; /* Version ID */
u_int32_t lorder; /* Byte Order */
int bsize; /* Bucket/Page Size */
int bshift; /* Bucket shift */
int dsize; /* Directory Size */
int ssize; /* Segment Size */
int sshift; /* Segment shift */
int ovfl_point; /* Where overflow pages are being
* allocated */
int last_freed; /* Last overflow page freed */
int max_bucket; /* ID of Maximum bucket in use */
int high_mask; /* Mask to modulo into entire table */
int low_mask; /* Mask to modulo into lower half of
* table */
int ffactor; /* Fill factor */
int nkeys; /* Number of keys in hash table */
int hdrpages; /* Size of table header */
int h_charkey; /* value of hash(CHARKEY) */
#define NCACHED 32 /* number of bit maps and spare
* points */
int spares[NCACHED];/* spare pages for overflow */
u_int16_t bitmaps[NCACHED]; /* address of overflow page
* bitmaps */
} HASHHDR;

Comme il s'agit de valeur
int
, on peut facilement faire le lien avec le fichier hash.h si on affiche le contenu du fichier « key3.db » en ligne par paquet de 4 octets:

druide@druide:~$ hexdump -v -e '4/1 "%02X" "\n"' ../.mozilla/firefox/zx12d1oo.default/key3.db
00061561 int magic; /* Magic NO for hash tables */
00000002 int version; /* Version ID */
000004D2 u_int32_t lorder; /* Byte Order */
00001000 int bsize; /* Bucket/Page Size */
0000000C int bshift; /* Bucket shift */
00000100 int dsize; /* Directory Size */
00000100 int ssize; /* Segment Size */
00000008 int sshift; /* Segment shift */
00000001 int ovfl_point; /* Where overflow pages are being allocated */
00000002 int last_freed; /* Last overflow page freed */
00000001 int max_bucket; /* ID of Maximum bucket in use */
00000003 int high_mask; /* Mask to modulo into entire table */
00000001 int low_mask; /* Mask to modulo into lower half of table */
00010000 int ffactor; /* Fill factor */
00000004 int nkeys; /* Number of keys in hash table */
00000001 int hdrpages; /* Size of table header */

On peut donc trouver 4 clés (nkeys) dans des pages qui font 0x00001000 octets (bsize). La première page ira donc de 0x1000 à 0x1FFF, la seconde page ira de 0x2000 à 0x2FFF etc... On le voit mieux sur une sortie standard de la commande hd :

druide@druide:~$ hd ../.mozilla/firefox/zx12d1oo.default/key3.db 
00000000  00 06 15 61 00 00 00 02  00 00 04 d2 00 00 10 00  |...a............|  \
00000010  00 00 00 0c 00 00 01 00  00 00 01 00 00 00 00 08  |................|   \
00000020  00 00 00 01 00 00 00 02  00 00 00 01 00 00 00 03  |................|    \
00000030  00 00 00 01 00 01 00 00  00 00 00 04 00 00 00 01  |................|     \
00000040  95 6e 7d e3 00 00 00 00  00 00 00 02 00 00 00 02  |.n}.............|      \ HEADER
00000050  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|      /
*
000000c0  00 00 00 00 08 01 00 00  00 00 00 00 00 00 00 00  |................|    /
000000d0  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................|   /
*
00001000  06 00 f9 0f f8 0f ea 0f  b6 0f ab 0f 97 0f 85 0f  |................|\ OFFSETS
00001010  97 0f ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................| \
00001020  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|  \
*
00001f90  ff ff ff ff ff ff ff 2f  f7 0c 0c 2f 03 7b 69 d8  |......./.../.{i.|    \
00001fa0  a2 88 39 e1 5c de 3d d8  ce 69 1a 67 6c 6f 62 61  |..9.\.=..i.globa|     \ PAGE 1
00001fb0  6c 2d 73 61 6c 74 03 14  01 7b 89 50 d3 9a 1b ea  |l-salt...{.P....|     / 
00001fc0  56 c1 23 77 7b 0d 2d a1  e4 e1 d9 83 2c 00 0b 2a  |V.#w{.-.....,..*|    /
00001fd0  86 48 86 f7 0d 01 0c 05  01 03 38 a3 f3 90 cd 70  |.H........8....p|   /
00001fe0  21 d6 6c da cb ae 67 8e  7b da 70 61 73 73 77 6f  |!.l...g.{.passwo|  /
00001ff0  72 64 2d 63 68 65 63 6b  03 56 65 72 73 69 6f 6e  |rd-check.Version| /
00002000  02 00 f0 0f 5d 0f 53 0f  5d 0f 00 00 00 00 00 00  |....].S.].......|\
00002010  00 00 00 00 00 00 00 00  00 00 00 00 00 00 00 00  |................| \
*
00002f50  00 00 00 00 00 00 00 00  00 00 00 00 00 03 00 01  |................|   \
00002f60  00 30 81 8c 30 28 06 0b  2a 86 48 86 f7 0d 01 0c  |.0..0(..*.H.....|    \
00002f70  05 01 03 30 19 04 14 51  89 d4 d4 ed b0 bb 77 69  |...0...Q......wi|     \
00002f80  ea a0 03 60 55 1b c6 9d  95 a2 22 02 01 01 04 60  |...`U.....‘‘....`|      \ PAGE 2
00002f90  1b 92 be 84 7a 2c e7 4c  f7 a3 aa bc 35 af 33 66  |....z,.L....5.3f|      /
00002fa0  19 4b da d0 16 fa 54 fb  b1 9b f1 08 bb 6c 29 8f  |.K....T......l).|     /
00002fb0  f2 af b2 7c be e2 91 18  a4 31 6e 9c 68 b5 b9 55  |...|.....1n.h..U|    /
00002fc0  f9 25 52 69 00 2a 1c 45  f4 26 98 b5 4e b0 00 95  |.%Ri.*.E.&..N...|   /
00002fd0  50 82 0a 4b 52 a8 2c 48  9b 4f 4a 34 2f f4 7f 34  |P..KR.,H.OJ4/..4|  /
00002fe0  ce 85 9e cc 66 9d ce dc  7f a5 ba f7 6b e0 c7 a0  |....f.......k...| /
00002ff0  f8 00 00 00 00 00 00 00  00 00 00 00 00 00 00 01  |................|/
00003000  fd ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
00003010  ff ff ff ff ff ff ff ff  ff ff ff ff ff ff ff ff  |................|
*
00004000
Au début de chaque page se trouve les offsets auquel on peut trouver les pairs ValeurClé.

PAGE 1
OFFSET    |     ADRESSES   | VALEURS / CLE
0ff9 0ff8 | 0x1ff8...0x1ff9 | 0x03 / Version
0fea 0fb6 | 0x1fb6...0x1fea |  0314017b8950d39a1bea56c123777b0d2da1e4e1d9832c000b2a864886f70d010c05010338a3f390cd7021d66cdacbae678e7bda / password-check
0fab 0f97 | 0x1f97...0x1fab |  2ff70c0c2f037b69d8a28839e15cde3dd8ce691a / global-salt

PAGE 2
0ff0 0f5d | 0x2f5d...0x2ff0 | f8000000000000000000000000000001 / 
0300010030818c3028060b2a864886f70d010c050103301904145189d4d4edb0bb7769eaa00360551bc69d95a22202010104601b92be847a2ce74cf7a3aab
c35af3366194bdad016fa54fbb19bf108bb6c298ff2afb27cbee29118a4316e9c68b5b955f9255269002a1c45f42698b54eb0009550820a4b52a82c489b4f4a342
ff47f34ce859ecc669dcedc7fa5baf76be0c7a0


En résumé, on se retrouve avec 3 valeurs importantes :

  1. password-check
  2. global-salt
  3. f8000000000000000000000000000001 (qui semble être de nouveau une valeur au format ASN1-DER)


Il nous manque encore un valeur importante (si elle a été définie), le MASTER PASSWORD.


Si l'utilisateur n'a pas défini de master password alors autant dire que le chiffrement appliqué dans la base « signons.sqlite » ou dans le fichier « logins.json » ne sert à rien. Je vais prendre le cas où le master password est défini.

Pour poursuivre le travail, il faut d'abords aller faire un tour sur la page du Dr Stephen N Henson. Ce dernier nous explique comment dériver les clés et le IV.

Entry-salt (ES)

Il faut commencer par décomposer la valeur « password-check » ainsi:


password-check : 0314017b8950d39a1bea56c123777b0d2da1e4e1d9832c000b2a864886f70d010c05010338a3f390cd7021d66cdacbae678e7bda

header : 03
entry-salt size : 14
number of entry-salt : 01
entry-salt (ES) : 7b8950d39a1bea56c123777b0d2da1e4e1d9832c
separator : 00 0b
oid : 2a864886f70d010c050103
la chaîne "password-check" chiffrée avec les clés et IV en 3DES : 38a3f390cd7021d66cdacbae678e7bda


Si on parvient à dériver correctement les clés et IV, alors nous pourrons déchiffrer cette dernière valeur et obtenir la chaîne "password-check".

Dérivation

Pour dériver les clés et IV, il faut appliquer la suite d'opérations suivantes :


HP : « hashed password »
| : « concaténation »
PES : « padded entry-salt » (append zero bytes to ES until the result is 20 bytes long)

HP = SHA1(global-salt | MasterPassword)

Note: à partir d'ici, on peut effacer efficacement le mot de passe de la mémoire. Toutes les opérations peuvent se réaliser seulement avec HP.

CHP = SHA1( HP | ES )
k1 = HMAC-SHA1( key=CHP, msg=PES | ES )
tk = HMAC-SHA1( CHP, PES )
k2 = HMAC-SHA1( CHP, tk | ES )
k = k1 | k2

les 24 premiers octets de k sont la clé 3DES (en fait, la concaténation des 3) et les 8 derniers l'IV.


J'ai écrit un code source permettant le réalisation de chacune des étapes ci-dessus en m'appuyant sur la librairie OpenSSL.
On peut également réaliser chacune des tâches dans un shell mais il faut pouvoir manipuler des variables et faire des conversions d'hexadécimales/binaires ce qui n'est pas très pratique...

A titre d'exemple, voici la première étape HP = SHA1(global-salt | MasterPassword) en shell

druide@druide:~$ echo -e "import sys\nhex_gs='2ff70c0c2f037b69d8a28839e15cde3dd8ce691a'\nstrpass='p4ssw0rd'\ngs=hex_gs.decode('hex')\ncat=gs+strpass\nsys.stdout.write(cat)" \
 | python \
 | openssl dgst -sha1
(stdin)= c318f6ae1cfb7ea06f87180fd89b9ba1c0da62a8


Le programme complet en C réalise toutes les tâches d'un coup


druide@druide:~$ ./dumpf 
HP  = SHA1(global-salt | MasterPassword) = c318f6ae1cfb7ea06f87180fd89b9ba1c0da62a8
CHP = SHA1( HP | ES )                    = 0c4edb5ecbab318e8dc32c52b19010073c4b280b
k1  = HMAC-SHA1( key=CHP, msg=PES | ES ) = d4d7460f4304d124ed109d91fcc374dacd7bf040
tk  = HMAC-SHA1( CHP, PES )              = 9a4c3381bc928c6e69fa811fa958571ed1a38484
k2  = HMAC-SHA1( CHP, tk | ES )          = 802e9de68b363942dd16e0d1de049bbb97619ab5
key = FIRST 24 bytes of ( k1 | k2 )      = d4d7460f4304d124ed109d91fcc374dacd7bf040802e9de6
iv  = LAST 8 bytes of ( k1 | k2 )        = de049bbb97619ab5

Uncipher[14] : password-check
On voit que le programme réalise chacune des étapes pour trouver au final la clé (key) sur 24 octets (soit les 3 clés) et le vecteur IV. Une fois en possession de ces valeurs, il décrypte les bytes 38a3f390cd7021d66cdacbae678e7bda et trouve naturellement la chaîne "password-check".


À partir d'ici, on peut dire qu'on est possession du bon mot de passe ✌.

Clé privée


On peut maintenant s'attaquer à la clé privée (private key). Celle présente dans la "PAGE 2" du fichier « key3.db »


f8000000000000000000000000000001 / 
0300010030818c3028060b2a864886f70d010c050103301904145189d4d4edb0bb7769eaa00360551bc69d95a22202010104601b92be847a2ce74cf7a3aab
c35af3366194bdad016fa54fbb19bf108bb6c298ff2afb27cbee29118a4316e9c68b5b955f9255269002a1c45f42698b54eb0009550820a4b52a82c489b4f4a342
ff47f34ce859ecc669dcedc7fa5baf76be0c7a0


Comme dit plus haut, cela ressemble à un codage ASN1-DER, voyons cela :


    0:d=0  hl=2 l=   0 prim: BIT STRING        
    2:d=0  hl=2 l=   0 prim: BOOLEAN           Bad boolean
:-1
    4:d=0  hl=3 l= 140 cons: SEQUENCE          
    7:d=1  hl=2 l=  40 cons: SEQUENCE          
    9:d=2  hl=2 l=  11 prim: OBJECT            :1.2.840.113549.1.12.5.1.3
   22:d=2  hl=2 l=  25 cons: SEQUENCE          
   24:d=3  hl=2 l=  20 prim: OCTET STRING      [HEX DUMP]:5189D4D4EDB0BB7769EAA00360551BC69D95A222
   46:d=3  hl=2 l=   1 prim: INTEGER           :01
   49:d=1  hl=2 l=  96 prim: OCTET STRING      [HEX DUMP]:1B92BE847A2CE74CF7A3AABC35AF3366194BDAD016FA54FBB19BF108BB6C298FF2AFB27CBEE29118A4316E9C68B5B955
                                                          F9255269002A1C45F42698B54EB0009550820A4B52A82C489B4F4A342FF47F34CE859ECC669DCEDC7FA5BAF76BE0C7A0


Le premier OCTET STRING correspond au nouveau « entry-salt » permettant de rechercher, selon la même méthode que pour la chaîne « password-check », la nouvelle paire KEY / IV qui permettra de déchiffrer le second OCTET STRING.
En utilisant le même programme que précédemment :


HP  = SHA1(global-salt | MasterPassword) = c318f6ae1cfb7ea06f87180fd89b9ba1c0da62a8
CHP = SHA1( HP | ES )                    = e76e29dcf71bd5d12c00c53894c1e0b85370c3d7
k1  = HMAC-SHA1( key=CHP, msg=PES | ES ) = 344c75972a22f3a3cc444878377286e2fb40eec0
tk  = HMAC-SHA1( CHP, PES )              = 8f39b8e36d7e8332bb9cb22e6ae97d34e2c56197
k2  = HMAC-SHA1( CHP, tk | ES )          = cd88836ec8128f3f2955194833d478aef714633f
key = FIRST 24 bytes of ( k1 | k2 )      = 344c75972a22f3a3cc444878377286e2fb40eec0cd88836e
iv  = LAST 8 bytes of ( k1 | k2 )        = 33d478aef714633f

Uncipher[90] : 
3058020100300d06092a864886f70d010101050004443042020100021100
f8000000000000000000000000000001020100021838fe015745378f8a947
fb03ba115f4c29e7c3b0b9b8a15c4020100020100020100020100020115
Tient, le résultat ressemble encore une fois à un format ASN1-DER ? Avec apparemment une clé f8000000000000000000000000000001.


Essayons :


    0:d=0  hl=2 l=  88 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :00
    5:d=1  hl=2 l=  13 cons: SEQUENCE          
    7:d=2  hl=2 l=   9 prim: OBJECT            :rsaEncryption
   18:d=2  hl=2 l=   0 prim: NULL              
   20:d=1  hl=2 l=  68 prim: OCTET STRING      [HEX DUMP]:3042020100021100F8000000000000000000000000000001020100021838FE01
                                                          5745378F8A947FB03BA115F4C29E7C3B0B9B8A15C40201000201000201000201
                                                          00020115
Décidément 😝, la valeur OCTET STRING est encore un ASN1-DER

    0:d=0  hl=2 l=  66 cons: SEQUENCE          
    2:d=1  hl=2 l=   1 prim: INTEGER           :00
    5:d=1  hl=2 l=  17 prim: INTEGER           :F8000000000000000000000000000001
   24:d=1  hl=2 l=   1 prim: INTEGER           :00
   27:d=1  hl=2 l=  24 prim: INTEGER           :38FE015745378F8A947FB03BA115F4C29E7C3B0B9B8A15C4
   53:d=1  hl=2 l=   1 prim: INTEGER           :00
   56:d=1  hl=2 l=   1 prim: INTEGER           :00
   59:d=1  hl=2 l=   1 prim: INTEGER           :00
   62:d=1  hl=2 l=   1 prim: INTEGER           :00
   65:d=1  hl=2 l=   1 prim: INTEGER           :15


Yes, cette fois on y est. Voici la clé 3DES permettant de déchiffrer les entrées présentes dans « signons.sqlite » et/ou « logins.json »

La preuve


Reprenons la valeur de départ plus haut dans ce document, correspondant à un mot de passe crypté


druide@druide:~$ echo MDoEEPgAAAAAAAAAAAAAAAAAAAEwFAYIKoZIhvcNAwcECLydV29T/O24BBCa+6MtPQeunrXsqX57j+Sq | base64 -d > valeur.asn1
druide@druide:~$ openssl asn1parse -in valeur.asn1 -inform der
    0:d=0  hl=2 l=  58 cons: SEQUENCE          
    2:d=1  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:F8000000000000000000000000000001
   20:d=1  hl=2 l=  20 cons: SEQUENCE          
   22:d=2  hl=2 l=   8 prim: OBJECT            :des-ede3-cbc
   32:d=2  hl=2 l=   8 prim: OCTET STRING      [HEX DUMP]:BC9D576F53FCEDB8
   42:d=1  hl=2 l=  16 prim: OCTET STRING      [HEX DUMP]:9AFBA32D3D07AE9EB5ECA97E7B8FE4AA
Le premier OCTET STRING est constant avec la valeur F8000000000000000000000000000001 Le second OCTET STRING, vu sa taille, correspond certainement au vecteur IV. En effet, notre travail nous a fournit une clé, en fait les 3 clés pour le 3DES mais pour décrypter une valeur, nous aurons besoin également d'un vecteur IV. Le troisième OCTET STRING correspond au mot de passe encrypté. En résumé

On connaît :

La clé : 38FE015745378F8A947FB03BA115F4C29E7C3B0B9B8A15C4 Le vecteur : BC9D576F53FCEDB8 Le mot de passe crypté : 9AFBA32D3D07AE9EB5ECA97E7B8FE4AA


Il ne reste plus qu'à décrypter :


## On met le mot de passe crypté dans un fichier
druide@druide:~$ echo -e "import sys\nhex_str='9AFBA32D3D07AE9EB5ECA97E7B8FE4AA'\nbin_str=hex_str.decode('hex')\nsys.stdout.write(bin_str)" \
 | python > value_to_decode.bin
## On demande à OpenSSL de décrypter
druide@druide:~$ openssl enc -des-ede3-cbc -K 38FE015745378F8A947FB03BA115F4C29E7C3B0B9B8A15C4 -iv BC9D576F53FCEDB8 -in value_to_decode.bin -d
1BonP4ass

Conclusion

Malgré l'apparente complexité de ce travail, la sécurité du trousseau de mot de passe Firefox repose sur le Master Password, 2 SHA1 et 3 HMAC-SHA1 ce qui finalement n'est pas grand chose!

Si par malheur votre mot de passe se trouve dans la liste des mots de passe testé par un crackeur tel que John alors là, autant dire que vos mot de passes ne sont pas protégés du tout.

Le crack, démonstration

Le master password est définit à p4ssw0rd. John va tenté de le trouver à l'aide du « password-check » et du dictionnaire « rockyou.txt ».

On commence par préparer un fichier texte pour John, on configure John pour utiliser le bon dictionnaire et...


## Ça c'est le contenu qu'il faut placer dans le fichier texte pour John
druide@druide:~$ mozilla2john.py ~/.mozilla/firefox/zx12d1oo.default/key3.db 
key3.db:$mozilla$*3*20*1*7b8950d39a1bea56c123777b0d2da1e4e1d9832c*11*0000000000000000000000*16*38a3f390cd7021d66cdacbae678e7bda*20*2ff70c0c2f037b69d8a28839e15cde3dd8ce691a
## Comme ça c'est fait
druide@druide:~$ mozilla2john.py ~/.mozilla/firefox/zx12d1oo.default/key3.db > firefox.txt
## On configure John pour utiliser le fichier rockyou.txt
druide@druide:~$ cat john.conf | grep Wordlist
Wordlist = $JOHN/rockyou.txt
## En moins d'une seconde
druide@druide:~$ john firefox.txt 
Loaded 1 password hash (Mozilla, Mozilla key3.db [SHA1 3DES 32/64])
Will run 4 OpenMP threads
Press 'q' or Ctrl-C to abort, almost any other key for status
p4ssw0rd         (key3.db)
1g 0:00:00:00 DONE 2/3 (2015-09-14 10:46) 11.11g/s 585777p/s 585777c/s 585777C/s toutou..loser69
Use the "--show" option to display all of the cracked passwords reliably
Session completed
## Ce qui est finalement logique car
druide@druide:~$ cat rockyou.txt | grep p4ssw0rd
p4ssw0rd


Pour un mot de passe plus complexe, ou n'étant pas présent dans la liste de mots, le temps dépendra de la puissance de calcul...

Pour ma part, je ne pense pas laisser mes mots de passes dans ce trousseau...

That's all folks

Tags: firefox key3.db signons.sqlite 3DES

  • 4 years 1 month before
  • |