Polymarket-Hack verschiebt 2,64 Millionen US-Dollar über gekapertes Script
Der Polymarket-Hack vom 29. Oktober nutzte bösartiges JavaScript, das von der Website des Prognosemarkts geladen wurde, um die Positionen einiger angemeldeter Händler zu verkaufen und Gelder an eine von einem Angreifer kontrollierte Wallet zu übertragen. Der Code ersetzte ein von DebugBear bereitgestelltes externes Script zur Leistungsüberwachung. Polymarket gibt an, rund 2,7 Millionen US-Dollar an 726 betroffene Wallets zurückzuerstatten. Von Forschern geprüfte Blockchain-Daten zeigen unterdessen, dass Kryptowährungen im Wert von etwa 2,64 Millionen US-Dollar in weniger als einer Stunde die Wallet der Angreifer erreichten.
Die legitime Datei gehörte zum real user monitoring (RUM) von DebugBear, das die Ladeleistung von Seiten für tatsächliche Besucher misst. DebugBear erklärte, dass seine DNS records, die Internetverkehr zum richtigen Online-Ziel leiten, über seinen Domain-Registrar kompromittiert worden seien. Die ersten Erkenntnisse des Unternehmens deuten darauf hin, dass die Website eines einzelnen Kunden angegriffen wurde. Es habe keine Hinweise darauf gefunden, dass seine eigenen Systeme kompromittiert worden seien, die Untersuchung dauere jedoch noch an.
Forscher von Hudson Rock luden die bösartige Datei am 29. Oktober von der Adresse herunter, die Polymarket für das DebugBear-Script verwendete. Sie stellten außerdem eine spätere Änderung am Website-Code von Polymarket fest, mit der die Integration entfernt wurde. Forscher von Ohey fanden um 18:13 UTC einen anderen Server vor, der auf die Webadressen von DebugBear antwortete, während die schädliche Datei weiterhin verfügbar war. Zuvor am selben Tag war das normale Script aus Google Cloud Storage bereitgestellt worden. DebugBear stellt jedem Kunden eine separate Kopie der Monitoring-Datei zur Verfügung, und bei der ersetzten Kopie handelte es sich um jene, die von Polymarket geladen wurde.
Hudson Rock untersuchte die Datei, ohne sie auszuführen, und stellte fest, dass sie Berechtigungen wiederverwendete, die bereits innerhalb einer geöffneten, authentifizierten Polymarket-Seite verfügbar waren. Sie las im Browser gespeicherte Kontoinformationen aus, darunter API keys (Application Programming Interface keys) für den Handel, also Zugangsdaten, die Software zur Kommunikation mit einem Online-Dienst verwendet. Diese API keys reichten nicht aus, um eine Order zu übermitteln, da Polymarket zusätzlich eine wallet signature verlangte, die kryptografische Freigabe einer Transaktion durch ein Konto.
Die Forscher fanden keinen Code, der die API keys, ein Passwort, eine seed phrase oder einen private key an den vom Script kontaktierten entfernten Server übermittelte. Stattdessen suchte der bösartige Code auf der Seite nach den Funktionen von Polymarket zur Orderaufgabe und nach dem signer, der für die Genehmigung von Kontotransaktionen zuständig war. Das bedeutet, dass der Polymarket-Hack versuchte, den bestehenden, vertrauenswürdigen Transaktionsprozess der Website zu verwenden, anstatt die sensibelsten Wallet-Zugangsdaten des Händlers zu extrahieren.
Das Script nutzte unterschiedliche Wege, je nachdem, wie sich der Händler angemeldet hatte. Bei Personen, die ihre eigenen Krypto-Wallets verwendeten, versuchte es, Handelspositionen direkt an die Wallet der Angreifer zu übertragen. Bei E-Mail-basierten Konten verkaufte es Positionen zu zunehmend schlechteren Preisen, bevor es die daraus entstandenen Gelder verschob. In beiden Fällen forderte der Code den signer des jeweiligen Kontos auf, seine Anweisungen zu genehmigen, und leitete diese an den relayer von Polymarket weiter, einen Dienst, der signierte Transaktionen zur Verarbeitung einreicht.
Hudson Rock wies darauf hin, dass eine an einen signer gesendete Anfrage nicht belegt, dass eine Transaktion abgeschlossen wurde, ohne dass der Händler eine Freigabeaufforderung sah. Ein Wallet-Anbieter könnte weiterhin eine Warnung anzeigen, die Anfrage ablehnen oder andere Sitzungsregeln durchsetzen. Die praktische Lehre für Händler lautet, dass unerwartete Transaktionsanfragen gefährlich sein können, selbst wenn sie innerhalb einer Website erscheinen, auf der der Nutzer bereits angemeldet ist.
Das Blockchain-Tracing von Ohey ergab, dass die im bösartigen Code hinterlegte Wallet ihre ersten Gelder um 17:10 UTC und ihre letzten um 18:02 UTC erhielt. In diesem Zeitraum sammelte sie 28,6 Millionen POL-Token und Handelspositionen aus 33 Wallets. DefiPrime berechnete, dass allein die POL um 18:19 UTC etwa 2,64 Millionen US-Dollar wert waren, ausgehend von dem DefiLlama-Preis von 0,0922 US-Dollar. Diese Bewertung umfasste die übertragenen Positionen nicht. Transaktionsdaten zeigen, dass anschließend zwischen 18:28 und 18:38 UTC alle 28,6 Millionen POL an drei weitere Adressen gesendet wurden.
Polymarket veröffentlichte um 17:38 UTC seine erste Statusmeldung zu nicht autorisierten Wallet-Aktivitäten. Um 18:05 UTC versetzte das Unternehmen die Börse in den cancel-only mode, in dem bestehende Orders storniert werden konnten, während der normale Handel gestoppt war, und pausierte Aktionen des relayer. Das Unternehmen erklärte, es habe das betroffene Script innerhalb einer Stunde entfernt, seine Caches geleert, jede aktive Anmeldesitzung beendet und den Handel ausgesetzt, während es überprüfte, dass die Website frei von Schadcode war. Es hat den Vorfall an die Strafverfolgungsbehörden weitergeleitet.
Bis zum 30. Oktober hatten nach Angaben von Polymarket 689 der 726 betroffenen Wallets vollständige Rückerstattungen erhalten. Zahlungen an die verbleibenden 37 wurden bearbeitet, während ihre Fälle geprüft wurden. Das Unternehmen zahlt außerdem separat 1,19 Millionen US-Dollar an etwa 5.500 Wallets, die während der Handelsunterbrechung Geld verloren hatten oder deren Positionen übernommen worden waren. Damit beläuft sich die insgesamt geplante Rückzahlung an Händler auf 3,9 Millionen US-Dollar. Nutzer müssen keine Ansprüche einreichen, die Statusseite stellt jedoch ein Formular für alle bereit, die der Ansicht sind, dass eine Zahlung fehlt oder fehlerhaft ist.
DebugBear riet RUM-Kunden, seinen Einbettungscode von ihren Websites zu entfernen. Als The Hacker News am 1. November eine Überprüfung vornahm, verfügte cdn.debugbear.com nicht mehr über einen DNS record. Polymarket erklärte, es werde externe Scripts mit zusätzlichen Kontrollen wieder einsetzen, darunter festgeschriebene Versionen, Sandboxing und eine stärkere Content Security Policy (CSP), die einschränkt, welche externen Ressourcen ein Browser laden oder ausführen darf.
Hudson Rock empfiehlt, unnötigen externen Code von Seiten fernzuhalten, auf denen Nutzer handeln oder Transaktionen genehmigen. Wenn eine Datei auf eine bekannte Version festgelegt werden kann, können Websites Subresource Integrity (SRI) verwenden, eine Browser-Prüfung, die eine Datei ablehnt, wenn ihr Inhalt nicht mehr mit einem erwarteten Wert übereinstimmt. Lediglich eine vertrauenswürdige Adresse für content delivery über eine Sicherheitsrichtlinie zuzulassen, überprüft nicht jede von dieser Adresse bereitgestellte Datei. Websitebetreiber sollten außerdem untersuchen, was Code, der auf einer authentifizierten Seite ausgeführt wird, einem signer zur Genehmigung vorlegen kann.
Dieser Vorfall verdeutlicht außerdem, wie wichtig es ist zu verstehen, wo das DNS-Vertrauen innerhalb der Supply Chain einer Website liegt. AEU DNS bietet privates, sicheres DNS für alle, obwohl die hier gemeldete Kompromittierung vom Registrar verwaltete records betraf, die von einem externen Script-Anbieter verwendet wurden. Für Websitebetreiber besteht das zentrale Problem darin, dass von einer anderen Domain geladener Code Zugriff auf eine sensible Seite mit aktiver Anmeldung erlangen kann. Daher sind das Entfernen von Scripts, strenge Browser-Kontrollen und die sorgfältige Genehmigung von Transaktionen wichtige Maßnahmen zur Begrenzung des Risikos.