Wprowadzenie do problemu / definicja luki
Wraz z boomem na GenAI, wiele firm stawia „bramki” (reverse proxy, API gateway, internal proxy) przed modelami językowymi — żeby ujednolicić dostęp, logować ruch, ukryć klucze API albo kierować zapytania do różnych dostawców. Problem zaczyna się wtedy, gdy takie proxy jest wystawione do internetu bez odpowiedniej kontroli dostępu (albo ma zbyt liberalną konfigurację routingu). W praktyce staje się otwartą furtką: każdy może wysyłać żądania, a rachunek i limity zużywa właściciel infrastruktury.
Na początku stycznia 2026 r. GreyNoise opisało kampanie, w których aktorzy (w tym prawdopodobnie „szarzy” researcherzy, ale też profesjonalny threat actor) masowo skanowali i testowali endpointy powiązane z LLM-ami, polując właśnie na takie błędy konfiguracyjne.
W skrócie
- GreyNoise zarejestrowało 91 403 sesje ataków na swojej infrastrukturze honeypot (Ollama) między październikiem 2025 a styczniem 2026 i wyodrębniło dwie osobne kampanie.
- Kampania #1: SSRF (server-side request forgery) — wymuszanie połączeń wychodzących z serwera ofiary (m.in. przez mechanizmy „model pull” i integracje webhook).
- Kampania #2: enumeracja i fingerprinting — od 28 grudnia 2025 dwa IP metodycznie sprawdzały 73+ endpointy modeli, generując 80 469 sesji w 11 dni, testując formaty zgodne z OpenAI i Google Gemini.
- Celem jest wykrycie źle zabezpieczonych proxy / bramek, które pozwalają uzyskać dostęp do komercyjnych API LLM (czyli realnie: ktoś inny płaci za tokeny).
Kontekst / historia / powiązania
Ten wektor nie jest „nowy” jako idea: źle skonfigurowane reverse proxy potrafi ujawnić dostęp do zasobów, które miały być wewnętrzne (np. inne hosty w sieci, metadane, usługi lokalne), a także bywa nadużywane jako „pośrednik” do wykonywania żądań w imieniu serwera. To klasyczny fundament pod SSRF i nadużycia routingu.
Nowością jest to, iż LLM-y są kosztowym zasobem (tokeny, limity, budżety) oraz coraz częściej stoją za nimi automaty (agenty, workflow, funkcje), więc choćby „niewinne” zapytania testowe mogą być wstępem do:
- kradzieży budżetu (token draining),
- pivotu do systemów wewnętrznych (jeśli gateway ma dodatkowe integracje),
- eskalacji do wycieku danych (jeśli proxy ma dostęp do RAG/źródeł).
Dodatkowo Cisco zwraca uwagę, iż wiele wdrożeń LLM bywa publicznie wystawionych przez pośpiech, kopiowanie przykładów konfiguracji i brak twardych kontroli dostępu (na przykładzie serwerów LLM wykrywanych przez Shodan).
Analiza techniczna / szczegóły luki
1) Kampania SSRF: „zmuś serwer, żeby zadzwonił do mnie”
GreyNoise opisuje kampanię aktywną od października 2025 do stycznia 2026, w której atakujący próbowali potwierdzać SSRF poprzez OAST (out-of-band application security testing) i domeny callback. W praktyce chodzi o to, żeby serwer ofiary wykonał połączenie wychodzące do kontrolowanej infrastruktury — co potwierdza podatność.
W raporcie pojawiają się m.in.:
- wykorzystywanie mechanizmu Ollama model pull do podkładania URL-i rejestru,
- współwystępujące próby przez integracje webhook (np. parametry typu MediaUrl w kontekście SMS/MMS),
- charakterystyka automatyzacji (fingerprinty JA4, wskazania na narzędzia w stylu Nuclei).
GreyNoise ocenia, iż ta część wygląda jak aktywność „research/bug bounty”, ale skala i timing (pik w okresie świątecznym) sugerują „grey-hat pushing boundaries”.
2) Kampania enumeracyjna: „zbuduj listę otwartych bramek do płatnych modeli”
Druga kampania jest bardziej niepokojąca operacyjnie. Od 28 grudnia 2025 dwa adresy IP wykonywały metodyczne próby na 73+ endpointach modeli, testując formaty API kompatybilne z OpenAI i Gemini. W 11 dni zrobiły 80 469 sesji.
Co istotne, testy były „ciche” — proste prompt-y („hi”, puste wejście, pytania faktograficzne), żeby:
- zidentyfikować, czy endpoint odpowiada,
- sfingerprintować, jaki model stoi za proxy,
- nie wywołać alarmów SOC/abuse detection.
GreyNoise wiąże tę infrastrukturę ze „znanymi” aktywnościami skanowania i eksploatacji CVE, co sugeruje, iż enumeracja ma zasilić większy pipeline (najpierw mapa, potem nadużycie/eksploatacja).
Dlaczego proxy jest tu kluczowe?
W wielu organizacjach wygląda to tak:
- reverse proxy/gateway ma ważny klucz API do OpenAI/Anthropic itp.,
- na zewnątrz wystawia „własny” endpoint (często kompatybilny z OpenAI),
- jeśli brakuje authN/authZ, ograniczeń tras lub izolacji tenantów, atakujący może używać tego endpointu jak „darmowej karty” do płatnego API.
To jest klasyczna konsekwencja złej konfiguracji reverse proxy: „proxy robi to, o co prosisz”, jeżeli nie ma bezpiecznych guardrail’i.
Praktyczne konsekwencje / ryzyko
- Koszty i limity (token theft / budget drain)
Najbardziej bezpośredni efekt: nieautoryzowane zapytania spalają tokeny, limity rate i budżety — często zanim ktoś zauważy. - Ryzyko incydentu danych (jeśli gateway ma dostęp do RAG lub narzędzi)
Samo „hello” nic nie kradnie. Ale jeżeli ten sam endpoint ma dostęp do: wewnętrznych konektorów, retrieval, funkcji/agentów, logów rozmów — to rośnie ryzyko wycieku lub nadużyć (np. wymuszanie działań przez integracje). - Sygnał, iż jesteś „na liście”
GreyNoise podkreśla, iż tak duża enumeracja to inwestycja; mapowanie infrastruktury zwykle poprzedza realne nadużycie. - Zgodność i reputacja
Koszty to jedno, ale druga sprawa to audyt, raportowanie incydentów, ślady w logach i ryzyko, iż twoje zasoby AI staną się „publicznym serwisem” bez twojej wiedzy.
Rekomendacje operacyjne / co zrobić teraz
Minimum bezpieczeństwa dla „AI gateway / LLM proxy”
- Wymuś uwierzytelnianie (mTLS, OAuth2, signed JWT, API keys per klient/usługa) i autoryzację (policy per endpoint/model).
- Nie wystawiaj kompatybilnych endpointów OpenAI „na świat” bez kontroli dostępu, choćby jeżeli to „tylko test”.
- Rate limiting + quota per klient/IP/token, osobno dla endpointów „model list / models” i „chat/completions”.
Twarde ograniczenia ruchu wychodzącego (SSRF)
- Egress filtering: serwery LLM/proxy nie powinny móc łączyć się „gdziekolwiek w internet”.
- Blokuj domeny OAST/callback na DNS (GreyNoise wskazuje wzorce .oast. jako istotne w kampanii SSRF).
- Jeśli używasz Ollama/pull: ogranicz „model pulls” do zaufanych rejestrów.
Detekcja i monitoring
- Alertuj na wzorce enumeracji: wiele endpointów modeli w krótkim czasie, nietypowe sekwencje „niewinnych promptów” i skok liczby sesji.
- Monitoruj fingerprinty sieciowe, jeżeli masz taką możliwość (GreyNoise opisuje użycie JA4 do identyfikacji automatyzacji).
- Przejrzyj logi reverse proxy pod kątem:
- nietypowych „OpenAI-compatible paths”,
- prób listowania modeli,
- powtarzalnych krótkich zapytań testowych.
Ramy kontrolne (żeby nie „zgubić” tego w backlogu)
W OWASP Top 10 dla aplikacji LLM temat nieautoryzowanego użycia, niewłaściwych kontroli oraz podatności wynikających z integracji i niebezpiecznych zachowań systemu przewija się wielokrotnie (np. ryzyka wokół nadużyć, DoS, ujawnień danych, supply chain i projektowania wtyczek/agentów). Traktuj te pozycje jako checklistę do przeglądu wdrożenia LLM.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
- Wycieki kluczy API: klasyka (klucz w repo/logach). Tu jest subtelniej: klucz może być dobrze ukryty, ale proxy jest otwarte i działa jak publiczna bramka.
- Publicznie wystawione serwery LLM (self-hosted): inny wariant problemu, ale podobna przyczyna — wdrożenie „na szybko”, bez kontroli dostępu i segmentacji (Cisco opisuje, jak takie ekspozycje można masowo wykrywać).
- SSRF „klasyczne” vs SSRF w ekosystemie GenAI: mechanika ta sama, ale konsekwencje szersze, bo pipeline AI często ma integracje i automatyzacje, a koszty LLM są bezpośrednio mierzalne (tokeny).
Podsumowanie / najważniejsze wnioski
- Od końcówki grudnia 2025 widać metodyczną enumerację endpointów LLM, ukierunkowaną na wykrycie źle skonfigurowanych proxy, które mogą dać dostęp do płatnych modeli kosztem ofiary.
- Równolegle działa kampania SSRF, gdzie celem jest potwierdzanie podatności i kanału egress (callback).
- Największe ryzyko „tu i teraz” to: koszty, limity, oraz potencjalny pivot w głąb środowiska, jeżeli bramka AI jest spięta z danymi i narzędziami.
- Obrona nie wymaga magii: authN/authZ na bramce, rate limit, egress filtering, blokady OAST, monitoring wzorców enumeracji.
Źródła / bibliografia
- BleepingComputer – opis kampanii i obserwacji GreyNoise (9 stycznia 2026). (BleepingComputer)
- GreyNoise – „Threat Actors Actively Targeting LLMs” (8 stycznia 2026), metryki, kampanie, IOCs i rekomendacje obrony. (GreyNoise)
- ProjectDiscovery – seria o nadużyciach reverse proxy (kontekst bezpieczeństwa i skutki błędnej konfiguracji). (ProjectDiscovery)
- Cisco Security – studium wykrywania publicznie wystawionych serwerów LLM (Ollama) i ryzyk wynikających z ekspozycji. (Cisco Blogs)
- OWASP – Top 10 dla aplikacji LLM (ramy ryzyk i kontroli bezpieczeństwa dla wdrożeń GenAI). (OWASP Foundation)
