Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.
Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.
Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.
Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.
Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.
Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.
Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.
Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.
Ten artykuł jest częścią serii „Bezpłatny Kurs LPI Security Essentials”, w ramach której znajdziesz wszystko, co potrzeba, aby zdać egzamin LPI Security Essentials 020-100 już za pierwszym razem.
Każdy moduł zawiera praktyczne przykłady, wyjaśnienia i materiały pomocnicze – wszystko po polsku, zrozumiale i konkretnie.
Microsoft opisał nowy atak boczny na zdalne modele językowe (LLM), nazwany Whisper Leak. Pozwala on pasywnemu podsłuchującemu — np. operatorowi sieci, atakującemu w tej samej sieci Wi-Fi lub obserwatorowi na łączu — wnioskować o temacie rozmowy z chatbotem, mimo że ruch jest szyfrowany (HTTPS/TLS). Skuteczność ataku wynika z analizy metadanych ruchu: rozmiarów i czasów nadejścia pakietów podczas strumieniowania odpowiedzi modelu. To nie jest błąd kryptograficzny TLS, tylko nadużycie informacji ujawnianej przez samą naturę strumieniowania tokenów.
W skrócie
Co wycieka? Nie treść wiadomości, lecz klasa/temat rozmowy (np. pytania o pranie pieniędzy, zdrowie, politykę).
Jak? Klasyfikator uczy się wzorców z sekwencji rozmiarów pakietów i odstępów czasowych przy strumieniowaniu odpowiedzi.
Skuteczność: Microsoft raportuje dla wielu popularnych modeli wyniki >98% AUPRC; w scenariuszu 1 rozmowa na 10 000 „szumu” możliwa jest 100% precyzja przy 5–50% pokrycia przypadków docelowych.
Kto załatał? Po jawnej koordynacji dostawcy tacy jak OpenAI, Mistral, Microsoft, xAI wdrożyli pierwsze obfuscatory strumienia (dodawanie losowego tekstu / parametry API) i inne utrudnienia.
Ryzyko: Realne dla użytkowników w środowiskach podwyższonego nadzoru (ISP, sieci publiczne), organizacji korzystających z LLM w wrażliwych domenach (prawo, zdrowie, compliance).
Kontekst / historia / powiązania
Whisper Leak wpisuje się w rosnące portfolio ataków kanałami pobocznymi na LLM:
Token-length side-channel (USENIX ‘24) — na podstawie długości tokenów (wnioskowanej z rozmiarów pakietów) rekonstruowano częściowo odpowiedzi oraz temat rozmowy.
Remote timing attacks (2024) — wykorzystują zależności czasowe w efektywnym wnioskowaniu (np. speculative decoding) do rozpoznawania właściwości promptu/odpowiedzi.
Microsoft buduje na tych pracach, łącząc rozmiary i timingi pakietów w jeden wektor cech i pokazując, że to wystarcza do trafnego klasyfikowania tematów w ruchu szyfrowanym.
Analiza techniczna / szczegóły luki
Założenie ataku: napastnik passive network observer ma podgląd do ruchu TLS między klientem a usługą LLM, ale go nie deszyfruje.
Powierzchnia ataku: większość klientów LLM strumieniuje odpowiedź — tokeny (lub małe grupy tokenów) są wysyłane na bieżąco. Dla TLS oznacza to ciąg pakietów o pewnych rozmiarach i przerwach. Ponieważ rozmiar szyfrogramu ~ rozmiarowi plaintextu + stałe narzuty, wzorce długości i czasu stają się „odciskiem palca” danego tematu i sposobu generacji.
Pipeline Whisper Leak (upraszczając):
Zbieranie próbek: generowanie zestawu wariantów pytań z wrażliwego tematu (POC: „legalność prania pieniędzy”) oraz dużego zbioru losowych pytań-szumu; rejestrowanie ruchu (np. tcpdump) dla różnych dostawców/modeli.
Ekstrakcja cech: sekwencje (size_i, Δt_i) z ruchu TLS podczas strumieniowania.
Uczenie: klasyfikatory sekwencji (LightGBM, Bi-LSTM, DistilBERT z bucketami rozmiaru/czasu).
Ewaluacja: metryka AUPRC na zbiorze ekstremalnie niezrównoważonym (np. 1:10 000 target:noise). Wynik: >98% dla wielu usług; w praktycznym modelu nadzoru wysoka precyzja przy istotnym recall.
Dlaczego to działa?
Autoregresja i (niekiedy) optymalizacje efektywności wprowadzają zależne od danych różnice czasowe.
TLS nie ukrywa rozmiarów i timingów rekordów/aplikacyjnych ramek; to metadane.
Minimalny PoC zbierania cech (edukacyjnie):
# przechwyć sesję HTTPS do dostawcy LLM (np. domena api.*)
sudo tcpdump -i eth0 -w llm.pcap 'tcp port 443 and host api.example-llm.com'
# wyodrębnij rozmiary i interwały z PCAP (pyshark)
import pyshark, numpy as np
cap = pyshark.FileCapture('llm.pcap', display_filter='tcp && tls')
sessions = {}
for p in cap:
key = (p.ip.src, p.tcp.stream) if 'TLS' in p else None
if not key: continue
ts = float(p.sniff_timestamp)
size = int(p.length) # długość ramki
sessions.setdefault(key, []).append((ts, size))
features = []
for k, seq in sessions.items():
seq.sort()
dts = np.diff([t for t,_ in seq], prepend=seq[0][0])
feats = list(zip([s for _,s in seq], dts))
features.append(feats)
print("sesji:", len(features))
(Powyższe służy naukowym ćwiczeniom nad detekcją wewnętrzną — nie do nadużycia).
Praktyczne konsekwencje / ryzyko
Model zagrożeń: ISP, operator chmury pośredniczącej, współużytkownicy Wi-Fi, każdy z możliwością passive sniffing.
Co można wywnioskować?Temat konwersacji (np. przestępczość finansowa, medyczne zapytania, poglądy polityczne). To wystarczy do profilowania i wyzwolenia działań (cenzura, targetowanie).
Sektory wrażliwe: prawo, zdrowie, finanse, sektor publiczny, media/NGO w krajach restrykcyjnych.
Skala: badanie obejmowało 28 modeli głównych dostawców; część z nich osiągała wyniki umożliwiające nadzór na masową skalę.
Rekomendacje operacyjne / co zrobić teraz
Dla dostawców/usług LLM (serwer)
Obfuskacja strumienia odpowiedzi — dodawanie losowego tekstu o zmiennej długości do chunków strumieniowych (wprowadzono m.in. w OpenAI, Azure; Mistral dodał dedykowany parametr). Silnie obniża skuteczność ataku.
Batching tokenów (np. wysyłanie co 3–5 tokenów zamiast pojedynczych) — wygładza wzorce. Trade-off: większa latencja „pierwszego znaku”.
Tryb niestreamingowy (opcjonalny) — umożliwienie klientom żądania odpowiedzi bez strumienia dla zapytań wrażliwych.
Ciągła ewaluacja — testy regresyjne pod kątem wycieków metadanych (AUPRC/ROC na syntetycznych zbiorach tematów).
Dla integratorów/architektów (klient, brzeg)
Wyłącz strumieniowanie dla przepływów „tajemniczych” (domyślnie stream=False / brak streamu w większości SDK). Segmentuj ruch (oddzielny endpoint/trasowanie dla zapytań wrażliwych).
Preferuj dostawców z wdrożonymi mitigacjami (OpenAI, Azure, Mistral, xAI — wg stanu na 7–9 listopada 2025).
VPN/zero-trust egress na wyjściu organizacji (utrudnia lokalnym przeciwnikom korelację strumienia, choć nie eliminuje ataku u dostawcy/ISP).
Buduj detektory anomalii na własnych bramach (np. wykrywanie nietypowych wzorców TLS/HTTP2 dla usług LLM, by lokalnie oceniać ryzyko ekspozycji).
Dla zespołów bezpieczeństwa (SOC/Blue)
Policy awareness: oznacz tematy wrażliwe i wymuś polityki non-streaming + dostawcy z mitigacjami.
Monitoring: rejestrowanie metryk egress (rozmiary rekordów, jitter) w kanałach do usług LLM, by audytować zgodność.
Szkolenia użytkowników:nie zadawać pytań o wysokiej wrażliwości przez LLM w sieciach niezaufanych (hotele, kawiarnie).
Przykładowe „kontrole” w praktyce (demo):
Blokowanie strumieniowania po stronie reverese-proxy (np. endpoint „sensitive” przekierowany do niestreamingowej ścieżki API).
Kontrola jakości dostawcy — test A/B: wysyłaj paczkę 100 pytań „sensitive” i 10 000 pytań „noise”; mierz AUPRC własnym klasyfikatorem metadanych — jeśli > próg (np. 0.9), eskaluj do zmiany dostawcy/konfiguracji.
Różnice / porównania z innymi przypadkami (jeśli dotyczy)
Whisper Leak vs. Token-length (Weiss et al. 2024): Weiss celował w rekonstrukcję treści bazując na długościach tokenów; Whisper Leak skupia się na klasyfikacji tematu na bazie rozmiarów i timingów pakietów — skuteczne nawet, gdy usługodawca grupuje tokeny.
Whisper Leak vs. Remote Timing (Carlini & Nasr 2024): Carlini/Nasr eksploitują optymalizacje efektywności (np. speculative decoding) i subtelne różnice czasowe; Whisper Leak korzysta z makro-wzorca strumienia (rozmiar+czas) i działa na popularnych usługach.
Podsumowanie / kluczowe wnioski
Metadane ruchu LLM potrafią zdradzić temat rozmowy mimo TLS.
Atak jest praktyczny przy masowym nadzorze (ISP/Wi-Fi), co rodzi realne ryzyka dla prywatności i compliance.
Mitigacje istnieją, ale to trade-off koszt/latencja/jakość i nie dają pełnej eliminacji — potrzebny defense-in-depth po stronie dostawcy i rozsądna higiena użytkowania po stronie klienta.
Źródła / bibliografia
Microsoft Security Blog — Whisper Leak: A novel side-channel attack on remote language models (7 listopada 2025). (Microsoft)
McDonald, Bar-Or — Whisper Leak: a side-channel attack on Large Language Models (arXiv, 5 listopada 2025). (arXiv)
Weiss et al. — What Was Your Prompt? A Remote Keylogging Attack on AI Assistants (USENIX Security 2024 / arXiv). (arXiv)
Carlini, Nasr — Remote Timing Attacks on Efficient Language Model Inference (arXiv, 22 października 2024). (arXiv)
The Hacker News — Microsoft Uncovers ‘Whisper Leak’ Attack That Identifies AI Chat Topics in Encrypted Traffic (8 listopada 2025). (The Hacker News)
Na OpenVSX (alternatywny rejestr rozszerzeń VS Code) wykryto powrót kampanii GlassWorm – zestawu złośliwych rozszerzeń wykorzystujących niewidzialne znaki Unicode do ukrywania i wykonywania JavaScriptu. Nowa fala obejmuje 3 rozszerzenia (m.in. ai-driven-dev.ai-driven-dev, adhamu.history-in-sublime-merge, yasuyuky.transient-emacs) i według bieżących raportów odnotowała łącznie >10 tys. pobrań. Kampania kontynuuje wcześniej opisane techniki: C2 w łańcuchu Solana, kradzież tokenów GitHub/npm/OpenVSX oraz danych portfeli krypto z 49 popularnych wtyczek.
W skrócie
Co się stało: po październikowych czyszczeniach OpenVSX znów pojawiły się 3 zainfekowane rozszerzenia z ukrytym ładunkiem GlassWorm.
Jak działa: payload jest schowany w znakach PUA/VS (Private Use Area/Variation Selectors) – „puste” w edytorze, ale dekodowane i wykonywane przez JS. C2 i aktualizacje są osadzane w transakcjach Solana (trwałość, anonimizacja, niskie koszty).
Po co: kradzież sekretów (GitHub, npm, OpenVSX), drenaż krypto, tworzenie SOCKS proxy/HVNC i budowa infrastruktury przestępczej na stacjach devów.
Skala i spór: OpenVSX informował, że incydent z października był „opanowany” i że nie była to autonomiczna samoreplikacja; jednak badacze widzą „samopowielanie” przez kradzież i użycie poświadczeń.
Nowość: potwierdzone wejście na GitHub (commity z doklejonym, ukrytym dekoderem + eval) – to rozszerza wektor poza marketplace.
Kontekst / historia / powiązania
Pierwsza fala GlassWorm została opisana 20 października 2025 r., gdy wykryto pakiet zainfekowanych rozszerzeń na OpenVSX i w marketplace Microsoftu (łączny licznik pobrań szacowany na ok. 35,8 tys., choć mógł być sztucznie zawyżony przez atakujących). 2 listopada OpenVSX ogłosił rotację tokenów i dodatkowe zabezpieczenia po wykryciu wycieku >550 sekretów; jednocześnie podkreślił, że kod nie był „samoreplikującym się” robakiem w klasycznym sensie. 6 listopada badacze Koi i Aikido pokazali jednak nową falę oraz pivot na GitHub. 8 listopada media potwierdziły trzy świeże rozszerzenia na OpenVSX.
Analiza techniczna / szczegóły luki
1) „Niewidzialny” ładunek
Atak wykorzystuje PUA/VS (np. zakresy U+E000–U+F8FF, U+FE00–U+FE0F), które nie renderują się w edytorze, ale są parsowane przez dekoder w JS. Typowy wzorzec: dekoder mapujący punkty kodowe → bajty → eval. Na GitHub widziano jednolinijkowy wariant, który dołączał dekoder na końcu pliku.
2) Kanał C2/aktualizacji w Solanie
Rozszerzenia pobierają następne etapy na podstawie transakcji Solana (w polach danych trzymane są base64 z URL-ami serwerów C2). Rozwiązanie trudne do zdejmowania (odporne, tanie, anonimowe). Backup: Google Calendar z linkiem base64 w tytule wydarzenia.
3) Zdolności końcowe
Kradzież tokenów/logowań (GitHub/npm/OpenVSX), portfeli krypto (49 wtyczek), uruchamianie SOCKS proxy, HVNC (ukryty VNC) – praktycznie przejęcie stacji deweloperskiej jako węzła przestępczego.
4) Infrastruktura i IOC
Koi w nowej fali wskazało, że używana jest ta sama infrastruktura (zaktualizowane wskaźniki C2 publikowane w Solanie; przykładowo w raporcie widnieją adresy 199.247.10.166 oraz 199.247.13.106:80/wall jako punkty komunikacji/eksfiltracji).
Praktyczne konsekwencje / ryzyko
Łańcuchowe kompromitacje: kradzione tokeny wydawnicze pozwalają wstrzykiwać złośliwe aktualizacje do innych rozszerzeń/repozytoriów/teamów.
Trwałość i trudne wyłączenie:C2 na blockchainie zmniejsza skuteczność klasycznych Takedownów. Zmiana transakcji → nowy endpoint → „samoleczenie” C2.
Ryzyko finansowe i reputacyjne: wyciek sekretów organizacji, kradzież krypto, nadużycie zasobów (proxy, botnet z dev-workstation).
Rozszerzenie wektora: pojawienie się ukrytych commitów na GitHub (AI-like, wiarygodne modyfikacje) utrudnia code review i detekcję.
Rekomendacje operacyjne / co zrobić teraz
0) Szybkie kroki IR (dla SOC/ITSec)
Zidentyfikuj i usuń trzy rozszerzenia z nowej fali (oraz te z list październikowych):
Sprawdź stacje devów pod kątem IOC/C2 i anomalii sieciowych (np. komunikacja do znanych hostów z raportu Koi).
Rotuj sekrety: patche PAT/ghp, npm tokens, OpenVSX tokens, klucze do CI/CD; wymuś 2FA i SSO. (OpenVSX przeszedł już rotację tokenów, ale Twoja organizacja musi zrobić to samo).
1) Wykrywanie „niewidzialnego” kodu (proste skrypty)
Linux/macOS – skan katalogów rozszerzeń VS Code/VSCodium
# VS Code i VSCodium: typowe ścieżki
EXT_DIRS=("$HOME/.vscode/extensions" "$HOME/.vscode-oss/extensions" "$HOME/.vscode-insiders/extensions")
# Znaki PUA/VS: U+E000–U+F8FF, U+FE00–U+FE0F, U+E0100–U+E01EF
for d in "${EXT_DIRS[@]}"; do
[ -d "$d" ] || continue
echo "[*] Skanuję $d"
grep -RIl --include='*.js' --include='*.ts' \
-P "[\x{E000}-\x{F8FF}\x{FE00}-\x{FE0F}\x{E0100}-\x{E01EF}]" "$d" || true
done
Sekrety: ogranicz TTL tokenów, wprowadź krótko żyjące PAT, automatyczną re-rotację po wykryciu wycieku; secret scanning w CI. (Zgodne z kierunkiem zmian deklarowanych przez OpenVSX).
Publikacja rozszerzeń: SBOM + skan artefaktów przed publikacją, signowanie, zasada 4-oczu na „release”.
Review kodu: wymuś widoczność znaków niewidzialnych w IDE i Diffach (np. włącz „Render Control Characters” w VS Code, używaj pre-commit hooków skanujących PUA). (W raporcie Aikido wskazano, że interfejsy nie zawsze oznaczały te znaki).
Egress i DNS: blokady do znanych IOC oraz monitorowanie zapytań powiązanych z Solaną używaną jako kanał C2 (telemetria proxy, NetFlow/Zeek).
Różnice / porównania z innymi przypadkami
Klasyczne „tylne drzwi” w npm (post-install, skrypty lifecycle) były wyraźniejsze w kodzie; tutaj ładunek „nie istnieje gołym okiem” i potrafi przenikać code review.
C2 w Solanie to nowszy trend utrudniający Takedown – w porównaniu do typowych domen/URL na VPS, które łatwiej zawiesić.
Spór o „worma”: OpenVSX wskazuje, że brak autonomicznej replikacji; badacze argumentują, że automatyczne aktualizacje + wykorzystanie wykradzionych tokenów de facto umożliwia rozprzestrzenianie się w ekosystemie. Wniosek operacyjny: dla obrony nie ma to znaczenia – ścieżka propagacji i tak omija kontrole.
Podsumowanie / kluczowe wnioski
Niewidzialny kod + blockchain C2 + kradzież sekretów = bardzo skuteczny model ataku na ekosystemy developerskie.
Nowa fala na OpenVSX pokazuje, że nawet po rotacji tokenów atakujący szybko wracają – potrzebne są krótkie TTL, skanowanie podczas publikacji i silne procesy w organizacjach.
Blue Teamy powinny wdrożyć skan PUA, bloki IOC, telemetrię egress i procedury IR wyspecjalizowane dla stacji developerskich (zależne od IDE/marketplace).
Źródła / bibliografia
BleepingComputer – nowa fala, 3 rozszerzenia i >10k pobrań (08.11.2025). (BleepingComputer)
BleepingComputer – analiza pierwszej fali (20.10.2025). (BleepingComputer)
Eclipse Foundation (OpenVSX) – aktualizacja bezpieczeństwa, rotacje tokenów i stanowisko nt. „self-replicating” (27.10.2025; podsumowane także 02.11.2025). (Eclipse Foundation Staff Blogs)
Koi Security – „GlassWorm Returns”: nowe IoC, opis pivotu i zrzuty z serwera atakujących (06.11.2025). (Koi)
Aikido Security – „The Return of the Invisible Threat”: wzorzec jednolinijkowego dekodera, pivot na GitHub (31.10.2025). (Aikido)