Wprowadzenie do problemu / definicja
W środowiskach agentów AI coraz częściej pojawiają się zagrożenia wynikające nie z klasycznych błędów aplikacyjnych, lecz z niewłaściwej architektury komunikacji sieciowej. Przypadek NemoClaw, wykorzystywanego do uruchamiania agentów OpenClaw, pokazuje, że nieautoryzowana ekspozycja lokalnego API modelu może prowadzić do przejęcia kontroli nad zachowaniem systemu opartego na LLM.
Najpoważniejszym skutkiem nie jest jednorazowa manipulacja odpowiedzią modelu, ale możliwość trwałego zatrucia warstwy sterującej. Oznacza to, że atakujący może wpłynąć na sposób interpretowania przyszłych poleceń przez agenta, zmieniając jego logikę działania na dłuższy czas.
W skrócie
Podatność dotyczy sposobu wystawiania lokalnego API Ollama przez NemoClaw. W określonych warunkach napastnik może wykorzystać złośliwą stronę internetową oraz technikę DNS rebinding, aby uzyskać nieuwierzytelniony dostęp do usługi działającej lokalnie na porcie 11434.
- możliwa jest enumeracja dostępnych modeli,
- atakujący może uruchamiać inferencję,
- istnieje ryzyko modyfikacji lub usunięcia modeli,
- najgroźniejsza pozostaje ingerencja w szablon czatu odpowiedzialny za instrukcje przekazywane do modelu.
W praktyce daje to możliwość trwałego wpływu na decyzje i odpowiedzi agentów AI działających w oparciu o OpenClaw.
Kontekst / historia
NemoClaw pełni rolę komponentu pomocniczego przy uruchamianiu frameworka OpenClaw w środowiskach sandboxowych. W takim modelu Ollama działa jako lokalny runtime dla dużych modeli językowych i udostępnia interfejs HTTP do obsługi zapytań.
Problem nie wynika z błędu typu memory corruption ani z klasycznego zdalnego wykonania kodu. Źródłem ryzyka jest decyzja konfiguracyjna polegająca na wystawieniu usługi w sposób dostępny poza interfejsem loopback. To przykład zmiany charakteru zagrożeń w systemach agentic AI, gdzie granica bezpieczeństwa przesuwa się z poziomu hosta i kontenera na komunikację między agentem, modelem oraz usługami pomocniczymi.
Analiza techniczna
Sedno podatności leży w sposobie uruchamiania Ollama przez NemoClaw. Ze względu na pracę w kontenerze usługa była wiązana do adresu 0.0.0.0:11434 zamiast do 127.0.0.1. Taka konfiguracja zwiększa powierzchnię ataku, ponieważ API staje się osiągalne spoza lokalnej pętli zwrotnej.
Eksploatacja może przebiegać z wykorzystaniem DNS rebinding. Ofiara odwiedza stronę kontrolowaną przez napastnika, a następnie domena tej strony zostaje powiązana z lokalnym adresem ofiary. Z perspektywy przeglądarki ruch nadal pochodzi z tego samego źródła, co pozwala złośliwemu kodowi komunikować się bezpośrednio z lokalnym API Ollama bez dodatkowego uwierzytelnienia.
Najbardziej krytyczny element ataku dotyczy modyfikacji chat template, czyli warstwy odpowiedzialnej za przekształcanie wiadomości wejściowych, w tym system promptów, do formy przekazywanej modelowi. Zmiana tego szablonu umożliwia wstrzyknięcie ukrytych instrukcji wykonywanych podczas kolejnych interakcji. W odróżnieniu od klasycznego prompt injection nie chodzi więc o jednorazową manipulację odpowiedzią, lecz o trwałą zmianę sposobu działania modelu i agenta.
Konsekwencje / ryzyko
Ryzyko operacyjne należy ocenić jako wysokie, ponieważ podatność dotyka warstwy kontrolnej agenta AI. Jeżeli agent posiada dostęp do repozytoriów kodu, systemów wewnętrznych, narzędzi automatyzacyjnych, API biznesowych lub danych organizacji, skutki mogą znacząco wykraczać poza sam runtime modelu.
Trwałość kompromitacji stanowi dodatkowy problem. Samo wdrożenie poprawki sieciowej może nie wystarczyć, jeśli wcześniej doszło do zmiany modeli, szablonów lub instrukcji sterujących. Organizacja musi wtedy zweryfikować integralność artefaktów modelu, konfiguracji oraz zależności wykorzystywanych przez agenta, aby odzyskać zaufany stan środowiska.
Przypadek ten pokazuje również, że nawet dobrze odizolowany sandbox nie gwarantuje pełnej ochrony, jeśli warstwa decyzyjna agenta może zostać przejęta przez manipulację modelem lub jego pośrednią logiką sterującą.
Rekomendacje
Organizacje korzystające z OpenClaw, NemoClaw lub lokalnych wdrożeń Ollama powinny jak najszybciej sprawdzić wersje używanego oprogramowania i wdrożyć dostępne poprawki. Konieczne jest także potwierdzenie, że API modelu pozostaje dostępne wyłącznie lokalnie lub przez ściśle kontrolowany kanał komunikacji.
- ograniczyć nasłuch usług AI wyłącznie do loopback lub zaufanego interfejsu wewnętrznego,
- wymusić uwierzytelnienie i autoryzację dla API modelu,
- monitorować i blokować próby DNS rebinding na poziomie przeglądarki, DNS oraz proxy,
- segmentować ruch między agentem, modelem i usługami narzędziowymi,
- weryfikować integralność modeli, szablonów czatu i konfiguracji inferencji,
- ograniczać uprawnienia agentów zgodnie z zasadą najmniejszych uprawnień,
- włączyć centralne logowanie zmian konfiguracji, template’ów i działań administracyjnych,
- stosować dodatkowe mechanizmy kontroli bezpieczeństwa dla komunikacji agent-model.
W środowiskach o podwyższonym profilu ryzyka warto również okresowo odtwarzać modele i konfiguracje z zaufanych obrazów referencyjnych. Takie podejście ułatwia usunięcie skutków potencjalnego zatrucia oraz skraca czas potrzebny do odzyskania zaufanego środowiska.
Podsumowanie
Incydent związany z NemoClaw potwierdza, że bezpieczeństwo agentów AI zależy nie tylko od ochrony promptów i jakości modelu, ale również od podstawowych decyzji dotyczących ekspozycji usług sieciowych. Połączenie nieautoryzowanego dostępu do API Ollama z techniką DNS rebinding może umożliwić trwałe zatrucie warstwy instrukcyjnej modelu i przejęcie zachowania agentów OpenClaw.
Dla zespołów bezpieczeństwa to wyraźny sygnał, że infrastruktura AI wymaga odrębnego modelu ochrony. Musi on obejmować kontrolę ruchu, integralność modeli, zarządzanie konfiguracją oraz ścisłe ograniczanie uprawnień komponentów odpowiedzialnych za podejmowanie decyzji.