So gut wie jeder Entwickler nutzt Drittanbieter-Bibliotheken – bei Millionen von Entwicklern, die ihre Kreationen mit der ganzen Welt teilen, ist der Einsatz bereits vorhandener Module zur Aufgabenlösung eine durchaus gute Möglichkeit, die Zeit clever zu nutzen. Der Haken an der Sache ist jedoch, dass man bei der Verwendung von Drittanbietercode auch den Entwicklern des Codes vollstes – und vor allem blindes – Vertrauen schenken muss. BitPay, Entwickler des Kryptowallets Copay, bekam die Nachteile bei der Verwendung von Open-Source-Assets von Drittanbietern vor Kurzem an eigenem Leib zu spüren.
Im Grunde genommen handelt es sich bei Copay um ein plattformübergreifendes Bitcoin/BitcoinCash-Krypto-Wallet, über das Nutzer ein sogenanntes „Shared Wallet“ erstellen können. Copay wurde unter Verwendung von JavaScript und TypeScript entwickelt und basiert auf vielen Open-Source-Bibliotheken von Drittanbietern.
Dazu gehört auch das Node.js-Open-Source-Modul event-stream, dessen Repository auf dem Versionsverwaltungsservice GitHub von seinem ursprünglichen Autoren, Dominic Tarr, verwaltet wurde, der bereits vor einiger Zeit das Interesse an dem Projekt verloren hatte und seit einigen Jahren nur halbherzig am Schicksal des Repositorys beteiligt gewesen war. Als ein interessierter Nutzer, mit geringer bis gar keiner vorherigen Aktivität auf GitHub, auf Tarr zukam und ihn nach den Admin-Rechten zur Verwaltung und Betreuung des Repositorys fragte, stellte ihm dieser die notwendingen Zugriffsrechte zur Verfügung.
Der neue Entwickler machte sich daraufhin unverzüglich an die Arbeit: Zunächst begann die Bibliothek event stream ein Modul namens flatmap-stream aus dem GitHub-Repository desselben Autoren zu verwenden. Danach wurde eine Modifikation am Modul flatmap-stream vorgenommen – diesem fügte der Entwickler Schadcode hinzu. Drei Tage nach dem Update wurde eine weitere Version von flatmap-stream hochgeladen, die keinen schädlichen Code enthielt – vermutlich, um die schädlichen Aktivitäten zu vertuschen.
Auf diese Weise konnte die event-stream-Bibliothek, die nicht nur von BitPay, sondern auch von vielen anderen Unternehmen verbreitet eingesetzt wird, kompromittiert werden. Obwohl die Kompromittierung angeblich nur insgesamt drei Tage anhielt, reichte die Zeit für die Copay-Entwickler aus, die aktualisierte Version der Bibliothek unbemerkt in ihr Projekt zu integrieren. Die aktualisierte Krypto-Wallet-Software wurde dann in sämtlichen App-Stores veröffentlicht und von zahlreichen Nutzern heruntergeladen.
Scheinbar wollten die Copay-Entwickler nicht viel Zeit in die Überprüfung der vorgenommenen Änderungen der verwendeten Bibliotheken investieren, um die Sicherheit der Software zu gewährleisten. Mittlerweile ist die Aktualisierung von Bibliotheken, die in einem Projekt verwendet werden, dank zahlreicher Paketverwaltungsdienste wie npm leicht zu automatisieren. Mithilfe von npm kann ein Entwickler einen einzigen Befehl ausführen, um alle in seinem Projekt verwendeten Drittanbieter-Module zu aktualisieren.
Selbst wenn die Entwickler einen Blick auf die aktualisierten Bibliotheken geworfen hätten, wäre der Schadcode schwer zu finden gewesen. Bibliotheken, die in einem Projekt verwendet werden, können von anderen Bibliotheken abhängen (so wie im Fall von event-stream und flatmap-stream), und die Überprüfung aller Abhängigkeiten kann viel Zeit in Anspruch nehmen. In diesem speziellen Fall wurde der Prozess zusätzlich dadurch erschwert, dass das Flatmap-Stream-Modul verschlüsselt wurde.
Der Newssite CCN zufolge wurde die Bibliothek flatmap-stream modifiziert, um den Anwendungen, die auf den Bibliotheken event-stream und copay-bash basieren, private Schlüssel (im Wesentlichen Krypto-Wallet-Passwörter) zu entwenden. Aus diesem Grund liegt der Verdacht nahe, dass es sich hierbei um einen zielgerichteten Angriff auf BitPay, die Ersteller von Copay und die Autoren von Copay-Dash handelte.
ArsTechnica zufolge ermöglichte die schädliche Nutzlast dem Cyberkriminellen, unbefugten Zugriff auf die Wallets der Nutzer zu erhalten und Geld von dort zu überweisen. Der Fehler wurde von einem GitHub-Nutzer entdeckt und gemeldet. Bis es dazu kam, wurden jedoch zahlreiche Versionen des Copay-Wallets mit schädlichem Code verteilt. BitPay räumte die Kompromittierung schließlich ein und riet Kunden mit den Copay-Versionen 5.0.2 bis 5.1.0, zu einem Update auf die neueste Version 5.2.0. Derzeit sind weder Informationen über die Anzahl der betroffenen Benutzer noch über die Höhe des möglichen Geldverlusts bekannt.
Es handelt sich hierbei um einen klassischen Supply-Chain-Angriff, bei dem Kriminelle eine von den Entwicklern einer App verwendete Drittanbieter-Bibliothek gefährden. Das Problem ist hier auf die Verwendung von Open-Source-Software zurückzuführen, die von Unbekannten betreut und verwaltet wird. Es gibt daher keine Garantie, dass neuere Versionen der Software genauso funktionieren, wie es ältere Versionen getan haben. Den Entwicklern von Open-Source-Software kann dafür allerdings keine Schuld gegeben werden – sie liefern ihre Produkte in der vorliegenden Form ab und übernehmen keinerlei Garantien.
Das Problem in diesem Fall ist, dass Copay ebenfalls Open Source ist und häufig von Entwicklern anderer Krypto-Wallets verwendet wird. Dieser Fall könnte also lediglich die Spitze des Eisbergs sein.
Unternehmen, die mit der Bereitstellung von Software Geld verdienen (insbesondere Software, die große Geldbeträge handelt), sollten sicherstellen, dass ihre Software vor der Veröffentlichung einer Sicherheitsüberprüfung unterzogen wird, einschließlich einer sehr sorgfältigen Analyse jeder neuen Version aller Drittanbieter-Bibliotheken, die in den Konfigurationsdateien aufgelistet sind.
Um Sicherheitsprobleme einer Software zu vermeiden, sollte man im Bestfall ein Auge auf den Status des Repositorys werfen, die Bewertungen anderer Entwickler berücksichtigen, überprüfen, wie oft das Projekt aktualisiert wurde, wie lange dieses Update her ist und das Fehlerprotokoll durchstöbern. Auffälligkeiten oder Besonderheiten können unter gewissen Umständen eine intensivere Untersuchung oder sogar einen Modulwechsel erfordern.
Wenn bei einer solchen Bibliothek etwas schief geht, beschuldigen Kunden das Unternehmen, das die Software, die auf die Bibliothek zurückgreift, zur Verfügung gestellt hat; auch wenn das Unternehmen hier gar keine Schuld trägt, sondern vielmehr die Entwickler der Bibliothek. Natürlich möchten wir nicht von der Verwendung von Open-Source-Produkten abraten, sondern lediglich darauf hinweisen, dass Sie bei ihrem Gebrauch Ohren und Augen stets offen halten sollten.