Archiwa: APT - Strona 23 z 31 - Security Bez Tabu

Krytyczna luka w WatchGuard Firebox (CVE-2025-9242) jest aktywnie wykorzystywana. Jak się bronić?

Wprowadzenie do problemu / definicja luki

W urządzeniach WatchGuard Firebox (system Fireware OS) wykryto lukę CVE-2025-9242 o krytycznym poziomie ryzyka (CVSS 9.3), która umożliwia zdalne wykonanie kodu bez uwierzytelnienia poprzez błąd out-of-bounds write w procesie iked (obsługa IKEv2/IPsec dla Mobile User VPN i Branch Office VPN). CISA dodała już podatność do katalogu Known Exploited Vulnerabilities (KEV) na podstawie dowodów aktywnego wykorzystywania w atakach.

W skrócie

Co: Out-of-bounds write w iked (IKEv2), prowadzący do RCE bez uwierzytelniania.
Kogo dotyczy: Fireware OS 11.10.2–11.12.4_U1, 12.0–12.11.3, 2025.1 (różne modele Firebox). Naprawione w 2025.1.1, 12.11.4, 12.5.13 (T15/T35), 12.3.1_Update3 (B722811); gałąź 11.x – EoL.
Wejście atakującego: Ruch IKEv2 z Internetu na UDP/500 i UDP/4500 (NAT-T).
Status: Aktywnie wykorzystywana; CISA/KEV wymaga szybkiej aktualizacji.
Ekspozycja: Shadowserver raportował >73k niezałatanych Fireboxów widocznych w Internecie w październiku.

Kontekst / historia / powiązania

WatchGuard opublikował poradnik PSIRT 17 września 2025 r., a 21 października 2025 r. zaktualizował go o wskaźniki ataku (IoA) i zalecenie rotacji lokalnie przechowywanych sekretów (np. hasła, pre-shared keys) „z ostrożności”, po sygnałach o realnych próbach eksploatacji. 13 listopada 2025 r. dołączenie do CISA KEV potwierdziło etap aktywnego nadużycia.

Równolegle watchTowr opublikował techniczną analizę i reprodukcję błędu, ułatwiającą zrozumienie prymitywu pamięci, który stoi za RCE.

Analiza techniczna / szczegóły luki

Wejście: komunikaty IKE_AUTH w trakcie zestawiania IKEv2. Błąd out-of-bounds write w implementacji iked można wywołać manipulując polami ładunku IDi (identyfikator inicjatora) – udokumentowanym wskaźnikiem podejścia jest nienaturalnie duży rozmiar IDi (>100 bajtów) w logach diagnostycznych. Udana eksploatacja może spowodować zawieszenie lub crash procesu iked, a w wektorze RCE – wykonanie kodu w kontekście urządzenia.

Warunek konfiguracji: Podatność dotyczy Mobile User VPN (IKEv2) i BOVPN (IKEv2) z dynamicznym peerem. Co istotne, nawet po usunięciu takich konfiguracji urządzenie może pozostać podatne, jeśli nadal istnieje BOVPN do statycznego peera.

Zakres wersji i poprawki: jw. (sekcja „W skrócie”). Gałąź 11.x jest EoL – brak poprawek producenta.

Dowody wykorzystania: wpis w CISA KEV oraz doniesienia branżowe; SecurityWeek wskazuje na decyzję CISA nakazującą pilną aktualizację w instytucjach federalnych (BOD 22-01).

Praktyczne konsekwencje / ryzyko

Przejęcie perymetru: RCE na firewallu = pełna kontrola nad ruchem, podsłuch/mitm, pivot do sieci wewnętrznej.
Wyłączenie VPN / zakłócenia: zawieszanie/crash iked przerywa tunele BOVPN i dostęp zdalny.
Masowa skala ataku: dziesiątki tysięcy urządzeń w Internecie, atrakcyjny cel dla ransomware/APT (brak uwierzytelnienia, stałe UDP).

Rekomendacje operacyjne / co zrobić teraz

0) Priorytet i okno serwisowe
Traktuj jako P1. Zaplanuj szybkie prace: upgrade + rotacja sekretów.

1) Szybka inwentaryzacja i wykrywanie

Zidentyfikuj wszystkie Fireboxy z interfejsem WAN mającym UDP/500 i UDP/4500 otwarte do Internetu.
Sprawdź wersję Fireware OS i konfigurację VPN (czy używasz IKEv2 oraz dynamic peers).
Przejrzyj logi iked pod kątem IoA od WatchGuard: „IKE_AUTH request … IDi(sz=…>100)”, zawieszenia lub crashe iked. (Włącz poziom Info dla diagnostyki iked, jeśli to konieczne).

Przykładowe zapytania (do szybkiego łapania IoA w SIEM):

Syslog / Splunk index=network_logs sourcetype=watchguard:iked "IKE_AUTH request" IDi(sz=* | rex "IDi\\(sz=(?<idi>\d+)\\)" | where tonumber(idi) > 100
Elastic (KQL) message : "*IKE_AUTH request*" and message : "*IDi(sz=*"
tcpdump – szybka inspekcja IKEv2 (porty i długości) Uwaga: rozmiary payloadów IKEv2 nie są „z pudełka” parsowane; użyj do triage’u i korelacji z logami. tcpdump -ni any udp port 500 or udp port 4500

2) Aktualizacja (remediacja właściwa)

Zaktualizuj do 2025.1.1 / 12.11.4 / 12.5.13 / 12.3.1_Update3 zgodnie z tabelą WatchGuard PSIRT. Dla 11.x – wymiana/upgrade platformy (EoL, brak łat). Po aktualizacji zrestartuj i zweryfikuj wersję.

3) Rotacja sekretów (po aktualizacji)

WatchGuard zaleca rotację wszystkich lokalnie przechowywanych sekretów (hasła, PSK, klucze) „z ostrożności”. Zacznij od PSK dla BOVPN/MUVPN oraz haseł administratorów.

4) Dodatkowe twardnienie i ograniczenie powierzchni ataku

Dostęp IKEv2 tylko z zaufanych adresów (listy peerów/ACL na brzegowym FW/WAF, o ile architektura pozwala).
Rate-limit dla UDP/500, 4500 na zewnętrznych interfejsach (nftables/iptables) – utrudnia bruteforce i rozpoznanie: # nftables – ratelimiting IKEv2 (przykład) nft add table inet edge nft add chain inet edge input { type filter hook input priority 0 \; } nft add rule inet edge input udp dport {500,4500} ct state new limit rate 20/second accept nft add rule inet edge input udp dport {500,4500} drop
Monitoring integralności i wysoki poziom logowania iked przynajmniej tymczasowo.

5) Doraźne obejścia (gdy nie możesz od razu patchować)

Jeśli używasz wyłącznie BOVPN do statycznych peerów, zastosuj wytyczne producenta dot. „Secure Access to BOVPN IKEv2” jako tymczasowe ograniczenie ryzyka. (Nie zastępuje aktualizacji!)

6) Wykrywanie w sieci (IDS/IPS) – przykładowa reguła Suricata

Heurystyka: nieproporcjonalnie duże IDi w IKE_AUTH. Reguła orientacyjna – wymaga testów i dostrojenia w danym środowisku.

alert udp any any -> $HOME_NET [500,4500] (
  msg:"IKEv2 anomaly: oversized IDi in IKE_AUTH (WatchGuard CVE-2025-9242 heuristic)";
  flow:to_server;
  dsize:>600;               # heurystyczny próg długości pakietu
  content:"|2f|"; offset:0; depth:1;  # IKEv2 major/minor wersja w pierwszym bajcie: 0x2F (IKE_SA?); DEMO
  classtype:attempted-admin; sid:25259242; rev:1;
)

(IKEv2 nie ma banalnego „sygnaturowego” pola dla IDi bez pełnego parsowania – potraktuj to jako punkt startowy do własnej inspekcji).

7) Skany zewnętrzne / wykrywacze

Zespół watchTowr udostępnił skrypt pomocniczy do weryfikacji podatności (detekcja warunku wersji/konfiguracji) – używaj wyłącznie we własnej infrastrukturze.

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

Charakter wektora: podobnie jak dawne łańcuchy RCE w Fortinet/Citrix, tutaj także mamy unauthenticated edge RCE na urządzeniu brzegowym. Różnica: specyfika IKEv2 i prymityw pamięci w iked.
Stan publicznych PoC: w chwili pisania brak szeroko dostępnego, w pełni działającego PoC RCE; istnieją analizy i reprodukcje badaczy (watchTowr), a CISA raportuje realne wykorzystanie. To klasyczny etap „patch now, ask later”.

Podsumowanie / kluczowe wnioski

CVE-2025-9242 to krytyczna luka RCE w WatchGuard Firebox/Fireware OS w komponencie IKEv2 (iked).
Jest aktywnie wykorzystywana; CISA wpisała ją do KEV – traktuj jako incydent prewencyjny o najwyższym priorytecie.
Aktualizuj do wersji naprawionych i rotuj sekrety; dla EoL 11.x – zaplanuj wymianę.
Zastosuj dodatkowe kontrole (ACL/ratelimity/monitoring IoA) do czasu pełnego wdrożenia poprawek.
Weryfikuj logi iked pod kątem anomalii (duży IDi) oraz stabilność procesu – to praktyczne IoA od producenta.

Źródła / bibliografia

WatchGuard PSIRT – „WatchGuard Firebox iked Out of Bounds Write Vulnerability (WGSA-2025-00015)” – zakres wersji, IoA, zalecenia (akt. 7 XI i 21 X 2025). (watchguard.com)
CISA – Alert/KEV: dodanie CVE-2025-9242 jako aktywnie wykorzystywanej (13 XI 2025). (CISA)
SecurityWeek – „Critical WatchGuard Firebox Vulnerability Exploited in Attacks” (13 XI 2025). (SecurityWeek)
Shadowserver – obserwacje skali ekspozycji (73k+ niezałatanych Fireboxów). (SecurityWeek)
watchTowr labs – analiza techniczna i reprodukcja błędu IKEv2/iked. (watchTowr Labs)

RCE w ImunifyAV/AI-Bolit: zdalne wykonanie kodu z poziomu skanera AV. Miliony serwisów Linux w zasięgu ataku

Wprowadzenie do problemu / definicja luki

W popularnym skanerze z rodziny Imunify – module AI-Bolit dostarczanym w Imunify360, ImunifyAV+ oraz darmowym ImunifyAV – wykryto krytyczny błąd pozwalający na zdalne wykonanie kodu (RCE) podczas analizy złośliwych, obfuskowanych plików PHP. Luka dotyczy wersji przed 32.7.4.0. Dostawca (CloudLinux/Imunify) wydał poprawki i zaleca natychmiastową aktualizację do ≥ 32.7.4.0; backport dla starszych gałęzi Imunify360 pojawił się 10 listopada 2025 r.

Kluczowe: wektor ataku uruchamia się w trakcie skanowania – skaner, próbując „odkleić” warstwy obfuskacji, może wykonać funkcje wskazane przez napastnika (np. system, exec, shell_exec, passthru, eval).

W skrócie

Zagrożone: instalacje Imunify360/AV+/AV z komponentem AI-Bolit < 32.7.4.0.
Ryzyko: RCE z uprawnieniami procesu skanera; na hostingu współdzielonym może to oznaczać pełne przejęcie serwera.
Wektor: specjalnie przygotowane, obfuskowane pliki PHP skanowane przez AI-Bolit (deobfuskacja wymuszona w integracji Imunify).
Stan: poprawka dostępna; brak CVE w momencie publikacji; oficjalna notka w bazie wiedzy, wzmianka w changelogu.
Akcja: update do 32.7.4.0+, audyt artefaktów po ewentualnym RCE, ograniczenie uprawnień procesu skanera, izolacja.

Kontekst / historia / powiązania

To nie pierwszy raz, gdy AI-Bolit ma problem z wykonywaniem nieufnych danych. W 2021 r. Talos opisał RCE (CVE-2021-21956) wynikające z PHP unserialize w AI-Bolit (dot. wersji 5.8–5.10.2), naprawione w 5.11.3. Obecna podatność jest innej natury, ale podobnie dotyka ścieżki analizy złośliwych próbek.

Wg źródeł publicznych, o problemie w 2025 r. informowano od końca października; 4 listopada pojawił się wpis w Zendesk (Knowledge Base) pt. „Ai-Bolit security vulnerability before v32.7.4.0”; 10 listopada – backport; 12–13 listopada – publikacje techniczne i prasowe.

Analiza techniczna / szczegóły luki

Miejsce błędu

AI-Bolit stosuje heurystyki i moduły deobfuskacji do rozklejania łańcuchów base64/gzinflate/pack/chr/ord/....
Krytyczna część logiki wywołuje funkcje przez call_user_func_array na nazwach funkcji odzyskanych z próbki (np. system, shell_exec, eval) – bez walidacji.
W CLI deobfuskacja bywa domyślnie wyłączona, ale integracja Imunify (Python wrapper) zawsze przekazuje --deobfuscate dla wszystkich typów skanów (tła, on-demand, user-initiated, rapid).

Wymagania ataku

Napastnik umieszcza plik PHP zawierający specjalnie przygotowany, obfuskowany ładunek (np. w katalogu strony lub katalogu tymczasowym), który trafi do skanera AI-Bolit.
W trakcie deobfuskacji skaner wykonuje zakodowane ciągi jako nazwy funkcji i argumenty → RCE.
Patchstack publikuje PoC, który podczas skanowania tworzy plik w /tmp – dowód wykonania komendy.

Poprawka

Vendor dodał whitelistę funkcji bezpiecznych i „deterministycznych” (np. base64_decode, gzinflate, strrev, chr, ord, …) oraz blokadę arbitralnych wywołań.

Praktyczne konsekwencje / ryzyko

Hosting współdzielony (cPanel/Plesk): jeśli skaner działa z podwyższonymi uprawnieniami (częste), exploity mogą umożliwić eskalację poza pojedynczy vhost – do roota w niektórych, źle utwardzonych konfiguracjach.
Zaciemnienie śladów: ładunki są z natury obfuskowane; logi skanera mogą nie zapisać jednoznacznej sygnatury. Trzeba polować na artefakty boczne (np. tworzone pliki w /tmp, nieoczekiwane połączenia wychodzące z procesu skanera PHP).
Łańcuchy ataków: możliwe dołożenie web-shelli, modyfikacja wp-config.php, wstrzyknięcie crontabów użytkowników, pivot na inne konta poprzez wspólne ścieżki/UID. (Wniosek z natury RCE skanera działającego globalnie na hostingu.)

Rekomendacje operacyjne / co zrobić teraz

1) Natychmiastowa aktualizacja

Docelowa wersja: AI-Bolit/Imunify AV 32.7.4.0 lub nowsza.
Oficjalne potwierdzenie i komunikat KB: „Ai-Bolit security vulnerability before v32.7.4.0” (CloudLinux Zendesk).

cPanel/WHM – systemy RPM (Alma/RHEL/CentOS):

# sprawdź pakiety Imunify/AI-Bolit
rpm -qa | egrep -i 'imunify|ai-bolit'

# aktualizacja z repozytoriów Imunify
yum clean all && yum -y update imunify* ai-bolit* imunify-antivirus* imunify360*

# restart usług powiązanych (przykładowo)
systemctl restart imunify360 imunify-antivirus || true

Debian/Ubuntu (Plesk/VPS):

apt-get update
apt-get install --only-upgrade imunify* ai-bolit* imunify360*
systemctl restart imunify360 imunify-antivirus || true

Uwaga: nazwy paczek różnią się między dystrybucjami/integracjami. W razie wątpliwości – sprawdź dpkg -l | grep -i imunify / rpm -qi <pakiet>.

2) Weryfikacja, czy wersja jest już bezpieczna

Ponieważ AI-Bolit to komponent, w praktyce sprawdzamy wersję paczek Imunify oraz binariów w /opt/ai-bolit/:

# szybkie tropy wersji
strings /opt/ai-bolit/ai-bolit.php 2>/dev/null | egrep -i 'version|ai-bolit'
# lub:
grep -i version /opt/ai-bolit/* 2>/dev/null

# Imunify360/AV wersje pakietów
imunify360-agent version 2>/dev/null || true
rpm -qa | grep -i ai-bolit || dpkg -l | grep -i ai-bolit

(Dostawca nie publikuje jednolitego polecenia „–version” dla AI-Bolit w każdej dystrybucji; opieramy się więc na wersjach pakietów i artefaktach plikowych). Informacja o wymaganej wersji pochodzi z BleepingComputer/KB.

3) Działania kompensacyjne (jeśli patch musi poczekać – niezalecane)

Izoluj skaner: uruchamiaj w kontenerze/sandboxie z mnim. uprawnieniami (AppArmor/SELinux profil, noexec na /tmp, ograniczenia sieciowe).
Zabroń deobfuskacji w trybie standalone (CLI) – nie w pełni skuteczne w integracji Imunify, która i tak wymusza --deobfuscate.
UCIĄĆ możliwości wykonania: mounty nodev,nosuid,noexec dla partycji tymczasowych (/tmp, /var/tmp, dev/shm).

4) Polowanie na ślady (triage po incydencie)

Skorzystaj z informacji o PoC (tworzenie pliku w /tmp), a także ogólnych wzorców RCE z PHP:

# 1) Artefakty PoC oraz potencjalnych ładunków
find /tmp -maxdepth 1 -type f -mmin -4320 -printf '%TY-%Tm-%Td %TT %p %s\n' | egrep 'l33t|def|tmp|\.php'

# 2) Nietypowe wywołania procesu skanera (czas skanów)
ps -eo user,pid,ppid,lstart,cmd | egrep -i 'ai-bolit|imunify|php'

# 3) Ostatnio zmieniane pliki w vhostach (web-shelle, .php w uploadach)
find /home /var/www -type f -mtime -2 -iname '*.php' -printf '%p %TY-%Tm-%Td %TT %u:%g %s\n' | head

# 4) Crontaby i autostarty użytkowników
for u in $(cut -d: -f1 /etc/passwd); do crontab -l -u "$u" 2>/dev/null | sed "s/^/$u: /"; done

# 5) Grep na funkcje wysokiego ryzyka w drzewach WWW
grep -R --include=*.php -nE '(shell_exec|system|passthru|eval\()' /var/www /home/*/public_html 2>/dev/null

Dodatkowo przejrzyj logi serwera w oknach czasowych skanów oraz outbound (egres) procesu PHP/ai-bolit.

5) Utwardzanie na przyszłość

Uruchamiaj skanery pod odseparowanym użytkownikiem, bez roota; ogranicz CAP_*.
Włącz LSM (AppArmor/SELinux) z profilami dla procesu skanera.
W hostingach współdzielonych: CageFS/CloudLinux, mod_suexec/php-fpm per-user, izolacja sieciowa i systemowa per konto.
Monitoring integralności (AIDE/OSSEC/Wazuh) + alerty na tworzenie plików wykonywalnych w /tmp.

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

CVE-2021-21956 (AI-Bolit unserialize) – RCE przez niebezpieczne deserializacje; naprawione w 5.11.3.
Obecna luka (2025) – RCE przez wykonywanie funkcji odzyskanych z obfuskowanego kodu podczas deobfuskacji; brak CVE w chwili pisania, naprawa w 32.7.4.0 i nowszych.
Wspólny mianownik: powierzchnia ataku w silniku analizy skanera. Wnioski dla vendorów: deobfuskacja powinna być czysto syntaktyczna, nigdy „egzekucyjna”.

Podsumowanie / kluczowe wnioski

Jeśli używasz Imunify360/ImunifyAV(+), zaktualizuj natychmiast do ≥ 32.7.4.0.
Potraktuj środowisko jak potencjalnie naruszone, jeśli skany uruchamiano na niezaufanych plikach w okresie przed aktualizacją – wykonaj triage i threat hunting.
Nawet narzędzia bezpieczeństwa wymagają zasady najmniejszych uprawnień i izolacji; skaner AV nie powinien móc zniszczyć całego hosta.

Źródła / bibliografia

BleepingComputer – „RCE flaw in ImunifyAV puts millions of Linux-hosted sites at risk”, 13 listopada 2025 (szczegóły wersji, kontekst wdrożeń, backport 10 XI). (BleepingComputer)
Patchstack – „Critical: Remote Code Execution via Malicious Obfuscated Malware in Imunify360 AV (AI-Bolit)”, 12 listopada 2025 (analiza techniczna, PoC, wymuszenie --deobfuscate, opis łatki). (Patchstack)
CloudLinux/Imunify – Knowledge Base: „Ai-Bolit security vulnerability before v32.7.4.0.”, wpis z 4–12 listopada 2025 (oficjalna notka i zalecenie aktualizacji). (cloudlinux.zendesk.com)
NVD/Cisco Talos – CVE-2021-21956 (porównanie z wcześniejszym RCE w AI-Bolit, 2021). (NVD)

Firefox 145 i Chrome 142 łatają luki o wysokiej wadze — co dokładnie naprawiono i jak szybko się zabezpieczyć

Wprowadzenie do problemu / definicja luki

11–12 listopada 2025 r. Mozilla i Google opublikowały stabilne aktualizacje przeglądarek Firefox 145 oraz Chrome 142, które usuwają istotne podatności bezpieczeństwa.

Chrome 142.0.7444.162/.163 (Windows), .162 (macOS/Linux) naprawia błąd w silniku V8 sklasyfikowany jako „high” (CVE-2025-13042).
Firefox 145 łata 16 podatności, w tym 9 o wysokiej wadze, głównie w obszarach Graphics/WebGPU, WebAssembly i JS JIT; część błędów to problemy z warunkami brzegowymi i wyścigiem, a także zbiorcze błędy bezpieczeństwa pamięci (CVE-2025-13021…13027).

Dodatkowo Firefox 145 wprowadza rozszerzone mechanizmy anty-fingerprinting, które znacząco utrudniają śledzenie użytkowników.

W skrócie

Chrome 142: jedna poprawka bezpieczeństwa „high” w V8 (CVE-2025-13042). Aktualizacja jest niewielka, ale ważna.
Firefox 145: 16 łatek, z czego 9 „high”; pięć dotyczy WebGPU (warunki brzegowe), jedna to race condition w grafice, jedna podatność w WebAssembly, jedna JIT miscompilation, plus zbiorcze błędy bezpieczeństwa pamięci.
Prywatność: nowe zabezpieczenia Firefoksa przeciw fingerprintingowi (na starcie w trybach Private/ETP Strict), istotnie ograniczają unikatowość odcisku przeglądarki.

Kontekst / historia / powiązania

Firefox od kilku wersji intensywnie rozwija WebGPU oraz równolegle twarde zabezpieczenia prywatności (ETP, Total Cookie Protection, anti-fingerprinting). W wydaniu 145 te dwa wątki „spotykają się”: z jednej strony naprawy błędów renderera, z drugiej — kolejne warstwy utrudniające identyfikację urządzenia.
Chrome cyklicznie dostarcza szybkie poprawki V8; nawet pojedyncza łatka „high” bywa krytyczna ze względu na ryzyko zdalnej eksploatacji przez złośliwy JS.

Analiza techniczna / szczegóły luki

Chrome 142 (V8)

CVE-2025-13042 – Inappropriate implementation in V8 (High): błąd implementacyjny w silniku JavaScript. Google ogranicza szczegóły do czasu szerokiego wdrożenia aktualizacji (standardowa praktyka), ale klasa ta często umożliwia DoS lub nawet remote code execution w kontekście renderera przy odpowiednio spreparowanym skrypcie. Wersje: 142.0.7444.162/.163 (Windows), .162 (macOS/Linux).

Firefox 145 (pakiet poprawek)

Najważniejsze elementy z MFSA 2025-87:

WebGPU / Graphics – incorrect boundary conditions (High): CVE-2025-13021, -13022, -13025 oraz dwa przypadki z potencjałem sandbox escape (CVE-2025-13023, -13026). Problemy z walidacją zakresów i granic buforów/tekstur mogą prowadzić do naruszenia pamięci.
Race condition w Graphics (High): CVE-2025-13012 — typowa klasa błędu deterministycznie trudna do reprodukcji, ale ryzykowna w kontekście równoległego przetwarzania grafiki.
WebAssembly (High): CVE-2025-13016 — nieprawidłowe warunki brzegowe w komponencie WebAssembly. Może skutkować niepoprawnymi odwołaniami do pamięci.
JS JIT miscompilation (High): CVE-2025-13024 — błąd kompilatora JIT może generować nieprawidłowy kod maszynowy, potencjalnie umożliwiając obejście mechanizmów bezpieczeństwa.
Memory safety bugs (High): CVE-2025-13027 — zbiorcza kategoria błędów bezpieczeństwa pamięci naprawiona w 145 (dotyczy też Thunderbird 145).

Uwaga: Mozilla i Google nie raportują na dziś potwierdzonych ataków „in the wild” dla wymienionych CVE, ale okno na odwrócenie łat (patch diffing) jest realne — szybka aktualizacja ma znaczenie.

Prywatność w Firefox 145

Nowe zabezpieczenia anty-fingerprinting standaryzują i/lub szumią część sygnałów identyfikacyjnych (m.in. rozdzielczość, czcionki, wskaźniki sprzętowe), obniżając odsetek unikatowych odcisków przeglądarki w testach Mozilli; startowo w Private Browsing i ETP Strict, z planem rozszerzeń.

Praktyczne konsekwencje / ryzyko

Ryzyko zdalne przez zawartość web: klasy V8/WebGPU/WebAssembly/JIT to typowy wektor przez złośliwy JS/WebGPU/WASM uruchamiany przy samej wizycie na stronie.
Escape’y z piaskownicy (CVE-2025-13023/-13026) zwiększają konsekwencje udanego ataku na renderer (potencjalnie dostęp do zasobów systemowych użytkownika).
Łatwość weaponizacji: po publikacji binarek i commitów rośnie ryzyko stworzenia PoC na bazie różnic w kodzie (diff). W praktyce okno kilku–kilkunastu dni to czas najwyższego ryzyka dla niezałatanych środowisk.

Rekomendacje operacyjne / co zrobić teraz

1) Pilna aktualizacja (end-user i fleet)

GUI:

Chrome: Menu → Help → About Google Chrome (uruchomi auto-update).
Firefox: Menu → Pomoc → O programie Firefox.

CLI (pojedyncze stacje):

# Windows (winget)
winget upgrade --id Google.Chrome --source winget
winget upgrade --id Mozilla.Firefox --source winget

# macOS (Homebrew)
brew update && brew upgrade --cask google-chrome firefox

# Ubuntu/Debian (repozytoria producentów)
sudo apt-get update
sudo apt-get install --only-upgrade google-chrome-stable firefox

# RHEL/Fedora
sudo dnf upgrade google-chrome-stable firefox

2) Weryfikacja wersji w organizacji

Windows/PowerShell (skan szybki):

# Chrome
Get-ItemProperty "HKLM:\Software\Microsoft\Windows\CurrentVersion\Uninstall\Google Chrome" -ErrorAction SilentlyContinue |
  Select-Object DisplayVersion

# Firefox (64-bit)
Get-ItemProperty "HKLM:\Software\Mozilla\Mozilla Firefox" -ErrorAction SilentlyContinue |
  Select-Object CurrentVersion

macOS (Chrome/Firefox):

# Chrome
defaults read "/Applications/Google Chrome.app/Contents/Info.plist" CFBundleShortVersionString
# Firefox
defaults read "/Applications/Firefox.app/Contents/Info.plist" CFBundleShortVersionString

Linux (wersje):

google-chrome --version
firefox --version

3) Polityki enterprise — wymuś auto-update i wersje docelowe

Chrome: użyj szablonów ADMX/Intune, ustaw AutoUpdateCheckPeriodMinutes, UpdateDefault i (opcjonalnie) TargetVersionPrefix zgodny z 142.0.7444.
Firefox: zarządzaj przez GPO / policies.json (Firefox for Enterprise). Dokumentacja: egzekwowanie polityk i dystrybucja w środowiskach korporacyjnych.

4) Obejścia ryzyka (opcjonalnie, tymczasowo — do czasu pełnego patchowania)

Tylko jeśli musisz utrzymać ekspozycję do czasu rollout’u aktualizacji.

Firefox — ogranicz WebGPU:

Ręcznie (pojedynczy host): about:config → ustaw dom.webgpu.enabled=false.
Enterprise: dystrybuuj preferencję poprzez policies.json/GPO (Preference/Policies).
To ogranicza funkcjonalność WebGPU, lecz redukuje powierzchnię ataku z klas „incorrect boundary conditions”/„sandbox escape”. (Preferencja jest znana i używana do sterowania WebGPU).

Chrome: brak sensownego obejścia dla błędu w V8 poza szybką aktualizacją i twardymi zasadami przeglądania (uBO/NoScript, izolacja profili o podwyższonym ryzyku).

5) Monitoring / detekcja

EDR/SIEM: flaguj nowe procesy przeglądarki uruchamiane z nietypowymi argumentami, podejrzane child-processy (np. droppery spoza katalogów profilu), anomalia w bibliotekach GPU/ANGLE/WASM.
Hunt: krótkie okna czasowe wzrostu crashy w procesach renderera po wejściu na tę samą stronę mogą wskazywać na próby DoS/wykrywanie wersji.

Różnice / porównania z innymi przypadkami

Jedna „high” w Chrome vs. wiele „high” w Firefox: tu Firefox ma większą liczbę łatek, ale to odzwierciedla intensywny rozwój WebGPU/JIT — komponentów historycznie „wrażliwych”. Nie oznacza automatycznie, że Firefox jest „mniej bezpieczny”, raczej że zwiększono pokrycie fuzzingiem i twardo łata się powierzchnię ataku.
Prywatność: Firefox 145 przynosi wymierne wzmocnienia anty-fingerprinting (niedostępne w takim kształcie w Chrome), co dla organizacji privacy-by-design ma realną wartość.

Podsumowanie / kluczowe wnioski

Zaktualizuj natychmiast do Chrome 142 i Firefox 145; nawet pojedyncza łatka V8 „high” jest krytyczna operacyjnie.
Firefox 145 zamyka szereg luk w WebGPU/WASM/JIT; dwie z nich mają potencjał sandbox escape — to ważny powód do szybkiego rollout’u.
Dodatkowy plus: lepsza prywatność w Firefox 145 dzięki nowym zabezpieczeniom anty-fingerprinting (na starcie w Private/ETP Strict).

Źródła / bibliografia

Chrome Releases – Stable Channel Update for Desktop (11 listopada 2025): wersje i CVE-2025-13042. (Chrome Releases)
Mozilla Foundation Security Advisory MFSA 2025-87 – Security Vulnerabilities fixed in Firefox 145 (lista CVE). (Mozilla)
Firefox 145 – Release Notes (nowości/funkcje). (firefox.com)
Mozilla Blog – Firefox expands fingerprinting protections (opis nowych zabezpieczeń prywatności). (Mozilla Blog)
SecurityWeek – przegląd aktualizacji Chrome 142 i Firefox 145 (kontekst rynkowy). (SecurityWeek)

“CitrixBleed 2” i krytyczne błędy w Cisco ISE: fala ataków na infrastrukturę tożsamości

Wprowadzenie do problemu / definicja luki

W najnowszej kampanii ofensywnej zaobserwowano równoległe wykorzystanie dwóch błędów 0-day w kluczowych komponentach tożsamości i dostępu:

Citrix NetScaler ADC/Gateway – CVE-2025-5777, nieformalnie nazwany „CitrixBleed 2”: błąd ujawnienia informacji (out-of-bounds read) umożliwiający odczyt fragmentów pamięci i przejęcie sesji (w tym admina) bez uwierzytelniania, gdy urządzenie działa jako Gateway/AAA.
Cisco Identity Services Engine – CVE-2025-20337: pre-auth RCE jako root przez podatne API; dotyczy ISE/ISE-PIC i uzyskało ocenę CVSS 10.0.

Według najnowszych doniesień, ten sam aktor wykorzystywał oba błędy przed publikacją łat, co wprost uderza w infrastrukturę IAM/NAC i ułatwia trwałą kontrolę nad środowiskiem ofiary.

W skrócie

„CitrixBleed 2” (CVE-2025-5777) → wyciek pamięci i kradzież tokenów/sesji w NetScalerach działających jako Gateway/AAA.
Cisco ISE (CVE-2025-20337) → zdalne wykonanie kodu bez uwierzytelnienia jako root przez podatne API.
APT wykorzystywał oba jako 0-day (pre-patch), wdrażając niestandardowe web-shelle/malware i utrzymując niewykrywalną obecność.
Priorytet: natychmiastowe łatki + unieważnienie sesji, rotacja poświadczeń/kluczy, przegląd zaufania do całej płaszczyzny tożsamości.

Kontekst / historia / powiązania

Nazwa „CitrixBleed 2” nawiązuje do CitrixBleed (CVE-2023-4966) z 2023 r., który był masowo nadużywany m.in. przez grupy ransomware. Obecna luka ma podobny skutek (wyciek pamięci → przejęcie sesji), ale dotyczy nowszych wersji NetScaler i znów eksponuje perymetr zdalnego dostępu.

Po stronie Cisco ISE producent 25 czerwca 2025 r. opublikował poradnik o krytycznych RCE w ISE/ISE-PIC i w lipcu dodał CVE-2025-20337, potwierdzając maksymalną wagę problemu. Niezależne ośrodki (CERT-EU, NVD, NHS) spójnie wskazują na pre-auth RCE przez API.

Analiza techniczna / szczegóły luki

CVE-2025-5777 – NetScaler („CitrixBleed 2”)

Typ: out-of-bounds read → ujawnienie pamięci (m.in. tokeny sesyjne, ciasteczka) po wysłaniu spreparowanych parametrów logowania do komponentu uwierzytelniania.
Warunki: NetScaler skonfigurowany jako Gateway (VPN/ICA Proxy/ CVPN/RDP Proxy) lub AAA vServer.
Skutki: „dołączenie” do dowolnej sesji, przejęcie pulpitów VDI, hijacking aktywnych sesji admina – konsekwencje obserwowane w praktyce.

CVE-2025-20337 – Cisco Identity Services Engine

Typ: brak walidacji danych wejściowych w określonym API ISE/ISE-PIC → RCE jako root bez uwierzytelniania po wysłaniu spreparowanego żądania.
Zakres: dotyczy gałęzi 3.3 i 3.4 (naprawy w patchach wydanych przez Cisco – patrz niżej). Niezależne biuletyny potwierdzają ścieżki naprawy (3.3 Patch 7, 3.4 Patch 2).
Obserwacje z incydentów: niestandardowy web-shell podszywający się pod komponent ISE, działający w pamięci, z naciskiem na trwałość i stealth.

„Patch-gap” i atak przed publikacją łatek

Amazon opisał wykorzystanie obu podatności jako 0-day jeszcze przed wydaniem łat – klasyczny przykład „patch-gap exploitation” (okno między wykryciem a pełnym rolloutem poprawek). Wnioski: zarządzanie ekspozycją i telemetria/anomalia wygrywają z samą prędkością patchowania.

Praktyczne konsekwencje / ryzyko

Przejęcie dostępu zdalnego i tożsamości
Kradzież ciasteczek/tokenów NetScaler → przejęcie sesji użytkowników/adminów; RCE na ISE → pivot do AD, MDM, VPN, segmentacji NAC.
Trwała obecność i niewidoczność
Web-shelle „osadzone” w ISE, wykonywane w pamięci i maskujące się jako komponenty systemowe. Ryzyko cichego podnoszenia uprawnień oraz lateral movement.
Szeroki blast radius
Atak na warstwę IAM/NAC wpływa na całe środowisko: federacje SSO, dostęp VPN, profile polityk dostępu, integracje z chmurą.

Rekomendacje operacyjne / co zrobić teraz

0) „Assume breach” dla NetScaler i ISE

Skoro obserwowano pre-patch exploitation, traktuj oba urządzenia jak potencjalnie naruszone. Priorytet: skracać ekspozycję i podnosić wierność logowania.

1) Patch & hardening (dziś)

NetScaler (CVE-2025-5777): zaktualizuj do buildów z poprawką i zastosuj konfiguracyjne kroki remediacji (NetScaler Console ma wbudowany 2-etapowy workflow: upgrade + szablon komend). Po aktualizacji wymuś wygaszenie sesji i przeprowadź skan instancji.
Cisco ISE (CVE-2025-20337): zastosuj patche wskazane przez Cisco dla linii 3.3/3.4 (zgodnie z komunikatami CERT/NHS: m.in. 3.3 Patch 7, 3.4 Patch 2). Zweryfikuj brak ekspozycji podatnych API do Internetu.

2) Response po aktualizacji

Unieważnij wszystkie aktywne sesje na NetScalerach (gateway/AAA), zrotuj klucze/sekrety (SAML/OIDC, certyfikaty), zresetuj hasła kont uprzywilejowanych, przeforcesuj re-logon. (Dostarczane przez NetScaler Console mechanizmy ułatwiają masowe działania).
Przegląd konfiguracji ISE: odłącz nieużywane integracje, wprowadź allow-list dla API/management plane (administracja wyłącznie z sieci zarządzania/VPN z MFA).

3) Detections – szybkie reguły dla SOC

Poniższe przykłady są defensywne (bez exploitów):

Splunk (NetScaler – anomalia sesji/admin hijack)

index=netscaler sourcetype=citrix:netscaler:* 
| eval ua=coalesce(http_user_agent, user_agent) 
| stats count dc(src_ip) values(ua) as uas by cs_user, http_cookie 
| where count>1 AND dc(src_ip)>1

Wyszukuje dzielone ciasteczka/sesje z różnych IP (hijack).

Splunk (Cisco ISE – podejrzane wywołania API)

index=cisco_ise sourcetype=cisco:ise:rest
| stats count values(http_method) as m values(uri_path) as up by src_ip, user
| where user="-" OR user="anonymous" OR like(m,"%POST%")

Wykrywa anonimowe POST-y do API.

Sigma (ogólne, do SIEM z HTTP logami)

title: Suspicious Anonymous API Calls to NAC/IAM
logsource: { category: webserver }
detection:
  selection:
    http.status: [200,201,204,500]
    http.verb: POST
    http.user: "-"
    http.path|contains:
      - "/ers/config"      # ISE ERS API
      - "/oauth"           # token endpoints
      - "/nitro/v1/config" # NetScaler NITRO API
  condition: selection
level: high

4) Telemetria i ograniczenie ekspozycji

Zamknij management plane (ACL, bastion, jump host, VPN z MFA).
Włącz HTTP request logging na brzegach (WAF/reverse proxy) i integrację z SIEM.
Monitoruj tokeny (źródła logowania, nagłe zmiany IP/ASN, skoki geolokalizacji).

5) Łączność z chmurą i federacje

Jeśli NetScaler/ISE federuje się z IdP/SSO, rozważ rotację kluczy podpisywania (SAML/OIDC), unieważnienie refresh tokenów i ponowne wymuszenie MFA.

Różnice / porównania z innymi przypadkami

CitrixBleed (2023) vs. „CitrixBleed 2” (2025): w obu przypadkach wyciek pamięci umożliwia przejęcie sesji, ale nowe CVE dotyka nowszych buildów i ponownie wykazuje, że urządzenia brzegowe IAM/VPN są „łakomym kąskiem”.
Cisco ISE RCE wyróżnia się na tle wielu błędów NAC tym, że daje root RCE pre-auth przez API – przez co łańcuch ataku jest krótszy (bez kradzieży kont).

Podsumowanie / kluczowe wnioski

Tożsamość to nowy perymetr – atak na NetScaler i ISE to skrót do całej organizacji.
Okno „patch-gap” jest realne – planuj kompensacyjne kontrole (segmentacja, izolacja zarządzania, wysokiej jakości logowanie) zanim pojawi się łatka.
Po każdej aktualizacji wykonuj czynności post-incident: unieważnienie sesji, rotacje i przegląd anomalii – samo „patch done” nie wystarczy.

Źródła / bibliografia

Dark Reading – opis kampanii i korelacja między Citrix i Cisco ISE. (Dark Reading)
AWS Security Blog (CJ Moses) – szczegóły o pre-patch exploitation i taktykach aktora. (Amazon Web Services, Inc.)
NetScaler Docs – procedura dwuetapowej remediacji CVE-2025-5777 (upgrade + konfiguracja). (docs.netscaler.com)
NVD – szczegóły CVE-2025-20337 (RCE pre-auth w API ISE/ISE-PIC). (NVD)
CERT-EU / NHS – kontekst wersji ISE i rekomendacje patchy (3.3/3.4). (cert.europa.eu)

Intel łata ponad 60 podatności (listopad 2025). Co to oznacza dla Twoich stacji roboczych i serwerów?

Wprowadzenie do problemu / definicja luki

W listopadowym „chipmaker Patch Tuesday” Intel opublikował 30 nowych biuletynów bezpieczeństwa opisujących ponad 60 podatności w szerokim wachlarzu produktów – od procesorów Xeon/Core i narzędzi deweloperskich po sterowniki grafiki, NPU oraz QuickAssist (QAT). Równolegle własne aktualizacje doręczyli AMD i NVIDIA, obejmując m.in. sterowniki XRT (AMD) oraz frameworki AI (NVIDIA NeMo, Megatron, AIStore, Triton). To wydanie łącznie adresuje błędy prowadzące do eskalacji uprawnień, ujawnienia informacji i DoS, a w przypadku części komponentów AI – także potencjalnego wykonania kodu.

W skrócie

Intel: 30 advisory, >60 CVE; wysokie ryzyka m.in. w Xeon/Slim Bootloader/PROSet/CIP/Graphics/QAT; liczne średnio-/niskopoważne błędy w narzędziach użytkowych i SDK.
AMD: 14 CVE w 6 advisory; wysoka powaga m.in. w XRT; StoreMi z EoL – producent nie dostarczy łatek (należy odinstalować).
NVIDIA: 6 CVE w 4 advisory dot. NeMo, Megatron, AIStore, Triton – część z nich umożliwia wykonanie kodu / EoP / ujawnienie danych.

Kontekst / historia / powiązania

Intel publikuje zbiory biuletynów cyklicznie (zwykle kwartalnie) w ramach Intel Product Security Center. Listopadowy zrzut (11 listopada 2025 r.) zawiera serię advisory INTEL-SA-0130x…0136x widocznych na stronie PSIRT, w tym np. INTEL-SA-01328 (CIP). Równolegle pojawiły się aktualizacje mikrokodu CPU dla Linuksa.

Analiza techniczna / szczegóły luki

Najczęściej dotknięte komponenty (Intel):

Procesory Xeon / Slim Bootloader / PROSet / CIP / Graphics / QAT – w części z nich błędy prowadzą do EoP i DoS (wysoka waga). Przykładowo INTEL-SA-01328 (CIP) klasyfikuje wpływ jako EoP/Info Disclosure (severity: HIGH).
Narzędzia i biblioteki (Server Configuration Utility, Display Virtualization, NPU drivers, SigTest, VTune, ITT API, oneAPI MKL, QAT userspace, Gaudi, MPI, PresentMon, Driver & Support Assistant, Rapid Storage Technology) – przeważnie średnie/niskie ryzyko (EoP/DoS/Info Disclosure).

AMD:

Advisory obejmują XRT (Xilinx Run Time), μProf, wybrane Epyc oraz status StoreMi – technologia jest poza wsparciem, brak łatek (zalecane usunięcie).

NVIDIA (AI stack):

NeMo i Megatron (frameworki LLM), AIStore (składowanie aplikacji AI) i Triton Inference Server – biuletyny z listopada 2025 r. naprawiają podatności pozwalające m.in. na wykonanie kodu, EoP i wyciek danych. Przykładowy biuletyn AIStore (listopad 2025): aktualizacja komponentu AuthN.

Praktyczne konsekwencje / ryzyko

Stacje robocze DaaS/VDI i deweloperskie (grafika Intel, narzędzia oneAPI/VTune/ITT, Driver & Support Assistant) – ryzyko lokalnej eskalacji uprawnień oraz ujawnienia informacji przez developer tools.
Serwery bare-metal i wirtualizacja (Xeon, QAT, Slim Bootloader) – potencjalna EoP/DoS może ułatwić pivot z VM do hosta lub zakłócić akceleratory kryptograficzne/kompresyjne (QAT).
Klastry AI/ML (NVIDIA NeMo/Megatron/Triton/AIStore) – błędy w pipeline’ach inferencyjnych/treningowych mogą skutkować RCE w węzłach GPU, sabotażem modeli czy kradzieżą artefaktów.
Dziedzictwo: instalacje z AMD StoreMi – niezabezpieczalne; pozostawienie oprogramowania zwiększa powierzchnię ataku.

Rekomendacje operacyjne / co zrobić teraz

1) Inwentaryzacja i priorytetyzacja

Zbuduj listę hostów z komponentami: Intel Graphics/PROSet/CIP/QAT/VTune/ITT/oneAPI/DSA/RST, Xeon/Core; u AMD – XRT, μProf, StoreMi; u NVIDII – NeMo/Megatron/AIStore/Triton. (Źródła producentów w sekcji na końcu).

Windows (PowerShell – szybkie sprawdzenie wybranych komponentów Intel):

# sterowniki Intel Graphics + wersja
Get-PnpDevice -Class Display | Get-PnpDeviceProperty DEVPKEY_Device_DriverVersion

# Intel Driver & Support Assistant
Get-ItemProperty "HKLM:\SOFTWARE\Intel\Intel(R) Driver & Support Assistant" | Select-Object Version

# Intel PROSet (NIC)
Get-ItemProperty "HKLM:\SOFTWARE\Intel\NetworkServices\PROSet" -ErrorAction SilentlyContinue

# RST (Rapid Storage Technology)
(Get-Item "HKLM:\SOFTWARE\Intel\IAStor*","HKLM:\SOFTWARE\WOW6432Node\Intel\IAStor*").Property

Linux (mikrokod CPU i QAT):

# wersja mikrokodu
dmesg | grep -i microcode
grep microcode /proc/cpuinfo | uniq

# pakiet mikrokodu (Debian/Ubuntu)
apt policy intel-microcode

# sterowniki QAT (przykład)
lsmod | grep -i qat
modinfo qat_4xxx | egrep 'version|vermagic'

2) Aktualizacje / łagodzenia

Intel: zastosuj pakiety z advisory z 11.11.2025 – szczególnie dla CIP (INTEL-SA-01328), Graphics, QAT, PROSet, VTune i komponentów firmware (Slim Bootloader). Sprawdź także dostępność mikrokodu CPU (Linux).
AMD: zaktualizuj XRT do wydania 2025.1+; odinstaluj StoreMi (EoL, brak łatek).
NVIDIA: zaktualizuj NeMo, Megatron, AIStore (AuthN), Triton do wersji wskazanych w biuletynach z listopada 2025 r.

3) Twardnienie i detekcja

W SIEM dodaj korelacje na nieoczekiwane ładowanie sterowników/narzędzi deweloperskich (np. vtune, ittapi, presentmon), eskalację integratorów sterowników (Intel DSA), a w klastrach AI – na nieautoryzowane aktualizacje modelu / pluginów Triton.
W EDR utwardź zasady driver loading i app control dla narzędzi z rodziny oneAPI, QAT i NPU.

4) Testy regresji

W środowiskach z QAT i akceleracją AI wprowadź krótkie testy wydajnościowe po aktualizacji; błędy DoS potrafią maskować się jako „spadki throughputu”.

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

W przeciwieństwie do wielu poprzednich wydań, tym razem ciężar komunikatów NVIDII dotyczy frameworków AI, nie tylko sterowników GPU – to ważne dla zespołów MLOps/AI Platform.
W ekosystemie AMD rzadkim, lecz istotnym przypadkiem jest brak łatek dla StoreMi z racji EoL – konieczna decyzja remove/replace zamiast „patch & continue”.
Intel utrzymuje szeroki zakres – od firmware (Slim Bootloader) po narzędzia deweloperskie – co wymaga zarówno aktualizacji OS/drivers, jak i firmware/BIOS/mikrokodu.

Podsumowanie / kluczowe wnioski

To wydanie jest „szerokospektralne”: dotyka endpointów użytkowników, hostów serwerowych i klastrów AI.
Priorytetyzuj: Intel CIP/Graphics/QAT/PROSet, AMD XRT, usunięcie StoreMi, NVIDIA NeMo/Megatron/AIStore/Triton.
Zadbaj o mikrokod CPU (Linux) i pipeline’y CI/CD dla komponentów AI – błędy w narzędziach deweloperskich i frameworkach to dziś realna ścieżka ataku.

Źródła / bibliografia

SecurityWeek – przekrojowe omówienie tegorocznego „Chipmaker Patch Tuesday” (Intel/AMD/NVIDIA), 12.11.2025. (SecurityWeek)
Intel Product Security Center – lista advisory z 11.11.2025 (m.in. INTEL-SA-01356…01364). (Intel)
Intel INTEL-SA-01328 (Computing Improvement Program – CIP), 11.11.2025. (Intel)
AMD – biuletyn StoreMi (EoL, brak planu łatek). (AMD)
NVIDIA – biuletyn AIStore (AuthN), listopad 2025. (NVIDIA Support)

Microsoft łata aktywnie wykorzystywaną lukę w jądrze Windows (CVE-2025-62215). Co to znaczy dla Twojej organizacji?

Wprowadzenie do problemu / definicja luki

Podczas listopadowego Patch Tuesday (11 listopada 2025 r.) Microsoft załatał aktywnie wykorzystywaną lukę podniesienia uprawnień w jądrze Windows – CVE-2025-62215. To błąd klasy race condition: atakujący, który ma już możliwość uruchomienia kodu w systemie (np. jako zwykły użytkownik), może „wygrać wyścig” i uzyskać uprawnienia SYSTEM, przejmując pełną kontrolę nad hostem. Microsoft potwierdził obserwacje exploitów w atakach w świecie rzeczywistym (szczegóły kampanii nie zostały ujawnione) i przypisał odkrycie MSTIC/MSRC.

Równocześnie opublikowano łatki do ~63 podatności (według BleepingComputer), w tym czterech oznaczonych przez Microsoft jako „krytyczne” (m.in. GDI+/Graphics Component, Office, Visual Studio, Nuance PowerScribe 360).

W skrócie

CVE-2025-62215 (Windows Kernel, EoP) – błąd race condition, pozwala uzyskać SYSTEM po lokalnym wykonaniu kodu; aktywnie wykorzystywany.
Zakres aktualizacji – ok. 63 luk (59 „Important”, 4 „Critical” wg ZDI), z czego 29 to EoP i 16 RCE (zestawienie liczbowo różni się nieznacznie między źródłami, zależnie od tego, czy liczone są też aktualizacje Chromium/Mariner).
Priorytet – traktować jako pilne; typowy łańcuch: zdalny RCE + lokalny EoP (CVE-2025-62215) = pełne przejęcie hosta.
Dodatkowy kontekst – to „lżejszy” miesiąc po październikowej kumulacji (ponad 170 CVE); mimo mniejszej liczby poprawek, ryzyko pozostaje wysokie ze względu na zero-day.

Kontekst / historia / powiązania

Relacje branżowe (SecurityWeek, BleepingComputer, ZDI, Cisco Talos, Qualys) są spójne: mamy jedną potwierdzoną 0-day w kernelu i kilka klas podatności, które często pojawiają się w łańcuchach ataków (Office/GDI+/DirectX/WinSock/CLFS). Talos podaje dla CVE-2025-62215 ocenę CVSS 7.8 i podkreśla „low complexity” przy spełnionych warunkach lokalnego uruchomienia kodu.

Warto odnotować, że Windows 10 przeszedł na ESU (płatne przedłużenie poprawek), co w wielu środowiskach komplikuje zgodność patch-managementu i priorytetyzację.

Analiza techniczna / szczegóły luki

CVE-2025-62215 – Windows Kernel EoP (race condition)

Warunek powodzenia: atakujący musi mieć lokalny dostęp i możliwość wykonania kodu (np. po udanym RCE, makrze Office, sideloadingu DLL, LPE przez sterownik, itp.).
Mechanizm: współbieżny dostęp do współdzielonego zasobu w jądrze bez właściwej synchronizacji umożliwia modyfikację stanu/struktur i eskalację do NT AUTHORITY\SYSTEM po „wygraniu wyścigu”. Microsoft explicite podkreśla, że exploit wymaga „wygrania race condition”.
Łańcuchy ataku w praktyce:
- Phish → Office RCE (np. CVE-2025-62199/62205/62216) → CVE-2025-62215 (EoP) → trwałość (LsaAddAccountRights, usługi, harmonogram) → C2.
- Drive-by/plik graficzny → GDI+ RCE (CVE-2025-60724) → kernel EoP.
- Dev/CI środowiska → VS/Agentic AI RCE (CVE-2025-62214/62222) → kernel EoP.

Inne ważne pozycje (wybór):

GDI+ RCE (CVE-2025-60724, CVSS 9.8) – potencjalnie bez interakcji na serwisach parsujących pliki; bardzo groźne w systemach serwerowych skanujących/konwertujących dokumenty.
DirectX Graphics Kernel EoP (CVE-2025-60716) – również z elementem race condition (Talos: „high complexity”).
CLFS EoP (CVE-2025-60709) – komponent historycznie atrakcyjny dla APT/crimeware (często eksploatowany w poprzednich latach).

Praktyczne konsekwencje / ryzyko

Eskalacja po „pierwszym wstrzyknięciu” – 0-day w kernelu zamyka łańcuch ataku, podnosząc uprawnienia z User do SYSTEM; utrudnia triage, bo telemetrycznie wygląda jak „local exploit”, gdy faktyczny wektor był zdalny.
Ucieczka z kontenerów/aplikacji „piaskownicy” – w środowiskach z AppContainer/WDAG/ciężkim hardeningiem eskalacja do SYSTEM może obejść izolację.
Skutki dla IR/SOC: krótkie okno detekcji; artefakty race condition bywają skąpe; trzeba łączyć alerty z fazy pre-EoP (phish/plik) z nietypowymi zdarzeniami jądra.

Rekomendacje operacyjne / co zrobić teraz

1) Priorytetowe wdrożenie poprawek

Windows (wszystkie wspierane edycje): wdrożyć listopadowe cumulative updates. Zgodnie z relacjami branżowymi aktualizacja łata CVE-2025-62215 oraz inne CVE o wysokim ryzyku (GDI+, Office, DirectX).

PowerShell – szybkie sprawdzenie poziomu łatek na hostach

# ostatnie zainstalowane aktualizacje jakościowe
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 10

# sprawdzenie dostępnych aktualizacji (wymaga PSWindowsUpdate)
Install-Module PSWindowsUpdate -Force
Get-WindowsUpdate -MicrosoftUpdate

# ciche zainstalowanie wszystkich aktualizacji i restart poza godzinami pracy
Install-WindowsUpdate -MicrosoftUpdate -AcceptAll -IgnoreReboot -AutoReboot

Intune – wymuszenie cyklu aktualizacji
Device > Windows > Update rings for Windows 10 and later → Ustaw krótki „Deadline for quality updates” (np. 2 dni) + „Grace period” 0–1 dzień dla krytycznych stacji.

WSUS/SCCM
Zatwierdź „Security Updates” z datą 2025-11-11 dla grup „Pilot” (24–48 h), następnie „Broad” (72–120 h) po smoke-teście zgodności.

2) Weryfikacja wdrożenia

PowerShell – weryfikacja konkretnego KB

# przykładowo sprawdź czy host ma listopadowy CU (KB będzie zależeć od wersji Windows)
$kb="KB5xxxxx"  # wstaw właściwy numer z dokumentacji wydanej dla Twojej wersji
(Get-HotFix -Id $kb -ErrorAction SilentlyContinue) -ne $null

Uwaga: numer KB różni się per wersja (23H2/24H2/25H2/Server). Zweryfikuj dla swojej gałęzi podczas publikacji w MSRC/Release Notes.

3) Wzmocnienie detekcji (MDE/Sysmon/SIEM)

Sysmon – zdarzenia warte korelacji:

Event ID 1/5/7/11 (ProcessCreate, ProcessTerminated, ImageLoaded, FileCreate) dla anomalii wokół win32k, ntoskrnl, sterowników grafiki/CLFS;
Nietypowe wątki w procesach niskoprzywilejowych prowadzące do zmian usług/kluczy LSA.

Microsoft Defender for Endpoint – zapytania KQL (Advanced Hunting):

// Podejrzane podniesienia uprawnień po niedawnym otwarciu dokumentu
DeviceProcessEvents
| where Timestamp > ago(7d)
| where InitiatingProcessFileName in~ ("WINWORD.EXE","EXCEL.EXE","POWERPNT.EXE")
| join kind=inner (
    DeviceProcessEvents
    | where Timestamp > ago(7d)
    | where FileName in~ ("cmd.exe","powershell.exe","rundll32.exe","reg.exe")
) on DeviceId
| project Timestamp, DeviceName, InitiatingProcessFileName, FileName, ProcessCommandLine
| order by Timestamp desc

// Szybka detekcja tworzenia usług po EoP
DeviceRegistryEvents
| where Timestamp > ago(7d)
| where RegistryKey contains @"SYSTEM\CurrentControlSet\Services"
| where InitiatingProcessAccountName !in~ ("SYSTEM","LOCAL SERVICE","NETWORK SERVICE")

4) Twarde ograniczenie wektorów wstępnych (do czasu pełnego patchowania)

Blokada podglądu w Office / Ochrona przed makrami – błąd Office RCE (CVE-2025-62199/62205/62216) może być łączony z EoP; ogranicz Preview Pane i makra z internetu.
Filtrowanie plików graficznych/metafili (GDI+ RCE, CVE-2025-60724) w bramkach, DLP, serwerach konwersji.
WDAC / AppLocker – polityki ograniczające uruchamianie binariów spoza zaufanych ścieżek.
EDR: monitoruj nietypowe TokenElevationType, SeDebugPrivilege, tworzenie usług, modyfikacje LSA/TTY.

5) Zarządzanie ryzykiem w Windows 10 (ESU)

Jeśli utrzymujesz Windows 10, zaplanuj ESU lub migrację do Windows 11; listopadowe łatki są pierwszym cyklem ESU i brak ich wdrożenia otwiera lukę na hostach „legacy”.

Różnice / porównania z innymi przypadkami

Wzorzec „RCE + EoP” jest typowy: w ostatnich latach wiele kampanii łączyło dokument/preview-based RCE (Office/GDI+) z kernel EoP (CLFS/win32k/DirectX). Bieżący zestaw CVE dokładnie wpisuje się w ten schemat.
Dynamika Patch Tuesday: po „ciężkim” październiku (ZDI raportował ~177 CVE) listopad wygląda spokojniej liczbowo, ale jakościowo mamy 0-day w kernelu – więc priorytet pozostaje wysoki.

Podsumowanie / kluczowe wnioski

CVE-2025-62215 to realne, potwierdzone zagrożenie: aktywny exploit + eskalacja do SYSTEM. Potraktuj jako priorytet P0.
Zastosuj listopadowe aktualizacje na Windows/Office/VS/DirectX/GDI+ jak najszybciej, ze szczególnym naciskiem na stacje użytkowników i serwery parsujące dokumenty.
W SOC skup się na korelacji: źródłowe zdarzenie (phish/plik) → nietypowe procesy → trwałość po EoP.
Jeśli masz Windows 10, upewnij się, że włączone są kanały ESU albo przyspiesz migrację.

Źródła / bibliografia

SecurityWeek – „Microsoft Patches Actively Exploited Windows Kernel Zero-Day” (11.11.2025). Potwierdzenie 0-day (CVE-2025-62215), klasa błędu (race condition), zakres miesiąca. (SecurityWeek)
BleepingComputer – „Microsoft November 2025 Patch Tuesday fixes 1 zero-day, 63 flaws” – liczby, lista kategorii, przypisanie MSTIC/MSRC. (BleepingComputer)
Zero Day Initiative – „The November 2025 Security Update Review” – komentarz techniczny, kontekst (liczby, porównanie do października), akcent na łańcuch RCE→EoP. (Zero Day Initiative)
Cisco Talos – „Microsoft Patch Tuesday for November 2025 — Snort rules and prominent vulnerabilities” – CVSS, krytyczne wpisy (GDI+/Office/VS/DirectX), zasady Snort. (Cisco Talos Blog)
Qualys – „Microsoft Patch Tuesday, November 2025 Security Update Review” – podsumowanie kategorii, opisy GDI+/Office/DirectX, potwierdzenie charakteru CVE-2025-62215. (Qualys)

CVE-2025-55177 — WhatsApp (iOS/macOS): niepełna autoryzacja komunikatów synchronizacji urządzeń połączonych

TL;DR

CVE‑2025‑55177 to błąd niepełnej autoryzacji w mechanizmie „Linked devices” WhatsAppa (iOS/macOS), który pozwalał niepowiązanemu napastnikowi wymusić przetwarzanie treści spod dowolnego URL na urządzeniu ofiary. Sam w sobie ma umiarkowane CVSS (5.4), ale w łańcuchu z iOS/macOS ImageIO (CVE‑2025‑43300) mógł prowadzić do zero‑click RCE i instalacji spyware w silnie ukierunkowanych kampaniach. Zalecane: aktualizacja WhatsApp ≥ 2.25.21.73 (iOS) / 2.25.21.78 (Business iOS, Mac), włączenie Lockdown Mode dla użytkowników wysokiego ryzyka, przegląd urządzeń połączonych, telemetria sieciowa dla procesu WhatsApp.

Krótka definicja techniczna

Luka wynika z CWE‑863: Incorrect Authorization – niekompletne sprawdzenia uprawnień dla komunikatów synchronizacji urządzeń połączonych w WhatsApp. Skutkiem było wywołanie przez napastnika przetwarzania zdalnej zawartości (arbitrary URL) na urządzeniu ofiary, co w praktyce umożliwiało „podrzucenie” potencjalnie szkodliwej treści parserom systemowym (np. ImageIO).

Gdzie występuje / przykłady platform

iOS/iPadOS: WhatsApp < 2.25.21.73, WhatsApp Business < 2.25.21.78 (iPhone/iPad).
macOS: WhatsApp < 2.25.21.78.
Inne środowiska (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365): brak bezpośredniego wpływu; obserwacje i detekcje mogą jednak korzystać z SIEM/XDR w tych domenach (np. Microsoft Defender XDR, Elastic). [brak natywnego telemetry w CloudTrail/K8s/M365 dla tej luki]

Szczegółowy opis techniki (jak działa, cele, dlaczego skuteczna)

Mechanizm Linked devices w WhatsApp umożliwia synchronizację danych czatu między urządzeniem głównym a urządzeniami wtórnymi. W CVE‑2025‑55177 brakowało pełnej autoryzacji wiadomości synchronizacyjnych, przez co osoba niepowiązana mogła spowodować, że klient pobrał/przetworzył treść z arbitralnego URL. W połączeniu z CVE‑2025‑43300 (ImageIO) – zero‑day w parserze obrazów Apple – przetworzona treść mogła wyzwolić korupcję pamięci i wykonanie kodu bez interakcji użytkownika (zero‑click), co zaobserwowano w kampanii ukierunkowanej na ograniczoną liczbę ofiar (≤200). Skuteczność wynika z połączenia: (1) braku UI (brak kliknięcia), (2) „legitymizacji” ruchu przez aplikację zaufaną oraz (3) łańcuchowania z podatnością systemową.

Artefakty i logi

Źródło / Artefakt	Platforma	Przykład pól/EID	Co szukać	Ścieżka/Notatka
Unified Logs (OSLog)	macOS	`process`, `eventMessage`, `subsystem`	Wejścia procesu WhatsApp tuż przed crash/alertem, wzmianki o `ImageIO`, nietypowe URL	Przegląd przez Console.app lub `log show`; crashy szukaj w DiagnosticReports.
Crash Reports	macOS	Raport `.crash`	Crashe procesu WhatsApp z ramkami `ImageIO`/`CFNetwork`	`~/Library/Logs/DiagnosticReports/` oraz `/Library/Logs/DiagnosticReports/`.
sysdiagnose / logarchive	iOS/macOS	logarchive	Chronologia zdarzeń WhatsApp/CFNetwork, domeny zdalne	Generowanie sysdiagnose i analiza `system_logs.logarchive`.
Microsoft Defender XDR	macOS/iOS (MTD)	DeviceNetworkEvents (`RemoteUrl`, `InitiatingProcessFileName`)	Połączenia WhatsApp do domen spoza allowlisty (np. .whatsapp.com/.net, .fbcdn.net, *.facebook.com)	Schemat Advanced Hunting.
Elastic / ECS	macOS	`event.category: network`, `process.name`, `destination.domain`	Nietypowe domeny pochodzące od procesu WhatsApp	EQL/Detection rules.
MDM (Jamf/itd.)	iOS	inwentarz wersji app	Wersje < 2.25.21.73/78	Procedury zbierania sysdiagnose / inwentarz aplikacji.
CloudTrail / K8s audit / M365	—	—	Nie dotyczy bezpośrednio (aplikacja kliencka na iOS/macOS)	[brak danych / poza zakresem]

Detekcja (praktyczne reguły)

Uwaga: reguły są defensywne i mają charakter wzorców do tuningu pod własne źródła logów; nie opisują sposobu nadużycia.

Sigma

title: WhatsApp connects to non-owned domains (macOS)
id: 5e7f6c7a-1b0b-4b1a-a1c3-WhatsApp-NonOwnedDomains
status: experimental
description: Detects WhatsApp initiating network connections to domains outside known Meta/WhatsApp CDNs which may indicate CVE-2025-55177 abuse chain.
references:
  - https://nvd.nist.gov/vuln/detail/CVE-2025-55177
  - https://www.whatsapp.com/security/advisories/2025
logsource:
  category: network_connection
  product: macos
detection:
  selection:
    ProcessName|contains:
      - "WhatsApp"
  filter_allowed_domains:
    DestinationDomain|endswith:
      - ".whatsapp.com"
      - ".whatsapp.net"
      - ".fbcdn.net"
      - ".facebook.com"
  condition: selection and not filter_allowed_domains
fields:
  - DestinationIp
  - DestinationPort
  - DestinationDomain
  - ProcessName
level: medium
tags:
  - attack.T1658
  - attack.T1203

Wymagane dopasowanie pól do źródeł w Twoim SIEM; logsource i pola zgodne z konwencją Sigma.

Splunk (SPL)

index=endpoint OR index=network
| eval pname=coalesce(process_name, process, Image, InitiatingProcessFileName)
| search pname="WhatsApp" OR pname="WhatsApp Helper"
| eval domain=coalesce(dest_domain, DestinationHostname, url, RemoteUrl)
| where NOT (like(domain, "%.whatsapp.com") OR like(domain, "%.whatsapp.net")
             OR like(domain, "%.fbcdn.net") OR like(domain, "%.facebook.com"))
| stats values(domain) as domains, dc(domain) as uniq by host, pname, dest_ip, dest_port
| where uniq>0

KQL (Microsoft Defender XDR – Advanced Hunting)

DeviceNetworkEvents
| where InitiatingProcessFileName in~ ("WhatsApp", "WhatsApp Helper")
| where isnotempty(RemoteUrl)
| where not(
    RemoteUrl endswith ".whatsapp.com" or
    RemoteUrl endswith ".whatsapp.net" or
    RemoteUrl endswith ".fbcdn.net" or
    RemoteUrl endswith ".facebook.com")
| summarize count(), make_set(RemoteUrl, 10) by DeviceName, bin(Timestamp, 1h)

Pola i tabela zgodne z dokumentacją DeviceNetworkEvents.

CloudTrail query (AWS CLI/CloudWatch)

Nie dotyczy bezpośrednio. Jeśli jednak Twoja organizacja loguje ruch proxy do CloudWatch (np. ALB/CloudFront), zastosuj CloudWatch Logs Insights dla dzienników HTTP, filtrując UA/hosty procesu WhatsApp — przykład do adaptacji:

fields @timestamp, @message
| filter @message like /WhatsApp/ and not @message like /whatsapp\.com|whatsapp\.net|fbcdn\.net|facebook\.com/
| sort @timestamp desc
| limit 100

Elastic / EQL

network where
  process.name == "WhatsApp" and
  not (destination.domain matches "*.whatsapp.com" or
       destination.domain matches "*.whatsapp.net" or
       destination.domain matches "*.fbcdn.net" or
       destination.domain matches "*.facebook.com")

Składnia i kontekst EQL wg dokumentacji Elastic.

Heurystyki / korelacje

Sekwencja czasowa: (a) nietypowe połączenie WhatsApp → obca domena → (b) crash/restart aplikacji lub wpisy ImageIO/CFNetwork → (c) ostrzeżenia MTD/XDR nt. anomalii. Koreluj w oknie ±5 min.
Kontekst użytkownika: ofiary o profilu wysokiego ryzyka (dziennikarze, NGO, VIP) – priorytet IR. (zero‑click, wysokie TTP APT/komercyjny spyware).
Wersje aplikacji/OS: detekcja urządzeń z wersjami poniżej bezpiecznych buildów WhatsApp i OS‑ów z CVE‑2025‑43300 przed poprawką.

False positives / tuning

Legalne media/CDN’y inne niż .whatsapp. / .fbcdn. mogą generować ruch (np. podgląd linków, załączniki) — dostosuj allowlistę do telemetrii.
Środowiska z TLS inspection / proxy: domena docelowa może być zastąpiona domeną proxy — filtruj po SNI/http_host w logach L7.
Aplikacje towarzyszące (np. komponenty WebKit Network/Helper na macOS) mogą mieć inne nazwy procesu — rozszerz listę InitiatingProcessFileName.
Brak crashy nie wyklucza próby — atak może nie trafić w podatny parser lub warunki wyścigu.

Playbook reagowania (IR)

Triage i ograniczenie ryzyka
- Zidentyfikuj urządzenia z WhatsApp < 2.25.21.73 (iOS) / < 2.25.21.78 (Business iOS, Mac). Wymuś aktualizację.
- Rozważ Lockdown Mode dla użytkowników wysokiego ryzyka (iPhone/iPad/Mac).
- W WhatsApp: przegląd i usunięcie nieznanych urządzeń połączonych (Linked devices).
Zachowanie materiału dowodowego
- Na iOS: wygeneruj sysdiagnose (czas, data) i zabezpiecz logarchive.
- Na macOS: zarchiwizuj Crash Reports i Unified Logs związane z WhatsApp/ImageIO.
Łowy zagrożeń
- Uruchom reguły z sekcji 7 w XDR/SIEM; skoreluj z domenami, które nie należą do Meta/WhatsApp.
Eradykacja i odtworzenie
- Aktualizacje OS ze ścieżki CVE‑2025‑43300 (iOS/iPadOS/macOS), reboot.
- Zresetuj sesje, odśwież tokeny push, rotuj klucze E2E (wylogowanie i ponowne sparowanie urządzeń) — zgodnie z polityką prywatności/ryzyka.
Komunikacja
- Poinformuj użytkowników o incydencie i konieczności aktualizacji; rozważ noty do zespołu prawnego/PR przy potencjalnej ingerencji spyware.

Przykłady z kampanii / case studies

Eksploatacja łańcuchowa: WhatsApp (CVE‑2025‑55177) → Apple ImageIO (CVE‑2025‑43300) → zero‑click na iOS/macOS; ≤200 celów globalnie, profil wysokiego ryzyka.
Potwierdzenie KEV (CISA): luka dodana do Known Exploited Vulnerabilities 2025‑09‑02.
Doniesienia branżowe: vendor advisories i analizy potwierdzają użycie luki w wysoko ukierunkowanych atakach z łańcuchowaniem do CVE‑2025‑43300.

Lab (bezpieczne testy) — przykładowe komendy

Wyłącznie w środowisku testowym / bez symulacji eksploitu. Celem jest weryfikacja widoczności i reguł.

macOS

# Sprawdź wersję aplikacji (App Store build)
mdls -name kMDItemVersion "/Applications/WhatsApp.app"

# Szybki podgląd aktywności procesu w logach z ostatnich 2h
log show --last 2h --predicate 'process == "WhatsApp"' --style syslog | head

# Wykaz bieżących połączeń sieciowych aplikacji
sudo lsof -i -a -c WhatsApp

iOS (bez jailbreak)

Wygeneruj sysdiagnose (kombinacja przycisków zg. z instrukcją Apple), zgraj i załaduj system_logs.logarchive do narzędzia analitycznego.

XDR/SIEM

Uruchom zapytania z sekcji 7 i zweryfikuj, że połączenia do dozwolonych CDN nie generują alertów (tuning allowlisty).

Mapowania (Mitigations, Powiązane techniki)

Mitigations (ATT&CK):

M1051 — Update Software: aktualizacje WhatsApp i OS (iOS/iPadOS/macOS).
M1042 — Disable or Remove Feature or Program: ogranicz lub wyłącz „Linked devices” dla grup wysokiego ryzyka (polityka MDM).
M1021 — Restrict Web‑Based Content: filtrowanie URL/SNI, SSL inspection z ostrożnością, polityki DLP dla mediów.

Powiązane techniki (do rozważenia w polu):

T1071.001 — Web Protocols (C2/Delivery przez HTTP/HTTPS) dla etapów późniejszych lub alternatywnych ścieżek.

Źródła / dalsza literatura

NVD — CVE‑2025‑55177 (opis, CVSS CNA 5.4, CWE‑863, KEV): „Incomplete authorization of linked device synchronization messages…”. (NVD)
CVE.org — rekord (Meta CNA). (CVE)
WhatsApp Security Advisories 2025 (wersje naprawcze; łańcuch z CVE‑2025‑43300). (whatsapp.com)
CISA KEV (dodanie do katalogu 2025‑09‑02). (CISA)
Apple / CVE‑2025‑43300 (ImageIO, out‑of‑bounds write; backporty): wsparcie i NVD. (Apple Support)
Unit 42 (kontekst łańcuchów zero‑click); The Hacker News, SecurityWeek (streszczenia). (Unit 42)
Apple forensics i logi: sysdiagnose / logarchive / Crash Reports (ścieżki). (Apple Podcasts)
ATT&CK Mobile/Enterprise (T1658, T1664, T1203; v18). (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC:

Wdrożone reguły z sekcji 7 (XDR/SIEM) + allowlista domen Meta/WhatsApp.
Raport urządzeń z wersjami WhatsApp < 2.25.21.73/78 i OS bez łatki CVE‑2025‑43300.
Procedura zbierania sysdiagnose/logarchive i Crash Reports gotowa na żądanie IR.
Korelacje: połączenie WhatsApp → obca domena + wpisy ImageIO/crash w ±5 min.

CISO:

Polityka MDM: wymuszona aktualizacja WhatsApp/OS; Lockdown Mode dla wysokiego ryzyka.
Przegląd i ograniczenie Linked devices w organizacji (edukacja + kontrola).
Potwierdzona zgodność z CISA KEV (SLA na patching).
Test stołowy: scenariusz zero‑click na urządzeniach mobilnych (triage + komunikacja).