Luki w AI Amazon Bedrock, LangSmith i SGLang umożliwiają eksfiltrację danych i zdalne wykonanie kodu

Bezpieczeństwo systemów AI stało się jednym z najtrudniejszych wyzwań współczesnej branży technologicznej. Podczas gdy giganci takie jak Amazon, Anthropic i OpenAI inwestują miliardy w rozwój zaawansowanych modeli językowych, ich infrastruktura — zwłaszcza piaskownice kodowe i środowiska wykonawcze — okazuje się podatna na ataki, które mogą prowadzić do całkowitego przejęcia systemu. Odkrycie dokonane przez zespół badaczy z BeyondTrust ujawnia zatrważającą lukę: atakujący mogą wykorzystać zwykłe zapytania DNS do eksfiltacji wrażliwych danych i uzyskania interaktywnych powłok systemowych na serwerach obsługujących popularne platformy AI.

To nie jest zwyczajne znalezisko podatności. Chodzi o fundamentalny błąd projektowy, który dotyka trzech kluczowych komponentów ekosystemu AI: Amazon Bedrock, LangSmith oraz SGLang. Każdy z nich jest szeroko wykorzystywany przez przedsiębiorstwa, startapy i badaczy na całym świecie. Luka pozwala na coś gorszego niż przeciek danych — umożliwia pełną zdalizowaną kontrolę nad środowiskami wykonawczymi, gdzie mogą być przechowywane klucze API, dane treningowe modeli, czy wrażliwe informacje klientów.

Polska branża technologiczna, coraz bardziej zainteresowana integracją narzędzi AI w swoich produktach, powinna zwrócić szczególną uwagę na tę lukę. Wiele polskich startupów i firm IT korzysta z usług Amazon Web Services oraz ekosystemu narzędzi związanych z LangChain (do którego należy LangSmith). To oznacza, że podatność ta może bezpośrednio wpływać na bezpieczeństwo systemów rozwijanych w Polsce.

Jak DNS stał się narzędziem ataku na piaskownice AI

Tradycyjnie piaskownice kodowe są projektowane w taki sposób, aby izolować kod wykonywany przez użytkownika od reszty systemu. Jednak Amazon Bedrock AgentCore Code Interpreter w trybie piaskownicy pozwala na wykonanie wychodzących zapytań DNS — coś, co na pierwszy rzut oka wydaje się niegroźne. Przecież DNS to tylko system translacji nazw domen na adresy IP. Czy może to naprawdę stanowić zagrożenie?

Odpowiedź jest zdumiewająca: tak. Badacze z BeyondTrust wykazali, że DNS może być używany jako kanał komunikacji do eksfiltacji danych. Zamiast wysyłać dane za pośrednictwem tradycyjnych połączeń sieciowych (które zwykle są monitorowane i filtrowane), atakujący mogą zacodować wrażliwe informacje w zapytaniach DNS. Serwer DNS kontrolowany przez atakującego odbiera te zapytania i loguje je — otrzymując w ten sposób dostęp do danych bez konieczności nawiązywania bezpośredniego połączenia TCP/UDP.

Mechanizm jest genialnie prosty. Załóżmy, że atakujący chce ukraść zmienną środowiskową zawierającą klucz API. Kod wykonywany w piaskownicy może wysłać zapytanie DNS w postaci: exfiltrated-api-key-xyz123.attacker.com. Serwer DNS atakującego otrzyma to zapytanie i zaloguje całą zawartość. Piaskownica nie może tego zablokować, ponieważ zapytania DNS są dozwolone — są niezbędne do normalnego funkcjonowania internetu.

To, co czyni tę lukę szczególnie niebezpieczną, to fakt, że większość systemów bezpieczeństwa nie monitoruje zapytań DNS na wystarczająco szczegółowym poziomie. Administratorzy zwykle skupiają się na blokowaniu połączeń wychodzących na podejrzane porty lub adresy IP, ale pozwalają na nieszkodliwy ruch DNS. Badacze BeyondTrust wykazali, że ta założenie — że DNS jest bezpieczny — jest fatalne.

RCE poprzez interaktywne powłoki systemowe

Eksfiltacja danych to dopiero początek problemu. Odkrycie BeyondTrust pokazuje coś znacznie bardziej zatrażającego: możliwość uzyskania Remote Code Execution (RCE) — zdalizowanego wykonania dowolnego kodu na serwerze. To oznacza, że atakujący nie tylko może ukraść dane, ale także przejąć pełną kontrolę nad środowiskiem wykonawczym.

Mechanizm działa w następujący sposób: po ustanowieniu kanału komunikacji poprzez DNS, atakujący może wysyłać komendy systemowe zakodowne w zapytaniach DNS. Piaskownica, pozwalająca na wychodzące zapytania DNS, nie ma możliwości ich zablokowania. W ten sposób atakujący uzyskuje interaktywną powłokę systemową (shell) — de facto terminal, z którego może wykonywać dowolne polecenia na serwerze.

Biorąc pod uwagę, że Amazon Bedrock jest usługą zarządzaną przez AWS i obsługuje wiele wrażliwych obciążeń biznesowych, scenariusz RCE jest katastrofalny. Atakujący mogą:

• Modyfikować modele AI lub dane treningowe
• Przechwytywać wszystkie żądania użytkowników przetwarzane przez agentów AI
• Instalować persistence mechanisms — mechanizmy utrzymujące dostęp nawet po zamknięciu sesji
• Lateralnie rozprzestrzeniać się na inne systemy w sieci korporacyjnej
• Uzyskiwać dostęp do wrażliwych dokumentów i danych przechowywanych w S3 buckets

To nie jest hipotetyczne zagrożenie. Badacze BeyondTrust zademonstrowali praktyczne ataki, które skutecznie uzyskały dostęp do powłok systemowych. Oznacza to, że każda organizacja używająca Amazon Bedrock do obsługi agentów AI — a takich organizacji jest tysiące — jest potencjalnie zagrożona.

LangSmith: luka w debugowaniu i monitorowaniu

LangSmith, należący do firmy LangChain, to narzędzie do debugowania, monitorowania i optymalizacji aplikacji opartych na modelach języka. Jest niezwykle popularne wśród deweloperów, którzy budują chatboty, asystentów AI i agentów autonomicznych. Platforma pozwala na śledzenie każdego kroku wykonania łańcucha (chain) przetwarzania, co jest nieocenione dla debugowania złożonych systemów AI.

Jednak ta sama przejrzystość, która czyni LangSmith tak użytecznym narzędziem, okazuje się być jego słabością. Badacze odkryli, że LangSmith nie w pełni chroni komunikację między klientem a serwerem. Wrażliwe informacje — takie jak prompty systemowe, klucze API, dane użytkowników — mogą być logowane i przechowywane w niezabezpieczony sposób.

Dla polskich deweloperów pracujących z LangChain (a takich jest coraz więcej), to ma konkretne konsekwencje. Jeśli budują aplikację AI, która integruje się z LangSmith do monitorowania, mogą nieświadomie wysyłać wrażliwe dane na serwery LangChain. Chociaż LangChain twierdzi, że dane są szyfrowane i zabezpieczone, luka odkryta przez BeyondTrust pokazuje, że bezpieczeństwo tej platformy ma poważne luki.

Szczególnie problematyczne jest to, że wiele organizacji nie zdaje sobie sprawy z tego, jakie dokładnie dane trafiają do LangSmith. Prompty systemowe zawierające instrukcje biznesowe, dane treningowe, a nawet informacje o klientach mogą być logowane automatycznie. Jeśli ktoś uzyska dostęp do konta LangSmith — poprzez phishing, słaby hasło lub właśnie poprzez lukę DNS — będzie miał dostęp do całej historii wykonywania aplikacji AI.

SGLang: piaskownica, która nie chroni

SGLang to mniej znane, ale równie ważne narzędzie w ekosystemie AI. Jest to framework do optymalizacji i wykonywania programów językowych (language programs) na modelach takich jak GPT czy Llama. Używany jest głównie przez badaczy i zaawansowanych deweloperów, którzy chcą mieć pełną kontrolę nad procesem wykonania modelu.

Podatność w SGLang jest podobna do tej w Amazon Bedrock — piaskownica pozwala na wychodzące zapytania DNS, które mogą być wykorzystane do eksfiltacji danych i RCE. Jednak SGLang jest często uruchamiany lokalnie lub w środowiskach badawczych, gdzie bezpieczeństwo sieciowe może być mniej rygorystyczne. To oznacza, że luka w SGLang może być szczególnie niebezpieczna dla akademickich laboratoriów, startupów i zespołów R&D, które mogą przechowywać wrażliwe dane dotyczące nowych modeli lub patentowanych algorytmów.

Biorąc pod uwagę, że SGLang jest open-source'owym projektem, podatność mogła być znana w społeczności przez jakiś czas. Jednak fakt, że BeyondTrust musiał ją formalnie ujawnić, sugeruje, że poprawka nie była priorytetem dla maintainerów projektu. To klasyczny problem w open-source'owych narzędziach — bezpieczeństwo często schodzi na dalszy plan wobec funkcjonalności.

Wpływ na polskie przedsiębiorstwa i startup'y

Polska branża technologiczna szybko adopcjonuje narzędzia AI. Wiele polskich startupów i firm IT buduje aplikacje oparte na Amazon Bedrock, LangChain/LangSmith i innych narzędziach z ekosystemu LLM. Luka odkryta przez BeyondTrust ma dla nich konkretne implikacje.

Po pierwsze, każda polska firma, która używa Amazon Bedrock do budowy agentów AI, powinna natychmiast przejrzeć swoją konfigurację bezpieczeństwa. AWS powinien udostępnić patch lub rekomendacje dotyczące ograniczenia wychodzących zapytań DNS z piaskownic. Jednak w praktyce, wiele małych firm może nie mieć zasobów do szybkiego wdrożenia takiej zmiany.

Po drugie, firmy używające LangSmith do monitorowania powinny przeanalizować, jakie dane trafiają do tej platformy. Jeśli wysyłają tam wrażliwe informacje, powinni rozważyć alternatywne rozwiązania lub wdrożyć dodatkową enkrypcję na poziomie aplikacji.

Po trzecie, zespoły badawcze pracujące z SGLang powinny być świadome zagrożenia i wdrożyć dodatkowe kontrole bezpieczeństwa sieciowego — na przykład blokowanie wychodzących zapytań DNS z maszyn, na których SGLang jest uruchamiany.

Polska komunita bezpieczeństwa cybernetycznego — w tym firmy takie jak Eset, Asseco czy mniejsze firmy specjalizujące się w security consulting — powinna zacząć oferować usługi audytu bezpieczeństwa dla aplikacji AI. To będzie rosnący rynek, szczególnie teraz, gdy ujawniane są takie fundamentalne luki.

Architektura Zero Trust jako odpowiedź

BeyondTrust w swoim raporcie podkreśla znaczenie architektury Zero Trust jako ochrony przed tego rodzaju atakami. Zero Trust to podejście do bezpieczeństwa, które zakłada, że żaden ruch sieciowy — nawet wewnątrz organizacji — nie powinien być zaufany bez weryfikacji.

W kontekście piaskownic AI, Zero Trust oznacza:

• Blokowanie wszystkich wychodzących połączeń z piaskownicy, chyba że są wyraźnie dozwolone
• Monitorowanie każdego zapytania DNS i filtrowanie podejrzanych zapytań
• Segmentacja sieci, aby piaskownice AI były izolowane od reszty infrastruktury
• Logowanie i audyt każdej operacji wykonanej w piaskownicy
• Zastosowanie mikrosegmentacji — każdy agent AI ma dostęp tylko do zasobów, które rzeczywiście potrzebuje

To podejście jest bardziej wymagające niż tradycyjne bezpieczeństwo perimetrowe (firewall + VPN), ale jest znacznie bardziej efektywne. Szczególnie dla organizacji, które intensywnie korzystają z AI i chcą minimalizować ryzyko.

Amazon, Anthropic i inne firmy powinny domyślnie wdrażać Zero Trust w swoich platformach AI. Jednak w praktyce, wiele z nich priorityzuje funkcjonalność i łatwość użycia nad bezpieczeństwem. To pozostawia użytkowników w trudnej sytuacji — muszą sami implementować dodatkowe kontrole bezpieczeństwa, aby chronić się przed lukami w infrastrukturze.

Lekcja z przeszłości: dlaczego bezpieczeństwo piaskownic jest takie trudne

To nie jest pierwszy raz, gdy piaskownice okazują się podatne na ataki. Historia bezpieczeństwa informatycznego jest pełna przykładów, gdzie izolacja, która miała być bezpieczna, okazywała się mieć fundamentalne luki. Od Java appletów w latach 90., przez przeglądarki internetowe, po współczesne kontenery Docker — każda technologia piaskownicy miała swoje podatności.

Problem polega na tym, że piaskownice muszą być użyteczne — muszą pozwalać na pewne operacje, aby kod mógł się wykonywać. Jednak każda operacja, którą się pozwala, to potencjalny wektor ataku. DNS jest doskonałym przykładem: jest niezbędny dla normalnego funkcjonowania internetu, ale może być nadużywany do eksfiltacji danych.

Innym klasycznym przykładem jest System V IPC (Inter-Process Communication) w Linuxie. Piaskownice, które nie ograniczają dostępu do IPC, mogą być obejdowane poprzez komunikację z procesami spoza piaskownicy. Podobnie, dostęp do systemu plików może być nadużywany do czytania wrażliwych danych, nawet jeśli piaskownica ma być izolowana.

Badacze bezpieczeństwa od lat wiedzą, że projektowanie bezpiecznych piaskownic jest niezwykle trudne. Wymaga głębokich znań z zakresu systemów operacyjnych, sieci, bezpieczeństwa i architektury aplikacji. Jednak wiele zespołów AI, które budują te piaskownice, nie ma takiej ekspertyzy. Rezultatem są luki, takie jak ta odkryta przez BeyondTrust.

Co powinni zrobić użytkownicy teraz

Dla organizacji, które już korzystają z Amazon Bedrock, LangSmith lub SGLang, istnieje kilka kroków, które powinny podjąć natychmiast:

• Przejrzyj konfigurację bezpieczeństwa: Sprawdź, jakie reguły firewall'a i grupy bezpieczeństwa są ustawione dla piaskownic AI. Upewnij się, że wychodzące zapytania DNS są monitorowane lub ograniczane.
• Rotacja wrażliwych danych: Jeśli używałeś Amazon Bedrock, zmień wszystkie klucze API i hasła, które mogły być ujawnione. Zakładaj, że każda zmienna środowiskowa, którą ustawiłeś w piaskownicy, mogła być przechwycona.
• Wdrażanie Zero Trust: Zamiast polegać na piaskownicy do izolacji, wdrażaj dodatkowe kontrole bezpieczeństwa na poziomie sieci i aplikacji.
• Monitoring i alerting: Skonfiguruj narzędzia do monitorowania anomalnych zapytań DNS i połączeń wychodzących z piaskownic.
• Audyt danych: Jeśli wysyłałeś dane do LangSmith, przeanalizuj, co dokładnie było logowane. Rozważ usunięcie historii lub przełączenie się na rozwiązanie on-premise.

Dla organizacji, które planują wdrażać AI, ta luka powinna być lekcją: nie polegaj na bezpieczeństwie zapewnianym przez dostawcę. Zawsze wdrażaj dodatkowe warstwy bezpieczeństwa, monitoruj ruch sieciowy i zakładaj, że każda piaskownica może być obejdowana.

Polska branża technologiczna, która coraz bardziej inwestuje w AI, musi być świadoma tych zagrożeń. Nie wystarczy po prostu integrować narzędzia takie jak Amazon Bedrock czy LangChain — trzeba je integrować bezpiecznie, z pełnym zrozumieniem potencjalnych wektorów ataku.