Kaip keturiasdešimt minučių kompromituoto DI kodo ištuštino technologijų milžinų skaitmeninius skliautus

Šiuolaikinis įmonės saugumo priemonių rinkinys kainuoja milijonus dolerių licencijavimo ir personalo mokesčių. Šios organizacijos diegia aukščiausio lygio pažeidžiamumų skenerius ir griežtą prieigos kontrolę, kad išlaikytų tvirtą perimetrą. Tačiau kovo mėnesį pasitaikęs keturiasdešimties minučių langas įrodė, kad vienos kenkėjiškos priklausomybės populiariame DI įrankyje pakanka, jog ši apsauga būtų visiškai apeita. „LiteLLM“ tiekimo grandinės ataka lėmė terabaitų jautrių prisijungimo duomenų eksfiltraciją iš kai kurių saugiausių aplinkų planetoje, įskaitant tas, kurias valdo „Microsoft“, „Amazon“ ir „Samsung“.

Rizikos požiūriu šis incidentas atskleidžia sisteminę nesėkmę tame, kaip mes tikriname įrankius, naudojamus DI valdomai programinei įrangai kurti. Pažeidimas įvyko ne dėl paties dirbtinio intelekto trūkumo. Jis įvyko todėl, kad „DevOps“ infrastruktūra, kurią naudojame DI diegimui, yra trapi. Kai 2 500 organizacijų kūrėjai iš „Python Package Index“ atsisiuntė „LiteLLM“ 1.82.7 ir 1.82.8 versijas, jie netyčia įsileido skaitmeninį Trojos arklį į savo jautriausias sistemas.

Saugaus skenerio paradoksas

Labiausiai stulbinantis šio pažeidimo aspektas yra jo kilmė. Infekcija prasidėjo nuo tiekimo grandinės atakos prieš „Trivy“ – plačiai pripažintą atvirojo kodo pažeidžiamumų skenerį. Organizacijos naudoja „Trivy“ būtent saugumo spragoms rasti. Užkrėtę įrankį, skirtą saugumui užtikrinti, užpuolikai įgijo absoliutaus pasitikėjimo poziciją. Užkulisiuose užpuolikai pasinaudojo klaida, kaip „Trivy“ kūrėjai valdė savo automatizavimo žetonus (tokens). Nors komanda bandė pakeisti kompromituotą žetoną, jiems nepavyko jo visiškai atšaukti dvidešimt dienų. Šis aplaidumas suteikė grėsmės sukėlėjams trijų savaičių langą priverstinai įkelti (force-push) kenkėjišką kodą į tolesnes versijas.

Ši infekcija išplito į kitus programinės įrangos paketus, įskaitant KICS ir „Telnyx Python SDK“, kol galiausiai pateko į „LiteLLM“. Tai sukuria architektūrinį paradoksą, kai patys įrankiai, skirti sustiprinti atakos paviršių, tampa pagrindiniu eksploatavimo vektoriumi. Remdamasis savo patirtimi audituojant debesijos aplinkas, dažnai pastebiu, kad komandos besąlygiškai pasitiki savo saugumo įrankiais. Jos daro prielaidą, kad jei skeneris yra oficialus ir populiarus, jo vientisumas yra garantuotas. Šis incidentas įrodo, kad tokia prielaida yra kritinis pažeidžiamumas.

Keturiasdešimties minučių langas į debesijos širdį

Tikrasis aktyvios „LiteLLM“ infekcijos langas buvo stebėtinai trumpas. Tik keturiasdešimt minučių kompromituotos versijos buvo prieinamos oficialioje „Python Package Index“ (PyPI) saugykloje. Per tą trumpą laiką automatizuoti CI/CD konvejeriai ir kūrėjai visame pasaulyje atsisiuntė kenkėjišką kodą. Šiuolaikinio programinės įrangos pristatymo greitis reiškia, kad keturiasdešimt minučių yra daugiau nei pakankamai laiko užkrėsti šimtus tūkstančių sistemų.

Saugumo įmonės „CloudSEK“ ir „Hudson Rock“ išanalizavo pasekmes gavusios 195 TB failą su pavogtais duomenimis. Informacijos kiekis yra stulbinantis. Duomenų rinkinyje yra debesijos raktai, saugyklų žetonai, SSH raktai ir „Kubernetes“ paslaptys. Tai yra pagrindiniai raktai į skaitmeninę karalystę. Žvelgiant proaktyviai, faktas, kad keturiasdešimties minučių langas galėjo duoti terabaitus duomenų, rodo, kad užkrėstas kodas buvo itin efektyvus atpažįstant ir eksfiltruojant didelės vertės paslaptis.

Atminties nuskaitymas ir toksiškas saugomų paslapčių turtas

Atakos mechanizmas buvo paprastas ir triuškinantis. Kompromituotose „LiteLLM“ versijose buvo kodas, skirtas pasiekti užkrėstos mašinos atmintį. Dauguma kūrėjų mano, kad jei paslaptis nėra išsaugota tekstiniame faile, ji yra saugi. Tai klaidinga nuomonė. Kenkėjiškas kodas nuskaitė sistemos atminties turinį, ieškodamas aplinkos kintamųjų ir aktyvių sesijų žetonų.

Duomenys tampa toksišku turtu, kai su jais elgiamasi netinkamai. Šiuo atveju „duomenys“ susidėjo iš prisijungimo duomenų, reikalingų valdyti 434 000 CI/CD konvejerių. Šie konvejeriai yra programinės įrangos kūrimo surinkimo linijos. Jei užpuolikas turi konvejerio prisijungimo duomenis, jis gali įterpti savo kodą į kiekvieną būsimą atnaujinimą, kurį įmonė išleidžia savo klientams. Tyrėjai pastebėjo, kad daugelis šių prisijungimo duomenų buvo paprasto teksto kintamieji, esantys atmintyje, visiškai neapsaugoti. Surinkti duomenys apima aktyvius duomenų bazių slaptažodžius ir trečiųjų šalių API raktus, kuriems trūksta bet kokios identifikuojančios informacijos, todėl tyrėjams sunku net pranešti atitinkamoms aukoms.

Paauglių grėsmė ir DevOps trumparegystės realybė

Atsakomybė už ataką tenka „TeamPCP“ – grupei, kurią daugiausia sudaro paaugliai. Nors jų metodai galbūt neapėmė itin sudėtingų nulinės dienos (zero-day) išnaudojimų, jų sėkmė yra neginčijama. Nepriklausomas saugumo tyrėjas Kevin Beaumont pažymėjo, kad šie užpuolikai lenkia organizacijas, kurios šiuo metu yra apsėstos skubėjimo pateikti DI produktus į rinką.

Šis skubėjimas sukuria „DevOps“ trumparegystę. Organizacijos teikia pirmenybę DI integracijos greičiui, o ne pagrindinei programinės įrangos tiekimo grandinės saugumo higienai. Kai bendrauju su etiškaissiais hakeriais per šifruotus kanalus, konsensusas visada yra tas pats: jums nereikia sudėtingo išnaudojimo būdo, jei taikinys palieka duris neužrakintas. Susitelkdamos į „kitą didelį dalyką“ DI srityje, daugelis įmonių ignoravo pagrindinį reikalavimą – tikrinti savo priklausomybių vientisumą.

Nepilno prisijungimo duomenų rotavimo nesėkmė

Ko gero, labiausiai nerimą kelianti šios istorijos dalis yra reaktyvi paveiktų organizacijų laikysena. Atskleidus pažeidimą, kelios didelės technologijų įmonės teigė, kad jos jau rotavo savo raktus ir kad incidentas buvo „niekinis“. Tačiau saugumo bendruomenės patikros pastangos atskleidė kitokią realybę.

Kevin Beaumont pranešė, kad po to, kai viena didelė JAV technologijų įmonė pareiškė, jog visi prisijungimo duomenys buvo rotuoti, jis išbandė nutekėjusius raktus su jų viešai prieinama infrastruktūra. Beveik kiekvienas raktas vis dar veikė. Tai rodo paviršutinišką požiūrį į reagavimą į incidentus. Rakto rotavimas nėra tas pats, kas jo atšaukimas. Jei senasis raktas vis dar galioja antrinėje sistemoje arba paliktoje (legacy) aplinkoje, pažeidimas išlieka aktyvus. Tokio masto pažeidimo atveju organizacija privalo daryti prielaidą, kad kiekviena paslaptis, prieinama užkrėstai aplinkai, yra kompromituota. Dalinis rotavimas iš esmės yra visai ne rotavimas.

Praktiniai žingsniai tiekimo grandinės atsparumui užtikrinti

Jei jūsų organizacija naudoja „LiteLLM“, „Trivy“ ar bet kokią DI tarpinio serverio (proxy) infrastruktūrą, pasyvaus reagavimo laikas praėjo. Atakos paviršiaus įvertinimui reikalingas išsamus kiekvieno prisijungimo duomens, praėjusio per jūsų CI/CD konvejerius per pastaruosius šešis mėnesius, auditas.

Skubus švelninimo priemonių kontrolinis sąrašas:

• Patikrinkite versijas: Audituokite savo aplinką dėl „LiteLLM“ 1.82.7 ir 1.82.8 versijų. Net jei nuo to laiko atnaujinote, duomenys tikriausiai buvo eksfiltruoti tuo metu, kai tos versijos buvo aktyvios.
• Agresyvus prisijungimo duomenų atšaukimas: Ne tik atnaujinkite slaptažodžius. Panaikinkite ir rotuokite kiekvieną debesijos raktą (AWS/Azure/GCP), „Kubernetes“ paslaugų paskyros žetoną ir „Git“ asmeninį prieigos žetoną (PAT), kuris buvo jūsų aplinkos kintamuosiuose.
• Audito žurnalai ir išėjimo srautas: Ieškokite neįprasto išsiunčiamo srauto į nežinomus IP adresus kovo mėnesį. Terabaitų duomenų eksfiltracija turėjo suaktyvinti išėjimo filtravimo įspėjimus, jei jie būtų tinkamai sukonfigūruoti.
• Įdiekite fiksavimą (pinning) ir maišą (hashing): Ateityje neleiskite savo CI/CD konvejeriams imti „naujausios“ paketo versijos. Naudokite priklausomybių fiksavimą ir patikrinkite kiekvienos išorinės bibliotekos SHA-256 maišos reikšmes prieš jai patenkant į jūsų kūrimo aplinką.

Šios atakos mastas stumia pramonę į naują realybę. Tinklo perimetras yra pasenęs pilies griovys eroje, kai mes savanoriškai atsisiunčiame kodą iš interneto kas kelias minutes. Kaip priešpriešinę priemonę organizacijos privalo vertinti kiekvieną išorinę priklausomybę kaip potencialiai kenkėjišką, kol neįrodyta priešingai. Saugumas nėra kontrolinis sąrašas, kurį užpildote kartą per metus; tai nenutrūkstamas verifikavimo procesas.

Šaltiniai:

• CloudSEK Threat Intelligence Report on LiteLLM Supply Chain Attack
• Hudson Rock Analysis of TeamPCP Data Dump
• MITRE ATT&CK Framework: Supply Chain Compromise (T1195)
• NIST Software Supply Chain Security Guidance

Atsakomybės apribojimas: Šis straipsnis yra skirtas tik informaciniams ir edukaciniams tikslams ir nepakeičia profesionalaus kibernetinio saugumo audito ar reagavimo į incidentus paslaugų.