Domain Mayday EP05 : Le détournement massif de domaines DeFi sur Squarespace en 2024

En juillet 2024, la chose la plus dangereuse sur le site web d'un projet crypto n'était pas un bug de contrat intelligent ni une clé privée divulguée. C'était le registrar qui détenait le domaine.

Pendant quelques jours ce mois-là, les utilisateurs qui saisissaient une adresse familière dans leur navigateur — le site officiel d'un protocole de prêt de confiance, un bridge utilisé des centaines de fois — atterrissaient exactement là où ils s'attendaient, sur une page qui semblait parfaitement normale, avant de voir leurs portefeuilles se vider. Rien n'avait été piraté au sens habituel du terme. Personne n'avait deviné un mot de passe ni hameçonné une phrase de récupération. Les attaquants avaient simplement pénétré par la porte d'entrée du domaine lui-même, parce que cette porte avait été laissée ouverte lors d'un déménagement d'entreprise que la plupart de ces projets n'avaient jamais remarqué.

Ce déménagement, c'était la migration de Google Domains vers Squarespace. La porte ouverte, c'était les paramètres d'authentification par défaut de Squarespace. Et le résultat fut une vague coordonnée de détournements DNS visant des projets crypto et DeFi contrôlant, selon les termes d'un chercheur, des milliards de dollars d'actifs.

Comment une migration de registrar a créé une surface d'attaque massive

Les domaines ne sont généralement pas perçus comme une flotte. Chacun semble être une chose unique et privée — votre adresse, votre panneau de contrôle, vos enregistrements DNS. Mais les registrars les détiennent en masse, et lorsque l'ensemble de la clientèle d'un registrar migre vers un autre, chaque compte de cette base migre selon la même logique, avec les mêmes paramètres par défaut, au même moment. Toute faiblesse présente dans cette logique n'est pas un bug isolé. C'est une propriété de l'ensemble de la flotte.

C'est ce qui a fait de l'incident de 2024 un événement massif plutôt qu'une série de compromissions individuelles malheureuses.

En juin 2023, Squarespace a racheté environ 10 millions de noms de domaine à Google Domains, après que Google a annoncé la fermeture de son registrar. Au cours de l'année suivante, Squarespace a migré les utilisateurs pour environ 10 millions de noms de domaine acquis lors de la transaction. Pour rendre la transition la plus fluide possible, Squarespace avait précréé des comptes pour les personnes associées à chaque domaine migré, en se basant sur les adresses e-mail enregistrées par Google.

La fluidité était précisément le problème. Une migration qui ne demande rien à l'utilisateur est une migration où l'utilisateur n'a rien prouvé — ni son mot de passe, ni son identité, ni son contrôle de l'adresse e-mail. Les comptes existaient, les domaines y étaient rattachés, et la seule chose qui séparait un domaine de quiconque se présentait en premier était un écran de connexion qui, pour ces comptes migrés, ne demandait presque rien.

Les détournements de juillet 2024

Les attaques ont débuté le 9 juillet et se sont poursuivies les jours suivants. Elles n'étaient pas discrètes. Une vague d'attaques de détournement DNS coordonnées ciblait des domaines de cryptomonnaies en finance décentralisée (DeFi) utilisant le registrar Squarespace, redirigeant les visiteurs vers des sites de phishing hébergeant des videurs de portefeuilles, comme l'a rapporté BleepingComputer.

La première à faire du bruit était l'un des plus grands noms du prêt DeFi. La société de sécurité Blockaid, qui a enquêté sur l'incident, a constaté que les visiteurs de ces sites étaient redirigés vers des pages malveillantes conçues pour vider les fonds des portefeuilles connectés. Les faux sites n'étaient pas de grossières copies. Selon Blockaid, ces fausses dApps utilisaient la dernière itération du kit de vidage Inferno, conçu pour inciter les utilisateurs à signer des transactions qui videraient leurs portefeuilles.

La liste des victimes confirmées ressemblait à un appel nominal de l'écosystème. Les entités détournées comprenaient Celer Network, Compound Finance, Pendle Finance et Unstoppable Domains. Pour Compound, son domaine principal avait été pris en otage pour afficher une page de phishing. Celer a détecté la tentative et récupéré rapidement ses enregistrements DNS ; Pendle a subi des problèmes similaires et a averti ses utilisateurs de révoquer les autorisations accordées à leurs portefeuilles.

Ce qui était en jeu — et ce que les utilisateurs ont perdu

La cruauté d'un détournement de domaine réside dans le fait qu'il annule tous les réflexes que l'on apprend aux utilisateurs. Vérifiez l'URL. Assurez-vous que c'est le vrai site. Cherchez l'icône de cadenas. Tous ces conseils supposent que le domaine pointe encore là où il est censé le faire. Quand l'attaquant contrôle le DNS du domaine, l'URL est réelle — c'est l'adresse authentique du projet — et elle résout vers le serveur de l'attaquant. Le cadenas est vert. La barre d'adresse est honnête. La page est un piège.

C'est pourquoi des kits de vidage de portefeuilles comme Inferno se marient si bien avec le détournement DNS. Le videur n'a pas besoin de voler un mot de passe ; il a besoin que la victime connecte un portefeuille et signe. Et un utilisateur qui est arrivé sur le vrai domaine de son protocole de prêt n'a aucune raison d'hésiter avant d'approuver une transaction. Le site de phishing hérite de toute la confiance que le domaine légitime a mis des années à construire.

Quelle aurait pu être l'ampleur des dégâts ? Le chiffre qui a capturé l'étendue du problème n'était pas le nombre de vols confirmés, mais le nombre de projets exposés. L'analyse de Blockaid, rapportée par Decrypt, était sans détour : environ 228 interfaces DeFi sont encore en danger, car chacune d'elles était derrière la même faiblesse des comptes migrés. Les détournements qui ont eu lieu n'étaient qu'un échantillon. La surface d'attaque, c'était l'ensemble de la communauté crypto ayant migré de Google vers Squarespace.

Comment cela s'est produit : la faille d'authentification de la migration

Le mécanisme, une fois reconstitué par les chercheurs, était presque embarrassant de simplicité — ce qui le rendait dangereux à grande échelle.

Partons de deux choix de conception. Premièrement, Squarespace ne vérifiait pas que la personne qui se connectait contrôlait réellement l'adresse e-mail du compte. Comme l'ont formulé les chercheurs, Squarespace n'exige pas de vérification par e-mail pour les nouveaux comptes créés avec un mot de passe. Deuxièmement, les comptes migrés avaient été précréés mais pas encore réclamés — ils n'avaient pas de mot de passe défini. Ainsi, quand quelqu'un arrivait avec la bonne adresse e-mail, comme il n'y a pas de mot de passe sur le compte, le système les dirige directement vers le flux « créez un mot de passe pour votre nouveau compte ».

Assemblez ces deux éléments et l'attaque s'écrit d'elle-même. Les adresses e-mail liées aux domaines migrés n'étaient pas secrètes — les contacts administrateurs et titulaires sont souvent publics ou devinables. Un attaquant qui s'inscrivait simplement en premier sur le compte, en utilisant un e-mail migré connu, avant que le vrai propriétaire ne se soit jamais connecté, repartait avec le contrôle du domaine. Taylor Monahan, responsable produit principal chez MetaMask et l'une des chercheuses qui ont disséqué l'incident, a décrit précisément l'angle mort : Squarespace n'avait jamais envisagé la possibilité qu'un acteur malveillant puisse s'inscrire sur un compte en utilisant une adresse e-mail associée à un domaine récemment migré avant que le titulaire légitime n'ait créé son propre compte.

Pourquoi ce pré-lien existait-il ? Par commodité. Les chercheurs ont conclu que Squarespace supposait que tous les utilisateurs migrant depuis Google Domains choisiraient les options de connexion sociale — Google OAuth — plutôt que l'e-mail et le mot de passe. Le système pré-liait toutes les adresses e-mail aux domaines, qu'un compte existe déjà ou non, probablement parce qu'ils voulaient permettre aux utilisateurs de se connecter via OAuth Google et d'accéder immédiatement à l'ensemble de leurs domaines, comme les chercheurs l'ont expliqué à The Register. Mais le chemin e-mail/mot de passe n'a jamais été fermé, et sur ce chemin, rien ne prouvait le contrôle de la boîte de réception.

Il y avait un autre facteur aggravant. Durant la migration, la protection qui aurait dû détecter cela avait été désactivée : dans le cadre de la transition vers Squarespace, l'authentification multifacteur avait été désactivée sur les comptes. Même un propriétaire de domaine ayant soigneusement activé l'AMF sur Google Domains arrivait chez Squarespace avec cette AMF supprimée. Pas de mot de passe à craquer, pas de second facteur à contourner, pas d'e-mail à intercepter — pour un compte migré et non réclamé, la possession d'une adresse e-mail devinable constituait l'intégralité du processus d'authentification.

Réponse et mesures correctives

La communauté de sécurité crypto a réagi plus vite que le registrar. Des chercheurs — parmi lesquels Samczsun, Taylor Monahan et Andrew Mohawk — ont publié le mécanisme, et Blockaid a diffusé des listes d'interfaces encore vulnérables pour que les projets puissent vérifier leur exposition. Les projets touchés ont couru pour récupérer leurs comptes, réinitialiser leurs enregistrements DNS et avertir leurs utilisateurs de révoquer les approbations de tokens accordées aux sites malveillants.

Le conseil de remédiation immédiat était le même pour tous ceux qui utilisaient encore un compte migré : se connecter et revendiquer le compte avant qu'un attaquant ne le fasse, définir un mot de passe fort et unique, et — surtout — réactiver l'authentification multifacteur, que la migration avait silencieusement supprimée. De son côté, Squarespace a travaillé à verrouiller les comptes migrés et le flux de création de compte. Mais la leçon structurelle a survécu au correctif : un contrôle de sécurité qu'un fournisseur désactive pendant une migration est, le temps de cette migration, un contrôle qui n'existe pas.

Ce que cela enseigne sur la sécurité des registrars et l'AMF

Les détournements sur Squarespace ne sont pas vraiment l'histoire d'une mauvaise configuration d'une seule entreprise. C'est l'histoire de l'endroit où réside réellement le contrôle d'un domaine, et à quel point la couche au-dessus de la blockchain reste fragile.

Quelques enseignements se généralisent bien au-delà de juillet 2024 :

1. Le compte registrar est la vraie racine de confiance — pas le contrat intelligent. Aucun des protocoles touchés n'avait de bug de contrat. Leur code on-chain était correct. Les attaquants ont pris le domaine, et le domaine est ce que les utilisateurs saisissent, font confiance, et connectent leurs portefeuilles. Un projet peut être irréprochable on-chain et quand même livrer ses utilisateurs à un attaquant si son plan de contrôle DNS est défaillant.

2. L'AMF n'est une protection que si elle survit aux migrations. Le détail douloureux ici est que l'AMF n'a pas échoué sous l'attaque — elle a été supprimée avant l'attaque, comme commodité de migration. Traitez le statut de l'AMF comme quelque chose à re-vérifier après chaque déplacement de compte, transfert ou changement de fournisseur, et non comme quelque chose que l'on configure une fois pour toutes.

3. « Transparent » est un compromis de sécurité. Chaque étape qu'une migration supprime pour la commodité de l'utilisateur est une étape où l'identité n'est pas prouvée. Les comptes précréés, les e-mails auto-liés et les connexions sans vérification sont autant de frictions que l'utilisateur n'a pas ressenties — et la friction est, très souvent, ce qui empêchait les attaquants d'entrer.

4. Les identifiants devinables sont des identifiants déguisés. Le « secret » qui a déverrouillé ces domaines était une adresse e-mail qui n'a jamais été secrète. Tout système dans lequel la connaissance d'un identifiant public accorde un contrôle n'est qu'à une usurpation d'identité d'une compromission.

5. Le rayon d'explosion d'un registrar est égal à l'ensemble de sa clientèle. La sécurité individuelle d'un domaine n'a pas d'importance si le comportement par défaut du registrar est faible, car le défaut s'applique à tout le monde en même temps. L'endroit où vit votre domaine, et la façon dont ce dépositaire gère l'authentification, est une décision de sécurité aussi importante que n'importe laquelle que vous prenez on-chain.

L'angle Namefi

Les détournements de 2024 se sont produits dans l'écart entre « qui possède vraiment ce domaine » et « qui peut se connecter au compte qui le contrôle ». Dans le modèle traditionnel, ces deux choses ne sont que vaguement liées : la propriété est un enregistrement dans la base de données d'un registrar, et l'accès est conditionné par l'authentification que ce registrar impose à ce moment-là — y compris au milieu d'une migration de 10 millions de domaines où la porte était, brièvement, grande ouverte.

Namefi est conçu pour combler cet écart. En représentant la propriété du domaine comme un actif tokenisé on-chain compatible avec le DNS, le contrôle devient quelque chose que l'on peut vérifier cryptographiquement plutôt que quelque chose qui repose sur un e-mail devinable et des paramètres de connexion par défaut d'un fournisseur. La propriété réside dans un portefeuille que vous contrôlez, les transferts sont auditables, et la question « qui est autorisé à modifier les enregistrements de ce domaine » a une réponse inviolable plutôt qu'une réponse du service client.

Cela n'aurait pas rendu la migration de Squarespace parfaite. Mais cela change le mode de défaillance. Un attaquant qui crée un compte avec un e-mail connu ne possède pas pour autant un domaine tokenisé — la propriété n'est pas une ligne qu'un compte à moitié initialisé peut silencieusement s'approprier. Le plan de contrôle d'un nom de domaine devrait être aussi difficile à usurper que les actifs qu'il protège. En juillet 2024, pour des centaines de projets crypto, ce n'était pas le cas. C'est précisément cet écart qui mérite d'être comblé par l'ingénierie.

Sources et lectures complémentaires

• Krebs on Security — Researchers: Weak Security Defaults Enabled Squarespace Domains Hijacks
• BleepingComputer — DNS hijacks target crypto platforms registered with Squarespace
• Blockaid — Squarespace Domain Hijacking Incident: Attack Report
• SecurityWeek — Hackers Exploit Flaw in Squarespace Migration to Hijack Domains
• Decrypt — More Than 220 DeFi Protocols Still 'at Risk' From Squarespace DNS Hijack
• The Register — Infoseccers claim Squarespace migration linked to DNS hijackings at Web3 firms
• Socket — Squarespace Domain Hijacks Enabled by Email Address Exploit on Migrated Accounts
• SiliconANGLE — Multiple crypto domains hijacked from Squarespace due to Google Domains migration flaw
• Cybernews — Squarespace crypto domains under DNS attack, lack of MFA to blame
• Hackread — DeFi Hack Alert: Squarespace Domains Vulnerable to DNS Hijacking
• CircleID — Security Lapses Lead to Squarespace Domain Hijacks