Attack on the PyTorch infrastructure, compromising the repository and releases

Details have emerged about the attack on the infrastructure used in the development of the PyTorch machine learning framework, which allowed the extraction of access keys sufficient to deploy arbitrary data in the project's release repository on GitHub and AWS, as well as to inject code into the main branch of the repository and add a backdoor through dependencies. The substitution of PyTorch releases could have been used to launch attacks on major companies such as 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 about the issue.

The essence of the attack lies in the ability to execute one's own code on servrar continuous integration systems that perform rebuilds and execute tasks for testing new changes sent to the repository. The issue affects projects that use self-hosted external handlers, "Self-Hosted Runner," with GitHub Actions. Unlike traditional GitHub Actions, Self-Hosted handlers are not executed in GitHub's infrastructure but on their own servers or in virtual machines managed by the developers.

Executing build tasks on one's own servers allows for the launching of code that can scan the enterprise's internal network, search the local filesystem for encryption keys and access tokens, and analyze environment variables with parameters for accessing external storage or cloud services. Without proper isolation of the build environment, any confidential data found can be sent to the attacker externally, for example, through calls to external APIs. To determine the use of "Self-Hosted Runner" by projects, the Gato toolkit can be used, analyzing public workflow files and logs of CI job executions.

I PyTorch och många andra projekt som använder "Self-Hosted Runner" är det endast utvecklare vars ändringar tidigare har granskats och inkluderats i projektets kodbas som har tillåtelse att starta bygguppgifter. Att ha status som "contributor" när man använder standardinställningarna i ett repository ger möjlighet att köra GitHub Actions-handledare när pull-begärningar skickas och därmed köra sin kod i vilken GitHub Actions Runner-miljö som helst som är kopplad till repositoryt eller den organisation som projektet övervakar.

Bindningen till statusen "contributor" visade sig vara lätt att kringgå — det räckte med att tidigare skicka en obetydlig ändring och vänta på att den skulle godkännas i kodbasen, vartill utvecklaren automatiskt fick status som aktiv deltagare vars pull-begärningar får testas i CI-infrastrukturen utan särskild granskning. För att få status som aktiv utvecklare under experimentet användes obetydliga kosmetiska ändringar kopplade till korrigeringar av typografiska fel i dokumentationen. För att få åtkomst till PyTorch-repositoryt och release-lagringen under attacken, genom att köra kod i "Self-Hosted Runner", genomfördes en avlyssning av en GitHub-token som användes för att få åtkomst till repositoryt från byggprocesserna, liksom AWS-nycklar som användes för att spara byggresultat.

Problemet är inte specifikt för PyTorch och berör många andra större projekt som använder standardinställningarna för "Self-Hosted Runner" i GitHub Actions. Till exempel har liknande attacker nämnts för att infoga bakdörrar i några stora kryptovaluta-plånböcker och blockchain-projekt med miljardkapitalisering, för att göra ändringar i Microsoft Deepspeed och TensorFlow-releaser, för att kompromettera en av CloudFlare-företagets applikationer, samt för att köra kod på datorer inom Microsofts nätverk. Detaljer kring dessa incidenter har ännu inte offentliggjorts. Inom ramen för de aktiva Bug Bounty-programmen har forskare skickat mer än 20 ansökningar för att få belöning på sammanlagt flera hundra tusen dollar.

Källa: opennet.ru