Gefahr für Software-Supply-Chain: Sicherheitslücke in PyTorch

Foto: Ralf Liebhold – shutterstock.com

Sicherheitsforschern ist es gelungen, die Entwicklungsinfrastruktur für PyTorch zu infiltrieren, indem sie unsichere Konfigurationen in GitHub Actions ausnutzen. PyTorch ist ein Open-Source-Programm für maschinelles Lernen (ML) auf Basis der Programmiersprache Phyton.

“Unser Exploit-Pfad führte dazu, dass bösartige PyTorch-Releases auf GitHub und auf AWS hochgeladen werden konnten. Zudem war es möglich, Code zum Haupt-Repository-Zweig hinzuzufügen und PyTorch-Abhängigkeiten über eine Backdoor einzuschleusen – die Liste lässt sich fortsetzen”, erklärt der Security-Analyst John Stawinski in seinem Blog-Beitrag. Stawinski hat den Angriff zusammen mit seinem Kollegen Adnan Khan entwickelt.

CI/CD-Plattformen in Visier

Die beiden Sicherheitsingenieure von der Cybersecurity-Firma Praetorian begannen im vergangenen Jahr, Exploits für Plattformen zur kontinuierlichen Integration und kontinuierlichen Bereitstellung (CI/CD) zu erforschen und zu entwickeln. Eines ihrer ersten Ziele war GitHub Actions. Mit dem CI/CD-Dienst können GitHub-Nutzer Softwarecode automatisiert erstellen und testen. Dazu werden Arbeitsabläufe definiert, die automatisch in Containern auf der Infrastruktur von GitHub oder der des Benutzers ausgeführt werden.

Khan fand zunächst eine kritische Schwachstelle, über die die offiziellen Runner-Images von GitHub Actions infiziert werden konnten. Bei den “Runnern” handelt es sich um virtuelle Maschinen (VMs), die in GitHub-Actions-Workflows definierte Build-Aktionen ausführen. Daraufhin meldete er die Schwachstelle bei GitHub. Anschließend erkannte er jedoch, dass das von ihm gefundene Kernproblem systemisch war und dass wahrscheinlich Tausende anderer Repositories betroffen waren.

Seitdem haben Khan und Stawinski Schwachstellen in den Software-Repositories und der Entwicklungsinfrastruktur großer Unternehmen und Softwareprojekte gefunden und über Bug-Bounty-Programme Hunderttausende von Dollar an Belohnungen gesammelt. Zu ihren “Opfern” gehörten Microsoft Deepspeed, eine Cloudflare-Anwendung, die TensorFlow-Bibliothek für maschinelles Lernen, die Krypto-Wallets und Knoten mehrerer Blockchains sowie PyTorch.

“Wir begannen damit, jede Nuance der Exploits von GitHub-Aktionen zu erforschen und Tools, Taktiken und Verfahren (TTPs) auszuführen, die noch nie zuvor in der freien Wildbahn gesehen wurden”, so Stawinski. “Mit fortschreitender Forschung haben wir unsere TTPs weiterentwickelt, um mehrere CI/CD-Plattformen anzugreifen, darunter GitHub Actions, Buildkite, Jenkins und CircleCI.”

Risiko durch selbst gehostete GitHub Actions-Runner

GitHub bietet verschiedene Arten von vorkonfigurierten “Runnern” (Windows, Linux und macOS) an, die direkt auf der Infrastruktur von GitHub laufen. Mit ihnen lassen sich Anwendungen für diese Betriebssysteme testen und erstellen.

Benutzer haben jedoch auch die Möglichkeit, den Build-Agent von GitHub Actions auf ihrer eigenen Infrastruktur einzusetzen und ihn mit ihrer GitHub-Organisation und ihren Repositories zu verknüpfen. Diese sogenannten Self-Hosted-Runner bieten mehrere Vorteile, zum Beispiel die Möglichkeit, verschiedene Betriebssystemversionen und Hardwarekombinationen auszuführen, sowie zusätzliche Softwaretools, über die von GitHub gehostete Runner nicht verfügen.

Lesetipp: GitHub-Repojacking-Studie

Angesichts dieser Flexibilität ist es nicht verwunderlich, dass sich viele Projekte und Organisationen sich für selbst gehostete Runner entscheiden. Dies war auch bei PyTorch der Fall, das sowohl die von GitHub gehosteten als auch die selbst gehosteten Build-Agents intensiv nutzt. Das Unternehmen hat mehr als 70 verschiedene GitHub-Workflow-Dateien in seinen Repositories und führt normalerweise mehr als zehn Workflows pro Stunde aus.

Actions-Workflows werden in .yml-Dateien definiert, die Anweisungen in YAML-Syntax enthalten, welche Befehle auf welchem Runner ausgeführt werden sollen. Diese Workflows werden automatisch bei verschiedenen Ereignissen ausgelöst – zum Beispiel bei pull_request, wenn jemand eine Codeänderung an einem Repository-Zweig vorschlägt. Dadurch können beispielsweise eine Reihe von Tests mit dem Code durchgeführt werden, bevor ein menschlicher Prüfer ihn sich überhaupt ansieht und entscheidet, ihn zusammenzuführen.

“Es ist ein Problem, dass einige der Standardeinstellungen von GitHub nicht sicher sind”, kritisiert Stawinski. “Wenn ein selbst gehosteter Runner an ein Repository angehängt wird, können alle Workflows dieses Repositorys standardmäßig diesen Runner verwenden. Diese Einstellung gilt auch für Workflows aus Fork-Pull-Requests [PRs]. Das Ergebnis dieser Einstellungen ist, dass standardmäßig jeder, der zum Repository beiträgt, Code auf dem selbst gehosteten Runner ausführen kann, indem er einen bösartigen PR einreicht.”

Ein Fork-Pull-Request bedeutet, dass jemand eine persönliche Kopie (einen Fork) des Repositorys erstellt hat, daran gearbeitet hat und nun versucht, die Änderungen wieder einzubinden. Dies ist eine gängige Praxis, da Mitwirkende oft in ihren eigenen Forks arbeiten, bevor sie die Änderungen zur Genehmigung an das Haupt-Repository zurücksenden.

Aus der Sicht von GitHub ist ein “Mitwirkender” jeder, dessen Pull-Requests zurück in den Standardzweig zusammengeführt wurden. Die Standardeinstellung für die Ausführung des Workflows ist die automatische Ausführung von Fork-Pull-Requests von früheren Mitwirkenden. Das bedeutet, wenn jemand jemals einen Fork-PR zusammengeführt hat, werden Workflows automatisch für alle zukünftigen Fork-PRs ausgeführt. Diese Einstellung kann dahingehend geändert werden, dass vor der Ausführung von Workflows für alle Fork-PRs eine Genehmigung erforderlich ist, unabhängig davon, ob der Eigentümer ein früherer Mitwirkender ist oder nicht.

“Bei der Durchsicht der Pull-Request-Historie fanden wir mehrere PRs von früheren Mitwirkenden, die pull_request-Workflows auslösten, ohne eine Genehmigung zu erfordern”, so die Forscher. “Dies deutet darauf hin, dass das Repository keine Workflow-Genehmigung für Fork-PRs von früheren Mitwirkenden benötigt. “

Ein Angreifer müsste also zunächst ein Mitwirkender werden, indem er einen legitimen Fork-PR einreicht, der dann zusammengeführt wird, und dann könnte er sein neu gewonnenes Privileg missbrauchen, einen Fork erstellen, eine bösartige Workflow-Datei darin schreiben und einen Pull-Request stellen. Dadurch wird ihr bösartiger Workflow automatisch auf dem selbst gehosteten GitHub-Actions-Runner der Organisation ausgeführt.

Das klingt nach einer Menge Arbeit, ist es aber nicht. Sie müssen keine neuen Funktionen zu einem Projekt hinzufügen, um ein Mitwirkender zu werden. Die Forscher erlangten den Status eines Mitwirkenden an PyTorch, indem sie einen Tippfehler in einer Dokumentationsdatei entdeckten und einen PR erstellten, um ihn zu beheben. Sobald ihre kleine Grammatikkorrektur akzeptiert wurde, waren sie in der Lage, bösartige Workflows auszuführen.

Verwendung des GitHub-Actions-Runner als Trojaner

Ein weiteres Standardverhalten von selbst gehosteten GitHub-Actions-Runnern ist, dass sie langlebig sind. Sie werden nicht zurückgesetzt und gelöscht, sobald ein Workflow abgeschlossen ist. “Dies bedeutet, dass der bösartige Workflow einen Prozess im Hintergrund starten kann, der nach Abschluss des Auftrags weiterläuft. Änderungen an Dateien (wie Programme im Pfad) bleiben also über den aktuellen Workflow hinaus bestehen”, so die Forscher. “Das bedeutet auch, dass künftige Workflows mit demselben Runner ausgeführt werden.

Dies macht ihn zu einem guten Ziel, um einen Trojaner einzuschleusen. Er stellt eine Verbindung zu den Angreifern her und sammelt dann alle möglichen sensiblen Informationen, die durch zukünftige Workflow-Ausführungen offengelegt werden. Aber was könnte man als Trojaner verwenden, der von Antivirenprodukten nicht erkannt oder dessen Kommunikation nicht blockiert wird? Denkbar ist der GitHub-Actions-Runner-Agent selbst, oder vielmehr eine andere Instanz davon, die nicht mit der PyTorch-Organisation, sondern mit einer von den Angreifern kontrollierten GitHub-Organisation verbunden ist.

“Unsere ‘Runner on Runner’-Technik (RoR) verwendet dieselben Server für C2 wie der vorhandene Runner, und die einzige Binärdatei, die wir ablegen, ist die offizielle GitHub-Runner-Agent-Binärdatei, die bereits auf dem System läuft”, sagte Stawinski. Das heble etwa EDR und Firewall-Schutz aus.

Lesetipp: Wie Angreifer GitHub Codespaces nutzen könnten

Extrahieren sensibler Zugriffstoken

Bis zu diesem Schritt ist es den Angreifern gelungen, ein sehr unauffälliges Trojaner-Programm auf einem Rechner auszuführen, der Teil der Entwicklungsinfrastruktur des Unternehmens ist und zur Ausführung sensibler Aufgaben im Rahmen der CI/CD-Pipeline verwendet wird. Der nächste Schritt ist die Post-Exploitation: der Versuch, sensible Daten zu stehlen und auf andere Teile der Infrastruktur überzugehen.

Workflows enthalten häufig Zugriffs-Token für GitHub oder andere Dienste von Drittanbietern. Diese Token sind erforderlich, damit die im Workflow definierten Aufträge korrekt ausgeführt werden können. So benötigt der Build-Agent beispielsweise Leseberechtigungen, um das Repository zunächst zu prüfen, und möglicherweise auch Schreibberechtigungen, um die resultierende Binärdatei als neue Version zu veröffentlichen oder bestehende Versionen zu ändern.

Diese Token werden im Dateisystem des Runners an verschiedenen Stellen gespeichert, zum Beispiel in der .git-Konfigurationsdatei oder in Umgebungsvariablen. Sie können von dem heimlichen “Trojaner” gelesen werden, der mit Root-Rechten läuft. Einige Token sind flüchtig und nur während der Ausführung des Workflows gültig. Doch die Forscher haben Wege gefunden, ihre Lebensdauer zu verlängern. Selbst wenn sie diese Methoden nicht gefunden hätten, werden in einem stark frequentierten Repository wie PyTorch ständig neue Arbeitsabläufe mit neu generierten Token ausgeführt, so dass es viele neue Token zu sammeln gibt.

“Das PyTorch-Repository verwendete GitHub-Geheimnisse, um den Runnern den Zugriff auf sensible Systeme während des automatisierten Release-Prozesses zu ermöglichen”, so Stawinski. “Das Repository verwendete eine Menge Geheimnisse, darunter mehrere Sätze von AWS-Schlüsseln und GitHub Personal Access Tokens (PATs).”

PATs sind oft überprivilegiert und ein attraktives Ziel für Angreifer, aber in diesem Fall wurden sie als Teil anderer Arbeitsabläufe verwendet, die nicht auf dem kompromittierten selbst gehosteten Runner ausgeführt wurden. Die Forscher fanden jedoch Wege, die kurzlebigen GitHub-Tokens, die sie sammeln konnten, zu nutzen. Damit konnten sie bösartigen Code in Workflows platzieren, die auf anderen Runnern ausgeführt wurden und diese PATs enthielten.

“Es hat sich herausgestellt, dass man einen GutHub-Token nicht verwenden kann, um Workflow-Dateien zu ändern”, sagte Stawinski. “Wir haben jedoch mehrere kreative ‘Umgehungslösungen’ entdeckt, mit denen man einem Workflow unter Verwendung eines GutHub-Token bösartigen Code hinzufügen kann. In diesem Szenario verwendete weekly.yml einen anderen Workflow, der ein Skript außerhalb des Verzeichnisses .github/workflows verwendete. Wir könnten unseren Code zu diesem Skript in unserem Fork hinzufügen. Dann könnten wir diesen Workflow in unserem Fork auslösen, wodurch unser bösartiger Code ausgeführt würde.”

Mit anderen Worten: Selbst wenn ein Angreifer einen Workflow nicht direkt ändern kann, ist er möglicherweise in der Lage, ein externes Skript zu ändern, das von diesem Workflow aufgerufen wird, und auf diese Weise seinen bösartigen Code zu erhalten. Repositories und CI/CD-Workflows können komplex sein und viele Abhängigkeiten aufweisen, so dass solche kleinen Versehen nicht ungewöhnlich sind.

Selbst ohne die PATs hätte der GutHub-Token allein mit Schreibrechten ausgereicht, um die PyTorch-Veröffentlichungen auf GitHub zu vergiften. Separat extrahierte AWS-Schlüssel hätten verwendet werden können, um PyTorch-Veröffentlichungen, die auf dem AWS-Konto des Unternehmens gehostet werden, durch eine Hintertür zu öffnen. “Es gab noch andere Sätze von AWS-Schlüsseln, GitHub-PATs und verschiedene Anmeldeinformationen, die wir hätten stehlen können, aber wir waren der Meinung, dass wir zu diesem Zeitpunkt die Auswirkungen klar demonstriert hatten”, so die Forscher. “Angesichts der kritischen Natur der Schwachstelle wollten wir den Bericht so schnell wie möglich einreichen”

Risikominimierung bei CI/CD-Workflows

Aus diesem Angriff können Softwareentwicklungsunternehmen viel lernen: von den Risiken, die mit der Ausführung von selbst gehosteten GitHub-Actions-Runnern in Standardkonfigurationen verbunden sind, über die Risiken von Workflows, die Skripte von außerhalb des Workflows-Verzeichnisses ausführen, bis hin zu den Risiken, die mit überprivilegierten Zugriffstoken und legitimen Anwendungen verbunden sind, die als Trojaner umfunktioniert werden. Andere Forscher haben dies bereits mit Amazons AWS-System-Manager-Agent und mit Googles SSO- und Geräteverwaltungslösung für Windows getan.

“Die Sicherung und der Schutz der Runner liegt in der Verantwortung der Endnutzer, nicht bei GitHub. Deshalb empfiehlt GitHub, keine selbst gehosteten Runner in öffentlichen Repositories zu verwenden”, so Stawinski.

Wenn selbst gehostete Runner jedoch notwendig sind, sollten Organisationen zumindest in Erwägung ziehen, die Standardeinstellung von “Genehmigung für erstmalige Mitwirkende erforderlich” in “Genehmigung für alle externen Mitarbeiter erforderlich” zu ändern. Es ist auch eine gute Idee, selbst gehostete Runner nur für kurze Zeit bestehen zu lassen und Workflows von Fork-PRs nur auf GitHub-gehosteten Runnern auszuführen.

Dies ist nicht das erste Mal, dass die unsichere Nutzung von GitHub-Actions-Funktionen zu Sicherheitsrisiken in der Software-Lieferkette geführt hat. Auch andere CI/CD-Dienste und -Plattformen haben ihre eigenen Schwachstellen und unsichere Standardkonfigurationen. “Die Probleme rund um diese Angriffswege sind nicht nur bei PyTorch zu finden”, so die Forscher. “Sie sind nicht einzigartig für ML-Repositories oder sogar für GitHub. Wir haben wiederholt Schwachstellen in der Lieferkette aufgezeigt, indem wir CI/CD-Schwachstellen in den fortschrittlichsten Technologieunternehmen der Welt über verschiedene CI/CD-Plattformen ausgenutzt haben, und diese sind nur eine kleine Teilmenge der größeren Angriffsfläche.” (jm)

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.