Analyse des Synopsys Cybersecurity Research Center Repo-Jacking in der Softwarelieferkette

Anbieter zum Thema

sysob IT-Distribution GmbH & Co. KG

TXOne Networks

SYNOPSYS GmbH

Eskenzi PR Limited

Neben der Anfang August beobachteten Pull-Bedrohung für GitHub-Projekte greift auch das Repository-Hijacking, kurz Repo Jacking, vermehrt um sich. Für Open-Source-Repositories ist diese Form des Lieferketten-Angriffs eine ernste Bedrohung.

Repo Jacking meint eine von außen provozierte, erzwungene Übernahme eines Eigentümer- oder Projektbetreuerkontos, das ein Repository hostet. Dadurch hat ein Angreifer die Möglichkeit, bösartigen Code in Implementierungen eines oder mehrerer Projekte einzuschleusen, die es als Abhängigkeit nutzen.

Diese Art des Lieferkettenangriffs beruht in der Regel auf einer von zwei Methoden. Beide nutzen eine fehlende Validierung der Neuanmeldung auf Hosting-Plattformen wie etwa GitHub aus:

Namensänderung: Wenn ein Benutzer einer Hosting-Plattform seinen Benutzernamen ändert, kann ein Angreifer das Repository möglicherweise mit dem ursprünglichen Benutzernamen neu registrieren. Auf diesem Weg lässt sich das Repository neu erstellen. Dabei ist die ursprüngliche Repository-URL für Aktualisierungen durch Pakete des Opfers (die das Projekt als Abhängigkeit nutzen) wahrscheinlich auch weiterhin zugänglich.

Kontolöschung: Ähnlich wie bei einer Namensänderung kann ein Angreifer ein gelöschtes Konto erneut registrieren und das Repository neu erstellen. Diese Methode verursacht eher Fehler bei Projekten, die versuchen, das Repository über eine URL abzurufen, da der Link beschädigt würde. Dies lässt erfolgreich umgehen. Dazu wird der gelöschte Benutzername erneut registriert – und zwar zwischen dem Löschzeitpunkt und der Aktualisierung von Projekten, die versuchen, das Repository abzurufen.

In beiden Fällen erlangt ein Angreifer volle Kontrolle über das Repository. Dies erlaubt ihm erlaubt, eine Reihe privilegierter Aktionen auszuführen. Er kann zum Beispiel weitere böswillige Benutzer hinzufügen oder selbst Administrator- und Betreuerkonten anlegen. Damit lassen sich dann Push- und Pull-Anforderungen an ein Repository genehmigen.

Über diesen Umweg kann der Angreifer erzwingen, dass Schad-Code oder zumindest unerwünschter Code in neue Versionen eines Projekts gelangt. Umgekehrt ist es möglich, Versionen und funktionalen Code aus dem Repository zu löschen oder absichtlich fehlerhafte Commits zu veröffentlichen. So werden bereits vorhandene Funktionen sabotiert oder beschädigt.

Schädliche Auswirkungen auf die Sicherheit

Erfolgreiche Repository-Hijacking-Angriffe haben potenziell schwerwiegende Auswirkungen auf die Sicherheit der Nutzer eines Pakets oder Produkts – insbesondere dann, wenn die betroffenen Pakete als Abhängigkeiten verwendet werden. Dies liegt häufig an der Art des Angriffs, der das uneingeschränkte Hochladen von Schadcode mit der erneuten Freigabe bestehender Versionen oder der Freigabe neuer Versionen ermöglicht. Sie werden benutzt, um den Schadcode direkt in externe Projekte einzuschleusen, die automatisch auf eine neue Version des betroffenen Pakets wechseln oder eine kürzlich veröffentlichte Version verwenden, die manuell eingestellt wird.

Angriffe bleiben nicht selten tage- oder sogar wochenlang unentdeckt und werden in der Regel nur von aufmerksamen Forschern, Nutzern oder dem ursprünglichen Eigentümer aufgedeckt (wie im Fall von UAParser.js). Wie man mit dem Problem umgeht, liegt zumeist in der Verantwortung der Hosting-Plattform. Sie kann entsprechende Maßnahmen ergreifen, um bösartige Paketversionen zu entschärfen, sie entfernen oder das kompromittierte Konto sperren.

Die Angriffe selbst lassen sich relativ einfach umsetzen, hängen aber in hohem Maße von bestimmten Bedingungen ab. Diese sind in der Regel nicht in den Konten von beliebten Projekt-Eigentümern vorzufinden; insbesondere nicht bei Projekten, die häufig aktualisiert werden. In solchen Fällen nehmen die Angreifer aktive Kontobesitzer mit Phishing- oder genauer „Whaling“-Techniken ins Visier. So verschaffen sie sich Zugriff auf das Konto oder zwingen sie Aktionen in Form von Cross-Site-Scripting-Angriffen auszuführen – obwohl viele Browser und Websites über einen integrierten Schutz gegen diese Angriffe verfügen.

Repo-Jacking in der Praxis

CTX

Ein aktuelles Beispiel für Repository-Hijacking ist das Python-Paket CTX. Dessen Repository wurde auf der beliebten Hosting-Seite PyPI feindlich übernommen. In diesem Fall war die ursprüngliche Domain-Hosting-Mail des Kontoinhabers abgelaufen. So konnte das Passwort zurückgesetzt und die Domain von einem Dritten neu registriert werden.

Wie viel Zeit zwischen Ablauf des Kontos und dem erfolgreichen Hijacking-Versuch tatsächlich verging, ist unklar. Einmal eingeleitet, benötigte der Angreifer bei seinem Hijacking-Versuch aber lediglich 40 Minuten, um bösartige Versionen des Pakets hochzuladen und die ursprünglichen Versionen zu ersetzen.

Hierbei wurde ein Codeabschnitt in die Datei ctx.py eingefügt, der die Umgebungsvariablen eines Benutzers abzieht und die Daten an einen externen Endpunkt schickt. In diesem Fall war das ein gehosteter Heroku-Server. Die Daten enthielten potenziell sensible Benutzerinformationen wie API-Schlüssel und Passwörter. Sie waren als Umgebungsvariablen gespeichert, was sie leicht zugänglich machte.

Die Übernahme blieb zehn Tage lang unentdeckt. Innerhalb dieses Zeitraums wurden die manipulierten Versionen von CTX über 27.000 Mal heruntergeladen. Danach handelten die PyPI-Administratoren schnell. Sie sperrten das übernommene Konto und entfernten sämtliche Versionen von CTX, sowohl die böswilligen als auch die ursprünglichen. Die Schwachstelle ist im Black Duck Security Advisory BDSA-2022-1523 dokumentiert.

PhPass

Auf die gleiche Art und Weise wurde das PHP-Paket PhPass ausgenutzt, das auf der PHP-Hosting-Plattform Packagist und bei GitHub gehostet wird. Das Konto des ursprünglichen Eigentümers wurde von einem Angreifer gelöscht und neu registriert. Dadurch konnte er direkt auf das ursprüngliche Repository zugreifen und die ursprünglichen Paketversionen durch bösartige ersetzen. Der in diesen Ersatzversionen enthaltene Schadcode führte die gleiche Aktion aus wie bei der CTX-Übernahme – er extrahiert Umgebungsvariablen an genau denselben Endpunkt.

Um das Problem zu beheben, wurde ein Fork des Repository erstellt, der die ursprünglichen, nicht schädlichen Versionen enthält. Um sicherzustellen, dass keine weiteren Downloads von Versionen aus dem bösartigen Repository erfolgen, leitete Packagist die ursprüngliche Download-URL auf den neuen Fork um. Diese Schwachstelle ist im Black Duck Security Advisory BDSA-2022-1526 dokumentiert.

UAParser.js

Ein extremer Fall von Repository-Hijacking ereignete sich im Oktober 2021. Dabei gelang es, die beliebte JavaScript-Bibliothek UAParser.js durch die Übernahme des npm-Kontos des Autors zum Angriffsvektor umzufunktionieren. Der Angreifer veröffentlichte drei bösartige Versionen: 0.7.29, 0.8.0 und 1.0.0. Das Ganze weitete sich rasch zu einem massiven Angriff aus, denn das Paket wird in zahlreichen Projekten weiterverwendet und entsprechend häufig heruntergeladen: zwischen 8 und 9 Millionen Mal pro Woche.

Der in diesen Versionen eingeführte bösartige Code hat besonders schädliche Auswirkungen. Vor allem lädt er bei der Installation Binärdateien von einem Remote-Server herunter und führte sie aus. Eine dieser Binärdateien war eine Crypto-Mining-Software. Das Beispiel zeigte, dass ein Remote-Angreifer in der Lage ist, das System eines Opfers komplett zu kontrollieren. Eine weitere Binärdatei, die nur auf Windows-Systemen eingeschleust worden war, entpuppte sich als Trojaner, welcher sensible Daten ausleitete.

Stunden nach dem UAParser.js-Angriff entfernte der Autor des Pakets die kompromittierten Versionen von npm und veröffentlichte drei neue Versionen (0.7.30, 0.8.1 und 1.0.1). Damit wollte man verhindern, dass automatisch geplante Upgrades die schädlichen Versionen beibehalten. Diese Schwachstelle ist im Black Duck Security Advisory BDSA-2021-3228 dokumentiert.

Welche Methoden vor Repo-Jacking schützen

Die Zahl der Angriffe auf die Lieferketten nimmt weiter zu – und damit auch Fälle von Repository-Hacking. Die sind nämlich meist der erste Schritt eines solchen Angriffs. Es mag simpel sein, ein Repository zu übernehmen. Die Folgen sind dennoch ernst und die Auswirkungen weitreichend. Zumindest gibt es einige Maßnahmen, um Abhilfe zu schaffen. Teils sind sie aktuell bereits verfügbar, teils in Vorbereitung.

Die Multifaktor-Authentifizierung, in der Regel als Zwei-Faktor-Authentifizierung (2FA) implementiert, bietet eine zweite Sicherheitsebene beim Zugriff auf Konten. Theoretisch sollte sie verhindern, dass ein Angreifer auf ein abgelaufenes oder gelöschtes Konto zugreifen kann. GitHub, einer der größten Hoster, hat angekündigt, dass 2FA ab 2023 für alle Betreuerkonten verpflichtend sein soll.

Den Stellenwert der Initiative verdeutlicht die Tatsache, dass derzeit nur 16,5 Prozent der aktiven GitHub-Nutzer 2FA verwenden. Der beliebte JavaScript-Paketmanager npm hingegen verzichtet auf eine solche Maßnahme und hat auch nichts dergleichen angekündigt. Und das obwohl laut Aqua Security, Team Nautilus, knapp ein Drittel der 35 wichtigsten npm-Pakete aufgrund fehlender 2FA von einer Kontoübernahme bedroht ist.

Domain-Übernahmen sind ein gängiger Teil der Lieferkette beim Hijacking von Repositories, z. B. wenn ein Angreifer die abgelaufene Domain einer E-Mail neu registriert und die Domain verwendet, um eine Passwortrücksetzung anzustoßen. Repository-Hosting-Plattformen können versuchen, das zu verhindern, indem sie Konten mit kurz vor dem Ablauf stehenden oder abgelaufenen Domains präventiv entfernen oder sperren.

Dieses Glied innerhalb der Kette zu durchtrennen ist ein wichtiger Schritt, um den Zugang zu Konten zu blockieren, die potenziell kompromittiert werden könnten. Damit ist allerdings ein höherer Wartungs- und Überwachungsaufwand für die Hosting-Plattformen verbunden.

Fazit

In den kommenden Jahren und Monaten werden Open-Source-Projekte weiter expandieren. Ihre Zahl wächst, wodurch sie noch abhängiger und anfälliger für Hijacking werden. Parallel dazu werden mehr und mehr Eigentümer- und Autorenkonten inaktiv oder sie stehen zum Löschen an. Das eröffnet zusätzliche Möglichkeiten, Repositories zu übernehmen.

Es ist möglich, viele dieser Schwachstellen zu entschärfen. Ein Blick in die Branchenlandschaft ist allerdings eher desillusionierend. Tatsächlich entscheiden sich zu wenige Nutzer für präventive Technologien wie MFA. Methoden wie 2FA obligatorisch einzuführen, wie das jetzt GitHub getan hat, könnte den Weg in die Zukunft weisen.

Wer Open-Source-Komponenten einsetzt, sollte genau wissen, was er tut. Unerlässlich ist ein Bewusstsein dafür, was genau bei der Softwareentwicklung verwendet wird – sei es der Quellcode, seien es direkte oder transitive Abhängigkeiten einer Open-Source-Software. Es gilt, hinsichtlich der Veränderungen und potenziellen Gefahrenquellen bei OSS immer auf dem aktuellen Stand zu sein – auch wenn es sich um einen Fall wie Repo-Jacking handelt.

* Boris Cipot ist Senior Sales Engineer bei Synopsys.

(ID:48538365)