Archiwa: LLM - Strona 17 z 20 - Security Bez Tabu

Tag: LLM

KONNI wykorzystuje AI do budowy backdoora w PowerShell i celuje w deweloperów (blockchain/crypto)

Wprowadzenie do problemu / definicja luki

W styczniu 2026 Check Point Research opisał aktywną kampanię phishingową przypisywaną do KONNI – północnokoreańskiego aktora działającego co najmniej od 2014 roku. Tym razem kluczową zmianą jest dobór ofiar (software development/engineering) oraz narzędzie egzekucji: backdoor w PowerShell, którego cechy wskazują na AI-assist/AI-generated development (nie tyle nowe TTP, co szybsze i „czyściejsze” wytwarzanie kodu z typowymi artefaktami LLM).

W praktyce nie jest to „pojedyncza luka CVE”, ale łańcuch infekcji oparty o socjotechnikę, pliki skrótów Windows (LNK) i wieloetapowe uruchomienie komponentów, którego efektem jest trwały dostęp do hosta oraz możliwość dalszej eskalacji do narzędzi zdalnego zarządzania.

W skrócie

  • Kampania celuje w deweloperów i zespoły inżynieryjne z dostępem do zasobów blockchain/crypto (repozytoria, API, portfele, infrastruktura).
  • Start łańcucha: link hostowany na Discord → pobranie ZIP z przynętą (PDF) i LNK, który uruchamia loader PowerShell i rozpakowuje kolejne elementy (DOCX + CAB).
  • Utrwalenie: Scheduled Task podszywający się pod OneDrive, uruchamiany cyklicznie, deszyfrujący (XOR) i wykonujący backdoor „in-memory”.
  • Backdoor zawiera rozbudowane anti-analysis (progi sprzętowe, blacklist narzędzi, wymaganie aktywności myszą), fingerprinting przez WMI oraz mechanizmy eskalacji UAC (fodhelper).
  • C2: obejście „bramki” po stronie serwera przez emulację JavaScript challenge i pozyskanie cookie __test, a potem cykliczne wysyłanie metadanych hosta do endpointu PHP.

Kontekst / historia / powiązania

KONNI historycznie kojarzono głównie z celami w Korei Południowej (dyplomacja, rząd, NGO, akademia) oraz klasycznym spear-phishingiem opartym o tematy geopolityczne. W opisywanej kampanii widać przesunięcie na ekosystemy techniczne: development i obszary, gdzie pojedynczy kompromitowany endpoint może otworzyć drogę do kontenerów, CI/CD, sekretów w repozytoriach czy kluczy do usług.

Z szerszej perspektywy to pasuje do obserwacji, że północnokoreański program cyber jest wykorzystywany nie tylko do szpiegostwa, ale również do operacji generujących środki finansowe, m.in. przez kradzieże kryptowalut i naruszenia sankcji.

Analiza techniczna / szczegóły luki

1) Przynęty i initial access

Przynęty wyglądają jak materiały projektowe (architektura, stack, harmonogramy, budżety/milestones) powiązane z blockchain/crypto. Wektor początkowy wprost nie jest ujawniony, ale łańcuch startuje od linku hostowanego na Discord, prowadzącego do archiwum ZIP.

Z perspektywy MITRE ATT&CK to klasyczny przypadek User Execution: Malicious File (T1204.002) – ofiara musi otworzyć/uruchomić spreparowany plik (tu: LNK).

2) Łańcuch infekcji (ZIP → LNK → CAB → BAT/PS1)

W ZIP znajdują się PDF (lure) oraz LNK. LNK uruchamia osadzony loader PowerShell, który:

  • zapisuje na dysk przynętę DOCX i archiwum CAB (oba osadzone w LNK i XOR-owane jednobajtowym kluczem),
  • otwiera DOCX, żeby odciągnąć uwagę,
  • rozpakowuje CAB, gdzie znajdują się: PowerShell backdoor, dwa batch file oraz exe do UAC bypass,
  • uruchamia pierwszy batch.

3) Persistence i „living off the land”

Pierwszy batch tworzy staging w C:\ProgramData, przenosi komponenty i zakłada Scheduled Task podszywający się pod zadanie OneDrive uruchamiane co godzinę. Zadanie czyta zaszyfrowany backdoor, wykonuje XOR-decrypt (klucz ‘Q’) i uruchamia kod w pamięci. Następnie batch usuwa się z dysku (redukcja śladów).

4) Cechy sugerujące AI-generated backdoor

CPR wskazuje na nietypowo „produktowy” charakter skryptu: czytelna struktura, komentarze/dokumentacja oraz artefakt wprost przypominający placeholder z generatorów LLM: komentarz w rodzaju „your permanent project UUID” (instrukcja dla człowieka jak uzupełnić wartość). To zestaw sygnałów, który ma wspierać tezę o AI-assist/AI-generated development.

5) Funkcje backdoora: anti-analysis, identyfikacja hosta, eskalacja

Backdoor wykonuje:

  • anti-analysis/sandbox evasion: progi sprzętowe, wykrywanie narzędzi (IDA, Wireshark, Procmon itd.), wymaganie interakcji użytkownika (ruch/kliknięcia myszy),
  • single-instance przez mutex Global\SysInfoProject_<projectUUID> (UUID stały dla próbek wskazanych w raporcie),
  • fingerprinting przez WMI (m.in. serial płyty głównej + UUID systemu), SHA-256 i skrócenie do 16 znaków,
  • rozgałęzienie działań wg uprawnień: dla „User” – fodhelper UAC bypass przez manipulacje w HKCU\Software\Classes i przekierowanie protokołu ms-settings, a następnie modyfikację ConsentPromptBehaviorAdmin (de facto ograniczenie promptów UAC dla adminów).

Dodatkowo, w scenariuszu „Admin” raport opisuje m.in. dodanie wykluczenia Windows Defender dla C:\ProgramData i podmianę zadania harmonogramu na wersję z wyższym kontekstem uprawnień.

6) C2 i obejście „bramki” anty-bot

C2 jest zabezpieczone client-side’ową „bramką” (AES/JS) i cookie __test. Backdoor emuluje JavaScript challenge: pobiera implementację AES używaną przez stronę, odtwarza logikę JS, odszyfrowuje ciphertext z serwera i wyciąga token, a następnie używa go jako cookie do kolejnych żądań. Potem okresowo wysyła metadane hosta (ID, poziom uprawnień, IPv4, username) do endpointu PHP, a odpowiedzi traktuje jako tasking (PowerShell wykonywany w tle).

7) Warianty i IoC

CPR wspomina też o wariancie z października 2025, gdzie początkowy payload był wprost obfuskowanym skryptem PowerShell pobierającym kolejne komponenty, a OneDriveUpdater.exe służył głównie do pobrania i uruchomienia klienta SimpleHelp (legit RMM) dla interaktywnego dostępu.

W raporcie podano też przykładowe domeny/IP C2 oraz listy hashy (IoC).

Praktyczne konsekwencje / ryzyko

Dla organizacji software’owych i zespołów blockchain/crypto ryzyko jest szczególne, bo kompromitacja jednego stanowiska developerskiego może przełożyć się na:

  • wyciek sekretów z repozytoriów (tokeny do Git, klucze API, SSH),
  • przejęcie CI/CD (wstrzyknięcia w pipeline, supply-chain),
  • dostęp do środowisk chmurowych i walletów/kluczy podpisujących,
  • lateral movement do zasobów produkcyjnych.

Kontekst finansowy jest istotny: w oficjalnych opracowaniach dot. aktywności DPRK podkreśla się skalę cyber-kradzieży i ich rolę w finansowaniu działań państwa, w tym obchodzeniu sankcji.

Rekomendacje operacyjne / co zrobić teraz

Szybkie działania (24–72h)

  1. Zablokuj/ogranicz uruchamianie LNK z pobranych archiwów i katalogów typu Downloads/Temp (tam, gdzie to możliwe politykami). To bezpośrednio tnie klasę ataków „malicious file + user execution”.
  2. Polowanie na Scheduled Tasks podszywające się pod OneDrive i uruchamiające inline PowerShell (szczególnie z odczytem bajtów z C:\ProgramData\… i natychmiastowym IEX).
  3. Telemetria EDR: alerty na PowerShell obfuskowany arytmetyką, nietypowe tworzenie słowników stringów + Invoke-Expression.
  4. Wykrywanie zmian w rejestrze pod fodhelper UAC bypass (ścieżki pod HKCU\Software\Classes i ms-settings) oraz modyfikacji ConsentPromptBehaviorAdmin.
  5. Network: blokady/alerty na wskazane w raporcie domeny/IP oraz na nietypowe żądania do endpointów PHP po wcześniejszym „handshake” z cookie __test.

Średni termin (1–4 tygodnie)

  • Hardening stacji dev: separacja kont, MFA wszędzie, minimalizacja lokalnych uprawnień admin, izolacja sekretów (vault), rotacja tokenów.
  • Ograniczenie możliwości dodawania Defender exclusions i monitorowanie wykluczeń dla C:\ProgramData.
  • Kontrole supply-chain: podpisywanie artefaktów, wymuszenie code review dla zmian w pipeline, zasada „two-person rule” dla kluczy produkcyjnych.
  • Uświadamianie: „projektowe PDF/DOCX z Discorda” jako realna przynęta dla devów – to dziś równie typowe jak „faktura” w klasycznych kampaniach.

Różnice / porównania z innymi przypadkami

  • KONNI (AI-assist backdoor): raportowane elementy wskazują na wykorzystanie AI głównie do wytwarzania/formatowania kodu (komentarze-artefakty, modularność), przy zachowaniu znanych TTP (LNK, scheduled task, PowerShell).
  • Szerszy trend AI-generated malware: Check Point kilka dni wcześniej opisał „VoidLink” jako przykład bardziej „frameworkowego” podejścia, gdzie AI miało przyspieszać nie tylko pisanie kodu, ale też planowanie i iterację całego projektu. To sugeruje, że „AI w malware” szybko przesuwa się od ciekawostek do realnego przyspieszacza R&D po stronie atakujących.
  • LNK jako stały motyw: niezależnie od tej konkretnej kampanii, analizy TTP w regionie (w tym porównania aktorów państwowych) pokazują, że pliki LNK w archiwach ZIP są dojrzałym i powtarzalnym wzorcem initial access.

Podsumowanie / kluczowe wnioski

  1. KONNI rozszerza profil ofiar: deweloperzy + blockchain/crypto to atrakcyjny cel, bo daje dostęp do sekretów i infrastruktury o wysokiej wartości.
  2. Największa nowość nie leży w „magicznych” nowych technikach, tylko w tym, że AI może obniżać koszt i czas tworzenia użytecznych implantów (bardziej uporządkowany kod, szybkie wariantowanie).
  3. Obrona powinna iść dwutorowo: (a) twarde kontrole uruchamiania plików i PowerShell, (b) security hygiene w środowisku dev (sekrety, pipeline, uprawnienia).
  4. Warto traktować kanały typu Discord jako realny wektor dystrybucji „materiałów projektowych” – szczególnie w społecznościach dev/web3.

Źródła / bibliografia

  1. Check Point Research – KONNI Adopts AI to Generate PowerShell Backdoors (22 stycznia 2026). (Check Point Research)
  2. MITRE ATT&CK – User Execution: Malicious File (T1204.002). (attack.mitre.org)
  3. Genians – analiza spear-phishing i nadużyć LNK/ZIP w kampaniach APT (kontekst TTP). (genians.co.kr)
  4. MOFA Japan (PDF) – raport dot. naruszeń/obchodzenia sankcji i roli DPRK cyber (kontekst finansowy).
  5. Check Point – VoidLink Signals the Start of a New Era in AI-Generated Malware (19 stycznia 2026). (Check Point Blog)

VoidLink: cloud-native framework malware dla Linuksa, który (prawdopodobnie) powstał „prawie w całości” z pomocą AI

Wprowadzenie do problemu / definicja zagrożenia

VoidLink to zaawansowany, „cloud-first” framework malware dla Linuksa zaprojektowany pod długotrwały, dyskretny dostęp do środowisk chmurowych i kontenerowych (Kubernetes/Docker). Z perspektywy obrońców najważniejsze jest to, że nie wygląda jak typowy „jednofunkcyjny trojan” – bardziej przypomina kompletne C2/post-exploitation narzędzie z loaderami, implantami, mechanizmami rootkit oraz rozbudowanym systemem wtyczek.

W styczniu 2026 temat zyskał dodatkowy ciężar: Check Point Research wskazuje na rzadko spotykane dowody sugerujące, że znacząca część rozwoju VoidLink mogła zostać wykonana w trybie „AI-driven development” (agent + specyfikacje + sprinty), co radykalnie skraca czas tworzenia złożonych narzędzi ofensywnych.

W skrócie

  • Cel i środowisko: Linux w chmurze i kontenerach; rozpoznawanie dostawcy chmury oraz kontekstu (K8s/Docker) i dopasowanie zachowania.
  • Architektura: loader 2-etapowy + implant + in-memory plugin system (ponad 30 modułów; panel wskazywał ok. 37 wtyczek).
  • Stealth i rootkity: LD_PRELOAD / LKM / eBPF – wybór techniki zależny od wersji kernela i „postury” środowiska.
  • C2/łączność: wiele kanałów (m.in. HTTP/HTTPS, DNS, ICMP) oraz mechanizmy kamuflażu ruchu; w próbkach widać też kierunek „mesh/P2P”.
  • AI w wytwarzaniu: Check Point opisuje metodykę SDD (Spec Driven Development) i artefakty po narzędziu TRAE SOLO; THN i Sysdig przytaczają dodatkowe sygnały „LLM-owego” boilerplate’u.
  • Status: brak potwierdzonych infekcji „w realu” w momencie publikacji analiz; wygląda na projekt w fazie intensywnego rozwoju.

Kontekst / historia / powiązania

  • Wykrycie: Check Point Research trafił na próbki w grudniu 2025; część binariów zawierała artefakty developerskie (np. symbole debug), co sugerowało buildy „w trakcie” a nie masowo wdrożone malware.
  • Atrybucja (ostrożnie): w raportach pojawia się wątek środowiska developerskiego powiązanego językowo/operacyjnie z Chinami, ale bez twardego przypisania do konkretnej grupy.
  • Tempo rozwoju: Check Point wskazuje, że narzędzie urosło do ~88 tys. linii kodu do początku grudnia 2025; THN podkreśla „pierwszy funkcjonalny implant” w czasie krótszym niż tydzień.
  • „Wgląd w warsztat”: kluczowe w tej historii jest to, że badacze mieli wyjątkowy wgląd w artefakty planowania i budowy (m.in. przez błędy OPSEC autora i wyciek plików).

Analiza techniczna / szczegóły luki

Poniżej najważniejsze elementy „tradecraftu” VoidLink, z perspektywy obrony chmury i Linuksa.

1) Cloud-first rozpoznanie i działania w kontenerach

VoidLink potrafi identyfikować popularnych dostawców chmury (m.in. AWS, Azure, GCP, Alibaba, Tencent) i pobierać dane z mechanizmów metadata/instancji. Dodatkowo wykrywa, czy działa w Dockerze lub w podzie Kubernetes, a następnie dobiera moduły post-exploitation (np. pod kątem eksfiltracji sekretów, prób „container escape”, ruchu lateralnego).

2) Modularność: Plugin API inspirowane Cobalt Strike

Check Point opisuje architekturę z własnym Plugin API inspirowanym podejściem Beacon Object Files (BOF). Wtyczki są ładowane w runtime i wykonywane in-memory, co sprzyja „cichym” operacjom i ogranicza artefakty na dysku. Kategorie modułów obejmują m.in. recon, cloud/container, credential harvesting, persistence, anti-forensics, lateral movement.

3) Rootkity i ukrywanie: LD_PRELOAD, LKM oraz eBPF

VoidLink ma „rootkit-style capabilities” w kilku wariantach:

  • LD_PRELOAD (user-mode hooking),
  • LKM (kernel module),
  • eBPF (hooking ścieżek w sposób lepiej dopasowany do nowszych, „utwardzonych” systemów).

Mechanizm doboru techniki zależy od kernela i dostępnych funkcji; celem jest m.in. ukrywanie procesów, plików i socketów, a także maskowanie samych komponentów.

4) C2 i kamuflaż ruchu

VoidLink obsługuje wiele transportów (HTTP/1.1, HTTP/2, WebSocket, DNS, ICMP) oraz warstwy kamuflażu (udawanie „legitnego” ruchu, pakowanie danych w obiekty przypominające treści webowe/grafiki itp.). W kodzie widać też kierunek rozwoju w stronę mesh/P2P.

5) Adaptive stealth i OPSEC: „ryzyko” środowiska wpływa na zachowanie

Jedna z mocniejszych cech: po starcie malware ma enumerować zabezpieczenia (np. EDR/hardening), wyliczać risk score i na tej podstawie modyfikować agresywność działań (np. wolniejsze skanowanie w środowisku monitorowanym). Do tego dochodzą: runtime code encryption, mechanizmy anty-debug, integralność runtime oraz self-deletion przy wykryciu manipulacji.

6) „Server-Side Rootkit Compilation” (Sysdig)

Sysdig zwraca uwagę na element, który rozwiązuje klasyczny problem LKM rootkitów: portowalność względem wersji kernela. Według analizy, serwer C2 ma budować moduły kernela „na żądanie” pod konkretną wersję kernela ofiary (SRC). To może znacząco podnieść skuteczność w heterogenicznych flotach linuksowych w chmurze.

Praktyczne konsekwencje / ryzyko

Dla większości organizacji ryzyko nie sprowadza się do „jeszcze jednego malware”, tylko do możliwego przejęcia warstwy sterującej chmurą:

  • Kradzież poświadczeń i sekretów (cloud creds, tokeny, klucze, dane do repozytoriów/SCM typu Git) → ryzyko kompromitacji CI/CD, „secrets sprawl” i dostępu do kodu.
  • Trwała obecność w klastrach i node’ach dzięki persistence + ukrywaniu (rootkit/eBPF/LKM) oraz adaptacji do monitoringu.
  • Cichy post-exploitation w K8s/Docker (recon, eskalacje, potencjalne ucieczki z kontenera) → dostęp do workloadów i danych.
  • Zmiana ekonomii ataku dzięki AI: jeśli Check Point ma rację, bariera wejścia dla budowy „pełnego frameworka” spada – pojedynczy actor może iterować szybciej, niż zespoły defensywne aktualizują detekcje i polityki.

Jednocześnie warto trzymać w głowie fakt, że w analizach na styczeń 2026 nie ma potwierdzonych, masowych infekcji w środowiskach produkcyjnych – ale projekt wygląda jak „prawie gotowy” ekosystem C2.

Rekomendacje operacyjne / co zrobić teraz

Poniżej lista działań, które mają sens nawet wtedy, gdy VoidLink nie jest (jeszcze) „w wild”.

1) Detekcja runtime dla Linuksa i kontenerów

  • Postaw na runtime monitoring (syscall/activity-based), bo część technik jest „fileless” lub ukrywa artefakty na dysku. Sysdig podkreśla, że mimo zaawansowania zachowania na poziomie syscalls są widoczne dla narzędzi klasy runtime (np. Falco).
  • W K8s: reguły na nietypowe exec w kontenerach, dostęp do socketów dockera, nietypowe mounty, operacje na /proc, manipulacje BPF, ładowanie modułów kernela.

2) Ograniczenie „blast radius” w chmurze

  • Przejrzyj IAM: minimalne uprawnienia, krótkie TTL tokenów, rotacja kluczy, rozdzielenie ról CI/CD i adminów.
  • Uszczelnij dostęp do instance metadata (IMDS/metadata proxy), bo VoidLink aktywnie pyta o dane środowiska chmurowego.
  • Zredukuj ekspozycję sekretów: używaj menedżerów sekretów (i audytuj, gdzie lądują w env/args).

3) Twarde kontrole na hoście

  • Rozważ ograniczenia dla eBPF i ładowania modułów (tam, gdzie to możliwe operacyjnie).
  • Hardening: kontrola integralności, ograniczenie narzędzi developerskich na serwerach produkcyjnych, monitoring zmian w usługach/systemd/cron (persistence).

4) Kontrola egress i anomalii C2

  • Monitoruj/ogranicz: DNS tunneling, nietypowe ICMP, WebSocket/HTTP2 do nieznanych destynacji. VoidLink ma wiele kanałów C2 i kamuflaż ruchu, więc „allow-all egress” w chmurze to proszenie się o kłopoty.

5) Przygotuj proces IR „pod cloud-native”

  • Playbook na incydent w K8s (izolacja node/pod, snapshoty, artefakty runtime, eksport audit logs).
  • Zbieraj dane, które przetrwają anti-forensics (telemetria runtime, logi z warstwy kontrolnej chmury).

Różnice / porównania z innymi przypadkami

  • VoidLink vs „klasyczne Linux malware”: tu mamy platformę C2 + post-exploitation z pluginami, dashboardem operatorskim i adaptacją do cloud/K8s – to bardziej „Linuxowy odpowiednik” ekosystemów znanych z Windows.
  • Inspiracje Cobalt Strike: podobieństwo jest jawne w warstwie API/wtyczek (BOF-like). To ważne, bo pokazuje przenoszenie sprawdzonych wzorców ofensywnych do chmury opartej o Linuksa.
  • AI-assisted malware (nowa jakość): Check Point argumentuje, że wcześniejsze „AI malware” bywało niskiej jakości lub wtórne, a VoidLink ma być pierwszym dobrze udokumentowanym przypadkiem, gdzie AI przyspieszyło budowę złożonego, oryginalnego frameworka przy udziale kompetentnego twórcy.

Podsumowanie / kluczowe wnioski

VoidLink to sygnał ostrzegawczy w dwóch wymiarach: (1) technicznie – bo łączy cloud awareness, pluginową architekturę i rootkity (LD_PRELOAD/LKM/eBPF) z wielokanałowym C2; (2) metodycznie – bo według Check Point znacząca część wytwarzania mogła być „napędzana” przez podejście agentowe (SDD + sprinty + automatyzacja), co skraca cykl tworzenia ofensywnych platform.

Dobra wiadomość: w momencie publikacji analiz (styczeń 2026) nie ma twardych dowodów na szerokie użycie w atakach. Zła: projekt wygląda jak „prawie gotowy” i może zostać szybko dopięty do kampanii szpiegowskich, kradzieży sekretów w chmurze lub działań supply-chain.

Źródła / bibliografia

  1. Check Point Research – „Unveiling VoidLink – A Stealthy, Cloud-Native Linux Malware Framework” (13.01.2026). (Check Point Research)
  2. Sysdig Threat Research – „VoidLink threat analysis: Sysdig discovers C2-compiled kernel rootkits” (16.01.2026). (sysdig.com)
  3. Check Point Research – „VoidLink: Evidence That the Era of Advanced AI-Generated Malware Has Begun” (20.01.2026). (Check Point Research)
  4. The Hacker News – „VoidLink Linux Malware Framework Built with AI Assistance Reaches 88,000 Lines of Code” (21.01.2026). (The Hacker News)
  5. SecurityWeek – „VoidLink Linux Malware Framework Targets Cloud Environments” (15.01.2026). (SecurityWeek)

ChainLeak w Chainlit: dwie luki (CVE-2026-22218 i CVE-2026-22219) mogą wyciekać pliki, sekrety i dane z infrastruktury AI

Wprowadzenie do problemu / definicja luki

Chainlit to popularny, otwartoźródłowy framework w Pythonie do budowania aplikacji konwersacyjnych (chatbotów i interfejsów dla agentów/LLM), często integrowany z ekosystemem narzędzi LLM. Zafran Labs opisał dwie podatności wysokiej wagi (zbiorczo nazywane „ChainLeak”), które w pewnych konfiguracjach mogą prowadzić do ujawnienia plików z serwera oraz do SSRF (Server-Side Request Forgery), czyli wykonywania żądań sieciowych z wnętrza serwera aplikacji do zasobów wewnętrznych (w tym endpointów metadanych chmurowych).

W skrócie

  • Dotknięte wersje: Chainlit < 2.9.4 (łatka w 2.9.4).
  • CVE-2026-22218 (arbitrary file read): uwierzytelniony klient może doprowadzić do skopiowania wskazanego pliku do swojej „sesji” i następnie pobrać go po identyfikatorze (m.in. przez endpoint /project/file/<chainlitKey>).
  • CVE-2026-22219 (SSRF): w konfiguracji z backendem warstwy danych opartym o SQLAlchemy uwierzytelniony klient może podać kontrolowany url, który serwer pobierze metodą HTTP GET, co umożliwia sięgnięcie do usług wewnętrznych i/lub metadanych chmurowych.
  • Skutek biznesowy: wyciek sekretów (np. kluczy API), danych aplikacji i potencjalnie danych innych użytkowników w środowiskach współdzielonych.

Kontekst / historia / powiązania

W aplikacjach opartych o LLM typowe „stare” klasy podatności webowych (IDOR, SSRF, file read) są szczególnie groźne, bo te systemy:

  • często działają internet-facing (boty wsparcia, portale dla klientów),
  • trzymają sekrety do modeli/agentów (API keys), konektory do baz danych i zasobów firmowych,
  • bywają wielowarstwowe (UI → orkiestracja → narzędzia → dane), co zwiększa powierzchnię ataku.

Zafran wskazuje, że podatności zostały potwierdzone w rzeczywistych, publicznie dostępnych wdrożeniach.

Analiza techniczna / szczegóły luki

CVE-2026-22218 — Arbitrary File Read przez „element update flow”

Z opisu podatności wynika następujący łańcuch:

  1. Uwierzytelniony klient wysyła spreparowany „Element” z kontrolowaną ścieżką (path).
  2. Serwer kopiuje wskazany plik do obszaru sesji atakującego.
  3. Serwer zwraca identyfikator (np. chainlitKey), który pozwala pobrać treść pliku przez API (w opisie pada ścieżka /project/file/<chainlitKey>).

Dlaczego to jest groźne w AI-app?
Jeśli proces Chainlit ma uprawnienia do odczytu wrażliwych plików (konfiguracje, klucze, cache, logi), atakujący może sukcesywnie „wydzierać” informacje z hosta.

CVE-2026-22219 — SSRF przez url w elementach (SQLAlchemy data layer)

Ten wektor dotyczy sytuacji, gdy aplikacja używa backendu warstwy danych opartego o SQLAlchemy. Mechanizm (z perspektywy opisu) wygląda tak:

  1. Atakujący (uwierzytelniony) tworzy element z kontrolowanym polem url.
  2. Logika serwera pobiera zawartość spod tego URL (HTTP GET) „z wnętrza” infrastruktury serwera.
  3. Odpowiedź może zostać zapisana w skonfigurowanym storage providerze, co ułatwia eksfiltrację.

W praktyce SSRF bywa wykorzystywane do:

  • skanowania usług wewnętrznych (panele admin, Redis/Elastic, wewnętrzne API),
  • uderzenia w cloud metadata endpoints (np. poświadczenia ról/instancji), co bywa początkiem eskalacji w chmurze.

Praktyczne konsekwencje / ryzyko

Najbardziej „nośne” scenariusze ryzyka w kontekście Chainlit/LLM to:

  • Wyciek sekretów i konfiguracji (zmienne środowiskowe, pliki .env, konfiguracje konektorów) – Zafran wskazuje m.in. możliwość odczytu /proc/self/environ jako przykład pozyskania wrażliwych wartości.
  • Wyciek danych aplikacyjnych: logi, cache, artefakty sesji, pliki tymczasowe – szczególnie jeśli serwer pracuje na wspólnym hoście/klastrze i ma szerokie uprawnienia.
  • Ryzyko w środowiskach multi-tenant: jeśli aplikacja przechowuje treści promptów/odpowiedzi w warstwach cache/plikach, file read może prowadzić do ujawnienia danych innych użytkowników.
  • SSRF jako „pomost” do chmury: dostęp do metadanych instancji lub wewnętrznych usług może skończyć się przejęciem uprawnień i ruchem bocznym (lateral movement).

Warto podkreślić: oba CVE wymagają uwierzytelnionego klienta, więc najczęściej nie jest to „drive-by” bez logowania. Z drugiej strony, w realnych wdrożeniach często istnieją konta o niskim poziomie zaufania (np. self-service), integracje SSO, konta testowe lub źle skonfigurowane role — i to zwykle wystarcza, by podatność stała się praktycznie wykorzystywalna.

Rekomendacje operacyjne / co zrobić teraz

1) Patch management (najważniejsze)

  • Zaktualizuj Chainlit do wersji 2.9.4 lub nowszej (to wersja wskazana jako naprawiająca problem).

2) Zmniejsz skutki, jeśli nie możesz patchować natychmiast

  • Ogranicz ekspozycję: jeśli to możliwe, zdejmij instancję z publicznego internetu (VPN / allowlista / reverse proxy z MFA). (To dobra praktyka dla paneli LLM i aplikacji wewnętrznych, nawet niezależnie od tej konkretnej luki.)
  • Zasada najmniejszych uprawnień dla procesu: uruchamiaj usługę na użytkowniku systemowym bez dostępu do katalogów z sekretami; rozważ kontenery z read-only FS tam, gdzie da się. (Zmniejsza to realny „zasięg” arbitrary file read.)
  • Egress filtering dla serwera (firewall/SG/NACL): ogranicz ruch wychodzący tylko do niezbędnych domen/usług (to kluczowe w obronie przed SSRF).
  • Ochrona metadanych chmurowych: w zależności od chmury i architektury — blokuj dostęp do adresów metadanych z poziomu aplikacji lub wymagaj nowszych mechanizmów autoryzacji (np. tokenów dla metadanych), by SSRF nie mógł pobrać poświadczeń „za darmo”.

3) Detekcja i monitoring

  • Przejrzyj logi pod kątem nietypowych żądań związanych z tworzeniem/aktualizacją „elementów” oraz pobieraniem plików po identyfikatorach.
  • Monitoruj nietypowy ruch wychodzący HTTP z hostów aplikacji (kierunki wewnętrzne, nietypowe hosty, próby dostępu do metadanych).

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

To dobry przykład, że „AI framework” nie musi mieć „AI-specyficznej” podatności, by doprowadzić do poważnego incydentu. W praktyce:

  • Arbitrary file read w aplikacji LLM to często natychmiastowy wyciek: kluczy API do modeli, konfiguracji narzędzi (tooling), poświadczeń do baz i integracji.
  • SSRF w środowisku chmurowym jest klasycznym wektorem do pozyskania tokenów/poświadczeń i eskalacji.

Wniosek operacyjny: traktuj warstwę aplikacji LLM jak każdą krytyczną aplikację webową — z pełnym zestawem kontroli (hardening, segmentacja, egress, least privilege), bo „nowoczesny” stos technologiczny dziedziczy „klasyczne” ryzyka.

Podsumowanie / kluczowe wnioski

  • Chainlit < 2.9.4 jest narażony na dwie podatności (CVE-2026-22218, CVE-2026-22219), które mogą prowadzić do wycieku plików i/lub SSRF.
  • W realnych wdrożeniach AI ryzyko jest podbite przez obecność sekretów (API keys), konektorów do danych firmowych i częstą ekspozycję usług na internet.
  • Najszybsza i najpewniejsza redukcja ryzyka: upgrade do 2.9.4+, a dodatkowo ograniczenie egress i uprawnień procesu.

Źródła / bibliografia

  1. SecurityWeek — opis podatności i kontekst ekspozycji instancji w internecie. (SecurityWeek)
  2. Zafran Labs — „ChainLeak” (analiza techniczna, scenariusze eksfiltracji i wpływ na AI stack). (Zafran Security)
  3. GitHub Advisory Database — CVE-2026-22218 (arbitrary file read, warunki i wersje). (GitHub)
  4. GitHub Advisory Database — CVE-2026-22219 (SSRF, warunki dot. SQLAlchemy, wersje). (GitHub)
  5. Tenable — opis CVE-2026-22218 i przykładowe ścieżki/endpointy eksfiltracji. (Tenable®)

Krytyczne luki w serwerach MCP: SSRF, RCE i ryzyko przejęć chmury w ekosystemie agentów AI (Microsoft, Anthropic)

Wprowadzenie do problemu / definicja luki

Model Context Protocol (MCP) to standard łączący modele językowe i agentów AI z narzędziami (np. repozytoriami Git, systemem plików, usługami chmurowymi czy konwerterami dokumentów). W praktyce MCP „wystawia” funkcje (tools), które agent może wywoływać w odpowiedzi na polecenia użytkownika… albo na polecenia przemycone w danych wejściowych (np. w README, stronie WWW, pliku).

Nowy problem nie polega wyłącznie na tym, że „gdzieś jest błąd”. Chodzi o to, że serwery MCP często działają jako uprzywilejowane pośredniki: mają dostęp do sieci, plików, tokenów, repozytoriów, a czasem wręcz do zasobów chmurowych. Jeśli da się nimi sterować (bez ograniczeń) albo jeśli agent da się nakłonić do uruchomienia sekwencji narzędzi — powstaje prosta ścieżka do SSRF, kradzieży sekretów i RCE.

W skrócie

  • Badacze opisali poważne ryzyka w popularnych serwerach MCP: SSRF w Microsoft MarkItDown MCP oraz łańcuch prowadzący do RCE w oficjalnych serwerach MCP Anthropic (Git + Filesystem).
  • W przypadku MarkItDown problemem jest możliwość pobierania dowolnych URI bez ograniczeń, co otwiera drogę do SSRF i np. odczytu metadanych instancji w chmurze.
  • W przypadku Anthropic zidentyfikowano trzy luki (CVE-2025-68145 / -68143 / -68144), które można łączyć z innymi narzędziami MCP, by doprowadzić do wykonania kodu.
  • Kluczowa lekcja: kompozycja narzędzi (tool chaining) + pośrednictwo agentów = ryzyko wykraczające poza „pojedynczą podatność” — to problem architektoniczny.

Kontekst / historia / powiązania

W artykule Dark Reading (20 stycznia 2026) podkreślono, że MCP powstał jako otwarty standard, a kwestie bezpieczeństwa w dużej mierze pozostawiono implementatorom. Efekt: część serwerów MCP „dowiozła funkcjonalność”, ale bez twardych barier bezpieczeństwa.

Microsoft równolegle publikuje materiały o zabezpieczaniu serwerów MCP (np. autentykacja/autoryzacja JWT, dobre praktyki dla wdrożeń oraz zarządzanie dostępem). To ważny sygnał: dostawcy widzą, że MCP szybko staje się infrastrukturą krytyczną, a nie tylko „wtyczką do LLM”.

Analiza techniczna / szczegóły luki

1) Microsoft MarkItDown MCP: SSRF przez „nieograniczone URI”

Z opisu wynika, że MarkItDown MCP przyjmuje od użytkownika/klienta URI wskazujące źródło pliku do konwersji i pobiera je bez mechanizmów ograniczających (brak sensownego allowlist/denylist, brak twardej walidacji docelowych adresów). To klasyczny wzorzec SSRF, tylko osadzony w nowym workflow: „agent → narzędzie MCP → sieć”.

Najbardziej niebezpieczny wariant to środowisko chmurowe: gdy serwer działa np. na instancji AWS EC2, możliwe jest odpytywanie usługi metadanych instancji (IMDS) i pozyskanie tymczasowych poświadczeń (access key/secret/session token) przypiętych do roli IAM. Dark Reading wskazuje też na różnicę odporności IMDSv2 vs IMDSv1.

Wniosek techniczny: w świecie MCP SSRF nie jest „tylko SSRF-em” — to często most do przejęcia chmury, bo serwer MCP bywa uruchamiany blisko sekretów, tokenów i metadanych infrastruktury.

2) Anthropic Git MCP + Filesystem MCP: łańcuch do RCE

Opisane błędy w oficjalnym Git MCP (mcp-server-git) obejmują m.in.:

  • obejście walidacji ścieżek (CVE-2025-68145),
  • możliwość inicjalizacji repozytorium w dowolnej lokalizacji (CVE-2025-68143),
  • wstrzyknięcie argumentów/niebezpieczne obchodzenie się z parametrami w kontekście git_diff (CVE-2025-68144).

Kluczowe jest jednak to, jak dochodzi do RCE: podatności stają się groźne, gdy agent potrafi wykonać sekwencję działań przez różne narzędzia MCP (np. Git + Filesystem). Dark Reading opisuje scenariusz, w którym atakujący przemyca instrukcje poprzez indirect prompt injection (np. „złośliwe README”), a następnie agent wykonuje działania prowadzące do przygotowania repozytorium i uruchomienia poleceń (np. przez mechanizmy git związane z filtrami/atrybutami).

Wniosek techniczny: tu nie chodzi o „magiczne RCE w LLM”, tylko o bardzo klasyczny łańcuch: błąd kontroli ścieżek + możliwość zapisu plików + uruchomienie procesu (git) z podatnymi parametrami — tyle że zautomatyzowany przez agenta.

Praktyczne konsekwencje / ryzyko

Najbardziej realistyczne scenariusze nadużyć w organizacjach:

  • Kradzież sekretów i eskalacja w chmurze: SSRF do IMDS / usług metadanych, odczyt tokenów, a potem przejęcie zasobów (storage, bazy, pipeline CI/CD).
  • RCE na stacjach dev / runnerach CI: jeśli MCP serwery (Git/Filesystem) działają lokalnie lub w środowiskach build, skutkiem może być przejęcie repozytoriów, podmiana artefaktów, wstrzyknięcia do łańcucha dostaw.
  • „Confused deputy” w architekturach pośredniczących: serwer MCP jako proxy do innych API może zostać użyty do uzyskania niezamierzonego dostępu, jeśli źle zaprojektowano autoryzację i zgody.
  • Ataki przez dane, nie przez użytkownika: indirect prompt injection sprawia, że bodźcem jest treść (plik/WWW), a nie „zły użytkownik w czacie”. To zmienia monitoring i model zagrożeń.

Rekomendacje operacyjne / co zrobić teraz

Twarde ograniczenia dla SSRF (priorytet #1)

  • Wprowadź allowlist schematów i hostów dla narzędzi pobierających zasoby (np. tylko https do zatwierdzonych domen/bucketów).
  • Zablokuj dostęp sieciowy z procesu MCP do adresów link-local i usług metadanych (np. 169.254.169.254), a także do prywatnych zakresów, jeśli nie są potrzebne (egress filtering).
  • W chmurze wymuś IMDSv2 tam, gdzie to możliwe (zmniejsza podatność na część klas SSRF).

Minimalizacja uprawnień i „blast radius”

  • Uruchamiaj serwery MCP w izolacji (kontener, sandbox, osobna tożsamość) i dawaj im tylko minimalne uprawnienia (RBAC/least privilege).
  • Rozdziel narzędzia „read” i „write”; operacje zapisu/niszczenia wymagaj jako jawnie zatwierdzane (human-in-the-loop dla krytycznych akcji).

Uwierzytelnianie i autoryzacja (bez tego MCP to „otwarta brama”)

  • Zaimplementuj authn/authz dla MCP (np. JWT/OAuth) oraz kontroluj, kto może wywoływać które tool’e. Microsoft pokazuje podejście z JWT i praktycznymi wzorcami wdrożeniowymi dla serwerów MCP.
  • Jeśli wystawiasz MCP przez warstwę zarządzania API, rozważ centralne egzekwowanie polityk dostępowych (klucze/subskrypcje, tokeny, walidacja) i spójny audyt wywołań.

Ochrona przed indirect prompt injection i „tool chaining”

  • Traktuj treści zewnętrzne (WWW/pliki) jako dane nieufne i projektuj agenta tak, by oddzielać „instrukcje” od „kontekstu”.
  • Dodaj reguły: agent nie może wykonywać operacji wysokiego ryzyka na podstawie niezweryfikowanej treści (np. z README). W praktyce: polityki wykonywania narzędzi, klasyfikacja ryzyka tool’i, oraz walidacje parametrów po stronie serwera MCP.

Różnice / porównania z innymi przypadkami

To nie jest „kolejna podatność w web appce”.
W klasycznym SSRF atakujący zwykle bije w endpoint aplikacji. W MCP często bije w narzędzie uruchamiane przez agenta, które działa z innym poziomem zaufania i uprawnień.

To nie jest też „tylko prompt injection”.
Prompt injection jest wyzwalaczem, ale realne szkody wynikają z tego, że agent ma dostęp do narzędzi o mocy porównywalnej z kontem uprzywilejowanym (chmura, system plików, repo). To przesuwa ciężar obrony na: tożsamość, granice sieciowe, walidację parametrów i polityki wykonywania narzędzi.

Podsumowanie / kluczowe wnioski

  • MCP przyspiesza budowę agentów AI, ale jednocześnie tworzy nową, bardzo „twardą” powierzchnię ataku: SSRF → sekrety → przejęcie chmury oraz kompozycja narzędzi → RCE.
  • Największe ryzyko wynika z braku ograniczeń na wejściu (URI/ścieżki/argumenty) i z faktu, że serwer MCP działa jako uprzywilejowany wykonawca.
  • Skuteczna obrona to kombinacja: walidacji + izolacji + least privilege + kontroli tożsamości + polityk wykonywania narzędzi (a nie tylko „lepszego promptu”).

Źródła / bibliografia

  1. Dark Reading — „Microsoft & Anthropic MCP Servers At Risk of RCE, Cloud Takeovers” (20.01.2026). (Dark Reading)
  2. The Register — opis podatności i CVE w Anthropic Git MCP (20.01.2026). (The Register)
  3. Microsoft Learn — „Foundry MCP Server best practices and security guidance” (aktualizacje i governance). (Microsoft Learn)
  4. Microsoft TechCommunity — „It’s time to secure your MCP servers. Here’s how.” (JWT, podejście wdrożeniowe). (TECHCOMMUNITY.MICROSOFT.COM)
  5. Model Context Protocol — „Security Best Practices” (ryzyka i mitigacje specyficzne dla MCP, m.in. confused deputy). (Model Context Protocol)

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)

Reprompt: jedno kliknięcie wystarczało, by przejąć sesję Microsoft Copilot i wyprowadzić dane

Wprowadzenie do problemu / definicja luki

„Reprompt” to opisany przez Varonis Threat Labs łańcuch ataku na Microsoft Copilot (wariant konsumencki: Copilot Personal), w którym napastnik mógł wstrzyknąć polecenie do Copilota przez legalny link i doprowadzić do cichej eksfiltracji danych po jednym kliknięciu. Kluczowy element: Copilot akceptował prompt przekazany w parametrze URL q i wykonywał go automatycznie po załadowaniu strony, co (w połączeniu z obejściami zabezpieczeń) umożliwiało działanie „w imieniu” zalogowanego użytkownika.

Microsoft załatał problem w aktualizacjach z 13 stycznia 2026 (Patch Tuesday), a według opisu nie ma potwierdzonych dowodów masowego wykorzystania „in the wild” w momencie publikacji.

W skrócie

  • Mechanizm wejścia: phishingowy (lub podsunięty innym kanałem) link do Copilota z ukrytym promptem w parametrze q.
  • Dlaczego to groźne: 1 klik, bez wtyczek/connectorów, a atak mógł utrzymywać sterowanie nawet po zamknięciu karty Copilota.
  • Trik na guardraile: tzw. double-request (polecenie wykonania tej samej akcji dwa razy) oraz chain-request (kolejne instrukcje pobierane z serwera atakującego).
  • Status: załatane przez Microsoft (Patch Tuesday 13.01.2026); Varonis podaje, że środowiska Microsoft 365 Copilot (enterprise) nie były objęte tym konkretnym scenariuszem.

Kontekst / historia / powiązania

Reprompt wpisuje się w szerszą klasę zagrożeń dla asystentów LLM: indirect prompt injection (pośrednie wstrzyknięcie poleceń), gdzie „instrukcje” dostarcza nie sam użytkownik, lecz dane z zewnątrz (np. link, treść strony, dokument). Microsoft wprost opisuje, że skutkiem takich ataków bywa m.in. eksfiltracja danych i wykonywanie niezamierzonych akcji z uprawnieniami użytkownika, dlatego promuje podejście „defense-in-depth” (m.in. izolowanie danych nieufnych, mechanizmy detekcji typu Prompt Shields, kontrola egress i governance).

Analiza techniczna / szczegóły luki

Varonis rozbił Reprompt na trzy kluczowe techniki, które razem tworzyły stabilny łańcuch eksfiltracji:

1) Parameter 2 Prompt (P2P) injection – q w URL

Copilot potrafił przyjąć prompt w parametrze q (np. copilot.microsoft.com/?q=<PROMPT>), a następnie automatycznie go wykonać po otwarciu strony. To „feature” UX-owy, ale jednocześnie gotowy wektor do nadużyć, bo ofiara widzi „legalny” link do usługi Microsoft.

2) Double-request technique – obejście guardrails przez „zrób to dwa razy”

Według opisu badaczy, zabezpieczenia C