Pred nekaj dnevi GitHub je razkril dva incidenta v infrastrukturi repozitorija paketov NPM, od tega podrobno opisuje, da so 2. novembra varnostni raziskovalci tretjih oseb v okviru programa Bug Bounty odkrili ranljivost v repozitoriju NPM ki omogoča objavo nove različice katerega koli paketa, ki uporablja, čeprav ni pooblaščen za izvedbo takšnih posodobitev.
Ranljivost je nastala zaradi nepravilnih preverjanj avtorizacije v kodi mikrostoritev ki obdeluje zahteve NPM. Storitev avtorizacije je opravila preverjanje dovoljenja za pakete na podlagi podatkov, posredovanih v zahtevi, vendar je druga storitev, ki je nalagala posodobitev v skladišče, določila, da se paket objavi na podlagi vsebine metapodatkov v naloženem paketu.
Tako bi lahko napadalec zahteval objavo posodobitve za svoj paket, do katerega ima dostop, a v samem paketu navede podatke o drugem paketu, ki bi se sčasoma posodobil.
V zadnjih nekaj mesecih je ekipa npm vlagala v infrastrukturo in varnostne izboljšave, da bi avtomatizirala spremljanje in analizo nedavno izdanih različic paketov za prepoznavanje zlonamerne programske opreme in druge zlonamerne kode v realnem času.
Obstajata dve glavni kategoriji dogodkov objavljanja zlonamerne programske opreme, ki se zgodita v ekosistemu npm: zlonamerna programska oprema, ki je objavljena zaradi ugrabitve računa, in zlonamerna programska oprema, ki jo napadalci objavijo prek svojih računov. Čeprav so pridobitve računov z velikim vplivom razmeroma redke, so v primerjavi z neposredno zlonamerno programsko opremo, ki jo objavijo napadalci z lastnimi računi, lahko pridobitve računov daljnosežne, če ciljate na priljubljene vzdrževalce paketov. Čeprav je bil naš čas zaznavanja in odziva na pridobitve priljubljenih paketov v zadnjih incidentih le 10 minut, še naprej razvijamo naše zmogljivosti za odkrivanje zlonamerne programske opreme in strategije obveščanja v smeri bolj proaktivnega modela odziva.
Problem popravljena je bila 6 ur po prijavi ranljivosti, vendar je bila ranljivost v NPM prisotna dlje kot pokrivajo dnevniki telemetrije. GitHub navaja, da ni bilo nobenih sledi napadov, ki uporabljajo to ranljivost od septembra 2020, vendar ni nobenega zagotovila, da problem še ni bil izkoriščen.
Drugi incident se je zgodil 26. oktobra. Med tehničnim delom s servisno bazo replicant.npmjs.com, je bilo razkrito, da so v bazi podatkov zaupni podatki, ki so na voljo za zunanje posvetovanje, ki razkriva informacije o imenih notranjih paketov, ki so bili omenjeni v dnevniku sprememb.
Informacije o teh imenih se lahko uporablja za izvajanje napadov odvisnosti na notranje projekte (Februarja je tak napad omogočil zagon kode na strežnikih PayPal, Microsoft, Apple, Netflix, Uber in 30 drugih podjetij.)
Poleg tega, v zvezi z vse pogostejšim zasegom odlagališč velikih projektov in spodbujanje zlonamerne kode z ogrožanjem računov razvijalcev, GitHub se je odločil uvesti obvezno dvofaktorsko preverjanje pristnosti. Sprememba bo začela veljati v prvem četrtletju leta 2022 in bo veljala za vzdrževalce in skrbnike paketov, uvrščenih na seznam najbolj priljubljenih. Poleg tega poroča o posodobitvi infrastrukture, ki bo uvedla avtomatizirano spremljanje in analizo novih različic paketov za zgodnje odkrivanje zlonamernih sprememb.
Spomnimo se, da glede na študijo, izvedeno leta 2020, samo 9.27% upraviteljev paketov uporablja dvofaktorsko preverjanje pristnosti za zaščito dostopa, v 13.37% primerov pa so razvijalci pri registraciji novih računov poskušali ponovno uporabiti ogrožena gesla, ki se pojavljajo v znanih geslih. .
Med preverjanjem trdnosti uporabljenih gesel je bilo do 12 % računov v NPM (13 % paketov) dostopnih zaradi uporabe predvidljivih in trivialnih gesel, kot je "123456". Med težavami so bili 4 uporabniški računi izmed 20 najbolj priljubljenih paketov, 13 računov, katerih paketi so bili naloženi več kot 50 milijonov krat na mesec, 40 - več kot 10 milijonov prenosov na mesec in 282 z več kot milijon prenosov na mesec. Glede na obremenitev modulov vzdolž verige odvisnosti bi lahko ogrožanje nezaupanja vrednih računov vplivalo na do 1 % vseh modulov v NPM skupaj.
Končno, če vas zanima več o tem lahko preverite podrobnosti V naslednji povezavi.