Tai pirmasis straipsnių serijos apie labiausiai paplitusias programinės įrangos tiekimo grandinės atakas epizodas: tas, kurios (piktnaudžiauja) viešuoju programinės įrangos komponentų registru, skirtu atvirojo kodo projektai įkelti artefaktus, kuriais būtų galima dalytis su kitais vartotojais. Kai kenkėjiški veikėjai ten paskelbia kenkėjišką programinę įrangą, naudodami registrą kaip kenkėjiškų programų platinimo priemonę, mes patiriame tiekimo grandinės ataką, kai aukos organizacijos įdiegia arba paleidžia užkrėstą programinės įrangos komponentą.
Kad būtų paprasčiau diskutuoti, kalbėsime apie programinės įrangos paketai:, trečiųjų šalių sukurti supakuoti komponentai. Tai apima ne tik komponentus, kuriuos naudoja paketų tvarkyklės, tokios kaip NPM ar Poetry, bet ir operacinės sistemos komponentai įskaitant bibliotekas ir vykdomuosius dvejetainius failus, konteinerio vaizdai, ir virtualios mašinos arba įrankių plėtiniai kūrimo, kompiliavimo ir diegimo įrankiams. Kenkėjiškų paketų matėme visur. Kibernetiniams nusikaltėliams tai netrukdo: juos džiugina šiuolaikinių programinės įrangos infrastruktūrų teikiamos alternatyvos ir jie naudoja registrą bei įrankį, kuris geriausiai atitinka jų ketinimus. Todėl nepamirškite, kad programinės įrangos paketai yra konteinerių atvaizdų, dvejetainių paketų, atvirojo kodo saugyklų ir visų rūšių plėtinių ar papildinių (IDE, ...) santrumpa. CI/CD sistemos, kūrimo įrankiai). Visos jos nuolat patiria atakas.
Serialas turės 5 epizodus:
- Kokia yra atvirojo kodo paketų problema? Šio įrašo tema. Kodėl visokie nusikaltėliai skelbia kenkėjiškus paketus? Kodėl turėčiau nerimauti?
- Kenkėjiškų paketų anatomija: kokios yra tendencijos? Šioje laidoje daugiausia dėmesio skirsime grėsmei, kurią kasdien stebime naudodami savo MEW sistemą. Dėl didelio skaičiaus kenkėjiškų paketų, naudojančių tipografijos klaidas ar priklausomybių painiavą, foninis triukšmas yra didelis, todėl mažesnė atakų dalis yra daug klastingesnės ir kelia didesnę riziką. Kaip pastaruoju metu pasikeitė kenkėjiškų veikėjų elgesys, susijęs su OS? Kokie yra skaičiai? Kokia yra naudojama taktika, metodai ir procedūros, ir kokie žalingi veiksmai pastebėti?
- Apsauga nuo atvirojo kodo kenkėjiškų paketų: kas veikia (neveikia)Dauguma saugumą išmanančių specialistų turi idėjų, kaip elgtis su šia grėsme. Esame girdėję saugumo vadovus nedvejojant sakant, kad... SCA Įrankiai jau nurodo, kada paketo versija yra kenkėjiška. Arba kad jie priklauso nuo gerai žinomų, kruopščiai peržiūrimų programinės įrangos komponentų, kuriuose bet kokia kenkėjiška programa būtų greitai aptikta ir pašalinta. Jie teigia, kad naudoja atviras nepilnavertes / pataisų versijas, kad automatiškai gautų pažeidžiamumų taisymus, ir tai yra tinkamas, rekomenduojamas būdas sumažinti atvirojo kodo priklausomybių riziką, laikantis principo „pataisykite anksti, pataisykite dažnai“. Šioje laidoje apžvelgsime, kodėl šios idėjos yra klaidingos ir kaip tokios klaidingos nuomonės prisideda prie šio atakų mechanizmo populiarumo ir didžiulės rizikos, kurią patiria organizacijos. Pabaigoje aptarsime, kas veikia ir kokios pastangos bei ištekliai reikalingi.
- Atvirojo kodo kenkėjiški paketai: „Xygeni“ metodasŠiame epizode pristatome, kokią strategiją „Xygeni“ taiko savo kenkėjiškų programų ankstyvojo įspėjimo (MEW) sistemai. Kaip ši daugiapakopė sistema veikia realiuoju laiku, kai publikuojama nauja paketo versija, kaip renkami įrodymai iš skirtingų šaltinių, kaip atliekamas triažas, kokiais klasifikavimo kriterijais vadovaujamės ir kodėl vis dar reikalinga rankinė analizė, siekiant patvirtinti kenkėjiško paketo pobūdį? Kaip mūsų vidaus ir registro komandų atsiliepimai padeda sistemai mokytis iš anksčiau surinktų įrodymų, kad būtų kuo mažiau klaidingų teigiamų rezultatų. Taip pat paaiškinsime, kaip padedame NPM, „GitHub“, „PyPI“ ir kitoms pagrindinėms atvirojo kodo ekosistemų infrastruktūroms sutrumpinti jų veikimo laiką..
- Atvirojo kodo išnaudojimas: ko tikėtis iš blogiukųSerija baigiasi daugiausia dėmesio skiriant naujausiems priešininkų veiksmams, kuriais siekiama, kad atakos būtų nepastebimos, sunkiau aptinkamos, labiau nukreiptos į konkrečias pramonės šakas ir išgautų daugiau naudos iš šios klasės atakų. Ar išpirkos reikalaujančios programinės įrangos atakos bus vykdomos naudojant šią priemonę? Kaip blogiukai naudoja dirbtinio intelekto įrankius, kad pateiktų sudėtingesnius kenkėjiškus paketus? Ar populiariausiems projektams gresia pavojus? Tai skirta suteikti skaitytojams supratimą apie šias ginklavimosi varžybas ir ko tikėtis trumpuoju laikotarpiu (2024 m. antroje pusėje) ir vidutinės trukmės laikotarpiu (2025 m.). Sužinosime, kaip tokios atakos kaip pastarojo meto... XZ-Utils galinės durys, arba išpuolis prieš gyvenant iš savo ūkių elektronų kūrėjas 2024 m. kovo mėn. įvykiai rodo, kad turėtume budriai stebėti, kaip keičiasi priešininkai.
Pradėkime sceną nuo pirmojo epizodo: Kas vyksta su kenkėjiškais atvirojo kodo atvirojo kodo paketais?
Kokia yra atvirojo kodo paketų problema?
Pastaraisiais metais įvairiausi nusikaltėliai naudojo atvirojo kodo atvirojo kodo programinės įrangos registrus kenkėjiškai veiklai vykdyti. Ši veikla tokia pat sena kaip ir atvirojo kodo programinė įranga, tačiau per pastaruosius trejus metus jos dažnumas smarkiai išaugo.
Kenkėjiškų komponentų publikavimas viešuosiuose registruose (priklausomybėmis pagrįstos atakos) yra asimetrinis partizaninis karas, kurį grėsmių veikėjai naudoja kenkėjiškoms programoms platinti, pasinaudodami organizacijų pasitikėjimu atvirojo kodo komponentais, gautais iš nežinomų kūrėjų (prisiminkite priklausomybės xkcd komiksas?). Kadangi pasitikite paketais ir jums netrukdo rankiniu būdu peržiūrėti paketų turinį ir jų priklausomybes, šios atakos yra nepaprastai veiksmingos. Asimetrija atsiranda todėl, kad jas galima daugiausia automatizuoti, o blogiukams nereikia tiesiogiai bendrauti su auka. Jie tiesiog įkelia paketą į viešąjį registrą ir jį paleidžia.
Kenkėjiški paketai išaugo 6 kartus 2022 m.ir 2023 m. toliau augo 2.5 karto. Praėjusiais metais buvo aptikta net 245 000 kenkėjiškų paketų – tai daugiau nei dvigubai daugiau nei bendras ankstesnių metų skaičius. Tai eksponentinis augimas! Nuo šimtų paketų pašalinimo kaip patvirtintos kenkėjiškos programos 2021 m. ir tūkstančių 2022 m. matėme daug daugiau foninio „triukšmo“ 2023 m., o šiais metais tempas buvo panašus. Ir paslėpta šiame fone, kurį sukėlė nepatyrę kibernetiniai nusikaltėliai, einantys „mažiausio pasipriešinimo keliu“, nedidelė dalis didelio atgarsio sulaukusių atakų pasiekė antraštes net ir bendrojoje žiniasklaidoje.
Kodėl ši problema yra tokio masto? Yra per didelis pasitikėjimas visoje grandinėje. Atvirojo kodo programinė įranga platinama kartu su jos šaltinio kodu ir išleidžiama pagal tam tikrą licenciją. Taip, bet kas gali patikrinti šaltinio kodą; bet kas tai daro apskritai? Kas, patikrinęs, ar programinėje įrangoje nėra kenkėjiškų programų, kuria programinę įrangą iš šaltinio kodo? Kas, prieš perduodamas supakuotą komponentą (dar vadinamą paketas) pasroviui iki paketų tvarkyklės arba kūrimo įrankio, užtikrina, kad paketas nebūtų užkrėstas kenkėjiška programine įranga ir atitiktų tariamą šaltinio kodą, iš kurio jis turėtų būti?
Kodėl infrastruktūra leidžia tokias lengvas atakas?
Paketų registrai yra atviri, dažnai reikalaujantys minimalaus leidėjo tapatybės patvirtinimo. „Kiekvienas gali čia publikuoti savo programinę įrangą!“ Užpuolikams keliami žemi reikalavimai: jie naudoja vienkartinius el. pašto adresus ir vienkartines „GitHub“ paskyras, kad sukurtų šimtus kenkėjiškų paketų trumpose, sukčiavimo apsimetant kampanijose. Tik tikslinėms kampanijoms reikalingas didesnis rafinuotumas: matėme net patikimos „GitHub“ šaltinio saugyklos su daugybe žvaigždžių sukūrimą ir commitiš daugybės netikrų bendraautorių ir kitų populiarumo bei priežiūros rodiklių. Gauti žvaigždžių stebėtojai ir reputacija dėl netikrų įnašų nėra sunku automatizuoti. Pastebėjome įvairių rūšių atviros programinės įrangos infrastruktūrų piktnaudžiavimo atvejus, ne tik kenkėjiškas programas, pvz., Arbatos protokolo incidentas.
Paketų tvarkyklės buvo sukurtos patogumui naudoti, o ne saugumui.Jie gali paleisti prieš diegimą ir po jo vykdomus scenarijus (kartais reikia sukompiliuoti bibliotekos kodą). Be to, Paketo valdytojai diegia paketus iš kelių šaltinių, o kartais pagal numatytuosius nustatymus naudojami viešieji registrai. Jie netikrino, ar nėra neatitikimų tarp metaduomenų publikavimo užklausoje ir pačiame pakete.
Priklausomybės yra įdėtos ir sudaro grafą. Tam tikrose ekosistemose, tokiose kaip „Node“ („JavaScript“), smulkiagrūdžių priklausomybių kaupiasi šimtais ar tūkstančiais. Vienas dalykas yra griežtai kontroliuoti tiesiogines priklausomybes, kurias deklaruoja mano programinės įrangos projektai, bet... tranzitinės priklausomybės yra sunkiau kontroliuojami. Atvirojo kodo programinė įranga sekė principu „mano draugų draugai yra mano draugai“. Brolystė yra norma laukiniuose Tolimuosiuose Rytuose! Grėsmių veikėjai tai žino ir giliai slepia kenkėjišką elgesį neaiškiose priklausomybėse, kurios dažnai nežinomos. Taip buvo su... įvykių srautas incidentas, nukreiptas į „Copay“ piniginė.
Taip atvirojo kodo programinė įranga veikė nuo pat jos atsiradimo. Tai daug nepasikeis. Kai kurie paketų registrai reikalauja dviejų veiksnių autentifikavimo ir dažnai tik populiariausiems paketams. Kai kurie registrai teikia taikymo sritis – patikrintos organizacijos vardų erdvę, bet... tragiškai kiti to nepalaiko (PyPI) arba daro jį neprivalomu (NPM). Įdomu pastebėti, kad net ir paprasta atrankos schema (remiantis DNS arba „GitHub“ saugyklos / organizacijos, atitinkančios grupės ID, valdymu) ir sudarymu PGP parašai privalomi visiems artefaktams, išskyrus kontrolines sumas, pašalina didžiąją dalį „triukšmo“, į spausdinimo klaidas panašių kenkėjiškų paketų ir apriboja didelę dalį priklausomybės painiavaSudėtingos atakos yra įmanomos, bet daug sunkesnės, tokių kaip... com.github.codingandcoding:maven-compiler-plugin žinomas dėl „Maven Central“. Ir ne visi „Maven“ registrai laikosi tos pačios praktikos!
Paketų tvarkyklių saugumo kontrolė gali apsunkinti, bet netrukdyti priklausomybių atakoms. Daugiafaktorinio autentifikavimo problema yra ta, kad automatizavimui iš automatizavimo scenarijų atliekamuose APIapi skambučiuose paskyroms generuojami išvestiniai prisijungimo duomenys, pvz., prieigos žetonai arba APIapi raktai, be jokio interaktyvaus vartotojo, kuris teiktų antrą veiksnį. Daugiafaktorinis autentifikavimas yra naudingas vartotojų paskyroms apsaugoti nuo slaptažodžių nutekėjimo, tačiau sugeneruotus prieigos žetonus arba APIapi raktus reikia apsaugoti, kol jie aktyvūs, kitaip priešininkai apsimes jų savininku. Didelė dalis paketų pagrindu sukurtų tiekimo grandinės kampanijų prasideda nuo nutekėjusio rakto / žetono. Tiesiog nepamirškite tokių incidentų kaip buhalterijos didžioji knyga, 3CXir daugelyje kitų atvejų, kai neinteraktyvūs prisijungimo duomenys pirmą kartą buvo pavogti atliekant preliminarų įsilaužimą, siekiant pradėti tiekimo grandinės ataką.
Į šią grėsmę nebuvo pakankamai tvirtai reaguojama. Trečiajame epizode daugiausia dėmesio skirsime tam, kas pasiteisino, o kas visiškai nepasiteisino. Pramonė turi dirbti kartu, kad... standards, procesai, mokymai ir įrankiai, skirti pasaulinių tiekimo grandinių rizikai sušvelninti. Tai nėra problema, kurios viena organizacija gali išspręsti pati.
Šią dalį užbaigsime esminiu nesusipratimu: kalbame apie tyčinis paketai, o ne pažeidžiamas Pažeidžiamumai atsiranda dėl projektavimo ar kodavimo klaidų, atsitiktinai įvestų be blogų ketinimų. Pažeidžiamumais galima pasinaudoti, bet daugelis jų nėra. Kenkėjiški paketai visada yra tyčiniai, ir juos įvykdžius, išnaudojimo tikimybė yra 100 %. Nėra panašios rizikos! Todėl... Paradoksalu matyti, kiek pastangų dedama pažeidžiamumų aptikimui ir jų šalinimui, ir kaip trūksta lygiaverčių priemonių kenkėjiškiems komponentams..
„Mes rimtai žiūrime į saugumą“
Įsivaizduokime įprastą. Acme korporacija„Acme“, pagrindinė „WileCoyote.com“ tiekėja, didžiąją dalį savo programinės įrangos gauna iš trečiųjų šalių, o daugiau nei 80 % – iš atvirojo kodo projektų. Jie kuria programinę įrangą vidiniam naudojimui, tačiau taip pat teikia programinę įrangą savo partneriams, tiekėjams ir klientams / galutiniams vartotojams. „Acme“ turi programinę įrangą, parašytą „Go“, „JavaScript“, „Java“, „C#“ ir „Python“ kalbomis, ir didžiąją dalį savo programinės įrangos veikia debesyje, „Kuberneteskubernetes“ klasteriuose. „Acme“ kuria savo pasirinktinius atvaizdus iš bazinių atvaizdų, paimtų iš „Docker Hub“ ir kitų registrų. Jie taip pat dalijasi keliomis bibliotekomis, paketais ir konteinerių atvaizdais viešuosiuose registruose.
„Acme“ rimtai žiūri į saugumą. Jie puikiai supranta šią problemą. open source securityir su tuo susijusią riziką. Visi kūrėjai, sistemų valdytojai ir „DevOps“ inžinieriai naudoja tuos mielus mažus kriptografinius raktus kaip antrojo faktoriaus autentifikavimą. Visi commitkodo saugyklos yra pasirašytos, įjungta šakos apsauga su privalomomis kodo peržiūromis, CI/CD užrakinti, slapti duomenys saugomi slaptoje saugykloje, o vidinis registras iš dalies atkartoja išorinius registrus, kuriuose saugomi tik leistini, baltajame sąraše esantys komponentai. Reikalaujama, kad „Acme“ sukurta programinė įranga perimtų trečiųjų šalių priklausomybes iš šio registro.
Tikriausiai dauguma organizacijų atitinka šį profilį. Mieli skaitytojai, jūsų profilis tikrai tinka, jei jau esate čia, ar ne?
Tada vieną nelaimingą dieną svarbus front-end kūrėjas „Acme“ bėgo npm įdiegti acme-cute-lib, pamirštant, kad @acme/cute-lib buvo tinkama apimties priklausomybė. Tiksli klaida nėra svarbi, daug kas gali nutikti ne taip, net jei manoma, kad programinės įrangos gyvavimo ciklas yra visiškai kontroliuojamas. Mūsų kūrėjas nežinojo, kad APT grupė taikosi į „Acme“, ir gudriai paskelbė kenkėjišką komponentą tuo pavadinimu, todėl kenkėjiškas elgesys suaktyvėja tik tada, kai programinė įranga įdiegiama „Acme“ kompiuteriuose. Paketas nebuvo aptiktas kelias savaites po jo paskelbimo.
Paleidžiamas diegimo scenarijus, kuris ieško kredencialų (mūsų kūrėjo nešiojamajame kompiuteryje buvo daug naudingų prieigos žetonų), suteikdamas prieigą prie vidinių programinės įrangos saugyklų ir jau minėtos vidinės saugyklos, prie kurios, žinoma, galima prisijungti tik per VPN. Kenkėjiškas kodas sugebėjo panaudoti esamą VPN ryšį ir į vidinį registrą įkelti antro etapo kenkėjišką komponentą, paveikdamas bendrą įrankių biblioteką, kuria naudojasi dauguma „Acme“ tiekiamos programinės įrangos.
Po kelių savaičių kitos organizacijos, naudodamos „Acme“ publikuotus įrankius, savo tinkluose pradėjo matyti keistą srautą, kuris naudojo „Acme“ protokolą, bet buvo nukreiptas į pagrindinius kompiuterius, panašius į „Acme“ domeną. Srautas buvo užšifruotas, tačiau sistemos stebėjimo įrankiai aptiko prieigą prie netikėtų failų ir procesų, kurie atrodo kaip sistemos komandos, bet galiausiai paleidžia atsisiųstus vykdomuosius failus, vykdymo.
Visa kita – istorija: „Acme“ iš pradžių neigė, kad toks elgesys yra jų kaltė ir kad buvo imtasi visų saugumo priemonių. Tik po to, kai kibernetinio saugumo žiniasklaida pradėjo klausinėti, kodėl aptikto elgesio šaltinis yra „Acme“ komponentai, o saugumo analizė paskelbė, kaip šie komponentai buvo užkrėsti slapta kenkėjiška programine įranga, „Acme“ turėjo pripažinti incidentą ir iškviesti incidentų valdymo įmonę. Neigiama rinkodaros kampanija, kuri akimirksniu pakenkė sunkiai užsitarnautam pasitikėjimui.„Acme“ buvo vos vieno npm įdiegimo atstumu nuo disaster„buvo dažna antraštė. Vėliau sekė teisminiai ieškiniai ir nutrauktos sutartys.
Ar matote panašumų su žinomais praeities incidentais? „Acme“ tiekimo grandinės incidentas įvyko dviem etapais, naudojant įvairius priklausomybės painiava / rašybos klaidos atakos, kurių metu kūrėjo darbo vieta buvo naudojama kaip placdarmas užkrėsti komponentus, kurie galiausiai patekdavo į trečiųjų šalių naudojamą programinę įrangą. Kaip būtų galima to išvengti arba sušvelninti?
Kodėl užnuodytos pakuotės tokios populiarios
Šis hipotetinis incidentas rodo, kad net ir taikant pagrįstą požiūrį į atvirojo kodo saugumą, organizacijoms reikia konkrečių priemonių, kad išvengtų kenkėjiškų programų, esančių atvirojo kodo komponentuose, aukomis. Schemiškai grėsmės veikėjas gali:
- Sukurkite naują paketą (vadovaudamiesi gerai žinomais klaidų iškraipymo ar priklausomybių painiavos būdais, tai yra dažniausiai pasitaikantis kelias, kurį blogiukai naudoja pagal apimtį);
- Pabandykite užkrėsti esamą, įterpdami jį į šaltinio kodą arba bandydami jį užmaskuoti kaip bendraautorį per pull requestarba pasitelkiant socialinę inžineriją, kad taptų palaikytoju (kaip „Jao Tan“ padarė „XZ Backdoor“ arba dešinysis 9valdiklis „GitHub“ vartotojas atliko įvykių srautas incidentas 2018 m. rudenį) arba gaudami atvirojo kodo saugyklos prisijungimo duomenis ir apsimesdami prižiūrėtoju;
- Įterpti kenkėjišką programinę įrangą paketo kūrimo metu, paleisdami kenkėjišką kūrimo scenarijųarba trukdo paketų atsisiuntimui naudojant „man-in-the-middle“ perėmimus (laimei, TLS dabar visada reikalingas daugumoje registrų).
- Įterpkite supakuotą komponentą tiesiai į registrą, paprastai užfiksuodami registro kredencialus (pageidaujama alternatyva daugeliui sudėtingų atakų, tokių kaip „Acme“, kai pažeista darbo stotis pirmajame etape turėjo vidinį registro prieigos raktą, pvz., įprastu būdu). .NS or ~/.m2/nustatymai.xml(blogi veikėjai žino, kur ieškoti paslapčių). Taip pat buvo išnaudotos registrų pažeidžiamos vietos.
Registrų užkrėtimas kenkėjiška programine įranga yra priklausomybės atakų pagrindas. Nieko naujo po saule: paplitimas smarkiai išaugo, tačiau tie patys metodai veikia dabar, kaip ir prieš penkerius metus.
šaltinis: „Backstabber's Knife“ kolekcija.
Kenkėjiškas paketas gali veikti diegimo, programinės įrangos kūrimo arba vykdymo metu. Jo elgesys svyruoja nuo informacijos nutekėjimo, pvz., paslapčių išgavimo antrajam bandymo etapui, iki šaltinio kodo išgavimo ir papildomos kenkėjiškos programos pateikimo. Kitame epizode analizuosime kenkėjiškus paketus ir kaip jie publikuojami.
Toliau skaitykite
Kitas epizodas Kenkėjiškų paketų anatomija: kokios yra tendencijos? daugiausia dėmesio skirsime realiems atvejams, kuriuos stebime naudodami savo kenkėjiškų programų ankstyvojo įspėjimo sistemą, kiekvieną dieną. Apžvelgsime, kokio tipo kenkėjiškos programos buvo pastebėtos ir kokia taktika, metodai ir procedūros yra mėgstamiausios. Išnagrinėsime klaidinimą ir kaip jie bando pasislėpti nuo potencialių recenzentų, apėjimo metodus, siekiant išvengti aptikimo, ir kaip jie vystosi atsižvelgiant į telemetriją ir horizontalią judėjimo kryptį. Sekite naujienas!
Nuorodos
- „Backstabber's Knife“ kolekcija: atvirojo kodo programinės įrangos tiekimo grandinės atakų apžvalgaM. Ohm ir kt., 2020 m. gegužė.
- Atvirojo kodo kenkėjiškų programų apsauga„Xygeni“ informacinis dokumentas.
- Software Supply Chain Security Retrospektyva: Saugesnio 2024-ųjų formavimasPranešimas iš Xygeni.
