Ovo je prva epizoda u seriji članaka o najraširenijoj vrsti napada na lanac snabdijevanja softverom: onima koji (zlo)upotrebljavaju javni registar softverskih komponenti, namijenjenih za open-source projekti za postavljanje artefakata koji bi se mogli dijeliti s drugim korisnicima. Kada negativci objave zlonamjerni softver tamo, koristeći registar kao sredstvo za distribuciju zlonamjernog softvera, imamo napad lanca snabdijevanja kada organizacije žrtve instaliraju ili pokreću zaraženu softversku komponentu.
Da bismo pojednostavili diskusiju, govorit ćemo o softverski paketi:, komponente u zapakovanom obliku koje proizvode treće strane. Ovo uključuje ne samo komponente koje koriste upravitelji paketa poput NPM-a ili Poetryja, već i komponente operativnog sistema uključujući biblioteke i izvršne binarne datoteke, slike kontejnera, i virtuelne mašine, ili produžeci alata za alate za razvoj, izgradnju i implementaciju. Vidjeli smo zlonamjerne pakete svuda. Cyber kriminalcima to ne smeta: oduševljeni su alternativama koje pružaju moderne softverske infrastrukture i koriste registar i alat koji najbolje odgovara njihovoj namjeri. Stoga, imajte na umu da su softverski paketi skraćenica za slike kontejnera, binarne pakete, repozitorije otvorenog koda i ekstenzije ili dodatke svih vrsta (IDE-ove, CI/CD sistemi, alati za izgradnju). Svi su rutinski pod napadom.
Serija će imati 5 epizoda:
- U čemu je problem sa paketima otvorenog koda? Ovo je tema ovog posta. Zašto kriminalci svih vrsta objavljuju zlonamjerne pakete? Zašto bih trebao biti zabrinut?
- Anatomija zlonamjernih paketa: Koji su trendovi? U ovoj epizodi, fokusiramo se na prijetnju koju pratimo pomoću našeg MEW sistema, iz dana u dan. S velikom pozadinskom bukom zbog velikog broja zlonamjernih paketa koji koriste tiposquatting ili konfuziju zavisnosti, manji procenat napada je mnogo podmukliji i predstavlja veći rizik. Kako se ponašanje zlonamjernih aktera u vezi sa operativnim sistemima promijenilo u skorijoj prošlosti? Koji su brojevi? Koje su korištene taktike, tehnike i procedure, te koje su štetne radnje uočene?
- Zaštita od zlonamjernih paketa otvorenog koda: Šta (ne) funkcionišeVećina stručnjaka koji su svjesni sigurnosti imaju ideje o tome kako se nositi s ovom prijetnjom. Čuli smo menadžere sigurnosti kako bez oklijevanja kažu da SCA Alati vam već govore kada je verzija paketa zlonamjerni softver. Ili da se oslanjaju na dobro poznate, visoko ocijenjene softverske komponente, gdje bi svaki zlonamjerni softver bio odmah otkriven i uklonjen. Oni kažu da koriste otvorene manje verzije/zakrpe za automatsko dobijanje ispravki ranjivosti i da je to ispravan, preporučen način za smanjenje rizika od zavisnosti otvorenog koda, slijedeći princip "zakrpi rano, zakrpi često". U ovoj epizodi ćemo razmotriti zašto su ove ideje pogrešne i kako takve zablude doprinose popularnosti ovog mehanizma napada i ogromnom riziku koji organizacije doživljavaju. Završit ćemo s onim što funkcionira i koji su uloženi trud i resursi.
- Zlonamjerni paketi otvorenog koda: Xygeni pristupU ovoj epizodi predstavljamo strategiju koju slijedimo u Xygeniju za naš sistem ranog upozoravanja na zlonamjerni softver (MEW). Kako ovaj višestepeni sistem funkcioniše u realnom vremenu kada se objavi nova verzija paketa, kako se dokazi prikupljaju iz različitih izvora, kako se vrši trijaža, koje kriterije klasifikacije pratimo i zašto je ipak potrebna ručna analiza da bi se potvrdila priroda kandidata za zlonamjerni paket? Kako povratne informacije naših internih i registarskih timova pomažu sistemu da uči iz prethodno prikupljenih dokaza kako bi se lažno pozitivni rezultati sveli na minimum. Objasnit ćemo i kako pomažemo NPM-u, GitHubu, PyPI-ju i drugim ključnim infrastrukturama u ekosistemima otvorenog koda da smanje vrijeme zadržavanja..
- Iskorištavanje otvorenog koda: Šta očekivati od loših momakaSerija se završava fokusirajući se na najnovije akcije koje protivnici preduzimaju kako bi napade učinili prikrivenijim, težim za otkrivanje, usmjerenijim na određene industrije i kako bi iz ove klase napada izvukli više koristi. Hoće li se napadi ransomwarea izvoditi korištenjem ovog sredstva? Kako negativci koriste alate umjetne inteligencije za isporuku sofisticiranijih zlonamjernih paketa? Jesu li najpopularniji projekti u opasnosti? Ovo je da bi se čitateljima dao osjećaj o ovoj utrci u naoružanju i šta mogu očekivati u kratkoročnom (druga polovina 2024.) i srednjoročnom periodu (2025.). Naučit ćemo kako se napadi poput nedavnog... XZ-Utils Backdoorili napad na one koji žive od zemlje graditelj elektrona u martu 2024. pokazuju da bismo trebali biti budni i pratiti kako se protivnici razvijaju.
Otvorimo scenu prvom epizodom: Šta se dešava sa zlonamjernim paketima otvorenog koda?
U čemu je problem sa paketima otvorenog koda?
Posljednjih godina, kriminalci svih vrsta koristili su registre softvera otvorenog koda za isporuku zlonamjernog ponašanja. Ove aktivnosti su stare koliko i sam otvoreni kod, ali njihova učestalost je eksplodirala u posljednje tri godine.
Objavljivanje zlonamjernih komponenti u javnim registrima (napadi zasnovani na zavisnostima) je asimetrično gerilsko ratovanje koje akteri prijetnji koriste za distribuciju zlonamjernog softvera, iskorištavajući povjerenje koje organizacije imaju u komponente otvorenog koda koje dolaze od nepoznatih programera (sjetite se ovisnost xkcd strip?). Budući da vjerujete paketima i ne smeta vam ručno pregledati sadržaj paketa i njihove zavisnosti, ovi napadi su izuzetno efikasni. A asimetrija dolazi jer se mogu uveliko automatizirati i zlonamjernici ne moraju direktno komunicirati sa žrtvom. Oni jednostavno prenesu paket u javni registar i puste ga.
Zlonamjerni paketi porastao je 6 puta u 2022. godini, i nastavio je rasti 2.5 puta u 2023. Prošle godine viđeno je čak 245,000 zlonamjernih paketa, što je više nego dvostruko više od ukupnog broja iz prethodnih godina zajedno. Ovo je eksponencijalni rast! Od uklanjanja paketa kao potvrđenog zlonamjernog softvera u stotinama tokom 2021. i hiljadama tokom 2022. godine, vidjeli smo mnogo više pozadinske „buke“ tokom 2023. godine, sa sličnim tempom za ovu godinu. I skriveno u toj pozadini koju su uzrokovali nesofisticirani cyber kriminalci koji slijede „put najmanjeg otpora“, manjina visokoprofilnih napada dospjela je na naslovnice čak i u općim medijima.
Zašto je ovo problem tolikih razmjera? Postoji višak povjerenja duž cijelog lanca. Softver otvorenog koda distribuira se zajedno sa svojim izvornim kodom i objavljuje se pod određenom licencom. Da, svako može pregledati izvorni kod; ali ko to radi općenito? Ko, nakon što provjeri da softver nema zlonamjerni softver, gradi softver iz izvornog koda? Ko, prije nego što proslijedi zapakiranu komponentu (također poznatu kao paket) nizvodno do upravitelja paketa ili alata za izgradnju, osigurava da paket nije prepun zlonamjernog softvera i da odgovara navodnom izvornom kodu iz kojeg bi trebao doći?
Zašto infrastruktura omogućava tako jednostavne napade?
Registri paketa su otvoreni, često zahtijevajući minimalnu provjeru identiteta izdavača. „Svako je dobrodošao da ovdje objavi svoj softver!“ Ljetvica za napadače je postavljena nisko: koriste jednokratne email adrese i jednokratne GitHubgithub račune za kreiranje stotina zlonamjernih paketa u kratkim, phishing kampanjama. Samo za ciljane pakete potrebna je veća sofisticiranost: Vidjeli smo čak i kreiranje kredibilnog GitHub repozitorija izvornog koda s mnogo zvjezdica i commitod više lažnih saradnika i drugih metrika popularnosti i održavanja. Dobijanje zvijezde i reputacija od lažnih doprinosa nije teško automatizirati. Vidjeli smo zloupotrebe na otvorenim softverskim infrastrukturama svih vrsta, ne samo zlonamjernog softvera, poput incident s protokolom čaja.
Upravitelji paketa su dizajnirani za jednostavnost korištenja, a ne za sigurnost.Mogu pokretati skripte prije i poslije instalacije (ponekad je potrebno kompajlirati izvorni kod za biblioteku). Također, Upravljači paketima instaliraju pakete iz više izvora, a ponekad je podrazumijevano korištenje javnih registara. Nisu provjeravali neusklađenost između metapodataka u zahtjevu za objavljivanje i metapodataka u samom paketu.
Zavisnosti su ugniježđene i formiraju graf. U određenim ekosistemima poput Node-a (JavaScript), sitnozrnate zavisnosti se akumuliraju u stotinama ili hiljadama. Jedna stvar je imati strogu kontrolu nad direktnim zavisnostima koje deklarišu moji softverski projekti, ali tranzitivne zavisnosti teže ih je kontrolirati. Otvoreni kod slijedio je pravilo "prijatelji mojih prijatelja su moji prijatelji". Bratstvo je norma na divljem Dalekom istoku! Akteri prijetnji to znaju i duboko skrivaju zlonamjerno ponašanje u nejasnim ovisnostima koje su često nepoznate. To je bio slučaj sa tok događaja incident usmjeren na Novčanik s doplatom.
Ovako je softver otvorenog koda funkcionisao od svog nastanka. Neće se mnogo promijeniti. Neki registri paketa zahtijevaju u najboljem slučaju dvofaktorsku autentifikaciju, a često samo za najpopularnije pakete. Neki registri pružaju opsege, imenski prostor u vlasništvu provjerene organizacije, ali tragično drugi ga ne podržavaju (PyPI) ili ga čine opcionim (NPM). Zanimljivo je primijetiti da čak i jednostavna shema probira (na osnovu kontrole DNS-a ili GitHub repozitorija/organizacije koja odgovara ID-u grupe) i pravljenje PGP potpisi su obavezni za sve artefakte osim kontrolnih suma uklanja većinu "šuma", zlonamjernih paketa sličnih tiposquattingu i ograničava mnogo toga konfuzija ovisnostiSofisticirani napadi su mogući, ali mnogo teži, a samo ih je nekoliko poput ovog... com.github.codingandcoding:maven-compiler-plugin poznat po Maven Centralu. I ne slijede svi Maven registri iste prakse!
Sigurnosne kontrole na upraviteljima paketa mogu opteretiti, ali ne i spriječiti napade ovisnosti. Problem s višefaktorskom autentifikacijom je taj što se za automatizaciju generiraju izvedeni akreditivi poput pristupnih tokena ili APIapi ključeva za račune koji se koriste u APIapi pozivima napravljenim iz skripti za automatizaciju, bez podrške interaktivnog korisnika koji pruža drugi faktor. Višefaktorska autentifikacija je dobra za zaštitu korisničkih računa od curenja lozinki, ali generirani pristupni tokeni ili APIapi ključevi moraju biti zaštićeni dok su aktivni, inače će protivnici lažno predstavljati njihovog vlasnika. Veliki dio kampanja u lancu snabdijevanja zasnovanih na paketima počinje s procurilim ključem/tokenom. Samo se sjetite incidenata poput... glavna knjiga, 3CX, i mnogi drugi, gdje su neinteraktivni akreditivi prvo ukradeni u preliminarnom upadu za pokretanje napada na lanac snabdijevanja.
Odgovor na ovu prijetnju nije bio dovoljno snažan. U trećoj epizodi ćemo se fokusirati na ono što je funkcioniralo, a što je neslavno propalo. Industrija mora zajednički raditi na... standards, procesi, edukacija i alati za ublažavanje rizika za globalne lance snabdijevanja. Ovo nije problem koji jedna organizacija može sama riješiti.
Za kraj ovog odjeljka, ključni nesporazum: govorimo o zlonamerni paketi, ne ranjivi one. Ranjivosti nastaju zbog grešaka u dizajnu ili kodiranju, slučajno unesenih, bez loše namjere. Ranjivosti se mogu iskoristiti, ali mnoge nisu. Zlonamjerni paketi su uvijek namjerni i postoji 100% iskoristivost ako se izvrše. Nema usporedivog rizika! Stoga Paradoksalno je vidjeti koliko se truda ulaže u otkrivanje i ublažavanje ranjivosti, a nedostatak ekvivalentnih mjera za zlonamjerne komponente.
"Sigurnost shvatamo ozbiljno"
Zamislimo uobičajeno Acme CorporationAcme, glavni dobavljač za WileCoyote.com, većinu svog softvera nabavlja od trećih strana, a više od 80% potiče iz projekata otvorenog koda. Proizvode softver za internu upotrebu, ali također pružaju softver svojim partnerima, dobavljačima i kupcima/krajnjim korisnicima. Acme ima softver napisan u Go, JavaScript, Java, C# i Python jezicima, a većinu svog softvera pokreće u oblaku, pod Kuberneteskubernetes klasterima. Acme gradi svoje prilagođene slike od osnovnih slika preuzetih iz Docker Huba i drugih registara. Također dijele nekoliko biblioteka, paketa i slika kontejnera u javnim registrima.
Acme ozbiljno shvata sigurnost. Prilično su svjesni problema open source security, i rizik koji to nosi. Svi programeri, sistem menadžeri i DevOpsdevops inženjeri koriste te slatke male kripto ključeve kao drugofaktorsku autentifikaciju. Svi commitrepozitorije koda su potpisane, zaštita grana je omogućena uz obavezne preglede koda, CI/CD zaključane, tajne pohranjene u tajnom trezoru, i s internim registrom koji djelomično odražava eksterne registre gdje su pohranjene samo dozvoljene komponente s bijele liste. Potreban je softver koji je izgradio Acme da preuzima zavisnosti trećih strana iz ovog registra.
Vjerovatno većina organizacija odgovara ovom profilu. Dragi čitaoče, vaša sigurno odgovara ako ste već ovdje, zar ne?
Onda, jednog nesretnog dana, važan frontend developer na Acmeu je trčao npm instalacija acme-cute-lib, zaboravljajući da je @acme/cute-lib bila ispravna ograničena zavisnost. Tačna greška nije bitna, mnogo toga može poći po zlu čak i kada se pretpostavi savršena kontrola nad životnim ciklusom softvera. Naš programer nije znao da APT grupa cilja Acme i objavio je zlonamjernu komponentu pod tim imenom, na lukav način tako da se zlonamjerno ponašanje aktivira samo kada je softver instaliran na Acme računarima. Paket nije otkriven sedmicama nakon objavljivanja.
Pokreće se instalacijski skript koji pretražuje vjerodajnice (u laptopu našeg programera bilo je mnogo "juicy" tokena za pristup), omogućavajući pristup internim repozitorijima softvera i prethodno spomenutom internom repozitoriju, kojem se, naravno, može pristupiti samo putem VPN-a. Zlonamjerni kod uspio je iskoristiti postojeću VPN vezu i objaviti zlonamjernu komponentu druge faze u internom registru, utječući na uobičajenu utility biblioteku koju dijeli većina softvera koji isporučuje Acme.
Sedmicama nakon toga, druge organizacije koje koriste Acme-ove objavljene alate počele su primjećivati čudan promet na svojim mrežama, pri čemu je promet koristio Acme-ov protokol, ali je bio usmjeren na hostove koji podsjećaju na Acme domenu. Promet je bio šifriran, ali su alati za praćenje sistema pronašli pristup neočekivanim datotekama i izvršavanju procesa koji izgledaju kao sistemske naredbe, ali koji na kraju pokreću preuzete izvršne datoteke.
Ostatak je historija: Acme je prvo negirao da je takvo ponašanje njima pripisivo i da su sve sigurnosne mjere bile na snazi. Tek nakon što su mediji koji se bave sajber sigurnošću počeli pitati zašto izvor otkrivenog ponašanja potiče iz Acmeovih komponenti, a sigurnosna analiza pokazala koliko su te komponente bile prepune skrivenog zlonamjernog softvera, Acme je morao prepoznati incident i pozvati firmu za reagovanje na incidente. Negativna marketinška kampanja koja je u trenutku potkopala teško stečeno povjerenje.Acme je bio udaljen samo jednu npm instalaciju od disaster„“ bio je čest naslov. Zatim su uslijedile tužbe i raskinuti ugovori.
Vidite li sličnosti s poznatim incidentima iz prošlosti? Acme je pogođen incidentom u lancu snabdijevanja u dvije faze, koristeći kombinaciju zabuna/greška u kucanju Napadi koji su koristili razvojnu radnu stanicu kao odskočnu dasku za zarazu komponenti koje su završile u softveru koji koriste treće strane. Kako se ovo može spriječiti ili ublažiti?
Zašto su otrovani paketi toliko popularni
Ovaj hipotetički incident pokazuje da čak i uz razuman pristup sigurnosti otvorenog koda, organizacije trebaju specifične mjere kako bi izbjegle da postanu žrtve zlonamjernog softvera u komponentama otvorenog koda. Shematski, akter prijetnje može:
- Kreirajte novi paket (slijedeći dobro poznate metode tiposquattinga ili zabune oko zavisnosti, ovo je put kojim se negativci najčešće koriste);
- Pokušajte zaraziti postojeći, bilo ubrizgavanjem u izvorni kod, pokušavajući ga prikriti kao doprinositelja putem pull requestili korištenje društvenog inženjeringa da bi se postalo održavatelj (kao što je "Jao Tan" uradio u XZ Backdoor-u ili desno9ctrl Korisnik GitHuba je uradio u tok događaja incident u jesen 2018.), ili pribavljanjem akreditacija repozitorija otvorenog koda i lažnim predstavljanjem kao održavatelj;
- Ubrizgati zlonamjerni softver tokom izgradnje paketa, bilo pokretanjem zlonamjernog skripta za izgradnju, ili ometanje preuzimanja paketa presretanjima tipa "čovjek u sredini" (srećom, TLS je sada uvijek potreban u većini registara).
- Ubrizgajte zapakovanu komponentu direktno u registar, obično snimanjem podataka iz registra (poželjna alternativa za mnoge sofisticirane napade poput Acme-ovog, gdje je kompromitovana radna stanica u prvoj fazi imala interni token za pristup registru, npr. u uobičajenom .NS or ~/.m2/settings.xml: zlonamjerni akteri znaju gdje tražiti tajne). Ranjivosti u registrima su također iskorištene.
Trovanje registara zlonamjernim softverom je osnova za napade ovisnosti. Ništa novo pod suncem: njegova rasprostranjenost je eksplodirala, ali iste tehnike funkcionišu sada kao i prije pet godina.
Izvor: Kolekcija noževa iz Backstabbera.
Zlonamjerni paket može djelovati prilikom instalacije, tokom izgradnje softvera ili tokom izvršavanja. Ponašanje se kreće od izvlačenja informacija, npr. izdvajanja tajni za pokušaj druge faze, do izdvajanja izvornog koda, ispuštanja dodatnog zlonamjernog softvera. U sljedećoj epizodi ćemo analizirati zlonamjerne pakete i kako se objavljuju.
dalje čitanje
Sljedeća epizoda Anatomija zlonamjernih paketa: Koji su trendovi? Fokusirat ćemo se na stvarne slučajeve koje pratimo pomoću našeg sistema za rano upozoravanje na zlonamjerni softver, dan za danom. Pregledat ćemo koje su vrste zlonamjernog softvera viđene i koje su taktike, tehnike i procedure omiljene. Ispitat ćemo prikrivanje i kako se pokušavaju sakriti od potencijalnih recenzenata, tehnike izbjegavanja otkrivanja i kako se one razvijaju s telemetrijom i lateralnim kretanjem. Molimo vas da ostanete u toku!
reference
- Kolekcija noževa Backstabbera: Pregled napada na lanac snabdijevanja softverom otvorenog kodaM. Ohm i dr., maj 2020.
- Zaštita od zlonamjernog softvera otvorenog kodaBijela knjiga od Xygenija.
- Software Supply Chain Security Retrospektiva: Oblikovanje sigurnije 2024. godineIzvještaj iz Xygenija.
