Skanowanie otwartych endpointów LLM: „How many states are there in the United States?” jako sygnał rozpoznania

Wprowadzenie do problemu / definicja luki

Wraz z upowszechnieniem wdrożeń LLM (lokalnych i chmurowych) rośnie liczba usług wystawianych na Internet „na szybko”: bez uwierzytelnienia, z błędną konfiguracją reverse proxy, z domyślnymi ustawieniami CORS albo z niekontrolowanym ruchem wychodzącym. To nie jest pojedyncza luka CVE, tylko klasa ryzyk: nieautoryzowana ekspozycja endpointów LLM oraz nadużycia wynikające z błędnych konfiguracji pośredników (proxy).

Sygnałem, że ktoś „szuka otwartych LLM”, mogą być pozornie banalne zapytania. SANS Internet Storm Center pokazał przypadek, w którym honeypot rejestrował powtarzające się requesty z promptem: „How many states are there in the United States?” – traktowane jako rozpoznanie (recon) w celu wykrycia dostępnych, niechronionych usług LLM.

W skrócie

• Atakujący prowadzą systematyczną enumerację publicznie dostępnych endpointów LLM i źle skonfigurowanych proxy, używając „bezpiecznych” promptów do fingerprintingu modelu.
• GreyNoise opisało kampanię, w której w 11 dni wygenerowano 80 469 sesji i sondowano 73+ endpointów (formaty kompatybilne z OpenAI oraz Google Gemini).
• W praktyce ryzyko dotyczy m.in. wdrożeń lokalnych (np. Ollama), gdy ktoś celowo lub przypadkiem wystawi API na sieć/Internet bez warstwy uwierzytelnienia. Ollama domyślnie nasłuchuje na 127.0.0.1:11434, ale można to zmienić zmienną OLLAMA_HOST — co bywa początkiem problemów, jeśli zabraknie kontroli dostępu.

Kontekst / historia / powiązania

Wzorzec jest znany z innych usług: najpierw ciche mapowanie powierzchni ataku, potem dopiero eksploatacja (lub „monetyzacja” dostępu). W przypadku LLM „monetyzacja” bywa nietypowa:

• użycie cudzej infrastruktury do generowania odpowiedzi (koszty),
• dostęp do danych przesyłanych w promptach (tajemnice, PII, fragmenty kodu),
• wykorzystanie modelu jako „silnika” do dalszych działań (np. automatyzacja phishingu, analiza danych, generowanie złośliwych treści – zależnie od polityk i zabezpieczeń).

GreyNoise zwraca uwagę na aspekt fingerprintingu bez wzbudzania alertów: zamiast agresywnych payloadów stosuje się neutralne pytania (w tym to o liczbę stanów USA), by potwierdzić, że endpoint żyje i jaki model/format API obsługuje.

Analiza techniczna / szczegóły luki

1) Jak wygląda rozpoznanie „na drzwiach” LLM

W logach honeypotów pojawiają się żądania HTTP przypominające typowe wywołania „chat/completions” lub endpointów kompatybilnych z OpenAI. W przykładzie z SANS widać request JSON zawierający pole prompt oraz charakterystyczny, powtarzalny tekst pytania, a także automatyzujący User-Agent (np. skaner).

To działa, bo:

• wiele wdrożeń kopiuje „de facto standard” formatów API,
• odpowiedź modelu (lub same błędy) pozwalają odróżnić implementacje,
• prompt jest na tyle neutralny, że często omija proste reguły detekcji.

2) Co mówi telemetryka GreyNoise

GreyNoise opisuje kampanię enumeracyjną, w której testowano zarówno OpenAI-compatible API, jak i formaty Google Gemini, obejmując szerokie spektrum rodzin modeli. Kluczowe jest to, że zapytania były „niewinne”, a celem najpewniej było ustalenie co odpowiada i jakim modelem.

3) Dlaczego Ollama i podobne wdrożenia są wrażliwe na „przypadkową ekspozycję”

Ollama to częsty wybór do uruchamiania modeli lokalnie. Problem zaczyna się, gdy ktoś:

• ustawia OLLAMA_HOST na adres dostępny w sieci,
• publikuje port przez router/tunnel,
• stawia reverse proxy „na szybko” bez autoryzacji.

Dokumentacja potwierdza, że domyślnie Ollama wiąże się z 127.0.0.1:11434 (czyli lokalnie), ale można ją wystawić na sieć przez zmianę bind address. Jednocześnie lokalny dostęp do API nie wymaga uwierzytelnienia — co jest OK dla localhost, ale ryzykowne po ekspozycji na zewnątrz.

Praktyczne konsekwencje / ryzyko

1. Nieautoryzowane użycie zasobów i koszty
   Jeśli endpoint/proxy daje dostęp do płatnych usług albo kosztownej infrastruktury GPU, atakujący mogą „po cichu” generować obciążenie.
2. Wyciek danych z promptów i kontekstu
   LLM często przetwarza dane wrażliwe (fragmenty kodu, logi, opisy incydentów). Przy błędnej konfiguracji kontroli dostępu ryzyko wycieku rośnie.
3. DoS i degradacja jakości usługi
   OWASP wprost wskazuje „Model Denial of Service” jako kategorię ryzyka: modele można przeciążyć ruchem lub drogimi zapytaniami, powodując przestoje i koszty.
4. Ryzyka łańcucha dostaw i integracji
   Gdy LLM ma „wtyczki”, akcje lub integracje, rośnie stawka: OWASP wymienia m.in. „Insecure Plugin Design” i „Excessive Agency” jako typowe problemy wdrożeń LLM.

Rekomendacje operacyjne / co zrobić teraz

Poniżej zestaw działań, które w praktyce najszybciej redukują ryzyko enumeracji i nadużyć:

Warstwa sieciowa i ekspozycja

• Nie wystawiaj endpointów LLM bezpośrednio na Internet. Jeśli musisz, rób to przez reverse proxy z silnym uwierzytelnieniem i ograniczeniami.
• Ogranicz dostęp po IP/VPN/Zero Trust (preferowane: dostęp tylko z sieci firmowej lub przez tunel z MFA).
• Rate limiting i ochrona przed skanowaniem na warstwie proxy/WAF (limity per IP/ASN, detekcja burstów, blokady na nietypowe UA).

Uwierzytelnienie i autoryzacja

• Traktuj LLM jak każdy krytyczny backend API: API key / mTLS / OIDC.
• W przypadku wdrożeń lokalnych pamiętaj, że brak auth jest normalny dla localhost, ale po zmianie bind address to już poważna luka konfiguracyjna.

Monitoring i detekcja

• Dodaj reguły SIEM/SOAR pod kątem powtarzalnych, „niewinnych” promptów używanych do fingerprintingu (np. pytania faktograficzne w dużej skali). GreyNoise pokazało, że takie prompty występują masowo.
• Loguj: źródłowe IP, ścieżki endpointów, czasy odpowiedzi, kody błędów, rozmiary payloadów, nagłówki (w tym UA).

Higiena wdrożeniowa (LLM security baseline)

• Oprzyj checklistę o OWASP Top 10 for LLM Applications: w praktyce najbardziej „natychmiastowe” są kontrola outputów (LLM02), ochrona przed DoS (LLM04), ochrona danych wrażliwych (LLM06) oraz ograniczenie agency/integracji (LLM08).

Różnice / porównania z innymi przypadkami (jeśli dotyczy)

Enumeracja LLM ≠ klasyczne skanowanie CVE.
W tradycyjnym skanowaniu szuka się konkretnej podatności i wersji. Tutaj często chodzi o:

• wykrycie „czy to w ogóle jest LLM”,
• jaki format API obsługuje,
• czy stoi za tym płatna usługa/proxy,
• czy są jakiekolwiek bariery (auth, limity, filtracja).

Dlatego „bezpieczne” prompty są sprytne: pozwalają mapować cele bez generowania oczywistych sygnatur exploitów.

Podsumowanie / kluczowe wnioski

• Powtarzalne, neutralne pytania (np. o liczbę stanów USA) mogą być realnym wskaźnikiem reconnaissance pod otwarte endpointy LLM.
• Kampanie enumeracyjne są prowadzone na dużą skalę i obejmują wiele rodzin modeli oraz formatów API.
• Największy błąd operacyjny to wystawienie API bez uwierzytelnienia (szczególnie po zmianie bind address lub przez źle skonfigurowane proxy).
• Sensowna „minimum viable security” dla LLM to: brak publicznej ekspozycji, silny auth, limity, monitoring oraz checklista OWASP LLM Top 10.

Źródła / bibliografia

• SANS Internet Storm Center (Didier Stevens), wpis dziennika o rekonesansie przez prompt „How many states…”. (SANS Internet Storm Center)
• GreyNoise: Threat Actors Actively Targeting LLMs (opis kampanii enumeracyjnej i charakterystycznych promptów). (greynoise.io)
• OWASP Foundation: Top 10 for Large Language Model Applications (kategorie ryzyk LLM). (owasp.org)
• Ollama Docs: FAQ (domyślne bindowanie do localhost, ekspozycja przez OLLAMA_HOST, proxy). (docs.ollama.com)
• Ollama Docs: API Authentication (brak auth lokalnie; znaczenie po ekspozycji). (docs.ollama.com)