Jak czterdzieści minut skażonego kodu AI opróżniło cyfrowe skarbce technologicznych gigantów

Nowoczesny stos zabezpieczeń przedsiębiorstwa kosztuje miliony dolarów w opłatach licencyjnych i kosztach personelu. Organizacje te wdrażają najwyższej klasy skanery podatności i rygorystyczne kontrole dostępu, aby utrzymać solidny obwód bezpieczeństwa. Jednak czterdziestominutowe okno w marcu udowodniło, że pojedyncza złośliwa zależność w popularnym narzędziu AI wystarczy, aby całkowicie obejść te zabezpieczenia. Atak na łańcuch dostaw LiteLLM doprowadził do eksfiltracji terabajtów wrażliwych danych uwierzytelniających z niektórych z najbezpieczniejszych środowisk na planecie, w tym zarządzanych przez Microsoft, Amazon i Samsung.

Z perspektywy ryzyka, incydent ten ujawnia systemową porażkę w sposobie, w jaki weryfikujemy narzędzia używane do budowy oprogramowania opartego na AI. Naruszenie nie nastąpiło z powodu błędu w samej sztucznej inteligencji. Stało się tak, ponieważ infrastruktura DevOps, której używamy do wdrażania AI, jest krucha. Gdy programiści z 2500 organizacji pobrali wersje 1.82.7 i 1.82.8 LiteLLM z Python Package Index, nieświadomie zaprosili cyfrowego konia trojańskiego do swoich najbardziej wrażliwych systemów.

Paradoks bezpiecznego skanera

Najbardziej uderzającym aspektem tego naruszenia jest jego pochodzenie. Infekcja rozpoczęła się od ataku na łańcuch dostaw Trivy, powszechnie szanowanego skanera podatności open source. Organizacje używają Trivy konkretnie po to, aby znajdować luki w zabezpieczeniach. Infekując narzędzie mające zapewniać bezpieczeństwo, napastnicy zyskali pozycję absolutnego zaufania. Za kulisami atakujący wykorzystali błąd w sposobie, w jaki programiści Trivy zarządzali swoimi tokenami automatyzacji. Chociaż zespół próbował zrotować skompromitowany token, nie udało im się go całkowicie unieważnić przez dwadzieścia dni. To przeoczenie dało podmiotom zagrażającym trzytygodniowe okno na wymuszenie wprowadzenia złośliwego kodu do kolejnych kompilacji.

Infekcja ta rozprzestrzeniła się na inne pakiety oprogramowania, w tym KICS i Telnyx Python SDK, zanim trafiła do LiteLLM. Tworzy to paradoks architektoniczny, w którym same narzędzia zaprojektowane do wzmacniania powierzchni ataku stają się głównym wektorem eksploatacji. W moim doświadczeniu w audytowaniu środowisk chmurowych często zauważam, że zespoły bezkrytycznie ufają swoim narzędziom bezpieczeństwa. Zakładają, że jeśli skaner jest oficjalny i popularny, jego integralność jest gwarantowana. Ten incydent dowodzi, że takie założenie jest krytyczną podatnością.

Czterdziestominutowe okno do serca chmury

Rzeczywiste okno aktywnej infekcji dla LiteLLM było niezwykle krótkie. Przez zaledwie czterdzieści minut skompromitowane wersje były dostępne w oficjalnym repozytorium Python Package Index (PyPI). W tym krótkim czasie zautomatyzowane potoki CI/CD i programiści na całym świecie pobrali złośliwy kod. Szybkość nowoczesnego dostarczania oprogramowania oznacza, że czterdzieści minut to więcej niż wystarczająco dużo czasu, aby zainfekować setki tysięcy systemów.

Firmy zajmujące się bezpieczeństwem, CloudSEK i Hudson Rock, przeanalizowały skutki po uzyskaniu pliku o rozmiarze 195 TB zawierającego skradzione dane. Sama objętość informacji jest oszałamiająca. Zrzut zawiera klucze chmurowe, tokeny repozytoriów, klucze SSH i sekrety Kubernetes. Są to klucze główne do cyfrowego królestwa. Mówiąc proaktywnie, fakt, że czterdziestominutowe okno mogło przynieść terabajty danych, sugeruje, że zainfekowany kod był wysoce wydajny w identyfikowaniu i eksfiltracji wysokowartościowych sekretów.

Scraping pamięci i toksyczne aktywa przechowywanych sekretów

Mechanizm ataku był zarówno prosty, jak i niszczycielski. Skompromitowane wersje LiteLLM zawierały kod zaprojektowany w celu uzyskania dostępu do pamięci zainfekowanej maszyny. Większość programistów uważa, że jeśli sekret nie jest zapisany w pliku tekstowym, jest bezpieczny. To błąd. Złośliwy kod przeszukiwał zawartość pamięci systemowej, szukając zmiennych środowiskowych i aktywnych tokenów sesji.

Dane są toksycznym aktywem, gdy są obsługiwane niewłaściwie. W tym przypadku „dane” składały się z poświadczeń wymaganych do zarządzania 434 000 potoków CI/CD. Potoki te są liniami montażowymi rozwoju oprogramowania. Jeśli atakujący posiada poświadczenia do potoku, może wstrzyknąć własny kod do każdej przyszłej aktualizacji, którą firma udostępnia swoim klientom. Badacze zauważyli, że wiele z tych poświadczeń było zmiennymi w formacie tekstowym znajdującymi się w pamięci, całkowicie niechronionymi. Zebrane dane obejmują aktywne hasła do baz danych i klucze API stron trzecich, które nie posiadają żadnych informacji identyfikujących, co utrudnia badaczom nawet powiadomienie właściwych ofiar.

Nastoletnie zagrożenie i rzeczywistość krótkowzroczności DevOps

Odpowiedzialność za atak spoczywa na TeamPCP, grupie składającej się głównie z nastolatków. Chociaż ich metody mogły nie obejmować wysoce złożonych exploitów typu zero-day, ich sukces jest niezaprzeczalny. Niezależny badacz bezpieczeństwa Kevin Beaumont zauważył, że ci atakujący prześcigają organizacje, które są obecnie obsesyjnie skupione na pośpiesznym wprowadzaniu produktów AI na rynek.

Ten pośpiech tworzy krótkowzroczność DevOps. Organizacje priorytetyzują szybkość integracji AI nad podstawową higienę bezpieczeństwa łańcucha dostaw oprogramowania. Kiedy komunikuję się z etycznymi hakerami za pośrednictwem szyfrowanych kanałów, konsensus jest zawsze taki sam: nie potrzebujesz wyrafinowanego exploita, jeśli cel zostawia otwarte drzwi. Skupiając się na „kolejnej wielkiej rzeczy” w AI, wiele firm zignorowało podstawowy wymóg weryfikacji integralności swoich zależności.

Porażka niepełnej rotacji poświadczeń

Być może najbardziej niepokojącą częścią tej historii jest reaktywna postawa dotkniętych organizacji. Po ujawnieniu naruszenia kilka dużych firm technologicznych twierdziło, że zrotowało już swoje klucze i że incydent był nieistotny. Jednak wysiłki weryfikacyjne społeczności bezpieczeństwa opowiedziały inną historię.

Kevin Beaumont poinformował, że po tym, jak jedna z głównych amerykańskich firm technologicznych stwierdziła, że wszystkie poświadczenia zostały zrotowane, przetestował wyciekłe klucze w ich publicznej infrastrukturze. Prawie każdy klucz nadal działał. Sugeruje to powierzchowne podejście do reagowania na incydenty. Rotacja klucza to nie to samo co jego unieważnienie. Jeśli stary klucz jest nadal ważny w systemie pomocniczym lub środowisku legacy, naruszenie pozostaje aktywne. W przypadku naruszenia o takiej skali organizacja musi założyć, że każdy sekret dostępny dla zainfekowanego środowiska został skompromitowany. Częściowa rotacja to w zasadzie brak rotacji.

Praktyczne kroki dla odporności łańcucha dostaw

Jeśli Twoja organizacja korzysta z LiteLLM, Trivy lub jakiejkolwiek infrastruktury proxy AI, czas na pasywną reakcję minął. Ocena powierzchni ataku wymaga szczegółowego audytu każdego poświadczenia, które przeszło przez Twoje potoki CI/CD w ciągu ostatnich sześciu miesięcy.

Lista kontrolna natychmiastowych działań naprawczych:

• Weryfikacja wersji: Przeprowadź audyt swojego środowiska pod kątem wersji LiteLLM 1.82.7 i 1.82.8. Nawet jeśli od tego czasu dokonałeś aktualizacji, dane prawdopodobnie zostały wyeksfiltrowane w oknie, w którym te wersje były aktywne.
• Agresywne unieważnianie poświadczeń: Nie ograniczaj się do zmiany haseł. Unieważnij i zrotuj każdy klucz chmurowy (AWS/Azure/GCP), token konta usługi Kubernetes oraz osobisty token dostępu Git (PAT), który znajdował się w Twoich zmiennych środowiskowych.
• Logowanie audytowe i ruch wychodzący: Poszukaj nietypowego ruchu wychodzącego do nieznanych adresów IP w marcu. Eksfiltracja terabajtów danych powinna wywołać alerty filtrowania ruchu wychodzącego, gdyby były one prawidłowo skonfigurowane.
• Wdrażanie przypinania i haszowania: W przyszłości nie pozwalaj swoim potokom CI/CD na pobieranie „najnowszej” wersji pakietu. Używaj przypinania zależności (dependency pinning) i weryfikuj skróty SHA-256 każdej zewnętrznej biblioteki, zanim trafi ona do Twojego środowiska budowania.

Skala tego ataku wprowadza branżę w nową rzeczywistość. Obwód sieciowy to przestarzała fosa zamkowa w erze, w której dobrowolnie pobieramy kod z Internetu co kilka minut. Jako środek zaradczy organizacje muszą traktować każdą zewnętrzną zależność jako potencjalnie złośliwą, dopóki nie zostanie udowodnione inaczej. Bezpieczeństwo nie jest listą kontrolną, którą wypełnia się raz w roku; to ciągły proces weryfikacji.

Źródła:

• 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

Zastrzeżenie: Niniejszy artykuł służy wyłącznie celom informacyjnym i edukacyjnym i nie zastępuje profesjonalnego audytu cyberbezpieczeństwa ani usługi reagowania na incydenty.