Au cours des dernières heures, une douzaine d'articles ont relaté la manière dont un pirate a tenté de voler des crypto-monnaies en exploitant une fuite BGP. (et a peut-être réussi).
Image CC BY 2.0 par elhombredenegro
Qu’est-ce que le protocole BGP ?
Le réseau Internet est composé de plusieurs axes. Pour notre résolveur DNS 1.1.1.1, nous vous indiquons que toutes les adresses IP comprises entre 1.1.1.0 et 1.1.1.255 sont accessibles depuis tous les PoP Cloudflare.
Les personnes ne disposant pas de liaison directe avec nos routeurs sont acheminées par l'intermédiaire de fournisseurs de transit, qui livrent les paquets à ces adresses à mesure qu'ils se connectent à Cloudflare et au reste d'Internet.
C’est là le fonctionnement normal d’Internet.
Il existe des organismes (Registres Internet régionaux ou RIR) chargés de distribuer les adresses IP afin d'éviter que des personnes utilisent les mêmes répertoires. Il s’agit de l’IANA, du RIPE, de l’ARIN, du LACNIC, de l’APNIC et de l’AFRINIC.
Qu’est-ce qu’une fuite BGP ?
Au sens large, une fuite BGP serait un espace d'adresses IP annoncé par quelqu'un qui n'a pas reçu l'autorisation du propriétaire. Lorsqu'un fournisseur de transit relaye l'annonce de Cloudflare concernant 1.1.1.0/24 et la diffuse sur Internet, nous le lui permettons. Il vérifie également en se servant des informations du RIR que seul Cloudflare peut le lui annoncer.
Cependant, il peut être compliqué de vérifier toutes les annonces. Surtout lorsque l'on sait qu'Internet compte plus de 700 000 liaisons et que des chaînes de fournisseurs échangent du trafic les uns avec les autres.
Du fait de leur nature, les fuites au niveau des liaisons sont localisées. Plus vous êtes connecté localement, plus le risque d'accepter une liaison à fuite est faible.
Pour être accepté sur une liaison légitime, la liaison doit :
soit avoir un préfixe plus petit (10.0.0.1/32 = 1 IP contre 10.0.0.0/24 = 256 IP) ;
soit avoir des indicateurs plus performants qu'un préfixe de même longueur (chemin plus court).
Les fuites BGP sont généralement dues à une erreur de configuration : un routeur annonce soudainement les adresses IP qu'il a apprises. Ou des préfixes plus courts utilisés en interne pour la gestion du trafic sont tout à coup rendus publics.
Mais il arrive parfois que cela provienne d'une intention malveillante. Le préfixe peut être réacheminé afin d'analyser passivement les données. Ou encore, quelqu'un peut mettre en place un service pour répondre de manière illégitime. Cela s’est déjà produit.
Que s'est-il passé aujourd'hui ?
Cloudflare dispose d'une gamme de collecteurs BGP recueillant des informations BGP à partir de centaines de routeurs à travers le monde.
BGP4MP|04/24/18 11:05:42|A|205.251.199.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.197.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.195.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.193.0/24|10297
BGP4MP|04/24/18 11:05:42|A|205.251.192.0/24|10297
...
BGP4MP|04/24/18 11:05:54|A|205.251.197.0/24|4826,6939,10297Entre 11:05:00 UTC et 12:55:00 UTC aujourd'hui, nous avons vu les annonces suivantes :
Voici des annonces plus précises des plages :
205.251.192.0/23205.251.194.0/23205.251.196.0/23205.251.198.0/23
Cet espace d’adresses IP est attribué à Amazon (AS16509). Mais l'ASN qui a annoncé que c'était eNet Inc (AS10297) à ses pairs l'a transmis à Hurricane Electric (AS6939).
Ces adresses IP sont pour lesserveurs DNS Amazon Route53. Lorsque vous effectuerez une requête pour l'une de leurs zones clientes, ces serveurs vous répondront.
Pendant les deux heures de fuite, les serveurs de la plage IP n'ont répondu qu'aux requêtes adressées à myetherwallet.com. Quelques personnes ont remarqué SERVFAIL.
Tout résolveur DNS auquel on a demandé des noms traités par Route53 a interrogé les serveurs de référence qui avaient été corrompus par la fuite BGP. Cela a empoisonné les résolveurs DNS dont les routeurs avaient accepté le routage.
Le résolveur DNS de Cloudflare 1.1.1.1 figuraient parmi ceux-ci. Nous avons été touchés à Chicago, Sydney, Melbourne, Perth, Brisbane, Cebu, Bangkok, Auckland, Muscat, Djibouti et Manille. Dans le reste du monde, 1.1.1.1 a fonctionné normalement.
BGP hijack this morning affected Amazon DNS. eNet (AS10297) of Columbus, OH announced the following more-specifics of Amazon routes from 11:05 to 13:03 UTC today:205.251.192.0/24205.251.193.0/24205.251.195.0/24205.251.197.0/24205.251.199.0/24
— InternetIntelligence (@InternetIntel) April 24, 2018
Correction: the BGP hijack this morning was against AWS DNS not Google DNS. https://t.co/gp3VLbImpX
— InternetIntelligence (@InternetIntel) April 24, 2018
$ dig +short myetherwallet.com @205.251.195.239
54.192.146.xxPar exemple, la requête suivante vous renverra les adresses IP légitimes d'Amazon :
Toutefois, pendant le détournement, elle a renvoyé des adresses IP associées à un fournisseur russe (AS48693 et AS41995). Vous n'aviez pas besoin d'accepter le détournement pour être victime de l'attaque : il suffisait d'utiliser un résolveur DNS empoisonné.
Si vous utilisiez HTTPS, le faux site Web arborait un certificat TLS signé par une autorité inconnue (le domaine indiqué dans le certificat était correct, mais il était auto-signé). Le seul moyen pour que cette attaque fonctionne était de continuer d’accepter le mauvais certificat. À partir de là, tout ce que vous envoyiez était crypté, mais l'attaquant disposait des clés.
Si vous étiez déjà connecté, votre navigateur envoyait les informations de connexion via le cookie. Sinon, votre nom d'utilisateur et votre mot de passe étaient envoyés si vous les aviez saisis sur une page de connexion.
Une fois que l'attaquant a obtenu les informations de connexion, il les a utilisées sur le site Web légitime pour transférer et voler de la crypto-monnaie Ethereum.
Résumé en images
Cas normal
Après une fuite de routage BGP
Régions touchées
Comme mentionné précédemment, AS10279 a annoncé ce routage. Cependant, seules quelques régions ont été touchées. Hurricane Electric est très présente en Australie, principalement en raison des coûts d'Internet. Chicago a été touchée, car AS10279 y est physiquement présent, ce qui a permis un échange de trafic direct.
Le graphique suivant montre le nombre de paquets reçus dans les régions affectées et non affectées (axe Y normalisé). La baisse est due au serveur de référence ne répondant plus à nos requêtes (il n'a répondu que pour un seul site et tous les autres domaines Amazon ont été ignorés).
Les autres fournisseurs de transits utilisés par eNet (CenturyLink, Cogent et NTT) ne semblaient pas avoir accepté ce routage : il se peut qu'ils aient des filtres et/ou Amazon en tant que client.
eNet fournit des services IP, donc un de ses clients aurait pu l'annoncer.
Peut-on blâmer quelqu'un ?
Étant donné le grand nombre d'acteurs impliqués, il est difficile de déterminer les responsabilités. Acteurs impliqués :
Le FAI qui a annoncé un sous-réseau qu'il ne possédait pas
Les fournisseurs de transit qui n'ont pas vérifié l'annonce avant de la relayer
Les FAI qui ont accepté le routage
Le manque de protection des résolveurs DNS et des DNS de référence
Le site de phishing hébergé chez des fournisseurs russes
Le site Web qui n'a pas exigé de certificats TLS légitimes
L'utilisateur qui a cliqué sur « Continuer » alors que le certificat TLS était invalide
Tout comme une blockchain, un changement de réseau est généralement visible et archivé. RIPE dispose d’une base de données à cette fin.
$ whois -h whois.radb.net ' -M 205.251.192.0/21' | egrep '^route:|^origin:|source:' | paste - - - | sort
route: 205.251.192.0/23 origin: AS16509 source: RADB
route: 205.251.192.0/23 origin: AS16509 source: REACHPouvons-nous remédier à la situation ?
Il s’agit d’une question difficile. Il existe des propositions pour sécuriser le protocole BGP :
Il est possible d'ajouter certains termes aux bases de données RIR, ce qui permet de générer une liste des sources autorisées :
L'établissement d'enregistrements RPKI/ROA avec le RIR comme source de vérité sur un trajet, bien que tout le monde ne crée pas ces enregistrements ou ne les valide pas. Les protocoles IP et BGP ont été créés il y a plusieurs décennies, avec des exigences différentes en matière d'intégrité et d'authenticité (moins de routes).
Il est possible de procéder à quelques manœuvres aux niveaux supérieurs de la pile réseau.
Sur les DNS, vous pouvez utiliser DNSSEC pour signer vos enregistrements. Les adresses IP renvoyées par le faux DNS n'auraient pas été signées, car elles ne disposent pas des clés privées.
Si vous utilisez Cloudflare en tant que DNS, vous pouvez activer DNSSEC en quelques clics dans le panneau.
Sur HTTPS, votre navigateur vérifiera le certificat TLS fourni par le site Web. Si HSTS est activé, le navigateur aura besoin d'un certificat valide à tout moment. La seule façon de générer un certificat TLS légitime pour un domaine serait d'empoisonner le cache d'un résolveur DNS sans DNSSEC de l'autorité de certification.
DANE offre un moyen d'associer des certificats à un nom de domaine en utilisant les DNS.
DNS over HTTPS permettrait également de confirmer que vous parlez au bon résolveur au cas où la fuite se produirait au niveau des résolveurs DNS au lieu des DNS de référence.
Il n'existe aucune solution parfaite ni unique. Plus ces protections sont nombreuses, plus il sera difficile pour un attaquant malveillant de perpétrer ce type d'attaque.