Archiwa: LLM - Security Bez Tabu

ShadowRay 2.0: nowa fala ataków zmienia klastry Ray w koparki kryptowalut

Wprowadzenie do problemu / definicja luki

Trwa globalna kampania „ShadowRay 2.0”, w której napastnicy przejmują publicznie dostępne klastry Ray (open-source framework do skalowania aplikacji AI/Python) i zamieniają je w samopropagującą się infrastrukturę do kopania Monero. Wektor wejścia to nadal sporna, niewyłatania podatność CVE-2023-48022 w API zadań Ray, umożliwiająca zdalne wykonanie kodu bez uwierzytelnienia przy błędnej ekspozycji usług na Internet. Najnowsza fala kampanii rozszerza się poza cryptojacking – obserwowane są kradzieże danych/poświadczeń i funkcje DDoS.

W skrócie

  • Nowa kampania („ShadowRay 2.0”): ta sama luka, bardziej automatyczny łańcuch ataku; self-spread między węzłami/klastrami.
  • Ekspozycja ekosystemu: badacze szacują dziś >230 tys. serwerów Ray widocznych w Internecie (wcześniej „kilka tysięcy”).
  • CVE-2023-48022: zdalne RCE przez Jobs API; ocena CVSS 9.8 (CRITICAL), status „disputed” – twórcy Ray wskazują, że Ray ma działać w „ściśle kontrolowanym środowisku”.
  • Ładunki: generowane z pomocą LLM (charakterystyczne komentarze/docstringi), moduł XMRig ograniczający użycie CPU do ~60%, utrwalanie przez cron/systemd, reverse-shelle i moduł DDoS (Sockstress).
  • Brak łatki: zalecenia to „best practices” Anyscale – uruchomienie w zaufowanej sieci, filtrowanie portu 8265 (Dashboard), autoryzacja przez proxy, monitoring anomalii.

Kontekst / historia / powiązania

Pierwszą kampanię ShadowRay opisano w marcu 2024 r., wskazując aktywne nadużycia od września 2023 r. Wtedy już raportowano setki skompromitowanych klastrów oraz dominujące użycie koparek (XMRig/NBMiner/Zephyr) i reverse-shelli. Jednocześnie Anyscale podtrzymało, że brak wbudowanego uwierzytelniania to decyzja projektowa, a instancje powinny działać w środowiskach kontrolowanych; firma zapowiadała dodanie auth w przyszłych wersjach.

Analiza techniczna / szczegóły luki

CVE-2023-48022 dotyczy Jobs API w Ray i umożliwia zdalne przesłanie/uruchomienie zadań (Bash/Python) bez uwierzytelnienia, jeśli endpointy są wystawione na świat. NVD klasyfikuje lukę jako krytyczną (CVSS 9.8). Brak łatki wynika z modelu zaufania Ray – framework zakłada izolację sieciową i kontrolę dostępu po stronie operatora. W praktyce tysiące wdrożeń są błędnie wystawione (np. 0.0.0.0) lub pozbawione filtracji, co czyni je łatwym celem.

W ShadowRay 2.0 napastnicy (TRACK: IronErn440) korzystają z CVE-2023-48022 do uruchamiania wielostopniowych łańcuchów Bash/Python. Payloady, z oznakami generowania przez LLM, po zainfekowaniu rozsiewają się na wszystkie węzły klastra poprzez natywne mechanizmy orkiestracji Ray, a nawet klaster-do-klastra. Zaobserwowano dwie fale: starszą z dystrybucją przez GitLab (zakończona 5 listopada) i nową przez GitHub (aktywna od 17 listopada).

Moduły złośliwe obejmują:

  • Cryptojacker (XMRig) – wykrywa CPU/GPU, maskuje procesy (np. dns-filter), limity CPU (ok. 60%), zabija konkurencyjne koparki, blokuje pule w /etc/hosts i iptables, utrzymuje persistencję przez cron/systemd.
  • Dostęp interaktywny – wiele reverse-shelli do infrastruktury C2, z możliwością eksfiltracji danych środowisk ML (sekrety, hasła DB, klucze SSH, tokeny usług).
  • DDoS – komponent oparty o Sockstress do wyczerpywania zasobów TCP.

Praktyczne konsekwencje / ryzyko

  • Utrata mocy obliczeniowej (GPU/CPU) i wzrost kosztów chmurowych przez kopanie kryptowalut.
  • Wycieki sekretów produkcyjnych: hasła DB, klucze SSH, tokeny (OpenAI, HuggingFace, Slack, Stripe), dostęp do kube-API – ryzyko lateral movement i kompromitacji danych klientów.
  • Degradacja dostępności: możliwość użycia zasobów do DDoS oraz wpływ na trening/inferencję modeli.

Rekomendacje operacyjne / co zrobić teraz

  1. Nie wystawiaj Ray na Internet: uruchamiaj wyłącznie w zaufowanej, odseparowanej sieci/VPC/VPN; blokuj ruch przychodzący do komponentów Ray (w tym Dashboard :8265) regułami firewall/SG.
  2. Warstwa autoryzacji przed Dashboard/Jobs API: jeżeli dostęp zdalny jest konieczny, zastosuj reverse proxy z uwierzytelnianiem (mTLS/OIDC) i autoryzacją endpointów. Nie wiąż usług na 0.0.0.0.
  3. Higiena sekretów: rotuj poświadczenia (DB/SSH/API), unieważnij tokeny znalezione w logach/środowiskach i wymuś krótkie TTL. (Wnioski z incydentów ShadowRay.)
  4. Monitoring runtime: alertuj na tworzenie nietypowych zadań, reverse-shelle, połączenia do puli Monero, procesy podobne do xmrig, modyfikacje crontab/systemd. (IOC-e i TTP-y opisane przez Oligo.)
  5. Segmentacja i egress control: ogranicz ruch wychodzący z węzłów Ray do niezbędnych destynacji; blokuj znane pule, domeny pastebin/Git* używane w kampanii.
  6. Plan odzyskania: w razie kompromitacji – odseparuj klaster, zbuduj nowy z zaufanych artefaktów, przeprowadź triage sekretów i przegląd dostępu do chmury.
  7. Śledź komunikaty producenta: Anyscale wcześniej sygnalizowało przyszłe wsparcie auth – wdrażaj gdy dostępne; do tego czasu polegaj na izolacji sieci i kontrolach dostępu.

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

W porównaniu z typowymi kampaniami cryptojacking w klastrach kontenerowych, ShadowRay wyróżnia:

  • Wykorzystanie Jobs API Ray jako „legalnego” mechanizmu wykonania kodu (przy błędnej ekspozycji), co utrudnia detekcję przez skanery SAST/kompilacyjne.
  • Szybkie rozprzestrzenianie w obrębie klastra dzięki wbudowanej orkiestracji Ray oraz automatyczne „cluster-to-cluster spreading” w fali 2.0.
  • Ładunki generowane przez LLM (charakterystyczne artefakty w kodzie), co wskazuje na rosnącą automatyzację po stronie atakujących.

Podsumowanie / kluczowe wnioski

  • ShadowRay 2.0 pokazuje, że błędna ekspozycja usług AI to dziś jeden z najbardziej kosztownych błędów operacyjnych.
  • Brak wbudowanego auth w Ray nie jest „bugiem” w rozumieniu vendor-a, ale ryzyko operacyjne – które trzeba neutralizować segmentacją, filtracją i proxy z autoryzacją.
  • Zespoły ML/AI powinny mieć runbook na wypadek kompromitacji klastrów treningowych/inferencyjnych oraz telemetrykę ukierunkowaną na IOC/TTP ShadowRay.

Źródła / bibliografia

  1. BleepingComputer – „New ShadowRay attacks convert Ray clusters into crypto miners” (18 listopada 2025). (BleepingComputer)
  2. Oligo Security – „ShadowRay: First Known Attack Campaign Targeting AI Workloads…” (26 marca 2024). (oligo.security)
  3. NVD (NIST) – wpis CVE-2023-48022 (RCE w Ray Jobs API, CVSS 9.8, status „disputed”). (NVD)
  4. SecurityWeek – „Ray AI Framework Vulnerability Exploited to Hack Hundreds of Clusters” (27 marca 2024). (SecurityWeek)
  5. The Hacker News – „Critical Unpatched Ray AI Platform Vulnerability Exploited for Cryptocurrency Mining” (27 marca 2024). (The Hacker News)

Microsoft ujawnia „Whisper Leak”: atak boczny ujawniający temat rozmów z LLM mimo szyfrowania

Wprowadzenie do problemu / definicja luki

Microsoft opisał nowy atak boczny na zdalne modele językowe (LLM), nazwany Whisper Leak. Pozwala on pasywnemu podsłuchującemu — np. operatorowi sieci, atakującemu w tej samej sieci Wi-Fi lub obserwatorowi na łączu — wnioskować o temacie rozmowy z chatbotem, mimo że ruch jest szyfrowany (HTTPS/TLS). Skuteczność ataku wynika z analizy metadanych ruchu: rozmiarów i czasów nadejścia pakietów podczas strumieniowania odpowiedzi modelu. To nie jest błąd kryptograficzny TLS, tylko nadużycie informacji ujawnianej przez samą naturę strumieniowania tokenów.


W skrócie

  • Co wycieka? Nie treść wiadomości, lecz klasa/temat rozmowy (np. pytania o pranie pieniędzy, zdrowie, politykę).
  • Jak? Klasyfikator uczy się wzorców z sekwencji rozmiarów pakietów i odstępów czasowych przy strumieniowaniu odpowiedzi.
  • Skuteczność: Microsoft raportuje dla wielu popularnych modeli wyniki >98% AUPRC; w scenariuszu 1 rozmowa na 10 000 „szumu” możliwa jest 100% precyzja przy 5–50% pokrycia przypadków docelowych.
  • Kto załatał? Po jawnej koordynacji dostawcy tacy jak OpenAI, Mistral, Microsoft, xAI wdrożyli pierwsze obfuscatory strumienia (dodawanie losowego tekstu / parametry API) i inne utrudnienia.
  • Ryzyko: Realne dla użytkowników w środowiskach podwyższonego nadzoru (ISP, sieci publiczne), organizacji korzystających z LLM w wrażliwych domenach (prawo, zdrowie, compliance).

Kontekst / historia / powiązania

Whisper Leak wpisuje się w rosnące portfolio ataków kanałami pobocznymi na LLM:

  • Token-length side-channel (USENIX ‘24) — na podstawie długości tokenów (wnioskowanej z rozmiarów pakietów) rekonstruowano częściowo odpowiedzi oraz temat rozmowy.
  • Remote timing attacks (2024) — wykorzystują zależności czasowe w efektywnym wnioskowaniu (np. speculative decoding) do rozpoznawania właściwości promptu/odpowiedzi.

Microsoft buduje na tych pracach, łącząc rozmiary i timingi pakietów w jeden wektor cech i pokazując, że to wystarcza do trafnego klasyfikowania tematów w ruchu szyfrowanym.


Analiza techniczna / szczegóły luki

Założenie ataku: napastnik passive network observer ma podgląd do ruchu TLS między klientem a usługą LLM, ale go nie deszyfruje.

Powierzchnia ataku: większość klientów LLM strumieniuje odpowiedź — tokeny (lub małe grupy tokenów) są wysyłane na bieżąco. Dla TLS oznacza to ciąg pakietów o pewnych rozmiarach i przerwach. Ponieważ rozmiar szyfrogramu ~ rozmiarowi plaintextu + stałe narzuty, wzorce długości i czasu stają się „odciskiem palca” danego tematu i sposobu generacji.

Pipeline Whisper Leak (upraszczając):

  1. Zbieranie próbek: generowanie zestawu wariantów pytań z wrażliwego tematu (POC: „legalność prania pieniędzy”) oraz dużego zbioru losowych pytań-szumu; rejestrowanie ruchu (np. tcpdump) dla różnych dostawców/modeli.
  2. Ekstrakcja cech: sekwencje (size_i, Δt_i) z ruchu TLS podczas strumieniowania.
  3. Uczenie: klasyfikatory sekwencji (LightGBM, Bi-LSTM, DistilBERT z bucketami rozmiaru/czasu).
  4. Ewaluacja: metryka AUPRC na zbiorze ekstremalnie niezrównoważonym (np. 1:10 000 target:noise). Wynik: >98% dla wielu usług; w praktycznym modelu nadzoru wysoka precyzja przy istotnym recall.

Dlaczego to działa?

  • Autoregresja i (niekiedy) optymalizacje efektywności wprowadzają zależne od danych różnice czasowe.
  • TLS nie ukrywa rozmiarów i timingów rekordów/aplikacyjnych ramek; to metadane.

Minimalny PoC zbierania cech (edukacyjnie):

# przechwyć sesję HTTPS do dostawcy LLM (np. domena api.*)
sudo tcpdump -i eth0 -w llm.pcap 'tcp port 443 and host api.example-llm.com'
# wyodrębnij rozmiary i interwały z PCAP (pyshark)
import pyshark, numpy as np
cap = pyshark.FileCapture('llm.pcap', display_filter='tcp && tls')
sessions = {}
for p in cap:
    key = (p.ip.src, p.tcp.stream) if 'TLS' in p else None
    if not key: continue
    ts = float(p.sniff_timestamp)
    size = int(p.length)  # długość ramki
    sessions.setdefault(key, []).append((ts, size))
features = []
for k, seq in sessions.items():
    seq.sort()
    dts = np.diff([t for t,_ in seq], prepend=seq[0][0])
    feats = list(zip([s for _,s in seq], dts))
    features.append(feats)
print("sesji:", len(features))

(Powyższe służy naukowym ćwiczeniom nad detekcją wewnętrzną — nie do nadużycia).


Praktyczne konsekwencje / ryzyko

  • Model zagrożeń: ISP, operator chmury pośredniczącej, współużytkownicy Wi-Fi, każdy z możliwością passive sniffing.
  • Co można wywnioskować? Temat konwersacji (np. przestępczość finansowa, medyczne zapytania, poglądy polityczne). To wystarczy do profilowania i wyzwolenia działań (cenzura, targetowanie).
  • Sektory wrażliwe: prawo, zdrowie, finanse, sektor publiczny, media/NGO w krajach restrykcyjnych.
  • Skala: badanie obejmowało 28 modeli głównych dostawców; część z nich osiągała wyniki umożliwiające nadzór na masową skalę.

Rekomendacje operacyjne / co zrobić teraz

Dla dostawców/usług LLM (serwer)

  1. Obfuskacja strumienia odpowiedzi — dodawanie losowego tekstu o zmiennej długości do chunków strumieniowych (wprowadzono m.in. w OpenAI, Azure; Mistral dodał dedykowany parametr). Silnie obniża skuteczność ataku.
  2. Batching tokenów (np. wysyłanie co 3–5 tokenów zamiast pojedynczych) — wygładza wzorce. Trade-off: większa latencja „pierwszego znaku”.
  3. Packet injection / cover traffic — wtryski dodatkowych ramek/”szumu” (koszt: 2–3× narzut pasma).
  4. Tryb niestreamingowy (opcjonalny) — umożliwienie klientom żądania odpowiedzi bez strumienia dla zapytań wrażliwych.
  5. Ciągła ewaluacja — testy regresyjne pod kątem wycieków metadanych (AUPRC/ROC na syntetycznych zbiorach tematów).

Dla integratorów/architektów (klient, brzeg)

  • Wyłącz strumieniowanie dla przepływów „tajemniczych” (domyślnie stream=False / brak streamu w większości SDK). Segmentuj ruch (oddzielny endpoint/trasowanie dla zapytań wrażliwych).
  • Preferuj dostawców z wdrożonymi mitigacjami (OpenAI, Azure, Mistral, xAI — wg stanu na 7–9 listopada 2025).
  • VPN/zero-trust egress na wyjściu organizacji (utrudnia lokalnym przeciwnikom korelację strumienia, choć nie eliminuje ataku u dostawcy/ISP).
  • Buduj detektory anomalii na własnych bramach (np. wykrywanie nietypowych wzorców TLS/HTTP2 dla usług LLM, by lokalnie oceniać ryzyko ekspozycji).

Dla zespołów bezpieczeństwa (SOC/Blue)

  • Policy awareness: oznacz tematy wrażliwe i wymuś polityki non-streaming + dostawcy z mitigacjami.
  • Monitoring: rejestrowanie metryk egress (rozmiary rekordów, jitter) w kanałach do usług LLM, by audytować zgodność.
  • Szkolenia użytkowników: nie zadawać pytań o wysokiej wrażliwości przez LLM w sieciach niezaufanych (hotele, kawiarnie).

Przykładowe „kontrole” w praktyce (demo):

  • Blokowanie strumieniowania po stronie reverese-proxy (np. endpoint „sensitive” przekierowany do niestreamingowej ścieżki API).
  • Kontrola jakości dostawcy — test A/B: wysyłaj paczkę 100 pytań „sensitive” i 10 000 pytań „noise”; mierz AUPRC własnym klasyfikatorem metadanych — jeśli > próg (np. 0.9), eskaluj do zmiany dostawcy/konfiguracji.

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

  • Whisper Leak vs. Token-length (Weiss et al. 2024): Weiss celował w rekonstrukcję treści bazując na długościach tokenów; Whisper Leak skupia się na klasyfikacji tematu na bazie rozmiarów i timingów pakietów — skuteczne nawet, gdy usługodawca grupuje tokeny.
  • Whisper Leak vs. Remote Timing (Carlini & Nasr 2024): Carlini/Nasr eksploitują optymalizacje efektywności (np. speculative decoding) i subtelne różnice czasowe; Whisper Leak korzysta z makro-wzorca strumienia (rozmiar+czas) i działa na popularnych usługach.

Podsumowanie / kluczowe wnioski

  • Metadane ruchu LLM potrafią zdradzić temat rozmowy mimo TLS.
  • Atak jest praktyczny przy masowym nadzorze (ISP/Wi-Fi), co rodzi realne ryzyka dla prywatności i compliance.
  • Mitigacje istnieją, ale to trade-off koszt/latencja/jakość i nie dają pełnej eliminacji — potrzebny defense-in-depth po stronie dostawcy i rozsądna higiena użytkowania po stronie klienta.

Źródła / bibliografia

  1. Microsoft Security Blog — Whisper Leak: A novel side-channel attack on remote language models (7 listopada 2025). (Microsoft)
  2. McDonald, Bar-Or — Whisper Leak: a side-channel attack on Large Language Models (arXiv, 5 listopada 2025). (arXiv)
  3. Weiss et al. — What Was Your Prompt? A Remote Keylogging Attack on AI Assistants (USENIX Security 2024 / arXiv). (arXiv)
  4. Carlini, Nasr — Remote Timing Attacks on Efficient Language Model Inference (arXiv, 22 października 2024). (arXiv)
  5. The Hacker News — Microsoft Uncovers ‘Whisper Leak’ Attack That Identifies AI Chat Topics in Encrypted Traffic (8 listopada 2025). (The Hacker News)

Daylight pozyskuje 33 mln dol. na „agentowe” MDR. Co to oznacza dla SOC-ów?

Wprowadzenie do problemu / definicja luki

Skalowanie operacji bezpieczeństwa (SOC) rozbija się dziś o dwa twarde limity: czas reakcji i liczbę ludzi. Klasyczne MDR-y (Managed Detection and Response) odciążają zespoły, ale nadal cierpią na przeciążenie alertami i „eskalowanie zamiast rozwiązywania”. Startup Daylight proponuje alternatywę: połączenie agentowych systemów AI z nadzorem doświadczonych analityków, aby dostarczać rezultaty (containment, remediacje) zamiast samych powiadomień. Firma właśnie ogłosiła rundę 33 mln USD (Series A), która ma przyspieszyć rozwój platformy oraz modułów dla Identity Threat Response i Cloud Workload Protection.

W skrócie

  • 33 mln USD Series A prowadzone przez Craft Ventures; udział m.in. Bain Capital Ventures i Maple VC. Całkowite finansowanie: 40 mln USD.
  • Daylight określa swój model jako MASS – Managed Agentic Security Services: autonomiczne agentowe AI + nadzór analityków 24/7.
  • Cel rundy: ekspansja w USA, rozwój platformy operacji bezpieczeństwa i uruchomienie modułów dla tożsamości oraz chmury.
  • Firma deklaruje wdrożenia „w mniej niż godzinę”, „do 90% mniej false positives” i klientów w USA/EU (m.in. The Motley Fool, Cresta, McKinsey Investment Office). (Deklaracje producenta)
  • Założyciele: Hagai Shapira (CEO) i Eldad Rudich (CTO) – weterani Unit 8200.

Kontekst / historia / powiązania

Runda ogłoszona 4–5 listopada 2025 r. następuje trzy miesiące po seedzie 7 mln USD i wpisuje się w trend przyspieszonego finansowania narzędzi AI-native SecOps. W tle mamy eksplozję ataków napędzanych AI, rosnące środowiska hybrydowe i chroniczny deficyt talentów w SOC. Daylight pozycjonuje MASS jako ewolucję MDR: agenci AI wykonują monitoring, triage, dochodzenia kontekstowe i wstępne remediacje, a analitycy podejmują decyzje o wyższym ciężarze.

Analiza techniczna / szczegóły podejścia

Architektura MASS (wysnuta z opisów publicznych):

  • Warstwa agentowa (AI-core): zestaw wyspecjalizowanych agentów wykonujących korelację sygnałów, priorytetyzację, „case building” oraz autonomiczne działania (np. izolacja hosta, blokada konta, polityka w EDR/IdP), z możliwością pracy cloud/on-prem/hybryda.
  • Nadzór ekspercki (human-in-the-loop): analitycy „kalibru PhD” potwierdzają hipotezy, rozszerzają zakres dochodzenia, zatwierdzają remediacje wysokiego ryzyka i utrzymują „guardrails” dla agentów.
  • Integracje i czas wartości: producent podkreśla szybkie wdrożenie (<1h) i pracę „w istniejącej infrastrukturze” – to sugeruje gotowe konektory do EDR/XDR, SIEM, IdP, chmur. (Deklaracje producenta)
  • Nowe moduły: Identity Threat Response i Cloud Workload Protection mają rozszerzyć autonomię poza klasyczne endpointy.

Różnica semantyczna: Daylight używa pojęcia MASS aby odróżnić się od „AI-assisted MDR”. Klucz to agentowość (samodzielne działanie agentów w granicach polityk) zamiast samego „copilota” do analizy zdarzeń.

Praktyczne konsekwencje / ryzyko

Plusy dla SOC:

  • Skrócenie MTTD/MTTR dzięki automatycznym dochodzeniom i remediacjom niskiego ryzyka.
  • Redukcja alert fatigue i kosztów eskalacji; potencjalnie mniej ról L1/L2, więcej „SRE-like SecOps”.

Ryzyka i „ciemne pola”:

  • Zaufanie do agentów: konieczne twarde guardrails, audyt działań i „two-person rule” dla akcji destrukcyjnych (np. masowe disable kont).
  • Bias danych i halucynacje: agentowe systemy oparte na LLM muszą mieć deterministyczne playbooki i walidację efektów.
  • Vendor lock-in & integracje: rzeczywista głębokość integracji z EDR/XDR/IdP/SaaS będzie decydować o skuteczności poza presales demo.
  • Regulacje/zgodność: ścieżki audytu, eDiscovery i zgodność z politykami tożsamości (zwłaszcza w UE).
    (Ocena własna na podstawie publicznych opisów architektury.)

Rekomendacje operacyjne / co zrobić teraz

  1. Pilot 60–90 dni: wybrane segmenty (np. wybrane OU w IdP, część floty EDR, wycinek chmury). Zdefiniuj KPI: MTTD/MTTR, % zautomatyzowanych remediacji, precyzja triage.
  2. RACI dla agentów: policy gates dla akcji o wysokim wpływie (disable użytkownika, kwarantanna zasobu chmurowego).
  3. Playbooki „deterministyczne”: ustandaryzowane runbooki SOAR jako „rails” dla agentów; logowanie decyzji i wyników.
  4. Ocena integracji: sprawdź konektory do twoich krytycznych systemów (IdP, EDR/XDR, chmury, SaaS).
  5. Model zagrożeń AI: włącz AI threat modeling (np. ryzyka „model misuse”, nadmierna autonomiczność, eskalacja uprawnień).
  6. Due diligence dostawcy: SLA na czas reakcji analityków, transparentność działań agentów, mechanizmy „kill-switch”.

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

  • Klasyczny MDR/XDR: zwykle „detect → alert → escalate”, ograniczona automatyzacja i często ręczne dochodzenia. Daylight twierdzi, że przechodzi do „detect → investigate → resolve” z agentami AI, a człowiek nadzoruje tylko trudne przypadki.
  • „AI-assisted SOC copilot”: narzędzia pomagające analitykom pisać zapytania lub streszczać alerty. MASS aspiruje do autonomii operacyjnej w ramach polityk (containment/remediacje), co zbliża je do „autonomic SOC”.

Podsumowanie / kluczowe wnioski

  • Runda 33 mln USD (Series A) potwierdza popyt na agentowe podejście do SecOps. MASS ma ambicję dostarczać wynik, nie tylko alert.
  • Sukces wdrożeń będzie zależeć od jakości integracji, dojrzałości guardrails i przejrzystości działań agentów.
  • Dla CISO to realna ścieżka do skrócenia MTTR bez liniowego zwiększania etatów – ale wymaga świadomego pilotowania, kontroli zmian i audytu.

Źródła / bibliografia

  1. SecurityWeek: Daylight Raises $33 Million for AI-Powered MDR Platform (05.11.2025). (SecurityWeek)
  2. Blog Daylight (Hagai Shapira): Lighting the Next Chapter… (04.11.2025). (daylight.ai)
  3. SiliconANGLE: Daylight Security raises $33M… (04.11.2025). (SiliconANGLE)
  4. CTech / Calcalistech: Cyber startup Daylight raises $33 million… (04.11.2025). (ctech)
  5. Daylight – About / Leadership. (daylight.ai)

PhantomRaven zalewa npm pakietami kradnącymi dane logowania. Co wiemy i jak się bronić

Wprowadzenie do problemu / definicja luki

Aktywna kampania PhantomRaven celuje w programistów ekosystemu JavaScript, publikując dziesiątki złośliwych paczek w rejestrze npm. Ich celem jest kradzież tokenów uwierzytelniających (npm, GitHub Actions, GitLab, Jenkins, CircleCI), sekretów CI/CD oraz poświadczeń do repozytoriów, co otwiera drogę do wtórnych ataków na łańcuch dostaw oprogramowania. Kampania rozpoczęła się w sierpniu 2025 r., obejmuje 126 paczek i przekroczyła 86 000 pobrań. Zidentyfikowali ją badacze Koi Security; część paczek w momencie publikacji raportów była wciąż dostępna w npm.

W skrócie

  • Skala: 126 złośliwych paczek, >86 000 pobrań (sierpień–październik 2025).
  • Technika ukrycia: Remote Dynamic Dependencies (RDD) – paczki deklarują 0 zależności, a właściwy ładunek dociągają z zewnętrznego serwera podczas npm install.
  • Egzekucja: wykorzystanie skryptów lifecycle (np. preinstall) do automatycznego uruchomienia payloadu bez interakcji użytkownika.
  • Kradzione dane: tokeny npm/GitHub/GitLab/Jenkins/CircleCI, fingerprinting systemu i środowiska CI/CD, adresy e-mail.
  • Exfiltracja: redundancja kanałów (HTTP GET z danymi w URL, HTTP POST/JSON, WebSocket).
  • Socjotechnika nazw: slopsquatting – wykorzystywanie halucynacji LLM do rejestrowania nieistniejących, lecz „wiarygodnie brzmiących” nazw paczek.

Kontekst / historia / powiązania

Ukrywanie złośliwego kodu w pakietach open source nie jest nowe, jednak PhantomRaven łączy kilka trendów: nadużycie rzadko używanej funkcji npm (URL-owe specyfikatory zależności), automatyczne skrypty instalacyjne i LLM-asystowanych rekomendacji paczek. Media branżowe opisują to jako ataki z „niewidzialnymi zależnościami”, które omijają statyczne skanery rejestrów i klasyczne analizatory SBOM.

Analiza techniczna / szczegóły luki

Remote Dynamic Dependencies (RDD)

Zamiast standardowych wpisów w "dependencies", złośliwe paczki wskazują HTTP URL (np. http://packages.storeartifact.com/...). Taki komponent nie znajduje się w npmjs.com, więc wiele narzędzi SCA/SAST go nie analizuje – interfejs npm pokazuje „0 dependencies”, co uśpiwa czujność. Podczas npm install pobierany jest zdalny pakiet, który zawiera preinstall uruchamiający złośliwy kod.

Łańcuch ataku

  1. Deweloper instaluje pozornie czystą paczkę z npm.
  2. Npm dociąga „niewidzialną” zależność z kontrolowanego przez atakującego hosta.
  3. Skrypt preinstall uruchamia się automatycznie, bez pytań.
  4. Malware wykonuje profilowanie systemu, enumerację e-maili i zbieranie sekretów CI/CD.
  5. Dane są eksfiltrowane wieloma kanałami (GET/POST/WebSocket).

Cele i techniki zbierania danych

  • Tokeny: npm, GitHub Actions, GitLab CI, Jenkins, CircleCI.
  • Fingerprinting: IP publiczny i lokalny, hostname, OS, wersja Node.js, bieżący katalog.
  • Artefakty identyfikacyjne: adresy e-mail z env, .gitconfig, .npmrc, package.json.

Infrastruktura i IoC

  • Domena/C2: packages.storeartifact.com
  • IP: 54.173.15.59
  • Endpoint exfiltracyjny: jpd.php
  • Wzorce kont/e-maili publikujących: jpdtester0X@..., m.in. jpdtester07@outlook[.]com, jpdtester12@gmail[.]com itd.
  • Przykładowe nazwy paczek: unused-imports, eslint-comments, transform-react-remove-prop-types, @gitlab-lsp/*, artifactregistry-login, crowdstrike, react-async-component-lifecycle-hooks, syntax-dynamic-import i wiele innych (pełna lista w raporcie Koi).

Slopsquatting (LLM-assisted naming)

Atakujący rejestrują nieistniejące wcześniej, lecz „wiarygodne” nazwy, które LLM potrafią podpowiadać jako rzekomo właściwe („unused-imports” vs. prawidłowe eslint-plugin-unused-imports, itp.). To omija proste reguły typosquattingu i zwiększa skuteczność socjotechniki wobec developerów polegających na asystentach AI.

Praktyczne konsekwencje / ryzyko

  • Przejęcie pipeline’ów i możliwość dorzucenia złośliwych commitów/releasów (supply-chain).
  • Kradzież sekretów skutkująca lateral movement do chmur, rejestrów artefaktów i środowisk produkcyjnych.
  • Trudna detekcja w klasycznych skanerach – ładunek nie jest obecny w artefakcie z npm, a zależności wyglądają na puste.

Rekomendacje operacyjne / co zrobić teraz

Natychmiastowa reakcja (IR):

  1. Blokada IoC: zablokuj packages.storeartifact.com i powiązane IP na egressie; monitoruj ruch HTTP/WS do niezatwierdzonych hostów.
  2. Hunting: przeszukaj logi o instalacjach paczek z listy Koi; sprawdź wywołania npm install z nietypowymi URL-ami w package.json/package-lock.json.
  3. Rotacja sekretów: unieważnij tokeny npm/GitHub/GitLab/Jenkins/CircleCI, klucze API i hasła; wymuś ponowną autoryzację runnerów/agentów.
  4. Przegląd repozytoriów: audit ostatnich commitów/tagów/CI workflows pod kątem nieautoryzowanych zmian.

Twardnienie (hardening) na przyszłość:

  • Wyłącz skrypty lifecycle podczas CI: uruchamiaj npm ci z --ignore-scripts (lub npm config set ignore-scripts true w pipeline’ach, a w razie potrzeby whitelistuj pojedyncze przypadki). Uzupełnij o izolację sieciową stepów instalacyjnych. (Zasada wynika z analizy mechanizmu preinstall.)
  • Blokada zależności z URL: polityki DevSecOps/SCA powinny odrzucać HTTP(S) dependencies w package.json. Monitoruj PR-y pod kątem zmian w sekcji dependencies/scripts.
  • Wymuś 2FA i OIDC-based tokens dla dostępu do rejestrów/kont CI/CD; minimalne uprawnienia i krótkie TTL tokenów.
  • SBOM + detekcja behawioralna: klasyczny SBOM nie pokaże RDD; uzupełnij go o dynamiczną analizę instalacji (wykrywanie połączeń sieciowych podczas npm install).
  • Repozytoria lustrzane/air-gap: rozważ wewnętrzne mirrorowanie uznanych paczek i blokadę instalacji z internetu w CI (allowlist).
  • Edukacja dot. LLM: wprowadź guideline’y nt. weryfikacji nazw paczek sugerowanych przez AI; wymagaj sprawdzenia istnienia i reputacji projektu.

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

  • Klasyczny typosquatting: złośliwy kod siedzi w paczce na rejestrze; tutaj kod jest poza rejestrem (RDD), więc omija wiele skanerów.
  • Kampanie 2023–2025 (npm/PyPI) nierzadko używały postinstall do exfiltracji; PhantomRaven dodaje „niewidzialne” zależności i slopsquatting, co utrudnia detekcję i zwiększa skuteczność dystrybucji.

Podsumowanie / kluczowe wnioski

PhantomRaven pokazuje, jak łatwo połączyć niszowe funkcje npm, automatyczne skrypty instalacyjne i błędy poznawcze (zaufanie do LLM) w skuteczny atak na łańcuch dostaw. Krytyczne są: blokada HTTP-owych zależności, wyłączenie skryptów lifecycle w CI, rotacja i krótkie TTL tokenów, monitoring ruchu podczas instalacji oraz dyscyplina weryfikacji paczek – szczególnie tych „poleconych” przez asystentów AI.

Źródła / bibliografia

  1. BleepingComputer — PhantomRaven attack floods npm with credential-stealing packages (29 paź 2025). (BleepingComputer)
  2. Koi Security — PhantomRaven: NPM Malware Hidden in Invisible Dependencies (paź 2025) — szczegóły RDD, IoC i lista paczek. (Koi)
  3. Dark Reading — Malicious NPM Packages Disguised With ‘Invisible’ Dependencies (29 paź 2025) — omówienie techniki i kontekstu. (SCM Demo)
  4. Phylum — Sensitive Data Exfiltration Campaign Targets npm and PyPI (26 wrz 2023) — wcześniejsze, pokrewne kampanie exfiltracyjne. (blog.phylum.io)

TEE.Fail: nowy atak, który podważa „confidential computing” na CPU Intela, AMD i w ekosystemie GPU NVIDIA

Wprowadzenie do problemu / definicja luki

Zespół badaczy z Georgia Tech i Purdue przedstawił technikę TEE.Fail, która z użyciem taniego (≈< 1000 USD) interposera magistrali DDR5 pozwala odczytywać tajemnice z TEE (Trusted Execution Environment) nowej generacji – m.in. Intel TDX/SGX oraz AMD SEV-SNP (nawet z włączonym Ciphertext Hiding). Co więcej, wykradzione klucze atestacyjne umożliwiają podszywanie się pod zaufane środowiska i podważają modele zaufania także w GPU Confidential Computing NVIDII (np. H100).

W skrócie

  • Vektor ataku: pasywny podsłuch ruchu pamięci DDR5 z interposerem; brak potrzeby modyfikacji danych w locie.
  • Słaby punkt: deterministyczne szyfrowanie pamięci TEE (ta sama dana → ten sam szyfrogram), co umożliwia korelację wzorców i ekstrakcję kluczy.
  • Skutki: kradzież kluczy ECDH i kluczy atestacyjnych TDX/SGX, fałszowanie atestacji (także dla GPU-CC NVIDII), uruchamianie zadań poza TEE przy „zielonej” atestacji.
  • Koszt/próg wejścia: komponenty „z półki”, całość < 1000 USD.
  • Status vendorów: Intel potwierdził badania i utrzymuje, że ataki fizyczne pozostają poza modelem zagrożeń dla SGX/TDX; publikacja ogłoszenia bezpieczeństwa 28 października 2025 r.

Kontekst / historia / powiązania

TEE.Fail to następca ataków WireTap i Battering RAM, które dotyczyły DDR4 oraz starszych platform (gł. SGX/SEV bez DDR5). Kluczowa różnica: pierwsza demonstracja praktycznej skuteczności na DDR5 oraz CVM (Confidential VMs) opartych o Intel TDX i AMD SEV-SNP – czyli rozwiązania stanowiące fundament współczesnych wdrożeń „confidential computing”.

Analiza techniczna / szczegóły luki

Interposer DDR5. Badacze zbudowali interposer podpinany do jednego kanału DDR5 DIMM (DDR5 ma dwa kanały na moduł, co upraszcza konstrukcję) i pasywnie przechwytywali cały ruch DRAM między CPU a pamięcią. Zapis/odczyt są widoczne nawet przy szyfrowaniu pamięci przez TEE.

Szyfrowanie deterministyczne. SGX/TDX oraz SEV-SNP używają trybów szyfrowania pamięci, które w praktyce są deterministyczne (identyczny plaintext → identyczny ciphertext w tej samej lokalizacji). To umożliwia budowę słowników i korelację wzorców; na ilustracjach badaczy różnica między prawidłowym szyfrowaniem a deterministycznym jest wyraźna.

Ekstrakcja i fałszowanie atestacji (Intel). Z przechwyconych śladów udało się pozyskać Provisioning Certification Key – per-CPU klucz z łańcucha zaufania SGX/TDX. Mając go, atakujący fałszuje raporty atestacyjne i może uruchamiać obciążenia poza TEE, a jednak przekonać systemy, że działają w zaufanym CVM (nawet na innej architekturze CPU). Intel potwierdza i podkreśla, że fizyczne interposery są out-of-scope dla modelu zagrożeń TDX/SGX.

AMD SEV-SNP z Ciphertext Hiding. Badacze pokazali, że ataki działają nawet przy aktywnym Ciphertext Hiding (Zen 5/EPYC 5. gen), a więc mimo ograniczania widoczności szyfrogramów przez hypervisor. Dodatkowo zademonstrowano ekstrakcję kluczy podpisu OpenSSL wewnątrz VM chronionej przez SEV-SNP.

GPU Confidential Computing (NVIDIA). Ponieważ GPU-CC NVIDII opiera się na atestacji CVM CPU (TDX/SEV-SNP), przejęcie/wyłudzenie kluczy atestacyjnych CPU pozwala „pożyczać” atestacje GPU i prezentować zadania AI jako uruchomione w zabezpieczonym środowisku, choć faktycznie tak nie jest. To łamie model zaufania dla zadań AI (np. chaty LLM, inferencja modeli) na H100.

Praktyczne konsekwencje / ryzyko

  • Chmura/CVM: dostawca z dostępem fizycznym do serwera może podsłuchiwać i fałszować atestacje, wynosząc dane/klucze bez wykrycia z poziomu software’u.
  • Blockchain/MEV: demonstracja fałszowania atestacji TDX w sieci BuilderNet (Ethereum block builders), otwierająca drogę do niejawnego frontrunningu i dostępu do poufnych transakcji.
  • AI/LLM-as-a-Service: możliwość „udowodnienia” GPU-CC przy realnym uruchomieniu poza TEE → ryzyko wycieku danych treningowych/kluczy API i manipulacji wynikiem.
  • Szeroki ekosystem TEE: Intel oficjalnie klasyfikuje interposery jako poza modelem zagrożeń, co oznacza, że brak łatwych łatek firmware’owych – konieczne będą zmiany w założeniach architektonicznych i procesach operacyjnych.

Rekomendacje operacyjne / co zrobić teraz

  1. Modeluj zagrożenia z fizycznym dostępem – jeśli Twoje ryzyko obejmuje atakującego z dostępem do szafy serwerowej, nie zakładaj, że TDX/SEV-SNP w DDR5 zapewnią pełną poufność. Zaktualizuj oceny ryzyka i umowy z operatorami DC/colocation.
  2. Zarządzaj zaufaniem do atestacjiwiąż atestacje z tożsamością sprzętu i lokalizacją (asset-binding), wdrażaj policyjne listy dozwolonych hostów, łącz atestację z kontrolą łańcucha dostaw/IMD i monitoringiem fizycznym.
  3. Segmentuj dane wrażliwe – minimalizuj ekspozycję tajemnic w TEE (krótkotrwałe klucze, HSM/KMS poza hostem, dzielone sekrety). Dla AI rozważ prywatność po stronie klienta/lokalne szyfrowanie przed wysłaniem do chmury. (Wnioski operacyjne na bazie skutków TEE.Fail).
  4. Twarde kontrole fizyczne – plombowanie, CCTV, ewidencja serwisantów, detection-by-presence (wykrywanie rozpięcia DIMM/risera). (Wnioski operacyjne wynikające z wektora ataku).
  5. Śledź komunikaty vendorów – Intel opublikował ogłoszenie bezpieczeństwa (28.10.2025). Monitoruj zapowiedziane stanowiska AMD i NVIDII dot. dostosowań modelu zagrożeń/mitigacji.
  6. Architektura „defense-in-depth” – TEE traktuj jako warstwę, nie jedyne zabezpieczenie. Odnów procedury DLP, EDR w hipervisorze, izolację sieciową CVM i kontrole dostępu do danych w spoczynku. (Dobre praktyki ogólne poparte kontekstem NCSC).

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

  • WireTap/Battering RAM (DDR4): atak na starszą generację pamięci/CPU; TEE.Fail eskaluje do DDR5 i CVM (TDX/SEV-SNP), co uderza w aktualne wdrożenia chmurowe.
  • RMPocalypse (CVE-2025-0033, AMD SEV-SNP): błąd inicjalizacji RMP łamie integralność VMs; TEE.Fail to atak fizyczny/side-channel na poufność + atestację. Razem pokazują, że zarówno błędy implementacji, jak i założenia modelu zagrożeń osłabiają dzisiejsze TEE.

Podsumowanie / kluczowe wnioski

TEE.Fail nie jest „kolejną” podatnością z CVE, lecz uderzeniem w fundamenty zaufania do confidential computing w epoce DDR5. Przy fizycznym dostępie do serwera i deterministycznym szyfrowaniu pamięci, granice TEE znikają: można wyciągnąć klucze, fałszować atestacje i obchodzić GPU-CC. Organizacje muszą przewartościować model zagrożeń, twardo kontrolować fizyczny dostęp oraz wiązać atestację ze sprzętem i lokalizacją. Krótkoterminowo – operacyjne obejścia i polityki; długoterminowo – zmiany w projektach szyfrowania pamięci i łańcuchach atestacji.

Źródła / bibliografia

  • Strona badaczy: TEE.fail – Breaking Trusted Execution Environments via DDR5 Memory Bus Interposition (FAQ, scenariusze ataku, skutki, mitgacje). (tee.fail)
  • Intel Security Announcement 2025-10-28-001 (TEE.fail) – stanowisko Intela i zakres modeli zagrożeń. (Intel)
  • BleepingComputer: „TEE.Fail attack breaks confidential computing on Intel, AMD, NVIDIA CPUs” – przegląd skutków i demonstracji (BuilderNet, fałszywe atestacje, wyciek ECDH). (BleepingComputer)
  • The Hacker News: „New TEE.Fail Side-Channel Attack Extracts Secrets from Intel and AMD DDR5 Secure Enclaves” – kontekst kosztu sprzętu i nowości względem DDR4. (The Hacker News)
  • NCSC (Szwajcaria): „Technology brief: Confidential Computing” – tło i modele TEE/CVM dla zrozumienia wpływu TEE.Fail. (ncsc.admin.ch)

ChatGPT Atlas: luka w „omniboxie” pozwala na jailbreaky i nadużycia agentów

Wprowadzenie do problemu / definicja luki

Badacze z NeuralTrust opisali nową technikę ataku na przeglądarkę ChatGPT Atlas, w której złośliwy ciąg wygląda jak adres URL, ale jest celowo sformatowany niepoprawnie. Atlas traktuje taki input w pasku adresu („omnibox”) najpierw jak URL, a gdy walidacja nawigacji zawodzi, degraduje go do polecenia tekstowego – jednak z wyższym zaufaniem i słabszymi kontrolami, co umożliwia cichy jailbreak i przejęcie zachowania agenta.

OpenAI w materiałach o Atlasie podkreśla, że bezpieczeństwo agentów było priorytetem – jednak opisana technika pokazuje, że granica między „zaufaną” intencją użytkownika a nieufnym inputem bywa w praktyce rozmyta.

W skrócie

  • Wejście przypominające URL wklejone do omniboxa może zostać potraktowane jako wysokozaufany prompt, jeśli nie przejdzie walidacji URL.
  • To pozwala omijać warstwy ochronne i wymuszać działania agenta (np. phishing, destrukcyjne operacje na kontach w chmurze).
  • Luka wpisuje się w szerszą klasę zagrożeń prompt injection dla „agenticznych” przeglądarek (Atlas, Comet, itp.).

Kontekst / historia / powiązania

Badania Brave pokazały systemowe problemy pośredniego prompt injection w przeglądarkach z agentami – złośliwe instrukcje mogą być ukryte nie tylko w tekście strony, lecz nawet w obrazach/screenshotach. Dyskusja ta rozgorzała w tym samym tygodniu, w którym zadebiutował Atlas.

Media branżowe i technologiczne zwracały uwagę na nowe wektory ryzyka wynikające z możliwości działania w imieniu użytkownika (dostępy do zalogowanych serwisów, historii, plików).

Analiza techniczna / szczegóły luki

NeuralTrust opisuje łańcuch zdarzeń:

  1. Przygotowanie ładunku – ciąg zaczyna się jak URL („https:” + domenopodobny fragment), ale zawiera język naturalny z imperatywami („follow these instructions…”) i celowe błędy (spacje, znaki, literówki).
  2. Wyzwolenie – użytkownik kopiuje/wkleja „link” do omniboxa (np. po kliknięciu „Copy link”).
  3. Iniekcja – walidacja URL nie przechodzi; Atlas traktuje treść jako prompt o pochodzeniu „od użytkownika”, z mniejszą liczbą kontroli.
  4. Eksploatacja – agent wykonuje instrukcje: od otwarcia fałszywego Google (phishing) po operacje na Google Drive (np. kasowanie plików) przy użyciu sesji uwierzytelnionej użytkownika.

SecurityWeek streszcza ten sam mechanizm i podaje przykładowy „URL-prompt”, ilustrując eskalację zaufania wynikającą z błędu parsowania pomiędzy trybem „Nawiguj” a „Zapytać/Wykonaj”.

Praktyczne konsekwencje / ryzyko

  • Phishing i kradzież sesji/poświadczeń poprzez otwieranie stron podszywających się pod zaufane serwisy.
  • Operacje krzyżodomenowe w kontekście zalogowanego użytkownika (np. Drive, poczta) – tradycyjne SOP/CSRF nie chronią przed intencją agenta.
  • Degradacja polityk bezpieczeństwa (RL, guardraily) – prompt traktowany jako „intencja” może ominąć filtry treści.

Szerszy ekosystem agentów przeglądarkowych już wcześniej wykazał podatność na injection (w tym z obrazów), co dowodzi, że to problem systemowy, a nie pojedynczy bug.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników końcowych (od razu):

  • Nie wklejaj do omniboxa „linków” z nieznanych źródeł; traktuj przycisk „Copy link” jak potencjalny wektor ataku.
  • Wyłącz/ogranicz automatyczne akcje agenta i wymagaj potwierdzenia przed dostępem do poczty, dysków, formularzy płatniczych.
  • Oddziel przeglądanie wrażliwe (bankowość, praca) od eksperymentów z agentem (np. osobny profil/konto).

Dla zespołów SecOps/AppSec (krótkoterminowo):

  • W politykach EDR/DLP i proxy oznaczaj ruch Atlas oraz monitoruj anomalie na kontach SaaS (Drive, O365).
  • Wprowadź kontrole kontekstowe (step-up MFA, reautoryzacja narzędzi) przy akcjach inicjowanych przez agentów.
  • Edukuj użytkowników: „URL ≠ URL” – pokaż przykłady obfuskacji i mechanizm degradacji do promptu. (na bazie case’u NeuralTrust).

Dla vendorów/pracujących nad agentami (średnioterminowo):

  • Twarde parsowanie i normalizacja URL; jeśli są niejednoznaczności – odrzuć, bez cichego fallbacku do trybu prompt.
  • Jawny wybór trybu (Navigate vs Ask/Act) i widoczny stan UI; brak automatycznych przełączeń.
  • Zasada najmniejszych uprawnień dla promptów z omniboxa; potwierdzenie użytkownika przy narzędziach/akcjach krzyżodomenowych.
  • Stripping instrukcji z inputów „URL-opodobnych” i tagowanie pochodzenia tokenów w rozmowie z LLM.

Różnice / porównania z innymi przypadkami

  • Comet / „niewidzialne” injekcje w obrazach: wektor to kontekst strony/screenshot, a nie omnibox; w Atlasie wektor siedzi w pasku adresu i podszywa się pod intencję użytkownika.
  • Klasyczne XSS/CSRF: atak nie łamie przeglądarkowego SOP – agent wykonuje akcje „w dobrej wierze”, co omija wiele klasycznych barier. (por. szersze omówienie w The Register i literaturze nt. agentów webowych).

Podsumowanie / kluczowe wnioski

  • Luka w omniboxie Atlasu to błąd granicy zaufania: URL-opodobny ciąg staje się wysokozaufanym promptem.
  • Efekt: jailbreaky i aktywne nadużycia w kontekście zalogowanego użytkownika.
  • Rozwiązania: twarde parsowanie, jawne tryby, potwierdzenia i proweniencja tokenów – do wdrożenia zarówno po stronie vendorów, jak i w politykach organizacji.

Źródła / bibliografia

  • NeuralTrust: „OpenAI Atlas Omnibox Prompt Injection: URLs That Become Jailbreaks” (24 paź 2025). (NeuralTrust)
  • SecurityWeek: „OpenAI Atlas Omnibox Is Vulnerable to Jailbreaks” (25 paź 2025). (SecurityWeek)
  • OpenAI: „Introducing ChatGPT Atlas” – sekcja o zabezpieczeniach agenta. (OpenAI)
  • Brave: „Unseeable prompt injections… more vulnerabilities in Comet and other AI browsers”. (Brave)
  • The Register: „OpenAI defends Atlas as prompt injection attacks surface”. (The Register)

AI Sidebar Spoofing: nowa technika podszywania się pod paski boczne w przeglądarkach AI (ChatGPT Atlas, Perplexity Comet, Edge/Brave/Firefox)

Wprowadzenie do problemu / definicja luki

Badacze SquareX opisali technikę AI Sidebar Spoofing – atak, w którym złośliwe rozszerzenie przeglądarki wstrzykuje w stronę fałszywy pasek boczny AI wyglądający identycznie jak oryginalny interfejs ChatGPT Atlas, Perplexity Comet czy wbudowane panele AI w Edge/Brave/Firefox. Użytkownik, przekonany że rozmawia z „prawdziwym” asystentem, otrzymuje zmanipulowane instrukcje prowadzące do phishingu, kradzieży danych lub wykonania złośliwych komend. Źródło: opis techniczny SquareX oraz omówienia prasowe z 23 października 2025 r.

W skrócie

  • Wektor: zainstalowane przez ofiarę rozszerzenie (malware, przejęte lub odkupione) z typowymi uprawnieniami host/storage.
  • Mechanika: w nowej karcie JS tworzy perfekcyjną kopię sidebaru AI i podstawia odpowiedzi z własnego LLM, wplatając fałszywe kroki (np. typosquatting, złośliwe komendy).
  • Zasięg: podatność systemowa dla „AI-browsers” (Comet, Atlas) i przeglądarek z panelami AI (Edge, Brave, Firefox).
  • Przykłady: phishing krypto (link do „binacee”), consent phishing/OAuth, reverse shell zamiast instalatora Homebrew.
  • Status: SquareX zgłosił temat do Perplexity; atak powtórzono także na ChatGPT Atlas (wydany kilka dni temu).

Kontekst / historia / powiązania

Przeglądarki z AI (Perplexity Comet, ChatGPT Atlas) stają się agentami wykonującymi działania w sieci. Wcześniejsze raporty (LayerX, Brave/Guardio) już pokazywały, że automatyzacja i brak „intuicji” modeli sprzyjają nadużyciom (np. prompt injection, transakcje na fałszywych sklepach). Sidebar spoofing wpisuje się w ten trend—tym razem celem jest zaufanie do interfejsu.

OpenAI w ogłoszeniu Atlasa podkreśla ograniczenia bezpieczeństwa agenta (m.in. nie uruchamia kodu w przeglądarce, nie instaluje rozszerzeń). Niestety, spoofing UI obchodzi te zabezpieczenia poprzez socjotechnikę i zewnętrzne rozszerzenie użytkownika.

Analiza techniczna / szczegóły luki

  1. Instalacja rozszerzenia
    • Atakujący dostarcza nowe/zainfekowane/odkupione rozszerzenie; ten wektor jest powszechny na rynku dodatków.
  2. Wstrzyknięcie UI
    • Po otwarciu nowej karty skrypt wstrzykuje HTML/CSS/JS i renderuje klon paska bocznego AI (layout, ikonografia, przepływ). Dla użytkownika brak różnic behawioralnych.
  3. Hook odpowiedzi LLM + modyfikacje
    • Rozszerzenie korzysta z własnego LLM (np. Gemini) i warunkowo modyfikuje odpowiedzi, gdy wykryje prośbę o instrukcje/komendy:
      • Phishing: typosquatted link zamiast oryginalnego (np. binacee zamiast Binance).
      • Consent phishing (OAuth): kierowanie do aplikacji żądającej szerokich uprawnień (np. pełny dostęp do Gmail/Drive).
      • RCE: podmiana komendy instalacyjnej na reverse shell (częściowo base64), uzyskanie zdalnej powłoki i trwałego dostępu.
  4. Wariant bez rozszerzenia
    • Możliwy również spoofing natywny w złośliwej witrynie (mniej elastyczny niż rozszerzenie, ale realny).
  5. Dlaczego to działa?
    • Heurystyka zaufania do UI: użytkownik ufa „znanemu” paskowi AI.
    • „Asystent” ≠ „przeglądarka”: zabezpieczenia agenta nie obejmują scenariusza, w którym UI agenta jest fałszywe.
    • Uprawnienia rozszerzeń: host/storage to popularne, „niewinne” uprawnienia.

Praktyczne konsekwencje / ryzyko

  • Kradzież tożsamości i środków: przekierowanie na phishingi (krypto, bankowość).
  • Przejęcie kont poprzez OAuth: aplikacje trzecie z nadmiernymi uprawnieniami.
  • Zdalne wykonanie kodu / Lateral movement: reverse shell, doinstalowanie RAT, ransomware.
  • Eskalacja w środowisku korporacyjnym: AI jako „opiekun procesu” normalizuje ryzykowne działania użytkownika; wcześniejsze incydenty z Comet pokazały, że AI potrafi wykonywać niebezpieczne akcje bez właściwej walidacji.

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów bezpieczeństwa (SecOps/IT):

  1. Twarda polityka rozszerzeń
    • Whitelisting, blokada instalacji poza sklepem, okresowe audytowanie zainstalowanych dodatków i ich uprawnień; SCA dla rozszerzeń (statyczna/dynamiczna analiza).
  2. EDR + reguły DLP pod AI
    • Detekcja wklejania komend o charakterze reverse shell, blokada podejrzanych łańcuchów base64, alerty na bash -i >& /dev/tcp/....
  3. Polityki przeglądarkowe
    • Wymuszanie trybów bezpiecznych, ostrzeganie przy OAuth z nadmiernymi uprawnieniami do niezatwierdzonych aplikacji; blokada znanych technik typosquattingu i stron ML-owo podejrzanych.
  4. Hardening agenta AI
    • W przeglądarkach z AI: widoczne wskaźniki autentyczności UI (origin/issuer), „secure attention sequence” przed wykonaniem instrukcji wysokiego ryzyka; włączanie restrykcji Atlasa to za mało—pamiętaj, że spoofing omija te warstwy.
  5. Szkolenia
    • „Zasada nieufności do UI AI”: jeśli pasek boczny instruuje do logowania, instalacji, poleceń systemowych — weryfikuj domenę i proś o wgląd w pełny URL; nigdy nie wykonuj bezpośrednio komend z UI. (Wskaż użytkownikom różnice między oficjalnym a „pływającym” panelem).

Dla użytkowników końcowych:

  • Instaluj rozszerzenia tylko z listy firmowej; sprawdzaj wydawcę i repozytorium.
  • Przed logowaniem/zakupem kliknij ikonę kłódki i porównaj pełny FQDN.
  • Kopiuj komendy do edytora i czytaj je, zanim trafią do terminala; zwróć uwagę na curl | sh, nc, bash -c, długie base64.
  • Gdy UI AI prosi o OAuth z szerokim dostępem (np. full access to Gmail/Drive) – przerwij i skonsultuj z IT.

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

  • Prompt/indirect injection vs UI spoofing: w pierwszym atakujesz model (logikę), w drugim percepcję użytkownika (interfejs) – co bywa skuteczniejsze, bo nie wymaga złamania sandboxu ani uprawnień agenta.
  • CometJacking/automatyzacja agentów (LayerX) wpływała na działania AI w ramach legalnego interfejsu; Sidebar Spoofing tworzy fałszywy interfejs, przez co ofiara nie zauważa, że nie rozmawia z prawdziwym agentem.

Podsumowanie / kluczowe wnioski

AI Sidebar Spoofing to atak na zaufanie do interfejsu AI. Nawet przy restrykcjach Atlasa, które ograniczają możliwości agenta, złośliwe rozszerzenie może całkowicie ominąć te bariery, podsuwając fałszywe instrukcje w „znanym” UI i prowadząc do poważnych incydentów (phishing, OAuth, RCE). Organizacje powinny traktować rozszerzenia jak kod o wysokim ryzyku, wdrożyć polityki przeglądarkowe i telemetrię specyficzną dla AI – oraz szkolić użytkowników, by nie ufać bezkrytycznie paskom bocznym AI.

Źródła / bibliografia

  • SecurityWeek: „AI Sidebar Spoofing Puts ChatGPT Atlas, Perplexity Comet and Other Browsers at Risk” (23 paź 2025). (SecurityWeek)
  • SquareX Labs: „AI Sidebar Spoofing: Malicious Extensions Impersonates AI Browser Interface” (16 paź 2025). (SquareX Labs)
  • BleepingComputer: „Spoofed AI sidebars can trick Atlas, Comet users into dangerous actions” (23 paź 2025). (BleepingComputer)
  • OpenAI: „Introducing ChatGPT Atlas” – sekcja o zabezpieczeniach agenta (ok. 21–22 paź 2025). (OpenAI)
  • LayerX Security: „CometJacking…” – szerszy kontekst ryzyk przeglądarek AI (4 paź 2025). (LayerX)