See on esimene osa artiklite sarjast, mis käsitleb kõige levinumaid tarkvara tarneahela rünnakuid: neid, mis (kuri)kasutavad avalikku tarkvarakomponentide registrit, mis on mõeldud avatud lähtekoodiga projektid et üles laadida esemeid, mida saaks teiste kasutajatega jagada. Kui pahad avaldavad seal pahavara, kasutades registrit pahavara levitamise vahendina, on meil tarneahela rünnak, kui ohvriks langenud organisatsioonid installivad või käivitavad nakatunud tarkvarakomponendi.
Arutelu lihtsustamiseks räägime sellest, tarkvarapaketid:, kolmandate osapoolte loodud pakendatud komponendid. See hõlmab lisaks paketihaldurite (nt NPM või Poetry) kasutatavatele komponentidele ka operatsioonisüsteemi komponendid sealhulgas teegid ja käivitatavad binaarfailid, konteineri pildid, ja virtuaalmasinad või tööriista pikendused arendus-, ehitus- ja juurutustööriistade jaoks. Oleme näinud pahatahtlikke pakette kõikjal. Küberkurjategijad ei pahanda: nad on rõõmsad tänapäevaste tarkvarainfrastruktuuride pakutavate alternatiivide üle ning kasutavad registrit ja tööriista, mis sobib kõige paremini nende eesmärgiga. Seega pidage meeles, et tarkvarapaketid on lühend konteinerikujutistest, binaarpakettidest, avatud lähtekoodiga repositooriumidest ja igasugustest laiendustest või pluginatest (IDE-dest, CI/CD süsteemid, ehitustööriistad). Kõik on pidevalt rünnaku all.
Sari koosneb viiest episoodist:
- Mis on avatud lähtekoodiga pakettidega seotud probleem? See on selle postituse teema. Miks avaldavad igasugused kurjategijad pahatahtlikke pakette? Miks peaksin ma muretsema?
- Pahatahtlike pakettide anatoomia: millised on trendid? Selles episoodis keskendume ohule, mida me oma MEW-süsteemiga päevast päeva jälgime. Suure hulga pahatahtlike pakettide tõttu, mis kasutavad trükivigu või sõltuvuste segadust, on taustamüra suur, mistõttu on väiksem protsent rünnakuid palju salakavalamad ja kujutavad endast suuremat riski. Kuidas on pahatahtlike isikute käitumine operatsioonisüsteemide osas viimasel ajal muutunud? Millised on numbrid? Milliseid taktikaid, tehnikaid ja protseduure kasutatakse ning milliseid kahjulikke tegevusi on täheldatud?
- Kaitse avatud lähtekoodiga pahatahtlike pakettide eest: mis toimib (ei toimi)Enamikul turvateadlikest spetsialistidest on ettekujutused selle ohuga toimetulekuks. Oleme kuulnud turvajuhte kõhklemata ütlemas, et SCA Tööriistad juba näitavad, millal paketi versioon on pahavara. Või et need sõltuvad tuntud ja hoolikalt hinnatud tarkvarakomponentidest, kus iga pahavara tuvastatakse ja eemaldatakse kohe. Nad ütlevad, et nad kasutavad haavatavuste automaatseks parandamiseks avatud väiksemaid/parandusversioone ja see on õige ja soovitatav viis avatud lähtekoodiga sõltuvuste riski vähendamiseks, järgides põhimõtet „parandus varakult, parandus sageli“. Selles osas vaatame üle, miks need ideed on valed ja kuidas sellised väärarusaamad aitavad kaasa selle rünnakumehhanismi populaarsusele ja organisatsioonide kogetavale ülekaalukale riskile. Lõpetame sellega, mis toimib ning millised on vajalikud pingutused ja ressursid.
- Avatud lähtekoodiga pahatahtlikud paketid: Xygeni lähenemisviisSelles episoodis tutvustame, millist strateegiat me Xygenis oma pahavara varajase hoiatamise (MEW) süsteemi puhul järgime. Kuidas see mitmeastmeline süsteem reaalajas töötab uue paketiversiooni avaldamisel, kuidas erinevatest allikatest tõendeid kogutakse, kuidas toimub triaaž, milliseid klassifitseerimiskriteeriume me järgime ja miks on pahatahtliku paketi kandidaadi olemuse kinnitamiseks veel vaja käsitsi analüüsi? Kuidas meie sise- ja registrimeeskondade tagasiside aitab süsteemil õppida varem kogutud tõenditest, et vähendada valepositiivseid tulemusi miinimumini. Ja me selgitame, kuidas me aitame NPM-il, GitHubil, PyPI-l ja teistel avatud lähtekoodiga ökosüsteemide võtmetaristutel vähendada ooteaega..
- Avatud lähtekoodi ärakasutamine: mida pahadelt poistelt oodataSari lõpeb keskendumisega uusimatele meetmetele, mida vastased omaks võtavad, et muuta rünnakud märksa salapärasemaks, raskemini avastatavaks, sihtida konkreetseid tööstusharusid ja saada sellest rünnakute klassist rohkem kasu. Kas lunavararünnakuid korraldatakse selle vahendi abil? Kuidas pahad kasutavad tehisintellekti tööriistu keerukamate pahatahtlike pakettide edastamiseks? Kas populaarsed projektid on ohus? See annab lugejatele aimu sellest võidurelvastumisest ning sellest, mida oodata lühiajaliselt (2024. aasta teisel poolel) ja keskpikas perspektiivis (2025). Saame teada, kuidas sellised rünnakud nagu hiljutine... XZ-Utilsi tagauksvõi maalt ära elatud rünnaku vastu elektronide ehitaja märtsis 2024 näitavad, et peaksime olema valvsad vastaste arengu suhtes.
Avame lava esimese episoodiga: Mis toimub pahatahtlike avatud lähtekoodiga avatud lähtekoodiga pakettidega?
Mis on avatud lähtekoodiga pakettidega seotud probleem?
Viimastel aastatel on igasugused kurjategijad kasutanud avatud lähtekoodiga tarkvara registreid pahatahtliku käitumise levitamiseks. Need tegevused on sama vanad kui avatud lähtekood, kuid nende sagedus on viimase kolme aasta jooksul plahvatuslikult kasvanud.
Pahatahtlike komponentide avaldamine avalikes registrites (sõltuvuspõhised rünnakud) on asümmeetriline sissisõda, mida ohustajad kasutavad pahavara levitamiseks, kasutades ära usaldust, mida organisatsioonid panevad tundmatute arendajate avatud lähtekoodiga komponentidesse (pidage meeles sõltuvus xkcd koomiks?). Kuna sa usaldad pakette ja sul pole midagi selle vastu, et sa saaksid käsitsi pakettide sisu ja nende sõltuvusi üle vaadata, on need rünnakud erakordselt tõhusad. Ja asümmeetria tuleneb sellest, et neid saab suures osas automatiseerida ja pahalased ei pea ohvriga otse suhtlema. Nad lihtsalt laadivad paketi avalikku registrisse üles ja lasevad sellel minna.
Pahatahtlikud paketid kasvas 2022. aastal 6 kordaja jätkas 2023. aastal 2.5-kordset kasvu. Eelmisel aastal nähti koguni 245 000 pahatahtlikku paketti, mis on enam kui kahekordne eelmiste aastate koguarvuga võrreldes. See on eksponentsiaalne kasv! Alates sadadest kinnitatud pahavarana eemaldatud pakettidest 2021. aastal ja tuhandetest 2022. aastal nägime 2023. aastal palju rohkem taustamüra, sarnase tempoga nagu sel aastal. Ja selle tausta all, mille põhjustasid kogenematud küberkurjategijad, kes järgisid „vähima vastupanu teed“, jõudis väike osa kõrgetasemelistest rünnakutest pealkirjadesse isegi üldises meedias.
Miks on see nii ulatuslik probleem? On olemas liigne usaldus kogu ahelas. Avatud lähtekoodiga tarkvara levitatakse koos lähtekoodiga ja avaldatakse kindla litsentsi alusel. Jah, igaüks saab lähtekoodi kontrollida; aga kes seda üldiselt teeb? Kes pärast tarkvara pahavara puudumise kontrollimist ehitab tarkvara lähtekoodist? Kes enne pakendatud komponendi (tuntud ka kui pakend) allavoolu paketihaldurile või ehitustööriistale, veendub, et pakett ei ole pahavaraga nakatunud ja vastab oletatavale lähtekoodile, kust see peaks pärinema?
Miks infrastruktuur võimaldab nii lihtsaid rünnakuid?
Pakettregistrid on avatud, nõudes sageli avaldaja identiteedi minimaalset kontrollimist. „Kõik on teretulnud siin oma tarkvara avaldama!“ Ründajatele on seatud madalad nõudmised: nad kasutavad ühekordseid e-posti aadresse ja ühekordseid GitHubgithubi kontosid, et luua lühikeste, andmepüügilaadsete kampaaniate käigus sadu pahatahtlikke pakette. Ainult sihtrühmale suunatud kampaaniate puhul on vaja suuremat keerukust: nägime isegi usaldusväärse GitHubi lähtekoodihoidla loomist paljude tähtedega ja commitmitmetelt võltskaastöölistelt ja muudelt populaarsuse ja hoolduse näitajatelt. Saamine Tähevaatlejad ja maine võltsitud panustest pole keeruline automatiseerida. Nägime igasuguseid kuritarvitusi avatud tarkvarainfrastruktuurides, mitte ainult pahavara, näiteks teeprotokolli intsident.
Paketihaldurid on loodud kasutusmugavust, mitte turvalisust silmas pidades.Nad saavad käivitada installieelseid ja -järgseid skripte (mõnikord on vaja teegi jaoks natiivset koodi kompileerida). Samuti Paketihaldurid installivad pakette mitmest allikast ja mõnikord on vaikimisi avalike registrite kasutamine. Nad ei kontrollinud avaldamistaotluse metaandmete ja paketi enda metaandmete mittevastavust.
Sõltuvused on pesastatud ja moodustavad graafi. Teatud ökosüsteemides, näiteks Node'is (JavaScript), kuhjub väikeseteralisi sõltuvusi sadades või tuhandetes. Üks asi on omada ranget kontrolli oma tarkvaraprojektide deklareeritud otseste sõltuvuste üle, aga... transitiivsed sõltuvused on raskem kontrollida. Avatud lähtekoodiga tarkvara järgis põhimõtet „minu sõprade sõbrad on minu sõbrad“. Vennaskond on metsikus Kaug-Idas normiks saanud! Ohutegelased teavad seda ja varjavad pahatahtlikku käitumist sügavalt varjatud sõltuvustes, mis on sageli teadmata. Nii oli see ka ... puhul. sündmuste voog intsident, mis on suunatud Copay rahakott.
Nii on avatud lähtekoodiga tarkvara oma loomisest peale töötanud. See ei muutu palju. Mõned paketiregistrid nõuavad parimal juhul kahefaktorilist autentimist ja sageli ainult kõige populaarsemate pakettide puhul. Mõned registrid pakuvad ulatusi, kontrollitud organisatsioonile kuuluvat nimeruumi, kuid traagiliselt teised seda ei toeta (PyPI) või muudavad selle valikuliseks (NPM). On huvitav märkida, et isegi a lihtne sõelumisskeem (põhineb grupi ID-le vastava DNS-i või GitHubi hoidla/organisatsiooni kontrollil) ja tehes PGP allkirjad on kohustuslikud kõigi artefaktide puhul, välja arvatud kontrollsummad, eemaldab suurema osa "mürast", trükivigu meenutavatest pahatahtlikest pakettidest ja piirab suurt osa sõltuvuse segadusKeerukad rünnakud on võimalikud, kuid palju raskemad, selliseid nagu com.github.codingandcoding:maven-compiler-plugin tuntud Maven Centrali poolest. Ja mitte kõik Maveni registrid ei järgi samu tavasid!
Paketihaldurite turvakontrollid võivad küll sõltuvusrünnakuid koormata, kuid ei takista neid. Mitmefaktorilise autentimise probleem seisneb selles, et automatiseerimiseks genereeritakse automatiseerimisskriptidest tehtud APIapi-kõnedes kasutatavate kontode jaoks tuletatud volikirjad, näiteks juurdepääsutokenid või APIapi-võtmed, ilma et interaktiivne kasutaja pakuks teist tegurit. Mitmefaktoriline autentimine on hea kasutajakontode kaitsmiseks paroolilekete eest, kuid genereeritud juurdepääsutokenid või APIapi-võtmed peavad olema aktiivsed, vastasel juhul võivad vastased nende omaniku isikustada. Suur osa paketipõhistest tarneahela kampaaniatest algab lekkinud võtme/tokeniga. Pidage meeles selliseid intsidente nagu pearaamat, 3CXja paljudes teistes kohtades, kus mitte-interaktiivsed volitused varastatakse esmakordselt tarneahela rünnaku käivitamiseks kavandatud esialgse sissetungi käigus.
Sellele ohule antud vastus ei olnud piisavalt jõuline. Kolmandas osas keskendume sellele, mis toimis ja mis ebaõnnestus. Tööstusharu peab selle nimel ühiselt tööd tegema. standardd, protsessid, koolitus ja tööriistad globaalsete tarneahelate riskide maandamiseks. See ei ole probleem, mida üksik organisatsioon saab üksi lahendada.
Selle osa lõpetuseks peamine arusaamatus: me räägime pahatahtlik pakette, mitte haavatav Haavatavused tulenevad disaini- või kodeerimisvigadest, mis on kogemata ja ilma pahatahtlikkuseta sisse toodud. Haavatavusi võidakse ära kasutada, kuid paljusid mitte. Pahatahtlikud paketid on alati tahtlikud ja nende käivitamisel on 100% ärakasutatavus. Võrreldavat riski pole! Seega On paradoksaalne näha, kui palju pingutusi tehakse haavatavuste avastamiseks ja leevendamiseks ning kui puuduvad samaväärsed meetmed pahatahtlike komponentide jaoks..
„Suhtume turvalisusse tõsiselt“
Kujutame ette tavapärast Acme korporatsioonAcme, WileCoyote.com-i peamine pakkuja, tellib suurema osa oma tarkvarast kolmandatelt osapooltelt, millest üle 80% pärineb avatud lähtekoodiga projektidest. Nad toodavad tarkvara sisekasutuseks, aga pakuvad tarkvara ka oma partneritele, pakkujatele ja klientidele/lõppkasutajatele. Acmel on tarkvara, mis on kirjutatud Go, JavaScripti, Java, C# ja Pythoni keeles ning suurem osa oma tarkvarast käitatakse pilves Kuberneteskubernetes klastrite all. Acme loob oma kohandatud kujutised Docker Hubi ja teiste registrite baaskujutistest. Samuti jagavad nad avalikes registrites mõnda teeki, paketti ja konteineri kujutist.
Acme suhtub turvalisusse tõsiselt. Nad on probleemist üsna teadlikud. open source securityja sellega kaasnevat riski. Kõik arendajad, süsteemihaldurid ja DevOps/devops insenerid kasutavad neid armsaid väikeseid krüptovõtmeid teise astme autentimiseks. Kõik commitkoodirepositooriumidele on alla kirjutatud, harukaitse on lubatud kohustuslike koodiülevaadetega, CI/CD lukus, saladused salvestatud salajasse hoidlasse ja sisemise registriga, mis osaliselt peegeldab väliseid registreid, kus salvestatakse ainult lubatud, valgesse nimekirja kantud komponendid. Acme loodud tarkvara peab sellest registrist võtma kolmandate osapoolte sõltuvused.
Tõenäoliselt sobib enamik organisatsioone sellesse profiili. Hea lugeja, sinu oma sobib kindlasti, kui sa juba siin oled, eks?
Siis ühel õnnetul päeval, oluline esiotsa arendaja Acme'is jooksis npm install acme-cute-lib, unustades, et @acme/cute-lib oli õige ulatusega sõltuvus. Täpne viga pole oluline, palju asju võib valesti minna isegi siis, kui eeldada tarkvara elutsükli täielikku kontrolli. Meie arendaja ei teadnud, et APT grupp sihitas Acme'i ja avaldas selle nime all kavala viisil pahatahtliku komponendi, seega aktiveerub pahatahtlik käitumine alles siis, kui tarkvara installitakse Acme arvutitesse. Paketti ei tuvastatud nädalaid pärast selle avaldamist.
Käivitatakse installiskript, mis otsib sisselogimisandmeid (meie arendaja sülearvutis oli palju mahlaseid juurdepääsutokeneid), lubades juurdepääsu sisemistele tarkvarahoidlatele ja eelmainitud sisemisele hoidlale, millele pääseb ligi loomulikult ainult VPN-i kaudu. Pahatahtlik kood suutis olemasolevat VPN-ühendust kasutada ja avaldada sisemisse registrisse teise astme pahatahtliku komponendi, mõjutades ühist utiliidikogu, mida jagab enamik Acme'i tarnitud tarkvarast.
Nädalaid hiljem hakkasid teised Acme avaldatud tööriistu kasutavad organisatsioonid oma võrkudes nägema kummalist liiklust, mis kasutas Acme protokolli, kuid oli suunatud Acme domeeniga sarnastele hostidele. Liiklus oli krüpteeritud, kuid süsteemi jälgimise tööriistad leidsid juurdepääsu ootamatutele failidele ja protsesside käivitamisele, mis nägid välja nagu süsteemikäsud, kuid käivitasid lõpuks allalaaditud käivitatavaid faile.
Ülejäänu on ajalugu: Acme eitas esialgu, et selline käitumine on neile omistatav ja et kõik turvameetmed on paigas. Alles pärast seda, kui küberturvalisuse meedia hakkas küsima, miks tuvastatud käitumise allikas pärines Acme komponentidest, ja turvaanalüüs avaldas, kui palju need komponendid olid varjatud pahavaraga täidetud, pidi Acme intsidendi tunnistama ja kutsuma intsidentidele reageerimise ettevõtte. Negatiivne turunduskampaania, mis õõnestas raskelt teenitud usaldust sekundiga.Acme oli di-st ühe npm paigalduse kauguselsaster„oli tavaline pealkiri. Seejärel järgnesid kohtuasjad ja tühistatud lepingud.
Kas näete sarnasusi teadaolevate varasemate intsidentidega? Acme'i tarneahela intsident toimus kahes etapis, kasutades selleks järgmist: sõltuvuse segadus/trükivea rünnakud, mis kasutasid arendaja tööjaama sillapeana komponentide nakatamiseks, mis sattusid kolmandate osapoolte kasutatavasse tarkvarasse. Kuidas saaks seda ära hoida või leevendada?
Miks on mürgitatud pakendid nii populaarsed
See hüpoteetiline intsident näitab, et isegi mõistliku lähenemisviisi korral avatud lähtekoodiga tarkvara turvalisusele vajavad organisatsioonid avatud lähtekoodiga komponentides sisalduva pahavara ohvriks langemise vältimiseks spetsiifilisi meetmeid. Skemaatiliselt saab ohu tekitaja:
- Loo uus pakett (järgides tuntud trükiviga või sõltuvuste segaduse tekitamise teid, see on pahalaste poolt mahu poolest enim läbitud tee);
- Proovige nakatada olemasolevat, kas sisestades selle lähtekoodi või püüdes seda kaastöölisena varjata pull requestvõi kasutades sotsiaalset manipuleerimist hooldajaks saamiseks (nagu „Jao Tan” tegi XZ Backdoor'is või parem 9ctrl GitHubi kasutaja tegi seda sündmuste voog intsident 2018. aasta sügisel) või avatud lähtekoodiga repositooriumi volituste hankimise ja hooldaja isikuna esinemise teel;
- Pahavara süstimine paketi loomise ajal, kas pahatahtliku ehitusskripti käivitamise teelvõi pakettide allalaadimise segamine man-in-the-middle pealtkuulamistega (õnneks on TLS nüüd enamikus registrites alati nõutav).
- Süstige pakendatud komponent otse registrisse, tavaliselt registri sisselogimisandmete jäädvustamise teel (eelistatud alternatiiv paljude keerukate rünnakute puhul, näiteks Acme'i puhul, kus ohustatud tööjaamal oli esimeses etapis sisemine registri juurdepääsuluba, nt tavapärases vormis). .env or ~/.m2/seaded.xml(Pahatahtlikud isikud teavad küll, kust saladusi otsida). Samuti kasutati ära registrite haavatavusi.
Registrite mürgitamine pahavaraga on sõltuvusrünnakute alus. Pole midagi uut päikese all: selle levimus on plahvatuslikult kasvanud, kuid samad tehnikad toimivad nüüd kui viis aastat tagasi.
Allikas: Seljatorkaja nugade kollektsioon.
Pahatahtlik pakett võib toimida installimise, tarkvara loomise või käitusaja ajal. Ja käitumine ulatub teabe lekkimisest (nt teise faasi katse jaoks saladuste väljavõtmine) kuni lähtekoodi väljavõtmiseni ja täiendava pahavara lisamiseni. Järgmises osas lahkame pahatahtlikke pakette ja nende avaldamise viisi.
Lisalugemist
Järgmine episood Pahatahtlike pakettide anatoomia: millised on trendid? Keskendume reaalsetele juhtumitele, mida jälgime oma pahavara varajase hoiatamise süsteemiga iga päev. Vaatame üle, milliseid pahavara tüüpe on täheldatud ning millised taktikad, tehnikad ja protseduurid on eelistatud. Uurime hägustamist ja seda, kuidas nad üritavad potentsiaalsete arvustajate eest varjata, avastamise vältimiseks kasutatavaid kõrvalehoidumistehnikaid ning kuidas need arenevad telemeetria ja külgliikumise abil. Jälgige meid!
Tehtud tööd
- Backstabber's Knife Collection: avatud lähtekoodiga tarkvara tarneahela rünnakute ülevaadeM. Ohm jt, mai 2020.
- Avatud lähtekoodiga pahavara kaitseXygeni aruanne.
- Software Supply Chain Security Tagasivaade: turvalisema 2024. aasta kujundamineAruanne Xygenilt.
