Kaip vienas „GitHub“ raktas apėjo pasaulinės farmacijos milžinės perimetrą

„Novo Nordisk“ palaiko daugiasluoksnę saugumo infrastruktūrą. Bendrovė naudoja pažangią galinių įrenginių aptikimo sistemą, tinklo segmentavimą ir specializuotą saugumo operacijų centrą. Ši apsauga kasmet kainuoja milijonus dolerių. Tačiau visa architektūra sugriuvo dėl vienos tekstinės eilutės viešai prieinamoje svetainėje. Danijos farmacijos milžinės patirtas saugumo pažeidimas yra pavyzdinis šiuolaikinės programinės įrangos kūrimo architektūrinio paradokso atvejis. Milžiniškos investicijos į perimetro apsaugą žlugo, nes vienas autentifikavimo raktas atsidūrė netinkamoje vietoje.

Daugelį metų bendravau su saugumo tyrėjais per „Signal“ ir PGP šifruotus kanalus. Dauguma jų neieško sudėtingų nulinės dienos (zero-day) pažeidžiamumų sustiprintose ugniasienėse. Jie ieško mažiausio pasipriešinimo kelio. „Novo Nordisk“ incidento atveju tas kelias buvo aukštų privilegijų „GitHub“ asmeninės prieigos raktas (PAT), paliktas kliento pusės „JavaScript“ kode mažai žinomame subdomene. Tai nebuvo sudėtingas įsilaužimas. Tai buvo atradimo procesas. Kai tik grėsmių grupė, žinoma kaip „FulcrumSec“, kovo mėnesį rado šį raktą, formalus saugumo perimetras tapo nebereikšmingas. Raktas suteikė autentifikuotą prieigą. Vidinėms sistemoms užpuolikai atrodė kaip teisėti kūrėjai.

Tylaus įsibrovimo anatomija

„FulcrumSec“ veikė „Novo Nordisk“ tinkle daugiau nei du mėnesius iki jų aptikimo. Per šį laikotarpį grupė naudojo pradinį „GitHub“ raktą privačioms saugykloms (repositories) klonuoti. Šiose saugyklose buvo ne tik kodas. Jose buvo antriniai prisijungimo duomenys, infrastruktūros aprašymai ir vidinė dokumentacija. Tai dažnas šiuolaikinių įsibrovimų modelis. Užpuolikas pasinaudoja nedidele atrama, kad surinktų galingesnes paslaptis. Jiems nereikia išnaudoti programinės įrangos klaidų, kai jie turi pagrindinių durų raktus.

Iki to laiko, kai „Novo Nordisk“ birželio 11 d. atskleidė incidentą, užpuolikai jau buvo išsiuntę 1,3 TB duomenų. Šį archyvą sudarė 700 000 failų. Nors bendrovė iš pradžių teigė, kad poveikis apsiribojo pseudonimizuotais pacientų duomenimis ir sveikatos priežiūros specialistų įrašais, tikrovė atrodo rimtesnė. Pavogti duomenys apima patentuotą informaciją apie rinkoje esančius ir dar neišleistus vaistus, klinikinių tyrimų duomenis bei vidinius DI modelius. „FulcrumSec“ teigia, kad ši informacija konkurentams galėtų sutaupyti nuo trejų iki penkerių metų kūrimo laiko. Tai yra sisteminės nesėkmės apibrėžimas. Pažeidimas iš paprasto nutekinto rakto virto pagrindinės intelektinės nuosavybės praradimu.

Kodėl kūrimo procesai yra gamybinės sistemos

Kūrimo platformos yra vertingiausios šiuolaikinės įmonės sistemos. Dauguma saugumo programų nesugeba pripažinti šios realybės. Kodo saugykla nebėra tiesiog paprasta tekstinių failų talpykla. Tai visos skaitmeninės aplinkos brėžinys. Joje saugomos debesijos aplinkų konfigūracijos ir diegimo procesai, kurie perduoda kodą klientams. Kai užpuolikas gauna prieigą prie saugyklos, jis mato visą organizacijos „elektros instaliaciją“.

Mattas Kimpelis, „Magna5“ informacijos saugumo vadovas, pažymi, kad kūrėjai turi nuolatinę prieigą prie svarbiausių sistemų. Jie disponuoja kūrimo procesų (build pipelines) ir debesijos aplinkų prisijungimo duomenimis. Šios sistemos yra aukščiau gamybinės aplinkos. Jei užpuolikas pažeidžia kodą prieš jį sukompiliuojant, jis valdo galutinį produktą. Dėl to kūrėjo darbo vieta ir saugykla tampa svarbesnės už patį gamybinį serverį. Tradicinės apsaugos priemonės, tokios kaip šakų patvirtinimai (branch approvals) ir kodo peržiūros, daro prielaidą, kad veiksmą atliekantis asmuo yra patikimas darbuotojas. Jei tapatybė yra pažeista, tos pačios kontrolės priemonės palengvina ataką.

Nematoma mašinų tapatybių rizika

Organizacijos paslapčių valdymą traktuoja kaip įrankių problemą. Jos nusiperka saugyklą (vault) ir mano, kad problema išspręsta. „Novo Nordisk“ incidentas įrodo, kad paslapčių valdymas yra tapatybės problema. Nutekintas „GitHub“ raktas yra mašinos tapatybė. Skirtingai nei žmonių paskyros, mašinų kredencialai dažnai neturi aiškių savininkų. Jie neturi nuoseklių keitimo tvarkaraščių. Jiems dažnai trūksta prasmingo stebėjimo. Šie raktai išlieka nepakeisti mėnesius ar metus.

Shane’as Barney, „Keeper Security“ saugumo vadovas, pabrėžia, kad šis nematomumas paverčia vieną raktą ilgalaikiu įsibrovimu. Kai mašinos kredencialas turi plačius leidimus ir niekas nestebi jo naudojimo, užpuolikui nereikia didinti privilegijų. Prieiga jau yra. Poveikio spindulys apima visą aplinką. Štai kodėl užpuolikai liko nepastebėti 60 dienų. Jie nesilaužė į sistemą. Jie naudojosi sistema taip, kaip ji buvo sukurta naudoti.

Antrinių grėsmių vykdytojų atsiradimas

Antroji grėsmių grupė, pasivadinusi „TheUSERS007“, taip pat teigė turėjusi prieigą prie „Novo Nordisk“ sistemų birželio 5–7 dienomis. Ši grupė taikėsi į duomenis, susijusius su DI tyrimais. Tai rodo, kad įvykus dideliam nuotėkiui, kiti veikėjai pradeda zonduoti tą pačią infrastruktūrą. Viena spraga kūrimo procese dažnai rodo platesnius sisteminius silpnumus. Jei vienas kūrėjas palieka raktą viešame skripte, tikėtina, kad kiti kūrėjai laikosi panašių nesaugių modelių. Atakos paviršius nėra statinis žemėlapis. Tai dinamiška aplinka, kurioje viena klaida pritraukia papildomą daugybės priešininkų dėmesį.

Šis antrinis įsibrovimas išryškina riziką vidiniams DI modeliams. Šie modeliai reprezentuoja farmacinių tyrimų ateitį. Jie sukurti remiantis ilgamečiais patentuotais duomenimis ir milžiniškomis skaičiavimo investicijomis. Šių modelių praradimas nėra tik duomenų saugumo pažeidimas. Tai konkurencinio pranašumo praradimas. Skaitmeninė aplinka neturi fizinių sienų. Kai sistemos logika atskleidžiama per pradinį kodą ir modelių svorius, žala tampa negrįžtama.

Perėjimas nuo reaguojančių įrankių prie proaktyvios tapatybės kontrolės

Norėdamos sumažinti šią riziką, organizacijos privalo pakeisti požiūrį į kūrėjų prieigą. Saugykla yra dėžė paslaptims. Tapatybės valdymas yra kontrolė, kas gali atidaryti dėžę ir kuriam laikui. Tikslas yra sutrumpinti kiekvienos paslapties galiojimo laiką. Jei raktas nustoja galioti po keturių valandų, nutekėjimas „JavaScript“ faile yra laikinas nepatogumas. Jei raktas galioja metus, nutekėjimas yra katastrofa.

Centralizuotas paslapčių valdymas yra būtinas žingsnis. Kiekviena tapatybė aplinkoje turėtų vadovautis mažiausių privilegijų principu. Tai reiškia, kad „GitHub“ raktas turėtų turėti prieigą tik prie konkrečių saugyklų, reikalingų užduočiai atlikti. Jis neturėtų turėti plačių administracinių teisių visoje organizacijoje. Automatinis keitimas užtikrina, kad kredencialai negyvuotų ilgiau nei jų paskirtis. Ši drausmė nesustabdo užpuoliko nuo rakto radimo, tačiau apriboja tai, ką jis gali su juo padaryti.

Praktiniai žingsniai procesų saugumui užtikrinti

Organizacijos turėtų pradėti nuo ne žmonių tapatybių inventorizacijos. Dauguma įmonių nežino, kiek API raktų ar paslaugų paskyrų egzistuoja jų aplinkoje. Negalite apsaugoti to, ko nematote. Ši inventorizacija turėtų apimti kiekvieno rakto apimtį ir paskutinio naudojimo datą. Daugelis organizacijų pastebi, kad didelė dalis jų aktyvių raktų nebėra reikalingi. Šios „našlaitės“ paslaptys yra itin vertingi taikiniai užpuolikams.

Mašinų tapatybių stebėjimas yra toks pat svarbus kaip ir žmonių prisijungimų stebėjimas. Saugumo komandos turi nustatyti bazinį normalų paslaugų paskyrų elgesį. Jei „GitHub“ raktas paprastai pasiekia tris saugyklas iš žinomo IP adreso ir staiga pradeda klonuoti 500 saugyklų iš kito regiono, sistema turėtų sugeneruoti įspėjimą. Aptikimas turi vykti tapatybės lygmenyje. Programinės įrangos lopymas yra svarbus, tačiau laikais, kai tapatybės yra pagrindinis taikinys, kredencialų naudojimo matomumas yra vienintelis būdas sugauti tylų įsibrovėlį.

Žingsniai skubiam rizikos mažinimui

1. Skenuokite visus viešai prieinamus resursus dėl atvirų paslapčių. Naudokite automatizuotus įrankius raktams, API raktams ir duomenų bazių kredencialams kliento pusės kode rasti.
2. Įdiekite trumpalaikius raktus. Pakeiskite ilgalaikius asmeninės prieigos raktus tiksliais, riboto laiko kredencialais visur, kur platforma tai palaiko.
3. Audituokite saugyklų leidimus. Pašalinkite administracinę prieigą iš kūrėjų raktų. Užtikrinkite, kad joks vienas raktas neturėtų galios klonuoti visos kodo bazės.
4. Įjunkite paslapčių skenavimą CI/CD procese. Blokuokite bet kokį kodo pateikimą (commit), kuriame yra atviro teksto paslaptis, kol jis nepasiekė saugyklos.
5. Stebėkite anomalią veiklą saugyklose. Nustatykite įspėjimus dėl masinio klonavimo ar prieigos iš neįprastų vietų.

Šis incidentas primena, kad perimetras pasislinko. Jis nebėra tinklo pakraštyje. Jis egzistuoja atskiro rakto ir konkrečios tapatybės lygmenyje. Jei nevaldysite šių tapatybių taip pat griežtai kaip savo gamybinių serverių, jūsų apsauga bus tik iliuzija.

Šaltiniai: NIST Cybersecurity Framework, MITRE ATT&CK Framework (Technique T1528: Steal Application Access Token), DataBreaches.net reporting.

Atsakomybės apribojimas: Šis straipsnis yra tik informacinio ir mokomojo pobūdžio. Jis nepakeičia profesionalaus kibernetinio saugumo audito ar incidentų valdymo paslaugų.