Archiwa: LLM - Strona 3 z 15 - Security Bez Tabu

Phantom squatting: halucynowane przez AI domeny stają się nowym narzędziem phishingu i malware

Wprowadzenie do problemu / definicja

Phantom squatting to nowa technika nadużyć, w której cyberprzestępcy rejestrują domeny wcześniej „wymyślone” przez modele językowe. Problem pojawia się wtedy, gdy system AI podaje użytkownikowi adres internetowy, który brzmi wiarygodnie i pasuje do kontekstu zapytania, ale w rzeczywistości nie istnieje. Jeśli taki adres zostanie przejęty przez atakującego, może posłużyć do phishingu, podszywania się pod markę lub dystrybucji złośliwego oprogramowania.

Z perspektywy bezpieczeństwa to groźne przesunięcie wektora ataku: źródłem ryzyka nie jest już tylko literówka użytkownika czy fałszywa reklama, ale także odpowiedź wygenerowana przez narzędzie AI, które bywa traktowane jako wiarygodny pośrednik między człowiekiem a internetem.

W skrócie

Badacze opisali kampanię, w której wykorzystano domeny halucynowane przez modele AI do działań przestępczych. Analiza dużej liczby zapytań i marek pokazała, że modele regularnie generują nieistniejące adresy URL, z których część była już powiązana ze złośliwą aktywnością, a część pozostawała wolna do rejestracji.

Zaobserwowano także scenariusze, w których domeny przewidziane wcześniej jako potencjalne halucynacje zostały po pewnym czasie rzeczywiście zarejestrowane i użyte do phishingu lub dystrybucji złośliwych aplikacji. To oznacza, że halucynacje AI mogą stać się przewidywalnym i praktycznym elementem łańcucha ataku.

Kontekst / historia

Zjawisko phantom squattingu wpisuje się w szerszy trend nadużyć związanych z generatywną AI. Wcześniej podobny mechanizm obserwowano w świecie pakietów programistycznych, gdzie modele kodujące podpowiadały nieistniejące biblioteki, a napastnicy rejestrowali je i publikowali pod nimi złośliwe komponenty.

Obecnie ten sam schemat przenosi się do przestrzeni DNS i podszywania się pod marki. Celem nie są już wyłącznie programiści, ale także zwykli użytkownicy, operatorzy agentów AI, zespoły SOC oraz firmy automatyzujące procesy przy pomocy modeli językowych. Im częściej odpowiedzi AI są traktowane jako użyteczne i domyślnie wiarygodne, tym większa szansa, że błędnie wygenerowany adres stanie się punktem wejścia do ataku.

Analiza techniczna

Mechanizm phantom squattingu opiera się na kilku właściwościach modeli językowych i samej infrastruktury internetowej. Po pierwsze, modele AI potrafią tworzyć domeny, które semantycznie pasują do pytania użytkownika. Dzieje się tak szczególnie przy zapytaniach o logowanie, bankowość, przesyłki, wsparcie techniczne, serwisy płatnicze czy aplikacje mobilne.

Po drugie, świeżo zarejestrowane domeny początkowo nie mają wyrobionej reputacji. W efekcie klasyczne mechanizmy ochrony oparte na historii domeny, reputacji, blocklistach czy feedach threat intelligence mogą potrzebować czasu, aby oznaczyć je jako podejrzane. Dla atakujących tworzy to cenne okno operacyjne.

Po trzecie, badania wskazują, że modele potrafią generować te same fałszywe domeny w sposób powtarzalny. Ta przewidywalność ma duże znaczenie operacyjne, ponieważ umożliwia identyfikowanie adresów, które z dużym prawdopodobieństwem będą pojawiać się ponownie w odpowiedziach AI. Im częściej dany nieistniejący URL jest generowany, tym bardziej atrakcyjny staje się dla przestępcy.

W opisanych przypadkach wykryto domeny powiązane z usługami finansowymi i pocztowymi, które najpierw zostały zidentyfikowane jako potencjalne halucynacje modeli, a następnie zostały zarejestrowane przez atakujących. Jedna z kampanii wykorzystywała zestaw phishingowy odtwarzający wygląd legalnego serwisu i służyła do zbierania danych kart płatniczych oraz informacji użytkowników. W innym przypadku domena posłużyła do dystrybucji złośliwej aplikacji na Androida podszywającej się pod legalne rozwiązanie.

Warto też zwrócić uwagę na kolejny poziom automatyzacji: część artefaktów sugerowała, że infrastruktura lub kod phishingowego zestawu mogły zostać przygotowane z wykorzystaniem asystenta AI. Oznacza to, że sztuczna inteligencja może uczestniczyć niemal w całym cyklu nadużycia — od wygenerowania fałszywego adresu po przygotowanie samej kampanii.

Konsekwencje / ryzyko

Najpoważniejszym skutkiem phantom squattingu jest przeniesienie zaufania z oficjalnej marki i świadomego działania użytkownika na odpowiedź modelu AI. Jeśli chatbot, wyszukiwarka oparta na LLM lub agent podaje konkretny adres, wiele osób może uznać go za zweryfikowany, mimo że jest to jedynie wynik probabilistycznego generowania tekstu.

Dla organizacji oznacza to kilka klas ryzyka:

kradzież danych uwierzytelniających i informacji finansowych,
dystrybucję malware przez strony podszywające się pod legalne usługi,
kompromitację agentów AI zdolnych do automatycznego otwierania linków lub pobierania plików,
ominięcie tradycyjnych zabezpieczeń reputacyjnych dzięki wykorzystaniu nowych domen,
wzrost skali brand impersonation i utratę zaufania do kanałów cyfrowych firmy.

Szczególnie zagrożone są sektory, w których użytkownicy regularnie korzystają z linków do logowania, płatności, dostaw, bankowości elektronicznej czy instalacji aplikacji. W takich scenariuszach jedna błędna odpowiedź AI może uruchomić pełny łańcuch ataku.

Rekomendacje

Organizacje powinny traktować phantom squatting jako realne ryzyko operacyjne związane z wdrażaniem AI. Nie jest to już jedynie problem jakości odpowiedzi, ale zagrożenie dla bezpieczeństwa użytkowników, marki i procesów biznesowych.

Weryfikować domeny zwracane przez modele AI przed ich użyciem w procesach biznesowych i komunikacji z klientami.
Blokować automatyczne otwieranie, pobieranie i uruchamianie treści pochodzących z linków wygenerowanych przez AI bez dodatkowej walidacji.
Monitorować nowe rejestracje domen podobnych do marki, także tych wynikających z przewidywalnych halucynacji modeli.
Rozszerzyć działania brand protection o scenariusze wykorzystujące adresy generowane przez AI.
Uwzględnić phantom squatting w playbookach SOC, procedurach threat huntingu i regułach detekcji.
Szkolić pracowników i użytkowników końcowych, że odpowiedź AI nie jest dowodem autentyczności domeny.
Stosować silne metody uwierzytelniania, w tym MFA odporne na phishing tam, gdzie to możliwe.
Sprawdzać wiek domeny, reputację, certyfikat oraz zgodność z oficjalnym katalogiem domen organizacji przed logowaniem lub instalacją aplikacji.

W środowiskach korzystających z agentów AI warto wdrożyć dodatkową warstwę kontroli polityk bezpieczeństwa, która oceni domenę docelową względem list dozwolonych, reputacji oraz reguł kontekstowych. To ważny krok w odejściu od modelu, w którym agent bezwarunkowo ufa linkowi zwróconemu przez LLM.

Podsumowanie

Phantom squatting pokazuje, że halucynacje modeli językowych przestały być wyłącznie problemem jakości generowanych odpowiedzi. Stały się pełnoprawnym wektorem ataku, który może wspierać phishing, podszywanie się pod marki i dystrybucję złośliwego oprogramowania.

Z perspektywy obrony kluczowe jest założenie, że każdy adres URL wygenerowany przez AI wymaga niezależnej weryfikacji. Wraz ze wzrostem znaczenia agentów, asystentów i wyszukiwarek opartych na LLM zagrożenie to będzie miało coraz większy wpływ na bezpieczeństwo użytkowników i integralność cyfrowego łańcucha zaufania.

Źródła

BioShocking: nowy atak prompt injection na przeglądarki AI umożliwia kradzież danych

Wprowadzenie do problemu / definicja

BioShocking to nowo opisana technika ataku wymierzona w przeglądarki oraz agentów AI działających w ramach sesji webowych. Mechanizm opiera się na prompt injection połączonym z manipulacją kontekstem zadania, tak aby model potraktował niebezpieczne działania jako element fikcyjnego scenariusza, gry lub symulacji.

W praktyce oznacza to możliwość obejścia zabezpieczeń, które powinny blokować dostęp do danych wrażliwych, kopiowanie sekretów czy wykonywanie operacji sprzecznych z polityką bezpieczeństwa. To istotna zmiana jakościowa, bo atak nie polega wyłącznie na wydaniu zakazanej komendy, lecz na stopniowym przestawieniu sposobu interpretowania sytuacji przez agenta.

W skrócie

Badacze opisali BioShocking jako metodę „przeprogramowania” agenta przeglądarkowego AI za pomocą odpowiednio przygotowanej strony internetowej. W scenariuszu proof-of-concept złośliwa witryna udawała grę logiczną i krok po kroku uczyła agenta, że działania zwykle uznawane za ryzykowne są w tym konkretnym kontekście akceptowalne.

W finalnej fazie agent otrzymywał polecenie przejścia do repozytorium kodu i skopiowania znajdujących się tam danych, w tym informacji poufnych. Z opisu wynika, że test objął sześć popularnych produktów z kategorii agentic browser, a skuteczną poprawkę wdrożył tylko jeden dostawca.

Kontekst / historia

Prompt injection od dłuższego czasu pozostaje jednym z najpoważniejszych problemów bezpieczeństwa systemów opartych na dużych modelach językowych. Dotychczas najwięcej uwagi poświęcano chatbotom, asystentom programistycznym oraz systemom korzystającym z mechanizmów retrieval-augmented generation.

Rozwój przeglądarek AI i agentów wykonujących działania w imieniu użytkownika znacząco rozszerzył jednak powierzchnię ataku. W odróżnieniu od klasycznego chatbota agent przeglądarkowy nie tylko interpretuje treść, ale również podejmuje realne akcje: otwiera strony, analizuje dokumenty, loguje się do usług, porusza się między kartami i kopiuje dane.

To sprawia, że skutki skutecznego prompt injection mogą być znacznie poważniejsze niż wygenerowanie błędnej odpowiedzi. BioShocking pokazuje, że problem dotyczy już nie tylko jakości odpowiedzi modelu, ale również jego zdolności do rozróżniania rzeczywistego środowiska użytkownika od sztucznie narzuconej narracji.

Analiza techniczna

Techniczna istota BioShocking polega na warstwowej manipulacji modelem sterującym przeglądarką. Atakujący przygotowuje stronę, która nie przypomina typowego wektora eksfiltracji danych, lecz wygląda jak nieszkodliwe zadanie lub gra. Taka witryna dostarcza agentowi serię instrukcji redefiniujących reguły działania.

Zamiast bezpośrednio żądać kradzieży danych, atak buduje alternatywny kontekst interpretacyjny, w którym odstępstwa od standardowych zasad mają zostać uznane za poprawne. To odróżnia BioShocking od prostszych prób nadpisania instrukcji systemowych. Tutaj celem jest wcześniejsze osłabienie mechanizmu oceny ryzyka przez „nauczenie” agenta, że działa w fikcyjnej rzeczywistości.

Jeżeli model zaakceptuje taką ramę, późniejsze polecenia mogą zostać potraktowane jako logiczna kontynuacja zadania. W opisywanym scenariuszu końcowy etap obejmował odwiedzenie repozytorium i skopiowanie danych obecnych w kodzie, w tym potencjalnie haseł, tokenów lub innych sekretów.

Kluczowy problem polega na błędzie separacji kontekstów. Agent nie rozpoznał tej czynności jako realnej operacji na wrażliwych danych, lecz jako element ukończenia gry. Z perspektywy architektury bezpieczeństwa to poważny sygnał ostrzegawczy dla całej klasy rozwiązań agentowych.

Jeśli agent ma uprawnienia do odczytu treści stron, interakcji z usługami SaaS, kopiowania danych do schowka lub wykonywania zadań między domenami, skuteczna manipulacja jego „rozumieniem sytuacji” może prowadzić do szkód wykraczających daleko poza pojedynczą witrynę.

Konsekwencje / ryzyko

Najważniejsze ryzyko związane z BioShocking to eksfiltracja danych przez zaufanego pośrednika, którym staje się sam agent AI. W tradycyjnym modelu bezpieczeństwa organizacje chronią użytkowników przed phishingiem, malware i złośliwymi skryptami. W modelu agentowym trzeba dodatkowo chronić samego agenta przed treściami wpływającymi na jego tok rozumowania i decyzje operacyjne.

ujawnienie haseł, tokenów, kluczy API i sekretów obecnych w repozytoriach lub aplikacjach webowych,
nieautoryzowane kopiowanie danych z systemów firmowych,
wykonywanie działań w imieniu użytkownika bez pełnej świadomości konsekwencji,
naruszenia polityk DLP, compliance i zasad dostępu warunkowego,
zwiększone ryzyko lateral movement w środowiskach, gdzie agent ma szeroki dostęp do usług.

Dodatkowym wyzwaniem pozostaje detekcja. Z punktu widzenia logów agent może wykonywać pozornie poprawne czynności: otwarcie strony, analizę treści, przejście do kolejnego zasobu i kopiowanie danych. Jeżeli systemy ochronne nie rozumieją semantyki decyzji agenta, incydent może wyglądać jak zwykła aktywność użytkownika wspierana automatyzacją.

Rekomendacje

Organizacje wdrażające przeglądarki AI lub agentów webowych powinny traktować je jako uprzywilejowany komponent wykonawczy, a nie tylko wygodny interfejs użytkownika. Oznacza to konieczność wprowadzenia dodatkowych kontroli technicznych i proceduralnych.

wymuszanie jawnego potwierdzenia użytkownika dla operacji wrażliwych, takich jak kopiowanie sekretów, pobieranie danych, zmiana haseł czy wysyłanie informacji poza zaufaną domenę,
ograniczanie zakresu sesji agenta do konkretnych zadań, domen i kontekstów biznesowych,
separacja dostępu między aplikacjami o różnym poziomie wrażliwości,
blokowanie lub ścisłe monitorowanie dostępu agentów AI do repozytoriów, paneli administracyjnych i systemów zawierających sekrety,
wdrożenie polityk least privilege dla rozszerzeń, wtyczek i przeglądarek agentowych,
traktowanie prompt injection jako pełnoprawnego zagrożenia webowego w programach AppSec i browser security,
stosowanie mechanizmów DLP oraz inspekcji działań wykonywanych przez agenta, a nie wyłącznie przez człowieka,
regularne testy red team i scenariusze BAS obejmujące agentów AI,
przegląd konfiguracji produktów AI pod kątem pamięci sesyjnej, dostępu do schowka, integracji z kontami oraz uprawnień między kartami.

Po stronie dostawców kluczowe wydają się trzy klasy zabezpieczeń: lepsze rozpoznawanie kontekstu, twarde granice dla działań wysokiego ryzyka oraz niezależna warstwa walidująca, czy polecenie dotyczy realnych zasobów i rzeczywistych danych. Sam filtr treści lub klasyczne guardrails modelu nie wystarczą, jeśli agent może zostać przekonany, że działa w „grze”, a nie w środowisku produkcyjnym.

Podsumowanie

BioShocking pokazuje nowy etap ewolucji prompt injection: od prostego nadpisywania instrukcji do manipulowania percepcją kontekstu przez agenta AI. To szczególnie groźne w przeglądarkach agentowych, które łączą zdolność rozumienia treści z możliwością wykonywania realnych operacji na danych użytkownika i zasobach organizacji.

Dla zespołów bezpieczeństwa wniosek jest jasny: agent AI w przeglądarce powinien być traktowany jak aktywny, uprzywilejowany podmiot wymagający osobnych polityk, monitoringu oraz kontroli dostępu. Wraz z popularyzacją agentic browsers podobne techniki będą prawdopodobnie coraz częściej testowane zarówno przez badaczy, jak i przez rzeczywistych przeciwników.

Źródła

BleepingComputer — https://www.bleepingcomputer.com/news/security/new-bioshocking-attack-manipulates-ai-browser-into-data-theft/
LayerX — BioShocking AI: “Gaming” the AI browser and escaping its guardrails — https://layerxsecurity.com/no/blog/bioshocking-ai-gaming-the-ai-browser-and-escaping-its-guardrails/
Help Net Security — Prompt injection still drives most agentic AI security failures in production — https://www.helpnetsecurity.com/2026/06/11/owasp-prompt-injection-ai-security-failures/
Cloud Security Alliance — AI Browser Extensions: The DLP-Invisible Enterprise Attack Surface — https://labs.cloudsecurityalliance.org/wp-content/uploads/2026/04/CSA_research_note_ai-browser-extension-security-gaps_20260411-csa-styled.pdf
arXiv — A Systematic Literature Review on LLM Defenses Against Prompt Injection and Jailbreaking: Expanding NIST Taxonomy — https://arxiv.org/abs/2601.22240

Przejęte endpointy AI to nowa powierzchnia ataku. Jak cyberprzestępcy nadużywają Ollama i LiteLLM

Wprowadzenie do problemu / definicja

Publicznie dostępne endpointy modeli AI oraz warstw pośredniczących LLM stają się nową i bardzo praktyczną powierzchnią ataku. W tym scenariuszu napastnik nie musi przejmować całego serwera ani wykorzystywać klasycznej podatności zdalnego wykonania kodu. Wystarczy, że organizacja wystawi do Internetu endpoint inferencyjny bez odpowiedniego uwierzytelniania lub z pozostawioną domyślną konfiguracją.

W efekcie atakujący może używać cudzej infrastruktury AI jako zaplecza do własnych operacji. Oznacza to nadużycie mocy obliczeniowej, tokenów, limitów modeli oraz logiki agentowej należącej do ofiary. To wyraźny sygnał, że bezpieczeństwo AI nie kończy się na ochronie modelu i danych, ale obejmuje również kontrolę ekspozycji API, autoryzację, monitoring oraz analizę treści żądań.

W skrócie

Badacze zaobserwowali kampanie, w których publicznie wystawione endpointy Ollama i LiteLLM były wykorzystywane do wspierania ofensywnych operacji AI. Atak nie wymagał pełnego przejęcia środowiska ani użycia klasycznej luki bezpieczeństwa.

Napastnicy kierowali klientów lub agentów AI na odsłonięte backendy modeli.
Cała logika działania agenta była dostarczana bezpośrednio w treści żądania.
Infrastruktura ofiary stawała się silnikiem dla rekonesansu, testów penetracyjnych lub reverse engineeringu.
Główną przyczyną problemu była błędna ekspozycja usług i słaba kontrola dostępu.

Kontekst / historia

Wraz ze wzrostem popularności modeli self-hosted oraz proxy LLM wiele organizacji wdraża komponenty AI szybciej niż dojrzałe mechanizmy zabezpieczeń. Narzędzia takie jak Ollama i LiteLLM znacząco upraszczają uruchamianie modeli oraz integrację z aplikacjami, ale przy niewłaściwej konfiguracji zwiększają ryzyko ekspozycji usług poza zaufaną strefą sieciową.

W analizowanych kampaniach badacze obserwowali kilka odrębnych operacji prowadzonych od marca do maja. Choć różniły się one celami i sposobem działania, łączył je ten sam schemat: wykorzystanie dostępnego z Internetu backendu AI jako zewnętrznego zasobu wykonawczego. To istotna zmiana w krajobrazie zagrożeń, ponieważ ciężar ryzyka przesuwa się z samych prompt injection i jailbreaków na przejmowanie użyteczności infrastruktury inferencyjnej.

Analiza techniczna

Sednem ataku jest wykorzystanie endpointów inferencyjnych, przez które aplikacje komunikują się z modelem. W przypadku Ollama ryzyko pojawia się wtedy, gdy usługa zostaje wystawiona poza lokalny host przez reverse proxy, tunel lub błędną konfigurację sieciową. W przypadku LiteLLM problem dotyczy przede wszystkim warstwy proxy udostępniającej zunifikowane API do różnych modeli, jeśli nie wymusza ona poprawnego uwierzytelniania lub korzysta ze słabych kluczy.

Zaobserwowany schemat był prosty i skuteczny. Najpierw wysyłano krótkie żądanie testowe, aby sprawdzić, czy endpoint odpowiada. Następnie operator przesyłał rozbudowany payload zawierający personę systemową, instrukcje operacyjne, definicje narzędzi oraz reguły działania agenta. Innymi słowy, pełna logika operacji znajdowała się w samym żądaniu, a infrastruktura ofiary dostarczała jedynie możliwości wykonawcze modelu.

W opisanych przypadkach wykorzystywano m.in. klientów LiteLLM i Ollama do obsługi frameworków agentowych o charakterze ofensywnym. Celem mogło być prowadzenie automatycznego rekonesansu, wspieranie testów penetracyjnych lub analiza aplikacji webowych pod przykryciem legalnego audytu. Kluczowe jest to, że napastnik nie potrzebował eksploitować hosta, uzyskiwać powłoki ani eskalować uprawnień. Wystarczało wskazanie publicznie dostępnego endpointu i poprawnie zbudowanego requestu.

Konsekwencje / ryzyko

Najbardziej bezpośrednią konsekwencją jest nieautoryzowane wykorzystanie zasobów organizacji. Obejmuje to moc obliczeniową, przepustowość, limity modeli oraz koszty związane z obsługą zapytań. W środowiskach komercyjnych może to szybko przełożyć się na wymierne straty finansowe.

Drugim poziomem ryzyka jest odpowiedzialność operacyjna i reputacyjna. Jeśli infrastruktura firmy zostanie użyta do wspierania działań ofensywnych wobec innych podmiotów, organizacja może nieświadomie stać się elementem łańcucha ataku. To komplikuje reagowanie na incydenty, relacje z partnerami oraz analizę nadużyć.

Istnieje też ryzyko związane z brakiem obserwowalności. Treści requestów do backendów AI mogą zawierać definicje narzędzi, instrukcje obchodzenia zasad bezpieczeństwa, cele operacyjne czy workflow agenta. Bez monitorowania zawartości żądań firma może długo nie zauważyć, że jej środowisko nie pełni roli zwykłego API, lecz aktywnie wspiera cudze operacje.

Rekomendacje

Podstawową zasadą powinno być niewystawianie backendów modeli do publicznego Internetu, jeśli nie jest to bezwzględnie konieczne biznesowo. Endpointy inferencyjne powinny być dostępne wyłącznie z zaufanych segmentów sieci, przez VPN lub kontrolowane reverse proxy z silnym uwierzytelnianiem.

Wymuś silną autoryzację i regularną rotację kluczy dostępu.
Usuń przykładowe, testowe i domyślne sekrety z konfiguracji.
Monitoruj krótkie żądania sondujące poprzedzające większe payloady.
Wykrywaj nietypowo rozbudowane prompty systemowe i definicje narzędzi ofensywnych.
Stosuj inspekcję request body, analizę logów API i korelację z telemetryką sieciową.
Traktuj środowiska AI jak standardowe systemy produkcyjne objęte nadzorem SOC.

Warto również wdrożyć podejście secure-by-default. Oznacza ono domyślne bindowanie usług do localhost, blokadę publicznej ekspozycji bez świadomej zmiany konfiguracji, obowiązkowe uwierzytelnianie oraz kontrolę dozwolonych klientów. Niezbędna jest także pełna inwentaryzacja komponentów AI, aby wiedzieć, które usługi są osiągalne z zewnątrz i jakie ryzyko generują.

Podsumowanie

Przejęcie użyteczności publicznie wystawionych endpointów AI to realny scenariusz zagrożenia, który nie wymaga klasycznego exploita. Wystarczy błędna ekspozycja usługi inferencyjnej i brak skutecznego uwierzytelniania, aby infrastruktura organizacji została wykorzystana jako zaplecze dla cudzych operacji ofensywnych.

Dla zespołów bezpieczeństwa to ważny sygnał ostrzegawczy. Endpointy LLM należy traktować jak wrażliwe usługi produkcyjne: izolować, uwierzytelniać, monitorować i regularnie testować pod kątem ekspozycji. W przeciwnym razie organizacja może szybko stać się nieświadomym dostawcą zasobów dla działań prowadzonych przez przeciwnika.

Źródła

282 aplikacje AI na iOS ujawniały klucze API LLM i otwierały dostęp do płatnych usług

Wprowadzenie do problemu

Bezpieczeństwo aplikacji wykorzystujących modele językowe coraz częściej zależy nie tylko od ochrony danych użytkowników, ale również od prawidłowego zarządzania kluczami API, tokenami i pośrednimi mechanizmami autoryzacji. Najnowsza analiza aplikacji AI dla iPhone’a pokazuje, że wiele produktów mobilnych nadal wdraża integrację z usługami LLM w sposób, który umożliwia nadużycia finansowe i techniczne.

Problem dotyczy przede wszystkim umieszczania poświadczeń po stronie klienta, niewłaściwie zabezpieczonych backendów oraz tokenów, które można przechwycić i wykorzystać ponownie. W praktyce oznacza to, że atakujący może uzyskać dostęp do płatnych usług modeli i generować koszty po stronie dostawcy aplikacji.

W skrócie

Badacze przeanalizowali 444 aplikacje chatbotów AI dla iPhone’a.
282 z nich ujawniały dostęp do płatnych usług LLM poprzez ruch sieciowy.
Wykryto jawne klucze API, otwarte backendy pośredniczące oraz podatne tokeny sesyjne.
Po trzech miesiącach od zgłoszenia tylko część aplikacji została jednoznacznie zabezpieczona.
Zjawisko wpisuje się w trend nadużyć określanych jako LLMjacking.

Kontekst i historia

Opisywane badanie zostało przedstawione jako pierwsza pogłębiona analiza tego problemu w ekosystemie iOS. Zespół badawczy skupił się na aplikacjach dostępnych w amerykańskim App Store pod koniec 2025 roku, analizując ich komunikację sieciową bez potrzeby jailbreaku urządzenia czy pełnej inżynierii wstecznej.

To ważna obserwacja, ponieważ pokazuje, że przechwycenie wrażliwych danych nie wymagało zaawansowanych technik. W wielu przypadkach wystarczała analiza zwykłego ruchu między aplikacją, serwerem pośredniczącym i dostawcą modeli językowych.

Choć podobne błędy były wcześniej opisywane w świecie Androida i szerzej w aplikacjach mobilnych, rozwój generatywnej AI zwiększył skalę ryzyka. Przejęty klucz API nie daje dziś wyłącznie dostępu do funkcji aplikacji, ale może bezpośrednio przekładać się na rosnące koszty usług obliczeniowych.

Analiza techniczna

Badacze podzielili 282 podatne aplikacje na trzy główne kategorie. Pierwsza obejmowała 54 aplikacje, które ujawniały klucze API w postaci jawnego tekstu. Taki model wdrożenia oznacza klasyczny błąd architektoniczny: sekret umieszczony po stronie klienta przestaje być sekretem, ponieważ użytkownik lub atakujący może go przechwycić.

Druga grupa objęła 92 aplikacje, których backendy pośredniczące akceptowały żądania bez skutecznej weryfikacji klienta. W praktyce taki serwer działa jak otwarty przekaźnik do płatnego konta AI. Atakujący nie musi nawet zdobywać głównego klucza, jeśli może bez przeszkód korzystać z serwera aplikacji jako bramy do modelu.

Trzecia i najliczniejsza kategoria, obejmująca 136 aplikacji, wykorzystywała tokeny czasowe lub pośrednie poświadczenia, które miały ograniczać ryzyko. W praktyce również one pojawiały się w ruchu sieciowym i często mogły zostać ponownie użyte. Część z nich zachowywała ważność znacznie dłużej, niż deklarowano, co dodatkowo zwiększało powierzchnię ataku.

Dodatkowym problemem okazał się wyciek promptów systemowych. W części aplikacji wraz z kluczem lub tokenem można było pozyskać również ukryte instrukcje sterujące zachowaniem modelu. To oznacza ryzyko nie tylko finansowe, ale również ujawnienie logiki biznesowej, zasad moderacji i wewnętrznej architektury produktu.

Badanie objęło co najmniej dziesięciu dostawców usług AI i 13 kategorii aplikacji. Najwięcej podatnych przypadków wykryto w obszarze produktywności, a najwyższy odsetek wycieków odnotowano w kategorii zdrowie i fitness, co sugeruje problem systemowy, a nie jednostkowy.

Konsekwencje i ryzyko

Najbardziej bezpośrednim skutkiem jest przejęcie cudzego budżetu na usługi AI. Osoba dysponująca kluczem lub tokenem może wykonywać zapytania do modeli na koszt właściciela aplikacji, a przy zautomatyzowanym nadużyciu skala strat może szybko wzrosnąć.

Kolejne ryzyko dotyczy utraty kontroli nad backendem aplikacji. Jeśli serwer pośredniczący nie rozróżnia legalnych i nielegalnych żądań, może zostać wykorzystany do masowych zapytań, obchodzenia limitów, ukrywania źródła ruchu lub testów obciążeniowych.

Istotne są także skutki związane z własnością intelektualną. Ujawnienie promptów systemowych i reguł sterujących ułatwia klonowanie produktu, omijanie mechanizmów bezpieczeństwa oraz przygotowywanie bardziej precyzyjnych ataków na użytkowników końcowych.

Z perspektywy reputacyjnej problem może być szczególnie dotkliwy dla aplikacji działających w obszarach zdrowia, produktywności i usług konsumenckich. Utrata zaufania użytkowników może okazać się równie kosztowna jak same nadużycia finansowe.

Rekomendacje

Podstawową zasadą bezpieczeństwa powinno być całkowite usunięcie długoterminowych kluczy API z aplikacji klienckiej. Wszystkie wywołania do usług LLM powinny przechodzić przez kontrolowany backend, który egzekwuje tożsamość użytkownika, autoryzację, limity użycia oraz kontekst sesji.

Należy stosować krótkotrwałe tokeny o minimalnym zakresie uprawnień, ściśle powiązane z użytkownikiem, urządzeniem lub sesją. Kluczowe jest również egzekwowanie wygaśnięcia po stronie serwera, a nie tylko deklarowanie go w metadanych klienta.

Organizacje powinny wdrożyć aktywny monitoring wykorzystania sekretów i tokenów. Analiza anomalii w wolumenie ruchu, geolokalizacji, liczbie urządzeń i wzorcach użycia może pomóc w szybkim wykrywaniu nadużyć i wymusić natychmiastową rotację poświadczeń.

W praktyce warto prowadzić regularne testy bezpieczeństwa z perspektywy ruchu sieciowego aplikacji mobilnej. Jeśli poświadczenie można przechwycić podczas zwykłego użycia aplikacji, należy uznać je za skompromitowane i niepolegające na właściwym modelu zaufania.

Po wykryciu incydentu konieczna jest szybka rotacja kluczy, unieważnienie tokenów, przegląd logów oraz ocena, czy nie doszło już do nadużyć finansowych lub masowego wykorzystania przez nieautoryzowane podmioty.

Podsumowanie

Analiza 444 aplikacji AI dla iOS pokazuje, że bezpieczeństwo integracji z modelami językowymi pozostaje jednym z najsłabszych punktów wielu produktów mobilnych. Skala problemu jest znacząca, ponieważ 282 aplikacje ujawniały mechanizmy dostępu do płatnych usług LLM, a część deweloperów nie usunęła błędów nawet po odpowiedzialnym zgłoszeniu.

Najważniejszy wniosek jest jednoznaczny: sekret przesyłany lub ujawniany po stronie klienta nie może być traktowany jako bezpieczny. W architekturze mobilnej klucz lub token widoczny w ruchu sieciowym należy uznać za sekret utracony.

Źródła

DifyTap: cztery luki w Dify naraziły ponad milion aplikacji AI

Wprowadzenie do problemu / definicja

Dify to popularna platforma open source wykorzystywana do budowy aplikacji opartych na dużych modelach językowych, workflow AI oraz mechanizmach RAG. Ujawniony zestaw podatności nazwany DifyTap pokazał jednak, że nawet dojrzałe środowiska LLMOps mogą zawierać błędy umożliwiające naruszenie poufności danych, obejście kontroli dostępu i dostęp do wewnętrznych usług.

W praktyce problem dotyczył nie tylko pojedynczej funkcji, ale całego łańcucha słabości obejmującego tracing, obsługę pluginów, podgląd dokumentów i operacje na plikach. To szczególnie istotne w środowiskach multi-tenant, gdzie jeden błąd autoryzacji może otworzyć drogę do danych innych klientów korzystających z tej samej infrastruktury.

W skrócie

Badacze ujawnili cztery podatności w Dify, w tym dwie o charakterze krytycznym.
Dwie luki mogły zostać wykorzystane bez uwierzytelnienia.
Trzy z opisanych błędów miały charakter cross-tenant, czyli umożliwiały dostęp do danych innych klientów.
Atakujący mogli przechwytywać rozmowy z modelami AI, odczytywać dokumenty oraz wykonywać żądania do wewnętrznych endpointów.
Producent opublikował poprawki obejmujące kluczowe elementy łańcucha ataku.

Kontekst / historia

Dify zdobyło dużą popularność jako platforma upraszczająca wdrażanie chatbotów, agentów AI i procesów automatyzacji opartych na modelach językowych. Dzięki dostępności zarówno w środowiskach lokalnych, jak i chmurowych, rozwiązanie stało się atrakcyjne dla firm budujących produkcyjne usługi generatywnej sztucznej inteligencji.

W takich wdrożeniach centralne znaczenie ma prawidłowa separacja tenantów. Gdy wiele organizacji współdzieli zaplecze aplikacyjne, każda luka w logice autoryzacji może skutkować wyciekiem danych między klientami. W przypadku DifyTap badacze wskazali właśnie na problemy z egzekwowaniem granic między tenantami oraz z ochroną zasobów przypisanych do konkretnych użytkowników i aplikacji.

Dodatkowym elementem ryzyka okazało się wykorzystanie podatnej wersji biblioteki PDFium do przetwarzania plików PDF. To rozszerzało powierzchnię ataku poza klasyczne błędy logiki biznesowej i pokazywało, że zagrożenie obejmuje również komponenty binarne odpowiedzialne za analizę nieufnych plików.

Analiza techniczna

Najpoważniejsza luka, oznaczona jako CVE-2026-41947, dotyczyła mechanizmu trace’owania. Funkcja tracingu służy do monitorowania działania aplikacji AI, w tym przepływu żądań, odpowiedzi modeli, liczby tokenów i czasu przetwarzania. W tym przypadku endpointy odpowiedzialne za konfigurację śledzenia nie weryfikowały prawidłowo kontekstu tenanta. Oznaczało to, że użytkownik posiadający konto w konsoli mógł utworzyć własny kanał trace dla aplikacji, do której miał dostęp jako zwykły klient, i w ten sposób uzyskać trwały wgląd w komunikację z modelem.

Druga krytyczna podatność, CVE-2026-41948, została znaleziona w komponencie Plugin Daemon, czyli wewnętrznej usłudze obsługującej ekosystem wtyczek. Badacze opisali dwa mechanizmy pozwalające dotrzeć do arbitralnych endpointów tego serwisu. Wariant oparty na metodzie GET wynikał z niewłaściwej sanityzacji parametru nazwy pliku, co otwierało drogę do path traversal. Dodatkowo endpoint pobierania ikon wtyczek nie wymagał logowania, więc atak mógł być wykonany zdalnie. W wariancie POST podobny problem dotyczył endpointu usuwania zadań.

Kolejne dwie luki, CVE-2026-41949 i CVE-2026-41950, dotyczyły kontroli dostępu do plików. Pierwsza umożliwiała użytkownikowi konsoli podgląd dowolnego dokumentu w systemie, ponieważ endpoint weryfikował jedynie typ obiektu, pomijając właściciela i tenant. Druga pozwalała dołączyć identyfikator UUID pliku należącego do innego użytkownika do własnej wiadomości w czacie, a następnie wykorzystać chatbota jako pośrednika do odczytu treści tego pliku.

To ważny przykład nowego wzorca ryzyka w systemach AI. Nawet jeśli aplikacja nie ujawnia zasobu bezpośrednio, model językowy może zostać wykorzystany jako warstwa pośrednia do eksfiltracji danych. W efekcie klasyczne błędy autoryzacji stają się jeszcze bardziej niebezpieczne, ponieważ mogą być łączone z zachowaniem aplikacji opartych na LLM.

Na uwagę zasługuje też kwestia zależności binarnych. Ustalono, że Dify przez długi czas korzystało z wersji PDFium podatnej na CVE-2024-5846, czyli błąd use-after-free. Przy odpowiednio spreparowanym pliku PDF taki komponent mógł potencjalnie stać się punktem wejścia do dalszego ataku na stos przetwarzania dokumentów.

Konsekwencje / ryzyko

Skutki opisanych luk mogą być poważne zarówno dla dostawców usług AI, jak i organizacji korzystających z Dify we własnych środowiskach. Przejęcie historii rozmów z modelami może prowadzić do ujawnienia danych klientów, fragmentów kodu, treści promptów, analiz dokumentów, danych operacyjnych oraz informacji biznesowych.

Szczególnie groźne są podatności cross-tenant, ponieważ uderzają w podstawowy mechanizm bezpieczeństwa usług wielodostępnych. Jeśli jeden klient może uzyskać wgląd w zasoby innego, problem wykracza poza pojedynczy incydent techniczny i staje się zagrożeniem dla zgodności, reputacji i bezpieczeństwa całej platformy.

Dostęp do dokumentów innych użytkowników może oznaczać wyciek umów, danych HR, informacji finansowych, dokumentacji technicznej czy materiałów objętych tajemnicą przedsiębiorstwa. Z kolei możliwość komunikacji z wewnętrznym API Plugin Daemon zwiększa ryzyko dalszej eskalacji, nadużyć w procesach pluginów i eksploracji funkcji normalnie niewidocznych z zewnątrz.

Ryzyko dotyczy zarówno modelu SaaS, jak i wdrożeń lokalnych. W środowiskach chmurowych najgroźniejszy jest wyciek pomiędzy tenantami, natomiast w instalacjach on-premise potencjalny zasięg może być mniejszy, ale przechowywane dane często mają znacznie wyższą wartość dla atakującego.

Rekomendacje

Organizacje korzystające z Dify powinny przede wszystkim sprawdzić, czy używane instancje działają na podatnych wersjach, a następnie niezwłocznie wdrożyć dostępne poprawki. Aktualizacja powinna objąć nie tylko główną aplikację, ale również komponenty towarzyszące i zależności wykorzystywane przy przetwarzaniu plików.

W środowiskach produkcyjnych warto dodatkowo ograniczyć powierzchnię ataku poprzez segmentację sieci, blokowanie nadmiernej ekspozycji usług wewnętrznych oraz monitorowanie ruchu do endpointów pluginów i mechanizmów obsługi plików. Szczególne znaczenie ma też analiza logów pod kątem nietypowych zmian konfiguracji tracingu oraz odczytów dokumentów poza normalnym profilem użycia.

zweryfikować wersję Dify i wdrożyć wszystkie opublikowane poprawki,
ograniczyć dostęp sieciowy do usług wewnętrznych, w tym Plugin Daemon,
wdrożyć ochronę przed path traversal i anomaliami w endpointach plikowych,
egzekwować ścisłą walidację tenant context w każdym endpointcie,
sprawdzać uprawnienia właściciela zasobu przy operacjach na dokumentach i plikach,
objąć parsery plików sandboxingiem i regularnym skanowaniem zależności,
przeprowadzić przegląd logów i ocenę potencjalnego zakresu wycieku danych.

Podsumowanie

DifyTap pokazuje, że platformy LLMOps stają się pełnoprawnym celem zaawansowanych ataków i muszą być oceniane tak samo rygorystycznie jak inne systemy krytyczne. Połączenie błędów autoryzacji, problemów z izolacją tenantów i ryzyka wynikającego z przetwarzania nieufnych plików tworzy niebezpieczny łańcuch, który może prowadzić do poważnych naruszeń poufności.

Najważniejszy wniosek jest prosty: wdrożenia AI nie mogą funkcjonować poza standardowym programem bezpieczeństwa organizacji. Potrzebują regularnego zarządzania podatnościami, segmentacji, monitoringu, przeglądów uprawnień i twardych kontroli dostępu na każdym poziomie architektury.

Źródła

DifyTap: Four Bugs Put over 1 million AI Apps at Risk — https://securityaffairs.com/194081/hacking/difytap-four-bugs-put-over-1-million-ai-apps-at-risk.html
DifyTap: Zafran discovers how attackers can silently wiretap AI data across tenants on a platform powering 1M+ apps — https://www.zafran.io/resources/difytap-zafran-discovers-how-attackers-can-silently-wiretap-ai-data-across-tenants-on-a-platform-powering-1m-apps
Release v1.14.2 – Security fixes, agent groundwork, workflow reliability, and deployment updates — https://github.com/langgenius/dify/releases/tag/1.14.2

BioShocking: nowa technika prompt injection zagraża przeglądarkom AI

Wprowadzenie do problemu / definicja

BioShocking to nowa odmiana pośredniego prompt injection, w której złośliwe instrukcje są ukrywane w publicznie dostępnych biogramach, opisach profili lub innych polach tekstowych analizowanych przez agentów AI zintegrowanych z przeglądarkami. Problem dotyczy narzędzi, które nie tylko odczytują treść stron internetowych, ale również podejmują działania w imieniu użytkownika.

W praktyce oznacza to, że pozornie neutralny opis użytkownika lub firmy może zostać zinterpretowany przez model językowy jako polecenie operacyjne. To zwiększa ryzyko manipulacji odpowiedziami, wycieku danych oraz wykonania nieautoryzowanych akcji.

W skrócie

BioShocking wpisuje się w rosnącą falę ataków indirect prompt injection wymierzonych w przeglądarki AI i agentów webowych. Mechanizm polega na osadzaniu złośliwych instrukcji w treści, którą model traktuje jednocześnie jako dane i potencjalne polecenia.

atak wykorzystuje publiczne pola tekstowe, takie jak biogramy i opisy profili,
zagrożone są przeglądarki AI oraz asystenci z funkcjami analizy stron,
skutkiem może być manipulacja odpowiedziami, wyciek danych lub wymuszenie działań,
ryzyko rośnie wraz z zakresem uprawnień nadanych agentowi.

Kontekst / historia

Prompt injection od dłuższego czasu pozostaje jednym z najpoważniejszych problemów bezpieczeństwa związanych z modelami językowymi. W ostatnim okresie szczególną uwagę zwracają ataki pośrednie, w których złośliwe instrukcje nie trafiają bezpośrednio do okna czatu, lecz są przemycane przez strony WWW, dokumenty, wiadomości e-mail lub inne źródła przetwarzane przez AI.

BioShocking należy postrzegać jako rozwinięcie tego trendu. Zamiast ukrywać polecenia w kodzie HTML czy niewidocznych fragmentach strony, napastnik wykorzystuje treść profilu lub opisu, czyli element naturalnie przetwarzany przez systemy wyszukiwania, podsumowywania i researchu. To sprawia, że atak może wyglądać niepozornie zarówno dla użytkownika, jak i dla prostych mechanizmów filtrowania.

Analiza techniczna

Od strony technicznej BioShocking opiera się na błędzie architektonicznym charakterystycznym dla wielu wdrożeń LLM. Model otrzymuje w jednym strumieniu semantycznym instrukcje systemowe, polecenie użytkownika oraz treść pobraną z internetu. Jeśli między tymi warstwami nie ma skutecznej separacji, złośliwy tekst może wpłynąć na decyzje modelu.

Atakujący publikuje spreparowany opis zawierający instrukcje sformułowane w sposób czytelny dla modelu, ale mało podejrzany dla człowieka. Gdy użytkownik poprosi agenta AI o przeanalizowanie profilu, przygotowanie podsumowania lub wykonanie researchu, treść ta trafia do kontekstu modelu i może zmienić jego zachowanie.

Typowy scenariusz ataku obejmuje kilka etapów:

napastnik umieszcza złośliwy biogram lub opis w publicznym serwisie,
ofiara otwiera stronę albo zleca agentowi analizę profilu,
agent pobiera treść i przekazuje ją do modelu,
model interpretuje ukryte instrukcje jako istotne polecenia,
system zmienia odpowiedź, odwiedza kolejne zasoby lub inicjuje nieautoryzowane działanie.

W bardziej zaawansowanych środowiskach skutki mogą być poważniejsze. Jeżeli agent ma dostęp do historii sesji, pamięci, schowka, kont, dokumentów lub zewnętrznych konektorów, prompt injection przestaje być wyłącznie problemem jakości odpowiedzi i staje się pełnoprawnym wektorem naruszenia bezpieczeństwa.

Konsekwencje / ryzyko

Największe zagrożenie wynika z faktu, że profile użytkowników i opisy kont nie są zwykle traktowane jako nośniki aktywnego ataku. Dla modelu językowego nie ma jednak znaczenia, czy instrukcja pochodzi z czatu, dokumentu czy sekcji „bio” na stronie internetowej.

Potencjalne skutki BioShocking obejmują:

manipulację odpowiedziami i fałszowanie wyników analizy,
obchodzenie ograniczeń zadanych przez użytkownika lub polityk bezpieczeństwa,
nakłanianie agenta do odwiedzania zasobów kontrolowanych przez napastnika,
wyciek danych kontekstowych, tokenów lub fragmentów dokumentów,
nadużycie funkcji automatyzacji i konektorów do usług zewnętrznych,
eskalację incydentu w środowiskach, gdzie agent może wykonywać realne operacje.

Poziom ryzyka rośnie proporcjonalnie do autonomii systemu. Narzędzie służące jedynie do podsumowywania treści niesie mniejsze zagrożenie niż agent zdolny do klikania, logowania, pobierania danych czy wysyłania wiadomości.

Rekomendacje

Organizacje wdrażające przeglądarki AI i agentów webowych powinny traktować BioShocking jako praktyczne zagrożenie operacyjne. Ochrona wymaga połączenia kontroli architektonicznych, ograniczania uprawnień i stałego monitorowania działań modelu.

stosować zasadę minimalnych uprawnień dla agentów AI,
oddzielać nieufną treść od instrukcji systemowych i logiki narzędzi,
blokować automatyczne wykonywanie akcji po analizie niezweryfikowanych danych,
wymuszać zgodę użytkownika dla operacji wysokiego ryzyka,
filtrować treści pod kątem ukrytych instrukcji i nietypowych wzorców,
monitorować wywołania narzędzi, ruch wychodzący oraz anomalie zachowania,
izolować sesje przeglądarki wykorzystywane przez AI,
ograniczać rozszerzenia i konektory z szerokim dostępem,
prowadzić testy red team oraz scenariusze prompt injection,
szkolić zespoły SOC, AppSec i inżynierów AI w zakresie zagrożeń dla LLM.

Kluczowe jest przyjęcie założenia, że każda treść pobierana z internetu może zawierać elementy wrogie. Agent AI powinien być projektowany tak, jakby działał w środowisku całkowicie nieufnym.

Podsumowanie

BioShocking pokazuje, że nawet krótki opis profilu może stać się skutecznym nośnikiem ataku na przeglądarki AI. Istotą problemu nie jest wyłącznie sam złośliwy tekst, lecz sposób, w jaki modele językowe łączą dane z internetu z logiką decyzyjną i dostępem do narzędzi.

Wraz z rozwojem agentowych interfejsów webowych prompt injection będzie coraz częściej prowadzić nie tylko do błędnych odpowiedzi, ale także do realnych incydentów bezpieczeństwa. Dla organizacji oznacza to konieczność wdrażania architektury zero trust, silnej kontroli uprawnień i nadzoru nad każdą akcją wykonywaną przez AI.

Źródła

Twój Laptop Już Słyszy Hasła. Acoustic Keystroke Recovery W Praktyce

Keylogger nie musi czytać klawiatury z systemu.

Kiedy mówimy „keylogger”, większość osób widzi klasyczny obrazek: malware, hooki w systemie operacyjnym, podejrzany proces, może DLL injection, może coś grzebiącego przy GetAsyncKeyState, może rozszerzenie przeglądarki czy fałszywy agent z uprawnieniami użytkownika.

Ale keylogger nie musi czytać klawiatury z systemu. Czasem wystarczy, że słucha pokoju.

Czytaj dalej