Security: RepoJacking auf GitHub betrifft auch große Firmen wie Google
Durch die Übernahme von Repositories hinter umbenannten Organisationen auf GitHub können Angreifer Schadcode verbreiten.
(Bild: zeevveez CC-BY 2.0)
Laut einer Untersuchung des auf Cloud-Native-Security spezialisierten Unternehmens Aqua Security stellt RepoJacking auf GitHub ein realistisches Risiko dar. Angreifer können Repositories übernehmen, für die GitHub nach einer Umbenennung der Organisation den Zugang automatisch weiterleitet. In das gekaperte Repo können sie Schadcode einbinden und so die Software Supply Chain angreifen.
Das für Security Research verantwortliche Nautilus-Team bei Aqua Security hat Datenbanken mit Daten von GitHub analysiert und dabei herausgefunden, dass von 1,25 Millionen untersuchten Repositories knapp drei Prozent anfällig für RepoJacking waren. Zu den betroffenen Organisationen gehörten Google und Lyft.
RepoJacking: Angriffsvektor Weiterleitung
Beim RepoJacking übernehmen Angreifer Repositories von Firmen oder Teams, die auf GitHub den Usernamen für ihre Inhalte geändert haben. Beispielsweise könnte ein Unternehmen auf GitHub unter dem Organisationsnamen Raider das Repository repo angelegt haben (https://github.com/Raider/repo). Später benennt es den GitHub-Account in Twix um, sodass das Repository unter https://github.com/Twix/repo zu finden ist.
Als Komfortfunktion kann GitHub Dependencies zum alten Account automatisch zum neuen umleiten. Skripte verwenden dann automatisch das Repository unter Twix, auch wenn es noch auf Raider verweist.
Allerdings gibt GitHub normalerweise den alten Organisationsnamen frei. Wenn also jemand den frei gewordenen Namen Raider verwendet und darunter ein Repository mit dem alten Namen anlegt, greifen alle Dependencies zu Raider/repo nicht mehr auf die Weiterleitung, sondern auf das neu angelegte Repository zu. Angreifer können dort Schadcode hinterlegen.
Abwehrmechanismen und deren Grenzen
GitHub hat durchaus Methoden, die RepoJacking für häufig verwendete beziehungsweise geklonte Repositories verhindern sollen. Allerdings gilt als Maßstab wohl der Zeitraum vor dem Umbenennen der Organisation. Für Repositories, die erst danach häufiger verwendet wurden, greift der Schutz nicht.
Auch verbreitete Projekte größerer Organisationen können durchaus betroffen sein, wenn sie interne Dependencies zu in der breiten Masse weniger bekannten Unterprojekten verwenden, die für RepoJacking anfällig sind.
Suche nach anfälligen Repositories
Aqua hat zum Suchen nach Repositories, die für RepoJacking anfällig sind, öffentlich verfügbare Daten über die GitHub-Nutzung verwendet. Das GHTorrent-Projekt hat Informationen zu allen öffentlichen Vorgängen wie Commits und Pull Requests auf GitHub gesammelt. Die zugehörige Website ist inzwischen ebenso wenig erreichbar wie der im Aqua-Blog genannte Link zum Datensatz, aber der Quellcode existiert weiter in einem GitHub-Repository. Die FAQ-Seite zeigt Details zum Projekt.
In dem Datensatz, den Aqua von der Projektseite heruntergeladen hatte, fand sich wohl die komplette Historie der Namen von Usern und Organisationen seit 2012. Die Security Researcher haben die Daten aus einem beliebig ausgewählten Monat (Juni 2019) heruntergeladen und daraus eine Liste mit 125 Millionen Repository-Namen zusammengestellt. Schließlich haben sie eine Stichprobe von einem Prozent der Daten auf Anfälligkeit für RepoJacking überprüft. Offenbar waren mit 37.000 Repositories knapp drei Prozent potenziell anfällig.
Lyft und Google betroffen
Die Untersuchung hat neben einer breiten Basis von potenziell gefährdeten Repositories, auf die vermutlich kaum jemand zugreift, auch konkrete Beispiele großer Unternehmen zutage gefördert. So fand sich in einem Repository von Lyft ein Installationsskript, das auf eine umgeleitete Organisation verweist.
(Bild: Aqua Security)
Das Nautilus-Team konnte die alte Organisation YesGraph registrieren und das im Installations-Skript angegebene Repository anlegen. Angreifer hätten auf die Weise Schadcode über ein vermeintlich vertrauenswürdiges Skript verteilen können.
Ein ähnlicher Fall betrifft Google, das in den Build-Anweisungen zum Projekt mathsteps den alten Organisationsnamen socraticorg angibt. Google hatte das Unternehmen Socratic 2018 übernommen und auf GitHub den Organisationsnamen für das Repository geändert, aber das Readme zeigt nach wie vor die Build-Anweisung mit dem alten Repository.
Sowohl Lyft als auch Google haben die Anfälligkeit laut Aqua Security inzwischen behoben. Der Blogbeitrag zur Untersuchung spricht darüber hinaus von weiteren von RepoJacking gefährdeten Unternehmen, die anonym bleiben wollen. Das Team hat nach eigenen Angaben einen Proof of Concept mit zahlreichen Repositories bekannter Unternehmen durchgeführt und überprüft, wer die Inhalte der mit RepoJacking angegriffenen Repositories heruntergeladen hat. Dabei waren wohl auch große Unternehmen betroffen.
Aufpassen und drinbleiben
Um RepoJacking entgegenzuwirken, sollte man Links zu externen GitHub-Repositories regelmäßig daraufhin überprüfen, ob sich womöglich der Name von Organisationen ändert. Tückisch ist, dass der Code dank Weiterleitung jahrelang wie gewünscht funktionieren kann, bevor Angreifer einen alten Organisationsnamen übernehmen.
Firmen oder Open-Source-Teams, die auf GitHub den Namen einer Organisation hinter einem häufig genutzten Repository ändern, sollten möglichst den alten Namen trotzdem in Besitz halten, damit niemand anderes Missbrauch mit den Inhalten treiben kann.
(rme)
