Inihayag ng GitHub ang dalawang insidente sa imprastraktura ng repositoryo ng package ng NPM nito. Noong Nobyembre 2, iniulat ng mga third-party na mananaliksik sa seguridad (Kajetan Grzybowski at Maciej Piechota), bilang bahagi ng Bug Bounty program, ang pagkakaroon ng kahinaan sa repositoryo ng NPM na nagbibigay-daan sa iyong mag-publish ng bagong bersyon ng anumang package gamit ang iyong account, na hindi awtorisadong magsagawa ng mga naturang pag-update.
Ang kahinaan ay sanhi ng mga maling pagsusuri sa pahintulot sa code ng mga microservice na nagpoproseso ng mga kahilingan sa NPM. Ang serbisyo ng awtorisasyon ay nagsagawa ng mga pagsusuri sa pahintulot ng package batay sa data na ipinasa sa kahilingan, ngunit isa pang serbisyo na nag-upload ng update sa repositoryo ang nagpasiya ng package na i-publish batay sa metadata na nilalaman ng 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 tukuyin sa package mismo ang impormasyon tungkol sa isa pang package, na sa kalaunan ay maa-update.
Naayos ang isyu 6 na oras pagkatapos maiulat ang kahinaan, ngunit ang kahinaan ay naroroon sa NPM na mas mahaba kaysa sa saklaw ng telemetry logs. Sinasabi ng GitHub na walang mga bakas ng mga pag-atake na gumagamit ng kahinaan na ito mula noong Setyembre 2020, ngunit walang garantiya na ang problema ay hindi pa pinagsamantalahan noon.
Ang pangalawang insidente ay naganap noong Oktubre 26. Sa panahon ng teknikal na gawain sa database ng serbisyo ng replicate.npmjs.com, ang pagkakaroon ng kumpidensyal na data sa database na naa-access sa mga panlabas na kahilingan ay inihayag, na nagbubunyag ng impormasyon tungkol sa mga pangalan ng mga panloob na pakete na binanggit sa log ng pagbabago. Maaaring gamitin ang impormasyon tungkol sa mga naturang pangalan para magsagawa ng mga pag-atake ng dependency sa mga panloob na proyekto (noong Pebrero, pinahintulutan ng isang katulad na pag-atake ang code na isagawa sa mga server ng PayPal, Microsoft, Apple, Netflix, Uber at 30 iba pang kumpanya).
Bilang karagdagan, dahil sa dumaraming kaso ng mga repositoryo ng malalaking proyekto na na-hijack at na-promote ng malisyosong code sa pamamagitan ng pagkompromiso sa 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 pinakasikat na listahan. Bukod pa rito, iniuulat ang tungkol sa modernisasyon ng imprastraktura, kung saan ang awtomatikong pagsubaybay at pagsusuri ng mga bagong bersyon ng mga pakete ay ipakikilala para sa maagang pagtuklas ng mga malisyosong pagbabago.
Tandaan natin na, ayon sa isang pag-aaral na isinagawa noong 2020, 9.27% ββlang ng mga package maintainer ang gumagamit ng two-factor authentication para protektahan ang access, at sa 13.37% ng mga kaso, kapag nagrerehistro ng mga bagong account, sinubukan ng mga developer na gumamit muli ng mga nakompromisong password na lumabas sa kilalang paglabas ng password. Sa panahon ng pagsusuri sa seguridad ng password, 12% ng mga NPM account (13% ng mga package) ang na-access dahil sa paggamit ng mga predictable at trivial na password gaya ng "123456." Kabilang sa mga may problema ay 4 na user account mula sa Top 20 pinakasikat na package, 13 account na may mga package na na-download nang higit sa 50 milyong beses bawat buwan, 40 na may higit sa 10 milyong mga pag-download bawat buwan, at 282 na may higit sa 1 milyong mga pag-download bawat buwan. Isinasaalang-alang ang paglo-load ng mga module sa isang hanay ng mga dependency, ang kompromiso ng mga hindi pinagkakatiwalaang account ay maaaring makaapekto sa hanggang 52% ng lahat ng mga module sa NPM.
Pinagmulan: opennet.ru