|
|
 | | |  | Rainbow Tables et support des caractères spéciaux sous Windows |  |
by Guillaume Lehembre (17/04/08)
---[ Rainbow Tables et support des caractères spéciaux sous Windows ]---
---[ 1. Introduction ]--------------------------------------------------
Le principe de tables Rainbow [1] est connu depuis longtemps et leur
efficacité sur des algorithmes sans graines (LM, NT, etc.) ou avec des
graines liées à l'identifiant (Oracle, MScash, etc.) ne se dément plus.
RainbowCrack [2] a été le premier logiciel implémentant le principe des
Rainbow Tables, suivi du logiciel OphCrack [3] qui apportait certaines
optimisations. Même des logiciels très populaires et accessibles à tous
comme Cain & Abel [4] ont intégré le support des Rainbow Tables.
Les tables disponibles publiquement ([5], [6] entre autres) sont
systématiquement générés pour des caractères anglo-saxons.
Cette brève détaille l'implémentations de caractères spéciaux, tels que
les accents français, dans RainbowCrack et apporte des recommandations
pour le stockage des empreintes sous Windows et le choix des mots de
passe. Elle fait suite à une intervention réalisée à la SSTIC07 lors des
Rump Sessions [7].
---[ 2. Les empreintes des mots de passe sous Windows ]-----------------
Deux algorithmes se côtoient pour le stockage non-réversible des mots de
passe des utilisateurs déclarés sur des sytèmes d'exploitation de type
Windows : Lan Manager (LM) et NT.
2.1 Les empreintes Lan Manager (LM)
L'algorithme permettant le calcul des empreintes LM repose sur le
chiffrement d'une chaîne connue par une clé générée à partir du mot de
passe de l'utilisateur :
Le détail de cet algorithme est le suivant :
1. Le mot de passe est tronqué à 14 caractères ;
2. Si il n'est pas assez long, il est complété avec des caractères nuls ;
3. Le mot de passe est simplifié : convertion d'une chaîne de caractères
Unicode en une chaîne ASCII et simplication des caractères pour ne
conserver que les caractères dits "OEM" [ avec entre autre la mise en
majuscule systématique ] ;
4. Il est ensuite tronqué en deux parties de 7 caractères ;
5. Chaque partie indépendante est utilisée comme une clé de chiffrement
DES 56 bits pour chiffrer la chaîne fixe "KGS!@#$%" ;
6. Les deux résultats de 8 octets sont concaténés pour donner l'empreinte
LM de 16 octets.
Les empreintes LM présentent plusieurs lacunes :
- Non utilisation de graines ("seed" en anglais) permettant de réaliser des
attaques par dictionnaires pré-calculés : principe des Rainbow Tables ;
- Le mot de passe est de longueur bornée (14 caractères), la complexité
est équivalente à deux mots de passe de 7 caractères de part la
construction de l'empreinte LM ;
- La complexité est diminuée du fait de l'utilisation de caractères OEM ;
- Il est possible de savoir très facilement si le mot de passe fait
moins de 7 caractères en comparant la seconde partie de l'empreinte
par rapport à une certaine constante.
Le nombre de combinaisons possibles est de 2 * 166^7 = 6,95 * 10^15 (il
y a 166 caractères différents après convertion en OEM)
2.2 Les empreintes NT
L'algorithme NT utilise la fonction de hachage MD4 pour générer une
empreinte de 16 octets. Le mot de passe est ici limité à 128 caractères
puis passé en Unicode, aucune simplification d'alphabet n'est
nécessaire. Cet algorithme a été introduit à partir de Windows NT 3.5
côté postes serveurs et dans Windows Millenium côté postes clients.
Une nouvelle fois, le calcul des empreintes NT ne fait pas intervenir
de graine, rendant toujours possible la création de dictionnaires
pré-calculés.
Le nombre de combinaisons possibles est ici de 256^14 = 5,19 * 10^33 ce
qui est sans comparaison avec le chiffre obtenu pour les empreintes LM.
2.3 La cohabitation des deux types d'empreintes
Par défaut, les empreintes NT cohabitaient avec les empreintes LM jusqu'à
Windows Vista. Windows Vista ne stocke plus ces empreintes LM mais les
calcule toujours en mémoire comme l'a montré Aurélien Bordes lors de sa
présentation intitulée « Secrets d'authentification sous Windows » au
SSTIC07 [8].
Les empreintes stockées peuvent être révélées à l'aide d'outils
spécifiques comme pwdump [9] ou fgdump [10] ou des outils plus
polyvalents comme Cain & Abel [4].
---[ 3. Rappel sur le fonctionnement des Rainbow Tables ]---------------
3.1 Introduction
Le principe de fonctionnement des Rainbow Tables est détaillé dans
plusieurs articles ([1], [11] et [12] en particulier). Ce paragraphe a
simplement comme vocation d'en extraire les grandes lignes.
Plusieurs possibilités sont envisageables pour casser l'empreinte d'un
mot de passe :
- Calculer l'empreinte de chaque mot de passe "candidat" suivant
l'algorithme utilisé et la comparer avec l'empreinte du mot de
passe à casser pour savoir si le mot de passe a été découvert. Cette
approche qu'on peut qualifier d'attaque exhaustive (brute-force) peut
nécessiter un temps de calcul très important en fonction de la
complexité des mots de passe. Dans la pratique, cette méthode est
souvent précédée d'une attaque par dictionnaire.
- Stocker tous les couples de mots de passe et d'empreintes associées
dans des tables triées. Pour un jeu de caractères complexe, la
quantité de mémoire nécessaire n'est plus dans le domaine du possible
mais le temps de cassage des mots de passe est très faible.
- Utiliser une méthode intermédiaire en stockant une partie des résultats
dans des tables et en effectuant un minimum de calculs, c'est donc un
compromis entre le temps (de calcul) et la mémoire.
Le principe du compromis temps mémoire (time-memory tradeoff) a été
inventé par Martin Hellman en 1980 et amélioré par de nombreux
chercheurs. En 2003, Philippe Oechslin inventa une variante beaucoup
plus rapide et démontra son efficacité pour le cassage des mots de
passe (en particulier sur les empreintes LM Windows), il nomma les
tables Rainbow Tables.
La génération des tables est une opération coûteuse en temps (bien plus
que le brute-force) mais rentable car le cassage des mots de passe est
ensuite très rapide. Seuls les mots de passe générés à partir
d'algorithmes sans graine (LM, NT, etc.) ou avec des graines liées à
l'identifiant (Oracle, MScache, etc.) sont susceptibles d'être cassés
via les Rainbow Tables. L'ajout d'une composante aléatoire (appelée
graine ou sel) rend inutile les Rainbow Tables : c'est le cas par défaut
sur les systèmes Linux avec l'utilisation de l'algorithme MD5 combiné à
une graine.
alice:$1$sVgP3DAm$68mmj7qv.PFAr6On2ZHx70:13025:0:99999:7:::
^ <------> <-------------------->
| | |---------------- Empreinte
| |-------------------------------- Graine
|------------------------------------- Algorithme (MD5 ici)
$ openssl passwd -1 -salt sVgP3DAm secret
$1$sVgP3DAm$68mmj7qv.PFAr6On2ZHx70
La graine permet de diversifier l'empreinte comme le montre la commande
suivante qui utilise le même mot de passe avec une autre graine :
$ openssl passwd -1 -salt sVgP3DAp secret
$1$sVgP3DAp$HSdu.x.OLdWufPBadkJPJ0
3.2 Un peu de théorie sur les Rainbow Tables (pour les gens courageux)
Pour en revenir aux Rainbow Tables, la clé de voûte du compromis temps
mémoire est l'utilisation d'une fonction de réduction pour générer des
chaînes. Une fonction de réduction est une fonction arbitraire générant
un mot de passe à partir d'une empreinte. Une chaîne est composée d'une
succession d'empreintes et de mots de passe liés entre eux soit par
une fonction de hachage (mot de passe -> empreinte) soit par une
fonction de réduction (empreinte -> mot de passe). Le schéma suivant
illustre ce principe :
H R1 H R2 H R3
C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer
La fonction de hachage (notée H) est dépendante de l'algorithme pour
lequel les Rainbow Tables ont été calculées (LM, NT, MD5, SHA1,
etc.), elle est unique pour toutes les chaînes et pour toutes les
tables.
La fonction de réduction (notée R) est une fonction surjective
permettant de passer d'une empreinte donnée à un mot de passe dans le
jeux de caractères (charset) choisi lors de la génération des tables. La
spécificité des Rainbow Tables est d'utiliser une fonction de réduction
différente à chaque étape des chaînes (d'où R1, R2, etc.) et pas
uniquement différente entre les tables (comme c'était le cas dans les
premières implémentations des compromis temps-mémoire).
Seul le premier et le dernier mot de passe sont conservés dans les
Rainbow Tables, les mots de passe et empreintes intermédiaires
peuvent être retrouvés en appliquant la fonction de hachage et les
fonctions de réductions successives.
Plusieurs problèmes peuvent survenir dans les RainbowTables :
- la fusion : se produit quand la fonction de réduction donne le même
mot de passe pour deux empreintes différentes. Plus les chaînes sont
longues et plus on a de chance qu'une nouvelle chaîne fusionne avec
une chaîne déjà présente dans la table. Les mots de passe se trouvant
après le point de fusion n'apportent donc pas de nouveaux mots de passe.
L'utilisation de fonctions de réduction différentes à chaque étape des
chaînes permet de n'avoir des fusions que si le même mot de passe
redondant résulte de la même fonction de réduction. L'exemple suivant
montre une fusion entre C2 et C1 au niveau de la fonction de réduction
R2 :
H R1 H R2 H R3
C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer
C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer
^^^
Fusion
- une collision : c'est le cas d'une fusion qui intervient lorsque le
même mot de passe redondant résulte de fonctions de réduction
différentes. Les mots de passe se trouvant après le point de collision
peuvent encore apporter de nouveaux mots de passe.
L'exemple suivant montre une collision entre C3 et C2 (ou entre C3 et
C1 d'ailleurs) au niveau de la fonction de réduction R1 :
H R1 H R2 H R3
C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer
C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer
C3 : bty ---> h7 ---> oef ---> h3 ---> tab ---> h8 ---> zab
^^^
Collision
- les fausses alarmes : sont la conséquence d'une fusion quand on
recherche le mot de passe correspondant à une empreinte donnée (Cf
exemple dans l'explication d'une recherche dans les Rainbow Tables)
Le principe de recherche dans les Rainbow Tables est assez simple à
comprendre. Si on veut casser une empreinte donnée, il faut retrouver
cette empreinte dans nos Rainbow Tables. Comme nous l'avons dit
précédemment, seul le premier et le dernier mot de passe d'une chaîne
sont conservés dans les tables. L'idée est donc de retrouver le plus
rapidement possible la chaîne susceptible de contenir l'empreinte
recherchée. Pour cela, il est nécessaire de recontruire petit à petit
une chaîne à partir de notre empreinte en itérant successivement les
fonctions de réduction et la fonction de hachage et en prenant soin de
reconstruire cette chaîne candidate par la fin (afin d'optimiser les
temps de calcul). Une comparaison est réalisée entre le mot de passe
final de la chaîne candidate et les mots de passe de fin de chaîne
des Rainbow Tables. Si aucun mot de passe ne correspond, il faut
itérer à un rang supérieur (ie remonter à une fonction de réduction
antérieure) sinon une chaîne devant contenir notre empreinte a été
découverte. En reconstruisant la chaîne à partir du mot de passe
initial, on est censé retrouver l'empreinte recherchée et le mot de
passe associé.
Mais deux cas de figures peuvent survenir en recalculant l'intégralité
de cette chaîne :
- l'empreinte recherchée peut y être découverte, le mot de passe associé
est donc découvert ;
- l'empreinte recherchée peut ne pas être présente, c'est possible si
une fusion avec une autre chaîne est présente, on parle alors de
fausse alarme et il faut recommencer la recherche !
Prenons un exemple avec les chaînes dont nous avons déjà parlé pour
illustrer cette longue théorie sur la recherche dans les Rainbow Tables :
H R1 H R2 H R3
C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer
C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer
C3 : bty ---> h7 ---> oef ---> h3 ---> tab ---> h8 ---> zab
^^^ ^^^
Pour rappel, seul le premier et le dernier mot de passe sont
réellement conservés dans les Rainbow Tables, le reste peut être
recalculé rapidement, ce qui donne pour schématiser :
C1 : acd - aer
C2 : tuk - aer
C3 : bty - zab
Supposons que nous voulions casser l'empreinte h6. On commence par
appliquer la dernière fonction de réduction (R3 dans notre exemple)
sur l'empreinte que nous recherchons :
R3
h6 ---> nfy
Le mot de passe obtenu ("nfy") ne correspond à aucun mot de passe de fin
chaîne contenu dans nos tables, il faut donc remonter à la fonction de
réduction précédente (R2) :
R2 H R3
h6 ---> oef ---> h3 ---> aer
Cette fois-ci, le mot de passe obtenu ("aer") correspond au mot de passe
final de la chaîne C1. En reconstruisant la chaîne initiale nous
devrions trouver l'empreinte h6 et le mot de passe associé (celui qui
nous intéresse) :
H R1 H R2 H R3
C1 : acd ---> h1 ---> dec ---> h2 ---> oef ---> h3 ---> aer
^^^
Malheureusement, l'empreinte h6 ne fait pas partie de cette chaîne, une
fusion a eu lieu au niveau de la fonction de réduction R2 (l'empreinte
h2 est aussi réduite en "oef"). Nous sommes donc en présence d'une
fausse alarme, il faut continuer la recherche dans les chaînes
suivantes. La chaîne C2 a aussi comme mot de passe de fin de chaîne
"aer" mais cette fois-ci l'empreinte h6 est présente dans la chaîne
qu'on génère :
H R1 H R2 H R3
C2 : tuk ---> h5 ---> zep ---> h6 ---> oef ---> h3 ---> aer
^^^
Le mot de passe recherché est donc celui ayant généré l'empreinte h6 via
la fonction de hachage H, soit "zep".
Pour accélérer la recherche dans les Rainbow Tables, les chaînes d'une
table sont triées d'après leur fin.
Enfin pour en terminer avec la théorie, il existe des Rainbow Tables
"parfaites" dans lesquelles toutes les chaînes fusionnant sont
supprimées. Pour compenser le nombre de mots de passe uniques supprimés
avant la fusion, il est nécessaire de générer plus de chaînes ce qui
allonge sensiblement le temps de calcul. En revanche, le temps de
recherche dans ces tables est réduit et leur efficacité supérieure.
Des sites communautaires de génération de tables [5] ont maintenannt
tendance à les privilégier.
---[ 3. Découverte des caractères OEM associés ]------------------------
Les caractères spéciaux, et en particulier les accents, ne sont pas
découverts avec les Rainbow Tables classiques car celles-ci n'ont pas
été générées avec le bon jeu de caractères (charset). Il ne suffit pas
de rajouter les accents dans son jeu de caractères pour découvrir les
mots de passe en contenant.
Comme expliqué au chapitre 2.1, le mot de passe Unicode saisi par
l'utilisateur est tout d'abord simplifié pour ne conserver que les
caractères "OEM". Ce sont ces caractères OEM qu'on retrouve dans les
Rainbow Tables. La création d'un jeu de caractères adapté passe donc
par la découverte d'une table de correspondance entre les caractères
spéciaux et les caractères OEM associés. Là où ça se complique un peu,
c'est que la simplification vers les caractères OEM va dépendre de la
page de code (code page) OEM du système, c'est à dire concrètement de
la langue du système. Par exemple, la simplification OEM ne donnera
pas forcément le même caractère OEM sur un Windows français, anglais,
allemand ou autre ...
La table de correspondance peut être obtenue :
- D'une manière qu'on pourrait qualifier d'empirique : on extrait sur
un Windows d'une langue donnée les empreintes LM de mots de passe d'1
caractère comportant le caractère spécial qui nous intéresse. Les
empreintes sont ensuite cassées vis à vis d'une Rainbow Table générée
sur un charset complet et un nombre de caractères restreint. Il est
alors possible de faire l'association entre le caractère OEM découvert
dans les Rainbow Tables et le caractère ASCII spécial qu'on avait saisi
dans notre mot de passe.
- D'une manière beaucoup plus rationnelle : des recherches poussées sur
l'authentification Windows ([8] et [14]) ont permis de révéler des
fonctions d'API Windows non documentées parmis lesquelles :
* RtlUpcaseUnicodeStringToOemString (ntdll.dll) : fonction documentée
convertissant une chaîne de caractères ASCII (le mot de passe en
l'occurence) en chaîne de caractères ASCII simplifiée comportant que
des caractères OEM ;
* SystemFunction006 (advapi32.dll) : fonction convertissant une chaîne
de caractères ASCII OEM en empreinte LM.
La connaissance de ces fonctions (et en particulier de la première)
permet d'obtenir très rapidement les caractères OEM pour un code page
donné.
La table de correspondance présentée au paragraphe 4 détaille les
résultats obtenus sur des Windows en langue française et anglaise.
On s'aperçoit par exemple que pour le caractère "è" [0xE9] on obtient le
caractère OEM "E" [0x45] sur un Windows anglais et "Ô" [0xD4] sur une
version française. Par contre le caractère "é" [0xE9] donne le caractère
[0x90] sur les Windows anglais et français.
Une fois que les tables ont été générées avec le bon charset, seul un
problème d'affichage dans RainbowCrack subsiste. Des modifications
mineures du code (pour les versions 1.2 ou 1.2a) permettent d'obtenir un
affichage satisfaisant et la bonne du casse du mot de passe. Le patch
correspondant est publiquement disponible [0].
---[ 4. Table de correspondance ] --------------------------------------
Les recherches précédentes permettent d'obtenir la table de correspondance
suivante :
ASCII ASCII OEM EN ASCII OEM FR
-------- -------- --------
à [0xE0] A [0x41] · [0xB7]
À [0xC0] A [0x41] · [0xB7]
â [0xE2] A [0x41] ¶ [0xB6]
 [0xC2] A [0x41] ¶ [0xB6]
ç [0xE7] [0x80] [0x80]
Ç [0xC7] [0x80] [0x80]
é [0xE9] [0x90] [0x90]
É [0xC9] [0x90] [0x90]
è [0xE8] E [0x45] Ô [0xD4]
È [0xC8] E [0x45] Ô [0xD4]
ê [0xEA] E [0x45] Ò [0xD2]
Ê [0xCA] E [0x45] Ò [0xD2]
ë [0xEB] E [0x45] Ó [0xD3]
Ë [0xCB] E [0x45] Ó [0xD3]
ï [0xEF] I [0x49] Ø [0xD8]
Ï [0xCF] I [0x49] Ø [0xD8]
î [0xEE] I [0x49] × [0xD7]
Î [0xCE] I [0x49] × [0xD7]
ô [0xF4] 0 [0x4F] â [0xE2]
Ô [0xD4] 0 [0x4F] â [0xE2]
ù [0xF9] U [0x55] ë [0xEB]
Ù [0xD9] U [0x55] ë [0xEB]
ü [0xFC] [0x9A] [0x9A]
Ü [0xDC] [0x9A] [0x9A]
û [0xFB] U [0x55] ê [0xEA]
Û [0xDB] U [0x55] ê [0xEA]
ÿ [0xFF] Y [0x59] Y [0x59]
Les Rainbow Tables supportant les accents français pour des Windows
anglais et français devront donc être générées à partir d'un charset
comportant 13 caractères OEM supplémentaires : 0x80, 0x90, 0x9A,
0xB6, 0xB7, 0xD2, 0xD3, 0xD4, 0xD7, 0xD8, 0xE2, 0xEA, 0xEB. Le choix
d'un charset pertinent et raisonnable va surtout dépendre de la
puissance de calcul disponible pour les générer. Un charset de 69
caractères (équivalent aux tables lm_alpha-numeric-symbol32-space)
comportant les ponctuations et caractères spéciaux les plus courants est
un choix judicieux pour un premier jeu de tables avec accents.
D'autres caractères spéciaux potentiellement intéressants sur un clavier
français sont accessibles facilement (ceux imprimés sur les claviers
français classiques), ils sont au nombre de 6. La découverte des codes
OEM associés à ces caractères est laissée aux lecteurs persévérants :-)
On notera bien évidemment que d'autres caractères (AltGr + <touche> ou
Alt + <code numérique>) sont possibles mais que ceux-ci représentent en
pratique un très faible pourcentage de caractères découverts dans les
mots de passe.
---[ 5. Recommandations ]-----------------------------------------------
On sait depuis longtemps que les empreintes LM font parti des "vieilles
casserolles" que se trimballe Windows depuis des années. On pensait le
problème réglé avec la sortie de Windows Vista mais les empreintes LM
sont toujours calculées et présentes en mémoire. Il est donc possible de
les extraire pour l'ensemble des sessions actives sur un système
compromis (Cf §8.1 de l'article [8]) et ce, quelque soit le système
Windows compromis (Vista compris).
Sur les systèmes antérieurs à Windows Vista, il est néanmoins recommandé
de ne plus stocker les empreintes LM [15] au niveau de la SAM locale et
de l'Active Directory et de supprimer celles existantes : soit en
forçant les utilisateurs à changer leur mot de passe une fois le
stockage des empreintes LM empêché, soit en les supprimant manuellement
à l'aide d'un outil comme ThashLM [16] (outil non supporté par Microsoft).
Il est aussi recommandé, dans la mesure du possible [17], d'éviter les
authentifications LM et NTLMv1 pour privilégier l'authentification
NTLMv2.
Même si les recommandations précédentes ne sont pas appliquées, il est
toujours possible d'empêcher le stockage des empreintes LM en :
- choisissant un mot de passe de 15 caractères minimum ;
- en utilisant le caractère euro dans un mot de passe, quel que soit sa
longueur.
Après avoir supprimé les empreintes LM, une politique de mot de passe
d'une longueur de 9 ou 10 caractères avec 3 critères de complexité
apparait être un bon compromis ... les Rainbow Tables NT avec un jeu
de caractères conséquent (lettres, chiffres) ne dépassant - pour
l'instant - pas 9 caractères.
---[ 6. Disponibilité des tables ]--------------------------------------
Les tables calculées NE SERONT PAS distribuées par HSC, que ce soit en
direct sur le site www.hsc.fr ou par le biais de logiciels P2P (Bittorrent
ou autres).
Néanmoins, cette brève détaille toutes les informations pour les
calculer soit-même et obtenir un affichage correct dans RainbowCrack (Cf
patch correspondant à cette brève [0] pour RainbowCrack 1.2 & 1.2a)
---[ 7. Conclusion ]----------------------------------------------------
Cette brève montre comment implémenter des caractères spéciaux (accents
ou autres) dans les Rainbow Tables. Elle met aussi en évidence la
corrélation entre la langue du système et les caractères OEM générés.
Avant la génération des tables Rainbow comportant ce type de caractères,
il est donc indispensable de :
- lister les caractères spéciaux qu'un utilisateur peut facilement
utiliser ;
- trouver les caractères OEM équivalents pour les langues fréquemment
utilisées dans le pays ;
- adapter le code source de Rainbowcrack pour obtenir un affichage
satisfaisant de certains caractères.
La connaissance du mot de passe en clair associé à une empreinte n'est
pas nécessaire pour se connecter à distance sur un système Windows, le
simple fait d'accéder aux empreintes permet de s'authentifier (Cf. outils
de la suite pshtoolkit [18]).
Néanmoins la connaissance des mots de passe en clair permet :
- de pouvoir réutiliser les mots de passe découverts sur d'autres
sytèmes ou applicatifs (très utile en test d'intrusion ...) ;
- d'évaluer la qualité des mots de passe ;
- de se construire de bons dictionnaires de mots de passe :-)
- de passer de bons moments en voyant certains mots de passe :-)
-- Guillaume Lehembre <Guillaume.Lehembre@hsc.fr> --
---[ 8. Références ]----------------------------------------------------
- [0] Patch rainbowcrack pour supporter les caractères spéciaux français
(accents ou autre) dans les Rainbow Tables
http://www.hsc.fr/~lehembre/breves/rainbowtables/rainbowcrack-1.2-french-accents-HSC.diff
- [1] « Making a Faster Cryptanalytic Time-Memory Trade-Off » - Philippe
Oechslin - http://lasecwww.epfl.ch/pub/lasec/doc/Oech03.pdf
- [2] Site officiel de RainbowCrack - Zhu Shuanglei
http://www.antsight.com/zsl/rainbowcrack/
- [3] OphCrack (Implémentation optimisée du principe des Rainbow Tables
par Philippe Oechslin - tables non compatibles avec celles de
RainbowCrack)
http://ophcrack.sourceforge.net/
- [4] Cain & Abel
http://www.oxid.it/
- [5] FreeRainbowTables - Calcul communautaire de RainbowTables &
RainbowTables en téléchargement libre
http://www.freerainbowtables.com
Mirroir en téléchargement direct : http://rainbowtables.ddl.cx/
- [6] RainbowTables du groupe Schmoo en téléchargement libre
http://rainbowtables.shmoo.com/
- [7] « Rainbow Tables et caractères accentués sous Windows » -
Rump Session SSTIC 07 - Guillaume Lehembre
http://www.hsc.fr/ressources/presentations/sstic07_rump_rainbow/
- [8] Secrets d'authentification sous Windows - SSTIC07 - Aurélien Bordes
http://actes.sstic.org/SSTIC07/Authentification_Windows/SSTIC07-Bordes-Secrets_Authentification_Windows.pdf
http://actes.sstic.org/SSTIC07/Authentification_Windows/SSTIC07-article-Bordes-Secrets_Authentification_Windows.pdf
- [9] pwdump6 - fizzgig
http://xxx.foofus.net/~fizzgig/pwdump/
- [10] fgdump - fizzgig
http://swamp.foofus.net/fizzgig/fgdump/
- [11] « Rainbow Tables : comment doper la vitesse de crackage des mots
de passe » - Philippe Oechslin, Cédric Tissières - Hakin9 2/2007 (21)
- [12] « How Rainbow Tables work »
http://kestas.kuliukas.com/RainbowTables/
- [13] « Les compromis temps-mémoire et leur utilisation pour casser les
mots de passe de Windows » - Philippe Oechslin, SSTIC04
http://lasecwww.epfl.ch/~oechslin/publications/sstic04.pdf
- [14] Fonctions non documentées de l'API Windows - DreamPackPL
http://www.d--b.webpark.pl/reverse01_en.htm
- [15] Suppression des empreintes LM dans la base SAM locale ou dans l'AD
http://support.microsoft.com/?kbid=299656
- [16] ThashLM - Outil de suppression des empreintes LM
http://www.toolcrypt.org/index.html?thrashlm
- [17] Limitations vis à vis du changement de valeur du paramètre
LMCompatibilityLevel
http://www.microsoft.com/technet/community/columns/secmgmt/sm1005.mspx
- [18] Pass-The-Hash Toolkit
http://oss.coresecurity.com/projects/pshtoolkit.htm
|
