Tag: Malware

Wprowadzenie do problemu / definicja luki

Zespół Wiz Research ujawnił 15 października 2025 r. systemowy problem bezpieczeństwa w ekosystemie rozszerzeń VS Code: setki kluczy i tokenów dostępowych zostały nieumyślnie spakowane w paczki rozszerzeń i opublikowane w Visual Studio Code Marketplace oraz Open VSX. W ponad stu przypadkach były to tokeny umożliwiające… aktualizację samego rozszerzenia — a ponieważ VS Code domyślnie autoaktualizuje rozszerzenia, przejęcie takiego tokenu pozwalałoby rozesłać złośliwą aktualizację do całej bazy instalacji danego rozszerzenia.

W skrócie

• Wiz znalazł 550+ ważnych sekretów w 500+ rozszerzeniach od setek wydawców; w tym tokeny Azure DevOps (VS Marketplace) i Access Tokens Open VSX. Łącznie dotknięta baza instalacji to ponad 85 tys. (VS Marketplace) i 100 tys. (Open VSX).
• Po zgłoszeniu przez Wiz, Microsoft włączył skanowanie sekretów i blokowanie publikacji rozszerzeń zawierających wykryte klucze; skanowanie objęło też istniejące rozszerzenia.
• Open VSX wprowadził prefiks tokenu („ovsxp_”) ułatwiający wykrywanie wycieków przez narzędzia skanujące.

Kontekst / historia / powiązania

Ryzyko łańcucha dostaw w IDE narasta od lat: rozszerzenia mają dostęp do środowiska dewelopera i mogą wykonywać kod. Microsoft dokumentował mechanizmy kontroli i „trust” w runtime rozszerzeń, ale tajne klucze w paczkach to inny wektor — działa poza samym silnikiem uprawnień: atak następuje na etapie publikacji/aktualizacji. Dlatego Microsoft zapowiedział i wdrożył „Secret Detection for Extensions” w Marketplace, a dodatkowo opisał szerszy plan podniesienia zaufania do ekosystemu.

Analiza techniczna / szczegóły luki

Wiz rozpakowywał paczki .vsix (to zwykłe archiwa ZIP) i znajdował w nich m.in.:

• Dotfiles i pliki konfiguracyjne (np. .env, config.json, mcp.json, .cursorrules) zawierające klucze;
• Twardo zakodowane sekrety w kodzie/package.json/README;
• Tokeny wydawców:
  • Azure DevOps PAT (dla publikacji do VS Marketplace),
  • Open VSX Access Tokens (dla Open VSX).

Najgroźniejsze były tokeny publikacyjne — przejęcie ich pozwalałoby wypchnąć złośliwą wersję do całej bazy odbiorców danego rozszerzenia (przy włączonym auto-update). Wiz potwierdził 100+ ważnych PAT-ów VS Marketplace (ok. 85 tys. instalacji) oraz 30+ tokenów Open VSX (ok. 100 tys. instalacji).

Praktyczne konsekwencje / ryzyko

• Masowa dystrybucja malware przez zaufany kanał aktualizacji rozszerzeń.
• Ukierunkowane ataki na firmy korzystające z wewnętrznych/„vendor-specific” rozszerzeń opublikowanych publicznie „dla wygody”.
• „Fałszywe poczucie bezpieczeństwa” przy motywie/tematach (themes) — choć zwykle nie zawierają kodu, nic nie blokuje dołączenia złośliwych payloadów do takiej paczki.

Rekomendacje operacyjne / co zrobić teraz

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

1. Minimalizacja rozszerzeń – instaluj tylko niezbędne; oceń reputację wydawcy, historię wersji i liczbę instalacji.
2. Zarządzanie autoaktualizacją – rozważ kontrolowane okna aktualizacji i obserwację zmian uprawnień/rozmiaru paczki; w środowiskach korporacyjnych wdrażaj aktualizacje etapowo.
3. Inwentaryzacja i „allowlista” rozszerzeń (VS Code wspiera centralne polityki).

Dla wydawców rozszerzeń

1. CI gate na sekrety: uruchamiaj skanery sekretów (np. GitHub Advanced Secret Scanning/partner program) i blokuj build/publikację przy wykryciu.
2. Higiena repo/paczki: usuń .env i inne dotfiles z artefaktów (.vscodeignore / konfiguracja vsce), rotuj i skracaj TTL dla tokenów.
3. Migracja tokenów: używaj tokenów z identyfikowalną strukturą/prefiksem (np. ovsxp_ w Open VSX) – to zwiększa skuteczność ochrony.

Dla operatorów platform

1. Blokowanie publikacji z sekretami (pre-publish scanning) i skan „retro” istniejących rozszerzeń. Microsoft ogłosił i włączył tryb blocking w VS Marketplace.
2. Standardyzacja sekretów (prefiksy, checksumy, CASK) oraz krótkie TTL.
3. Transparentność i roadmapa bezpieczeństwa — publikowanie postępów i zasad (jak w aktualizacji Microsoft z czerwca 2025).

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

Ta kampania nie polegała głównie na publikacji ewidentnie złośliwych rozszerzeń, ale na wyciekach sekretów wydawców, co czyni wektor wyjątkowo niebezpiecznym: atakujący może podszyć się pod legalnego wydawcę i wykorzystać auto-update. To odróżnia sprawę od „klasycznych” kampanii złośliwych pluginów, a reakcje platform (blokowanie publikacji, skan istniejących paczek, prefiksy tokenów) są tu kluczowe.

Podsumowanie / kluczowe wnioski

• Łańcuch dostaw IDE to realny wektor ataku: sekret w paczce rozszerzenia = potencjał RCE przez zaufaną aktualizację.
• Reakcja platform (blokowanie publikacji, retro-skan, prefiksy tokenów) znacząco zmniejsza ryzyko, ale higiena po stronie wydawców i zespołów pozostaje niezbędna.
• Organizacje powinny wdrożyć allowlistę, inwentaryzację, kontrolowane aktualizacje oraz policyjne skanowanie sekretów w CI/CD.

Źródła / bibliografia

1. Wiz Research: “Dismantling a Critical Supply Chain Risk in VSCode Extension Marketplaces” (15 października 2025). (wiz.io)
2. GitHub (Microsoft VS Marketplace): „Upcoming Security Enhancement: Secret Detection for Extensions” + ogłoszenie trybu blocking. (GitHub)
3. Microsoft DevBlogs: „Security and Trust in Visual Studio Marketplace” (11 czerwca 2025). (Microsoft for Developers)
4. Open VSX (Eclipse): dokumentacja prefiksu tokenów ovsx.token-prefix. (GitHub)
5. VS Code Docs: „Extension runtime security” (sekcja o skanowaniu sekretów i blokowaniu publikacji). (Visual Studio Code)

Wprowadzenie do problemu / definicja luki

Pixnapping to nowa klasa ataków na Androida pozwalająca złośliwej aplikacji „podejrzeć” zawartość ekranu innej aplikacji lub witryny – jakby robiła jej zdalny zrzut, ale bez uprawnień i bez interakcji użytkownika. Badacze pokazali, że możliwe jest m.in. odczytanie kodów 2FA z Google Authenticator, fragmentów Gmaila czy treści z aplikacji Signal i Venmo. Google przypisało podatności identyfikator CVE-2025-48561. Częściowa łatka znalazła się w biuletynie zabezpieczeń z września 2025, a pełniejsze poprawki Google zapowiada na grudzień 2025. Nie ma śladów wykorzystania „in the wild”.

W skrócie

• Co to jest: Ramy ataku, które umożliwiają wyciek pikseli z ekranu innej aplikacji/strony poprzez zestaw legalnych API Androida i kanał boczny w GPU.
• Na co działa: Zademonstrowano na Pixel 6–9 i Samsung Galaxy S25 (Android 13–16, do buildu BP3A.250905.014). Inne urządzenia najpewniej też są podatne.
• Uprawnienia: Brak – złośliwa aplikacja nie potrzebuje żadnych zezwoleń w manifeście.
• Szybkość wycieku: ~0,6–2,1 piksela/s – wystarczająco do odzyskania 6-cyfrowych kodów TOTP.
• Status łatek: Wrzesień 2025 – częściowa, obejście istnieje; zapowiedziano kolejną w grudniu 2025.

Kontekst / historia / powiązania

Pixnapping łączy dwie linie badań:

1. GPU.zip – kanał boczny wynikający z zależnej od danych, transparentnej dla oprogramowania kompresji graficznej w nowoczesnych GPU. Pozwala wnioskować o kolorze pikseli na podstawie czasu renderowania/pasmo pamięci.
2. Android Custom Tabs / „Tabbed Out” – analiza modelu bezpieczeństwa komponentu Custom Tabs (IEEE S&P 2024), która zainspirowała część wektora inicjowania renderowania zawartości ofiary.

Artykuł The Register z 13 października 2025 opisuje Pixnapping i przytacza stanowisko Google o częściowej łatce (wrzesień) oraz planach na grudzień.

Analiza techniczna / szczegóły luki

Model zagrożenia. Zainstalowana aplikacja (bez specjalnych uprawnień) inicjuje sekwencję, w której:

1. Wypycha piksele ofiary do potoku renderowania – np. uruchamia Google Authenticator/Gmail poprzez Android Intents, aby ich UI został narysowany.
2. Nakłada półprzezroczyste „Activities” nad wybranym obszarem ekranu i indukuje operacje graficzne (użyto window blur API). Czas renderowania zależy od danych (koloru piksela).
3. Mierzy czas (VSync callbacks) i przez kanał boczny GPU.zip odtwarza wartości pikseli – następnie OCR składa znaki (np. cyfry TOTP).

Dlaczego to działa? W GPU (np. Mali w Pixelach) bezstratna kompresja graficzna ma współczynnik kompresji zależny od danych, co przekłada się na różnice w czasie renderowania/zużyciu przepustowości – możliwe do pomiaru z aplikacji użytkownika.

Identyfikator CVE i metryki. CVE-2025-48561 opisuje ujawnienie informacji przez kanał boczny w wielu miejscach kodu, bez wymaganych dodatkowych uprawnień i bez interakcji użytkownika. NVD klasyfikuje ją obecnie (CVSS 3.x) jako MEDIUM 5.5 (ocena może ulec zmianie wraz z uzupełnieniem metadanych).

Łatki Google. Pierwsza zmiana ogranicza liczbę wywołań rozmycia (blur) akceptowanych przez system kompozytujący SurfaceFlinger („Don’t blur too many layers”, limit 10 „front-most” blurów). Badacze wskazują jednak, że znaleźli obejście – szczegóły pod embargiem. Kolejne poprawki zapowiedziano na grudzień 2025.

Praktyczne konsekwencje / ryzyko

• Wykradanie kodów 2FA (TOTP) z aplikacji wyświetlających je wprost (np. Google Authenticator). To realnie obniża skuteczność MFA opartego wyłącznie na TOTP na podatnych urządzeniach.
• Podgląd treści komunikatorów i e-maili, jeśli ekran aplikacji jest renderowany w momencie ataku.
• Fingerprinting aplikacji zainstalowanych w systemie – badacze wskazują wektor ominięcia mechanizmów prywatności listy aplikacji (Google ocenił „won’t fix (infeasible)”).
• Brak uprawnień → potencjalnie większa skala dystrybucji w razie pojawienia się malware’u wykorzystującego exploit (choć Google deklaruje, że na Play nie wykryto takich aplikacji).

Rekomendacje operacyjne / co zrobić teraz

Dla zespołów SecOps / MDM (organizacje):

1. Wymuś aktualizacje systemu – natychmiast instaluj poprawki z września 2025 i egzekwuj instalację po grudniowym biuletynie. Ustal wskaźniki zgodności (compliance) na poziomie floty.
2. Tymczasowe zasady aplikacyjne:
   • Ogranicz użycie lokalnych aplikacji TOTP na urządzeniach o wysokim ryzyku; preferuj FIDO2/WebAuthn/klucze sprzętowe lub push-MFA z potwierdzeniem kontekstowym. (Wniosek na podstawie ryzyka opisanego przez badaczy).
   • W politykach EDR/MDM monitoruj nietypowe nakładanie Activities i intensywne wywołania blur (heurystyka na wzorzec PoC). (Wniosek na podstawie patcha i opisu ataku).
3. Hardening przeglądarki/aplikacji biznesowych: Włączaj tryby ograniczające osadzanie (X-Frame-Options/CSP frame-ancestors) oraz przegląd konfiguracji Custom Tabs (np. Ephemeral Tabs, jeśli dostępne). (Kontekst badań „Tabbed Out”).

Dla deweloperów Android:

• Minimalizuj ekspozycję wrażliwych danych na UI (maskowanie, ukrywanie kodów TOTP, skrócone okno wyświetlania). To nie eliminuje luki systemowej, ale zmniejsza powierzchnię ataku. (Wniosek na podstawie modelu wycieku pikseli).
• Wykrywaj nakładki/„draw over” i nietypowe przełączanie się Activities nad Twoją aplikacją; w razie detekcji ukrywaj wrażliwe elementy UI. (Heurystyka defensywna wynikająca z opisu PoC).
• Rozważ weryfikację kontekstu przed renderowaniem sekretów (np. wymuszenie interakcji, dodatkowy unlock, brak aktywnych nakładek). (Wniosek na podstawie wektora ataku).

Dla użytkowników:

• Aktualizuj Androida jak tylko pojawi się poprawka; ogranicz instalację aplikacji spoza Google Play. Google deklaruje, że nie wykryto aplikacji wykorzystujących CVE-2025-48561 w Play.
• Preferuj MFA odporne na podsłuch (klucze bezpieczeństwa/FIDO2) tam, gdzie to możliwe. (Rekomendacja wynikająca z natury ataku na TOTP).

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

• Klasyczne ataki iframe/timing (2013) zostały w dużej mierze zmitigowane w przeglądarkach. Pixnapping wskrzesza ideę „kradzieży pikseli”, ale poza przeglądarką – na poziomie stosów UI Androida + kanału GPU.
• GPU.zip (2023/2024) pokazał, że kompresja graficzna sama w sobie jest kanałem bocznym. Pixnapping wykorzystuje podobną obserwację, lecz łączy ją z nakładaniem Activities i blur API, co daje praktyczny wyciek z natywnych aplikacji mobilnych.

Podsumowanie / kluczowe wnioski

Pixnapping (CVE-2025-48561) to realny, choć niskoprzepustowy, wektor boczny na Androidzie, zdolny do kradzieży kodów 2FA i fragmentów danych aplikacji bez uprawnień. Częściowe łatanie po stronie Androida (limitowanie wywołań „blur”) nie zamyka jeszcze problemu – badacze wskazują obejście, a pełniejsze poprawki są w drodze. Organizacje powinny przyspieszyć patchowanie oraz ograniczyć zależność od TOTP na urządzeniach mobilnych wysokiego ryzyka, preferując FIDO2.

Źródła / bibliografia

1. Strona projektu Pixnapping (paper, Q&A, timeline). (pixnapping.com)
2. The Register: „Android ‘Pixnapping’ attack can capture app data like 2FA codes” (13.10.2025). (The Register)
3. NVD: wpis CVE-2025-48561 (opis, metryki). (NVD)
4. Android AOSP / googlesource: commit „Don’t blur too many layers” (ograniczenie wywołań blur). (Android Git Repositories)
5. GPU.zip – strona i preprint (kanał boczny kompresji graficznej). (hertzbleed.com)