HSC
Network Security Consulting Agency Since 1989 - Specialized in Unix, Windows, TCP/IP and Internet
Text mode: access to the page content
Hervé Schauer Consultants
You are here: Home > Resources > Tips > Rainbow Tables et support des caractères spéciaux sous Windows
Go to: HSC Trainings
Télécharger le catalogue des formations
Search:  
Version française
   Services   
o Skills & Expertise
o Consulting
o ISO 27001 services
o Audit & Assessment
o Penetration tests
o Vunerability assessment (TSAR)
o Forensics
o ARJEL
o Training courses
o E-learning
   Conferences   
o Agenda
o Past events
o Tutorials
   Resources   
o Thematic index
o Tips
o Lectures
o Courses
o Articles
o Tools (download)
o Vulnerability watch
   Company   
o Hervé Schauer
o Team
o Job opportunities
o Credentials
o History
o Partnerships
o Associations
   Press and
 communication
 
 
o HSC Newsletter
o Bulletin juridique HSC
o Press review
o Press releases
o Publications
   Contacts   
o How to reach us
o Specific inquiries
o Directions to our office
o Hotels near our office
|>|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



Last modified on 30 April 2008 at 14:05:37 CET - webmaster@hsc.fr
Mentions légales - Information on this server - © 1989-2013 Hervé Schauer Consultants