Geek Mexicain

Rétro-ingénierie d'une attaque récente de grande ampleur, pour vous prouver que naviguer sur le web en 2018 n'est toujours pas sécurisé en tout point...

Internet... Nous utilisons ce mot au quotidien des centaines de fois, mais faisons-nous souvent allusion aux différents réseaux ("systèmes autonomes" pour être exact) le composant ?
Ceux-ci sont complètement transparents pour nous quand nous surfons, alors que nous en traversons des dizaines en permanence.

Pourtant, l'évènement ayant eu lieu le 24 avril de cette année nous prouve que l'interconnexion de ces derniers laisse ouvertes des failles pouvant être exploitées à très grandes échelles, et parfois même totalement à notre insu.

Les étapes décrites ci-dessous n'étant pas évidentes, j'invite fortement le lecteur (ou la lectrice !) à se munir d'un papier et d'un crayon ;)

La cible de l'attaque : MyEtherWallet.com (MEW)

Vous le connaissez peut-être si vous vous êtes déjà intéressé(e) de près ou de loin à la cyptomonnaie ou à la blockchain, myetherwallet.com est un site faisant office de portefeuille (wallet) pour la chain Ethereum (ayant l'Ether comme monnaie donc)... Parmi tant d'autres.

Un tel site Internet stocke gentiment les clefs privées (normalement de manière chiffrée) des utilisateurs lui faisant confiance, leur permettant à leur tour d'effectuer des transactions sur la chain.
Ces mêmes clefs sont également la cible des attaquants qui, une fois en mains, peuvent décider de l'avenir et de l'appartenance des ethers des victimes.
Sauf que ces entités sont indexées directement sur le dollar Américain, ce qui leur donne donc une valeur, bien que volatile et contestable d'un point de vue purement économique.

Déroulement de l'attaque

Détournement de route

Vous le savez maintenant, Internet est composé d'une multitude de réseaux inter-connectés.
Quand vous envoyez un "paquet" de votre client A à un serveur B sur la planète, il est transporté de point en point à travers différents réseaux grâce à des équipements bien connus : les routeurs.
Afin de déterminer quelle route est la meilleure (en fonction de la rapidité, de la fiabilité, etc.), les routeurs échangent en permanence des informations au travers d'un protocole peu connu : BGP (Border Gateway Protocol).

Cependant BGP commence à être un peu âgé, et ne prend pas en compte le fait que des réseaux puissent émerger en étant d'origines ""malveillantes"".
Il n'intègre tellement pas de mécanisme de sécurité qu'il "suffit" à des attaquants de forger des paquets BGP indiquant qu'ils "connaissent" une route plus précise ou plus rapide vers une plage d'adresses IP, pour que les routeurs les plus proches se mettent potentiellement à router les paquets vers leur infrastructure réseau (avec en plus un effet de propagation sur les routeurs inter-connectés à leur tour, et ainsi de suite).

Dans notre cas, il s'agit des routes menant aux résolveurs de noms de domaine d'Amazon Web Service (Route 53) qui ont été visées (voir ci-dessous le rôle qu'elles ont joué dans l'attaque).
Techniquement, les préfixes d'adresses menant à ces résolveurs en question sont :

205.251.192.0/23

205.251.194.0/23

205.251.196.0/23

205.251.198.0/23

Cependant, entre 11h05 et 13h03 le 24 avril dernier, voici les routes que certains systèmes autonomes se sont mis à proposer :

205.251.192.0/24

205.251.193.0/24

205.251.195.0/24

205.251.197.0/24

205.251.199.0/24

Le masque possédant 1 octet de plus que les préfixes d'adresses légitimes, les attaquants ont "proposé" de facto des routes plus précises (pour les routeurs, elles permettraient de rejoindre plus "rapidement" une destination telle que 205.251.193.10 par exemple).

En faisant un petit calcul très rapide, on se rend compte que c'est près de ~1 280 adresses IP qui ont donc été déroutées pour les utilisateurs navigant à travers les systèmes autonomes concernés, et non 13 000 comme il est possible de le lire à certains endroits.

Ces routes à l'origine (11h05) ont été originellement proposées par eNet (AS10297), puis re-proposées quasiment instantanément par d'autres AS interconnectés à ce dernier, tels que l'AS6939 (Hurricane Electric) ou bien l'AS6237 (Shaw Communications).

NB : Les plus attentifs d'entre vous auront pu remarquer que les attaquants n'ont pas dérouté uniquement les plages appartenant à Amazon. Dans le lot se sont retrouvées également concernées certaines adresses appartenant à CloudFlare.

---

Petit détail et une question que l'on peut tout de même se poser avant de passer à la suite :

Pourquoi ces routes-ci en particulier (celles avec les valeurs impaires), et non celles indiquées plus haut, avec un /24 de la même façon ?

Parce qu'une cible était particulièrement dans le viseur : MEW (sans trop de surprise) !

Si l'on s'amuse maintenant à faire un petit whois sur son nom de domaine, voici ce qui apparaît (cela va nous servir pour la prochaine partie !) :

---

Pour résumer en une phrase : Ces nouvelles routes ont eu comme effet de rediriger le traffic DNS à destination des résolveurs d'Amazon (premières victimes dans l'histoire), vers un serveur tiers (hébergé chez Equinix, à Chicago), appartenant aux attaquants.

Analyse personnelle : Le serveur des attaquants ayant été hébergé chez Equinix, qui n'est rien d'autre qu'un Internet Exchange Point (point où différents systèmes autonomes s'interconnectent ["peering"]), il est fort probable que l'annonce des fausses-routes ait pris de l'ampleur de par la position géographique stratégique de cette infrastructure.

Fausse résolution DNS

DNS est un protocole permettant de résoudre des noms de domaine.
En d'autres termes, il translatera les noms de domaine (faciles à retenir) en adresses IP qui vous permettent ensuite de joindre les serveurs correspondant.
Par exemple, lorsque vous tapez https://geek-mexicain.net/, votre navigateur effectuera automatiquement une requête vers le serveur DNS que vous aurez paramétré (ou bien celui que votre réseau aura choisi pour vous), qui obtiendra finalement pour vous une réponse d'un serveur faisant autorité sur la zone cible (.net. dans le cas de l'exemple précédent).
Pour l'URL renseignée ci-dessus, il vous répondra (si tout va bien !) : 178.170.102.55.

Nous avons vu précédemment que les attaquants sont parvenus à rediriger les requêtes vers les DNS d'Amazon sur une machine qu'ils possedaient, sur la côte Ouest des USA.

"Mais pourquoi ?" me diriez-vous.
Il se trouve que MEW est hébergé chez l'AWS d'Amazon et que les serveurs de noms faisant ainsi autorité sur ce nom de domaine sont ceux de Route53, les première cibles !

Maintenant, re-sortons notre nslookup (voilà ce qui arrive quand on écrit un article depuis Windows !), et amusons-nous à ns-looker les noms de domaine des résolveurs faisant autorité pour MEW :

Les adresses surlignées ne vous rappellent rien de familier ? Remontez jeter un coup d'oeil à la partie précédente ;)

C'est bon vous comprenez maintenant pourquoi les attaquants n'ont proposé que certaines fausses routes ?

Analyse personnelle : Il est possible qu'ils aient limité la portée de l'attaque pour que le re-routage soit le plus discret possible tout en ayant 100% de match sur les requêtes DNS pour MEW. Manque de bol pour eux, certaines autorités surveillent en permanence l'état du réseau mondial, et leurs fausses-annonces ont été repérées aux alentours de 12h55.

L'étape suivante de l'attaque a été donc de répondre aux requêtes désirant résoudre myetherwallet.com, mais potentiellement toutes les autres également (rappelez-vous, d'autres plages d'adresses ont été déroutées aussi) avec une adresse illégitime : Celle d'un autre serveur qu'ils possedaient (situé en Russie).

Pendant que nous y sommes, beaucoup d'articles qui traitent de ce sujet se basent sur la géolocalisation de ce fameux second serveur pour affirmer que les attaquants soient d'origine Russe.
Bien que cela soit effectivement possible (et probable), n'oublions pas qu'il est facile de disposer d'un serveur sur Internet, et ce n'importe où sur la planète.

L'intérêt final de toute cette masquarade ? Partie suivante !

Un phishing (presque) parfait

Les utilisateurs recevant cette réponse biaisée du résolveur des attaquants ont donc été rédirigés vers un faux site myetherwallet.com qui ressemblait étrangement à... l'original !

Usuellement, les campagnes de phishing de ce type sont vectorisés par des milliers de courriels envoyés sur toute la planète jusqu'à tomber sur une personne peu sensibilisée ou bien étourdie.

Pourquoi ne pas intervenir directement au milieu du routage Internet pour surprendre une très grande partie des utilisateurs sans aucune mauvaise action de leur part ?
C'est ce que les attaquants ont réussi à mettre en oeuvre jusque là !

Cependant, l'attaque aurait pu être parfaite, mais il y a eu un problème : HTTPS.
Il se trouve que les attaquants n'ont pas réussi à générer un certificat TLS reconnu par une autorité de certification (coucou Let's Encrypt !) et se sont donc "contentés" d'un certificat auto-signé.

Vous ne voyez pas en quoi cela a été un problème pour eux ? Pourtant je suis sûr que vous connaissez bien le type d'avertissement que l'on reçoit dans ce cas ;)

Analyse personnelle : Le déroutage n'ayant pas touché une assez grande partie du réseau mondial, il est probable que Let's Encrypt ! (s'ils l'ont effectivement utilisé), durant sa procédure de vérification, ait obtenu comme réponse l'adresse légitime de myetherwallet.com, et non celle du serveur des pirates, de la part de Route 53 vers lequel le routage n'a pas dû être impacté.
Ainsi, le processus de validation n'a pas pu aboutir, et les pirates n'ont pas obtenu de certificat valide pour ce nom de domaine.

Conséquences de l'attaque

En à peine plus de 2 heures, les attaquants ont réussi à dérober l'équivalent de 150 000$ (~200 ethers au moment de la rédaction de cet article), et non ~18 000 000$ comme il est possible de le lire sur beaucoup d'articles.

Il se trouve en fait que le portefeuille des attaquants contenait déjà effectivement une vingtaine de Millions de dollars, présente bien avant la date de l'attaque... Fruits d'un précédent coup monté ?

Des moyens de mitigation ?

À vrai dire... Pas vraiment.

Faisons un rapide tour d'horizon de ce qu'on peut lire à ce sujet à travers différents articles ou forums au sujet des protocoles pouvant nous prémunir, ou non, de ce type d'attaques :

• HSTS : Non. Tout nouvel utilisateur n'ayant jamais visité MEW aurait pu être assujetti à l'attaque de manière transparente.
• DNSSec : Oui mais... non. Il se trouve que malgré le gain en sécurité qu'il apporte, "peu" de TLD laissent la possibilité de l'installer, et pour ceux où c'est effectivement possible, peu d'administrateurs le mettent en place...
• MANRS : Du bricolage à la tonton-barbu-des-années-90' dans le but de patcher les trous causés par BGP (en partie), mais rien de viable sur le long terme car le problème est bien systèmique (et en plus certains AS n'implémentent pas la totalité des recommandations).
  Cependant, dans la plupart des cas, effectuer un filtrage de préfixe (prefix filtering) comme préconisé permet de contrer des tentatives d'attaques de ce type.
• BGPSec : Oui ! Mais... La norme date d'environ 8 mois, donc il faudra attendre encore quelques années avant de le voir déployé et utilisé à l'échelle mondiale...

Dans notre cas, il est important de souligner que si les attaquants étaient parvenus à obtenir un certificat TLS valide, l'attaque aurait pris une ampleur colossale (en partant du principe que beaucoup d'utilisateurs n'ont pas outre-passer le message d'avertissement concernant la non-validité du certificat auto-signé durant ces deux heures de déroutage).

Conclusion

On ne va pas dire que des attaques de ce genre sont courantes mais... presque (amusez-vous à taper "bgp" sur votre moteur de recherche préféré).

Pire que cela d'ailleurs, elles ont déjà été constatées au niveau étatique, lorsque la Chine, les USA, la Russie ou même l'Italie (!) se sont permis de dérouter de grandes parties du réseau mondial afin de le faire passer par chez eux (Man in the middle à très grande échelle).

Pour les lecteurs non-initiés, nous rappelons que durant ce type d'attaque, l'intégralité des données transitant sur le réseau sont à la merci de l'Homme du Milieu. Vous comprendrez donc l'intérêt de chiffrer les communication de bout-en-bout (HTTPS pour le traffic web).

Constatant le niveau de sophistication de cette attaque, il est évident que rien n'ait été laissé au hasard et qu'elle est le résultat de quelques heures de préparation minutieuse.