„Strapi“ apgaulė: kaip 36 kenkėjiški „npm“ paketai nusitaikė į duomenų bazių infrastruktūrą

Per trumpą 13 valandų laikotarpį „npm“ registrą užplūdo 36 kenkėjiški paketai, apsimetę populiaraus „Strapi CMS“ įrankiais. Tai nebuvo atsitiktinis skaitmeninis vandalizmas; tai buvo apskaičiuotas, sisteminis bandymas įsiskverbti į svarbias duomenų bazių aplinkas. Kol „SafeDep“ saugumo tyrėjai identifikavo kampaniją, grėsmės sukėlėjai jau buvo įsitvirtinę, pasinaudodami pasitikėjimu, kurį programuotojai skiria atvirojo kodo ekosistemoms.

Žvelgiant iš rizikos perspektyvos, šis incidentas pabrėžia nesaugią šiuolaikinės programinės įrangos kūrimo realybę: mūsų tiekimo grandinės yra tik tiek stiprios, kiek stipri jų silpniausia priklausomybė. Užpuolikai naudojo keturias netikras paskyras – umarbek1233, kekylf12, tikeqemif26 ir umar_bektembiev1 – paketams platinti, kurie iš pirmo žvilgsnio atrodė kaip brandūs bendruomenės įskiepiai. Tačiau užkulisiuose šie paketai buvo sukurti veikti kaip skaitmeninis Trojos arklys, nešantis kenkėjišką turinį, galintį pakenkti „Redis“ ir „PostgreSQL“ egzemplioriams.

Apgaulės anatomija

Užpuolikai naudojo gudrią pavadinimų suteikimo tvarką, kad apeitų užsiėmusių programuotojų filtrus. Pridėdami priešdėlį strapi-plugin- ir pridėdami įprastus funkcinius terminus, tokius kaip cron, database ar health, jie imitavo oficialios „Strapi“ ekosistemos pavadinimų struktūrą. Įdomu tai, kad visuose 36 paketuose jie taip pat įrašė versijos numerį 3.6.8. Tai buvo apgalvotas pasirinkimas, kad programinė įranga atrodytų kaip brandi, stabili versija, o ne įtartinas naujas įkėlimas.

Analizuojant grėsmių žvalgybos ataskaitas, tokio tipo „typosquatting-adjacent“ (panašaus pavadinimo parinkimo) elgsena tampa vis dažnesnė. Užpuolikai žino, kad programuotojai dažnai pirmiausia ieško funkcionalumo, o leidėją tikrina tik po to. Nors oficialūs „Strapi“ įskiepiai yra griežtai apriboti @strapi/ vardų srityje, privalomos srities trūkumas bendruomenės įskiepiams sukuria spragą, kurią piktavaliai mielai užpildo.

„Postinstall“ kabliukas: tylusis vykdytojas

Architektūriniu lygmeniu pagrindinis čia išnaudotas pažeidžiamumas nėra „Strapi“ ar pačios „npm“ klaida, o veikiau „npm“ gyvavimo ciklo funkcija. Kiekviename iš 36 paketų buvo postinstall.js skriptas. „npm“ ekosistemoje po įdiegimo vykdomas skriptas paleidžiamas automatiškai, kai tik paketas atsisiunčiamas, nereikalaujant jokios vartotojo sąveikos.

Todėl kenkėjiškas kodas vykdomas su tomis pačiomis privilegijomis, kaip ir diegimą atliekantis vartotojas. Vietinėje kūrimo aplinkoje tai gali reikšti prieigą prie asmeninių failų ir aplinkos kintamųjų. Tačiau reguliavimo kontekste, kur duomenų vientisumas yra svarbiausias, tikrasis pavojus kyla CI/CD konvejeriuose ir „Docker“ konteineriuose. Jei automatizuotas kūrimo procesas paima vieną iš šių paketų, skriptas faktiškai gauna „root“ prieigą tame konteineryje, o tai leidžia jam plėstis ir pulti vidinę infrastruktūrą.

Duomenų sluoksnio išnaudojimas

Ši kampanija yra ypač pavojinga dėl savo orientacijos į duomenų sluoksnį. Kenkėjiškas turinis nebuvo bendro pobūdžio; jis buvo specialiai pritaikytas išnaudoti „Redis“ ir „PostgreSQL“. Kai tik buvo suaktyvintas postinstall skriptas, jis bandė:

• Surinkti prisijungimo duomenis: ieškoti duomenų bazių prisijungimo eilučių aplinkos kintamuosiuose ir konfigūracijos failuose.
• Įdiegti atvirkštinius apvalkalus (reverse shells): užmegzti nuolatinį ryšį su užpuoliko valdymo serveriu (C2).
• Palikti nuolatinius implantus: užtikrinti, kad net jei pradinis procesas būtų nutrauktas, užpuolikas išlaikytų prieigą prie sistemos.

Iš esmės užpuolikai ieškojo „karalystės raktų“. Duomenų bazės dažnai yra jautriausia programos architektūros dalis, kurioje saugoma viskas – nuo vartotojų asmens duomenų (PII) iki patentuotos verslo logikos. Nusitaikę į „Redis“ ir „PostgreSQL“, užpuolikai siekė paprastą paketo įdiegimą paversti viso masto duomenų saugumo pažeidimu.

Žmogiškoji ugniasienė ir tiekimo grandinės saugumas

Žvelgiant į grėsmių aplinką, turime pripažinti, kad nepaisant pataisų, žmogiškasis faktorius išlieka svarbiu kintamuoju. Prisimenu atvejį atliekant duomenų nutekėjimo tyrimą, kai vyresnysis programuotojas netyčia įvedė kenkėjišką priklausomybę, nes dirbo vėlai ir nepatikrino paketo pradinio puslapio. Tai nutinka net geriausiems, tačiau automatizuotų atakų pasaulyje nebegalime sau leisti tokių klaidų.

Galutinio vartotojo požiūriu, tokio pažeidimo poveikis dažnai yra nematomas, kol tampa per vėlu. Kitaip tariant, pažeista priklausomybė yra tarsi lėtas nuotėkis laivo korpuse; galite nepastebėti kylančio vandens, kol varikliai nesuges. Šiuo atveju „varikliai“ yra jūsų duomenų bazės, o „vanduo“ – neteisėta prieiga prie jūsų svarbių duomenų.

Proaktyvi gynyba: kaip apsaugoti savo konvejerį

Galiausiai atsakomybė už programinės įrangos tiekimo grandinės apsaugą tenka tiek platformoms, tiek jas naudojantiems programuotojams. Nors „npm“ stengiasi pašalinti šiuos paketus, kai tik apie juos pranešama, 13 valandų prieinamumo langas buvo daugiau nei pakankamas laikas automatizuotoms sistemoms įsisavinti kenkėjišką kodą.

Norėdami sukurti atsparesnę sistemą, apsvarstykite šiuos veiksmus:

1. Naudokite apribotos srities paketus: naudodami „Strapi“, teikite pirmenybę įskiepiams iš @strapi/ srities. Būkite itin skeptiški dėl paketų be nurodytos srities, kurie neturi aprašymo, saugyklos ar pradinio puslapio.
2. Pagal numatytuosius nustatymus išjunkite skriptus: naudokite --ignore-scripts vėliavėlę vykdydami npm install aplinkose, kuriose nepasitikite kiekviena priklausomybe. Tai neleidžia automatiškai vykdyti postinstall skriptų.
3. Naudokite užrakto failus (lockfiles) ir auditą: reguliariai vykdykite npm audit ir naudokite package-lock.json, kad užtikrintumėte, jog jūsų priklausomybių medis yra nuspėjamas ir nebuvo pakeistas.
4. Įdiekite tinklo išėjimo filtravimą: architektūriniu lygmeniu jūsų CI/CD vykdytojai ir gamybiniai konteineriai neturėtų turėti neribotos prieigos prie interneto. Neautorizuotų išeinančių ryšių blokavimas gali neleisti atvirkštiniams apvalkalams prisijungti prie užpuoliko.

Kaip priešpriešinę priemonę būsimoms atakoms, kiekvieną trečiosios šalies priklausomybę turime vertinti kaip potencialią riziką. Taikydami nulinio pasitikėjimo (zero-trust) požiūrį į savo paketų tvarkykles, galime paversti savo kūrimo konvejerius tvirta gynyba, o ne atviromis durimis išnaudojimui.

Šaltiniai:

• SafeDep Threat Research Team Analysis
• npm Registry Security Advisory Logs
• Strapi Official Documentation on Plugin Security