Telnet : lire des credentials en clair dans une capture réseau

Telnet est un protocole de terminal distant datant de 1969. Il ne chiffre rien : chaque octet échangé entre le client et le serveur transite en clair sur le réseau. Un attaquant en position d’écoute sur le segment réseau lit la session dans son intégralité — identifiants, commandes, sorties.

Pourquoi Telnet est un problème

SSH a remplacé Telnet dès 1995. Pourtant, Telnet reste actif sur des équipements réseau anciens (routeurs, switches, imprimantes, systèmes embarqués), des environnements industriels, et des services legacy jamais migrés.

Contrairement à SSH :

	Telnet	SSH
Chiffrement	Aucun	AES, ChaCha20…
Authentification	Credentials en clair	Clés publiques, MFA
Intégrité	Aucune	HMAC
Port par défaut	23/TCP	22/TCP

Le problème du caractère par caractère

Telnet envoie chaque touche pressée dans un paquet TCP séparé, immédiatement après la frappe. Une session de connexion génère donc des dizaines de petits paquets contenant chacun un seul caractère.

Lire ces paquets un à un dans Wireshark donne :

Paquet 1  → "a"
Paquet 2  → "d"
Paquet 3  → "m"
Paquet 4  → "i"
Paquet 5  → "n"
Paquet 6  → "\r\n"

Ce qui semble illisible à première vue se reconstruit en suivant le flux TCP.

Reconstituer la session dans Wireshark

Filtrer le trafic Telnet

telnet

Ou filtrer par port :

tcp.port == 23

Suivre le flux TCP

1. Sélectionner n’importe quel paquet Telnet dans la liste
2. Clic droit → Follow → TCP Stream
3. Wireshark reconstitue l’intégralité de la session en réassemblant les paquets dans l’ordre

Le résultat affiche la session comme si on regardait directement le terminal :

Ubuntu 20.04.6 LTS

login: admin
Password:
Last login: Mon Jan 15 14:23:07 2024

$ whoami
admin
$ cat /etc/passwd
root:x:0:0:root:/root:/bin/bash
daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin
...
$ sudo su
Password:
#

Les données en rouge sont envoyées par le client (ce que l’utilisateur tape), en bleu les réponses du serveur. Le mot de passe apparaît en clair même si le terminal ne l’affiche pas à l’écran — il transite sur le réseau comme n’importe quel autre caractère.

Extraire uniquement les données du client

Dans la fenêtre du flux TCP, sélectionner client → serveur dans le menu déroulant pour n’afficher que ce que l’utilisateur a tapé : identifiant, mot de passe, commandes.

Depuis la ligne de commande avec tshark

# Extraire tous les flux Telnet d'un fichier de capture
tshark -r capture.pcap -q -z follow,tcp,ascii,0

# Filtrer sur le port 23 et afficher les données brutes
tshark -r capture.pcap -Y "tcp.port == 23" -T fields -e data | xxd

Ce qu’on peut reconstituer

Sur une session Telnet capturée, l’analyse du flux TCP donne accès à :

• Les credentials de connexion : login et mot de passe en clair
• L’historique des commandes exécutées pendant la session
• La sortie des commandes : contenu de fichiers, résultats de ls, cat, ip addr…
• Les élévations de privilèges : sudo, su avec les mots de passe associés
• Les fichiers transférés si des commandes comme cat sont utilisées pour exfiltrer du contenu

Remédiation

Remplacer Telnet par SSH

# Désactiver le service Telnet
sudo systemctl stop telnet
sudo systemctl disable telnet

# Installer et activer SSH
sudo apt-get install openssh-server
sudo systemctl enable --now ssh

Sur les équipements réseau (Cisco IOS) :

! Désactiver Telnet sur les lignes VTY
line vty 0 4
 transport input ssh
 no transport input telnet

! Activer SSH
ip domain-name exemple.local
crypto key generate rsa modulus 2048
ip ssh version 2

Si Telnet ne peut pas être supprimé

Isoler les équipements Telnet sur un VLAN dédié sans accès depuis les segments non maîtrisés, et imposer un tunnel SSH ou VPN pour y accéder depuis l’extérieur. Enregistrer toutes les sessions dans un bastion.

À retenir

Toute session Telnet capturée sur le réseau — par un switch en port mirror, un ARP spoofing, ou un accès à la capture d’un équipement — livre les credentials et l’historique des commandes en clair. Suivre le flux TCP dans Wireshark prend dix secondes. SSH existe depuis trente ans : il n’y a aucune justification à laisser Telnet actif sur un système exposé.