#7 Vertrauens-Wallet-Vorfall: Gestohlener API-Schlüssel macht offiziellen Update-Kanal zur Hintertür

#7 Vertrauens-Wallet-Vorfall: Gestohlener API-Schlüssel macht offiziellen Update-Kanal zur Hintertür

Am 25. Dezember 2025 erlitt Trust Wallet einen kritischen Sicherheitsbruch in seiner Chrome-Erweiterung (v2.68), der zum Diebstahl von etwa 8,5 Millionen US-Dollar an Benutzergeldern führte.

Ursache war eine bösartige Backdoor, die in die Erweiterung eingeschleust wurde und aus einem Supply-Chain-Angriff stammte, der den Standard-Release-Prozess des Projekts kompromittierte. Die eingeschleuste Backdoor-Methode lädt Benutzer-Seed-Phrasen auf einen Angreifer-kontrollierten Server hoch und kompromittiert so alle Wallets, die mit dieser spezifischen Version der Erweiterung generiert oder importiert wurden. Der Angreifer hat anschließend Benutzergelder über mehrere Ketten abgezogen und sie an Nicht-KYC-Börsen geleitet.

Hintergrund

Die Chrome-Erweiterung von Trust Wallet ist als typisches Self-Custody-Wallet konzipiert, das es Benutzern ermöglicht, bestehende Wallets zu erstellen oder zu importieren. Das Herzstück jedes Kryptowährungs-Wallets ist die Seed-Phrase, auch bekannt als Mnemonic. Sie ist eine menschenlesbare Darstellung des privaten Schlüssels des Wallets. Diese Seed-Phrase kann deterministisch alle dem Wallet zugeordneten privaten Schlüssel ableiten und ist somit das kritischste Geheimnis, das ein Benutzer besitzt. Jeder, der Zugriff auf eine Seed-Phrase hat, erhält die vollständige Kontrolle über alle Wallet-Gelder.

Um sicherzustellen, dass Seed-Phrasen sicher und selbstverwahrt werden, speichert die Erweiterung von Trust Wallet diese lokal in verschlüsselter Form unter Verwendung kryptographischer Algorithmen. Sie können nur bei einer legitimen Benutzeranfrage mit ordnungsgemäßer Authentifizierung entschlüsselt werden. Dieser Prozess erfordert, dass sich Benutzer je nach konfigurierter Methode mit ihren biometrischen Daten oder ihrem Passwort authentifizieren. In einem ordnungsgemäß funktionierenden Self-Custody-Wallet werden entschlüsselte Seed-Phrasen ausschließlich innerhalb der lokalen Erweiterungsumgebung verwendet und niemals an externe Server übertragen.

Schwachstellenanalyse

Die Schwachstelle rührt vom Wallet-Unlock-Flow her, insbesondere über biometrische und Passwort-basierte Mittel. Bei einem Entsperrvorgang werden Seed-Phrasen als Analysedaten erfasst und an eine vom Angreifer kontrollierte Domain gesendet, die sich als legitimer Endpunkt ausgibt. Da der Exploit-Mechanismus für beide Mittel identisch ist, nehmen wir den biometrischen Weg als Beispiel zur Veranschaulichung der Schwachstelle.

Die folgende Analyse und die Screenshots basieren auf dem deobfuskierten Quellcode.

Abruf entschlüsselter Seed-Phrasen

Der bösartige Code wurde in die Unlock-Funktion in der Datei 8423.js injiziert, die das Entsperren des Wallets und die Entschlüsselung der Seed-Phrase nach der Benutzerauthentifizierung übernimmt. In der Unlock-Logik bettete der Angreifer einen scheinbar harmlosen Mechanismus zur Erfassung von Analysedaten ein. Wie im folgenden Code-Snippet hervorgehoben, wurde der Abruf von Seed-Phrasen unmittelbar nach dem normalen Authentifizierungsfluss platziert. Er durchläuft alle Wallets, extrahiert entschlüsselte Seed-Phrasen und speichert sie in einer irreführend benannten Variable errorMessage. Diese Daten werden dann in eine error-Eigenschaft von Analyse-Ereignisobjekten eingebettet.

Das gleiche bösartige Muster tritt im Passwort-Unlock-Flow (Zeilen 485-527) auf, wobei die biometrische Authentifizierung durch passwortbasierte Entschlüsselung ersetzt wird.

Übertragung sensibler Daten

Sobald die Seed-Phrasen gesammelt und als Analysedaten verpackt waren, wurden sie über eine PostHog-Analyseinfrastruktur geleitet. Die Infrastruktur wurde von dem Angreifer in v2.68 gezielt für die Datenübertragung eingeführt. Über diesen Weg werden Analysedaten, die Seed-Phrasen enthalten, an einen Analyse-Service-Wrapper gesendet, der die capture()-Methode von PostHog aufruft, um Ereignisobjekte zu generieren. Die Ereignisse werden in einer Warteschlange zusammengefasst und gestapelt, dann in JSON-Format serialisiert. Die JSON-Nutzlast wird komprimiert und per HTTP-POST-Anfrage an den Server des Angreifers übertragen.

Die Datei 4482.js zeigt eine PostHog-Konfiguration, die Analysedaten an api.metrics-trustwallet.com weiterleitet. Diese Domain wurde vom Angreifer speziell registriert, um einen legitimen Analyseendpunkt von Trust Wallet zu imitieren.

Beim Testen mit der Erweiterung v2.68 haben wir eine verdächtige Anfrage erfasst und analysiert, die während des Entsperrens des Wallets ausgelöst wurde. Die Anfrage sendet GZIP-komprimierte Daten an den vom Angreifer kontrollierten Endpunkt, die dekomprimiert werden können, um die Seed-Phrasen im Klartext zu extrahieren.

Angriffsanalyse

Der Angriffsprozess erstreckte sich über etwa einen Monat von der anfänglichen Vorbereitung bis zum endgültigen Exploit und entfaltete sich in drei Phasen:

  1. Kompromittierung des Chrome Web Store (CWS) API-Schlüssels

  2. Bereitstellung der Erweiterung mit bösartigem Code

  3. Diebstahl von Geldern aus kompromittierten Benutzer-Wallets

Phase 1: Kompromittierung des CWS API-Schlüssels

Die Geschichte begann mit einem weit verbreiteten Supply-Chain-Angriff im November, bekannt als „Shai-Hulud 2.0“ [2]. Diese Kampagne zielte auf Entwicklungsumgebungen über NPM (Node Package Manager) ab und kompromittierte zahlreiche legitime NPM-Pakete. Wenn Entwickler diese kompromittierten Pakete installierten, wurde bösartiger Code auf ihren Systemen ausgeführt, um sensible Anmeldeinformationen und Authentifizierungstoken zu stehlen.

Durch diesen Supply-Chain-Angriff erlangte der Angreifer den Chrome Web Store (CWS) API-Schlüssel von Trust Wallet. Dieser Schlüssel war besonders kritisch, da er das direkte Hochladen von Erweiterungsbuilds in den Chrome Web Store ermöglichte und damit die internen Genehmigungen und Überprüfungen von Trust Wallet im Rahmen des Standard-Release-Prozesses vollständig umging.

Phase 2: Veröffentlichung der Erweiterung mit bösartigem Code

Im Dezember 2025, mit dem gestohlenen CWS API-Schlüssel in der Hand, implementierte der Angreifer seine Angriffsinfrastruktur:

  1. Registrierung der bösartigen Domain metrics-trustwallet.com (und der Subdomain api.metrics-trustwallet.com) zur Hosterung des Datenerfassungs-Endpunkts.

  2. Einschleusen von Backdoor-Code in die Wallet-Unlock-Flows und Modifikation der PostHog-Analyse-Konfiguration, um Daten an seinen Server zu leiten.

  3. Hochladen der bösartigen Erweiterung direkt in den Chrome Web Store unter Verwendung des gestohlenen API-Schlüssels, wodurch der Standard-Release-Prozess umgangen wurde.

Die bösartige Version 2.68 bestand die automatische Überprüfung von Chrome und wurde im Store veröffentlicht, wobei sie als legitimes Update vom offiziellen Entwicklerkonto erschien.

Phase 3: Diebstahl von Geldern aus kompromittierten Benutzer-Wallets

Wenn Benutzer ihre Wallets mit dieser anfälligen Erweiterung entsperrten, wurden ihre Seed-Phrasen stillschweigend an api.metrics-trustwallet.com, den vom Angreifer kontrollierten Server, übertragen. Mit vollständigem Zugriff auf diese Seed-Phrasen erhielten die Angreifer die volle Kontrolle über die Wallets der Opfer.

Anstatt die Gelder sofort abzuziehen, was zu einer schnellen Erkennung geführt hätte, übten die Angreifer Geduld und ermöglichten die Erweiterung des Opferpools, während sie heimlich vorgingen.

Ab dem 25. Dezember begann der Angreifer mit der systematischen Entnahme von Geldern aus kompromittierten Wallets. Die Operation betraf ungefähr 2.520 verschiedene Wallet-Adressen, die sich über 10 verschiedene Blockchains erstreckten.

Zusammenfassung

Dieser Bruch dient als ernüchternde Erinnerung daran, dass Sicherheit den gesamten Lebenszyklus des Protokolls umfassen muss, einschließlich Entwicklung und Bereitstellung. Im Jahr 2025 entwickelten sich Supply-Chain-Angriffe zur zerstörerischsten Bedrohung für die Kryptowährungsinfrastruktur, wobei allein zwei Vorfälle (einschließlich des 1,5 Milliarden Dollar schweren Bybit-Hacks im Februar) erhebliche Verluste verursachten. Über Smart Contract Audits hinaus müssen Protokolle ihre Build-Pipelines sichern, Entwickler-Anmeldeinformationen schützen und kontinuierliche Überwachung aufrechterhalten, um Benutzervermögen zu schützen.

Referenzen

  1. Offizieller Post-Mortem
  2. Shai-Hulud 2.0

Über BlockSec

BlockSec ist ein Full-Stack-Anbieter für Blockchain-Sicherheit und Krypto-Compliance. Wir entwickeln Produkte und Dienstleistungen, die Kunden bei der Code-Prüfung (einschließlich Smart Contracts, Blockchains und Wallets), der Echtzeit-Abwehr von Angriffen, der Analyse von Vorfällen, der Rückverfolgung von illegalen Geldern und der Einhaltung von AML/CFT-Verpflichtungen über den gesamten Lebenszyklus von Protokollen und Plattformen hinweg unterstützen.

BlockSec hat mehrere Blockchain-Sicherheitsartikel auf renommierten Konferenzen veröffentlicht, mehrere Zero-Day-Angriffe auf DeFi-Anwendungen gemeldet, mehrere Hacks abgewehrt, um mehr als 20 Millionen Dollar zu retten, und Kryptowährungen im Wert von Milliarden gesichert.

Sign up for the latest updates