Der Krieg in der Ukraine findet längst nicht mehr „nur“ auf dem Schlachtfeld vor Ort statt. Kürzlich hatte ich über diesen digitalen Krieg berichtet, er wird parallel zum physischen Krieg geführt. Rund um den Globus beteiligen sich verschiedene Menschen, daher reichen seine Auswirkungen auch weit über die Landesgrenzen von Russland/Ukraine aus. Nun ist der Krieg im Node.js-Ökosystem angekommen. Dort sind allerdings Unbeteiligte ebenfalls betroffen.
Das NPM-Paket node-ipc
JavaScript ist eine Skriptsprache, die ursprünglich für Internetbrowser entwickelt wurde. Durch die Laufzeitumgebung Node.js kann man JS auch außerhalb des Browsers verwenden. Der Paketmanager NPM soll es ermöglichen, Programmcode in Form von Modulen anderen zur Verfügung zu stellen. Davon hat der Entwickler RIAEvangelist Gebrauch gemacht und bietet mit seinem Paket node-ipc eine Bibliothek zur Interprozesskommunikation: Verschiedene Prozesse können dadurch Daten miteinander austauschen. Ein einfaches Beispiel für solchen Datenaustausch ist die Pipe in Linux:
ps -ax | grep apache
Der Befehl ps liefert eine Liste aller laufenden Prozesse, leitet sie per Pipe (|) an den zweiten Befehl grep, wo dann wiederum diese Daten eingelesen und gefiltert werden. Mit node-ipc kann man solche Transfers zwischen verschiedenen Prozessen in seine Anwendung integrieren. Auch sind komplexere Szenarien möglich, etwa die Übertragung über das Netzwerk zu einem anderen System.
„peacenotwar“-Paket: Friedlicher Protest über Software-Abhängigkeiten?
Am 07. März hat der Entwickler (auf GitHub unter dem Name RIAEvangelist aktiv) sein Paket aktualisiert und dort Malware eingebaut. Entgegen des Artikels war dies laut meinen Recherchen bereits am 07. und nicht erst am 08. März der Fall. Nur wenig später entdeckte der Nutzer MindSpike das Paket peacenotwar, welches eine Meldung ausgibt, die sich gegen den Krieg in der Ukraine ausspricht. Das peacenotwar NPM Paket soll friedlich gegen den Krieg demonstrieren und aufzeigen, warum es wichtig ist, seine Node-Module zu kontrollieren. Beides soll ausdrücklich rein friedlich geschehen, ohne Schaden anzurichten. Es legt eine Textdatei namens WITH-LOVE-FROM-AMERICA.txt auf dem Desktop an. Für Windows-Nutzer die OneDrive verwenden, wird eine weitere Kopie in ihre Microsoft-Cloud gespeichert. Die Datei kritisiert in verschiedenen Sprachen, welchen Schaden Kriege verursachen und dass sie daher niemals eine Lösung darstellen können.
RIAEvangelist hat sein peacenotwar-Modul als Abhängigkeit in seine anderen Projekte eingebaut. Der Entwickler begründet seinen Schritt damit, dass diese Änderungen gut dokumentiert sind und in einer eigenen Hauptversion durchgeführt wurden – wer die Abhängigkeit nicht möchte, könne das Update auf betroffene Versionen entsprechend unterlassen. Außerdem sah er sich in der Verantwortung, etwas gegen den Krieg zu unternehmen, damit daraus kein dritter Weltkrieg entsteht.
Wer ein Paket von ihm nutzt und dies, aktualisiert ohne zumindest die Changelogs zu lesen oder gar den Code zu prüfen, dessen eigenes Programm erstellt dadurch automatisch diese Textdatei bei den Nutzern. Da das NPM-Ökosystem ist allerdings bekannt ist, oft viele Abhängigkeiten über mehrere Ecken aufzuweisen. Daher sind zahlreiche Projekte betroffen, die das node-ipc Modul gar nicht kennen – aber über verschiedene Abhängigkeiten nutzen. Ein bekanntes Beispiel ist das JavaScript-Framework Vue.js. Dort hat man offensichtlich Updates eingespielt, ohne die Änderungen in den Abhängigkeiten zu prüfen.
Die Geschichte der Malware in node-ipc
Doch das ist noch nicht alles. Neben dem peacenotwar-Modul hat RIAEvangelist in einem inzwischen gelöschten Commit eine weitere JavaScript-Datei direkt in node-ipc eingebaut. Sie ist obfuscated und minified – also bewusst unleserlich gemacht, damit es schwieriger ist, seine Funktion zu verstehen. Die zumindest Formatierte Datei findet man in diesem Eintrag einer Schwachstellen-Datenbank. Zeichenketten wurden mit Base64 maskiert:
> Buffer.from("Y291bnRyeV9uYW1l", "base64").toString()
'country_name'
> Buffer.from("cnVzc2lh", "base64").toString()
'russia'
> Buffer.from("YmVsYXJ1cw==", "base64").toString()
'belarus'
Der Code prüft anhand von Zufallszahlen, ob er Ausgeführt wird. Ist das der Fall, sendet er eine HTTP-Anfrage an eine Schnittstelle von ipgeolocation.io. Sie liefert Informationen zur IP-Adresse des abrufenden Internetanschlusses, unter anderem das zugeordnete Land. Wird erkannt, dass sich die IP un Russland oder Belarus befindet, überschreibt der Code den Inhalt aller Dateien im aktuellen und übergeordneten Verzeichnissen mit einem Herz-Smiley.
Auf NPM sind nicht mehr alle Versionen verfügbar und auch auf GitHub hat der Eigentümer bereits versucht, Beweise zu zensieren oder löschen. Hier leugnet er etwa, dass sein Code überhaupt Schaden anrichten kann. Nachdem andere Community-Mitglieder seine Behauptungen mit Beweisen widerlegen, gesteht er seine Manipulation – aber nur Teilweise per Salamitaktik. Beispielsweise gesteht er im späteren Verlauf der Diskussion ein, dass sein Code die Daten löscht, wenn die IP aus Russland oder der Ukraine stammt. Behauptet aber, die Erkennung würde nicht funktionieren, weil der dafür notwendige API-Schlüssel ungültig ist. Laut Aussagen anderer Mitglieder war der Schlüssel zum Zeitpunkt ihrer Tests jedoch gültig – er wurde anscheinend erst im Nachhinein zurückgezogen.
Soweit es sich rekonstruieren lässt, ist Version 10.1.1 von node-ipc die erste Version, welche die destruktive Malware (Löschen von Dateien) enthält. Kurz darauf folgte 10.1.2, worin sie ebenfalls enthalten ist. In Version 10.1.3 wurde diese Malware wieder entfernt und eine neue Hauptversion 11.0.0 veröffentlicht.
Auswirkungen dieses sogenannten „Lieferketten-Angriffs“
Diese Malware ist in mehrerer Hinsicht problematisch: Die verwendete Geo-IP Zuordnung ist nicht 100% exakt. Es wird möglicherweise eine IP Russland zugeordnet, die von wo anders stammt. Auch VPNs und Proxys verfälschen dies. Deren Nutzung wird in letzter Zeit wohl zugenommen haben, da aufgrund von Zensur auf beiden Seiten nicht mehr alle Medien zugreifbar sind. Wer Beispielsweise Propagandavorwürfe in Russischen Medien aus erster Hand prüfen möchte, kommt aufgrund von Verboten etwa nicht mehr ohne VPN/Proxy auf die Seite von RT.
Abgesehen davon: Die Malware unterscheidet nicht, ob sich jemand am Krieg beteiligt oder sich gar dagegen ausspricht. Sie trifft am Ende z.B. zivile Entwickler, die sich damit ihren Lebensunterhalt finanzieren – und durch die Löschung ihrer Daten im schlimmsten Falle in ihrer Existenz gefährdet sind. Gemäß Gießkannen-Prinzip wird jeder aus Russland bestraft. In wie weit das den Krieg beendet statt weiter zu eskalieren, ist doch sehr fraglich.
Unabhängig von der Motivation handelt es sich bei dem Vorfall um einen sogenannten Lieferketten-Angriff: Da node-ipc in hunderten anderen Paketen verwendet wird, waren und sind viele wohl über mehrere Ecken davon betroffen – somit eine Art Lieferkette. Das Vue.js Framework hatte ich zuvor bereits als Beispiel erwähnt: Alleine deren Paket @vue/cli-ui erreicht über 131.000 Downloads pro Woche. Selbst wenn darin nur für wenige Tage eine Schadsoftware enthalten ist, kann man sich das Ausmaß vorstellen. Und das wie gesagt nur in einem dieser Fälle. Es gibt unterschiedliche Gründe für solche Angriffe. Andere sind nicht politischer Natur, sondern finanziell motiviert. Unabhängig davon haben sie massive Auswirkungen gemeinsam, da sich aufgrund der hohen Abhängigkeit der Angriff auf ein einziges Projekt direkt oder indirekt auf dutzende weitere auswirkt.
Fazit
Das ist ein Problem, vor allem wenn großzügig und leichtsinnig mit Abhängigkeiten umgegangen wird. Wenngleich ich die Vorgehensweise von node-ipc, dies mit politisch motivierten destruktiven Angriffen nicht gut heiße – unabhängig davon, gegen wen sie sich richten. Ich kann daher an dieser Stelle nur ein weiteres mal davon abraten, dies nachzuahmen oder anderweitig Selbstjustiz im Krieg zu üben. Im vorherigen Beitrag zum Cyberwar in der Ukraine hatte ich das ausführlicher begründet, warum ich der Meinung bin, dass die (potenziellen) Gefahren dem möglichen Nutzen überwiegen.
Generell sollten wir vorsichtiger damit umgehen, fremden Code in eigene Projekte einzubinden. Und zwar ohne sämtliche Entwickler unter Generalverdacht anzuprangern. Die große Mehrheit davon hat keine bösen Absichten. Allerdings gibt es Szenarien, die realistisch ausgenutzt werden können. Kaspersky könnte selbst Malware über Updates ausliefern, gewollt oder ungewollt. Das ist aber nur die Spitze vom Eisberg, viele andere könnten das ebenfalls. Es ist nicht der erste Angriff dieser Art und es wird wohl kaum der letzte bleiben, unabhängig davon, wie sich die Lage in der Ukraine entwickelt. Produkte zu wechseln wird dafür nicht ausreichen, da die Probleme tiefer liegen.