Das ausgetauschte Skript stammte aus DebugBears Real-User-Monitoring-Produkt (RUM), das misst, wie schnell Webseiten bei echten Besuchern laden. Forscher von Hudson Rock luden die bösartige Datei am 29. Oktober von genau der Adresse herunter, über die Polymarket das DebugBear-Skript einband. Sie stellten außerdem eine Änderung am Seitencode von Polymarket fest, mit der das DebugBear-Skript entfernt wurde.

DebugBear erklärte auf X, die eigenen DNS-Einträge seien über den Domain-Registrar kompromittiert worden. Erste Erkenntnisse deuteten darauf hin, dass der Angriff auf die Website eines einzelnen Kunden zielte. Hinweise auf einen Einbruch in die eigenen Systeme gebe es nicht, die Prüfung laufe aber weiter.

Forscher von Ohey beobachteten um 18:13 UTC einen anderen Server, der für DebugBears Webadressen antwortete, während die bösartige Datei noch online war. Früher am selben Tag war das reguläre Skript aus Google Cloud Storage ausgeliefert worden. Jeder DebugBear-Kunde lädt eine eigene Kopie des Skripts – ausgetauscht wurde die Datei von Polymarket.

Wie der Code an das Geld kam

Hudson Rock analysierte die Datei, ohne sie auszuführen: Der Code nutzt den Zugriff, den ein angemeldeter Händler in einer geöffneten Polymarket-Seite ohnehin besitzt. Er liest Kontodaten aus, die Polymarket im Browser ablegt, darunter einen Satz Trading-API-Schlüssel. Diese Schlüssel allein können auf Polymarket keine Order platzieren, da Orders zusätzlich eine Wallet-Signatur erfordern. Hudson Rock fand keinen Codeteil, der Schlüssel, Passwort, Seed Phrase oder privaten Schlüssel an den Server übermittelt, an den der Code berichtet.

Stattdessen sucht der Code in der Seite nach der Komponente, die Orders aufgibt, sowie nach dem Signer, der Transaktionen des Kontos freigibt. Danach schlägt er einen von zwei Wegen ein:

  • Bei Konten, die sich mit einer eigenen Krypto-Wallet anmelden, verschiebt er die Positionen des Händlers direkt auf die Wallet der Angreifer.
  • Bei Konten mit E-Mail-Anmeldung verkauft er Positionen zu immer schlechteren Preisen und transferiert anschließend das Geld ab.

In beiden Fällen lässt der Code den Signer des Kontos seine Anfragen signieren und übergibt sie dem Relayer von Polymarket, der sie einreicht. Hudson Rock betonte, eine Signaturanfrage allein belege nicht, dass ein Händler ohne sichtbare Abfrage signiert habe – der Wallet-Anbieter könne weiterhin nachfragen, ablehnen oder eigene Regeln für die Sitzung anwenden.

Die im Code hinterlegte Wallet erhielt laut der Blockchain-Auswertung von Ohey ihren ersten Zufluss um 17:10 UTC und den letzten um 18:02 UTC. In dieser Zeit sammelte sie 28,6 Millionen POL-Token sowie Positionen aus 33 Wallets ein. Um 18:19 UTC entsprachen diese 28,6 Millionen POL nach Berechnung von DefiPrime rund 2,64 Millionen Dollar, bei einem DefiLlama-Kurs von 0,0922 Dollar; die Summe umfasst nur die POL, nicht die Positionen. Zwischen 18:28 und 18:38 UTC leitete die Wallet sämtliche 28,6 Millionen POL an drei weitere Adressen weiter, wie ihre Transaktionshistorie zeigt.

Reaktion und Erstattungen

Polymarket veröffentlichte um 17:38 UTC eine erste Statusmeldung über unautorisierte Aktivitäten in Nutzer-Wallets. Um 18:05 UTC teilte das Unternehmen mit, die Börse befinde sich im Cancel-only-Modus, Relayer-Aktionen seien pausiert. Das Skript habe man „innerhalb der Stunde" entfernt. Zudem seien alle Caches geleert, sämtliche aktiven Login-Sitzungen zurückgesetzt und der Handel pausiert worden, bis die Seite sauber war. Den Fall hat Polymarket an die Strafverfolgungsbehörden übergeben.

Bis zum 30. Oktober waren 689 der 726 betroffenen Wallets vollständig erstattet, die verbleibenden 37 wurden nach Prüfung ausgezahlt. Zusätzlich zahlt Polymarket 1,19 Millionen Dollar an rund 5.500 Wallets, die während der Handelspause Verluste erlitten oder Positionen verloren hatten. Insgesamt fließen damit 3,9 Millionen Dollar an Händler zurück. Ein Antrag ist dafür nicht nötig; die Statusseite verlinkt ein Formular für alle, die ihren Betrag für falsch halten oder eine Zahlung vermissen.

Konsequenzen für Websites und Händler

DebugBear hat Kunden seines RUM-Produkts aufgefordert, den Einbettungscode von ihren Websites zu entfernen. Die Adresse, über die die Schaddatei ausgeliefert wurde – cdn.debugbear[.]com –, hatte am 1. November keinen DNS-Eintrag mehr.

Polymarket erklärte, Skripte Dritter würden mit zusätzlichen Kontrollen wieder eingebunden, etwa einer strengeren Content Security Policy (CSP), fixierten Versionen und Sandboxing.

Hudson Rock empfiehlt Websites, die externe Skripte laden:

  • Nicht benötigten Fremdcode von Seiten fernhalten, auf denen Nutzer handeln oder signieren.
  • Wo eine Datei fixiert werden kann, Subresource Integrity (SRI) einsetzen, damit der Browser die Datei bei geändertem Inhalt zurückweist. Eine Sicherheitsrichtlinie, die lediglich ein vertrauenswürdiges CDN erlaubt, prüft die von diesem CDN ausgelieferten Dateien nicht.
  • Prüfen, welche Aktionen Code auf einer angemeldeten Seite vom Signer anfordern kann.

Händlern rät Hudson Rock, jede unerwartete Signaturanfrage abzulehnen.