Archiwa: AI - Strona 50 z 51 - Security Bez Tabu

Tag: AI

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)

Atak łańcuchowy na rozszerzenia VS Code z malware „GlassWorm”. Niewidzialny kod, C2 na blockchainie i samopropagacja

Wprowadzenie do problemu / definicja luki

W połowie października 2025 r. wykryto wysoce zaawansowany atak łańcuchowy na ekosystem rozszerzeń dla VS Code. Kampania, nazwana GlassWorm, infekuje rozszerzenia publikowane w OpenVSX (alternatywny, otwarty rejestr) i w pojedynczych przypadkach w Visual Studio Code Marketplace. Celem jest kradzież tokenów NPM/GitHub/Git (i innych), drenaż środków z 49 wtyczek kryptowalutowych, a także przejęcie stacji roboczych deweloperów jako węzłów infrastruktury przestępczej (SOCKS proxy, ukryty VNC). Atak rozpowszechnia się sam — używa przejętych poświadczeń do kompromitowania kolejnych rozszerzeń/pakietów. Pierwsze zainfekowane wydania w OpenVSX pojawiły się 17 października 2025 r.; do 20–21 października potwierdzono ok. 35,8 tys. instalacji złośliwych wersji.

W skrócie

  • Wejście: zainfekowane rozszerzenia VS Code w OpenVSX (i jeden przypadek w oficjalnym marketplace Microsoftu).
  • Technika ukrycia: „niewidzialny kod” oparty o Unicode variation selectors – złośliwy JS nie renderuje się w edytorze i znika w diffach.
  • C2: łańcuch Solana (memo w transakcjach zawiera wskaźnik do ładunku) + Google Calendar jako zapasowy kanał + bezpośrednie IP.
  • Zdolności: exfiltracja sekretów (NPM, GitHub, OpenVSX, Git), drenaż portfeli krypto (49 rozszerzeń), SOCKS proxy, HVNC, P2P (WebRTC), DHT, samopropagacja.
  • Skala: min. 35,8 tys. instalacji; co najmniej 7 rozszerzeń w OpenVSX na starcie, kolejne dołączane w toku.

Kontekst / historia / powiązania

GlassWorm pojawia się miesiąc po kampanii Shai Hulud (samopropagujący się robak w ekosystemie npm), również opisanej przez Koi Security. Wcześniej w 2025 r. społeczność zwracała uwagę na ryzyka marketplace’ów VS Code/OpenVSX (m.in. wycieki sekretów i słabe procesy publikacji). Choć podatność procesu publikacji w OpenVSX zgłoszona w maju i załatana w czerwcu nie miała potwierdzonego nadużycia, łańcuch dostaw rozszerzeń pozostaje atrakcyjny dla atakujących. GlassWorm pokazuje kolejny krok — połączenie samopropagacji z infrastrukturą C2 odporną na „takedown”.

Analiza techniczna / szczegóły luki

Niewidzialny kod (Unicode):
Złośliwe fragmenty są wstrzykiwane z użyciem Unicode variation selectors, które nie generują widocznego znaku. W efekcie w edytorze i w przeglądarce diffów widać „puste” linie; interpreter JS nadal wykonuje payload. To znacząco obniża skuteczność przeglądu kodu i części narzędzi SAST.

  1. Solana – malware wyszukuje transakcje z określonego portfela i odczytuje memo z zaszytym (base64) linkiem do kolejnego etapu; zmiana ładunku to publikacja nowej transakcji (tani, dynamiczny i odporny na usunięcie kanał).
  2. Google Calendar – tytuł wydarzenia zawiera kolejny wskaźnik URL (backup C2).
  3. Bezpośrednie IP – serwer serwujący zaszyfrowane ładunki, z kluczem AES przekazywanym w nagłówkach HTTP.

Łańcuch infekcji i moduły:

  • Etap kradzieży: pozyskanie tokenów NPM/GitHub/Git/OpenVSX + dane z 49 rozszerzeń portfeli kryptowalut.
  • Samopropagacja: użycie skradzionych poświadczeń do publikacji zainfekowanych wersji pakietów/rozszerzeń.
  • „ZOMBI”: aktywacja SOCKS proxy, WebRTC P2P, BitTorrent DHT do dystrybucji komend oraz HVNC (ukryty zdalny pulpit) — pełny, niewidoczny dostęp do stacji roboczej.

Skala i czas:

  • Start: 17 października 2025 – 7 rozszerzeń OpenVSX.
  • 18–21 października: ~35,8 tys. instalacji, kolejne rozszerzenia aktywnie serwowały malware; wykryto też pojedyncze zainfekowane rozszerzenie w Microsoft VS Code Marketplace (usunięte po zgłoszeniu).

Praktyczne konsekwencje / ryzyko

  • Kompromitacja łańcucha dostaw: każdy zainfekowany deweloper staje się wektorem do przejęcia następnych rozszerzeń i repozytoriów.
  • Utrata sekretów i eskalacja: wyciek tokenów repozytoryjnych i rejestrów pakietów = możliwość publikacji trojanizowanych wersji oprogramowania.
  • Pivot do sieci wewnętrznej: HVNC + SOCKS czynią z laptopów deweloperów ukryte backdoory i węzły pośredniczące.
  • Trwałość i odporność na wyłączenie: C2 oparte na blockchainie i usługach chmurowych utrudnia neutralizację i blokowanie.

Rekomendacje operacyjne / co zrobić teraz

Traktuj to jako aktywny incydent, nie tylko „podatność”. Poniżej lista działań priorytetowych:

  1. Natychmiastowa higiena i izolacja
  • Odłącz stacje deweloperskie od sieci firmowej; zablokuj wyjścia do: znanych IoC (np. 217.69.3.218, 140.82.52.31), RPC Solany i wskazanego wydarzenia Google Calendar (blok domenowy/aplikacyjny).
  • Tymczasowo wyłącz auto-aktualizacje rozszerzeń w IDE; wstrzymaj instalacje z OpenVSX i niezweryfikowanych marketplace’ów.
  1. Łańcuch tożsamości i sekretów
  • Rotacja wszystkich sekretów używanych na stacjach deweloperskich: tokeny NPM/GitHub/Git/OpenVSX/VS Code, hasła, klucze SSH; unieważnij sesje.
  • Wymuś re-login po rotacji, włącz obowiązkowo MFA i zasady urządzeń zaufanych.
  1. Triaga i detekcja
  • Przeskanuj hosty pod kątem: procesów HVNC, uruchomionych SOCKS proxy, komponentów WebRTC P2P, wpisów autostartu HKCU/HKLM...\Run, artefaktów z listy IoC Koi.
  • Monitoruj nietypowe połączenia wychodzące (Solana RPC, kalendarz Google, nietypowe IP HTTP z nagłówkami niestandardowymi).
  1. Remediacja hostów
  • Pełny reimage zaufanym obrazem → odtworzenie środowiska developerskiego → dopiero potem przywracanie dostępu do repozytoriów/registrów. (Rekomendowane przez badaczy w związku z HVNC i trwałością modułów).
  1. Zarządzanie ryzykiem marketplace’ów
  • Wprowadź allow-listę rozszerzeń (zarządzanie katalogiem dopuszczonych dodatków), SBOM dla pluginów oraz cykliczny przegląd autorów/łańcucha wydawniczego.
  • Rozważ blokadę OpenVSX w sieci korporacyjnej do czasu pełnego wyjaśnienia; zezwalaj wyłącznie na oficjalny marketplace i/lub wewnętrzne mirrory z walidacją.
  1. Długofalowo
  • Włącz skanery sekretów i SCA dla rozszerzeń i pakietów developerskich; egzekwuj zasady „no tokens in builds”.
  • Edukuj dev-teamy o wektorach „niewidzialnego kodu” (Unicode), kontroluj diffy w trybie view raw bytes lub z narzędziami wykrywającymi znaki kontrolne.

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

  • Shai Hulud (npm, IX 2025) – pierwszy robak samopropagujący w ekosystemie npm (kradł tokeny i publikował zainfekowane wersje). GlassWorm adaptuje ten model do OpenVSX/VS Code i dodaje niewidzialny kod + C2 na blockchainie + HVNC (większa odporność i wpływ na hosta).
  • WhiteCobra / fale złośliwych rozszerzeń – wcześniejsze kampanie (stealery) bazowały głównie na exfiltracji; GlassWorm tworzy żyjący ekosystem z P2P/DHT/HVNC i realnym „przejęciem” stacji. (Wskazuje to trend eskalacji w marketplace’ach IDE).

Podsumowanie / kluczowe wnioski

GlassWorm to punkt zwrotny dla bezpieczeństwa rozszerzeń IDE: łączy trik steganograficzny (Unicode), C2 odporny na likwidację (Solana/Google Calendar) i robakową samopropagację. Organizacje korzystające z VS Code i pochodnych narzędzi powinny potraktować sprawę jak incydent średnio-/wysokiego ryzyka, nie czekać na listy „złych rozszerzeń” i wdrożyć rotację sekretów + reimage najbardziej narażonych hostów developerskich.

Źródła / bibliografia

  • SecurityWeek: „Supply Chain Attack Targets VS Code Extensions With ‘GlassWorm’ Malware”, 21 października 2025. (SecurityWeek)
  • Koi Security (analiza techniczna), 18 października 2025. (koi.ai)
  • Koi Security (strona incydentu z IoC i aktualizacjami), 20 października 2025. (koi.ai)
  • Dark Reading: „Self-Propagating GlassWorm Attacks VS Code Supply Chain”, 20 października 2025. (Dark Reading)
  • CSO Online/InfoWorld: „Self-propagating worm found in marketplaces for VS Code extensions”, 21 października 2025. (CSO Online)

Gladinet łata aktywnie wykorzystywany zero-day w CentreStack (CVE-2025-11371)

Wprowadzenie do problemu / definicja luki

Gladinet wydał poprawkę dla biznesowego rozwiązania do udostępniania plików CentreStack, usuwając podatność CVE-2025-11371. To nieautoryzowana LFI (Local File Inclusion), która była aktywnie wykorzystywana od końca września. Patch jest dostępny w wersji 16.10.10408.56683 CentreStack. Triofox pozostaje powiązany funkcjonalnie, ale komunikaty o wydaniu łaty dotyczą wprost CentreStack.

W skrócie

  • Id: CVE-2025-11371 (LFI, ujawnienie plików systemowych bez uwierzytelnienia).
  • Status: ataki „in the wild” potwierdzone (co najmniej trzy ofiary); patch już dostępny (16.10.10408.56683).
  • Wektor nadużycia: odczyt Web.config → przejęcie machineKey → podpisanie danych i RCE przez deserializację ViewState.
  • Wersje podatne (wg NVD): wszystkie do i łącznie z 16.7.10368.56560.

Kontekst / historia / powiązania

W kwietniu 2025 ujawniono krytyczne CVE-2025-30406: twardo zakodowane klucze kryptograficzne (machineKey) umożliwiały RCE przez deserializację ViewState. Błąd załatano (min. CentreStack 16.4.10315.56368), ale nowy zero-day CVE-2025-11371 pozwalał napastnikom odzyskać klucz z dysku i ponownie osiągnąć RCE mimo kwietniowej łaty. Stąd fala ataków we wrześniu/październiku.

Analiza techniczna / szczegóły luki

Huntress opisał ścieżkę nadużycia: publiczny endpoint obsługiwany przez klasę GladinetStorage.TempDownload w komponencie GSUploadDownloadProxy akceptował ciągi z sekwencjami przejścia katalogu. To pozwalało na odczyt dowolnych plików względem katalogu tymczasowego – w praktyce również .../root/Web.config. Po pobraniu Web.config atakujący wyciągał machineKey i przechodził do RCE poprzez przygotowanie złośliwego ViewState (deserializacja po stronie serwera). Huntress udostępnił minimalistyczny 1-liner PowerShell do pobrania Web.config jako PoC po tym, jak Gladinet wypuścił patch.

NVD potwierdza klasyfikację błędu jako LFI umożliwiającą niezamierzone ujawnienie plików oraz wskazuje zakres wersji podatnych (≤16.7.10368.56560). Horizon3.ai dodatkowo podkreśla, że LFI → machineKey → RCE to łańcuch ataku możliwy w domyślnych instalacjach CentreStack/Triofox.

Praktyczne konsekwencje / ryzyko

  • Przełamanie uwierzytelniania logicznego: dowolny, nieautoryzowany klient może czytać pliki aplikacyjne/OS (LFI).
  • Eskalacja do pełnego kompromisu hosta Windows: po uzyskaniu machineKey możliwe jest zdalne wykonanie kodu z uprawnieniami procesu serwera WWW (w praktyce często SYSTEM).
  • Ryzyko wtórne: kradzież danych klientów, pivot do sieci wewnętrznej, wstrzyknięcie web-shella, trwałość poprzez zadania harmonogramu/usługi.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj CentreStack do 16.10.10408.56683 (panel aktualizacji/instalator). Zweryfikuj wersję po aktualizacji.
  2. Jeśli patch chwilowo niemożliwy – zastosuj mitigacje Huntress:
    • Wyłącz handler t.dn w UploadDownloadProxy\Web.config (usunięcie wpisu mapującego).
    • Ogranicz ekspozycję portali (geofencing/VPN/WAF), jeśli to możliwe.
  3. Natychmiastowa detekcja/IR:
    • Przejrzyj logi pod kątem żądań typu GET /storage/t.dn?s=..\..\..\Program+Files+(x86)\Gladinet+Cloud+Enterprise\root\Web.config&sid=1.
    • Szukaj nietypowych POST z zakodowanymi base64 payloadami oraz plików tymczasowych zawierających wyniki poleceń (np. CentreStac_log.txt).
    • Zresetuj/obróć wartości machineKey i inne sekrety, jeśli istnieje podejrzenie odczytu Web.config.
  4. Twarde utwardzenie konfiguracji ASP.NET:
    • Wymuś custom machineKey generowany per-instancję (nie domyślne).
    • Włącz ViewState MAC i rozważ ViewStateUserKey (zgodnie z best practices). (Wniosek wynikający z analizy mechanizmu ataku.)
  5. Atak łańcuchowy a stare CVE: upewnij się, że CVE-2025-30406 było wcześniej załatane (min. 16.4.10315.56368). Ten błąd historycznie umożliwiał RCE i pozostaje częścią łańcucha, jeśli machineKey jest znany.

Różnice / porównania z innymi przypadkami

  • CVE-2025-30406 (kwiecień 2025): problem z twardo zakodowanymi kluczami w Web.config → natychmiastowe RCE; naprawiony w 16.4.x.
  • CVE-2025-11371 (październik 2025): LFI pozwala wydobyć machineKey z Web.config, co odtwarza warunki do RCE znane z wcześniejszej luki. Ta podatność została teraz załatana w 16.10.x.

Podsumowanie / kluczowe wnioski

  • Patch jest już dostępny – zaktualizuj do 16.10.10408.56683 bez zwłoki.
  • LFI w CentreStack nie wymaga uwierzytelnienia i prowadzi do RCE przez kradzież machineKey.
  • Nawet organizacje załatane na kwietniowe CVE-2025-30406 były podatne, dopóki CVE-2025-11371 pozostawało niezałatane.
  • W logach szukaj śladów odczytu Web.config i nietypowych base64 payloadów. W razie podejrzeń rotuj klucze/sekrety i przeprowadź IR.

Źródła / bibliografia

  • BleepingComputer: „Gladinet fixes actively exploited zero-day in file-sharing software” (16 października 2025) – informacja o wydaniu łat 16.10.10408.56683. (BleepingComputer)
  • Huntress: „Active Exploitation of Gladinet CentreStack and Triofox Local File Inclusion Flaw (CVE-2025-11371)” – techniczne szczegóły LFI, ścieżka eksploatacji, IoC i mitigacje. Aktualizacja z 15 października. (Huntress)
  • NVD: CVE-2025-11371 – opis podatności i zakres wersji podatnych (≤16.7.10368.56560). (NVD)
  • NVD: CVE-2025-30406 – wcześniejsza luka RCE (hardcoded machineKey) oraz wersja naprawcza 16.4.10315.56368. (NVD)
  • Horizon3.ai: Analiza CVE-2025-11371 (LFI → RCE) – omówienie łańcucha ataku. (Horizon3.ai)