Protection des mots de passe par Firefox et Thunderbird : analyse par la pratique

Le gestionnaire de mots de passe de Firefox

Le Password Manager [1] de Firefox permet de stocker les mots de passe et identifiants (login) associés à un site web. Il s'agit par exemple des valeurs saisies dans les champs userid et pass de la page de connexion https://signin.ebay.fr. Au moment où l'on retourne sur une page dont le mot de passe est sauvegardé, Firefox préremplit les valeurs de ces champs. On suppose que dans un formulaire HTTP POST, lorsque le nom d'un premier champ contient user ou login, suivi par un deuxième champ nommé pass ou password (et de type password), Firefox les identifie alors comme paire login/mot de passe.

Le même site officiel [1] explique que ces mots de passe sont stockés dans les fichiers key3.db et signons.sqlite du profil utilisateur Firefox. Il est également recommandé d'utiliser un Master Password afin de protéger ces mots de passe.

Structure et contenu de Signons.sqlite

Intéressons-nous d'abord à ce dernier fichier, au format SQL, et examinons la structure de la table SQL moz_logins. Pour l'exemple précédent, les valeurs des colonnes les plus intéressantes sont :

On comprend donc comment sont stockés les mots de passe associés à chaque page. La question suivante est bien sûr : comment sont chiffrés les champs username et password ?

Choisissons une paire utilisateur/mot de passe complet. Nous garderons d'ailleurs cet exemple jusqu'à la fin de l'article, y compris pour le contenu de key3.db,

On reconnaît facilement l'encodage Base64 grâce à la suite ...AAAAAA..., encodant des octets nuls. Après décodage, chaque séquence de 80 caractères Base64 donne 60 octets, ici représentée comme séquence hexadécimale.

Les 2 valeurs sont encodées en ASN1 DER [2]. La syntaxe est type-longueur-valeur. Ici, respectivement 0x30, 0x32, puis la séquence de 50 octets 0410...1d11. Le type 0x30 est une séquence (SEQUENCE), le type 4 une chaîne d'octet (OCTETSTRING), le type 6 « OBJECT IDENTIFIER », etc.

Après décodage, la chaîne user se lit comme suit (les codes couleur pour les types et les valeurs sont conservés) :

et la chaîne passwd

Finalement, on obtient pour chaque enregistrement un triplet de 3 valeurs, dont la première f800....0001 est constante. L'Object Identifier (ou OID) signifie que l'algorithme de chiffrement utilisé [4] est 3DES EDE3 (avec 3 clés de 56 bits chacune) et en mode CBC, ce qui nécessite un vecteur d'initialisation (IV), qui pour 3DES est de 8 octets.

Justement, à chaque fois la deuxième chaîne d'octets (OCTETSTRING) fait 8 octets de long (peut être l'IV ?) et la deuxième chaîne possède une longueur multiple de 8, soit la taille du bloc de l'algorithme DES.

Nous y reviendrons plus tard, car il nous faut trouver la clé 3DES. Examinons donc le fichier key3.db.

Structure et contenu de key3.db

Cette base de données est de format Berkeley en version 1.85 [3].

key3.db contient quatre enregistrements dont les identifiants sont f8000000000000000000000000000001, Version, password-check et global-salt. Le Dr Stephen Henson [5] et Plakosh and Al. [6] expliquent comment utiliser la valeur password-check que voici, quelque peu « mise en forme » pour en faciliter l’interprétation :

Le 2e octet (en rouge) code la longueur du l'entry-salt qui commence à l'octet 4 (en bleu). Les 16 derniers octets représentent la chaîne de caractères password-check, chiffrée en 3DES CBC avec une clé dérivée du Master Password (qui peut être vide), du global-salt et de l'entry-salt. La valeur 2a86...0103 encode l'OID de l'algorithme utilisé, nous y reviendrons.

Ce format est partiellement décrit dans le code source (keydb.c) de la bibliothèque NSS de Netscape/Mozilla [8]. Pour la première fois, dès 1999, ce sont [5] et [6] qui décrivent l'algorithme de dérivation ; reprenons globalement la notation de [5], voir également la figure 1 :

Cet algorithme de dérivation de clé (voir figure 1), spécifique à Netscape, est implanté dans secpkcs5.c [9].

On vérifie donc la valeur de cette clé en déchiffrant les données de l'enregistrement password-check.

Soit, avec les valeurs global-salt et entry-salt

et un Master Password égal à MISC*, les valeurs pour l'algorithme 3DES résultantes sont :

ainsi selon la syntaxe PyCrypto :

la valeur en clair est bien password-check\x02\x02, avec le bourrage (ici, de type PKCS) nécessaire à DES, dont la taille des données doit être multiple de 64 bits.

Décodage et déchiffrement de la clé privée

Vous avez bien sûr remarqué la valeur f8000000000000000000000000000001 qui est à la fois l'identifiant d'un enregistrement dans key3.db et est également présente dans chaque triplet des valeurs username et password étudiées précédemment et stockées dans signons.slite. Vous avez deviné : c'est cet enregistrement de key3.db qui contient la clé privée permettant de déchiffrer les valeurs protégées dans signons.slite.À nouveau [5] et [6] nous aide à interpréter la valeur de la base de données dont la clé est f8000000000000000000000000000001 et dont la valeur, d'une longueur est de 147 octets (0x93), est mise en forme ci-dessous :

Le 2ème OCTETSTRING (72d5...e861) est à nouveau chiffré avec 3DES CBC, et le 1er OCTETSTRING (a8db...33ee) doit être utilisé comme valeur d'entry-salt pour en dériver la clé 3DES et son IV, de la même manière que pour la procédure de vérification du Master Password.

Ce format de données est finalement très proche de PKCS#12 V1.0, datant de 1999 [10]. Ainsi, l'IOD 1.2.840.113549.1.12.5.1.3 (pbeWithSha1AndTripleDES-CBC)correspond à la chaîne d'octets remarquée précédemment (2a864886f70d010c050103). PBE signifie Password Based Encryption, mais l’algorithme de dérivation décrit plus haut est bien spécifique à Netscape et non conforme à PKCS#5 [11] et PKCS#12 qui définissent les formats et ces algorithmes, dont le plus couramment utilisé aujourd’hui est PBKDF2.

Continuons, après déchiffrement avec

nous obtenons la valeur

qui est une nouvelle fois au format ASN1, ce qui donne :

et en décodant une dernière fois en ASN1 la chaîne d'octets :

On obtient enfin la clé privée tant recherchée, après avoir transformé le 2ème entier en une séquence qui doit faire 24 d'octets ! Il s'agit donc de la clé 3DES CBC qui permet de décoder les valeurs username et password. Mais, où trouver l'IV de 8 octets nécessaire au mode CBC ?

Déchiffrement des valeurs username et password

Revenons à l'objectif initial : déchiffrer les données stockées dans signons.sqlite. Nul besoin d'attendre plus longtemps, les 8 octets parmi les triplets contiennent bien l'IV à utiliser pour déchiffrer la 3ème suite d'octets de chaque triplet, ici 92ff4b0f04861d11.

Ainsi, avec les paramètres suivants :

il devient possible de déchiffrer le username :

ce qui donne : login\x03\x03\x03.Pour le mot de passe, le principe est identique, mais laissé en exercice. Une vue d'ensemble de toutes ces opérations est en figure 2.

Analyse du niveau de protection

Analysons maintenant l'algorithme de dérivation de clé via la figure 1. Bien sûr, sans « mot de passe principal », le niveau de protection est nul et le déchiffrement des login/mot de passe est immédiat.

Et combien faut-il d’opérations élémentaires cryptographiques pour tester un mot de passe lors d'une attaque par force brute ? Deux SHA1 et deux à trois HMAC-SHA1 par itération, les données dépendantes du mot de passe étant représentées par des flèches pleines, et données pré-calculables en pointillés. Cela est très peu, surtout que dès PKCS#5 v2 (1999), le nombre minimal d'itérations recommandé est 1000. À titre de comparaison, IOS 3 d'Apple (en 2009) utilisait 2000 itérations de PBKDF2 et 10000 avec IOS 4.0 pour protéger l'accès de l'iPhone [12].

Pourquoi une protection si modeste ? Certainement pour raison historique, car cet algorithme de dérivation de clé date de Netscape 4.x en 1997. Il faut se souvenir que les États-Unis interdisaient avant 2000 l'export de la cryptographie au-delà de 40 bits. Le code source de Netscape Communicator 5.0 a été publié en mars 1998 [13], mais sans la cryptographie. Netscape avec SSL RC4-128 bits (auparavant 40 puis 56 bits) a été autorisé à l'export seulement en mai 2000, avec la version 4.73.

Mais curieusement, après la description des formats et algorithmes faite en 1999, il faudra attendre 2006, et l'outil FireMaster [14] qui permet l'attaque par force brute du fichier key3.db. Cette fonctionnalité est intégrée dans John the Ripper depuis 2012 [15].

Afin d'être complets, Thunderbird et SeaMonkey utilisent la même protection des mots de passe. Il est à noter également qu'avec Windows 7 version entreprise, Firefox ne sauvegarde aucun mot de passe, même si l'option est activée.

Un dernier (algo)test pour la route ?

Il serait dommage de ne pas tester, à titre indicatif, combien de temps prend John the Ripper (1.7.9-jumbo-7) pour casser un mot de passe, non ? La machine utilisée est un ICore5/3230M @2.6 Ghz avec 6 Go de RAM, ce qui est loin d'être une formule 1. Le principe utilisé est de brute-forcer le « password check » vu plus haut.

Voici la ligne générée par l'outil mozilla2john.exe, à partir de key3.db, comme entrée pour john.exe :

On trouve, dans l'ordre : l'entry-salt (20 octets), l'OID de l'algorithme (11 octets, inutile ici), la chaîne password-check\x02\x02 chiffrée (16 octets) et enfin le global-salt (20 octets).

Conclusion

Nous avons appris avec cet article comment reconnaître des données en Base64 et ASN1, les formats et algorithmes utilisés pour protéger les mots de passe enregistrés par Mozilla. Il faut retenir que l'algorithme de dérivation de la clé utilisant le « Mot de passe Principal » de Mozilla est loin des standards actuels et donc à la portée d'une attaque par force brute.Je remercie le site root-me.org pour l'idée de cet article et ses nombreux challenges, et le Dr Stephen Henson pour les précisions historiques. Merci enfin aux relecteurs pour leurs conseils.

Références

[1] Mozilla support, Password Manager: http://support.mozilla.org/en-US/kb/password-manager-remember-delete-change-passwords, http://support.mozilla.org/en-US/kb/profiles-where-firefox-stores-user-data, http://support.mozilla.org/en-US/kb/use-master-password-protect-stored-logins

[2] ASN1 DER encoding : http://en.wikipedia.org/wiki/Distinguished_Encoding_Rules#DER_encoding

[3] Berkeley DB 1.85 source code : http://download.oracle.com/berkeley-db/db.1.85.tar.gz

[4] http://oid-info.com/get/1.2.840.113549.3.7

[5] Dr. Stephen Henson, August 4th 1999 : http://marc.info/?l=openssl-dev&m=93378860132031&w=2

[6] Into the Black Box: A Case Study in Obtaining Visibility into Commercial Software, D. Plakosh, S. Hissam, K. Wallnau, March 1999, Carnegie Mellon University : http://www.sei.cmu.edu/library/abstracts/reports/99tn010.cfm

[7] firepwd.py : https://github.com/lclevy/firepwd

[8] Private key database code from Netscape Security Service (NSS) library, février 2001, https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_2_1_RTM/src/nss-3.2.1/mozilla/security/nss/lib/softoken/keydb.c

[9] PKCS #5 Password based encryption code, NSS Library, janvier 2001 : https://ftp.mozilla.org/pub/mozilla.org/security/nss/releases/NSS_3_2_1_RTM/src/nss-3.2.1/mozilla/security/nss/lib/softoken/secpkcs5.c

[10] PKCS#12v1, Personal Information Exchange Syntax Standard, RSA labs : ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-12/pkcs-12v1.pdf

[11] PKCS#5v2, Password-Based Cryptography Standard, RSA labs, March 1999 : ftp://ftp.rsasecurity.com/pub/pkcs/pkcs-5v2/pkcs5v2-0.pdf

[12] Advanced Password Cracking, Vladimir Katalov, décembre 2010 : http://blog.crackpassword.com/2010/12/cracking-blackberry-backups-is-now-slower-but-still-possible-thx-to-gpu-acceleration/

[13] Netscape sets source code free, mars 1998 : http://news.cnet.com/2100-1001-209666.html

[14] FireMaster, Nagareshwar Talekar, janvier 2006 : http://seclists.org/basics/2006/Jan/18

[15] John the Ripper 1.7.9-jumbo-6 release, juin 2012 : http://www.openwall.com/lists/john-users/2012/06/29/1