Details of the attack on the infrastructure used for developing the PyTorch machine learning framework have been revealed. This allowed for the extraction of access keys sufficient to place arbitrary data in the project's release repository on GitHub and AWS, as well as to insert code into the main branch of the repository and add a backdoor through dependencies. The replacement of PyTorch releases could have been used to launch attacks on major companies like Google, Meta, Boeing, and Lockheed Martin, which utilize PyTorch in their projects. As part of the Bug Bounty program, Meta paid researchers $16,250 for information regarding the issue.
The essence of the attack lies in the ability to execute one's own code on Servern continuous integration systems that rebuild and execute tasks for testing new changes submitted to the repository. The issue affects projects that use their own external handlers called ‘Self-Hosted Runners’ with GitHub Actions. Unlike traditional GitHub Actions, Self-Hosted Runners are executed not in GitHub infrastructure, but on their own servers or in virtual machines supported by the developers.
Die Ausführung von Build-Jobs auf eigenen Servern ermöglicht das Starten von Code, der das interne Netzwerk des Unternehmens scannen kann, um in der lokalen Dateiablage nach Verschlüsselungsschlüsseln und Zugriffstoken zu suchen sowie Umgebungsvariablen mit Parametern für externe Speicher oder Cloud-Dienste zu analysieren. Bei fehlender angemessener Isolation der Build-Umgebung können gefundene vertrauliche Daten von Angreifern nach außen gesendet werden, beispielsweise durch Aufrufe an externe APIs. Zur Bestimmung des Einsatzes von "Self-Hosted Runner"-Projekten kann das Gato-Toolset verwendet werden, das öffentliche Workflow-Dateien und Protokolle von CI-Jobs analysiert.
In PyTorch und vielen anderen Projekten, die "Self-Hosted Runner" verwenden, ist der Start von Build-Jobs nur Entwicklern erlaubt, deren Änderungen zuvor überprüft und in das Projekt-Repository aufgenommen wurden. Der Status "Contributor" ermöglicht es, bei Verwendung der Standardeinstellungen im Repository GitHub Actions-Handler zu starten, wenn Pull-Requests übermittelt werden, und somit eigenen Code in jeder Umgebung des GitHub Actions Runners auszuführen, die mit dem Repository oder der betreuenden Projektorganisation verbunden ist.
Die Umgehung des Status „Contributor“ stellte sich als einfach heraus – es genügte, eine geringe Änderung vorzuschlagen und auf deren Annahme in die Codebasis zu warten. Danach erhielt der Entwickler automatisch den Status eines aktiven Mitwirkenden, dessen Pull-Requests im CI-System ohne separate Überprüfung getestet werden durften. Um den Status eines aktiven Entwicklers zu erlangen, wurden geringfügige kosmetische Änderungen verwendet, die mit der Behebung von Tippfehlern in der Dokumentation verbunden waren. Um Zugriff auf das Repository und das Release-Archiv von PyTorch während des Angriffs zu erhalten, wurde in einem „Self-Hosted Runner“ ein Token von GitHub abgefangen, das für den Zugang zum Repository aus den Build-Prozessen verwendet wurde, sowie AWS-Schlüssel, die zur Speicherung der Build-Ergebnisse eingesetzt wurden.
Das Problem ist nicht spezifisch für PyTorch und betrifft viele andere große Projekte, die die Standardkonfiguration für den "Self-Hosted Runner" in GitHub Actions verwenden. So wurden beispielsweise ähnliche Angriffe festgestellt, um Backdoors in einige große Kryptowährungs-Wallets und Blockchain-Projekte mit Milliardenbewertung einzuschleusen, Änderungen an den Releases von Microsoft Deepspeed und TensorFlow vorzunehmen, eine der Anwendungen von CloudFlare zu kompromittieren und Code auf einem Computer im Microsoft-Netzwerk auszuführen. Details zu diesen Vorfällen sind bisher nicht bekannt gegeben worden. Im Rahmen der bestehenden Bug-Bounty-Programme haben Forscher mehr als 20 Anträge auf Prämien in Höhe von mehreren Hunderttausend Dollar eingereicht.
Quelle: opennet.ru
