Details des Angriffs auf die Infrastruktur, die bei der Entwicklung des PyTorch-Frameworks für maschinelles Lernen verwendet wurde, wurden enthüllt, was es ermöglichte, ausreichende Zugriffsschlüssel zu extrahieren, um beliebige Daten im Repository mit Projektveröffentlichungen auf GitHub und AWS zu platzieren sowie Code zu ersetzen im Hauptzweig des Repositorys und fügen Sie über Abhängigkeiten eine Hintertür hinzu. PyTorch-Release-Spoofing könnte genutzt werden, um große Unternehmen wie Google, Meta, Boeing und Lockheed Martin anzugreifen, die PyTorch in ihren Projekten verwenden. Im Rahmen des Bug-Bounty-Programms zahlte Meta Forschern 16250 US-Dollar für Informationen über das Problem.
Der Kern des Angriffs besteht in der Möglichkeit, Ihren Code auf Continuous-Integration-Servern auszuführen, die Neuerstellungen durchführen und Jobs ausführen, um neue, an das Repository gesendete Änderungen zu testen. Das Problem betrifft Projekte, die ihre eigenen externen „Self-Hosted Runner“-Handler mit GitHub-Aktionen verwenden. Im Gegensatz zu herkömmlichen GitHub-Aktionen werden selbstgehostete Handler nicht auf der GitHub-Infrastruktur ausgeführt, sondern auf ihren eigenen Servern oder in vom Entwickler verwalteten virtuellen Maschinen.
Durch die Ausführung von Assembly-Aufgaben auf Ihren Servern können Sie den Start von Code organisieren, der das interne Netzwerk eines Unternehmens scannen, den lokalen FS nach Verschlüsselungsschlüsseln und Zugriffstokens durchsuchen und Umgebungsvariablen mit Parametern für den Zugriff auf externe Speicher oder Cloud-Dienste analysieren kann. Ohne eine ordnungsgemäße Isolierung der Assembly-Umgebung können die gefundenen vertraulichen Daten beispielsweise durch den Zugriff auf externe APIs an Angreifer außerhalb gesendet werden. Um die Nutzung von Self-Hosted Runner durch Projekte zu ermitteln, kann das Gato-Toolkit zur Analyse öffentlich zugänglicher Workflow-Dateien und CI-Aufgabenstartprotokolle verwendet werden.
In PyTorch und vielen anderen Projekten, die den Self-Hosted Runner verwenden, dürfen nur Entwickler, deren Änderungen zuvor einer Peer-Review unterzogen und in die Codebasis des Projekts aufgenommen wurden, Build-Jobs ausführen. Der Status „Mitwirkender“ bei Verwendung der Standardeinstellungen im Repository ermöglicht es, GitHub Actions-Handler beim Senden von Pull-Requests zu starten und Ihren Code entsprechend in jeder GitHub Actions Runner-Umgebung auszuführen, die mit dem Repository oder der Organisation, die das Projekt überwacht, verbunden ist.
Es stellte sich heraus, dass der Link zum Status „Mitwirkender“ leicht zu umgehen war. Es reicht aus, zunächst eine geringfügige Änderung einzureichen und darauf zu warten, dass diese in die Codebasis übernommen wird. Anschließend erhielt der Entwickler automatisch den Status eines aktiven Teilnehmers. deren Pull-Requests ohne separate Verifizierung in der CI-Infrastruktur getestet werden dürfen. Um den Status eines aktiven Entwicklers zu erreichen, umfasste das Experiment kleinere kosmetische Änderungen, um Tippfehler in der Dokumentation zu korrigieren. Um Zugriff auf das Repository und den Speicher von PyTorch-Versionen zu erhalten, fing der Angriff beim Ausführen von Code im „Self-Hosted Runner“ das GitHub-Token ab, das für den Zugriff auf das Repository aus Build-Prozessen verwendet wurde, sowie die AWS-Schlüssel, die zum Speichern der Build-Ergebnisse verwendet wurden .
Das Problem ist nicht spezifisch für PyTorch und betrifft viele andere große Projekte, die die Standardeinstellungen für „Self-Hosted Runner“ in GitHub Actions verwenden. Beispielsweise wurde die Implementierung ähnlicher Angriffe erwähnt, um eine Hintertür in einigen großen Kryptowährungs-Wallets und Blockchain-Projekten mit einer Kapitalisierung von einer Milliarde Dollar zu installieren, Änderungen an den Versionen von Microsoft Deepspeed und TensorFlow vorzunehmen, eine der CloudFlare-Anwendungen zu kompromittieren und auch auszuführen Code auf einem Computer im Microsoft-Netzwerk. Einzelheiten zu diesen Vorfällen wurden noch nicht bekannt gegeben. Im Rahmen bestehender Bug-Bounty-Programme haben Forscher mehr als 20 Anträge auf Belohnungen im Wert von mehreren hunderttausend Dollar eingereicht.
Source: opennet.ru