GitHub: Wie geänderte Benutzernamen die Supply Chain gefährden

Potenziell betroffen waren durch die Schwachstelle alle geänderten Benutzernamen auf GitHub, einschließlich über 10.000 Pakete von Paketmanager Go, Swift und Packagist. Zwar wurde die Schwachstelle von GitHub bereits behoben und ist nicht mehr ausnutzbar. Sie ist aber auch nicht die erste, die Experten diesem Zusammenhang entdeckt haben. Erst Anfang 2022 nutzte ein Angreifer eine ähnliche Schwachstelle aus, um beliebte PHP-Pakete mit Millionen von Downloads zu hijacken und zu infizieren. RepoJacking wird wohl auch in Zukunft ein attraktiver Hebel für Supply-Chain-Angriffe bleiben.

Verknüpfung von GitHub Repository URL mit Benutzernamen

GitHub Repositories haben eine eindeutige URL, die unter dem Benutzerkonto verschachtelt ist, das das Repository erstellt hat. Möchte jemand das Open Source Repository downloaden (klonen), verwendet er die vollständige Repository URL.

GitHub Repositories sind also mit Benutzernamen verknüpft. Und was passiert, wenn Benutzer beschließen, ihren Benutzernamen zu ändern? In diesem Fall zeigt GitHub die folgende Warnung an. Und weist darauf hin, dass der gesamte für die alte Repository URL intendierte Traffic auf die neue URL umgeleitet wird.

Akzeptiert man die Bedingungen und ändert den Benutzernamen, richtet GitHub automatisch Redirects von den alten Repository URLs zu den neuen ein. So laufen Requests anderer Benutzer, die nichts von der Änderung des Benutzernamens wissen, an die alte Repository URL nicht ins Leere.

Was steckt hinter RepoJacking?

RepoJacking ist eine Technik, mit der Angreifer den Traffic geänderter Repository-URLs hijacken. Und so zu ihrem eigenen Repository umleiten können, indem sie einen logischen Fehler ausnutzen, der den ursprünglichen Redirect aufbricht. Ein GitHub Repository ist prinzipiell immer dann anfällig für RepoJacking, wenn dessen Ersteller seinen Benutzernamen ändert und der alte Benutzername dadurch wieder zur Verfügung steht, sich also registrieren lässt.

Da der Repository-Name und der Benutzername des Erstellers in der Repository-URL verknüpft sind, können Angreifer nun ein neues GitHub-Konto mit derselben Kombination anlegen. Sie können so die alte Repository URL, auf die bestehende Benutzer zugreifen, imitieren und hijacken. Denn sobald sie das tun, wird der ursprüngliche Redirect deaktiviert. Hierbei wird der gesamte bestehende Traffic zu deren bösartigen GitHub Repository umgeleitet.

Welchen Schutz bietet GitHub vor RepoJacking?

Um dem einen Riegel vorzuschieben, hat GitHub den „Popular Repository Namespace Retirement“ Mechanismus implementiert. Jedes Repository, das zu dem Zeitpunkt, zu dem das zugehörige Benutzerkonto umbenannt wird, mehr als 100 Klone aufweist, gilt als „Retired“ und kann von anderen nicht mehr verwendet werden. Zur Verdeutlichung: Was als „Retired“ gilt, ist der Namespace, also die Kombination aus Benutzername und Repository-Name.

Nehmen wir als Beispiel das Repository mit dem Namen „repo“ und dem Benutzernamen „account-takeover-victim“. Dieses Repository wurde kürzlich 100-mal geklont, weshalb der „Popular Repository Namespace Retirement“ Mechanismus greift. An diesem Punkt beschließt der Besitzer des zugehörigen Kontos, seinen Benutzernamen zu ändern. In der Praxis bedeutet das, dass der Benutzername „account-takeover-victim“ nun von jedem beansprucht werden kann. Sobald jedoch der neue Besitzer dieses Benutzernamens versucht, ein neues Repository unter dem Namen „repo“ zu öffnen, wird er blockiert und erhält die folgende Meldung:

Wie Angreifer diesen Schutz hätten umgehen können

Allerdings fand unser Supply Chain Security Research Team um Chief Architect Elad Rapoport einen Weg, diesen Schutz zu umgehen. Im Zentrum des Exploits steht die Funktion „Repository Transfer“, die Angreifer wie folgt hätten missbrauchen können:

1. „victim/repo“ ist ein beliebtes GitHub Repository, das als „Retired“ gilt, sprich bei dem der Schutz des „Popular Repository Namespace Retirement“ Mechanismus greift
2. „helper_account” erstellt das Repository „repo”
3. „helper_account“ überträgt das Eigentum am Repository „repo“ an „attacker_account“
4. „attacker_account“ ändert seinen Benutzernamen in „victim“
5. Das neue Konto „victim“ (zuvor „attacker_account“) akzeptiert die Eigentumsübertragung, wodurch der Angreifer die Kontrolle über den Namespace „victim/repo“ erlangt

Auswirkungen des Angriffs

Dieser Exploit hätte es Angreifern ermöglichen können, beliebte Code-Pakete in mehreren Paketmanagern, darunter Packagist, Go, Swift und andere, zu hijacken. Die Experten von Supply Chain Security Research hat mehr als 10.000 Pakete in diesen Paketmanagern identifiziert, die geänderte Benutzernamen verwenden und potenziell angreifbar gewesen wären. Ebenso wäre es vorstellbar gewesen, dass Angreifer auf diesem Weg beliebte GitHub Actions kompromittieren, die sich ebenfalls unter Angabe eines GitHub Namespaces nutzen lassen. Kompromittierte GitHub Actions hätten schwerwiegende Supply-Chain-Angriffe mit weitreichenden Folgen ins Rollen bringen können.

Dass GitHub-Benutzer – darunter bisweilen auch solche, die beliebte Repositories und Pakete kontrollieren – ihren Benutzernamen ändern, ist an sich keine Seltenheit. Aus diesem Grund bleibt der Versuch, den „Popular Repository Namespace Retirement“-Mechanismus zu umgehen, ein attraktiver Vektor für Supply-Chain-Angriffe, der immensen Schaden verursachen kann. Zumal dieser auf Basis interner Metriken greift, ohne dass Nutzer Rückschlüsse darauf ziehen können, ob ein bestimmter Namespace geschützt ist oder nicht.

Über den Autor: Aviad Gershon ist Research Engineer bei Checkmarx und hat eine besondere Affinität zu Machine Learning und Deep Learning. Vor seinem Engagement bei Checkmarx arbeitete er als Security Researcher bei Dustico, als Cyber-Threat-Analyst beim Cyber Emergency Response Team (IL-CERT) in Israel und gründete Synolo – eine auf Deep Learning basierende App zur Unterstützung von Aquafarming. Er hat einen B.Sc.-Abschluss in Physik und Philosophie der Hebräischen Universität Jerusalem. (sg)

Lesen Sie auch: Sicherheitslücke in Salesforce: Varonis verbessert Schutz von SaaS-Daten

Aufmacherbild: VideoFlow – Adobe Stock