Detaljer om angrebet på den infrastruktur, der blev brugt i udviklingen af PyTorchs maskinlæringsramme, blev afsløret, hvilket gjorde det muligt at udtrække adgangsnøgler, der var tilstrækkelige til at placere vilkårlige data i depotet med projektudgivelser på GitHub og AWS, samt at erstatte kode i depotets hovedgren og tilføje en bagdør gennem afhængigheder. PyTorch release spoofing kunne bruges til at angribe store virksomheder som Google, Meta, Boeing og Lockheed Martin, der bruger PyTorch i deres projekter. Som en del af Bug Bounty-programmet betalte Meta forskere $16250 for information om problemet.
Essensen af angrebet er evnen til at køre din kode på kontinuerlige integrationsservere, der udfører genopbygninger og kører job for at teste nye ændringer sendt til lageret. Problemet påvirker projekter, der bruger deres egne eksterne "Self-Hosted Runner"-handlere med GitHub Actions. I modsætning til traditionelle GitHub-handlinger, kører Self-Hosted-handlere ikke på GitHub-infrastrukturen, men på deres egne servere eller i udviklervedligeholdte virtuelle maskiner.
Udførelse af monteringsopgaver på dine servere giver dig mulighed for at organisere lanceringen af kode, der kan scanne det interne netværk i en virksomhed, søge i den lokale FS efter krypteringsnøgler og adgangstokens og analysere miljøvariabler med parametre for adgang til ekstern lagring eller cloud-tjenester. I mangel af korrekt isolering af assemblermiljøet kan fundne fortrolige data sendes eksternt til angribere, for eksempel gennem adgang til eksterne API'er. For at bestemme brugen af Self-Hosted Runner af projekter, kan Gato-værktøjssættet bruges til at analysere offentligt tilgængelige workflowfiler og CI-opgavestartslogfiler.
I PyTorch og mange andre projekter, der bruger Self-Hosted Runner, er det kun udviklere, hvis ændringer tidligere er blevet peer-reviewed og inkluderet i projektets kodebase, der har lov til at køre byggejobs. At have "bidragyder"-status, når du bruger standardindstillingerne i repository, gør det muligt at starte GitHub Actions-handlere, når du sender pull-anmodninger og følgelig udføre din kode i ethvert GitHub Actions Runner-miljø, der er knyttet til repository eller organisationen, der overvåger projektet.
Linket til "bidragyder"-status viste sig at være let at omgå - det er nok først at indsende en mindre ændring og vente på, at den blev accepteret i kodebasen, hvorefter udvikleren automatisk modtog status som en aktiv deltager, hvis pull-anmodninger har tilladelse til at blive testet i CI-infrastrukturen uden separat verifikation. For at opnå aktiv udviklerstatus inkluderede eksperimentet mindre kosmetiske ændringer for at rette tastefejl i dokumentationen. For at få adgang til lageret og lagringen af PyTorch-udgivelser, opsnappede angrebet, mens koden blev eksekveret i "Self-Hosted Runner", GitHub-tokenet, der blev brugt til at få adgang til depotet fra byggeprocesser, samt AWS-nøglerne, der blev brugt til at gemme byggeresultaterne .
Problemet er ikke specifikt for PyTorch og påvirker mange andre store projekter, der bruger standardindstillingerne for "Self-Hosted Runner" i GitHub Actions. For eksempel blev implementeringen af lignende angreb nævnt for at installere en bagdør i nogle store cryptocurrency tegnebøger og blockchain-projekter med en milliard-dollar kapitalisering, foretage ændringer i udgivelserne af Microsoft Deepspeed og TensorFlow, kompromittere en af CloudFlare-applikationerne og også eksekvere kode på en computer på Microsoft-netværket. Detaljer om disse hændelser er endnu ikke blevet offentliggjort. Under eksisterende bug bounty-programmer har forskere indsendt mere end 20 ansøgninger om belønninger til en værdi af flere hundrede tusinde dollars.
Kilde: opennet.ru