Detaljer om attacken mot infrastrukturen som användes i utvecklingen av PyTorchs maskininlärningsramverk avslöjades, vilket gjorde det möjligt att extrahera åtkomstnycklar tillräckliga för att placera godtycklig data i förvaret med projektutgåvor på GitHub och AWS, samt att ersätta kod i förvarets huvudgren och lägg till en bakdörr genom beroenden. PyTorch release spoofing kan användas för att attackera stora företag som Google, Meta, Boeing och Lockheed Martin som använder PyTorch i sina projekt. Som en del av Bug Bounty-programmet betalade Meta forskarna 16250 XNUMX dollar för information om problemet.
Kärnan i attacken är förmågan att köra din kod på kontinuerliga integrationsservrar som utför ombyggnader och kör jobb för att testa nya ändringar som skickas till förvaret. Problemet påverkar projekt som använder sina egna externa "Self-Hosted Runner"-hanterare med GitHub Actions. Till skillnad från traditionella GitHub-åtgärder, körs Self-Hosted-hanterare inte på GitHub-infrastrukturen, utan på sina egna servrar eller i utvecklarunderhållna virtuella maskiner.
Genom att utföra monteringsuppgifter på dina servrar kan du organisera lanseringen av kod som kan skanna det interna nätverket i ett företag, söka i den lokala FS efter krypteringsnycklar och åtkomsttokens och analysera miljövariabler med parametrar för åtkomst till extern lagring eller molntjänster. I avsaknad av korrekt isolering av assemblermiljön kan hittade konfidentiella data skickas externt till angripare, till exempel genom åtkomst till externa API:er. För att bestämma användningen av Self-Hosted Runner av projekt kan Gato-verktygslådan användas för att analysera allmänt tillgängliga arbetsflödesfiler och CI-uppgiftsstartsloggar.
I PyTorch och många andra projekt som använder Self-Hosted Runner är det bara utvecklare vars ändringar tidigare har granskats och inkluderats i projektets kodbas som får köra byggjobb. Att ha statusen "bidragsgivare" när du använder standardinställningarna i förvaret gör det möjligt att starta GitHub Actions-hanterare när du skickar pull-förfrågningar och följaktligen exekvera din kod i valfri GitHub Actions Runner-miljö som är associerad med förvaret eller organisationen som övervakar projektet.
Länken till statusen "bidragsgivare" visade sig vara lätt att kringgå - det räcker att först skicka in en mindre ändring och vänta på att den ska accepteras i kodbasen, varefter utvecklaren automatiskt fick statusen som en aktiv deltagare, vars pull-förfrågningar tillåts testas i CI-infrastrukturen utan separat verifiering. För att uppnå aktiv utvecklarstatus inkluderade experimentet mindre kosmetiska ändringar för att korrigera stavfel i dokumentationen. För att få tillgång till förvaret och lagringen av PyTorch-utgåvor, fångade attacken medan koden kördes i "Self-Hosted Runner" GitHub-tokenen som användes för att komma åt förvaret från byggprocesser, såväl som AWS-nycklarna som användes för att spara byggresultaten .
Problemet är inte specifikt för PyTorch och påverkar många andra stora projekt som använder standardinställningarna för "Self-Hosted Runner" i GitHub Actions. Till exempel nämndes implementeringen av liknande attacker för att installera en bakdörr i några stora kryptovaluta-plånböcker och blockchain-projekt med en miljarddollarkapitalisering, göra ändringar i utgåvorna av Microsoft Deepspeed och TensorFlow, kompromissa med en av CloudFlare-applikationerna och även köra kod på en dator i Microsofts nätverk. Detaljer om dessa incidenter har ännu inte avslöjats. Under befintliga bug-bounty-program har forskare skickat in mer än 20 ansökningar om belöningar värda flera hundra tusen dollar.
Källa: opennet.ru