LiteLLM-ketjun hyökkäys: muistivarastojen laaja vuoto

Neljäkymmentä minuuttia. Siinä ajassa tänä maaliskuussa hyökkäjät pystyivät muuttamaan rutiininomaiset pakettien lataukset valtavaksi tietovarkaudeksi.

Kehittäjät ja insinöörit, jotka latasivat sellaisten julkaisujen luulemiaan laillisia versioita avoimen lähdekoodin AI-integraatiokirjastosta LiteLLM (versiot 1.82.7 ja 1.82.8), saivatkin koodin, johon oli upotettu muistia kaiveleva takaportti. Kun haittaohjelma suoritettiin, se kävi läpi järjestelmän RAM-muistin, keräsi sieltä löydetyt salaisuudet ja striimasi ne hyökkäjien hallinnoimille palvelimille. Lopputulos: useiden teratavujen arvosta arkaluonteista aineistoa vietiin joidenkin maailman suurimpien yritysten ääreistä.

Miten pakettien kompromettointi muuttui globaaliksi toimitusketjukatastrofiksi

Tietoturvatutkijat löytivät myöhemmin noin 195 teratavun käyttöjättiläisen tietokannan. Siellä oli pilvipalvelujen avaimia, konttirekisterin tokeneita, SSH-avaimia ja aktiivisia tietokantasalasanoja, jotka liittyivät yli 2 500 organisaatioon. Aineisto sisälsi myös tunnistetietoja yli 434 000 CI/CD-putken merkinnästä, joista monet olivat paljastuneet anteliaiden julkisten putkikonfiguraatioiden vuoksi. Lyhyesti: kun tunnukset olivat muistissa tai putkimuuttujissa, ne olivat vaarassa.

Tunkeutuminen ei alkanut LiteLLM:stä. Tutkijoiden yhdistelemien teknisten jäljitysten mukaan hyökkäjät kompromettoivat ensin laajasti käytetyn haavoittuvuusskannerin Trivyn ja käyttivät tuota jalansijaa myrkyttääkseen siihen liitetyjä projekteja, kuten KICS:ia ja Telnyxin Python SDK:ta. Tästä myrkytetty ketju levisi LiteLLM:n julkaistuihin paketteihin.

Operaation vetäytykseen on ilmoittautunut ryhmittymä, joka kutsuu itseään TeamPCP:ksi. Useat itsenäiset tietoturvatiimit ovat todentaneet hyökkäyskuvion ja aikajanan, jättäen vähän epäilystä siitä, että kyse oli koordinoidusta toimitusketjukampanjasta eikä erillisestä haavoittuvuudesta.

Kuka joutui kohteeksi? Vuoto on laaja. Teknologiayhtiöt ja kriittisen infrastruktuurin toimijat nousevat ilmoituksissa esiin: Nvidia, Amazon Web Services, Samsung, Cisco, Siemens, Volkswagen, Reuters, FedEx, Epic Games, X (aiemmin Twitter), HP, Philips ja Deutsche Bank ovat mukana yrityksissä, joiden paljastuneita avaimia on vahvistettu korkealla varmuudella.

Miksi tilanne eskaloitui niin nopeasti? Taustalla oli kaksi nivoutunutta syytä: halu nopeasti omaksua AI-työkalut ja hauras luottamismalli avoimen lähdekoodin toimitusketjuissa. Organisaatiot, jotka halusivat nopeasti integroida tekoälyominaisuuksia, asentivat kirjastoja ja automaatioputkistoja vain minimisella auditoinnilla. Ympäristömuuttujissa pidetyt tai build-runnerien muistissa lymyilleet salaisuudet tarjosivat helpon saaliin.

Hyökkäyksellä oli myös tekninen syy tehokkuuteensa. Haitalliset LiteLLM-kokoonpanot suorittivat muistin skannauksen, joka dumppasi kaikki muistiin ladatut tunnistetiedot ja lähetti ne keräilijälle. Se tarkoittaa, että jopa lyhyesti deployn aikana käytetyt epäpäättömät tokenit siepattiin. Lyhytkestoinen ei ole turvallinen, jos hyökkäjä voi lukea RAM-muistia.

Peruuta ja vaihda kaikki paljastuneet avaimet ja tokenit välittömästi.

Tämä yksittäinen kehotus on se, jota tietoturvatiimit toistavat nyt. Korjaustoimet ovat kuitenkin sotkuisia. Koska monet vuotaneet salaisuudet havaittiin ilman verkkotunnusmerkintäjä tai organisaatiotunnisteita, puolustajilla on tuskallinen inventaariohaaste: tunnistaa, mitä avaimia kukin palvelu oli luonut, ja sitten peruuttaa, vaihtaa ja uudelleenkonfiguroida ne. Monille kehitystiimeille se tarkoittaa CI/CD-runnerien rakentamista uudelleen, upotettujen salaisuuksien korvaamista lyhytkestoisilla tunnuksilla ja salaisuuksien skannaus-työkalujen omaksumista, jotka havaitsevat vuodot ennen tuotantoon menoa.

Opit ovat selvät ja kovia. Ensinnäkin riippuvuuksien alkuperä on merkityksellinen. Helppokäyttöisten kirjastojen kiireellinen asentaminen ilman tarkistussummien ja julkaisijoiden identiteettien varmistamista luo toimitusketjuriskin. Toiseksi salaisuuksia ei pidä pitää seltekstimuotoisina putkimuuttujina tai pitkäkestoisina tunnuksina. Käytä mahdollisuuksien mukaan lyhytaikaisia palveluidentiteettejä ja kuormituspohjaista pääsyä. Kolmanneksi avoimen lähdekoodin ekosysteemi tarvitsee vahvempia suojakaiteita: toistettavat buildit, allekirjoitetut paketit ja parempi julkaisijahygienia vähentävät tämän tyyppisten hyökkäysten vaikutusta.

Organisaatioille, jotka käyttävät LiteLLM:aa tai muita liitäntiöhän kuuluvia työkaluja, välittömiin toimiin tulisi kuulua:

• Kartoitus kaikista tunnuksista ja tokeneista, jotka olisivat voineet ladata build- tai ajonaikaiseen muistiin.
• Peruuta ja vaihda nämä avaimet, anna uudet tunnukset pienimmän oikeuden periaatteella.
• Tarkasta CI/CD-putket ja korvaa kaikki seltekstimuotoiset salaisuudet holviin perustuvilla lyhytaikaisilla tokeneilla.
• Varmista pakettien eheys tarkistussummia ja mieluummin luotettujen ylläpitojen allekirjoitettuja julkaisuja suosien.
• Seuraa poikkeavaa ulospäin suuntautuvaa liikennettä build-infrastruktuurista, joka voi viitata jäljellä oleviin takaportteihin.

Hyökkäys on herättelykutsu. AI-työkalujen integrointi voi tuoda merkittäviä tuottavuushyötyjä. Mutta kun nopeus menee turvallisuuden edelle, seuraukset eivät ole teoreettisia. Tunnukset ovat valuuttaa. Kun ne vuotavat, ne mahdollistavat eskalaation, lateraalisen liikkuvuuden ja laajamittaisen tietovarkauden. Tiimien on oletettava kompromissin mahdollisuus ja rakennettava järjestelmiä, jotka minimoivat sen, mitä hyökkäjä voi nappaista yhdessä istunnossa.

Odota yksityiskohtaisempia ilmoituksia tietoturvayrityksiltä niiden jatkaessa noin 195 teratavun aarrearkun järjestelyä ja vaikuttuneiden organisaatioiden kartoittamista. Toistaiseksi turvallisin toimintatapa on nopea, koordinoitu avainten vaihto yhdistettynä forensiikka-arvioon build- ja julkaisuprosesseista.