Archiwa: AI - Strona 93 z 94 - Security Bez Tabu

Tag: 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 atestacji – wiąż 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)

3 000 filmów na YouTube jako pułapki malware. „YouTube Ghost Network” rozbite — co to było i jak się bronić

Wprowadzenie do problemu / definicja luki

Check Point Research ujawnił skoordynowaną operację dystrybucji złośliwego oprogramowania na YouTube, nazwaną YouTube Ghost Network. Sieć wykorzystywała przejęte lub fałszywe konta, by publikować filmy-tutoriale (cracki, „haki” do gier), które prowadziły do pobrania stealerów informacji. Zidentyfikowano ponad 3 000 złośliwych filmów, z których wiele miało setki tysięcy wyświetleń. Po zgłoszeniach badaczy Google usunął większość treści. Źródło przypisuje aktywność co najmniej od 2021 r., a w 2025 r. liczba filmów potroiła się.

W skrócie

  • Skala: >3 000 filmów na przejętych kanałach; rekordowe pojedyncze wideo ~293 tys. wyświetleń (Photoshop), inne ~147 tys. (FL Studio).
  • Wektor socjotechniczny: „darmowe” cracki i cheaty (m.in. Roblox, Adobe, FL Studio), komentarze i lajki budujące fałszywą wiarygodność.
  • Rodziny malware: głównie infostealery – Lumma (przed jej wiosennym rozbiciem), później Rhadamanthys, a także RedLine, StealC, Phemedrone/0debug; bywał łańcuch z HijackLoaderem.
  • Łańcuch infekcji: linki w opisie, przypiętych komentarzach lub „instrukcji wideo” → skracacze URL → Google Sites/Blogger/Telegra.ph lub dyski Dropbox/Google Drive/MediaFire → archiwum z hasłem + prośba o wyłączenie Defendera → payload.
  • Reakcja branży: Check Point + Google usunęli większość treści; media branżowe potwierdziły skalę i modus operandi.

Kontekst / historia / powiązania

  • Lumma Stealer był „hitem” w sieci do czasu międzynarodowej akcji Microsoftu i Europolu (16 marca–16 maja 2025 r.), po której operatorzy kampanii częściej przechodzili na Rhadamanthys.
  • Zjawisko „Ghost Network” wcześniej opisywano na GitHubie (kampania Stargazers Ghost Network), gdzie masowo podszywano się pod wiarygodne repozytoria do dystrybucji złośliwych plików. YouTube to kolejna odsłona tej samej taktyki „platform-as-distribution”.

Analiza techniczna / szczegóły luki

Architektura ról (operacja na YouTube):

  1. Video-accounts – publikują filmy-wabiki i udostępniają linki (w opisie, przypiętym komentarzu lub jako „hasło+link” w samym wideo).
  2. Post-accounts – publikują posty społeczności z linkami i hasłami do archiwów; aktualizują wpisy, by omijać zgłoszenia; możliwe użycie AI do interakcji.
  3. Interact-accounts – dodają „lajki” i entuzjastyczne komentarze („works!”, „no virus”), podbijając sygnały zaufania.

Łańcuch dystrybucji i unikanie detekcji:

  • Skracacze URL maskujące destynację.
  • Hosty plików i usługi Google (Sites/Blogspot/Drive) – wysoka reputacja domen utrudnia filtrowanie reputacyjne.
  • Archiwa chronione hasłem (często „1337”) – brak możliwości skanowania zawartości bez hasła.
  • Instrukcje „wyłącz Defendera na chwilę” – celowe osłabienie ochrony podczas instalacji.
  • Pliki o dużych rozmiarach lub MSI instalujące HijackLoadera, który dociąga właściwy stealer (np. Rhadamanthys).

Cele i treści przynęt:

  • Cracki do Adobe Photoshop/Premiere/Lightroom, FL Studio, CorelDRAW, cheaty do gier (np. Roblox).
  • Kierowanie do grup docelowych (twórcy wideo/muzyki, gracze), gdzie popyt na „darmowe” narzędzia jest wysoki.

Praktyczne konsekwencje / ryzyko

  • Utrata danych uwierzytelniających (przeglądarki, menedżery haseł, cookie session tokens), portfele kryptowalut, poczta i konta społecznościowe — typowe dla stealerów.
  • Przejęcia kont korporacyjnych przez wykradzione sesje (SSO, M365, Slack, Git).
  • Wektory wtórne: zainfekowane endpointy stają się punktem wyjścia do BEC, ransomware lub dalszych kradzieży danych. (Wynika z typowych zdolności Lumma/Rhadamanthys i obserwacji Check Point dot. infostealerów w kampanii).

Rekomendacje operacyjne / co zrobić teraz

Dla SOC/IT (organizacje)

  1. Zablokuj ryzykowne kategorie transferów: egzekwuj polityki dla popularnych skracaczy URL i hostingów plików (Dropbox/Drive/MediaFire) w ruchu korporacyjnym — co najmniej kontrola i logowanie + izolacja przeglądarkowa dla niezweryfikowanych pobrań.
  2. Reguły detekcji:
    • Alerty na pobrania archiwów z hasłem z przeglądarki i nietypowe uruchomienia msiexec/exe po pobraniu.
    • Telemetria EDR dla wskaźników typowych dla Rhadamanthys/Lumma (procesy z nietypową komunikacją C2, kradzież danych z przeglądarek). (Uzasadnienie: kampania dostarczała właśnie te stealer-y).
  3. Zasady anty-tampering: wymuś niemożność wyłączenia Defendera/AV przez użytkownika bez uprawnień admina; monitoruj zdarzenia prób wyłączenia ochrony w czasie instalacji.
  4. Twarde uwierzytelnianie: MFA odporne na phishing (FIDO2/Passkeys), krótkie TTL sesji, automatyczne unieważnianie tokenów po incydencie ze stealerem. (Kontekst: masowe kradzieże cookies przez stealery).
  5. Kontrola aplikacji i uprawnień: blokada uruchamiania niepodpisanych MSI/EXE spoza zaufanych katalogów; WDAC/AppLocker; zasada least privilege na endpointach.
  6. DTR/IR playbook dla stealerów: natychmiastowa rotacja haseł/kluczy/API, reset sesji, przegląd logowania z nowych lokacji, przegląd skrzynek i reguł przekierowań.

Dla użytkowników (awareness)

  • Nie instaluj cracków i „hacków do gier” — to w 2025 r. najczęstsza przynęta w tej kampanii.
  • Weryfikuj kanały i linki: jeśli link prowadzi przez skracacz lub na Google Sites/Telegra.ph i wymaga hasła do archiwum – traktuj to jako czerwone flagi.
  • Nie wyłączaj antywirusa „na chwilę” z powodu filmu w sieci.
  • Używaj menedżera haseł + MFA i aktualizuj system.

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

  • GitHub „Stargazers Ghost Network” (2024–2025) i YouTube Ghost Network (2025) to ta sama logika „Ghost accounts as a service” na różnych platformach: manipulacja sygnałami zaufania (gwiazdki/forciowanie repo vs. wyświetlenia/komentarze), treści przynęt (narzędzia/dev-tool vs. cracki/cheaty), lecz cel identyczny — masowa dystrybucja infostealerów przy użyciu „dobrych” domen i funkcji społecznościowych.

Podsumowanie / kluczowe wnioski

  • Kampania YouTube Ghost Network pokazała, jak łatwo zbrodnicze grupy weaponizują platformy społecznościowe — od SEO i komentarzy po posty społeczności — by sprzedawać wiarygodność i dostarczać malware na masową skalę.
  • Cracki i cheaty pozostają najbardziej ryzykownym typem treści dla użytkowników; to na nich żerują operatorzy stealerów.
  • Higiena tożsamości, polityki pobrań i kontrola aplikacji są dziś równie ważne, co sygnaturowe AV.
  • Po rozbiciu Lumma napastnicy przechodzą na alternatywy (Rhadamanthys), co wymaga ciągłej adaptacji detekcji.

Źródła / bibliografia

  • Check Point Research: Dissecting YouTube’s Malware Distribution Network (23 października 2025). (Check Point Research)
  • The Hacker News: 3,000 YouTube Videos Exposed as Malware Traps… (24 października 2025). (The Hacker News)
  • The Register: Google and Check Point nuke massive YouTube malware… (23 października 2025). (The Register)
  • Help Net Security: Researchers expose large-scale YouTube malware distribution network (23 października 2025). (Help Net Security)
  • Europol: Europol and Microsoft disrupt world’s largest infostealer Lumma (21 maja 2025). (Europol)

Hakerzy polują na użytkowników przeglądarki Perplexity Comet: fałszywe domeny, aplikacje i reklamy

Wprowadzenie do problemu / definicja luki

Krótko po premierze przeglądarki Perplexity Comet cyberprzestępcy uruchomili skoordynowaną kampanię podszywania się pod markę: rejestrowali domeny podobne do oficjalnych adresów, publikowali fałszywe aplikacje mobilne i promowali fikcyjne instalatory poprzez reklamy w wyszukiwarkach i mediach społecznościowych. Celem jest skłonienie użytkowników do pobrania nieautoryzowanego oprogramowania lub przeklikania się do stron phishingowych podszywających się pod „pobieranie Comet”. Takie wnioski opublikował zespół BforeAI, a temat opisał SecurityWeek.

W skrócie

  • Czas: Comet wystartował 9 lipca 2025 r.; 2 października 2025 r. został udostępniony bezpłatnie dla wszystkich. Kampania fałszywych domen i aplikacji nasiliła się między sierpniem a październikiem 2025 r.
  • Skala: BforeAI przeanalizowało >40 podejrzanych domen; część z nich to bezpośrednie imitacje marki (np. perplexitycomet-ai.com, cometaibrowser.com).
  • Aplikacje mobilne: wykryto krytyczne fałszywe pozycje w Google Play oraz nieautoryzowaną aplikację w App Store, przed którą publicznie ostrzegł CEO Perplexity.
  • Powiązane ryzyka: wcześniejsze badania wykazały, że AI-przeglądarki (w tym Comet) są podatne na prompt-injection, phishing i scenariusze „agentic”.

Kontekst / historia / powiązania

Perplexity uruchomiło Comet jako AI-native przeglądarkę z asystentem zintegrowanym w przepływ pracy (poczta, kalendarz, research). Początkowo dostęp był ograniczony, później – od 2 października – produkt stał się darmowy dla wszystkich użytkowników, co znacząco zwiększyło rozpoznawalność marki i… atrakcyjność dla oszustów.

Równolegle pojawiły się niezależne badania bezpieczeństwa: Guardio Labs pokazało scenariusz „Scamlexity”, w którym AI-przeglądarka potrafi zautomatyzować błędne działania (np. pomagać dokonać zakupu na fałszywym sklepie), a LayerX opisał technikę CometJacking, gdzie pojedynczy złośliwy URL „przejmuje” agenta i wykrada dane (e-maile, kalendarz, „pamięć” użytkownika).

Analiza techniczna / szczegóły kampanii podszywania się

Wektory ataku zidentyfikowane przez BforeAI:

  1. Typosquatting i brand impersonation — rejestracje po starcie Comet, z użyciem słów kluczowych „comet”, „ai”, „browser”, „perplexity”, „download”. Przykłady: cometai.site, cometaibrowser.com, perplexitycomet-ai.com, cometbrowser.net, aicometbrowser.com. Część domen parkowana (np. cometai.net oferowana za 9 999 $).
  2. SEO-poisoning / malvertising — reklamy w wyszukiwarkach i social media kierujące do „pobierania Comet” z nieoficjalnych stron trzecich; serwowane pseudo-instalatory EXE.
  3. Fałszywe aplikacje mobilne — m.in. „Comet AI Atlas App Info” w Google Play; dodatkowo nieautoryzowana pozycja w iOS App Store, przed którą ostrzegł publicznie CEO Perplexity 14 października 2025 r.

Cechy operacyjne kampanii: wykorzystanie prywatności WHOIS, rejestratorów w różnych jurysdykcjach (w tym REG.RU, Name SRS AB, NameCheap) i szybkich, niedrogich rejestracji TLD (.com, .net, .ai, .site, .app), co utrudnia egzekwowanie i sprzyja rotacji infrastruktur.

Praktyczne konsekwencje / ryzyko

  • Zainfekowanie endpointu przez pobranie nieoficjalnego instalatora (infostealery, adware, RAT) podszywającego się pod „Comet Setup”. (Wniosek na podstawie znanych TTP kampanii malvertising / fake installers).
  • Kradzież danych i sesji: w scenariuszu CometJacking samo odwiedzenie spreparowanego linku może wywołać działania agenta i eksfiltrację treści (e-maile, kalendarz, „memory”).
  • Utrata środków / phishing transakcyjny: „Scamlexity” pokazuje, że agent może „pomóc” dokończyć oszustwo, jeśli UX atakującego zostanie zaprojektowany pod AI.
  • Ryzyko reputacyjne i zgodności dla organizacji dopuszczających niezweryfikowane pobrania i korzystanie z nieoficjalnych aplikacji.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników i zespołów IT

  1. Pobieraj Comet wyłącznie z oficjalnych kanałów Perplexity (witryna i wpisy na blogu produktu). Zweryfikuj domenę perplexity.ai i podpisy binariów.
  2. Ignoruj reklamy „Download Comet” w Google/Bing oraz „skróty” w social media — zamiast tego wpisz adres ręcznie. (Wniosek na podstawie analizy malvertisingu BforeAI).
  3. Na mobile: do czasu oficjalnej premiery iOS nie instaluj żadnej „Comet” z App Store; zgłaszaj podejrzane pozycje.
  4. Przeglądarka/agent – higiena bezpieczeństwa: wyłącz autowykonywanie wtyczek/akcji, ogranicz uprawnienia do skrzynek pocztowych i kalendarzy, używaj profili tymczasowych do zadań „agentic”. (Wniosek na podstawie CometJacking/Scamlexity).

Dla SOC/Blue Team

  1. Blokady DNS/URL: dodaj wykazane przez BforeAI wskaźniki (domeny typosquatting) do list blokad i monitoringu; śledź rejestracje z ciągami comet|perplexity|browser|ai.
  2. Polityka instalacji: wymuś allow-listę źródeł oprogramowania; blokuj instalatory z unknown publisher.
  3. Detekcje: reguły na ruch do nowych, świeżo zarejestrowanych domen + detekcja nietypowych zapytań HTTP/JS wskazujących na exfiltrację przez agenta (np. base64 w parametrach URL opisana przez LayerX).
  4. Awareness: przeszkol użytkowników nt. prompt-injection i ryzyk „agentic browsing”; pokaż realne dema (Scamlexity).

Różnice / porównania z innymi przypadkami

  • AI-native vs. klasyczne przeglądarki: kluczowa różnica to agent wykonujący akcje. W tradycyjnej przeglądarce ofiara musi kliknąć/ulegać socjotechnice; w AI-przeglądarce agent może zautomatyzować niepożądane decyzje. (Wniosek na podstawie Guardio/LayerX).
  • Powierzchnia ataku: poza phishingiem dochodzi manipulacja kontekstem (prompt-injection, data exfiltration z „pamięci” agenta), co zwiększa skutki błędu użytkownika.

Podsumowanie / kluczowe wnioski

  • Popularność Comet po udostępnieniu „dla wszystkich” zbiegła się z falą nadużyć marki (domeny, reklamy, aplikacje).
  • Zagrożenia „agentic” sprawiają, że koszt błędu użytkownika jest wyższy niż w klasycznych przeglądarkach. Zasada 0-zaufania do reklam i nieoficjalnych źródeł jest tu krytyczna.
  • Organizacje powinny wyprzedzić atakujących: blokady DNS, polityki instalacji, profile ograniczone dla AI-agentów, oraz bieżące śledzenie wskaźników BforeAI.

Źródła / bibliografia

  • SecurityWeek: Hackers Target Perplexity Comet Browser Users (24 paź 2025). (SecurityWeek)
  • BforeAI: Threat Research Report: Malicious Activity Surrounding Perplexity’s Comet Browser Launch (paź 2025). (BforeAI)
  • Perplexity Blog: Introducing Comet (9 lip 2025) i Comet is now available to everyone worldwide (2 paź 2025). (Perplexity AI)
  • Guardio Labs: “Scamlexity”: We Put Agentic AI Browsers to the Test (20 sie 2025). (Guard.io)
  • LayerX: CometJacking: How One Click Can Turn Perplexity’s Comet AI Browser Against You (paź 2025). (LayerX)

GlassWorm: samorozprzestrzeniający się robak infekuje rozszerzenia VS Code i uderza w łańcuch dostaw

Wprowadzenie do problemu / definicja luki

Badacze bezpieczeństwa opisali nową kampanię malware nazwaną GlassWorm, która samodzielnie rozprzestrzenia się poprzez zainfekowane rozszerzenia Visual Studio Code publikowane w rejestrach Open VSX i Microsoft VS Code Marketplace. Atak celuje w łańcuch dostaw oprogramowania – wprost w narzędzia deweloperskie – kradnie poświadczenia (npm, GitHub), przejmuje środowiska i wykorzystuje maszyny programistów jako infrastrukturę przestępczą.

W skrócie

  • Skala: ok. 35,8 tys. instalacji złośliwych rozszerzeń; co najmniej kilka–kilkanaście paczek w obiegu w OpenVSX i na rynku Microsoftu.
  • Techniki ukrywania: „niewidzialny kod” z użyciem niewidocznych znaków Unicode w źródłach rozszerzeń, utrudniający przegląd i detekcję.
  • Zdolności: kradzież tokenów npm/GitHub, celowanie w 49 wtyczek portfeli krypto, uruchamianie SOCKS proxy i ukrytego VNC/RAT dla pełnego zdalnego dostępu.
  • Propagacja: użycie wykradzionych poświadczeń do publikowania zainfekowanych aktualizacji i przejmowania kolejnych kont/paczek.

Kontekst / historia / powiązania

Pierwsze publiczne raporty pojawiły się 20–24 października 2025 r.. Media branżowe i dostawcy bezpieczeństwa (m.in. BleepingComputer, Dark Reading) potwierdzają, że to jedna z najpoważniejszych jak dotąd kampanii wymierzonych w ekosystem VS Code. Część źródeł wiąże odkrycie z pracą badaczy Koi Security, a rozszerzenia w OpenVSX miały zostać podmienione 17 października; 2 dni później część z nich nadal rozprowadzała malware.

Analiza techniczna / szczegóły luki

Vektor wejścia. GlassWorm trafia do środowisk poprzez instalację (lub aktualizację) zainfekowanych rozszerzeń VS Code z OpenVSX oraz Microsoft Marketplace. Atakujący przejmują konta wydawców lub łańcuch CI/CD i publikują skażone wersje.

„Niewidzialny” kod. Krytycznym elementem jest ukrywanie złośliwej logiki z użyciem znaków sterujących Unicode (np. kierunków zapisu/bidirectional control), które sprawiają, że fragmenty kodu nie są widoczne przy zwykłym przeglądzie i mogą mylić zarówno recenzentów, jak i niektóre narzędzia SAST. Efekt: czysty diff, pozornie prawidłowa składnia, złośliwe ścieżki wykonania zaszyte między literami.

Zdolności po infekcji. Po zainstalowaniu, GlassWorm:

  • eksfiltruje poświadczenia npm i GitHub oraz inne sekrety deweloperskie,
  • skanuje przeglądarkę/środowisko pod kątem 49 rozszerzeń portfeli krypto i próbuje drenować środki,
  • wdraża SOCKS proxy, aby wykorzystywać hosta jako przekaźnik,
  • instaluje ukryte VNC/RAT dla pełnego zdalnego dostępu, utrzymując się w systemie,
  • używa skradzionych tokenów do przejęcia kolejnych pakietów/rozszerzeń i samoreplikacji.

Skala i telemetry. Według niezależnych relacji prasowych i firm badawczych mówimy o ~35,8 tys. instalacji/udanych pobrań skażonych rozszerzeń; atak dotknął co najmniej kilka–kilkanaście pakietów w popularnych rejestrach rozszerzeń.

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: przejęte tokeny npm/GitHub = ryzyko publikacji trojanów w repozytoriach firmy/OSS.
  • Ryzyko finansowe: celowanie w portfele krypto i możliwa utrata środków.
  • Infrastruktura przestępcza: hosty dev stają się proxy i zdalnymi stacjami sterowanymi przez atakujących (VNC/RAT) – ekspozycja sieci wewnętrznej.
  • „Blind spot” w code review: użycie niewidzialnych znaków obchodzi kontrolę peer review i statyczną analizę, co utrudnia tradycyjne procesy SDLC.

Rekomendacje operacyjne / co zrobić teraz

Natychmiast (IR – Incident Response):

  1. Inwentaryzacja rozszerzeń VS Code w organizacji (OpenVSX/Microsoft Marketplace). Wytypować i odinstalować podejrzane/ostatnio aktualizowane.
  2. Rotacja i unieważnienie wszystkich tokenów npm/GitHub/PAT, kluczy CI/CD, cookies sesyjnych przeglądarki; włączyć 2FA i ograniczyć zakres uprawnień (fine-grained PAT).
  3. Izolacja stacji roboczych dev: odłączenie od sieci, skan EDR/AV, detekcja SOCKS proxy i ukrytych usług VNC/RAT; przegląd autostartów i harmonogramów zadań.
  4. Przegląd repozytoriów i rejestrów: niezwłoczne sprawdzenie ostatnich publikacji/commitów/wersji paczek pod kątem nietypowych zmian i „niewidzialnego” Unicode.

W kolejnych dniach (hardening):

  • Wymuś weryfikację wydawcy i pinning zaufanych rozszerzeń; ogranicz instalację do listy dozwolonych (allow-list). (Praktyka zalecana przez branżę w kontekście tego incydentu).
  • W pipeline’ach dodaj kontrole Unicode (detekcja znaków sterujących Bidi, zero-width, itd.) i policy skanów dla rozszerzeń/artefaktów przed dopuszczeniem do stacji dev.
  • Egzekwuj zasadę najmniejszych uprawnień dla tokenów (scopes, TTL, rotacja), ochronę sekretów i monitoring publikacji (alerty przy zmianie maintainerów lub kluczy publikacyjnych).
  • Użyj EDR z regułami na nietypowe połączenia proxy/VNC i anomalie narzędzi deweloperskich; przegląd ruchu wychodzącego pod kątem tuneli SOCKS.

Artefakty/detekcja (przykłady do playbooka IR):

  • Skan plików źródłowych pod kątem znaków: \u202E, \u2066–\u2069, \u200B itd. (Bidi/zero-width).
  • Audyt folderów rozszerzeń ~/.vscode/extensions / %USERPROFILE%\.vscode\extensions pod kątem niepodpisanych/nieznanych vendorów i recent-modified. (Dobre praktyki zgodne z doniesieniami o wektorze).

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

W porównaniu z wcześniejszymi incydentami „tylko” trojanizującymi pojedyncze rozszerzenie, GlassWorm łączy samopropagację (wykorzystanie świeżo wykradzionych tokenów do publikacji kolejnych zainfekowanych aktualizacji) z niewidzialnym kodem Unicode, co utrudnia review i automatyczną analizę. To jakościowy skok względem znanych kampanii typosquattingu i przejęć paczek NPM/VS Code.

Podsumowanie / kluczowe wnioski

  • GlassWorm uderza w samo serce SDLC – narzędzia deweloperskie – i omija klasyczne bramki kontrolne dzięki „niewidzialnym” trikom Unicode.
  • Organizacje powinny traktować sprawę jak incydent bezpieczeństwa łańcucha dostaw: natychmiastowa rotacja sekretów, czyszczenie stacji dev, whitelisting rozszerzeń i kontrole Unicode w pipeline’ach.
  • Nawet po usunięciu skażonych wtyczek, skradzione tokeny mogą umożliwiać dalsze nadużycia – higiena kluczy i monitoring publikacji są krytyczne.

Źródła / bibliografia

  • The Hacker News – „Self-Spreading ‘GlassWorm’ Infects VS Code Extensions…” (24 października 2025). (The Hacker News)
  • BleepingComputer – „Self-spreading GlassWorm malware hits OpenVSX, VS Code registries” (20 października 2025). (BleepingComputer)
  • Dark Reading – „Self-Propagating GlassWorm Attacks VS Code Supply Chain” (20 października 2025). (Dark Reading)
  • Truesec – „GlassWorm – Self-Propagating VSCode Extension Worm” (analiza techniczna, październik 2025). (Truesec)
  • Koi Security (blog) – przegląd zdolności GlassWorm i TTP (październik 2025). (koi.ai)

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)