La solution : utilisez IPsec et des protocoles de sécurité similaires pour vous protéger contre toute exploitation par des acteurs malveillants.
Il existe plus de 4 millions d’hôtes vulnérables sur Internet qui acceptent du trafic non authentifié, affirment des chercheurs belges, qui préviennent que, à moins que des mesures ne soient prises par les RSSI et les fabricants de produits réseau, ces hôtes peuvent être utilisés abusivement comme proxys à sens unique, permettant à un adversaire de usurper l’adresse source des paquets pour permettre l’accès au réseau privé d’une organisation, ou être exploitée pour faciliter de nouvelles attaques par déni de service.
La preuve se trouve dans un article universitaire publié cette semaine par les auteurs Angelos Beitis et Mathy Vanhoef de l’unité de recherche DistriNet de l’Université KU Leuven.
Ils ont commencé par analyser Internet à l’aide de sept méthodes d’analyse pour rechercher des appareils, notamment des ordinateurs de bureau, des serveurs cloud et des routeurs principaux, qui acceptent le trafic de tunneling existant ou moderne non protégé par une sécurité telle qu’IPSec. Les 4 millions d’hôtes vulnérables qu’ils ont découverts acceptent le trafic IP non authentifié dans IP (IPIP), Generic Routing Encapsulation (GRE), IPv4 dans IPv6 (4in6) ou IPv6 dans IPv4 (6in4). Par défaut, ils n’utilisent ni authentification ni cryptage.
Il est déjà assez grave, ont écrit les auteurs, que ces hôtes puissent être exploités par des attaques existantes, mais ils peuvent également faciliter de nouvelles attaques d’amplification par déni de service distribué (DDoS), ont découvert les chercheurs. L’un concentre le trafic dans le temps et l’autre boucle les paquets entre les hôtes vulnérables, ce qui entraîne un facteur d’amplification d’au moins 16 et 75, respectivement.
De plus, les hôtes peuvent être victimes de ce que les auteurs appellent une attaque de déni économique de durabilité (EDoS), dans laquelle la bande passante sortante d’un hôte est drainée, ou d’un déni de service administratif, dans laquelle les hôtes vulnérables envoient du trafic qui provoque le destinataire doit déposer un rapport d’abus auprès du FAI de l’hébergeur, ce qui peut entraîner la suspension de son compte.
Défenses
Cependant, les RSSI ne sont pas sans défense, affirme le journal.
Tout d’abord, un hôte doit utiliser un ensemble sécurisé de protocoles pour fournir l’authentification et le cryptage, tels que IPsec (Internet Protocol Security). Souvent utilisé pour configurer des VPN, IPsec crypte les paquets IP et authentifie la source des paquets.
« Étant donné qu’IPsec peut transporter n’importe quel protocole IP, il peut être utilisé pour protéger tous les protocoles de tunneling discutés ; un hôte ne doit accepter que les paquets de tunneling protégés par IPsec », indique le journal.
Deuxièmement, des défenses réseau telles que le filtrage du trafic entrant et sortant et l’inspection approfondie des paquets peuvent être mises en œuvre sur les routeurs ou autres boîtiers intermédiaires Internet pour prévenir ou limiter les dommages causés par les attaques. Le filtrage du trafic empêcherait un adversaire de forcer les hôtes à usurper les paquets, tandis qu’une inspection approfondie des paquets détecterait les paquets de tunneling potentiellement malveillants. Par exemple, indique le journal, le réseau pourrait abandonner des paquets dont le nombre d’en-têtes encapsulés dépasse un nombre x, où x est le nombre d’hôtes tunnelés dans le réseau.
Troisièmement, le document indique que dans certains réseaux, il peut également être possible de bloquer tous les paquets de tunneling non cryptés entrants ou sortants. Par exemple, si un hôte utilise IPsec en combinaison avec GRE mais, en raison d’une mauvaise configuration, accepte également les paquets GRE non chiffrés, le réseau peut bloquer les paquets GRE non chiffrés. L’hôte serait toujours en mesure de recevoir du trafic IPsec et donc de fonctionner normalement tout en étant protégé contre les attaques.
Le problème des hôtes acceptant le trafic non chiffré n’est pas nouveau, a commenté Johannes Ullrich, doyen de la recherche à l’Institut SANS. « Les gens redécouvrent cela depuis au moins 2001 », a-t-il déclaré dans un courriel. C’est l’année où il a vu pour la première fois des tunnels 6to4 utilisés pour la communication Internet Relay Chat (IRC) avec un botnet. Microsoft a en partie résolu ce problème en activant le protocole de tunneling Terado dans Windows 7, a-t-il écrit. Terado est une technologie de transition qui offre une connectivité IPv6 aux hôtes compatibles IPv6 sur Internet IPv4 qui n’ont pas de connexion native à un réseau IPv6.
Les hôtes acceptant le trafic non chiffré ont été exploités à plusieurs reprises, écrit Ullrich, « mais pour la plupart, cela n’a jamais tourné au drame.
« Les gens redécouvrent aussi occasionnellement que IPv6 est préféré à IPv4 dans la plupart des systèmes d’exploitation, et que les réseaux IPv6 malveillants peuvent dans certains cas conduire à une fuite VPN », a-t-il ajouté.
Pourquoi est-ce important
Les protocoles de tunneling – notamment IPIP et GRE – constituent l’épine dorsale essentielle d’Internet, indique le journal. Ces protocoles peuvent relier des réseaux déconnectés et former des réseaux privés virtuels (VPN). Mais une limitation est que ces protocoles n’authentifient ni ne chiffrent le trafic. Au lieu de cela, pour sécuriser ces protocoles, ils doivent être combinés avec IPsec.
Des recherches antérieures ont montré que des hôtes IPv4 mal configurés peuvent accepter du trafic de tunnel IPIP non authentifié provenant de n’importe quelle source, indique le document, et que ces hôtes pourraient être utilisés pour usurper des adresses IPv4. Les recherches des auteurs montrent que les hôtes IPv4 et IPv6 utilisant d’autres protocoles de tunneling peuvent également être exploités.
Les nouvelles attaques DoS par amplification découvertes par les deux chercheurs sont :
- Lentille temporelle tunnelisée (TuTL): Cette attaque concentre dans le temps les paquets générés par l’attaquant. Par exemple, l’attaquant envoie des paquets pendant 10 secondes et utilise les propriétés du protocole pour garantir qu’ils arrivent à la victime dans un délai de moins d’une seconde, ce qui entraîne un facteur d’amplification d’au moins 10. Pour ce faire, l’adversaire envoie du trafic sur plusieurs canaux différents. chaînes d’hôtes vulnérables afin que tout le trafic arrive simultanément à la victime.
- L’attaque du ping-pong: Cette attaque boucle les paquets envoyés par un attaquant entre des hôtes vulnérables. L’idée, selon le document, est qu’un adversaire construit un paquet de tunneling qui a un autre paquet de tunneling comme paquet interne, et ainsi de suite, jusqu’à ce que la taille maximale du paquet soit atteinte. Les en-têtes IP du paquet interne ont l’autre hôte vulnérable comme destination, ce qui signifie que le paquet (décapsulé) est constamment envoyé entre les hôtes.
La nouvelle attaque EDoS (Economic Denial of Sustainability) vise à augmenter les coûts pour une victime sur le cloud en tirant parti d’une attaque Ping-Pong pour consommer de la bande passante.
« L’attaque TuTL est particulièrement préoccupante, car elle peut être utilisée de manière abusive pour effectuer des attaques DoS contre n’importe quel hôte tiers sur Internet », ont écrit les auteurs.
« Nos mesures montrent également que de nombreux systèmes autonomes, plus de quatre mille au total, n’implémentent pas (correctement) le filtrage des adresses sources, permettant ainsi l’usurpation des adresses IP sources », ont-ils écrit. « Nous espérons que nos résultats motiveront et guideront les administrateurs pour mieux sécuriser les hôtes de tunneling. »
Atténuation
Dans un e-mail, Beitis et Vanhoef ont émis l’hypothèse que ce problème n’avait pas été résolu depuis de nombreuses années en raison d’un certain nombre de facteurs, notamment la nécessité pour certaines organisations et FAI d’avoir une compatibilité ascendante avec les appareils plus anciens, la transition vers des réseaux compatibles IPv6 et le besoin de certains administrateurs d’avoir de la simplicité et des performances dans leurs réseaux.
« Dans tous les cas », ont-ils ajouté, « ce problème ne peut pas être résolu de manière triviale, car certains FAI peuvent avoir mal configuré des appareils existants qui nécessiteront une coordination pour les remplacer/reconfigurer, etc. »
Les FAI devraient intégrer les mécanismes de filtrage recommandés depuis de nombreuses années afin d’interdire le trafic usurpé, ont indiqué les auteurs dans leur courrier électronique, en particulier le filtrage des entrées et des sorties. Les FAI doivent également s’assurer que leurs appareils, par défaut, ne transfèrent pas de paquets tunnelés sans authentification/chiffrement. Ils notent que le document aborde également la nécessité d’une inspection approfondie des paquets suspects tunnelisés.
Un fournisseur de VPN, ajoutent les auteurs, doit s’assurer que les protocoles de tunneling utilisés pour connecter ses clients à ses serveurs VPN sont sécurisés, en intégrant des mesures d’authentification et de cryptage telles que Wireguard, la suite de protocoles IPSec, OpenVPN et bien plus encore.
Les fournisseurs d’équipements réseau doivent s’assurer que leur équipement ne gère pas par défaut les paquets non sécurisés. Idéalement, ils devraient limiter leur utilisation uniquement en combinaison avec IPsec et émettre un avertissement lorsque l’appareil est configuré pour accepter des paquets de tunneling non authentifiés.
Si l’organisation d’un RSSI possède ses propres plages d’adresses IP, ont également déclaré les auteurs, elle devrait s’abonner à la Shadowserver Foundation pour recevoir des avertissements automatisés, car Shadowserver effectue des analyses quotidiennes et peut informer les propriétaires des hôtes vulnérables. Sinon, les organisations peuvent demander l’accès aux outils des auteurs pour confirmer que leur réseau ne contient aucun hôte de tunneling ouvert.