Token-Diebstahl durch gefälschtes PyPI-Paket

Vor dem Hintergrund des anhaltenden Kryptohypes und der zunehmenden Abhängigkeit des Finanzsektors von Open-Source-Komponenten warnt JFrog vor einem Supply-Chain-Angriff mit weitreichenden Folgen.

Die Sicherheitsforscher haben auf der Plattform PyPI ein manipuliertes Python-Paket entdeckt, das gezielt Nutzer der Börse MEXC ins Visier nimmt. Unter dem Namen „ccxt-mexc-futures“ tarnt sich das Paket als Erweiterung der populären Trading-Bibliothek CCXT, die in der Krypto-Entwicklung weit verbreitet ist. In Wahrheit handelt es sich jedoch um Schadsoftware, die Handelsanfragen auf eine betrügerische Infrastruktur umleitet und dabei gezielt API-Schlüssel und Zugangsdaten abgreift.

Besonders perfide: Das Paket nutzt die Struktur und Funktionsweise der legitimen CCXT-Bibliothek, die zahlreiche Krypto-Börsen unterstützt – darunter auch MEXC –, um sich nahtlos in bestehende Handelsprozesse einzuklinken. Der Vorfall zeigt exemplarisch, wie professionell Angreifer inzwischen vorgehen, um das Vertrauen in etablierte Open-Source-Komponenten zu missbrauchen – und wie dringend Entwickler, Plattformbetreiber und Investoren Sicherheitsaspekte in ihren Entwicklungs- und Betriebsprozessen mitdenken müssen.

Technischer Hintergrund

API-Übernahme durch gezielte Überschreibungen

Die Angreifer manipulierten gezielt drei zentrale Funktionen der CCXT-Schnittstelle – describe, sign und prepare_request_headers. Durch diese Eingriffe wurden handelsübliche API-Aufrufe der Bibliothek auf täuschend echt gestaltete, aber vom Angreifer kontrollierte Server umgeleitet. Besonders betroffen waren die für Order-Erstellung und -Stornierung zuständigen Einträge contract_private_post_order_submit und contract_private_post_order_cancel. Darüber hinaus wurde mit spot4_private_post_order_place ein zusätzlicher, manipulierter Endpunkt eingeführt, der auf den ersten Blick wie ein legitimer Teil der CCXT-Bibliothek wirkte, in Wahrheit jedoch gezielt auf eine bösartige Infrastruktur verwies.

Verschleierungstechniken und Schadcode-Ausführung

Um die schädlichen Funktionen zu verschleiern, kamen in den unterschiedlichen Versionen des Pakets verschiedene Techniken zum Einsatz: In Version 0.1.4 wurde Schadcode base64-codiert und über die Python-Funktion exec()ausgeführt. Version 0.1.8 ging noch einen Schritt weiter und nutzte verschachtelte eval()-Aufrufe zur Entschlüsselung von hexadezimal kodierten Strings – ein klares Indiz für den Versuch, statische Sicherheitsanalysen zu umgehen.

Nach der Entschlüsselung kontaktierte der Schadcode eine externe Konfigurationsquelle unter der Domain v3.mexc.workers.dev, die sich als legitimer MEXC-Dienst tarnte. Darüber erhielt das Paket eine JSON-Datei mit manipulierten API-Einstellungen.

Umleitung, Täuschung und gezielter Datendiebstahl

Diese Konfiguration leitete alle Handelsanfragen auf eine alternative Domain (greentreeone.com), die vollständig unter der Kontrolle der Angreifer stand. Die Einstellungen täuschten gültige Handelsbedingungen vor, etwa indem ungültige Kontrakte als verfügbar deklariert oder Fehlermeldungen manipuliert wurden. Ein scheinbarer „OrderFilled“-Erfolg konnte so sogar dann zurückgegeben werden, wenn die Order in Wahrheit fehlschlug.

Im Zentrum des Angriffs stand jedoch die gezielte Ausleitung von API-Schlüsseln und geheimen Zugangsdaten: Die manipulierte sign-Funktion leitete Authentifizierungsdaten im Rahmen jeder Order-Anfrage direkt an die Angreifer weiter. War kein Token vorhanden, forderte die Software den Nutzer explizit zur Eingabe auf – ein weiterer Trick, um an kritische Informationen zu gelangen.

Ausblick: Wachsamkeit bleibt entscheidend

Der Fall ccxt-mexc-futures ist ein alarmierendes Beispiel dafür, wie raffiniert heutige Angriffe auf Software-Lieferketten bereits sind. Die Kombination aus vertrauenswürdiger Open-Source-Bibliothek, manipulierten Schnittstellen und gezielter Datenexfiltration über täuschend echte Infrastruktur zeigt, wie wichtig eine ganzheitliche Sicherheitsstrategie im Entwicklungsprozess geworden ist.

Entwicklern wird dringend geraten, betroffene Abhängigkeiten zu entfernen, eventuell kompromittierte API-Schlüssel umgehend zu deaktivieren und Sicherheitsprüfungen ihrer Projektumgebungen durchzuführen.

Die vollständige Untersuchung des JFrog Security Research Teams finden Sie hier.

(ds/JFrog)