Wprowadzenie do problemu / definicja
Bezpieczeństwo środowisk AI coraz częściej zależy nie tylko od samych modeli, ale również od warstw wykonawczych, narzędzi observability oraz komponentów infrastrukturalnych. Najnowsze ustalenia badaczy pokazują, iż podatności w usługach uruchamiania kodu, platformach śledzenia pracy modeli oraz frameworkach serwujących duże modele językowe mogą prowadzić do wycieku danych, przejęcia kont, a choćby zdalnego wykonania kodu.
Problem dotyczy trzech różnych obszarów: izolacji środowiska wykonawczego w Amazon Bedrock AgentCore Code Interpreter, bezpieczeństwa sesji i przekierowań w LangSmith oraz niebezpiecznej deserializacji w SGLang. Razem pokazują one, iż powierzchnia ataku w ekosystemie AI obejmuje dziś cały łańcuch przetwarzania, a nie wyłącznie model.
W skrócie
- W Amazon Bedrock AgentCore Code Interpreter wykryto możliwość wykorzystania zapytań DNS jako ukrytego kanału komunikacji i eksfiltracji danych z sandboxa.
- W LangSmith luka związana z parametrem baseUrl może prowadzić do kradzieży tokenów i przejęcia kont użytkowników.
- W SGLang opisano kilka podatności opartych na niebezpiecznej deserializacji obiektów pickle, co może skutkować zdalnym wykonaniem kodu.
- Ryzyko obejmuje zarówno środowiska testowe, jak i produkcyjne, zwłaszcza tam, gdzie komponenty AI mają szerokie uprawnienia i dostęp do danych.
Kontekst / historia
Dynamiczny rozwój agentów AI, systemów wykonujących kod oraz narzędzi do obserwowalności workflow modeli sprawił, iż platformy te stały się pełnoprawnym elementem infrastruktury produkcyjnej. W praktyce oznacza to, iż błędy projektowe lub implementacyjne w tych komponentach należy traktować z taką samą powagą jak klasyczne podatności w aplikacjach webowych, usługach chmurowych czy middleware.
W przypadku Amazon Bedrock badacze zwrócili uwagę na rozbieżność między deklarowaną izolacją środowiska a jego rzeczywistym zachowaniem. W LangSmith problem został usunięty w wersji 0.12.71, natomiast w SGLang opisano kilka scenariuszy związanych z deserializacją danych pochodzących z niezaufanych źródeł. Wszystkie te przypadki potwierdzają, iż bezpieczeństwo AI trzeba analizować całościowo — od warstwy wykonawczej po integracje i mechanizmy telemetryczne.
Analiza techniczna
Najbardziej nietypowy scenariusz dotyczy Amazon Bedrock AgentCore Code Interpreter. Usługa została zaprojektowana jako odizolowane środowisko do wykonywania kodu, jednak badacze wykazali, iż sandbox dopuszcza wychodzące zapytania DNS. Taka możliwość może zostać użyta do stworzenia kanału C2, w którym polecenia i odpowiedzi są przesyłane z wykorzystaniem rekordów DNS.
W praktyce oznacza to możliwość budowy tunelu komunikacyjnego między interpreterem a infrastrukturą kontrolowaną przez napastnika. o ile przypisana rola IAM posiada nadmierne uprawnienia, atak nie musi kończyć się na samym wykonaniu poleceń. Może prowadzić również do odczytu danych z zasobów chmurowych dostępnych dla tej roli, w tym obiektów przechowywanych w usługach magazynowania danych.
W LangSmith problem ma charakter aplikacyjny i wynika z niewystarczającej walidacji parametru baseUrl. Odpowiednio spreparowany link może skłonić aplikację do przekazania wrażliwych danych sesyjnych do serwera kontrolowanego przez atakującego. Chodzi między innymi o token bearer, identyfikator użytkownika oraz identyfikator workspace. Taki scenariusz może zostać uruchomiony z użyciem socjotechniki, na przykład poprzez nakłonienie ofiary do kliknięcia złośliwego odnośnika.
SGLang reprezentuje z kolei dobrze znaną, ale wciąż bardzo groźną klasę błędów: niebezpieczną deserializację obiektów pickle. W kilku komponentach frameworka dane odbierane z sieci lub odczytywane z plików są deserializowane bez odpowiedniego uwierzytelnienia i walidacji. To szczególnie niebezpieczne, ponieważ pickle nie jest formatem bezpiecznym do przetwarzania niezaufanych danych.
Jeżeli napastnik może dostarczyć złośliwy obiekt do procesu korzystającego z funkcji deserializacji, może doprowadzić do wykonania arbitralnego kodu po stronie serwera. Opisane przypadki obejmują między innymi brokerów opartych o ZeroMQ oraz moduły powiązane z generacją multimodalną i mechanizmami disaggregation. W określonych konfiguracjach i przy odpowiedniej ekspozycji usług z sieci oznacza to realne ryzyko pełnej kompromitacji procesu serwującego model.
Konsekwencje / ryzyko
Skutki tych podatności są istotne zarówno dla środowisk badawczych, jak i produkcyjnych. W Amazon Bedrock główne ryzyko wynika z połączenia ukrytego kanału DNS z nadmiernie uprzywilejowanymi rolami IAM. Taka kombinacja może prowadzić do eksfiltracji danych, naruszenia poufności informacji klientów, a także nieautoryzowanych działań wewnątrz infrastruktury chmurowej.
W LangSmith najpoważniejszym zagrożeniem jest przejęcie tożsamości użytkownika oraz dostęp do danych związanych z obserwowalnością pracy agentów AI. Może to oznaczać ujawnienie historii wywołań, zapytań do narzędzi, metadanych operacyjnych, a choćby fragmentów kodu lub danych biznesowych przetwarzanych w pipeline’ach AI.
W SGLang konsekwencje są jeszcze bardziej bezpośrednie. Zdalne wykonanie kodu w warstwie serwującej modele może prowadzić do pełnej kompromitacji hosta, instalacji tylnej furtki, ruchu bocznego w sieci oraz manipulacji wynikami generowanymi przez model. W środowiskach współdzielonych lub połączonych z zasobami GPU i magazynami danych wpływ takiego incydentu może być bardzo szeroki.
Rekomendacje
Organizacje korzystające z Amazon Bedrock AgentCore Code Interpreter powinny ocenić, czy wrażliwe obciążenia nie są uruchamiane w trybie sandbox bez dodatkowych zabezpieczeń. W scenariuszach wymagających rzeczywistej izolacji warto rozważyć przejście do trybu VPC, wdrożenie kontroli filtrowania ruchu DNS oraz dokładny audyt ról IAM zgodnie z zasadą najmniejszych uprawnień.
W przypadku LangSmith priorytetem jest weryfikacja wersji wdrożenia i aktualizacja do wersji zawierającej poprawkę. Dodatkowo warto przeanalizować logi pod kątem nietypowych przekierowań, użycia parametru baseUrl oraz potencjalnych oznak przejęcia sesji. Pomocne będą również krótkotrwałe tokeny, segmentacja dostępu do workspace’ów i szkolenia użytkowników z rozpoznawania ataków socjotechnicznych.
Dla środowisk wykorzystujących SGLang najważniejsze jest ograniczenie ekspozycji interfejsów sieciowych. Brokerów ZeroMQ i innych wewnętrznych komponentów nie należy udostępniać do sieci niezaufanych. Niezbędne są również reguły segmentacji, listy kontroli dostępu, monitorowanie nietypowych połączeń przychodzących oraz obserwacja procesów potomnych uruchamianych przez usługę.
W ujęciu przekrojowym organizacje powinny traktować narzędzia orkiestracji, observability i wykonania kodu jako systemy o wysokiej krytyczności. Oznacza to regularne przeglądy konfiguracji, testy bezpieczeństwa komponentów wspierających modele, ograniczanie uprawnień oraz analizę ruchu wychodzącego, w tym zapytań DNS.
Podsumowanie
Opisane przypadki pokazują, iż bezpieczeństwo AI nie kończy się na samym modelu ani na filtrach promptów. Realne ryzyko pojawia się na styku środowisk wykonawczych, integracji chmurowych, mechanizmów sesyjnych i bibliotek infrastrukturalnych. Amazon Bedrock pokazuje, jak choćby częściowy dostęp do sieci może podważyć założenia izolacji sandboxa, LangSmith przypomina o trwałym zagrożeniu ze strony klasycznych błędów aplikacyjnych, a SGLang potwierdza, iż niebezpieczna deserializacja przez cały czas pozostaje jedną z najgroźniejszych klas podatności.
Dla zespołów bezpieczeństwa to wyraźny sygnał, iż cały ekosystem AI powinien być objęty takim samym rygorem ochronnym jak krytyczne usługi infrastrukturalne. Bez tego choćby zaawansowane wdrożenia modeli mogą stać się łatwym celem ataków.