L’attaque par usurpation d’IP qui pousse le monde entier à envoyer des signalements d’abus à vos amis
(delroth.net)- Hetzner a transmis un signalement d’abus indiquant qu’un scan du port SSH provenait de
195.201.9.37, mais aucune preuve de processus malveillant, de modification de fichiers ou de trafic anormal n’a été trouvée sur le serveur - Le flux réel observé avec
tcpdumpne montrait pas le serveur se connectant vers des ports22/tcpexternes, mais ressemblait plutôt à du backscatter : plusieurs hôtes Internet renvoyaient des TCP RST au serveur - La cause principale est qu’il est possible d’envoyer des paquets avec une adresse IP source arbitraire via des réseaux qui n’appliquent pas le filtrage BCP38 ; avec TCP, QUIC et TLS, qui nécessitent des réponses aller-retour, l’attaquant ne peut pas voir directement les réponses
- Le même motif est apparu sur deux autres relais Tor de l’auteur, et des phénomènes similaires étaient signalés depuis quelques jours sur la liste de diffusion
tor-relayset dans une issue du Tor Project, avec certains nœuds temporairement mis hors ligne - Un attaquant peut usurper l’IP de la victime comme source, envoyer des tentatives de connexion vers plusieurs cibles SSH, et déclencher des signalements d’abus automatisés, des listes de blocage et des actions de fournisseurs d’hébergement
Signalement d’abus Hetzner et vérification du serveur
- Hetzner a envoyé un e-mail AbuseInfo concernant l’IP
195.201.9.37- Le signalant était
abuse@watchdogcyberdefense.com - Les journaux contenaient plusieurs entrées
DENIEDvers le port22/tcpde cibles202.91.16x.x
- Le signalant était
- À première vue, cela donnait l’impression que le serveur avait commencé à établir des connexions SSH vers Internet, une situation qui ferait généralement suspecter une infection par malware
- Après 1 à 2 heures de vérification, l’état du serveur semblait proche de la normale
- Aucun processus suspect
- Aucun changement du système de fichiers
- Aucun trafic réseau anormal du point de vue de l’hyperviseur
- Plusieurs services distribués ou fédérés tournaient sur ce serveur
- Relais Syncthing
- Instance Mastodon
- Relais Tor
- Homeserver Matrix
- Le relais Tor se connecte bien à certains relais en
22/tcp, mais cela ne correspondait pas au réseau du signalement ; les journaux Matrix et Mastodon, ainsi que la file Sidekiq de Mastodon, ne montraient pas non plus de traces de requêtes vers des IP ou ports arbitraires
Le flux réel de paquets montré par tcpdump
- Au départ, le filtre
dst port 22a été utilisé pour vérifier le trafic sortant du serveur vers des ports22/tcpexternes - En remplaçant le filtre par
not src host 195.201.9.37, on voyait des paquets TCP RST entrants, depuis le port22/tcpde plusieurs IP externes vers des ports éphémères du serveur de l’auteur - En réalité, le serveur n’avait pas envoyé de connexions vers le
22/tcpd’hôtes arbitraires ; des hôtes Internet arbitraires envoyaient plutôt des paquets reset au serveur - Ce motif correspond à du backscatter, où les paquets de réponse reviennent vers l’IP usurpée à cause d’une usurpation de l’adresse IP source
Usurpation d’adresse IP source et failles de BCP38
- Sur Internet, l’IP de destination doit être correcte, mais il est possible d’envoyer à plusieurs destinations des paquets dont l’IP source est falsifiée
- BCP38 est la bonne pratique actuelle consistant à n’autoriser un réseau pair à utiliser comme source que les adresses IP attendues
- Ce filtrage doit être appliqué au début du trajet des paquets pour être efficace
- Au niveau des grands transit providers, un filtrage significatif est difficile, car les pairs s’attendent à pouvoir leur transmettre du trafic vers tout Internet
- Il suffit de trouver un seul transit provider n’appliquant pas BCP38 pour pouvoir envoyer des paquets avec une adresse IP source arbitraire
- En 2023, l’APNIC a publié un article expliquant pourquoi la validation de l’adresse source reste un problème
- Les familles TCP, QUIC et TLS nécessitent des échanges aller-retour ; si l’IP source est usurpée, l’attaquant ne peut donc pas voir les réponses
- Ce n’est pas adapté pour consulter les résultats d’un scan de ports classique
- Il existe toutefois des formes d’abus connues, comme les attaques DDoS par réflexion
Pourquoi ce spoofing provoque des dégâts
- Le scénario le plus plausible est que quelqu’un utilise l’IP de l’auteur comme adresse source pour envoyer des tentatives de connexion vers le
22/tcpde plusieurs hôtes Internet - Si l’objectif était une découverte classique de ports ouverts, cela n’aurait pas de sens logique, car l’usurpateur ne peut pas voir les réponses
- Il existait autrefois une technique appelée Idle Scanning, mais elle dépendait de serveurs peu sollicités et de compteurs de pile réseau prévisibles, et elle a perdu son intérêt pratique depuis des décennies
- Le volume de trafic est trop faible et sa durée trop longue pour que l’hypothèse d’une IP source mal saisie dans la configuration d’un scanner soit vraiment convaincante
- Le vrai dommage vient de l’automatisation des signalements d’abus
- Les tentatives de connexion usurpées atteignent un réseau doté d’un honeypot ou d’un système de détection d’intrusion
- Certains systèmes envoient automatiquement des signalements d’abus
- Le fournisseur d’hébergement peut croire à tort que le serveur victime est compromis ou malveillant
Motif répété sur d’autres relais Tor
- L’auteur confirme à nouveau que son serveur fonctionne comme relais Tor
- Un relais Tor est un nœud interne au réseau Tor et, s’il ne s’agit pas d’un nœud de sortie, il ne communique pas directement avec l’Internet public
- Un relais transmet du trafic anonyme chiffré entre les nœuds participant au réseau Tor
- Certains relais peuvent agir comme Guard Nodes, c’est-à-dire comme points d’entrée dans le réseau Tor
tcpdumpa aussi été lancé sur deux relais supplémentaires situés dans des pays et chez des FAI différents- Un relais sur une connexion résidentielle
- Un relais sur un VPS Linode au Japon
- Sur ces deux relais également, le même motif de réponses TCP usurpées provenant de ports
22/tcpexternes vers l’IP du relais est apparu - L’auteur a envoyé un e-mail à la liste de diffusion
tor-relays, et il existait déjà une issue du Tor Project diagnostiquant le même phénomène depuis quelques jours - Cette attaque par spoofing avait commencé sur d’autres types de nœuds avant les relais, et certains nœuds avaient été temporairement mis hors ligne à cause d’un volume plus important de connexions usurpées
Un déroulé d’attaque qui peut viser n’importe qui
- Le déroulé possible de l’attaque est le suivant
- L’attaquant accède à un réseau sans filtrage BCP38
- Il envoie des demandes de connexion TCP vers le
22/tcpde plusieurs hôtes Internet arbitraires - L’IP source est usurpée avec celle de la victime
- Les hôtes cibles ou leurs systèmes de sécurité pensent que la victime a tenté de se connecter et envoient des signalements d’abus
- À une échelle suffisante, l’IP de la victime se retrouve sur plusieurs listes de blocage, et le fournisseur d’hébergement peut suspendre le serveur
- Cette attaque n’a rien de spécifique à Tor
- Elle ne semble pas particulièrement difficile à mener pour un attaquant seul et motivé
- La victime n’est pas l’attaquant réel, mais le propriétaire de l’adresse IP source usurpée ; elle peut néanmoins subir des dommages opérationnels à cause des signalements d’abus automatisés et de la réaction des fournisseurs d’hébergement
Un problème d’exploitation d’Internet encore présent en 2024
- Le fait que les adresses IP source usurpées restent un problème en 2024 ressemble à un échec de l’exploitation d’Internet
- Outre BCP38, RPKI a connu des problèmes similaires de déploiement, et n’a commencé à se généraliser que lorsque de grandes entreprises Internet ont commencé à imposer directement des exigences à leurs pairs
- La suite à donner face à cette attaque n’est pas claire
- Elle est déjà en cours dans la réalité
- L’auteur ne sait pas s’il s’agit d’une attaque déjà documentée
- Il ne connaît pas de méthode pour retracer a posteriori la véritable source des paquets à IP usurpée
- Les opérateurs recevant des signalements d’abus similaires doivent vérifier que leur serveur est peut-être la victime plutôt que l’auteur de l’attaque, et rassembler des éléments pour l’expliquer à leur fournisseur d’hébergement
1 commentaires
Avis sur Hacker News
Ce genre de problème est vraiment pénible à gérer. Car la réponse légitime à un signalement d’abus — « quelqu’un a usurpé mon IP, ce n’était pas moi, et mon matériel n’a pas été compromis » — est exactement la même que l’excuse que donnerait un acteur malveillant.
Au final, comme dans l’article, on doit apporter une preuve d’absence à un interlocuteur qui n’en a pas grand-chose à faire, ce qui est en pratique presque impossible.
Un signalement d’abus automatique pour quelque chose qui peut être facilement usurpé ne suffit pas à le justifier en soi, mais cela peut être une raison de vérifier rapidement que mon serveur fonctionne normalement et n’a pas été détourné.
Il faudrait au minimum des éléments sur l’identité et la juridiction, et peut-être même quelque chose comme un appel vidéo. Se contenter d’affirmer anonymement sur Internet « je suis quelqu’un de bien » et demander qu’on vous croie ne suffit pas.
C’est pareil pour les adresses MAC usurpées, les adresses e-mail, les messages ARP, Neighbor Discovery, ou encore les certificats TLS d’homme du milieu.
C’est presque étonnant que quoi que ce soit fonctionne encore.
Si on avait essayé de le concevoir et de l’exploiter de façon parfaite, il se serait sans doute beaucoup plus souvent cassé gravement. Sa capacité à tolérer une certaine imperfection a beaucoup contribué à sa robustesse et à son utilité.
Cela ne veut pas dire qu’il ne faut pas l’améliorer ; c’est plutôt un avertissement : en poursuivant le perfectionnisme, on risque facilement de commettre de grosses erreurs qui gâchent tout.
Par le passé, on scannait des serveurs de réflexion DrDoS de manière similaire. Comme aucun hébergeur n’a envie de recevoir des signalements de scan de ports, il suffisait de prendre comme adresse source du scan l’IP d’un fournisseur cloud innocent et de bonne réputation, et les serveurs de réflexion envoyaient gentiment leurs réponses UDP de ce côté-là.
Le fournisseur cloud recevait évidemment une énorme quantité de signalements, mais si je disais que mon serveur n’effectuait pas de scan, il vérifiait et ne coupait pas le service. Le serveur qui envoyait les paquets de scan usurpés n’étant pas détecté, on pouvait scanner tout Internet en boucle sans les problèmes habituels de signalements d’abus.
Je ne sais pas à quelle fréquence cela se produit réellement, mais en coopérant avec les opérateurs de transit et en remontant les sauts, il est possible de retrouver l’origine des paquets usurpés. Une fois, JPMorgan, en coopération avec Cogent, nous a demandé de ne pas envoyer de paquets vers ses adresses IP. Pour mémoire, Cogent est plutôt tolérant envers le spoofing parmi les opérateurs de niveau 1 d’Internet.
C’est la première fois que j’entends dire que cette technique a été utilisée spécifiquement contre Tor, et c’est un peu contre-intuitif. J’aurais plutôt pensé que la personne qui envoie les paquets usurpés serait favorable à Tor. C’est probablement juste un troll, et heureusement les hébergeurs de Tor ne devraient pas trop s’en soucier.
C’est peut-être juste un troll, mais cela pourrait aussi venir de quelqu’un qui veut faire traiter Tor comme un déchet radioactif parce qu’il gêne les opérations de surveillance.
Ce n’est pas nouveau. Il y a quelques années, j’avais créé une règle de pare-feu très basique : pour les paquets TCP entrants vers le port de destination 22 avec SYN=1 et ACK=0, je bloquais l’IP source pendant une journée.
Puis des plaintes sont apparues indiquant que certains sites et services ne fonctionnaient plus. Il s’est avéré que, tous les quelques jours, des paquets de ce type arrivaient depuis des IP de serveurs populaires comme 8.8.8.8, 1.1.1.1, Steam, Roblox, Microsoft, Facebook, Instagram et divers services de messagerie. Évidemment, c’étaient tous des paquets usurpés, et j’ai fini par ajouter un peu plus de vérification à la règle de pare-feu.
Je suis donc assez convaincu que c’est courant. Personnellement, je sais que je suis un cas particulier, puisque j’exploite plusieurs adresses IP, mais j’ai besoin de la flexibilité de pouvoir envoyer des paquets vers n’importe quel FAI en utilisant n’importe laquelle de mes adresses source. C’est important pour moi, et si un FAI filtre selon l’adresse source, ce serait un motif de rupture de contrat : je passerais chez un autre FAI.
Dans ce dernier cas, on est plutôt dans la catégorie « rallumer le chauffage à la barre d’espace », et j’espère que les FAI corrigeront leurs réseaux défectueux.
Une entreprise hébergeait certains actifs web sur site dans une agence, qui disposait d’un lien à 1 Gbit/s. Le siège avait plusieurs liens 10G et un datacenter assez correct ; les VM web ont donc été déplacées au siège tout en conservant les adresses IP attribuées, c’est-à-dire les IP publiques statiques du FAI-A. Le trafic était routé jusqu’au siège via VPN, et le serveur envoyait ses réponses avec l’IP source du FAI-A via le lien 10G du FAI-B en utilisant la passerelle par défaut.
Ainsi, même si la réception restait limitée à 1G, l’émission pouvait utiliser 10G. De toute façon, il ne s’agissait que de requêtes GET. Ce n’était pas une configuration optimale et les IP ont fini par être changées, mais cela me semble être un cas d’usage valable.
Deuxième exemple : nous avions deux liens chez deux FAI différents, notre propre ASN et notre propre bloc /23. Pour équilibrer une partie du trafic, nous envoyions la moitié des IP via le FAI-A et l’autre moitié via le FAI-B. Cela fonctionnait bien, mais quand nous avons essayé de mélanger un peu l’équilibrage, un problème intéressant est apparu. Le premier /24 était annoncé au FAI-A et le second /24 au FAI-B, mais le FAI-A avait du filtrage RP. Nous avons donc dû leur annoncer toutes les IP également.
Vu le fonctionnement du filtre RP, on ne peut pas faire de préfixage AS-path ou autre : tout le trafic doit entrer par eux. S’ils voient une meilleure route vers ce préfixe, ils filtrent. Pendant des mois, ils ont refusé de corriger cela au nom de la sécurité. Puisque c’était présenté comme une bonne pratique de sécurité, je peux bien citer le nom du FAI : c’était Virgin Media.
Pour information, le lien Internet avec rp_filter ne coûtait pas 20 dollars par mois, mais plus de 5 000 dollars par mois. Il n’y avait pas d’alternative dans la région, donc nous n’avons pas pu changer, mais s’il y en avait eu une, il est évident qui aurait perdu le contrat.
L’hypothèse selon laquelle « quelqu’un déteste les relais Tor » ne paraît pas très convaincante au regard des efforts déployés
Il se pourrait que l’acteur qui exploite des relais malveillants fasse tomber de manière non éthique des relais légitimes afin d’augmenter la part du réseau qu’il contrôle
Quelques téléchargements BitTorrent peuvent suffire
Que faudrait-il pour qu’un nombre suffisant d’opérateurs réseau refusent le trafic de tous les AS qui n’implémentent pas BCP38, afin que le spoofing ne soit plus possible ?
Comme il contrôle déjà suffisamment de trafic entrant, « vérification de la sécurité de la connexion » pourrait prendre un vrai sens
Cela dit, réduire le facteur d’amplification par réflexion est bien plus simple. Avec IPv4, on peut scanner les vecteurs de réflexion et se plaindre auprès de ceux qui répondent avec 10 fois plus d’octets que ce qu’ils reçoivent
C’est un problème similaire au swatting. Il repose sur le fait qu’une entité dotée d’autorité prend des mesures fortes sur la base de signalements de problèmes non vérifiés
La différence serait qu’au lieu de contacter directement l’autorité, on utilise des tiers sans rapport pour leur faire envoyer les signalements
Pour une requête qui se limite à un seul paquet et ne comporte aucun aller-retour, un système ne devrait pas envoyer automatiquement de signalement d’abus, sauf s’il s’agit d’un volume de trafic relevant du déni de service
En particulier avec SSH, avant qu’une forme quelconque de handshake n’ait lieu, il n’y a aucun moyen de considérer cela comme une tentative de connexion valide
Mon serveur principal a déjà été mis hors ligne à cause d’un faux signalement d’abus. On affirmait que mon IP lançait une attaque DoS de plus de 1 Gbps, alors que la liaison de mon serveur était limitée à 400 Mbps. Si un humain avait simplement lu le signalement, il aurait vu que c’était impossible, et je n’aurais pas eu à me battre pendant deux jours avec le support téléphonique pendant mes vacances
C’est la version IP du swatting, du harcèlement par brevets, de l’accusation d’innocents et des demandes de retrait DMCA visant à éliminer des concurrents
En substance, cela consiste à militariser les mécanismes anti-abus pour attaquer une cible qui ne plaît pas. Il est intéressant de voir qu’une entité dotée d’autorité devient le maillon faible et peut être activement exploitée par des acteurs malveillants pour atteindre leurs objectifs, mais ce n’est pas un phénomène entièrement nouveau
D’après les graphiques du nombre de relais et de l’« advertised bandwidth » sur metrics.torproject.org, cela ne semble pas avoir fait une grande différence, mais cela reste intéressant
Le pire, c’est que des acteurs imitant des racketteurs comme « Watchdog Cyber Defense », Spamhaus, Shadowserver ou UCEPROTECT peuvent envoyer automatiquement des millions de signalements, et que les hébergeurs doivent en pratique les prendre en compte s’ils ne veulent pas voir leurs plages d’IP se retrouver sur des listes de blocage
Il n’existe pas de solution dans la bande à ce problème, mais il peut exister des solutions hors bande
Par exemple : (1) informer le FAI de destination qu’il reçoit du trafic de retour, (2) ce FAI vérifie d’où viennent les paquets et informe le FAI correspondant, (3) répéter l’étape 2 jusqu’à trouver la source, (4) isoler la partie du réseau concernée jusqu’à ce qu’elle fonctionne correctement
En fin de compte, Internet est fait d’êtres humains