Padziļināta rokasgrāmata par NPM drošības auditu un piegādes ķēdes uzbrukumiem

Sākums » Pitons » Padziļināta rokasgrāmata par NPM drošības auditu un piegādes ķēdes uzbrukumiem

Ja šodien kaut ko veidojat, izmantojot Node.js vai TypeScript, jūs stāvat virs gigantiskas npm atkarību kaudzes, kuras neesat rakstījis un, iespējams, nekad pilnībā neizlasīsiet. Tas ir neticami ērti funkciju ātrai ieviešanai, taču tas arī paver milzīgu uzbrukuma virsmu piegādes ķēdes apdraudējumiem, akreditācijas datu zādzībām un smalkām aizmugurējām durvīm, kas iekļūst jūsu lietotnēs vai CI/CD cauruļvados.

Mūsdienu npm drošība vairs nav tikai jautājums par to, “vai manos pakotnēs ir zināmi CVE?” — tā ir par aizsardzība pret pikšķerēšanas kampaņām, kas nozog uzturētāju kontus, tārpi, kas automātiski publicē inficētas versijas, un ļaunprātīgas bibliotēkas, kas mēģina izdzēst izstrādātāja home direktoriju vai nozagt mākoņa akreditācijas datus. Šajā rokasgrāmatā mēs aprakstīsim, kā npm drošības audits darbojas, kā uzlabot savas darbplūsmas ar tādiem rīkiem kā npm audit, Dependabot, SAST/SCA skeneri un CI/CD pārbaudes, kā arī to, ko jūs kā izstrādātājs reāli varat darīt, ja uztraucaties, ka “šī foršā mazā bibliotēka varētu būt ļaunprogrammatūra”.

Kāpēc npm atkarības drošība ir tik svarīga?

Katru reizi, kad skrienat npm install, jūs importējat trešās puses kodu savā projektā un efektīvi uzticoties tā autoriem ar daļu no jūsu uzbrukuma virsmas. Node.js vidē šī uzticamības ķēde var būt pārsteidzoši dziļa: viena augstākā līmeņa atkarība var piesaistīt simtiem tranzitīvu pakotņu, kuras jūs nekad neesat tieši izvēlējies.

Neaizsargātas vai pamestas atkarības var izraisīt klasiskas drošības problēmas, piemēram, injekcijas uzbrukumus, pakalpojuma atteikumu (DoS), privilēģiju eskalāciju vai datu noplūdi. Pat neliela kļūda zema līmeņa utilītā — HTTP klientā, krāsu parsētājā, YAML ielādētājā — var radīt plašu ietekmi, ja tā atrodas zem populāriem ietvariem un rīkiem.

Papildus tradicionālajām ievainojamībām ekosistēmai tagad ir jātiek galā ar klaju ļaunprātīgu rīcību: pakotnēm, kas apzināti izstrādātas, lai nozagtu noslēpumus , ievadītu kriptovalūtu ieguves kodu vai apdraudētu CI/CD cauruļvadus. Tie nav teorētiski riski; vairāki reāli incidenti ir parādījuši, ka uzbrucēji uzbrūk uzturētāju kontiem un pēc tam izmanto uzticamas pakotnes kā ieroci.

Tāpēc atkarību auditēšana un atjaunināšana nav patīkams higiēnas uzdevums, bet gan jebkura nopietna Node.js vai TypeScript projekta uzturēšanas pamatelements. Regulāri drošības auditi, gan automatizēti, gan manuāli, ir vienīgais veids, kā uzturēt trešo pušu koda radīto risku pieņemamā līmenī.

NPM audita izpratne un tas, ko tas faktiski pārbauda

npm audit ir iebūvēta komanda, kas skenē jūsu projekta atkarību koku, salīdzinot to ar zināmu ievainojamību datubāzi, un izveido drošības pārskatu. Palaižot to projekta saknē, npm aplūko jūsu package.json un bloķēšanas failu, izveido pilnu atkarību grafiku un salīdzina katru versiju ar ieteikumiem.

Audita ziņojumā ir ietvertas gan tiešās, gan netiešās atkarības (pakotnes, kuras pats uzskaitāt, un atkarību atkarības). Katrai problēmai tajā ir norādīta skartā pakotne, ievainojamības kopsavilkums, tās nopietnība (zema, vidēja, augsta, kritiska) un versiju diapazons, kurā ir ietverts labojums.

No darbplūsmas viedokļa, npm audit var izmantot interaktīvi izstrādātājiem un neinteraktīvi CI/CD cauruļvados. Cauruļvados jūs pat varat panākt, lai būvēšana neizdotos tikai tad, ja ievainojamības pārsniedz noteiktu nopietnības slieksni, izmantojot tādus karodziņus kā --audit-level.

Šis rīks pieder pie plašākas programmatūras kompozīcijas analīzes (SCA) saimes : tas koncentrējas uz zināmām problēmām atvērtā pirmkoda komponentos, nevis uz kļūdām jūsu pašu kodā. Tas nozīmē, ka tas ir ļoti spēcīgs novecojušu vai neaizsargātu bibliotēku atrašanā, taču tas maģiski neatklāj pavisam jaunu ļaunprogrammatūru, kas nosūtīta vakar ar nekad iepriekš neredzētu pakotnes nosaukumu.

Kā veikt NPM auditu un interpretēt rezultātus

Lai veiktu pamata drošības auditu, atveriet termināli projekta saknes direktorijā (kur package.json dzīvības) un skrien npm auditPēc īsas atkarību analīzes npm izvadīs problēmu tabulu, kas sagrupēta pēc nopietnības pakāpes, kā arī ieteiktos novēršanas pasākumus, piemēram, jaunināšanu uz ielāpu versiju.

Audita izvadē parasti tiek iekļauts pakotnes nosaukums, instalētā versija, ievainojamības apraksts un nopietnības pakāpe (zema, vidēja, augsta, kritiska) , kā arī ceļi, kas parāda, kur atkarību kokā pakotne tiek izmantota, un ieteicamā fiksētā versija vai diapazons. Uztveriet to kā prioritāru uzdevumu sarakstu: sāciet ar kritisko un augsto, pēc tam virzieties uz leju.

Ja vēlaties rezultātus ievadīt citos rīkos vai saglabāt tos vēlākam laikam, varat pieprasīt JSON izvadi, izmantojot npm audit --jsonTas ir īpaši ērti, ja integrējaties ar pielāgotiem informācijas paneļiem, biļešu pārdošanas sistēmām vai drošības orķestrācijas platformām.

CI/CD cauruļvados daudzas komandas konfigurē cauruļvadu tā, lai tas darbotos npm audit --json tūlīt pēc atkarību instalēšanas parsēt rezultātu un neizdoties veidot, ja ir kāda ievainojamība, kas pārsniedz izvēlēto nopietnības līmeni. Ārējie palīglīdzekļi, piemēram, audit-ci var ietvert šo loģiku jūsu vietā un nodrošināt ērtas iespējas pārtraukt būvējumus, ja tiek pārsniegti sliekšņi.

Ievainojamību novēršana ar npm audita labojumu

Vienreiz npm audit problēmas, jūsu pirmā aizsardzības līnija ir npm audit fix, kas mēģina automātiski jaunināt neaizsargātās atkarības uz tuvākajām drošajām versijām. Zem pārsega tas pārraksta package-lock.json (Un package.json ja piemērojams), lai palielinātu pakotņu skaitu saderīgu versiju diapazonos.

Šī automātiskā labošana labi darbojas daudzu zemu un vidēju problēmu gadījumā, kā arī dažu augstāku nopietnību problēmu gadījumā, ja labojums ir neliels vai ielāpa izlaidums. Tā ir ātra uzvara, kas bieži vien atbrīvo lielu daļu no jūsu kavējumiem ar minimālu cilvēka piepūli.

Ne visas ievainojamības var droši novērst ar automātisku jaunināšanu; dažām ir nepieciešamas būtiskas versiju izmaiņas, kas var sabojāt jūsu kodu vai citas atkarības. Tieši tur... npm audit fix --force nāk iekšā: tas piespiež veikt jauninājumus pat starp bojātām izmaiņām, taču tas jāizmanto uzmanīgi un vienmēr rūpīgi jāpārbauda pēc tam.

Pirms piespiedu opcijas izmantošanas nopietnos projektos ir ieteicams veikt bloķēšanas faila apstiprināšanu vai dublēšanu un nodrošināt labu testēšanas pārklājumu. Piespiedu jaunināšana var izraisīt uzvedības izmaiņas vai regresijas, kuras ir grūtāk izsekot, ja nav salīdzinājuma ar bāzes līniju.

Bloķēt failus, npm ci un deterministiskas instalācijas

The package-lock.json fails (vai yarn.lock/pnpm-lock.yaml citiem pārvaldniekiem) ir kritiski svarīga drošībai, jo tā piesprauž katras jūsu projektā izmantotās atkarības precīzas versijas. Bez tās katrs npm install var izgūt nedaudz atšķirīgas saderīgas versijas, padarot būvējumus nedeterministiskus un grūtāk auditējamus.

Jums vajadzētu izvairīties no rediģēšanas package-lock.json manuāli un tā vietā ļaujiet npm to pārvaldīt, kad pievienojat, noņemat vai atjaunināt atkarības. Koda apstiprināšanas laikā vienmēr iekļaujiet abus package.json un bloķēšanas failu, lai visi — un jūsu CI/CD — instalētu vienas un tās pašas versijas.

Automatizētā vidē dodiet priekšroku npm ci vairāk npm install jo npm ci izmanto bloķēšanas failu kā stingru līgumu un atsakās darboties, ja tas neatbilst deklarētajām atkarībām. Tas nodrošina ātrāku un pilnībā atkārtojamu instalēšanu, kas ir tieši tas, ko vēlaties CI.

No piegādes ķēdes drošības viedokļa instalāciju bloķēšana un reproducēšana nozīmē, ka jūs precīzi zināt, kuras versijas tika izmantotas konkrētajai versijai, kas ir ļoti svarīgi, ja jums ir jāpārbauda, ​​vai jūsu ķēdē jebkad ir ievilināta ļaunprātīga versija. Ja nepieciešams, varat atkārtoti atskaņot versijas, izmantojot vēsturiskos bloķēšanas failus, lai redzētu, vai ir bijusi neaizsargāta vai aizmugures durvju versija.

Atjauninājumu automatizācija ar Dependabot, Renovate un npm rīkiem

Manuāla novecojušu vai ievainojamu pakotņu izsekošana daudzās krātuvēs ātri kļūst nekontrolējama, tāpēc automatizācija, izmantojot tādus rīkus kā Dependabot vai Renovate, ir tik vērtīga. Šie pakalpojumi uzrauga jūsu atkarības un atver pieprasījumus, kad parādās jaunas versijas vai drošības labojumi.

Piemēram, GitHub Dependabot ir konfigurēts, izmantojot .github/dependabot.yml fails, kas norāda, kuras ekosistēmas novērot, atjaunināšanas biežumu un mērķa zarus. Kad tas atklāj neaizsargātu vai novecojušu npm pakotni, tas izveido PR atjaunināšanu package.json un package-lock.json, bieži vien ar saitēm uz ieteikumiem.

Pāri ar npm audit, jūs iegūstat labu atgriezeniskās saites cilpu: audits identificē problēmas, un Dependabot (vai Renovate) nepārtraukti piedāvā jauninājumus, lai tās novērstu. Jūsu uzdevums ir pārskatīt un testēt šos pieprasījumus, nevis manuāli meklēt katru atsevišķu versijas izciļņu.

Papildus automatizācijai, npm pats nodrošina palīgkomandas, piemēram npm outdated lai uzskaitītu pakotnes ar jaunākām versijām un npm update veikt jaunināšanu atļauto versiju diapazonu ietvaros. Regulāri lietojot, tie samazina iespēju, ka ievērojami atpaliksiet un jums būs jāpāriet uz vairākām galvenajām versijām vienlaikus.

Drošības pārbaužu veikšana CI/CD cauruļvados

Droša npm iestatīšana neapstājas pie jūsu klēpjdatora; jūsu CI/CD cauruļvadiem ir arī jāievieš drošības pārbaudes, lai novērstu neaizsargāta vai ļaunprātīga koda nonākšanu ražošanas vidē. Katrā posmā — avota izveidē, izveidē, testēšanā, izvietošanā — jābūt atbilstošām kontrolēm.

Ir ierasts skriet npm audit automātiski izveides vai pirmsizvietošanas posmā, bieži vien ar --json karodziņš vienkāršākai integrācijai ar uzraudzības rīkiem. Ja skenēšanas laikā tiek atklātas ievainojamības, kas pārsniedz jūsu riska slieksni, cauruļvads var neizdoties un bloķēt izlaišanu.

Tādi moderni rīki kā Snyk var darboties kā drošības vārtu sargi CI/CD vidē, skenējot atkarības un neizdodot būvējumus, ja tiek atrastas nopietnas vai kritiskas problēmas. Apvienojot tos ar kvalitātes analizatoriem, piemēram, SonarQube vai SonarCloud, jūs iegūstat plašāku priekšstatu par koda kvalitāti, drošības riskiem un tehnisko parādu.

Izstrādes laikā tika izmantoti statiskās analīzes rīki, piemēram, ESLint, ar tādiem spraudņiem kā eslint-plugin-security un eslint-plugin-node palīdzēt jums laikus pamanīt nedrošus modeļus jūsu kodā. Tas papildina atkarību skenēšanu, kas koncentrējas uz trešo pušu komponentiem, nevis jūsu biznesa loģiku.

CI/CD cauruļvadu nostiprināšana pēc npm audita

Automatizētas skenēšanas ir jaudīgas, taču drošam cauruļvadam ir nepieciešama arī spēcīga slepeno datu pārvaldība, stabila piekļuves kontrole un laba repozitorija higiēna. Nepareizi konfigurēti slepenie dati vai pārāk atļaujošas lomas var nelielu pārkāpumu pārvērst par pilnvērtīgu incidentu.

Izmantojiet specializētus slepeno datu pārvaldniekus, piemēram, HashiCorp Vault vai AWS Secrets Manager, nevis ieguliet žetonus vai atslēgas konfigurācijas failos vai vides mainīgajos, kas pārbaudīti versiju kontrolē. Tas samazina iespēju, ka uzbrucējs vai pat ziņkārīgs līdzstrādnieks jūsu repozitorijā nejauši uzduras sensitīviem datiem.

Lomām balstīta piekļuves kontrole (RBAC) ar mazāko privilēģiju principu ir ļoti svarīga GitHub, npm un jebkurai CI/CD platformai, ko izmantojat. Izstrādātājiem un pakalpojumu kontiem jābūt tikai tām atļaujām, kas tiem absolūti nepieciešamas — nekam vairāk.

Pirmsapstrādes āķi un slepenās informācijas skenēšanas rīki var vispār apturēt API atslēgu, žetonu vai paroļu iekļūšanu jūsu repozitorijos. Apvienojumā ar strukturētām GitOps darbplūsmām un aizsargātām filiālēm tie nodrošina skaidru audita taku un samazina nepārskatītu izmaiņu apvienošanas risku.

Paziņojumi no jūsu drošības rīkiem ir jāintegrē reāllaika kanālos, piemēram, Slack, Microsoft Teams vai e-pastā, taču tie ir rūpīgi jāpielāgo, lai jūsu komanda netiktu pārslogota ar mazvērtīgiem brīdinājumiem. Prioritāšu noteikšana pēc nopietnības un konteksta ļauj koncentrēties uz to, kas patiešām ir svarīgs.

Reālās pasaules NPM piegādes ķēdes uzbrukumi un ko tie mums māca

Pēdējo gadu laikā npm ir saskāries ar vairākiem augsta līmeņa piegādes ķēdes incidentiem, kuros uzbrucēji bija vērsti pret uzturētājiem vai pakotnēm, nevis atsevišķām lietojumprogrammām. Šie uzbrukumi izceļ, kā viens apdraudēts konts var ietekmēt miljoniem lejupējo instalāciju.

Vienā kampaņā labi pazīstams npm uzturētājs saņēma rūpīgi izstrādātu pikšķerēšanas e-pastu no domēna, kas gandrīz neatšķīrās no oficiālās npm vietnes. Ziņojumā tika draudēts bloķēt kontu, ja netiks “atjaunināta” divfaktoru autentifikācija, tādējādi pievilinot upuri uz viltotu pieteikšanās lapu, kurā tika iegūti akreditācijas dati.

Kad uzbrucējs ieguva kontroli pār uzturētāja npm kontu, viņš izplatīja 18 ārkārtīgi populāru pakotņu ļaunprātīgas versijas ar miljardiem lejupielāžu nedēļā. Tā kā šīs pakotnes bija dziļi iestrādātas JavaScript ekosistēmas atkarību grafikā, potenciālais sprādziena rādiuss bija milzīgs.

Ievadītais kods darbojās kā pārlūkprogrammas puses pārtvērējs, kas vērsts uz kriptovalūtu un Web3 aktivitātēm: tas piesaistīja pārlūkprogrammas API, piemēram, fetch, XMLHttpRequest un maku saskarnes, piemēram, window.ethereum vai Solana maka API. Tā skenēja tīkla atbildes un darījumu vērtumus, meklējot jebko, kas izskatījās pēc kriptovalūtas adreses vai pārskaitījuma.

Kad ļaunprogrammatūra pamanīja darījumu, tā aizstāja likumīgo saņēmēja adresi ar uzbrucēja kontrolētu adresi, bieži vien izvēloties līdzīgas virknes, lai izvairītos no aizdomām. Daudzos gadījumos lietotāja saskarnē joprojām šķita redzama “pareizā” adrese, lai gan pamatā esošie parakstītie dati jau bija modificēti, lai nosūtītu līdzekļus uzbrucējam.

Ļaunprātīgais kods bija ievērojami maskēts, izmantojot tādus mainīgos kā _0x... un lieli kodēti virkņu masīvi, kas tika dekodēti izpildlaikā, un dažreiz tas atgrieza viltotas veiksmīgas atbildes, lai lietojumprogramma nepamanītu neko nepareizu. Tikai noteiktas lietotnes bija patiesi izmantojamas, īpaši tās, kas mijiedarbojās ar makiem vai kriptopakalpojumiem un instalēja skartās versijas šaurajā kompromitēšanas logā.

Norādījumi no šī pārlūkprogrammas pārtvērēja incidenta

Viena skaidra mācība ir tāda, ka izstrādātājiem jābūt gataviem ātri atgriezties pie zināmām labām versijām, kad tiek paziņots par pakotnes kompromitēšanu. Pat ja reģistrs noņem ļaunprātīgas versijas, jūsu bloķēšanas faili un kešatmiņas joprojām var uz tām atsaukties, līdz jūs skaidri pazemināt vai jaunināt versiju.

Rūpīga pārbaude package.json un package-lock.json (Vai yarn.lock) ir svarīgi, lai pārbaudītu, vai jūsu projekts jebkad ir ielādējis ļaunprātīgās versijas. Šeit deterministiskas instalācijas un versiju piesaistīti bloķēšanas faili padara forenzikas darbu daudz vieglāk pārvaldāmu.

Ja jūsu lietojumprogramma mijiedarbojas ar kriptovalūtu makiem vai Web3 API, jums rūpīgi jāuzrauga darījumu žurnāli, lai atrastu anomālus galamērķus vai negaidītus apstiprinājumus laika logā, kurā atradās kompromitētas pakotnes. Agrīna atklāšana var ierobežot finansiālos zaudējumus un palīdzēt identificēt skartos lietotājus.

Konta drošības stiprināšana ar divfaktoru autentifikāciju, ideālā gadījumā izmantojot aparatūras atslēgas, ir vitāli svarīga npm un GitHub kontiem, īpaši populāru pakotņu uzturētājiem. Pat tad vienmēr esiet skeptiski pret e-pastiem, kas mudina noklikšķināt uz saites, lai “atjauninātu” akreditācijas datus; tā vietā dodieties tieši uz oficiālo vietni un pārbaudiet tur esošos brīdinājumus.

Organizācijas, kas izmanto komerciālus SCA un SBOM rīkus, bieži vien var veikt vaicājumus saviem krājumiem pēc pakotnes nosaukuma un versijas, lai atrastu visas sistēmas un lietojumprogrammas, kas ir atkarīgas no kompromitētas bibliotēkas. Šī pārskatāmība ievērojami saīsina reakcijas laiku piegādes ķēdes incidentu gadījumā.

Shai-Hulud tārps: pašreplicējošs npm ļaunprogrammatūra

Vēl viena ievērojama kampaņa, kuras iesauka bija Shai-Hulud kampaņa , pacēla npm piegādes ķēdes uzbrukumus jaunā līmenī, uzvedoties kā pašreplicējošs tārps dažādās pakotnēs un izstrādātāju vidēs. Tā padarīja npm pēcinstalēšanas skriptus par ieroci, lai tie palaistu ļaunprātīgu loģiku, tiklīdz tika instalēta kompromitēta versija.

Ļaunprogrammatūra skenēja vidi, meklējot sensitīvus akreditācijas datus, tostarp .npmrc faili ar npm žetoniem, GitHub personiskās piekļuves žetoniem, SSH atslēgām un mākoņpakalpojumu sniedzēju API atslēgām AWS, GCP un Azure. Viss, ko tas atrada, tika izfiltrēts uzbrucēja kontrolētajai infrastruktūrai.

Izmantojot nozagtus npm žetonus, tārps autentificējās kā kompromitēti uzturētāji, uzskaitīja citas viņiem piederošās pakotnes, ievadīja savu vērtumu un pēc tam publicēja jaunas ļaunprātīgas versijas. Šī automatizācija ļāva tam ātri izplatīties, uzbrucējam manuāli nepieskaroties katrai pakotnei.

Daudzos gadījumos nozagtie noslēpumi tika ievietoti jaunizveidotās publiskās GitHub krātuvēs upura paša kontā, ar nosaukumiem vai aprakstiem, kas atsaucas uz Shai-Hulud. Tas situāciju vēl vairāk pasliktināja, atklājot sensitīvus datus ikvienam, kurš nejauši uzdūrās šīm krātuvēm.

Drošības pētnieki pamanīja pazīmes (tostarp dīvainus komentārus un pat emocijzīmes), kas liecināja, ka daļa no ļaunprātīgajiem bash skriptiem ir ģenerēta, izmantojot lielus valodu modeļus. Tas ir spilgts piemērs tam, kā ģeneratīvo mākslīgo intelektu var ļaunprātīgi izmantot, lai paātrinātu uzbrukuma rīku izveidi.

Shai-Hulud 2.0: iepriekš instalēta sabotāža un destruktīvas atkāpšanās

Vēlāka vilnis, kas tika nodēvēts par Shai-Hulud 2.0, mainīja taktiku, lai izpildītu pirmsinstalēšanas fāzē, nevis pēcinstalēšanas, ievērojami paplašinot tā darbības jomu izstrādātāju datoros un CI/CD serveros. Pirmsinstalēšanas skripti tiek palaisti vēl agrāk dzīves ciklā un var tikt aktivizēti vairākās sistēmās.

Viens no šī varianta satraucošākajiem aspektiem bija rezerves mehānisms: ja ļaunprogrammatūrai neizdevās nozagt noderīgus akreditācijas datus vai izveidot saziņas kanālu, tā mēģināja veikt destruktīvas darbības, piemēram, noslaukot cietušā home katalogsTas tika paveikts, pārrakstot un droši izdzēšot visus rakstāmos failus, kas pieder pašreizējam lietotājam šajā direktorijā.

Kravnesība tika maskēta kā noderīgi Bun instalētāja skripti, piemēram, setup_bun.js un milzīgs, stipri apmulsināts bun_environment.js fails pārsniedz 9 MB. Lai nepiesaistītu uzmanību, galvenā loģika tika novirzīta uz fona procesu, lai sākotnējā instalēšana, šķiet, pabeigtos normāli.

Šīs kampaņas laikā apkopotie akreditācijas dati un noslēpumi atkal tika nopludināti uz GitHub, šoreiz krātuvēs, kas aprakstītas kā “Sha1-Hulud: The Second Coming”, un ļaunprogrammatūra centās iegūt noturību, izveidojot GitHub Actions darbplūsmas, piemēram, discussion.yamlŠīs darbplūsmas reģistrēja inficētās mašīnas kā pašviesotas palaistnes, ļaujot uzbrucējiem aktivizēt patvaļīgas komandas, vienkārši atverot diskusijas.

Kopējais darbības joma bija milzīga, skarot desmitiem tūkstošu repozitoriju un vairāk nekā 25 000 ļaunprātīgu repozitoriju simtiem GitHub kontu, tostarp populārās bibliotēkās, piemēram, @ctrl/tinycolor ar miljoniem lejupielāžu nedēļā. Tā kā mērķis ietvēra akreditācijas datu zādzību mākoņplatformās, pakārtotā ietekme varētu būt no datu zādzības un izspiedējvīrusa līdz kriptovalūtu ieguvei un plašiem pakalpojumu pārtraukumiem.

Neatliekamas aizsardzības darbības pret npm piegādes ķēdes tārpiem

Saskaroties ar tādām kampaņām kā Shai-Hulud, incidentu reaģēšanas speciālisti iesaka nekavējoties mainīt visus izstrādātāja līmeņa akreditācijas datus — npm tokenus, GitHub PAT, SSH atslēgas un visas mākoņa API atslēgas, kas tiek izmantotas izstrādātāju datoros vai būvēšanas serveros. Pieņemiet, ka jebkas, kas atrodas kompromitētā darbstacijā, varētu būt noplūdis.

Ir svarīgi veikt pilnīgu atkarību auditu visos projektos, izmantojot tādus rīkus kā npm audit, SBOM inventārus vai komerciālas SCA platformas, lai atrastu jebkādu skarto pakotņu nosaukumu un versiju lietojumu. Bloķēt failus (package-lock.json, yarn.lock) sniedz patiesību par to, kas faktiski tika uzstādīts.

Izstrādātājiem jāpārbauda savi GitHub konti, vai tajos nav dīvainu publisko repozitoriju (īpaši tādu, kas nosaukti Šai Huluda vārdā), aizdomīgu izmaiņu vai negaidītu izmaiņu GitHub Actions darbplūsmās, kas varētu būt reģistrējušas neatļautas izpildītājus. Jebkuras anomālijas jāuztver kā kompromitācijas pazīmes.

Daudzfaktoru autentifikācijas ieviešana visos izstrādātāju kontos — ja iespējams, izmantojot pret pikšķerēšanu izturīgas metodes — ir vēl viens neapspriežams solis. Tas nenovērš risku, bet paceļ latiņu uzbrucējiem, kas mēģina ļaunprātīgi izmantot akreditācijas datu zādzības kampaņas.

Organizācijas, kas izmanto uzlabotas apdraudējumu meklēšanas platformas, var arī izmantot pielāgotus vaicājumus, lai meklētu zināmus rādītājus, piemēram, izsaukumus uz konkrētiem webhook.site URL, tādu failu klātbūtne kā shai-hulud-workflow.yml vai aizdomīgi liels bun_environment.js Izstrādātāju datoros rakstīti faili. Agrīna noteikšana, izmantojot telemetriju, var ievērojami samazināt aizkavēšanās laiku.

Kā pārdevēji reaģē: atklāšanas un novēršanas iespējas

Drošības pārdevēji ir atjauninājuši savus produktus, lai atklātu un bloķētu uz npm vērstus piegādes ķēdes uzbrukumus gan galapunktā, gan tīklā. Tas ietver zināmu ļaunprātīgu vērtumu parakstus un uzvedības modeļus neparastām procesu vai failu aktivitātēm instalēšanas laikā.

Uzlaboti smilškastes un ļaunprogrammatūras analīzes pakalpojumi var atzīmēt apmulsinātas JavaScript vērtuma slodzes, piemēram, tās, kas tiek izmantotas Shai-Hulud kampaņās. Kad šie rīki pamana aizdomīgus pēcinstalēšanas vai pirmsinstalēšanas skriptus, kas mēģina atklāt akreditācijas datus vai iznīcināt failus, tie ģenerē brīdinājumus vai bloķē izpildi.

Nākamās paaudzes ugunsmūri ar uzlabotu apdraudējumu novēršanu un URL filtrēšanu var palīdzēt, bloķējot piekļuvi ļaunprātīgiem domēniem, ko izmanto pikšķerēšanā vai eksfiltrācijā, piemēram, viltotiem npm atbalsta domēniem vai konkrētiem webhook.site galapunkti ir iekodēti ļaunprogrammatūrā. Šo URL klasificēšana kā ļaunprātīgus neļauj veiksmīgi nosūtīt nozagtus datus..

Galapunktu noteikšanas un reaģēšanas (EDR/XDR) aģenti palīdz, uzraugot procesu uzvedību, skriptu izpildi, neparastu failu izveidi (piemēram, milzu bun_environment.js faili) un aizdomīgas komandrindas. Tie var apturēt gan zināmus hešus, gan iepriekš neredzētus variantus, pamatojoties uz uzvedības noteikumiem.

Mākonī bāzētās lietojumprogrammu drošības platformas arvien vairāk pievieno piegādes ķēdei paredzētas funkcijas, piemēram, SBOM redzamību reāllaikā, atvērtā pirmkoda komponentu riska novērtēšanu un CI/CD nepareizas konfigurācijas pārbaudes (trūkstoši bloķēšanas faili, nedroši npm install lietošana, uz Git balstītas atkarības bez piespraustām izmaiņu izmaiņu jaucējkodām, neizmantotas atkarības, kas paplašina uzbrukuma virsmu). Šīs kontroles apgrūtina ļaunprātīgu vai nepārbaudītu pakotņu versiju iekļūšanu ražošanas vidē.

Praktiski ieradumi izstrādātājiem, kas uztraucas par ļaunprātīgām npm pakotnēm

Ja esat jauns JS/TS lietotājs un jūtaties neērti katru reizi, kad instalējat npm pakotni, jūs neesat viens — taču ir konkrēti ieradumi, ko varat ieviest, lai samazinātu risku, neapdraudot savu produktivitāti. Uztveriet tos kā personīgo drošības kontrolsarakstu.

Pirmkārt, dodiet priekšroku labi izveidotām pakotnēm ar labu uzturēšanas vēsturi , aktīvu problēmu izsekotāju un plašu lietojumu, īpaši pamata infrastruktūrai, piemēram, HTTP klientiem, reģistrēšanai vai kriptovalūtām. Tas negarantē drošību, bet parasti nozīmē vairāk uzmanības kodam un ātrāku atklāšanu, ja kaut kas noiet greizi.

Mazas vai neskaidras pakotnes (īpaši tās, kurām gandrīz nav lejupielāžu) rūpīgi pārbaudiet: pārbaudiet npm lapu, repozitorija saites, pēdējās publicēšanas datumu un to, vai uzturētājs ir skaidri identificējams. Esiet uzmanīgi, ja npm pakotne ir saistīta ar GitHub repozitoriju, kas faktiski nesatur publicēto kodu vai joprojām norāda uz nesaistītu augšupējo resursu.

Ja iespējams, pārbaudiet publicēto pakotnes tarball, ne tikai avota repozitoriju, jo uzbrucēji var nosūtīt npm citu versiju nekā tā, kas parādās GitHub. Tādi rīki kā npm pack apvienojumā ar manuālu pārskatīšanu (pat ja kods ir transpilēts vai samazināts) var atklāt acīmredzamas brīdinājuma zīmes, piemēram, dīvainus instalēšanas skriptus, apmulsinātus blobus vai negaidītus tīkla izsaukumus.

TypeScript bibliotēkām, kas nodrošina tikai tipu definīcijas un minimizētu JavaScript, ir grūtāk veikt ātru manuālu auditu, tāpēc jūs varat izlemt tās izmantot tikai aiz stingras smilškastes vai atdalīt un atjaunot no pirmkoda, ja tās kļūst kritiski svarīgas jūsu stekam. Dažos drošības ziņā jutīgos kontekstos komandas patiešām izvēlas atdalīt atkarības privātos reģistros pēc rūpīgas pārskatīšanas.

Padariet npm drošību par rutīnu, nevis par ugunsgrēka trauksmes mācībām: palaidiet npm audit Regulāri notīriet neizmantotās atkarības, saglabājiet bloķēšanas failus aizsargātus un integrējiet SCA/SAST pārbaudes savā CI/CD. Apvienojumā ar spēcīgu kontu higiēnu un slepeno datu pārvaldību šīs prakses nepadara jūs neaizsargātu, taču tās ievērojami samazina iespēju, ka nejauša npm instalēšana nemanāmi apdraudēs jūsu sistēmas.