Złośliwe wydanie LiteLLM 1.107.0 przeszło przez firmowy mechanizm publikacji. Raport z 23 października koryguje wcześniejsze wyjaśnienie pochodzenia przejętych tokenów, a analiza Microsoft ostrzega, że kod mógł uruchomić się przy starcie Pythona, bez importowania LiteLLM. Zespoły korzystające z pakietu powinny sprawdzić środowiska i wyjść poza samą listę wywołań biblioteki.

Wyobraź sobie linię pakowania z dwiema pieczęciami odbioru. Regulamin wymaga, żeby każdą przyłożyła inna osoba. Jeżeli oba stemple leżą w jednej dostępnej szufladzie, dwa odciski nie dowodzą niezależnej kontroli. To analogia do ryzyka, które powinien ocenić właściciel automatycznej publikacji oprogramowania po incydencie LiteLLM. Samo istnienie dwóch kont w regule zatwierdzania nie odpowiada na pytanie, czy jedna osoba może użyć obu. Dla kierownika zespołu technicznego zadanie polega więc na sprawdzeniu dostępu do poświadczeń, a dla klienta biblioteki na ustaleniu, czy podejrzany artefakt znalazł się w jego środowisku. Te dwa przeglądy mają innych właścicieli i inne kryteria zakończenia.

Raport z 23 października zastępuje wcześniejszą hipotezę

Według kanonicznej analizy przyczyn LiteLLM 27 maja publicznie ujawniono główny klucz Agent Platform i nie unieważniono go. 10 października sprawca odczytał token GitHub CLI właściciela organizacji, a następnie tokeny innych opiekunów projektu. 21 października zmienił repozytorium źródłowe pipeline, obszedł ochronę gałęzi i drugim tokenem zatwierdził publikację. Pipeline podpisał i opublikował złośliwe wydanie 1.107.0. Raport zastępuje wcześniejszą hipotezę o pochodzeniu tokenów.

Wniosek redakcji dotyczy granicy zaufania. Jeżeli system publikacji traktuje poprawne poświadczenie jako wystarczający dowód woli człowieka, kradzież tego poświadczenia może odebrać znaczenie formalnej zgodzie. Rekomendujemy sprawdzenie, gdzie przechowywane są tokeny osób zatwierdzających i kto może je odczytać. Nie wystarczy policzyć kont w panelu. Przegląd powinien objąć możliwość użycia poświadczeń poza zwykłą sesją właściciela konta oraz sposób ich unieważnienia po ujawnieniu.

Dwie zgody dają niezależną kontrolę tylko wtedy, gdy sprawca nie może użyć obu zestawów poświadczeń.

Dla własnego zespołu proponujemy także próbę wyjaśnienia jednej ostatniej publikacji. Osoba odpowiedzialna powinna umieć wskazać źródło kodu, zatwierdzenie i tożsamość, która uruchomiła wydanie. Jeżeli dowody kończą się na informacji, że automat zadziałał poprawnie, przegląd nie odpowiedział jeszcze na pytanie o uprawnienie do zlecenia pracy automatowi.

Diagnostyka przez Python może uruchomić podejrzany kod

Microsoft opisuje złośliwe pliki startowe, dzięki którym wykonanie było możliwe przy uruchomieniu Pythona bez importu LiteLLM. Zbieracz sięgał po dostępne dane uwierzytelniające, środowisko i bazę proxy. Lista celów w kodzie nie dowodzi udanej kradzieży każdego sekretu. Obsługa pobrania dodatkowego kodu na systemach Unix również nie potwierdza, że taki etap się wykonał.

Microsoft zaleca, aby nie uruchamiać Python ani pip do diagnozy podejrzanego środowiska i używać czystych narzędzi. W naszej ocenie ta instrukcja powinna trafić bezpośrednio do osoby wykonującej przegląd. Ogólne polecenie sprawdzenia wersji może skłonić administratora do rutynowego uruchomienia interpretera. Bezpieczniej określić w zadaniu również sposób zbierania informacji i odseparować od niego środowisko objęte podejrzeniem.

Według komunikatu LiteLLM siedem złośliwych plików wheel wersji 1.107.0 było dostępnych w PyPI 21 października od 11:39:51 do 13:23 UTC, a złośliwe kontenery w Docker Hub od 11:46:56 do 14:20 UTC. Dotyczyło to tagów v1.107.0, latest, main-latest i main-stable. Dostawca podał, że prywatny rejestr enterprise nie był dotknięty, oraz zalecił odtworzenie środowisk i rotację dostępnych sekretów.

Nasza rekomendacja to zachowanie informacji o pochodzeniu pobranego artefaktu. Sama nazwa produktu nie rozstrzyga narażenia, a bieżąca zawartość ruchomego tagu nie opisuje automatycznie tego, co zespół pobrał wcześniej. W pierwszym przeglądzie można zebrać zapisy wdrożeń i historię pobrań bez uruchamiania podejrzanego środowiska. Braki w tych zapisach powinny trafić do prowadzącego incydent jako niewiadome.

Odtworzenie środowiska i rotacja mają osobne wyniki

Dla zarządu proponujemy oddzielne rozliczenie odzyskania środowiska i danych uwierzytelniających. W ocenie redakcji przywrócenie aplikacji do działania nie odpowiada na pytanie, czy poprzedni sekret nadal pozwala korzystać z usługi docelowej. Z kolei wymiana sekretu nie potwierdza, że środowisko uruchomieniowe pochodzi z zaakceptowanego źródła. Jedno zgłoszenie może obejmować oba zadania, ale każde potrzebuje dowodu zakończenia.

Nie znamy strat konkretnego czytelnika ani zawartości jego środowiska. Dlatego odradzamy przekształcanie listy funkcji złośliwego kodu w listę potwierdzonych strat firmy. W raporcie wewnętrznym dla LiteLLM 1.107.0 proponujemy rozdzielić stwierdzone pobranie, dostępność sekretów oraz dowody ich użycia. Dzięki temu właściciel systemu może uzasadnić działania zapobiegawcze bez przedstawiania hipotezy jako wyniku dochodzenia.

Podpis wydania potwierdza działanie mechanizmu podpisującego; ocenę bezpieczeństwa kodu trzeba oprzeć na dodatkowych dowodach.

Właściciel publikacji powinien też ustalić, kto ma prawo zatrzymać kolejne wydanie podczas wyjaśniania incydentu. To propozycja organizacyjna, a nie opis dodatkowego zdarzenia w LiteLLM. Własny przegląd może zakończyć się listą uprawnień do zmiany i terminem ich odebrania. Dwa pola zatwierdzeń w formularzu nie zastąpią tej pracy.

Polski zespół AI potrzebuje historii wdrożeń

Polskiej firmie zlecającej utrzymanie aplikacji AI rekomendujemy poproszenie wykonawcy o zakres wykorzystania LiteLLM 1.107.0 i źródło artefaktów. Odpowiedź powinna obejmować konkretne środowiska, bez domyślnego przenoszenia wniosków z produkcji na stanowiska programistów. To proponowany zakres kontroli, nie twierdzenie, że incydent dotknął którąkolwiek polską organizację.

Wspólny raport klienta i wykonawcy może zaczynać się od jednego wdrożenia z 21 października. Jeżeli nie da się ustalić wersji lub źródła, zespół powinien wskazać ten brak i osobę odpowiedzialną za dalszą decyzję. Naszym zdaniem taka odpowiedź jest użyteczniejsza od zapewnienia, że nikt świadomie nie importował podejrzanej biblioteki. Mechanizm opisany przez Microsoft sprawia, że samo pytanie o import nie wystarcza do oceny zdarzenia.

Co z tym zrobić w poniedziałek

  1. W 20 minut sprawdź zapis jednego wdrożenia. Z czystego stanowiska przejrzyj historię pakietów lub kontenerów pod kątem LiteLLM 1.107.0 i wskazanych tagów. Nie uruchamiaj Python ani pip w podejrzanym środowisku.
  2. W 30 minut przygotuj zakres reakcji dla jednego środowiska. Wypisz właścicieli jego dostępnych sekretów i osobę odpowiedzialną za odtworzenie. Zabezpiecz dostępne zapisy; wykonanie całej odbudowy zaplanuj osobno.
  3. W 20 minut sprawdź niezależność dwóch zgód. Z właścicielem publikacji ustal, czy tokeny obu zatwierdzających są dostępne z tego samego konta lub środowiska. Zapisz wykryte wspólne dostępy jako zadania do usunięcia.

Incydent LiteLLM uzasadnia sprawdzenie, kto rzeczywiście kontroluje publikację, nawet gdy automat wykonuje wszystkie zaplanowane kroki. Odbiorca pakietu potrzebuje natomiast dowodów dotyczących własnych środowisk. Rozdzielenie tych odpowiedzialności ułatwia reakcję i ogranicza puste zapewnienia o bezpieczeństwie.

Źródła

Redakcja cyberinsight.pl.