Aller au contenu principal

Un mot de passe intercepté en direct sur le réseau

Pas besoin de le craquer : parfois, il suffit de regarder passer les données

Petite vérification​

Avant de commencer, vérifiez si vous savez encore réaliser ces 3 actions très simples, sur la séance précédente consacrée au craquage de mots de passe :

  1. depuis ~/tp-craquage, relancer time python3 craquage.py et vérifier que le mot de passe retrouvé pour amelie est toujours Mediatheque2024
  2. vérifier que, pour direction, le script affiche toujours qu'aucun mot de passe de la liste ne correspond
  3. citer la commande utilisée pour mesurer la durée d'exécution du script
📌 Réponse attendue

TP pour réfléchir et résoudre des problèmes​

Votre défi pour aujourd'hui consiste à observer, depuis une position de simple témoin sur le réseau, un mot de passe envoyé à un formulaire de connexion

info

Le formulaire utilisé dans ce TP est un formulaire minimal, créé pour l'exercice : il ne représente pas le vrai site de la médiathèque Jules Verne.

attention

Ce TP se déroule entièrement sur votre propre machine (interface lo, c'est-à-dire la boucle locale). Capturer le trafic réseau de quelqu'un d'autre, sans son autorisation explicite, est interdit par la loi, quel que soit le réseau.

Étape 1 — Démarrer un petit serveur de connexion​

Créez un dossier tp-sniffing, puis le fichier serveur.py :

from http.server import BaseHTTPRequestHandler, HTTPServer

class Connexion(BaseHTTPRequestHandler):
    def do_POST(self):
        longueur = int(self.headers['Content-Length'])
        self.rfile.read(longueur)  # le corps de la requête est reçu, mais jamais affiché ici
        self.send_response(200)
        self.end_headers()
        self.wfile.write(b"Connexion recue")

HTTPServer(('localhost', 8000), Connexion).serve_forever()

Dans un premier terminal, lancez-le et laissez-le tourner :

cd ~/tp-sniffing
python3 serveur.py

Question : ce serveur affiche-t-il, à un seul endroit de son code, le contenu reçu (pseudo, mot de passe) ?

📌 Réponse attendue

Étape 2 — Se placer en position d'observateur, avant toute connexion​

Dans un deuxième terminal, démarrez la capture avant d'envoyer la moindre connexion :

sudo tcpdump -i lo -A -s 0 'tcp port 8000'
  • -i lo : observer la boucle locale (le trafic reste sur votre machine pour cet exercice).
  • -A : afficher le contenu de chaque paquet en texte lisible.
  • -s 0 : capturer chaque paquet en entier, sans le tronquer.

Laissez ce terminal ouvert et visible : c'est lui qui joue le rôle de l'observateur du réseau.

Étape 3 — Envoyer une connexion, comme le ferait un formulaire Web​

Dans un troisième terminal, simulez l'envoi du formulaire de connexion :

curl -s -X POST -d "pseudo=amelie&mot_de_passe=Mediatheque2024" http://localhost:8000/connexion

Étape 4 — Lire ce que l'observateur a capturé​

Revenez au deuxième terminal (celui qui exécute tcpdump).

  1. Repérez, dans le texte affiché, la ligne qui contient pseudo=amelie&mot_de_passe=Mediatheque2024.
  2. Cette ligne apparaît-elle en clair, ou sous une forme chiffrée illisible ?
  3. serveur.py a-t-il eu besoin d'afficher quoi que ce soit pour que ce mot de passe devienne visible dans le deuxième terminal ?
📌 Réponse attendue

Arrêtez la capture avec Ctrl+C dans le deuxième terminal.

Étape 5 — Réagir à un cas pratique​

Le responsable informatique de la médiathèque propose : « il suffit de choisir une adresse de connexion compliquée et difficile à deviner (par exemple http://localhost:8000/x7f-connexion-secrete), personne ne la trouvera pour l'espionner ». Que lui répondez-vous ?

Restitution orale​

Un étudiant (ou un binôme) vient présenter au tableau ce qui a été observé dans le terminal de capture à l'étape 4 et sa réponse au responsable informatique de l'étape 5.

  • Durée : 5 minutes de présentation + 2 à 3 minutes de questions.
  • Qui passe : un(e) étudiant(e) (ou un binôme) désigné(e) par l'enseignant.
  • Support : le travail réalisé pendant le TP, aucune préparation supplémentaire n'est nécessaire.
  • Ce qui est attendu :
    • rappeler ce qui a été vu passer en clair dans le terminal de capture ;
    • expliquer pourquoi ni le code du serveur ni celui du client n'ont besoin d'afficher le mot de passe pour qu'il soit observable ;
    • répondre aux questions de la classe.
astuce

Cet exercice entraîne à l'oral technique court exigé par plusieurs épreuves du BTS (notamment E5 et E6) : clarté, structure, capacité à répondre à l'improviste.

📌 Une solution

Notions théoriques​

Vous venez d'observer, sans toucher ni au client ni au serveur, un mot de passe circuler en clair sur le réseau. C'est ce qu'on appelle le sniffing.

Qu'est-ce que le sniffing ?​

Le sniffing (écoute réseau) consiste à observer le trafic qui circule sur un réseau, sans le modifier ni s'y faire passer pour quelqu'un d'autre. C'est une attaque passive : rien ne distingue, pour le client ou le serveur, une connexion observée d'une connexion qui ne l'est pas.

remarque

Le sniffing que vous venez de pratiquer est passif. Une attaque plus avancée, appelée attaque de l'homme du milieu (Man in the Middle, MITM), va plus loin : l'attaquant se place activement entre les deux parties, au point de pouvoir modifier ou rediriger leurs échanges. Cette attaque active sera étudiée en détail dans une séance à venir.

Pourquoi HTTP expose tout en clair​

Le protocole HTTP, utilisé par défaut par de nombreux formulaires Web, transmet ses données sans aucun chiffrement : chaque caractère envoyé (identifiant, mot de passe, contenu d'un formulaire) circule tel quel dans les paquets réseau.

ProtocoleContenu visible pour un observateur du réseau
HTTPEn clair, lisible directement (ce que vous venez de constater)
HTTPS (HTTP + TLS)Chiffré : seules des données illisibles sans la clé de déchiffrement sont visibles
attention

Ce problème ne concerne pas que les formulaires de connexion : toute donnée envoyée en HTTP (un message, un fichier, un numéro de carte) est exposée de la même façon à qui observe le réseau.

Qui peut sniffer un réseau, en pratique ?​

Dans ce TP, vous observiez votre propre machine. En situation réelle, quiconque partage le même segment réseau peut faire la même chose, avec les mêmes outils :

  • un autre appareil connecté au même réseau Wi-Fi public (café, gare, hôtel) ;
  • un équipement réseau mal sécurisé, entre l'utilisateur et le serveur ;
  • toute personne ayant un accès légitime à une partie du réseau traversé.
info

C'est pour cette raison précise qu'un réseau Wi-Fi public est considéré comme un environnement à risque pour toute connexion non chiffrée. L'usage d'un VPN pour s'en protéger sera étudié dans une séance à venir.

Test de mémorisation/compréhension​


Qu'est-ce que le sniffing réseau ?


D'après le TP, pourquoi le mot de passe envoyé par curl apparaît-il en clair dans la capture tcpdump ?


Quelle est la différence entre le sniffing pratiqué dans ce TP et une attaque de l'homme du milieu (MITM) ?


Que change HTTPS par rapport à HTTP, du point de vue d'un observateur du réseau ?


D'après le TP, en quoi la proposition de choisir une adresse de connexion « compliquée à deviner » est-elle inefficace contre le sniffing ?


Pourquoi un réseau Wi-Fi public est-il considéré comme un environnement à risque pour une connexion non chiffrée ?


Dans ce TP, pourquoi est-il important de démarrer la capture tcpdump avant d'envoyer la requête curl ?


Bonnes pratiques​

  • Chiffrer la connexion (HTTPS/TLS) : rend le contenu des paquets illisible pour un observateur, même s'il les capture.
  • Éviter les réseaux Wi-Fi publics non protégés pour toute donnée sensible.
  • Utiliser un VPN sur un réseau non maîtrisé, pour chiffrer la connexion de bout en bout jusqu'à un point de confiance.
  • Ne jamais compter sur une adresse difficile à deviner : ce n'est pas l'adresse qui doit être cachée, c'est le contenu des échanges qui doit être chiffré.