Ilang araw na nakalipas Inihayag ng GitHub ang dalawang insidente sa imprastraktura ng imbakan ng pakete ng NPM, kung saan idinetalye nito na noong Nobyembre 2, ang mga third-party na mananaliksik sa seguridad bilang bahagi ng programa ng Bug Bounty ay nakakita ng kahinaan sa repositoryo ng NPM na nagbibigay-daan sa pag-publish ng bagong bersyon ng anumang pakete na ginagamit kahit na hindi ito awtorisado upang maisagawa ang mga naturang pag-update.
Ang kahinaan ay sanhi ng maling mga pagsusuri sa awtorisasyon sa microservices code ang prosesong iyon ay humihiling sa NPM. Ang serbisyo ng awtorisasyon ay nagsagawa ng pagsusuri ng pahintulot sa mga pakete batay sa data na ipinasa sa kahilingan, ngunit ang isa pang serbisyo na nag-a-upload ng update sa repositoryo ang nagpasiya ng package na i-publish batay sa nilalaman ng metadata sa na-upload na package.
Kaya, ang isang umaatake ay maaaring humiling ng pag-publish ng isang update para sa kanyang package, kung saan siya ay may access, ngunit ipahiwatig sa package mismo ang impormasyon tungkol sa isa pang package, na sa kalaunan ay maa-update.
Sa nakalipas na ilang buwan, ang npm team ay namumuhunan sa mga pagpapabuti sa imprastraktura at seguridad upang i-automate ang pagsubaybay at pagsusuri ng mga kamakailang inilabas na bersyon ng package upang matukoy ang malware at iba pang nakakahamak na code sa real time.
Mayroong dalawang pangunahing kategorya ng mga kaganapan sa pag-post ng malware na nangyayari sa npm ecosystem: malware na nai-post dahil sa pag-hijack ng account, at malware na pino-post ng mga umaatake sa pamamagitan ng sarili nilang mga account. Bagama't medyo bihira ang mga pagkuha ng account na may mataas na epekto, kumpara sa direktang malware na nai-post ng mga umaatake gamit ang kanilang sariling mga account, ang mga pagkuha ng account ay maaaring malayong maabot kapag nagta-target ng mga sikat na tagapanatili ng package. Bagama't ang aming oras ng pagtuklas at pagtugon sa mga pagkuha ng mga sikat na pakete ay kasing baba ng 10 minuto sa mga kamakailang insidente, patuloy naming binabago ang aming mga kakayahan sa pag-detect ng malware at mga diskarte sa pag-abiso tungo sa isang mas proactive na modelo ng pagtugon.
Ang problema naayos ito 6 na oras pagkatapos maiulat ang kahinaan, ngunit mas matagal ang kahinaan sa NPM kaysa sa saklaw ng telemetry logs. Sinasabi ng GitHub na walang mga bakas ng mga pag-atake gamit ang kahinaang ito mula noong Setyembre 2020, ngunit walang garantiya na ang problema ay hindi pa pinagsamantalahan noon.
Ang ikalawang insidente ay naganap noong Oktubre 26. Sa kurso ng teknikal na gawain kasama ang database ng serbisyo ng replicant.npmjs.com, ipinahayag na mayroong kumpidensyal na data sa database na magagamit para sa panlabas na konsultasyon, naglalahad ng impormasyon tungkol sa mga pangalan ng mga panloob na pakete na binanggit sa changelog.
Impormasyon sa mga pangalang iyon ay maaaring gamitin upang magsagawa ng mga pag-atake ng dependency sa mga panloob na proyekto (Noong Pebrero, pinahintulutan ng naturang pag-atake ang code na tumakbo sa mga server ng PayPal, Microsoft, Apple, Netflix, Uber, at 30 iba pang kumpanya.)
Bukod dito, kaugnay ng dumaraming insidente ng pag-agaw ng mga repositoryo ng malalaking proyekto at ang pag-promote ng malisyosong code sa pamamagitan ng kompromiso ng mga developer account, Nagpasya ang GitHub na ipakilala ang mandatoryong two-factor authentication. Magkakabisa ang pagbabago sa unang quarter ng 2022 at malalapat sa mga maintainer at administrator ng mga package na kasama sa listahan ng pinakasikat. Bukod pa rito, ibinibigay ang impormasyon tungkol sa modernisasyon ng imprastraktura, kung saan ang awtomatikong pagsubaybay at pagsusuri ng mga bagong bersyon ng package ay ipakikilala para sa maagang pagtuklas ng mga malisyosong pagbabago.
Alalahanin na ayon sa isang pag-aaral na isinagawa noong 2020, 9.27% lamang ng mga manager ng package ang gumagamit ng two-factor authentication upang maprotektahan ang pag-access, at sa 13.37% ng mga kaso, kapag nagrerehistro ng mga bagong account, sinubukan ng mga developer na muling gumamit ng mga nakompromisong password na lumalabas sa mga kilalang password. .
Sa panahon ng pagsusuri sa lakas ng mga password na ginamit, 12% ng mga account sa NPM (13% ng mga package) ang na-access dahil sa paggamit ng mga predictable at walang kuwentang password tulad ng "123456". Kabilang sa mga problema ay 4 na user account ng 20 pinakasikat na mga pakete, 13 mga account na ang mga pakete ay na-download nang higit sa 50 milyong beses bawat buwan, 40 - higit sa 10 milyong mga pag-download bawat buwan at 282 na may higit sa 1 milyong mga pag-download sa isang buwan. Isinasaalang-alang ang pag-load ng module kasama ang chain ng mga dependency, ang pagkompromiso sa mga hindi pinagkakatiwalaang account ay maaaring makaapekto sa hanggang 52% ng lahat ng module sa NPM sa kabuuan.
Sa wakas, kung interesado kang malaman ang tungkol dito maaari mong suriin ang mga detalye Sa sumusunod na link.