PyTorch logotyp
Nyligen sdetaljer om en attack släpptes att infrastrukturen som användes vid utvecklingen av ramverket för maskininlärning blev lidande PyTorch. Bland de tekniska detaljerna som avslöjas nämns det att Angriparen lyckades extrahera åtkomstnycklar som tillät dig att lägga in godtycklig data i GitHub- och AWS-förvaret, ersätta kod i förvarets huvudgren och lägga till en bakdörr via beroenden.
Den här incidenten utgör betydande risker, eftersom spoofing av PyTorch-versioner kan användas för att attackera stora företag som Google, Meta, Boeing och Lockheed Martin, som använder PyTorch i sina projekt.
För fyra månader sedan utnyttjade Adnan Khan och jag en kritisk CI/CD-sårbarhet i PyTorch, en av världens ledande maskininlärningsplattformar. Används av titaner som Google, Meta, Boeing och Lockheed Martin, PyTorch är ett stort mål för både hackare och nationalstater.
Lyckligtvis utnyttjade vi denna sårbarhet innan skurkarna gjorde det.
Så här gjorde vi det.
Angående attacken nämns att detta Det handlar om möjligheten att köra 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 externa "Self-Hosted Runner"-drivrutiner med GitHub Actions. Till skillnad från traditionella GitHub-åtgärder, körs inte självvärdade kontroller på GitHub-infrastruktur, utan på sina egna servrar eller på virtuella maskiner som underhålls av utvecklare.
Genom att köra bygguppgifter på dina servrar kan du organisera frigivningen av kod som kan skanna ett företags interna nätverk, söka i den lokala FS efter krypteringsnycklar och åtkomsttokens och analysera miljövariabler med parametrar för att komma åt extern lagring eller molntjänster och med detta, genom dessa drivrutiner kunde angriparen utföra kompileringsuppgifter på sina egna servrar, vilket gjorde det möjligt för dem att skanna ett företags interna nätverk för att söka efter krypteringsnycklar och åtkomsttokens.
I PyTorch och andra projekt som använder Self-Hosted Runner, den Utvecklare kan köra byggjobbn först efter att dina ändringar har granskats. dock, lyckades angriparen kringgå detta system genom att först skicka en mindre ändring och sedan, när den väl accepterats, fick automatiskt statusen "samarbetspartner" vilket tillät dig att köra kod i vilken GitHub Actions Runner-miljö som helst som är associerad med arkivet eller den övervakande organisationen. Under attacken fångades GitHub-åtkomstnycklar och AWS-nycklar, vilket gjorde att angriparen kunde äventyra infrastrukturen.
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 får statusen som en aktiv deltagare. vars pull-förfrågningar kan testas i CI-infrastrukturen utan separat verifiering. För att uppnå aktiv utvecklarstatus inkluderade experimentet mindre kosmetiska ändringar för att åtgärda stavfel i dokumentationen. För att få tillgång till förvaret och lagringen av PyTorch-versioner, under en attack vid exekvering av kod i "Self-Hosted Runner", fångades GitHub-tokenen som användes för att komma åt förvaret från byggprocesserna (GITHUB_TOKEN tillät skrivåtkomst ), liksom som AWS-nycklarna som är involverade i att spara byggresultaten.
Som sådan nämns det det här problemet är inte specifikt för PyTorch och påverkar andra stora projekt som använder standardkonfigurationer för "Self-Hosted Runner" i GitHub Actions.
Dessutom har möjligheten för liknande attacker mot kryptovaluta, blockchain, Microsoft Deepspeed, TensorFlow och andra projekt nämnts, med potentiellt allvarliga konsekvenser. Forskare har skickat in mer än 20 ansökningar till bug-bounty-program, efter belöningar värda flera hundra tusen dollar.
äntligen om du är det intresserad av att veta mer om detkan du kontrollera detaljerna i följande länk.