Angreb på PyTorch-infrastrukturen, der kompromitterer repository og udgivelser

Detaljer om angrebet på infrastrukturen, der anvendes til udviklingen af maskinlæringsrammen PyTorch, er blevet afsløret. Dette angreb gjorde det muligt at udtrække adgangsnøgler, der var tilstrækkelige til at indsætte vilkårlige data i repository med projektets udgivelser på GitHub og AWS samt til at indsætte kode i hovedgrenen af repository og tilføje bagdøre via afhængigheder. Erstatning af PyTorch-udgivelser kunne anvendes til at udføre angreb på store virksomheder som Google, Meta, Boeing og Lockheed Martin, der bruger PyTorch i deres projekter. Som en del af Bug Bounty-programmet udbetalte Meta $16250 til forskere for information om problemet.

Kernen i angrebet er muligheden for at eksekvere sin kode på servere kontinuerlig integration, der udfører rekonstruktioner og kører opgaver for at teste nye ændringer, der sendes til repository. Problemet angår projekter, der bruger egne eksterne behandlere kaldet 'Self-Hosted Runner' med GitHub Actions. I modsætning til traditionelle GitHub Actions behandles Self-Hosted i ikke-GitHub-infrastruktur, men på egne servere eller i virtuelle maskiner, der understøttes af udviklerne.

Udførelse af byggeopgaver på egne servere muliggør kørsel af kode, som kan scanne virksomhedens interne netværk, søge i det lokale filsystem efter krypteringsnøgler og adgangsbilletter, samt analysere miljøvariabler med parametre til forbindelse til eksterne lagre eller cloud-tjenester. I mangel af ordentlig isolation af byggemiljøet kan de fundne fortrolige oplysninger sendes til angriberen, for eksempel ved adgang til eksterne API'er. For at identificere anvendelsen af projekter med 'Self-Hosted Runner' kan værktøjet Gato anvendes, som analyserer offentligt tilgængelige workflow-filer og logs fra CI-opgaver.

I PyTorch og mange andre projekter, der bruger "Self-Hosted Runner", er det kun udviklere, hvis ændringer tidligere er blevet gennemgået og inkluderet i projektets kodebase, der har tilladelse til at starte byggeopgaver. At have status som "contributor" ved brug af repositoryets standardindstillinger giver mulighed for at køre GitHub Actions-handlinger ved indsendelse af pull-anmodninger, og dermed udføre sin kode i ethvert miljø af GitHub Actions Runner, der er knyttet til repositoryet eller den organisation, der kuraterer projektet.

Binde status som "contributor" viste sig at være let at omgå - det var nok at sende en ubetydelig ændring og vente på, at den blev accepteret i kodebasen, hvorefter udvikleren automatisk fik status som aktiv deltager, hvis pull-anmodninger kunne testes i CI-infrastrukturen uden yderligere kontrol. For at få status som aktiv udvikler blev der i eksperimentet brugt ubetydelige kosmetiske ændringer relateret til at rette tastefejl i dokumentationen. For at få adgang til repositoryet og udgivelseslageret i PyTorch i forbindelse med angrebet blev der foretaget en opsnapning af en GitHub-token, der blev anvendt til at få adgang til repositoryet fra byggeprocesserne, samt AWS-nøgler, der blev brugt til at gemme resultaterne af bygningen.

Problemet er ikke specifikt for PyTorch og berører mange andre store projekter, der bruger standardindstillingerne for "Self-Hosted Runner" i GitHub Actions. For eksempel er der blevet nævnt gennemførelse af lignende angreb for at indsætte backdoors i nogle store kryptovaluta-tegnebogs- og blockchainprojekter med milliardkapitalisering, ændringer i udgivelserne af Microsoft Deepspeed og TensorFlow, kompromittering af en af CloudFlare's applikationer samt udførelse af kode på en computer i Microsofts netværk. Detaljer om disse hændelser afsløres endnu ikke. Inden for de aktuel bug bounty-programmer har forskere indsendt mere end 20 ansøgninger for at modtage belønninger på flere hundrede tusinde dollars.

Kilde: opennet.ru

Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere 🔥 Køb pålidelig webhosting med DDoS-beskyttelse, VPS VDS-servere | ProHoster