Comprendre le cassage distribué avec John the Ripper

Introduction

Dans ce laboratoire, vous explorerez les aspects conceptuels du cassage de mots de passe distribué à l'aide de John the Ripper. Bien que nous n'allions pas mettre en place un environnement distribué en direct en raison de la complexité et des exigences en ressources, vous acquerrez une solide compréhension du fonctionnement du cassage distribué, des outils impliqués, ainsi que des défis et des avantages qu'il présente. Cette compréhension conceptuelle est cruciale pour toute personne intéressée par la cybersécurité, les tests d'intrusion ou la sécurité des mots de passe. Vous apprendrez les principes sous-jacents à la distribution des tâches de cassage, la manière dont différents outils s'intègrent à John the Ripper à cette fin, et les facteurs influençant les performances de tels systèmes.

Comprendre les concepts de cassage distribué

Dans cette étape, vous apprendrez les concepts fondamentaux du cassage de mots de passe distribué. Le cassage distribué implique l'utilisation de plusieurs ressources informatiques (machines, CPU, GPU) pour travailler collectivement sur le cassage d'un ensemble de hachages de mots de passe. Cette approche réduit considérablement le temps nécessaire pour casser les mots de passe par rapport à l'utilisation d'une seule machine, en particulier pour les mots de passe complexes ou longs.

L'idée principale est de diviser la charge de travail entre plusieurs "nœuds" ou "workers". Chaque worker reçoit une partie de l'espace de mots de passe (par exemple, une plage de mots de passe possibles ou un sous-ensemble de hachages) et tente de les casser indépendamment. Une fois qu'un worker trouve un mot de passe cassé, il le signale à un nœud "maître" ou "coordinateur" central.

Les concepts clés comprennent :

Distribution de la charge de travail (Workload Distribution) : Comment la tâche de cassage est divisée entre plusieurs machines. Cela peut être fait en attribuant différentes parties du dictionnaire, différents ensembles de caractères ou différents sous-ensembles de hachages à chaque worker.
Contrôle centralisé vs décentralisé (Centralized vs. Decentralized Control) : Comment les workers communiquent et rapportent les résultats. Dans un modèle centralisé, un nœud maître gère tous les workers. Dans un modèle décentralisé, les workers peuvent communiquer directement ou via une base de données partagée.
Scalabilité (Scalability) : La capacité d'ajouter plus de workers pour augmenter la vitesse de cassage.
Tolérance aux pannes (Fault Tolerance) : La capacité du système à continuer de fonctionner même si certains workers échouent.
Latence réseau (Network Latency) : Le délai de communication entre les nœuds, qui peut affecter les performances globales.

Considérez un scénario où vous avez une grande liste de hachages de mots de passe à casser. Au lieu d'une seule machine puissante essayant toutes les combinaisons possibles, vous pourriez avoir dix machines moins puissantes, chacune essayant 1/10ème des combinaisons. Ce traitement parallèle accélère considérablement le processus.

Pour illustrer, pensons à la manière dont une attaque par dictionnaire pourrait être distribuée. Si vous avez un fichier dictionnaire, vous pourriez le diviser en plusieurs fichiers plus petits, et chaque machine worker pourrait traiter l'un de ces fichiers dictionnaire plus petits contre les hachages cibles.

Conceptual Example:
Master Node:
  - Receives password hashes.
  - Divides dictionary file into chunks (e.g., dict_chunk_A, dict_chunk_B).
  - Assigns dict_chunk_A to Worker 1.
  - Assigns dict_chunk_B to Worker 2.
  - Collects cracked passwords from workers.

Worker 1:
  - Receives dict_chunk_A and hashes.
  - Runs John the Ripper with dict_chunk_A against hashes.
  - Reports cracked passwords to Master Node.

Worker 2:
  - Receives dict_chunk_B and hashes.
  - Runs John the Ripper with dict_chunk_B against hashes.
  - Reports cracked passwords to Master Node.

Cette compréhension conceptuelle constitue la base de l'exploration d'outils et de techniques spécifiques dans les étapes suivantes.

Explorer les outils pour le cassage distribué avec John the Ripper

Dans cette étape, vous explorerez les différents outils et méthodes utilisés pour faciliter le cassage distribué avec John the Ripper. Bien que John the Ripper lui-même soit un puissant outil de cassage sur un seul nœud, il ne dispose pas nativement de capacités de cassage distribué intégrées comme certains autres outils (par exemple, hashcat-utils de Hashcat pour les sessions distribuées). Par conséquent, le cassage distribué avec John the Ripper implique souvent des outils d'orchestration externes ou des scripts personnalisés.

Les approches et outils courants comprennent :

Scripts personnalisés (Bash/Python) : L'approche la plus flexible consiste à écrire des scripts personnalisés qui gèrent la distribution des tâches. Cela implique :
- La division de grandes listes de mots de passe ou de fichiers de hachages.
- La copie des données vers les nœuds workers (par exemple, en utilisant scp ou rsync).
- L'exécution de commandes John the Ripper sur les nœuds distants (par exemple, en utilisant ssh).
- La récupération des résultats des nœuds workers.
- Exemple : Un script maître pourrait se connecter via ssh aux machines workers, exécuter john --wordlist=part_X.txt hashes.txt, puis récupérer le fichier john.pot via scp.
Frameworks de calcul distribué : Pour des configurations plus complexes, des frameworks de calcul distribué à usage général peuvent être adaptés. Bien qu'ils ne soient pas spécifiquement conçus pour le cassage de mots de passe, ils peuvent gérer des tâches sur un cluster. Exemples :
- Celery (Python) : Une file d'attente de tâches distribuée qui peut être utilisée pour distribuer les commandes John the Ripper en tant que tâches aux nœuds workers.
- Apache Spark : Bien que disproportionné pour un cassage simple, il pourrait théoriquement être utilisé pour des opérations de cassage à très grande échelle et gourmandes en données.
Outils d'orchestration de cassage spécialisés : Certains outils sont conçus pour gérer le cassage distribué, prenant souvent en charge plusieurs moteurs de cassage.
- hashcat-utils de Hashcat (spécifiquement hccapx2john et potfile_merge) : Bien que principalement pour Hashcat, le concept de préparation des données pour le cassage distribué et de fusion des résultats est similaire. Pour John, vous vous concentreriez sur la distribution des fichiers d'entrée et la fusion des fichiers john.pot.
- Interfaces Web/API personnalisées : Pour les équipes plus importantes, une interface basée sur le Web pourrait être créée pour soumettre des travaux de cassage, surveiller la progression et récupérer les résultats d'un cluster d'instances John the Ripper.

Considérons un exemple conceptuel utilisant ssh et scp pour une configuration distribuée simple :

## Conceptual Master Script (on master machine)
## This script is for conceptual understanding only and will not be executed.

## Assume worker1 and worker2 are accessible via SSH
WORKERS="worker1 worker2"
HASH_FILE="hashes.txt"
DICTIONARY_FILE="rockyou.txt" ## Large dictionary

## Step 1: Split the dictionary file
## This would be done on the master or a shared storage
## For simplicity, let's assume we split it into 2 parts
## split -l 5000000 $DICTIONARY_FILE dict_part_

## Step 2: Distribute hash file and dictionary parts to workers
for WORKER in $WORKERS; do
  echo "Distributing files to $WORKER..."
  ## scp $HASH_FILE $WORKER:~/project/
  ## scp dict_part_aa $WORKER:~/project/ ## For worker1
  ## scp dict_part_ab $WORKER:~/project/ ## For worker2
done

## Step 3: Start cracking jobs on workers
## This would be done via SSH
## ssh worker1 "cd ~/project && john --wordlist=dict_part_aa $HASH_FILE" &
## ssh worker2 "cd ~/project && john --wordlist=dict_part_ab $HASH_FILE" &

## Step 4: Monitor and collect results
## This would involve checking john.pot files on workers and merging them
## scp worker1:~/project/john.pot john_worker1.pot
## scp worker2:~/project/john.pot john_worker2.pot
## cat john_worker1.pot john_worker2.pot > merged.pot

Ce script conceptuel met en évidence l'effort manuel impliqué dans l'orchestration de John the Ripper sur plusieurs machines. Des outils plus sophistiqués automatisent ces étapes.

Configuration d'un environnement de cassage distribué simple (Conceptuel)

Dans cette étape, vous configurerez conceptuellement un environnement de cassage distribué simple. Comme il s'agit d'un laboratoire conceptuel, nous ne provisionnerons pas de machines virtuelles ou de matériel physique réels. Au lieu de cela, nous décrirons les étapes et les considérations pour la mise en place d'un tel environnement, en nous concentrant sur l'architecture logique.

Une configuration conceptuelle typique implique :

Nœud Maître (Master Node) :
- Agit comme point de contrôle central.
- Stocke le fichier de hachages d'origine et potentiellement le dictionnaire/les listes de mots complets.
- Gère la distribution des tâches aux nœuds workers.
- Collecte et agrège les résultats des nœuds workers.
- Nécessite un client ssh, scp et des capacités de scripting (Bash, Python).
Nœuds Workers (2 ou plus) :
- Effectuent le travail de cassage réel.
- Reçoivent un sous-ensemble de hachages ou une portion de l'espace de mots de passe du maître.
- Exécutent des instances de John the Ripper.
- Stockent leurs fichiers john.pot (mots de passe cassés).
- Rapportent les résultats au maître.
- Nécessitent un serveur ssh, John the Ripper installé, et des ressources CPU/GPU suffisantes.

Étapes de configuration conceptuelle :

Configuration réseau : Assurez-vous que tous les nœuds maîtres et workers peuvent communiquer entre eux. Cela implique généralement la mise en place d'un réseau local ou la garantie de règles de pare-feu appropriées si vous utilisez des instances cloud. Pour simplifier, supposez qu'ils sont sur le même sous-réseau ou qu'ils peuvent s'atteindre via des adresses IP/noms d'hôtes.
Authentification par clé SSH : Pour le scripting automatisé, il est crucial de configurer l'authentification par clé SSH du nœud maître vers tous les nœuds workers. Cela permet au maître d'exécuter des commandes et de transférer des fichiers sans saisie manuelle de mot de passe.
- Sur le maître : ssh-keygen
- Copier la clé publique vers les workers : ssh-copy-id user@worker_ip
Installation de John the Ripper (Conceptuel) : Sur chaque nœud worker, John the Ripper devrait être installé. Pour ce laboratoire conceptuel, nous supposons qu'il est disponible.
Répertoire partagé (Optionnel mais recommandé) : Pour les configurations plus importantes, un système de fichiers réseau partagé (NFS, SMB) pourrait être utilisé pour stocker les fichiers de hachages, les dictionnaires et les fichiers john.pot, simplifiant ainsi la distribution et la collecte des données. Cependant, pour les configurations plus petites, scp est souvent suffisant.

Considérons un fichier ~/.ssh/config conceptuel sur le nœud maître pour simplifier les connexions SSH :

## Conceptual ~/.ssh/config on Master Node
## This file is for conceptual understanding only.

Host worker1
    Hostname 192.168.1.101
    User labex
    IdentityFile ~/.ssh/id_rsa

Host worker2
    Hostname 192.168.1.102
    User labex
    IdentityFile ~/.ssh/id_rsa

Avec cette configuration, vous pourriez simplement utiliser ssh worker1 au lieu de ssh labex@192.168.1.101.

La configuration conceptuelle met l'accent sur l'infrastructure et la connectivité requises avant que tout travail de cassage puisse être initié. L'efficacité du cassage distribué dépend fortement d'un environnement sous-jacent bien configuré et stable.

Gérer les tâches de cassage distribué

Dans cette étape, vous apprendrez conceptuellement comment gérer les tâches de cassage distribué une fois l'environnement configuré. Une gestion efficace des tâches est cruciale pour maximiser l'efficacité, surveiller la progression et traiter les résultats dans une configuration de cassage distribué.

Les aspects clés de la gestion des tâches de cassage distribué comprennent :

Soumission des tâches :
- Définition de la tâche : Quels hachages casser, quel mode de cassage (liste de mots, force brute), quelles règles et quel dictionnaire/jeu de caractères utiliser.
- Division de la charge de travail : C'est la partie la plus critique. Pour les attaques par liste de mots, vous pourriez diviser le fichier dictionnaire en morceaux. Pour la force brute, vous pourriez attribuer différentes plages de caractères (par exemple, a-m au worker1, n-z au worker2).
- Distribution des fichiers d'entrée : S'assurer que chaque worker dispose des fichiers de hachages, des morceaux de dictionnaire ou des fichiers de règles nécessaires.
Suivi de la progression :
- Statut john à distance : John the Ripper peut afficher son statut dans la console. Vous auriez besoin d'un moyen de vérifier à distance ce statut sur chaque worker.
- Fichiers journaux (Log Files) : Rediriger la sortie de John vers des fichiers journaux sur chaque worker, puis récupérer ou suivre périodiquement ces journaux depuis le maître.
- Tableau de bord centralisé (Avancé) : Pour les configurations très importantes, un tableau de bord Web personnalisé pourrait afficher l'état de tous les workers, les hachages cassés et le temps restant estimé.
Collecte et fusion des résultats :
- Fichiers john.pot : Chaque instance de John the Ripper sur un worker générera son propre fichier john.pot contenant les mots de passe cassés.
- Récupération de john.pot : Utilisez scp ou un système de fichiers partagé pour ramener tous les fichiers john.pot sur le nœud maître.
- Fusion des fichiers john.pot : John the Ripper dispose d'un mécanisme intégré pour fusionner les fichiers john.pot. Vous pouvez simplement les concaténer, puis utiliser john --show sur le fichier fusionné, ou utiliser john --restore sur un fichier john.pot combiné, car John gérera automatiquement les doublons.

Considérons un flux de travail conceptuel pour gérer une attaque distribuée par liste de mots :

Conceptual Job Management Workflow:

1. Prepare Hashes:
   - Master node has `target_hashes.txt`.

2. Prepare Dictionary:
   - Master node splits `large_dictionary.txt` into `dict_part_01`, `dict_part_02`, etc.
   - Command: `split -l 1000000 large_dictionary.txt dict_part_`

3. Distribute Files:
   - Master node `scp`s `target_hashes.txt` to all workers.
   - Master node `scp`s `dict_part_XX` to the respective worker (e.g., `dict_part_01` to worker1, `dict_part_02` to worker2).

4. Launch Cracking Jobs:
   - Master node `ssh`es into each worker and starts John:
     `ssh worker1 "cd ~/project && john --wordlist=dict_part_01 target_hashes.txt --format=raw-md5"`
     `ssh worker2 "cd ~/project && john --wordlist=dict_part_02 target_hashes.txt --format=raw-md5"`
   - Use `nohup` and `&` to run in background and prevent termination on SSH disconnect.

5. Monitor Progress (Conceptual):
   - Periodically `ssh` into workers and check `john.log` or `john --status`.
   - `ssh worker1 "cat ~/project/john.log"`

6. Collect Results:
   - Once jobs are complete or paused, `scp` `john.pot` files from each worker to master:
     `scp worker1:~/project/john.pot worker1_pot.txt`
     `scp worker2:~/project/john.pot worker2_pot.txt`

7. Merge Results:
   - Concatenate all `pot` files on the master:
     `cat worker1_pot.txt worker2_pot.txt > combined.pot`
   - John will handle duplicates when showing results from `combined.pot`:
     `john --show combined.pot`

Ce flux de travail conceptuel démontre les étapes manuelles impliquées. Dans un scénario réel, ces étapes seraient automatisées à l'aide de scripts ou d'outils d'orchestration spécialisés.

Analyser les performances du cassage distribué

Dans cette étape, vous analyserez conceptuellement les aspects de performance du cassage distribué de mots de passe. Comprendre les performances est crucial pour optimiser votre configuration et prendre des décisions éclairées concernant l'allocation des ressources.

Plusieurs facteurs influencent les performances d'un système de cassage distribué :

Nombre de workers : Généralement, plus il y a de workers, plus le cassage est rapide. Cependant, il y a des rendements décroissants en raison des surcoûts tels que la latence réseau et la coordination.
Matériel des workers : La puissance de traitement (cœurs CPU, capacités GPU) des nœuds workers individuels a un impact direct sur leur vitesse de cassage. L'utilisation de GPU, si elle est prise en charge par John the Ripper pour le type de hachage spécifique, peut fournir des accélérations significatives.
Latence et bande passante réseau : Une latence élevée ou une faible bande passante entre le maître et les workers, ou entre les workers s'ils doivent communiquer, peut devenir un goulot d'étranglement, en particulier lors du transfert de gros fichiers de dictionnaire ou de résultats.
Stratégie de distribution de la charge de travail : L'efficacité avec laquelle le travail est réparti entre les workers. Une distribution inégale (certains workers terminant beaucoup plus tôt que d'autres) entraîne des ressources inactives et réduit l'efficacité globale.
Complexité du type de hachage : Certains types de hachages sont plus intensifs en calcul à casser que d'autres, affectant le temps global indépendamment de la distribution.
Configuration de John the Ripper : Les paramètres optimaux de John the Ripper (par exemple, l'option --fork pour les CPU multi-cœurs sur une seule machine, les règles spécifiques ou les listes de mots) sur chaque worker peuvent avoir un impact significatif sur les performances individuelles des workers.

Métriques de performance conceptuelles :

Hachages par seconde (H/s) : La métrique principale pour la vitesse de cassage. Dans une configuration distribuée, vous additionneriez les H/s de tous les workers actifs pour obtenir les H/s totaux du système.
Temps de cassage : Le temps total nécessaire pour casser un ensemble spécifique de hachages. C'est la mesure ultime de l'efficacité.
Utilisation des ressources : Surveillance de l'utilisation du CPU, du GPU, de la mémoire et du réseau sur chaque worker et le maître pour identifier les goulots d'étranglement.

Stratégies d'optimisation conceptuelles :

Équilibrage de charge (Load Balancing) : Assurez une distribution équitable du travail entre les workers. Pour les attaques par dictionnaire, cela signifie diviser le dictionnaire en parties à peu près égales. Pour la force brute, attribuer des plages de caractères équilibrées.
Minimiser le trafic réseau : Transférez uniquement les données nécessaires. Par exemple, si un dictionnaire est statique, transférez-le une fois et conservez-le sur les workers.
Utiliser les GPU : Si John the Ripper prend en charge le cassage par GPU pour votre type de hachage cible, exploitez les GPU sur les nœuds workers pour des accélérations massives.
Surveiller et ajuster : Surveillez en permanence les performances de votre système distribué et ajustez la distribution de la charge de travail ou ajoutez/supprimez des workers si nécessaire.

Considérez un scénario conceptuel : Vous avez 10 nœuds workers, chacun capable de 100 000 H/s. Total théorique H/s = 10 * 100 000 H/s = 1 000 000 H/s (1 MH/s). Cependant, en raison de la surcharge réseau et de la coordination, les H/s effectifs réels pourraient être de 800 000 H/s. L'objectif de l'analyse des performances est d'identifier et de réduire cet écart.

Conceptual Performance Analysis:

## On each worker, John the Ripper's status output would show H/s:
## Example output from 'john --status' on a worker:
## 0g 0:00:00:05 DONE (2023-10-27 10:30) 0g/s 100000p/s 100000c/s 100000C/s ...

## Master would aggregate these:
## Worker1 H/s: 100,000
## Worker2 H/s: 95,000 (maybe slightly slower due to hardware variation)
## Worker3 H/s: 102,000
## ...
## Total System H/s = Sum of all worker H/s.

## If one worker consistently shows much lower H/s, it might indicate a bottleneck
## (e.g., less powerful hardware, network issues, or an uneven workload).

En comprenant ces facteurs et métriques de performance, vous pouvez concevoir et gérer un environnement de cassage distribué plus efficace.

Résumé

Dans ce laboratoire, vous avez acquis une compréhension conceptuelle approfondie du cassage distribué de mots de passe à l'aide de John the Ripper. Vous avez exploré les concepts fondamentaux de la distribution des tâches de cassage, y compris la distribution de la charge de travail, la scalabilité et la tolérance aux pannes. Vous vous êtes ensuite penchés sur les différents outils et approches utilisés pour l'orchestration, des scripts personnalisés avec ssh et scp à l'utilisation potentielle de frameworks de calcul distribué.

Vous avez également appris la configuration conceptuelle d'un environnement de cassage distribué, en identifiant les rôles des nœuds maître et workers, ainsi que l'importance de la configuration réseau et de l'authentification basée sur les clés SSH. De plus, vous avez compris les aspects critiques de la gestion des tâches de cassage distribué, notamment la soumission des tâches, le suivi de la progression, ainsi que la collecte et la fusion des résultats. Enfin, vous avez analysé les facteurs clés influençant les performances d'un système de cassage distribué, tels que le nombre de workers, les capacités matérielles, les conditions réseau et les stratégies de distribution de la charge de travail.

Bien que ce laboratoire se soit concentré sur la compréhension conceptuelle plutôt que sur la mise en œuvre pratique, les connaissances acquises fournissent une base solide à toute personne souhaitant approfondir les aspects pratiques des opérations de cassage de mots de passe à grande échelle ou comprendre les implications de sécurité de telles techniques puissantes.

John the Ripper et le cassage distribué (Conceptuel)