Fork bomb nas uratował

Złośliwe oprogramowanie w LiteLLM 1.82.8 zawierało plik .pth, który uruchamiał się przy każdym starcie Python. Zbierał klucze SSH, dane uwierzytelniające do chmury, portfele kryptowalut i sekrety CI/CD, szyfrował je kluczem RSA o długości 4096 bitów i eksfiltrował archiwum do domeny kontrolowanej przez atakującego. Ładunek był dobrze zaprojektowany. Szyfrowanie było solidne. Eksfiltracja przebiegała czysto.¹ Ten incydent jest częścią mojej serii o bezpieczeństwie agentów, poświęconej rzeczywistym awariom, które kształtują sposób budowania zaufania w systemach zautomatyzowanych.

Plik .pth uruchamiał również proces potomny Python, aby wykonać swoją pracę. Ten proces potomny ponownie wyzwalał plik .pth. Co uruchamiało kolejny proces potomny. Który wyzwalał go ponownie. Wykładnicza fork bomba, która w ciągu sekund pochłaniała 100% CPU i ponad 5 GB RAM.²

Fork bomba była błędem. Atakujący nie zamierzał, by złośliwe oprogramowanie było widoczne. Poprawnie zaimplementowana wersja działałaby cicho przy każdym wywołaniu Python na każdym zainfekowanym systemie, potencjalnie przez tygodnie. Zamiast tego programiści zauważyli, że ich maszyny zaczynają się zawieszać, zbadali sprawę i odkryli narzędzie do kradzieży danych uwierzytelniających. PyPI poddał kwarantannie obie wersje 46 minut po publikacji.¹

Czterdzieści sześć tysięcy instalacji w czterdzieści sześć minut. Mechanizmem wykrycia był błąd implementacyjny w złośliwym oprogramowaniu.

TL;DR

• Błąd: Narzędzie do kradzieży danych uwierzytelniających w LiteLLM 1.82.8 miało błąd fork bomby, przez który zainfekowane maszyny zaczynały się zawieszać. Bez tego błędu narzędzie działałoby cicho przez tygodnie.
• Luka: Analiza statyczna, monitoring behawioralny i przegląd kodu — wszystko zawiodło. Każda warstwa detekcji zakładała, że inna warstwa wykryje atak. Żadna tego nie zrobiła.³
• Krzywa: Jakość atakujących rośnie z każdą iteracją. Technika .pth jest teraz publicznie udokumentowana. Następny atakujący dziedziczy ją bez błędu.
• Co działa bez szczęścia: Sprawdzanie wieku domeny przy ruchu wychodzącym, bazowanie behawioralne dla instalacji pakietów, kanarkowe pliki w systemie plików, izolacja instalacji. Każde z tych rozwiązań działa niezależnie od jakości ładunku.
• Asymetria: To obrońca wybiera środowisko. Jeśli środowisko instalacyjne nie zawiera danych uwierzytelniających do kradzieży, nawet doskonały ładunek nie zbierze niczego.

Mieliśmy szczęście

Usuńmy fork bombę z ładunku — atak powiedzie się w ciszy. Plik .pth uruchamia się przed jakimkolwiek importem, przed kodem aplikacji, przed jakimkolwiek sandboxem na poziomie Python. Nie ma punktu przechwycenia. Nie ma wpisu w logach. Narzędzie do kradzieży danych uwierzytelniających uruchamia się, szyfruje, eksfiltruje, a proces Python kontynuuje normalną pracę. Programista nic nie widzi. Pipeline CI nic nie widzi. Skaner bezpieczeństwa nic nie widzi, ponieważ to właśnie skaner bezpieczeństwa był wektorem ataku.³

Historia wykrycia LiteLLM 1.82.8 to nie „nasz monitoring to wychwycił”. Historia wykrycia to „atakujący wypuścił błąd”.

To nie jest komfortowa podstawa dla bezpieczeństwa łańcucha dostaw. Jak argumentuję w artykule sandbox twojego agenta to tylko sugestia, granice, które zakładamy między zaufanym a niezaufanym kodem, są znacznie bardziej porowate, niż większość zespołów zdaje sobie sprawę.

Krzywa jakości atakujących

Jakość oprogramowania rośnie z iteracją. Dotyczy to zarówno atakujących, jak i obrońców. Kampania TeamPCP uderzyła w pięć ekosystemów w ciągu jednego tygodnia: GitHub Actions, Docker Hub, npm, Open VSX i PyPI.⁴ Każde przejęcie ekosystemu wykorzystywało dane uwierzytelniające pozyskane z poprzedniego. Kampania wykazała zaawansowanie operacyjne: rejestracja domeny 24 godziny przed dostarczeniem ładunku, przejęcie tagów na mutowalnych referencjach oraz obejście rotacji danych uwierzytelniających przez niepełne zmiany kluczy Aqua Security.

Fork bomba była jedynym błędem w skądinąd kompetentnej operacji. Następna kampania tego błędu nie popełni. Technika pliku .pth jest teraz publicznie udokumentowana, przeanalizowana przez CrowdStrike, Microsoft, Wiz i Palo Alto.³ Następny atakujący dziedziczy technikę bez błędu.

Zdolności ofensywne podlegają tej samej krzywej doskonalenia co zdolności defensywne. Technika jest publiczna. Analiza jest publiczna. Następny atakujący zaczyna tam, gdzie TeamPCP skończył. W artykule co naprawdę się psuje bez nadzoru analizuję, co ta krzywa oznacza dla systemów autonomicznych.

Wykrywanie nie może zależeć od błędów atakującego

Obecny model wykrywania w łańcuchu dostaw ma trzy warstwy i wszystkie trzy zawiodły w przypadku LiteLLM:

Analiza statyczna zawiodła. Plik .pth to legalna funkcja Python. Ładunek był podwójnie zakodowany w base64 i dekodowany w czasie wykonania. Skanery statyczne szukające znanych złośliwych wzorców nie znajdują niczego, ponieważ wzorzec jest nowy.

Monitoring behawioralny zawiódł. Narzędzie do kradzieży danych uwierzytelniających wykonało jedno wychodzące żądanie HTTPS POST do domeny wyglądającej jak legalna usługa (models.litellm.cloud). Monitoring ruchu wychodzącego sprawdzający domeny docelowe musiałby wiedzieć, że ta konkretna domena została zarejestrowana 24 godziny wcześniej. Większość monitorów ruchu wychodzącego nie sprawdza wieku domeny.

Przegląd kodu zawiódł. Złośliwe wersje zostały opublikowane bezpośrednio na PyPI, omijając pipeline CI/CD GitHub. Nie było pull requesta do przeglądu. Nie było diffa do inspekcji. Atakujący użył skradzionych danych uwierzytelniających do publikacji, aby przesłać gotowe pakiety.

Każda warstwa detekcji zakładała, że inna część łańcucha ataku wyłapie problem. Żadna tego nie zrobiła. Fork bomba wyłapała problem.

Co faktycznie wykrywa ciche złośliwe oprogramowanie

Jeśli nie można polegać na błędach atakujących, potrzebne są mechanizmy detekcji działające niezależnie od jakości implementacji.

Sprawdzanie wieku domeny przy żądaniach wychodzących. Domena eksfiltracyjna została zarejestrowana 24 godziny przed atakiem. Reguła firewalla oznaczająca żądania wychodzące do domen młodszych niż 7 dni wykryłaby to. Reguła jest prosta, współczynnik fałszywych alarmów jest do opanowania i wykrywa najczęstszy wzorzec eksfiltracji.

Bazowanie behawioralne dla procesów Python. Polecenie pip install, które nagle wykonuje żądania HTTPS POST do nieznanej domeny, jest anomalią. Monitoring behawioralny na poziomie procesów, śledzący aktywność sieciową podczas instalacji pakietów, oznaczyłby to.

Kanarkowe pliki w systemie plików. Umieść fałszywy klucz SSH w kanarkowej ścieżce i fałszywe dane uwierzytelniające AWS w innej kanarkowej ścieżce. Monitoruj każdy proces, który odczytuje te pliki. Narzędzie do kradzieży danych uwierzytelniających przeszukujące standardowe ścieżki odczyta kanary. Legalny proces tego nie zrobi. Kanar wyzwala alert, zanim eksfiltracja się zakończy.

Izolacja instalacji. Uruchom pip install w środowisku bez dostępu do prawdziwych danych uwierzytelniających. Następnie skopiuj zainstalowane pakiety do środowiska produkcyjnego. Plik .pth uruchamia się podczas własnego procesu Python narzędzia pip, co oznacza, że narzędzie do kradzieży danych uwierzytelniających działa podczas instalacji. Jeśli środowisko instalacyjne nie zawiera danych uwierzytelniających do kradzieży, atak nie zbiera niczego.

Żaden z tych mechanizmów nie wymaga, by atakujący popełnił błąd. Działają niezależnie od jakości ładunku. Wzorzec architektoniczny — projektowanie środowisk, w których nawet doskonały atak nie zbiera niczego — to ta sama zasada, która stoi za artykułem wdrażaj i broń: paradoks zaufania agentów.

Asymetria

Obrona ma jedną przewagę strukturalną: to obrońca wybiera środowisko. Atakujący musi działać w ramach środowiska, w którym pakiet jest instalowany. Jeśli to środowisko nie zawiera danych uwierzytelniających, nie ma dostępu do sieci i posiada kanarkowe pliki, ładunek odnosi sukces techniczny, ale ponosi porażkę operacyjną.

Atak na LiteLLM zadziałał, ponieważ środowisko instalacyjne było tym samym środowiskiem, które przechowywało dane uwierzytelniające do publikacji, klucze SSH i tokeny chmurowe. Fork bomba była nieistotna dla architektury bezpieczeństwa. Była istotna dla osi czasu.

Następnym razem fork bomby nie będzie. Dane uwierzytelniające nadal będą w tym samym środowisku co menedżer pakietów. Pytanie brzmi, czy zmienisz środowisko, zanim następny atakujący wypuści czysty ładunek. Moja analiza architektury agenta Ralph pokazuje, jak strukturyzować systemy agentowe, aby skompromitowane komponenty nie mogły eskalować poza swoją granicę izolacji.

FAQ

Dlaczego atakujący nie przetestował fork bomby?

Uruchomienie procesu potomnego przez plik .pth to rozsądny wybór implementacyjny dla wykonania ładunku bez blokowania procesu nadrzędnego. Rekurencyjne wyzwalanie to subtelna interakcja między .pth a inicjalizacją site.py w Python. To rodzaj błędu, który pojawia się w testach integracyjnych, ale nie w testach jednostkowych, a autorzy złośliwego oprogramowania mają ograniczone możliwości testowania integracyjnego w realistycznych środowiskach.

Czy fork bomba mogła być zamierzona?

Mało prawdopodobne. Fork bomba natychmiast ujawniła złośliwe oprogramowanie, co jest przeciwieństwem celu atakującego. Cichy kradziej danych uwierzytelniających działający przez tygodnie zbiera o rzędy wielkości więcej danych uwierzytelniających niż taki, który zostaje wykryty w 46 minut.

Czy sprawdzanie wieku domeny jest praktyczne na dużą skalę?

Tak. Wiek domeny jest dostępny poprzez WHOIS lub APIs daty rejestracji DNS. Sprawdzenie dodaje milisekundy opóźnienia na żądanie. Większość organizacji może dodać znane nowe domeny do białej listy.

Sources