Résumé

  • Le détournement n’a pas remplacé Internet : des routes plus spécifiques ont attiré certains résolveurs vers un faux serveur faisant autorité, tandis que d’autres chemins continuaient d’atteindre Amazon Route 53.
  • La défense exige une responsabilité par couche et des refus indépendants : filtrage de routes, ROV, validation DNSSEC, HSTS, contrôle du certificat et confirmation séparée de l’action irréversible.

Une carte faite de résolveurs, non de pays

Le 24 avril 2018, Cloudflare vit son résolveur 1.1.1.1 touché à Chicago, dans plusieurs villes d’Australie et d’Asie, à Muscat et à Djibouti. D’autres implantations continuèrent normalement. Cette carte discontinue ne suivait ni une frontière politique, ni la clientèle de MyEtherWallet, ni l’ensemble du réseau d’Amazon.

Elle suivait des décisions de routage. Entre environ 11 h 05 et 12 h 55 UTC, des préfixes /24 plus spécifiques apparurent dans quatre blocs /23 d’Amazon utilisés par Route 53. L’origine observée était AS10297, celle d’eNet, et certains chemins passaient par Hurricane Electric AS6939. Cloudflare précisa qu’un client d’eNet pouvait avoir émis les annonces. L’ASN observé n’est donc pas une attribution pénale.

Chaque réseau choisit ensuite ce qu’il propageait et ce qu’il préférait. Certains transits d’eNet ne semblèrent pas accepter les routes. Là où elles furent retenues, la règle du préfixe le plus spécifique attira les paquets destinés aux adresses concernées, même si les routes légitimes d’Amazon restaient présentes.

Le résolveur récursif donna à cette anomalie une portée indirecte. Il consulta le serveur faisant autorité que sa propre table de routage lui permettait d’atteindre. Ses clients reçurent ensuite sa réponse, même lorsque leur réseau d’accès n’avait jamais choisi la route hostile. Le risque d’un utilisateur dépendait ainsi d’une décision prise ailleurs, dans l’infrastructure d’un service partagé.

Le faux serveur ne possédait qu’un pouvoir étroit

Selon les observations de Cloudflare, le serveur imposteur répondait pour myetherwallet.com et laissait échouer d’autres requêtes. Il ne reproduisait pas Route 53. Il exploitait une courte fenêtre pour un objectif précis.

Cette précision montre ce que l’attaquant n’avait pas obtenu. Aucun élément public ne prouve une connexion au compte AWS du client, une modification de la zone hébergée, une compromission du code de MyEtherWallet ou un transfert juridique des adresses d’Amazon. La route créait une capacité technique : recevoir certains paquets. Elle ne créait aucun titre sur le préfixe, le domaine ou le service.

La fausse réponse DNS n’était encore qu’une étape. Le site de hameçonnage présentait, d’après Cloudflare, un certificat auto-signé. Le navigateur pouvait signaler que l’émetteur n’était pas digne de confiance. L’attaque ne devenait financièrement utile que lorsqu’un utilisateur franchissait cette alerte et interagissait avec la page.

MyEtherWallet estima ensuite la perte à environ 150 000 dollars d’Ether. Cette somme est le chiffre publié par le service touché, non le résultat d’un audit indépendant disponible dans les sources examinées. Le nombre de victimes et le détail de toutes les transactions restent donc bornés.

Six autorités répondirent à six questions différentes

L’annonceur disait : « ce chemin permet d’atteindre ce préfixe ». Les transits décidaient s’ils transmettaient cette affirmation. Le réseau du résolveur décidait quelle route il installait. Le résolveur acceptait ou validait les données DNS. Le navigateur évaluait le certificat. Enfin, l’application et l’utilisateur autorisaient une action sur des actifs.

Aucune de ces réponses ne contenait les autres. Une route joignable n’authentifiait pas la zone. Une réponse DNS ne garantissait pas le certificat. Un certificat valide n’aurait pas, à lui seul, garanti l’honnêteté de la page. Et une page bien identifiée n’aurait pas prouvé l’intention exacte d’un transfert.

Le mot « détournement » donne l’impression d’un remplacement. L’incident ressemblait plutôt à un assemblage temporaire. L’attaquant emprunta le pouvoir de chaque couche sans posséder l’ensemble. C’est précisément ce qui rendit la détection difficile : chaque opérateur ne voyait qu’une partie du mensonge.

RPKI et DNSSEC ferment des portes différentes

Le RFC 6811 décrit la validation d’origine. Des ROA correctement bornées permettent aux réseaux pratiquant ROV de classer comme Invalid une annonce plus spécifique provenant d’un autre ASN, puis de la rejeter selon leur politique locale avant qu’elle n’influence un résolveur.

Cette amélioration ne transforme pas RPKI en validation du chemin complet. Un adversaire déterminé peut chercher à falsifier l’origine autorisée dans l’AS-PATH. L’adoption de ROV reste inégale et le maxLength d’une ROA détermine quelles annonces plus spécifiques elle rend Invalid.

DNSSEC traite un autre objet. Les RFC 4033 et 9364 définissent l’authentification de l’origine et l’intégrité des données DNS. Un résolveur validant peut refuser une réponse qui ne possède pas la signature attendue, même s’il a atteint le mauvais serveur par BGP. DNSSEC ne corrige pas le chemin ; il empêche ce chemin d’inventer une donnée authentifiée.

AWS annonça en décembre 2020 la signature DNSSEC des zones publiques Route 53 et la validation par Route 53 Resolver. Cette date documente une capacité ultérieure. Elle ne suffit pas à reconstituer l’état de la zone de MyEtherWallet en 2018 ni à attribuer toute la responsabilité à une fonctionnalité alors absente sous cette forme.

Lire correctement la réponse de MyEtherWallet

Après l’incident, MyEtherWallet annonça une migration vers Cloudflare et cita verrouillage du registre et du bureau d’enregistrement, HSTS et préchargement HSTS, CAA, DNSSEC, CDN et protection DDoS. La liste réunissait des défenses utiles, mais dirigées contre des mécanismes différents.

Les verrous de domaine protègent contre le transfert ou le changement non autorisé des serveurs de noms. Ils n’arrêtent pas une route BGP déjà propagée. CAA limite les autorités de certification autorisées ; il ne transforme pas un certificat auto-signé en certificat accepté. HSTS préchargé retire à l’utilisateur la possibilité de contourner l’erreur TLS. DNSSEC permet au résolveur de rejeter la fausse donnée. ROA et ROV agissent avant, sur l’origine de la route.

Une direction doit demander pour chaque mesure : quelle condition précise bloque-t-elle, qui l’opère, comment voit-on son échec et quel état demeure après le retour à la normale ? Sans cette table, « sécurité DNS renforcée » devient une formule qui masque les coutures.

La primauté du code comme limite analytique

La Running-Code Primacy de Heng Lu aide à séparer capacité et mandat. L’annonce AS10297 eut une force pratique parce que des réseaux l’acceptèrent. Elle ne conféra aucune autorité légitime sur les actifs d’Amazon. La réponse du faux serveur eut un effet parce que des résolveurs la servirent. Elle ne devint pas pour autant la vérité de la zone.

Le modèle distribué ne garantit donc pas le bon résultat. Plusieurs décisions locales peuvent s’aligner sur un mauvais état. Sa vertu réside ailleurs : chaque couche peut encore refuser. Un transit peut filtrer, un réseau peut rejeter Invalid, un résolveur peut valider DNSSEC, un navigateur peut imposer HSTS et une interface matérielle peut confirmer la destination finale.

La responsabilité consiste à préserver ces refus, puis à faire circuler leurs signaux. Aucun comité central ne pourra retirer assez vite une transaction déjà signée. L’architecture doit stopper la chaîne avant l’irréversible.

Ce que l’incident permet de conclure

L’événement ne fut ni mondial ni uniforme. Il n’identifie pas publiquement son auteur. Il ne prouve pas une compromission d’AWS ou du logiciel MyEtherWallet. Il ne montre pas non plus que l’utilisateur fut l’unique cause : l’alerte TLS arriva après plusieurs acceptations hostiles par l’infrastructure.

Il montre qu’un service critique dépend de preuves dont les propriétaires sont différents. Lorsque ces preuves sont confondues, une route temporaire peut emprunter un nom, et un nom peut emprunter la confiance d’une application. Lorsque les preuves restent séparées, une couche tardive peut encore arrêter une couche antérieure.

La meilleure défense n’est donc pas un gardien universel. C’est une chaîne où aucune affirmation étroite ne devient silencieusement une autorisation générale.

Sources