Kā četrdesmit minūtes kompromitēta AI koda iztukšoja tehnoloģiju milžu digitālos seifus

Mūsdienīgs uzņēmuma drošības risinājumu kopums maksā miljonus dolāru licencēšanas un personāla izmaksās. Šīs organizācijas ievieš augstākā līmeņa ievainojamību skenerus un stingras piekļuves kontroles, lai uzturētu spēcīgu perimetru. Tomēr četrdesmit minūšu logs martā pierādīja, ka ar vienu vienīgu ļaunprātīgu atkarību populārā AI rīkā pietiek, lai pilnībā apietu šo aizsardzību. LiteLLM piegādes ķēdes uzbrukuma rezultātā tika eksfiltrēti terabaiti sensitīvu akreditācijas datu no dažām drošākajām vidēm uz planētas, tostarp tām, kuras pārvalda Microsoft, Amazon un Samsung.

No riska perspektīvas šis incidents atklāj sistēmisku kļūmi tajā, kā mēs pārbaudām rīkus, ko izmanto AI vadītas programmatūras izstrādei. Pārkāpums nenotika pašas mākslīgā intelekta kļūdas dēļ. Tas notika tāpēc, ka DevOps infrastruktūra, ko mēs izmantojam AI izvietošanai, ir trausla. Kad izstrādātāji 2500 organizācijās no Python pakotņu indeksa (PyPI) lejupielādēja LiteLLM versijas 1.82.7 un 1.82.8, viņi nejauši ielaida digitālu Trojas zirgu savās sensitīvākajās sistēmās.

Drošā skenera paradokss

Visvairāk satraucošais šī pārkāpuma aspekts ir tā izcelsme. Infekcija sākās ar piegādes ķēdes uzbrukumu Trivy — plaši atzītam atvērtā pirmkoda ievainojamību skenerim. Organizācijas izmanto Trivy tieši tam, lai atrastu drošības trūkumus. Inficējot rīku, kuram ir jāsniedz drošība, uzbrucēji ieguva absolūtas uzticības pozīciju. Aizkulisēs uzbrucēji izmantoja kļūdu tajā, kā Trivy izstrādātāji pārvaldīja savus automatizācijas marķierus (tokens). Lai gan komanda mēģināja rotēt kompromitēto marķieri, viņiem neizdevās to pilnībā atsaukt divdesmit dienas. Šī nolaidība deva draudu izpildītājiem trīs nedēļu logu, lai piespiedu kārtā ievietotu ļaunprātīgu kodu pakārtotajās būvēs.

Šī infekcija izplatījās uz citām programmatūras pakotnēm, tostarp KICS un Telnyx Python SDK, pirms nonāca LiteLLM. Tas rada arhitektonisku paradoksu, kur tieši tie rīki, kas paredzēti uzbrukuma virsmas nostiprināšanai, kļūst par galveno ekspluatācijas vektoru. Mana pieredze, auditējot mākoņvides, rāda, ka komandas bieži vien akli uzticas saviem drošības rīkiem. Viņi pieņem, ka, ja skeneris ir oficiāls un populārs, tā integritāte ir garantēta. Šis incidents pierāda, ka šāds pieņēmums ir kritiska ievainojamība.

Četrdesmit minūšu logs mākoņa sirdī

LiteLLM aktīvās inficēšanās logs bija pārsteidzoši īss. Tikai četrdesmit minūtes kompromitētās versijas bija pieejamas oficiālajā Python pakotņu indeksa (PyPI) krātuvē. Šajā īsajā laikā automatizētie CI/CD cauruļvadi un izstrādātāji visā pasaulē lejupielādēja ļaunprātīgo kodu. Mūsdienu programmatūras piegādes ātrums nozīmē, ka četrdesmit minūtes ir vairāk nekā pietiekami, lai inficētu simtiem tūkstošu sistēmu.

Drošības firmas CloudSEK un Hudson Rock analizēja sekas pēc tam, kad ieguva 195 TB lielu failu ar nozagtajiem datiem. Informācijas apjoms ir satriecošs. Izgāztuvē ir iekļautas mākoņa atslēgas, krātuvju marķieri, SSH atslēgas un Kubernetes noslēpumi. Šīs ir digitālās karaļvalsts galvenās atslēgas. Raugoties proaktīvi, fakts, ka četrdesmit minūšu logs varēja sniegt terabaitiem datu, liecina, ka inficētais kods bija ļoti efektīvs augstvērtīgu noslēpumu identificēšanā un eksfiltrēšanā.

Atmiņas pārmeklēšana un glabāto noslēpumu toksiskais aktīvs

Uzbrukuma mehānisms bija vienkāršs un vienlaikus postošs. Kompromitētās LiteLLM versijas saturēja kodu, kas paredzēts piekļuvei inficētās mašīnas atmiņai. Lielākā daļa izstrādātāju uzskata, ka, ja noslēpums nav saglabāts teksta failā, tas ir drošībā. Tie ir maldīgi priekšstati. Ļaunprātīgais kods pārmeklēja sistēmas atmiņas saturu, meklējot vides mainīgos un aktīvās sesijas marķierus.

Dati ir toksisks aktīvs, ja ar tiem rīkojas nepareizi. Šajā gadījumā "dati" sastāvēja no akreditācijas datiem, kas nepieciešami 434 000 CI/CD cauruļvadu pārvaldībai. Šie cauruļvadi ir programmatūras izstrādes montāžas līnijas. Ja uzbrucējam ir cauruļvada akreditācijas dati, viņš var ievietot savu kodu katrā turpmākajā atjauninājumā, ko uzņēmums izlaiž saviem klientiem. Pētnieki atzīmēja, ka daudzi no šiem akreditācijas datiem bija vienkārša teksta mainīgie, kas atradās atmiņā, pilnīgi neaizsargāti. Iegūtie dati ietver aktīvas datubāzu paroles un trešo pušu API atslēgas, kurām trūkst jebkādas identificējošas informācijas, kas pētniekiem apgrūtina pat pareizo upuru informēšanu.

Pusaudžu draudi un DevOps tuvredzības realitāte

Atbildība par uzbrukumu gulstas uz TeamPCP — grupu, kuras sastāvā galvenokārt ir pusaudži. Lai gan viņu metodes, iespējams, neietvēra augstas sarežģītības nulles dienas (zero-day) ekspluatācijas, viņu panākumi ir nenoliedzami. Neatkarīgais drošības pētnieks Kevins Bomonts (Kevin Beaumont) atzīmēja, ka šie uzbrucēji apsteidz organizācijas, kuras pašlaik ir pārņemtas ar steigu laist tirgū AI produktus.

Šī steiga rada DevOps tuvredzību. Organizācijas par prioritāti izvirza AI integrācijas ātrumu, nevis programmatūras piegādes ķēdes drošības pamathigiēnu. Kad es sazeros ar "balto cepuru" hakeriem, izmantojot šifrētus kanālus, konsenss vienmēr ir viens un tas pats: jums nav nepieciešama sarežģīta ekspluatācija, ja mērķis atstāj durvis neaizslēgtas. Koncentrējoties uz "nākamo lielo lietu" AI jomā, daudzi uzņēmumi ignorēja pamatprasību pārbaudīt savu atkarību integritāti.

Nepilnīgas akreditācijas datu rotācijas neveiksme

Iespējams, visvairāk satraucošā šī stāsta daļa ir skarto organizāciju reaktīvā nostāja. Pēc tam, kad pārkāpums tika atklāts, vairāki lieli tehnoloģiju uzņēmumi apgalvoja, ka tie jau ir rotējuši savas atslēgas un ka incidents ir "nekas īpašs". Tomēr drošības kopienas veiktās pārbaudes liecināja par ko citu.

Kevins Bomonts ziņoja, ka pēc tam, kad viens liels ASV tehnoloģiju uzņēmums apgalvoja, ka visi akreditācijas dati ir rotēti, viņš pārbaudīja nopludinātās atslēgas pret to publiski pieejamo infrastruktūru. Gandrīz katra atslēga joprojām darbojās. Tas liecina par virspusēju pieeju incidentu novēršanai. Atslēgas rotēšana nav tas pats, kas tās atsaukšana. Ja vecā atslēga joprojām ir derīga sekundārajā sistēmā vai mantotā vidē, pārkāpums joprojām ir aktīvs. Šāda mēroga pārkāpuma gadījumā organizācijai ir jāpieņem, ka katrs noslēpums, kas pieejams inficētajai videi, ir kompromitēts. Daļēja rotācija būtībā nav nekāda rotācija.

Praktiski soļi piegādes ķēdes noturībai

Ja jūsu organizācija izmanto LiteLLM, Trivy vai jebkuru AI starpniekservera infrastruktūru, pasīvas reakcijas laiks ir pagājis. Uzbrukuma virsmas novērtēšanai ir nepieciešams detalizēts audits katram akreditācijas datam, kas pēdējo sešu mēnešu laikā ir izgājis cauri jūsu CI/CD cauruļvadiem.

Tūlītēju seku mazināšanas pasākumu saraksts:

• Pārbaudiet versijas: Auditējiet savu vidi, meklējot LiteLLM versijas 1.82.7 un 1.82.8. Pat ja kopš tā laika esat veikuši atjaunināšanu, dati, visticamāk, tika eksfiltrēti tajā laikā, kad šīs versijas bija aktīvas.
• Agresīva akreditācijas datu atsaukšana: Neveiciet tikai paroļu atjaunināšanu. Invalidējiet un rotējiet katru mākoņa atslēgu (AWS/Azure/GCP), Kubernetes pakalpojuma konta marķieri un Git personīgās piekļuves marķieri (PAT), kas atradās jūsu vides mainīgajos.
• Audita žurnālfaili un izejošā plūsma: Meklējiet neparastu izejošo trafiku uz nezināmām IP adresēm marta mēnesī. Terabaitiem datu eksfiltrācijai vajadzēja izraisīt izejas filtrēšanas brīdinājumus, ja tie būtu pareizi konfigurēti.
• Ieviesiet fiksēšanu (pinning) un jaukšanu (hashing): Turpmāk neļaujiet saviem CI/CD cauruļvadiem lejupielādēt pakotnes "jaunāko" versiju. Izmantojiet atkarību fiksēšanu un pārbaudiet katras ārējās bibliotēkas SHA-256 jaucējkodus, pirms tā nonāk jūsu būvēšanas vidē.

Šī uzbrukuma mērogs ieved nozari jaunā realitātē. Tīkla perimetrs ir novecojis pils grāvis laikmetā, kad mēs brīvprātīgi lejupielādējam kodu no interneta ik pēc dažām minūtēm. Kā pretpasākumu organizācijām ir jāizturas pret katru ārējo atkarību kā pret potenciāli ļaunprātīgu, līdz tiek pierādīts pretējais. Drošība nav kontrolsaraksts, ko aizpildāt reizi gadā; tas ir nepārtraukts pārbaudes process.

Avoti:

• 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

Atruna: Šis raksts ir paredzēts tikai informatīviem un izglītojošiem nolūkiem un neaizstāj profesionālu kiberdrošības auditu vai incidentu novēršanas pakalpojumu.