PyTorch logotipas
Neseniai sbuvo paskelbta išsami informacija apie išpuolį kad nukentėjo kuriant mašininio mokymosi sistemą naudojama infrastruktūra „PyTorch“. Tarp atskleistų techninių detalių minima, kad Užpuolikui pavyko išgauti prieigos raktus kuri leido įdėti savavališkus duomenis į „GitHub“ ir AWS saugyklą, pakeisti kodą pagrindinėje saugyklos šakoje ir pridėti užpakalines duris per priklausomybes.
Šis įvykis kelia didelę riziką, nes PyTorch versijų klastojimas gali būti panaudotas atakuojant dideles įmones, tokias kaip Google, Meta, Boeing ir Lockheed Martin, kurios savo projektuose naudoja PyTorch.
Prieš keturis mėnesius Adnanas Khanas ir aš išnaudojome kritinį CI / CD pažeidžiamumą PyTorch, vienoje iš pasaulyje pirmaujančių mašininio mokymosi platformų. Naudojamas titanų, tokių kaip Google, Meta, Boeing ir Lockheed Martin, PyTorch yra pagrindinis įsilaužėlių ir nacionalinių valstybių taikinys.
Laimei, pasinaudojome šiuo pažeidžiamumu anksčiau nei blogi vaikinai.
Štai kaip mes tai padarėme.
Kalbant apie išpuolį, minima, kad š Tai priklauso nuo galimybės paleisti kodą nuolatinės integracijos serveriuose kurios atlieka atkūrimą ir vykdo užduotis, kad išbandytų naujus saugyklos pakeitimus. Problema turi įtakos projektams, kuriuose naudojamos išorinės „Self-Hosted Runner“ tvarkyklės su „GitHub Actions“.. Skirtingai nuo tradicinių GitHub Actions, savarankiškai priglobti valdikliai veikia ne GitHub infrastruktūroje, o savo serveriuose arba kūrėjų prižiūrimose virtualiose mašinose.
Vykdydami kūrimo užduotis savo serveriuose galite organizuoti kodo, kuris gali nuskaityti įmonės vidinį tinklą, išleidimą, vietinėje FS ieškoti šifravimo raktų ir prieigos prieigos raktų ir analizuoti aplinkos kintamuosius su parametrais, kad galėtumėte pasiekti išorinę saugyklą ar debesies paslaugas, ir taip, per šias tvarkykles užpuolikas galėjo atlikti kompiliavimo užduotis savo serveriuose, o tai leido nuskaityti įmonės vidinį tinklą ir ieškoti šifravimo raktų ir prieigos prieigos raktų.
„PyTorch“ ir kituose projektuose, kuriuose naudojamas „Self-Hosted Runner“, The Kūrėjai gali vykdyti kūrimo darbusn tik peržiūrėjus pakeitimus. Tačiau, užpuolikas sugebėjo apeiti šią sistemą, pirmiausia išsiuntęs nedidelį pakeitimą ir tada, kai sutiko, automatiškai gavo „bendradarbio“ statusą kuri leido paleisti kodą bet kurioje „GitHub Actions Runner“ aplinkoje, susietoje su saugykla arba prižiūrinčia organizacija. Per ataką buvo perimti „GitHub“ prieigos raktai ir AWS raktai, todėl užpuolikas galėjo pažeisti infrastruktūrą.
Paaiškėjo, kad nuorodą į „bendrautojo“ būseną buvo lengva apeiti: pakanka iš pradžių pateikti nedidelį pakeitimą ir palaukti, kol jis bus priimtas į kodų bazę, o po to kūrėjas automatiškai gauna aktyvaus dalyvio statusą. kurių ištraukimo užklausas galima išbandyti CI infrastruktūroje be atskiro patikrinimo. Norint pasiekti aktyvaus kūrėjo būseną, eksperimente buvo atlikti nedideli kosmetiniai pakeitimai, siekiant ištaisyti rašybos klaidas dokumentacijoje. Norint gauti prieigą prie „PyTorch“ versijų saugyklos ir saugyklos, atakos metu, kai vykdomas kodas „Self-Hosted Runner“, taip pat buvo perimtas „GitHub“ prieigos raktas, naudojamas prieigai prie saugyklos iš kūrimo procesų (GITHUB_TOKEN leido rašyti). kaip AWS raktai, susiję su kūrimo rezultatų išsaugojimu.
Kaip tokia, minima ši problema nėra būdinga PyTorch ir turi įtakos kitiems dideliems projektams kurios naudoja numatytąsias „Self-Hosted Runner“ konfigūracijas „GitHub Actions“.
Be to, buvo paminėta panašių atakų prieš kriptovaliutą, „blockchain“, „Microsoft Deepspeed“, „TensorFlow“ ir kitus projektus galimybė, kurios gali turėti rimtų pasekmių. Tyrėjai pateikė daugiau nei 20 paraiškų klaidų kompensavimo programoms, siekdami kelių šimtų tūkstančių dolerių vertės atlygio.
pagaliau jei esi domina sužinoti daugiau apie tai, išsamią informaciją galite patikrinti sekanti nuoroda.