Protocoles en clair : ce que voient les attaquants

HTTP transmet toutes les données sous forme de texte ASCII en clair, sans chiffrement. Lorsque vous envoyez un formulaire de connexion sur HTTP, le navigateur transmet une requête POST contenant votre nom d’utilisateur et votre mot de passe en clair. Toute personne présente sur le même segment réseau, ou tout routeur situé entre vous et le serveur, peut lire la requête complète, notamment les identifiants, les cookies de session et toutes les données sensibles du formulaire.

Telnet était le protocole standard de terminal distant avant SSH. Chaque touche saisie dans une session Telnet est envoyée au serveur sous la forme d’un unique paquet TCP non chiffré. Un attaquant qui capture le trafic réseau voit non seulement le nom d’utilisateur et le mot de passe saisis lors de la connexion, mais aussi chaque commande saisie et chaque ligne de sortie affichée, ce qui permet de détourner complètement la session sans aucune protection cryptographique.

FTP s’authentifie au moyen d’une commande USER suivie d’une commande PASS, toutes deux envoyées en texte clair sur le port TCP 21. Une capture de paquets d’une connexion FTP affiche les identifiants exacts. Même si le canal de transfert de fichiers est chiffré avec FTPS, l’échange d’authentification initial révèle le mot de passe à tout observateur. Les serveurs FTP anciens sont courants dans les environnements professionnels et constituent des cibles faciles pour le vol d’identifiants.

POP3 (port 110) et IMAP (port 143) sans TLS envoient les identifiants de messagerie et le contenu intégral des messages en texte clair. Lorsqu’une personne ouvre son client de messagerie sur le Wi-Fi d’un café avec une configuration de serveur de messagerie non chiffrée, chaque courriel téléchargé est lisible par tout autre appareil du réseau. Le passage à POP3S (port 995) et à IMAPS (port 993) utilise TLS dès le début de la connexion.

Les serveurs de bases de données comme MySQL (port 3306) et PostgreSQL (port 5432) autorisent par défaut les connexions non chiffrées. Les serveurs applicatifs qui se connectent à la base de données sans exiger SSL envoient les requêtes et leurs résultats, y compris les données personnelles sensibles, en texte clair sur le réseau. Les réseaux internes sont souvent considérés comme fiables, mais les attaquants qui obtiennent le moindre point d’appui peuvent immédiatement commencer à intercepter le trafic de la base de données.

LDAP (protocole léger d’accès aux annuaires) sur le port 389 transmet en texte clair les requêtes d’annuaire et les données d’authentification. Les environnements professionnels qui utilisent Active Directory pour l’authentification peuvent avoir des opérations de liaison LDAP exposant les noms d’utilisateur et les mots de passe sur le réseau interne. LDAPS sur le port 636 utilise TLS, et STARTTLS sur le port 389 peut faire passer la connexion à TLS, mais ces mécanismes ne sont pas toujours imposés.

Redis écoute par défaut sur le port 6379 sans authentification ni TLS. Une instance Redis exposée sur le réseau sans mot de passe permet à n’importe quel client de lire toutes les clés stockées, d’exécuter des commandes arbitraires et potentiellement d’écrire des fichiers de configuration. Jusqu’à l’ajout de la prise en charge de TLS dans Redis 6.0 (2020), tout le trafic Redis, y compris les données de cache et les jetons de session, était entièrement exposé sur le réseau.

Memcached, une couche de mise en cache largement utilisée, ne possède aucun mécanisme d’authentification intégré et envoie toutes les données sous forme de texte ASCII non chiffré sur le port TCP 11211. Les développeurs comptent généralement sur des pare-feu réseau pour restreindre l’accès, mais des instances Memcached mal configurées et exposées à Internet ont été utilisées dans des attaques DDoS par amplification et des vols de données. Tout le contenu mis en cache, y compris les données de session et les réponses d’API, est visible par toute personne capable d’atteindre le port.

Syslog traditionnel utilise le port UDP 514 sans authentification ni chiffrement. Les journaux système envoyés sur le réseau peuvent être lus, modifiés ou falsifiés par quiconque se trouve sur le chemin. Un attaquant capable d’intercepter le trafic syslog peut lire les événements de sécurité en temps réel ou injecter de fausses entrées de journal pour effacer ses traces. RFC 5425 définit syslog sur TLS, mais de nombreux systèmes utilisent encore l’ancien protocole en clair.

Depuis un seul point d’observation du réseau, un attaquant qui capture le trafic de protocoles en clair obtient une vue complète de l’environnement. Il voit les noms d’utilisateur et les mots de passe de plusieurs services, les jetons de session qui peuvent être rejoués sans le mot de passe d’origine, les données sensibles transférées et l’architecture interne du réseau. Ces informations peuvent être recueillies passivement, sans aucune interaction avec les systèmes cibles.

Malgré des décennies de connaissance des risques liés au texte en clair, les protocoles non chiffrés persistent en raison de systèmes anciens impossibles à mettre à niveau, de la complexité de configuration des grands environnements, de préoccupations liées aux performances sur les liaisons internes à haut débit et de l’hypothèse selon laquelle les réseaux internes sont fiables. Les principes de segmentation réseau et d’architecture à confiance nulle remettent en cause cette hypothèse en soumettant le trafic interne au même niveau d’examen que le trafic externe.

Laquelle des combinaisons protocole-port suivantes transmet par défaut les identifiants d’authentification en texte clair ?

HTTP, Telnet, FTP, POP3, IMAP, les connexions directes aux bases de données, LDAP, Redis, Memcached et syslog transmettent tous les données sans chiffrement par défaut. Tout observateur situé sur le chemin réseau peut lire les identifiants, les jetons de session et les données sensibles. Des équivalents sécurisés par TLS existent pour tous ces protocoles. Les hypothèses de confiance envers les réseaux internes sont dangereuses : les principes de confiance nulle considèrent tout le trafic comme potentiellement observable.