How Shady Code Commits Compromise the Security of the Open-Source Ecosystem
In this blog entry, we discuss how open-source code has been subjected to protest-driven code modifications by its maintainers or backers. We also provide an analysis of what these incidents could mean for the IT industry and the open source community.
Save to Folio
Traditionell drehten sich die Bedenken bezüglich der Sicherheit von quelloffenem Code um die Frage, ob dieser Sicherheitslücken, Hintertüren oder versteckten bösartigen Code enthalten könnte. In letzter Zeit konnten wir jedoch eine Verstärkung eines bestimmten Trends beobachten: Die Funktionalität von Open Source-Code wird verändert, um politischen Protest auszudrücken. Diese Instanzen von so genannter „Protestware“ sind nicht neu, doch hat die jüngste geopolitische Situation die Open Source Community gespalten: Einige unterstützen diese Entwicklung, während andere wollen, dass das Open Source-Ökosystem unpolitisch bleibt, weil Protestware die Vertrauenswürdigkeit dieser Software als Ganzes gefährden könnte.
Diese Art von Aktivitäten geriet in den Blickpunkt, nachdem der Betreuer einer wichtigen Node.js-Lieferkettenkomponente, node-ipc, ihren Code so verändert hatte, dass er zerstörerisches Verhalten zeigte. Der Vorfall ereignete sich im März und erwies sich keineswegs als Einzelfall. Es gab weitere Aktionen in der Open Source-Community, die mit den anhaltenden Konflikten in der Ukraine, Israel und Palästina sowie anderen geopolitischen Themen zusammenhängen. Die Nutzer von quelloffener Software müssen daher dafür sorgen, dass die gesamte Lieferkette ihres quelloffenen Software-Stacks sicher ist und nicht durch Codeänderungen beeinflusst wurde, die nicht mit der Hauptfunktionalität der Codekomponenten zusammenhängen. Dies ist in der Tat eine neue Herausforderung, die IT-Administratoren bei der Sicherung ihrer Systeme bewältigen müssen. Jetzt kommt hinzu, dass sie auch darüber nachdenken müssen, wie die Politik ihre digitale Lieferkette beeinträchtigen könnte.
node-ipc-Versionen mit gelöschten Dateien und Herz-Emojis
Der bemerkenswerteste der jüngsten Open Source-Code-Fälle war die node-ipc-Aktion. Node-ipc ermöglicht die Remote Interprozesskommunikation (IPC) in Node.js und ist eine Schlüsselkomponente des Node Packet Managers (npm), dem Standard-Paketmanager für Node.js. Daher wird die Komponente auf vielen Servern weltweit eingesetzt, auch wenn Systemadministratoren sie nicht ausdrücklich installiert haben.
Im März 2022 wurde der Code für node-ipc wurde so verändert, dass zerstörerische Befehle ausgeführt werden, wenn der Code erkennt, dass er in bestimmten geografischen Regionen abläuft. Er überschrieb er jede Datei, auf die er zugreifen konnte, mit einem Herz-Emoji, wenn er die Geolokalisierungsprüfung bestand. Zwei bestimmte Versionen, 10.1.1 und 10.1.2, enthielten diese Codeänderung. Diese geänderten Versionen waren etwa fünf Stunden lang online, bis sie durch Version 10.1.3 ersetzt wurden.
Eine weitere modifizierte Version wurde dann innerhalb von vier Stunden hochgeladen mit dem peacenotwar-Modul, das eine Textdatei auf dem Desktop eines Benutzers ablegt. Die Funktionalität wurde in der README-Datei der neuen Version deklariert, was bei den früheren Versionen aus offensichtlichen Gründen nicht der Fall war. Diese Version wurde von mehr als 300 Paketen verwendet und in den ersten drei Märzwochen mehr als eine Million Mal heruntergeladen.
Am 15. März wurde die stabile Version von node-ipc auf 9.2.2 aktualisiert, und hier wurden die Auswirkungen deutlicher, da viele Projekte auf die stabile Version bauten. Die Version führte ebenfalls das peacenotwar-Modul aus, wenn node-ipc als Abhängigkeit aufgerufen wurde, so dass dieses zusätzliche Verhalten viel deutlicher sichtbar wurde. Zu den am stärksten betroffenen Anwendungen gehörten die Unity-3D-Spiele-Engine und das JavaScript-Framework Vue.js, das auf vielen Websites eingesetzt wird. Bei Websites, die das Framework verwenden, bestand entweder die Gefahr, dass ihre Inhalte gelöscht wurden, oder, was noch schlimmer ist, dass sie bereits gelöscht waren, und zwar auf Basis der Geostandorts der IP-Adresse des Nutzers. Dies wiederum stieß in der Open Source Community auf erhebliche Kritik und führte dazu, dass mindestens eine Maintenance Fork von node-ipc unter einem anderen Maintainer erstellt wurde.
Die wechselseitige Abhängigkeit und die Sicherheit der Lieferkette bei Open Source-Projekten wird immer mehr zum Problem. In einem separaten, nicht politischen Fall bemerkte beispielsweise ein Sicherheitsberater namens Lance R. Vick, dass die foreach-Komponente von npm von einem einzigen Maintainer kontrolliert wurde, der nicht in der Lage war, seine persönliche E-Mail-Domain zu erneuern. Der Berater behauptete, dass es ihm gelungen war, die Domain zu kaufen und dass er das foreach-Paket kontrolliere, obwohl er in späteren Interviews erklärte, sich nie tatsächlich in das Konto eingeloggt zu haben. Dies verdeutlicht die mangelnde Sicherheit von Open Source-Code-Maintainer-Konten, ein Problem, auf das Vick bereits 2020 hingewiesen hatte. In einem anderen Fall verkaufte ein Betreuer einer Browsererweiterung sein Projekt an einen Dritten, der das Projekt offenbar zu einem böswilligen Zweck kaufte.
Es5-ext ist ein anderes Node.js Package, in welches längere Antikriegsbotschaften eingefügt wurden. Einzelheiten dazu und auch zu weiteren npm-Vorfällen beinhaltet der Originalbeitrag.
Die Malware-behaftete The Great Suspender Browser Extension
Angriffe auf Software-Lieferketten nehmen zu. Die Motivation dahinter ist nicht immer politisch: Der Code wird auch aus rein finanziellem Interesse manipuliert, wie im Fall des quelloffenen The Great Suspender, einer Erweiterung für Google Chrome.
Dies war eine leichtgewichtige Anwendung, die dazu beitrug, Systemressourcen freizugeben, indem sie ungenutzte Tabs in Chrome automatisch aussetzte oder schloss. Diese kostenlose App ist mehr als zwei Millionen Mal installiert worden, bevor Google sie aus dem Chrome Web Store entfernte und in den Browsern der Nutzer automatisch deaktivierte oder abschaltete. Im Juni verkaufte der ursprüngliche Maintainer der App den Sourcecode an Unbekannte, die zwei Versionen veröffentlichten: v7.1.8 und v7.1.9.
V7.1.8, die im Chrome Web Store, aber nicht auf GitHub veröffentlicht wurde, führte beliebigen Code von einem Remote-Server aus. Einem GitHub-Bericht zufolge nutzten Kriminelle diese neue Version offenbar für Malware-ähnliche Tracking- und Betrugsaktionen und spielten sie auf Rechner auf, ohne deren Nutzer zu benachrichtigen. Sie erhielt auch das Update zur Beseitigung der Malware nicht automatisch. Dies bedeutete, dass diese bösartige Version weiterlief, bis Google die App deaktivierte.
In der Zwischenzeit erstelle und veröffentlichte der böswillige Betreuer die Version 7.1.9 ohne den bösartigen Code, aber da sie von ihm selbst verwaltet wurde, hätte jederzeit kompromittierter Code eingefügt werden können.
Erhöhte Sicherheit für die Software-Lieferkette
Unabhängig davon, wie manche Entwickler zu politischen Themen stehen, ist es leider Tatsache, dass die Äußerung von Meinungen über Software, oder „Protestware“, unbeabsichtigte Konsequenzen hat. Unternehmen, die kompromittierte Open Source-Tools in ihren Produkten verwenden, könnten einen erheblichen Imageschaden erleiden, insbesondere wenn ihre Produkte ein bösartiges Verhalten zeigen, das ihnen nicht bekannt ist. Ein Beispiel für Software, die kompromittierten Open Source-Code verwendet hat, ist die russische Staatsbank Sberbank, die ihre Nutzer wegen „verstärkter Cyberangriffe“ davor gewarnt hat, ihre Software zu aktualisieren.
Böswillige Code-Commits im Open Source-Code wecken generell Zweifel an der Zuverlässigkeit von quelloffener Software. Dies könnte deren Einführung behindern oder sogar umkehren, da einige Unternehmen aufgrund dieser unerwünschten Vorfälle den Code überprüfen.
Mit der Einführung der Software-Stückliste (Software Bill of Materials, SBOM) wird versucht, die Sicherheit der Software-Lieferkette zu verbessern. Eine SBOM soll den Prozess der Verfolgung von Sicherheitspaketen, Softwareversionen und Software-Patches, die bei der Softwarebereitstellung verwendet werden, vereinheitlichen. Dieses Programm ermöglicht es den Sicherheitsteams der Unternehmen, schnell auf Verletzungen der Software-Lieferkette zu reagieren, die potenziellen Auswirkungen zu bewerten und die damit verbundenen Risiken zu mindern. Unternehmen können auch Software Composition Analysis-Tools (SCA) einsetzen, um einen besseren Überblick über Open Source-Komponenten zu erhalten. Dies ist ein Bereich, mit dem sich die Forscher von Trend Micro derzeit befassen.
Fazit
Selbst wenn hinter politischen Code-Änderungen gute Absichten stehen, sind die Folgen unerwünscht: Sie beruhen häufig auf der Prüfung der Zeitzonen oder Geolocation-API-Abfragen. Diese Prüfungen und Parameter sind nicht immer genau und können bei falscher Auslösung unerwartete Auswirkungen haben. Beispiele für eine falsche Auslösung sind Angriffe auf die Zeitsynchronisation, die Manipulation von Parametern, Fehler bei der Zeitzonen-Konfiguration und ungenaue Geolokalisierungsdienste.
Unternehmen können zur Sicherheit Lösungen einsetzen, die die Sichtbarkeit verbessern und den Open Source-Anwendungscode überwachen. Dazu gehört auch Trend Micro Cloud One – Open Source Security by Snyk, das automatisch Schwachstellen und Lizenzrisiken in Open Source-Abhängigkeiten von Anwendungen findet, priorisiert und meldet. Als Teil der Trend Micro Cloud One-Sicherheitsplattform lässt sich die Lösung mit Code-Repositories und CI/CD-Pipelines verbinden, um Projekte zu scannen. Sicherheitsteams erhalten so relevante Einblicke und verbessern das Risikomanagement durch mehr Transparenz, Nachverfolgung und frühzeitiges Erkennen von Open Source-Problemen.