Domain Mayday EP05: Der Squarespace-DeFi-Domain-Massenraub 2024

Im Juli 2024 war das Gefährlichste an der Website eines Krypto-Projekts kein Smart-Contract-Fehler und kein durchgesickerter privater Schlüssel. Es war der Registrar, dem die Domain gehörte.

Über mehrere Tage in jenem Monat landeten Nutzer, die eine vertraute Adresse in ihren Browser eingaben – die offizielle Website eines Kreditprotokolls, dem sie vertrauten, einer Brücke, die sie hundertmal benutzt hatten – genau dort, wo sie es erwarteten: auf einer Seite, die exakt richtig aussah, und sahen dann zu, wie ihre Wallets geleert wurden. Gehackt wurde im üblichen Sinne nichts. Niemand hatte ein Passwort geknackt oder eine Seed-Phrase abgefischt. Die Angreifer waren schlicht durch die Eingangstür der Domain selbst spaziert, weil diese Tür während eines Firmenumzugs ungesperrt geblieben war, den die meisten dieser Projekte gar nicht bemerkt hatten.

Der Umzug war die Migration von Google Domains zu Squarespace. Die offene Tür waren die Standard-Authentifizierungseinstellungen von Squarespace. Das Ergebnis war eine koordinierte Welle von DNS-Hijacks gegen Krypto- und DeFi-Projekte, die – so ein Forscher – Milliarden von Dollar an Vermögenswerten kontrollierten.

Wie eine Registrar-Migration eine Massenangriffsfläche schuf

Domains werden normalerweise nicht als Flotte betrachtet. Jede einzelne fühlt sich wie etwas Persönliches an – Ihre Adresse, Ihr Kontrollpanel, Ihre DNS-Einträge. Aber Registrare halten sie in großer Zahl, und wenn der gesamte Kundenstamm eines Registrars zu einem anderen wechselt, folgen alle Konten derselben Migrationslogik, mit denselben Standardeinstellungen, zur selben Zeit. Welche Schwäche auch immer in dieser Logik steckt, ist kein Einzelfehler. Sie ist eine Eigenschaft der gesamten Flotte.

Genau das machte den Vorfall von 2024 zu einem Massenereignis und nicht zu einer Reihe von Einzelpech-Kompromittierungen.

Im Juni 2023 kaufte Squarespace rund 10 Millionen Domainnamen von Google Domains, nachdem Google angekündigt hatte, seinen Registrar zu schließen. Im darauffolgenden Jahr migrierte Squarespace die Nutzer für rund 10 Millionen Domainnamen, die im Rahmen der Transaktion erworben wurden. Damit der Übergang nahtlos wirkte, legte Squarespace vorab Konten für die Personen an, die mit jeder migrierten Domain verknüpft waren, unter Verwendung der E-Mail-Adressen, die Google gespeichert hatte.

Nahtlos war genau das Problem. Eine Migration, die dem Nutzer nichts abverlangt, ist eine Migration, bei der der Nutzer nichts bewiesen hat – weder sein Passwort noch seine Identität noch seine Kontrolle über die E-Mail-Adresse. Die Konten existierten, die Domains waren verknüpft, und das Einzige, was zwischen einer Domain und demjenigen stand, der als Erster auftauchte, war ein Anmeldebildschirm, der für diese migrierten Konten fast nichts verlangte.

Die Hijacks im Juli 2024

Die Angriffe begannen am 9. Juli und zogen sich über die folgenden Tage hin. Sie waren nicht subtil. Eine Welle koordinierter DNS-Hijacking-Angriffe richtete sich gegen Domains von dezentralen Finanz- (DeFi) Kryptowährungsplattformen, die den Registrar Squarespace nutzten, und leitete Besucher auf Phishing-Seiten mit Wallet-Drainern um, wie BleepingComputer berichtete.

Der erste, der für Aufmerksamkeit sorgte, war einer der bekanntesten Namen im DeFi-Kreditwesen. Das Sicherheitsunternehmen Blockaid, das den Vorfall untersuchte, stellte fest, dass Besucher dieser Seiten auf bösartige Seiten umgeleitet wurden, die darauf ausgelegt waren, Gelder aus verbundenen Wallets abzuziehen. Die gefälschten Seiten waren keine plumpen Fälschungen. Laut Blockaid verwendeten diese gefälschten dApps die neueste Version des Inferno-Drainer-Kits, das Nutzer dazu verleiten soll, Transaktionen zu unterzeichnen, die ihre Wallets leeren.

Die Liste der bestätigten Opfer las sich wie ein Aufmarsch des Ökosystems. Zu den gekaperten Entitäten gehörten Celer Network, Compound Finance, Pendle Finance und Unstoppable Domains. Bei Compound wurde die Hauptdomain übernommen, um eine Phishing-Seite anzuzeigen. Celer entdeckte den Versuch und stellte seine DNS-Einträge schnell wieder her; Pendle hatte ähnliche Probleme und warnte seine Nutzer, Wallet-Freigaben zu widerrufen.

Was auf dem Spiel stand – und was Nutzer verloren

Die Grausamkeit eines Domain-Hijacks besteht darin, dass er jede Gewohnheit unterläuft, auf die Nutzer trainiert wurden. Überprüfen Sie die URL. Stellen Sie sicher, dass es die echte Seite ist. Achten Sie auf das Schlosssymbol. All dieser Rat setzt voraus, dass die Domain noch dorthin zeigt, wo sie soll. Wenn der Angreifer die DNS der Domain kontrolliert, ist die URL echt – es ist die genuine Adresse des Projekts – und sie löst zum Server des Angreifers auf. Das Schloss ist grün. Die Adressleiste lügt nicht. Die Seite ist eine Falle.

Deshalb passen Wallet-Drainer-Kits wie Inferno so gut zu DNS-Hijacking. Der Drainer muss kein Passwort stehlen; er braucht das Opfer dazu, eine Wallet zu verbinden und zu unterzeichnen. Und ein Nutzer, der die echte Domain seines Kreditprotokolls aufgerufen hat, hat keinen Grund zu zögern, bevor er eine Transaktion genehmigt. Die Phishing-Seite erbt das gesamte Vertrauen, das die legitime Domain über Jahre aufgebaut hat.

Wie schlimm hätte es werden können? Die Zahl, die das Ausmaß verdeutlichte, war nicht die Anzahl der bestätigten Diebstähle, sondern die Anzahl der exponierten Projekte. Blockaid's Analyse, von Decrypt berichtet, war unmissverständlich: rund 228 DeFi-Protokoll-Frontends sind noch immer gefährdet, weil jedes einzelne hinter derselben Schwachstelle der migrierten Konten saß. Die tatsächlichen Hijacks waren nur eine Stichprobe. Die Angriffsfläche war die gesamte Krypto-Gemeinschaft, die die Google-zu-Squarespace-Migration mitgemacht hatte.

Wie es passierte: der Authentifizierungsfehler der Migration

Der Mechanismus war, nachdem Forscher ihn rekonstruiert hatten, fast beschämend einfach – was ihn im großen Maßstab gefährlich machte.

Beginnen wir mit zwei Gestaltungsentscheidungen. Erstens überprüfte Squarespace nicht, ob die Person, die sich anmeldete, tatsächlich die Kontrolle über die E-Mail-Adresse des Kontos hatte. Wie die Forscher es formulierten, verlangt Squarespace keine E-Mail-Verifizierung für neue Konten, die mit einem Passwort erstellt werden. Zweitens waren die migrierten Konten zwar vorab angelegt, aber noch nicht beansprucht worden – sie hatten kein Passwort. Wenn also jemand mit der richtigen E-Mail-Adresse auftauchte, da kein Passwort auf dem Konto vorhanden ist, wird man direkt zum Ablauf „Passwort für Ihr neues Konto erstellen" weitergeleitet.

Diese beiden Punkte zusammen, und der Angriff schreibt sich von selbst. Die E-Mail-Adressen, die mit migrierten Domains verknüpft waren, waren kein Geheimnis – Admin- und Registranten-Kontakte sind oft öffentlich oder erraten. Ein Angreifer, der das Konto einfach zuerst registrierte, mit einer bekannten migrierten E-Mail, bevor der echte Eigentümer sich jemals anmeldete, hatte damit die Kontrolle über die Domain. MetaMask-Leiterin für Produktmanagement Taylor Monahan, eine der Forscherinnen, die den Vorfall untersuchte, beschrieb den blinden Fleck präzise: Squarespace hat nie die Möglichkeit berücksichtigt, dass ein Bedrohungsakteur sich für ein Konto mit einer E-Mail-Adresse anmelden könnte, die mit einer kürzlich migrierten Domain verknüpft ist, bevor der legitime E-Mail-Inhaber das Konto selbst erstellt.

Warum gab es die Vorab-Verknüpfung überhaupt? Der Bequemlichkeit halber. Die Forscher kamen zu dem Schluss, dass Squarespace davon ausging, alle von Google Domains migrierenden Nutzer würden die Social-Login-Optionen wählen – Google OAuth – anstelle von E-Mail und Passwort. Das System verknüpfte alle E-Mails vorab mit Domains, unabhängig davon, ob das Konto bereits existierte, wahrscheinlich weil man wollte, dass Nutzer sich per OAuth mit Google anmelden und sofort Zugang zu all ihren Domains haben, wie die Forscher gegenüber The Register erklärten. Aber der E-Mail-und-Passwort-Pfad wurde nie geschlossen, und auf diesem Pfad bewies nichts die Kontrolle über das Postfach.

Es gab noch einen weiteren Brandbeschleuniger. Während der Migration war der Schutz, der dies hätte verhindern sollen, abgeschaltet: Im Rahmen des Übergangs zu Squarespace wurde die Multi-Faktor-Authentifizierung auf den Konten deaktiviert. Selbst ein Domain-Inhaber, der bei Google Domains sorgfältig MFA aktiviert hatte, kam bei Squarespace an, ohne diese MFA. Kein Passwort zu knacken, kein zweiter Faktor zu umgehen, keine E-Mail abzufangen – für ein migriertes, noch nicht beanspruchtes Konto war der Besitz einer erratbaren E-Mail-Adresse die gesamte Authentifizierungsgeschichte.

Reaktion und Schadensbegrenzung

Die Krypto-Sicherheits-Community handelte schneller als der Registrar. Forscher – darunter Samczsun, Taylor Monahan und Andrew Mohawk – veröffentlichten den Mechanismus, und Blockaid verteilte Listen noch angreifbarer Frontends, damit Projekte prüfen konnten, ob sie exponiert waren. Betroffene Projekte beeilten sich, ihre Konten zurückzugewinnen, DNS-Einträge zurückzusetzen und Nutzer zu warnen, Token-Genehmigungen zu widerrufen, die den bösartigen Seiten erteilt wurden.

Der unmittelbare Abhilferat war für alle noch auf einem migrierten Konto gleich: Anmelden und das Konto beanspruchen, bevor ein Angreifer es tut, ein starkes, einzigartiges Passwort setzen und – vor allem – die Multi-Faktor-Authentifizierung wieder aktivieren, die die Migration stillschweigend entfernt hatte. Squarespace seinerseits arbeitete daran, die migrierten Konten und den Kontoerstellungsablauf abzusichern. Die grundlegende Lehre überdauerte den Patch: Eine Sicherheitskontrolle, die ein Anbieter während einer Migration deaktiviert, ist für die Dauer dieser Migration eine Kontrolle, die nicht existiert.

Was dies über Registrar-Sicherheit und MFA lehrt

Die Squarespace-Hijacks sind nicht wirklich eine Geschichte über die Fehlkonfiguration eines einzelnen Unternehmens. Sie sind eine Geschichte darüber, wo Domain-Kontrolle tatsächlich angesiedelt ist, und wie fragil die Schicht oberhalb der Blockchain bleibt.

Einige Lektionen verallgemeinern sich weit über Juli 2024 hinaus:

1. Das Registrar-Konto ist die eigentliche Vertrauenswurzel – nicht der Smart Contract. Keines der betroffenen Protokolle hatte einen Contract-Fehler. Ihr On-Chain-Code war in Ordnung. Die Angreifer haben die Domain übernommen, und die Domain ist das, was Nutzer eingeben, dem sie vertrauen und mit dem sie ihre Wallets verbinden. Ein Projekt kann on-chain makellos sein und seine Nutzer trotzdem einem Angreifer ausliefern, wenn seine DNS-Steuerungsebene schwach ist.

2. MFA ist nur dann ein Schutz, wenn sie Migrationen überlebt. Das schmerzliche Detail hier ist, dass MFA nicht unter einem Angriff versagt hat – sie wurde vor dem Angriff als Migrationserleichterung entfernt. Behandeln Sie den MFA-Status als etwas, das nach jedem Kontoumzug, jeder Übertragung oder jedem Anbieterwechsel erneut überprüft werden muss, nicht als etwas, das man einmal einrichtet und vergisst.

3. „Nahtlos" ist ein Sicherheits-Trade-off. Jeder Schritt, den eine Migration zugunsten der Benutzerfreundlichkeit überspringt, ist ein Schritt, bei dem die Identität unbewiesen bleibt. Vorab erstellte Konten, automatisch verknüpfte E-Mails und Anmeldungen ohne Verifizierung sind alles Hürden, die der Nutzer nicht gespürt hat – und Hürden sind sehr oft das, was Angreifer draußen hält.

4. Erratbare Identifikatoren sind Zugangsdaten in Verkleidung. Das „Geheimnis", das diese Domains entsperrte, war eine E-Mail-Adresse, die nie geheim war. Jedes System, bei dem die Kenntnis eines öffentlichen Identifikators Kontrolle verleiht, ist eine Identitätsfälschung von einem Kompromiss entfernt.

5. Der Schadensradius eines Registrars entspricht seinem gesamten Kundenstamm. Individuelle Domain-Sicherheit spielt keine Rolle, wenn das Standardverhalten des Registrars schwach ist, weil der Standard für alle gleichzeitig gilt. Wo Ihre Domain beheimatet ist, und wie dieser Verwahrer mit Authentifizierung umgeht, ist eine Sicherheitsentscheidung, die so bedeutsam ist wie jede, die Sie on-chain treffen.

Die Namefi-Perspektive

Die Hijacks von 2024 ereigneten sich in der Lücke zwischen „wem gehört diese Domain wirklich" und „wer kann sich in das Konto einloggen, das sie kontrolliert". Im traditionellen Modell sind diese beiden Dinge nur lose verknüpft: Eigentümerschaft ist ein Eintrag in der Datenbank eines Registrars, und der Zugang dazu wird von der Authentifizierung abgesichert, die dieser Registrar gerade zufällig durchsetzt – auch mitten in einer 10-Millionen-Domain-Migration, bei der das Tor kurzzeitig weit offen stand.

Namefi ist darauf ausgelegt, diese Lücke zu schließen. Indem Domain-Eigentümerschaft als tokenisiertes, on-chain-Asset dargestellt wird, das mit DNS kompatibel bleibt, wird Kontrolle zu etwas, das man kryptografisch verifizieren kann, anstatt etwas, das auf einer erratbaren E-Mail-Adresse und den Standard-Anmeldeeinstellungen eines Anbieters beruht. Eigentümerschaft liegt in einer Wallet, die Sie kontrollieren, Übertragungen sind nachprüfbar, und die Frage „Wer darf die Einträge dieser Domain ändern" hat eine manipulationssichere Antwort statt einer Kundenservice-Antwort.

Das hätte die Migration von Squarespace nicht fehlerfrei gemacht. Aber es ändert den Fehlermodus. Ein Angreifer, der ein Konto mit einer bekannten E-Mail-Adresse registriert, besitzt dadurch keine tokenisierte Domain – Eigentümerschaft ist keine Zeile, die ein halb initialisiertes Konto still und leise beanspruchen kann. Die Steuerungsebene für einen Namen sollte genauso schwer zu fälschen sein wie die Vermögenswerte, die er schützt. Im Juli 2024 war das für hunderte von Krypto-Projekten nicht der Fall. Diese Lücke ist genau die, die es wert ist, technisch zu schließen.

Quellen und weiterführende Lektüre

• 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