Archiwa: Admin - Strona 21 z 33 - Security Bez Tabu

CVE-2023-27997 – Krytyczna podatność typu heap‑based buffer overflow w FortiOS/FortiProxy (SSL‑VPN, FortiGate)

TL;DR

  • Co: Pre‑auth RCE w FortiOS/FortiProxy SSL‑VPN (FortiGate) — CVE‑2023‑27997 („XORtigate”).
  • Jak: nadpisanie bufora (heap) poprzez parametr enc w endpointzie /remote/hostcheck_validate, co umożliwia wykonanie kodu bez logowania.
  • Ryzyko: krytyczne, aktywnie wykorzystywane, w KEV (CISA).
  • Naprawa: aktualizacja co najmniej do FortiOS 6.0.17 / 6.2.15 / 6.4.13 / 7.0.12 / 7.2.5 oraz odpowiednie wersje FortiProxy; w razie potrzeby tymczasowo wyłączyć SSL‑VPN.
  • ATT&CK: T1190 (Initial Access). Wskazane korelacje z T1133 (External Remote Services) oraz T1210 (Exploitation of Remote Services) dla ruchu/powykorzystaniowych zachowań.

Krótka definicja techniczna

CVE‑2023‑27997 to błąd heap‑based buffer overflow (CWE‑122/CWE‑787) w komponencie SSL‑VPN FortiOS/FortiProxy umożliwiający zdalne wykonanie kodu na urządzeniu bez uwierzytelnienia poprzez „specjalnie spreparowane” żądania HTTP/HTTPS do publicznego interfejsu VPN.


Gdzie występuje / przykłady platform

  • Network Devices (FortiGate/FortiProxy) — urządzenia brzegowe z włączonym SSL‑VPN. (Matryca ATT&CK obejmuje „Network Devices”).
  • Chmura/edge: gdy FortiGate stoi za ALB/WAF (AWS/Azure/GCP), ślady ataków w logach ALB/WAF/Load Balancer. [Mimo że sama podatność dotyczy urządzenia, telemetria może być w logach chmurowych.]
  • Windows/AD/Azure/M365/K8s/ESXi: pośrednio — jako dalsze cele po początkowym włamaniu (lateral movement), nie jako wektor podatności.

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

Atakujący składa pre‑auth żądania HTTP(S) do portalu SSL‑VPN FortiGate. Kluczową rolę odgrywa endpoint /remote/hostcheck_validate i parametr enc, którego długość i dekodowanie są błędnie weryfikowane. Błąd pozwala na nadpisanie pamięci sterty i w konsekwencji wykonanie kodu. Badanie LEXFO opisuje też zależności od /remote/info (do pobrania „salt”) oraz charakter „XOR‑overflow” wykorzystywany do manipulacji pamięcią. W praktyce umożliwia to początkowy dostęp (Initial Access) i często ominięcie MFA, ponieważ atak następuje przed uwierzytelnieniem.

Fortinet potwierdził krytyczność problemu (FG‑IR‑23‑097), publikując łatki i zalecając niezwłoczną aktualizację; CISA dodała CVE do KEV (Known Exploited Vulnerabilities).


6) Artefakty i logi (tabela)

Źródło/warstwaKluczowe pola / wzorcePrzykładowe wartości / IOCUwagi
FortiGate system/sslvpn logstype=event, subtype=vpn/daemon, msg, service=sslvpn, logid, eventtimeBłędy invalid enc data length, restarty/„sslvpnd daemon crash/watchdog timeoutCrashe/timeouty sslvpnd są sygnałem ostrzegawczym.
FortiGate HTTP/HTTPS accessurl, http_method, status, user="" (pre‑auth), srcipŻądania do /remote/hostcheck_validate z parametrem enc=; skoki 4xx/5xxNajlepiej zbierać jako syslog/CEF do SIEM.
FortiGate Event (log IDs)logid, action, userZalew SSL‑VPN login fail (np. ...user-ssl-login-fail...) lub niestandardowe wzorcePrzydatne do korelacji szumu skanowania z exploitami.
Crashlogdiag debug crashlog readWpisy o sslvpnd, sygnały, restartyMateriał dowodowy na awarie procesu.
ALB/WAF/Reverse Proxyrequest_uri, user_agent, status, bytes/remote/hostcheck_validate, enc=; piki z pojedynczych IPGdy urządzenie stoi za LB/WAF.
Windows EID[nie dotyczy]Bezpośrednio brak artefaktów Windows.
AWS CloudTrail[nie dotyczy]CloudTrail nie rejestruje treści HTTP; szukaj w ALB/WAF (CloudWatch Logs).
K8s audit[nie dotyczy]
M365 audit[nie dotyczy]

Detekcja (praktyczne reguły)

Sigma (FortiGate / proxy logs)

title: FortiGate SSL-VPN hostcheck_validate enc Anomaly (CVE-2023-27997)
id: 4d6f70b0-6b8a-4a3a-9be1-enc-hostcheck
status: experimental
description: Wykrywa żądania do /remote/hostcheck_validate z parametrem enc= (pre-auth) – możliwe wykorzystanie CVE-2023-27997.
references:
  - https://nvd.nist.gov/vuln/detail/cve-2023-27997
  - https://blog.lexfo.fr/xortigate-cve-2023-27997.html
  - https://www.cisa.gov/news-events/alerts/2023/06/13/cisa-adds-one-known-exploited-vulnerability-catalog
tags:
  - attack.t1190
  - cve.2023-27997
logsource:
  category: firewall
  product: fortinet
detection:
  sel_path:
    url|contains: "/remote/hostcheck_validate"
  sel_param:
    url|contains: "enc="
  # alternatywne pola spotykane w CEF/LEEF
  sel_alt1:
    cs-uri-stem|contains: "/remote/hostcheck_validate"
  sel_alt2:
    cs-uri-query|contains: "enc="
  condition: (sel_path and sel_param) or (sel_alt1 and sel_alt2)
fields:
  - src_ip
  - dst_ip
  - url
  - http_method
  - http_status
falsepositives:
  - Starsze klienty FortiClient wykonujące host-check (rzadkie)
level: high

Splunk (SPL)

Wyszukaj podejrzane żądania i skoki błędów:

index=network (sourcetype=fortigate* OR sourcetype=proxy*)
("|/remote/hostcheck_validate" OR cs_uri_stem="/remote/hostcheck_validate")
("enc=" OR cs_uri_query="*enc=*")
| bin _time span=5m
| stats count count(eval(http_status>=400 AND http_status<600)) AS errs
        values(http_method) AS methods
        values(http_status) AS statuses
        by _time, src_ip, dest_ip, uri, user
| where count>=5 OR errs>=3

Crashes sslvpnd (system events):

index=network sourcetype=fortigate:syslog ("sslvpnd" OR "SSL VPN Watchdog" OR "daemon crash")
| stats count latest(msg) AS any_message by _time, host

KQL (Microsoft Sentinel — CommonSecurityLog lub CEF z FortiGate)

let t = 5m;
CommonSecurityLog
| where DeviceVendor =~ "Fortinet"
| where RequestURL has "/remote/hostcheck_validate" and RequestURL has "enc="
| summarize cnt = count(), statuses = make_set(FlexString1) by bin(TimeGenerated, t), SourceIP, DestinationIP, RequestURL
| where cnt >= 5

AWS — CloudWatch Logs Insights (ALB/WAF access logs; nie CloudTrail)

fields @timestamp, @message, httpRequest.clientIp as src
| filter requestURI like /\/remote\/hostcheck_validate/ and @message like /enc=/
| stats count() as hits, countif(elb_status_code like /5\d\d|4\d\d/) as errs by bin(5m), src, requestURI
| filter hits >= 5 or errs >= 3

Elastic (Kibana KQL + EQL)

KQL (HTTP/Proxy index):

url.path : "/remote/hostcheck_validate" and url.query : "*enc=*"

EQL (jeśli parsowane do pól http/url):

sequence by source.ip with maxspan=5m
  [ network where url.path == "/remote/hostcheck_validate" and url.query : "*enc=*" ]
  [ any where process.name == "sslvpnd" and event.action in ("crash","restart") ]

Heurystyki / korelacje

  • Wzorzec żądań: burst żądań do /remote/hostcheck_validate z enc= z pojedynczego IP + wysoki udział 4xx/5xx → koreluj z restartem/crashem sslvpnd w ±5 min.
  • Pre‑auth charakter: brak user w logu, brak sesji, nietypowy User‑Agent (skanery/custom).
  • Post‑exploitation: nagłe utworzenie/zmiana konta admina (np. fortigate-tech-support) lub odczyt konfiguracji — sygnał znany z incydentów wokół CVE‑2023‑27997.
  • Trwałość na urządzeniu: modyfikacje w przestrzeni plików SSL‑VPN (np. katalog językowy) i techniki „symlink” opisywane przez Fortinet jako metoda ukrywania artefaktów po wcześniejszych exploitach — warto hunting.

False positives / tuning

  • Prawdziwe host‑checki starych klientów FortiClient mogą dotykać hostcheck_validate, jednak wolumen jest niewielki i statusy HTTP są zazwyczaj 200/302.
  • Skanery bezpieczeństwa/VAS mogą generować pojedyncze hity.
  • Tuning: whitelisty źródeł administracyjnych, progi wolumetryczne (np. ≥5 w 5 min), statusy ≥400, brak user, nietypowe geolokalizacje/GEO‑ASN.

Playbook reagowania (IR)

  1. Identyfikacja ekspozycji
    • Zbierz listę FortiGate/FortiProxy z włączonym SSL‑VPN i sprawdź wersje (get system status).
    • Jeżeli urządzenie podatne i dostępne z Internetu — podnieś priorytet.
  2. Doraźne ograniczenie ryzyka (jeśli patch niedostępny)
    • Wyłącz SSL‑VPN do czasu aktualizacji (Fortinet wskazuje to jako obejście).
  3. Patch & Verify
    • Zaktualizuj co najmniej do FortiOS 6.0.17 / 6.2.15 / 6.4.13 / 7.0.12 / 7.2.5; FortiProxy do odpowiednich wersji (≥7.2.4 lub ≥7.0.10).
  4. Hunting (±30 dni)
    • Przeszukaj SIEM pod kątem /remote/hostcheck_validate + enc=; wysoki wolumen/4xx/5xx.
    • Sprawdź crashlog/system events (sslvpnd crash/watchdog).
    • Zweryfikuj kontrolę administracyjną: nieautoryzowane konta admin (np. fortigate-tech-support), anomalie w konfiguracji.
  5. Forensyka na urządzeniu
    • Sprawdź katalogi językowe SSL‑VPN pod kątem podejrzanych plików/symlinków (wątek post‑exploitation opisany przez Fortinet).
  6. Remediacja haseł/kluczy
    • Po kompromitacji: rotacja poświadczeń, kluczy VPN, certyfikatów; sprawdź integracje LDAP/Radius.
  7. Hardening
    • Ogranicz ekspozycję panelu/portu VPN do zaufanych adresów; włącz WAF/geo‑IP rate‑limit/DoS‑policy.
  8. Zgłoszenie i lessons learned
    • Odnotuj w rejestrze incydentów; zaktualizuj reguły, dashboardy, runbooki.

Przykłady z kampanii / case studies

  • CISA KEV: CVE‑2023‑27997 dodane 13 czerwca 2023 do katalogu KEV — wymóg szybkiej remediacji.
  • Fortinet PSIRT (06.2023): ograniczone przypadki wykorzystania „in the wild”; zalecenie natychmiastowego upgrade, brak powiązania z Volt Typhoon w dacie publikacji.
  • Raporty branżowe (2024–2025): CVE pojawia się w zestawieniach „routinely exploited”; organy rządowe ostrzegały przed utrzymaną obecnością na FortiOS po patchach (konieczny threat hunting).

Lab (bezpieczne testy)

Tylko w kontrolowanym labie (izolowane FortiGate/FortiProxy). Celem jest detekcja, nie eksploatacja.

  1. Przygotowanie:
    • Urządzenie testowe FortiGate z włączonym SSL‑VPN, wersja podatna (offline, bez Internetu).
    • SIEM (np. Splunk/Elastic/Sentinel) z odbiorem syslog/CEF.
  2. Generowanie normalnego ruchu:
    • Z klienta FortiClient zestaw połączenie → powstaną logi tunnel-up / tunnel-down (do porównania).
  3. Generowanie podejrzanych wzorców (bez exploitów):
    • Wyślij wielokrotne żądania GET do /remote/hostcheck_validate?enc=AA z różnych IP źródłowych (np. z testowych kontenerów) — celem jest wygenerowanie charakterystycznego wzorca URI i 4xx w logach (nie dostarczać Keystream/PoC).
    • Zweryfikuj, czy reguły z pkt 7 aktywują alerty, a dashboardy pokazują piki 4xx/5xx.
  4. Symulacja awarii procesu:
    • (Opcjonalnie) ręcznie zrestartuj usługę SSL‑VPN, aby przetestować korelację z logami „daemon restart/crash” bez wymuszania błędu w pamięci.
  5. Walidacja:
    • Przejrzyj korelacje: burst /remote/hostcheck_validate + restart sslvpnd + brak user + 4xx.

Mapowania (Mitigations, powiązane techniki)

Technika główna: T1190 – Exploit Public‑Facing Application (Initial Access).

Techniki powiązane:

  • T1133 – External Remote Services (VPN jako brama zdalna; logika detekcji dostępowej).
  • T1210 – Exploitation of Remote Services (ew. późniejsze ruchy boczne).

Mitigations (ATT&CK):

  • M1030 — Network Segmentation (DMZ dla usług publicznych).
  • M1035 — Limit Access to Resource Over Network (allow‑list do portalu VPN).
  • M1042 — Disable or Remove Feature or Program (wyłącz SSL‑VPN, jeśli nieużywany).
  • M1050 — Exploit Protection (ochrony przed exploitami, w tym IPS/WAF).
  • M1016 — Vulnerability Scanning (ciągła walidacja wersji).

Źródła / dalsza literatura

  • NVD: opis, wersje dotknięte, CVSS 9.8. (NVD)
  • CISA KEV: dodanie CVE‑2023‑27997 do katalogu (2023‑06‑13). (CISA)
  • Fortinet PSIRT (blog, 12.06.2023): kontekst, zalecenia, brak bezpośredniego powiązania z Volt Typhoon w dacie publikacji. (Fortinet)
  • FortiGuard CVRF FG‑IR‑23‑097: opis, workaround „disable SSL‑VPN”. (FortiGuard)
  • LEXFO (XORtigate): szczegóły techniczne błędu (/remote/hostcheck_validate, enc). (blog.lexfo.fr)
  • Rapid7: wersje naprawcze (6.0.17/6.2.15/6.4.13/7.0.12/7.2.5), IOCs (np. fortigate-tech-support). (Rapid7)
  • Fortinet (04.10.2025): technika symlink post‑exploitation na FortiOS. (Fortinet)
  • Fortinet community: watchdog/crash sslvpnd — jak rozpoznać w logach. (Fortinet Community)

Checklisty dla SOC / CISO

SOC (operacyjna):

  • Alert na /remote/hostcheck_validate + enc= (pre‑auth) z progami wolumetrycznymi.
  • Korelacja z sslvpnd crash/restart i pikami 4xx/5xx.
  • Hunting kont admina (np. fortigate-tech-support) i zmian konfiguracji.
  • Dashboard narażonych wersji (parsing get system status).
  • Logi z ALB/WAF, jeśli FortiGate za load balancerem.

CISO (strategiczna):

  • Patch policy: SLA dla urządzeń brzegowych (≤7 dni dla CVE krytycznych, w KEV).
  • Segmentacja/DMZ dla serwisów publicznych (M1030).
  • Dostęp warunkowy do paneli VPN (M1035/M1042) + geofencing.
  • Testy kontrolne: cykliczne skany podatności (M1016) i symulacje IR.

VPN Hardening Cookbook

Dlaczego to ma znaczenie?

VPN jest bramą do firmowej sieci – ułatwia pracę zdalną, ale dla atakujących stanowi atrakcyjny cel. Wystarczy jedno przejęte konto lub luka w VPN, by intruz zyskał dostęp do zasobów wewnętrznych. Przykładowo, głośny atak na Colonial Pipeline w 2021 rozpoczął się od wykradzionych danych dostępowych VPN bez wymuszonego MFA, co sparaliżowało krytyczną infrastrukturę. To pokazuje, że kompromitacja VPN niesie poważne konsekwencje – od wycieku danych po zatrzymanie działalności firmy.

Czytaj dalej „VPN Hardening Cookbook”

Grafana: luka „admin spoofing” o maksymalnej wadze (CVE-2025-41115) — co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

Grafana Labs poinformowała o krytycznej luce CVE-2025-41115 (CVSS 10.0), która w Grafana Enterprise 12.0.0–12.2.1tylko przy włączonym i skonfigurowanym SCIM (System for Cross-domain Identity Management) — pozwala atakującemu podszyć się pod dowolnego użytkownika, w tym konta administratorów, albo podnieść uprawnienia. Grafana OSS nie jest podatna. Dostępne są aktualizacje bezpieczeństwa: 12.3.0, 12.2.1, 12.1.3, 12.0.6. Usługi zarządzane (Grafana Cloud, Amazon Managed Grafana, Azure Managed Grafana) zostały już załatane.

W skrócie

  • Identyfikator: CVE-2025-41115, CVSS 10.0 (krytyczna).
  • Zakres: Grafana Enterprise 12.0.0–12.2.1 z włączonym SCIM (enableSCIM=true oraz [auth.scim] user_sync_enabled=true). OSS nie jest dotknięta.
  • Skutek: podszycie (impersonation) lub eskalacja uprawnień do poziomu admina.
  • Łatki: z 19 listopada 2025 r. — wydania 12.3.0 / 12.2.1 / 12.1.3 / 12.0.6.
  • Mitigacje doraźne: wyłączyć SCIM, ograniczyć/odciąć klientów SCIM, wymusić rotację ich sekretów, przegląd logów provisioningowych.

Kontekst / historia / powiązania

SCIM wdrożono w Grafana Enterprise i Grafana Cloud w kwietniu 2025 r. w celu automatyzacji cyklu życia tożsamości (provisioning/deprovisioning). Podczas wewnętrznego przeglądu w listopadzie zespół Grafany wykrył błąd mapowania identyfikatorów, przygotował prywatne łatki (5 listopada) i 19 listopada ogłosił publicznie aktualizacje.

Równolegle media branżowe (BleepingComputer, The Hacker News) zwracają uwagę na maksymalną wagę problemu i możliwość pełnego przejęcia instancji przy błędnej konfiguracji SCIM.

Analiza techniczna / szczegóły luki

Sednem podatności jest nieprawidłowe przypisywanie uprawnień w logice SCIM. W określonej konfiguracji Grafana mapowała pole SCIM externalId bezpośrednio do wewnętrznego identyfikatora użytkownika (user.uid). Jeżeli złośliwy (lub skompromitowany) klient SCIM dostarczył wartość numeryczną (np. „1”), mogło to nadpisać wewnętrzne ID i sprawić, że nowo założone konto było traktowane jak istniejące, np. wbudowany administrator. Warunki konieczne do eksploatacji: włączone enableSCIM i [auth.scim] user_sync_enabled.

Wektory CVSS podane przez Grafana wskazują na zdalny (AV:N), bez interakcji użytkownika (UI:N) i bez wymogu uprawnień (PR:N) atak, co tłumaczy bazową ocenę 10.0.

Praktyczne konsekwencje / ryzyko

  • Przejęcie panelu administracyjnego i modyfikacja ról/organizacji.
  • Dostęp do źródeł danych (np. tajne URI, tokeny), możliwość modyfikacji dashboardów i alertów.
  • Lateral movement w środowisku przez poświadczenia i integracje zapisane w Grafanie.
  • Ryzyko zgodności (ekspozycja danych monitoringu/zdrowia systemów).
    Powyższe scenariusze są konsekwencją potwierdzonej możliwości impersonacji użytkowników w tym adminów.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj natychmiast wszystkie wrażliwe instancje Grafana Enterprise do wersji z poprawką: 12.3.0 / 12.2.1 / 12.1.3 / 12.0.6. Zweryfikuj, że środowiska Amazon Managed Grafana / Azure Managed Grafana oraz Grafana Cloud są już bezpieczne (dostarczone poprawki).
  2. Jeżeli nie możesz patchować „od ręki” — wyłącz SCIM: ustaw enableSCIM=false lub w sekcji [auth.scim] user_sync_enabled=false. Zablokuj ruch do endpointów SCIM z wyjątkiem zaufanego IdP.
  3. Rotuj sekrety klientów SCIM oraz odwołaj nieużywane integracje; przejrzyj uprawnienia tokenów.
  4. Przeanalizuj logi provisioningowe i audytowe w okresie od kwietnia 2025 r. do wdrożenia poprawek pod kątem:
    • tworzenia kont ze skrótowymi/numericznymi externalId (np. „1”, „2”, itp.),
    • niespodziewanych zmian ról/organizacji,
    • prób logowania z nowych adresów.
  5. Wymuś ponowną weryfikację członkostw i ról użytkowników „krytycznych” (admin, org admin, właściciele).
  6. Twarde reguły sieciowe: ogranicz dostęp do interfejsów administracyjnych Grafany do sieci zaufanych/VPN; egzekwuj SSO/MFA. (Dobra praktyka niezależnie od tej luki).
  7. Zaktualizuj playbooki IR o scenariusz „SCIM impersonation”, w tym szybkie wyłączenie SCIM i czasową blokadę klientów SCIM.

Różnice / porównania z innymi przypadkami

  • Nie mylić z wcześniejszymi lukami (np. XSS/redirect CVE-2025-4123 z maja 2025 r. lub starszymi problemami z pluginami). Tutaj mówimy o SCIM i mapowaniu tożsamości, co umożliwia bezużytkownikową eskalację zdalną (PR:N, UI:N), stąd CVSS 10.0.
  • W przeciwieństwie do dawnych błędów dot. ścieżek/pluginów, CVE-2025-41115 zależy od konkretnej funkcji (SCIM) i jej konfiguracji — instancje bez SCIM nie są podatne.

Podsumowanie / kluczowe wnioski

  • Jeśli używasz Grafana Enterprise 12.0.0–12.2.1 i masz SCIM włączony — traktuj to jak incydent krytyczny.
  • Patch lub wyłączenie SCIM to dwie najszybsze ścieżki ograniczenia ryzyka.
  • Audyt tożsamości i logów SCIM jest konieczny, by wykryć ewentualną impersonację.
  • Usługi Grafana Cloud i zarządzane przez dostawców chmurowych otrzymały poprawki; Grafana OSS nie jest dotknięta.

Źródła / bibliografia

  1. Grafana Labs — Security update & szczegóły CVE-2025-41115 (19 listopada 2025): patch levels, warunki eksploatacji, timeline. (Grafana Labs)
  2. Grafana Labs — Oficjalny advisory CVE-2025-41115: CVSS 10.0, wektory, wersje naprawione. (Grafana Labs)
  3. BleepingComputer — „Grafana warns of max severity admin spoofing vulnerability” (21 listopada 2025): opis skutków i wymagań konfiguracyjnych. (BleepingComputer)
  4. The Hacker News — „Grafana Patches CVSS 10.0 SCIM Flaw…” (21 listopada 2025): wpływ i kontekst SCIM. (The Hacker News)
  5. runZero — Wykrywanie podatnych instancji (przegląd dla zespołów asset discovery). (RunZero)

Sturnus — nowy trojan bankowy na Androida przechwytuje wiadomości z WhatsAppa, Telegrama i Signal

Wprowadzenie do problemu / definicja luki

Badacze ThreatFabric opisali nową, prywatnie rozwijaną rodzinę Sturnus — trojana bankowego na Androida, który potrafi obchodzić E2EE komunikatorów (WhatsApp, Telegram, Signal), przechwytując treści po odszyfrowaniu na ekranie. Malware łączy klasyczne techniki bankerów (overlaye HTML, keylogging przez Accessibility) z pełnym przejęciem urządzenia (VNC/hVNC) i aktywną obroną przed usunięciem. Wstępna telemetria wskazuje na celowanie w użytkowników instytucji finansowych w Europie Środkowej i Południowej.

W skrócie

  • Co robi: wykrada dane logowania do bankowości, podsłuchuje czaty po stronie urządzenia, zdalnie steruje telefonem, ukrywa aktywność “czarną nakładką”.
  • Status kampanii: funkcjonalny, lecz w fazie rozwoju/testów; na razie niska skala, celowanie regionalne (EU S/CE).
  • Wejście do systemu: dystrybuowany jako fałszywe APK, m.in. podszywające się pod Google Chrome i “Preemix Box”; wektory prawdopodobne: malvertising/DM.
  • Dlaczego E2EE nie pomaga: Sturnus nie łamie kryptografii — czyta ekran/UI po odszyfrowaniu z użyciem Accessibility i zrzutów ekranu/struktury widoków.

Kontekst / historia / powiązania

Sturnus wpisuje się w trend wzrostu możliwości bankerów na Androida (Herodotus, Crocodilus), którzy łączą Device Takeover z precyzyjnymi overlayami i anti-removal. Media branżowe (SecurityWeek, The Record, BleepingComputer, The Hacker News) potwierdzają wczesną, ale zaawansowaną naturę zagrożenia oraz nacisk na Europę.

Analiza techniczna / szczegóły luki

Łańcuch komunikacji i C2

  • Dwukanałowa łączność: HTTP(S) + WebSocket (WSS); rejestracja klienta, wymiana kluczy RSA→AES, a następnie ruch AES/CBC (IV per wiadomość). WebSocket służy m.in. do sesji VNC.

Pozyskiwanie danych

  • Overlaye HTML (repozytorium szablonów w przestrzeni aplikacji) na popularne aplikacje bankowe; JavaScript bridge do natychmiastowej eksfiltracji. Po zebraniu danych overlay dla danej aplikacji bywa wyłączany, by ograniczyć podejrzenia.
  • Keylogging i obserwacja UI przez Accessibility Service (zdarzenia TYPE_VIEW_*, rekonstrukcja drzewa UI), co pozwala odczytywać tekst oraz kontekst ekranów nawet gdy FLAG_SECURE blokuje standardowy screen capture.

Obchodzenie E2EE komunikatorów

  • Monitorowanie aplikacji pierwszoplanowej i automatyczne włączenie kolekcji UI-tree przy WhatsApp/Telegram/Signal. Dane są widoczne “po stronie ekranu” — po odszyfrowaniu przez legalną aplikację. To nie łamie kryptografii, lecz obchodzi jej model zagrożeń poprzez pełne przejęcie hosta.

Zdalne sterowanie (VNC / hVNC)

  • Dwie ścieżki: strumień obrazu (systemowe przechwytywanie ekranu lub fallback przez Accessibility) oraz sterowanie po drzewie UI (kliki, wprowadzanie tekstu, przewijanie, uruchamianie aplikacji, potwierdzania dialogów). Dostępny czarny overlay ukrywający działania operatora.

Utrzymanie i anty-usuwanie

  • Nadużycie Android Device Administrator; wykrywanie prób odebrania uprawnień i automatyczne wycofywanie użytkownika z ekranu ustawień. Do czasu ręcznego cofnięcia uprawnień odinstalowanie (nawet ADB) jest utrudnione. Rozbudowane monitorowanie środowiska (broadcast receivery, stan baterii/SIM/ADB/SELinux/patch level).

Wejście: fałszywe APK

  • Udokumentowane nazwy pakietów dystrybucyjnych to m.in.:
    • com.klivkfbky.izaybebnx (podszywa się pod Google Chrome)
    • com.uvxuthoq.noscjahae (Preemix Box)
      Dystrybucja prawdopodobnie przez malvertising lub bezpośrednie wiadomości z linkami do APK.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla bankowości mobilnej: przejęcie sesji, autoryzacji i potwierdzeń (MFA) w czasie rzeczywistym; możliwość wykonania przelewów podczas “czarnej nakładki”.
  • Ryzyko dla prywatności i zgodności: masowy exfil treści rozmów z E2EE, kontaktów i metadanych; potencjalne naruszenia RODO, tajemnicy bankowej i poufności klientów.
  • Ryzyko dla zespołów SOC/CSIRT: tradycyjne wskaźniki sieciowe mogą być skąpe (custom protokół, AES/WSS); konieczność telemetrii na poziomie urządzenia i korelacji zdarzeń Accessibility/overlay.

Rekomendacje operacyjne / co zrobić teraz

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

  1. Blokada sideloadingu (MDM/Intune/Endpoint Management): wyłącz nieznane źródła instalacji APK; wymuś Google Play Protect.
  2. Polityki uprawnień: audytuj i ogranicz uprawnienia Accessibility (zezwalaj tylko aplikacjom biznesowo uzasadnionym; alerty na nowe zgody).
  3. EDR/Mobile Threat Defense (MTD): wybieraj rozwiązania wykrywające:
    • stałe połączenia WSS do nietypowych domen;
    • intensywne zdarzenia Accessibility i enumerację UI;
    • tworzenie overlayów i długotrwałe “foreground services”.
  4. Higiena MFA: preferuj out-of-band (np. FIDO2/U2F, klucze sprzętowe) zamiast kodów w tej samej przeglądarce/urządzeniu.
  5. Twarde usuwanie: jeśli urządzenie wykazuje symptomy (czarna nakładka, brak możliwości odinstalowania), wejdź do trybu awaryjnego, cofnij Device Admin, następnie odinstaluj; w razie wątpliwości factory reset + odtworzenie zaufanego backupu.
  6. Szkolenia anty-phishingowe: kampanie o fałszywych APK (Chrome/“update systemu”/“Preemix Box”) i malvertisingu.

Dla banków/fintechów

  • Risk-based authentication i detekcje anomalii mobilnych (np. nienaturalne gesty, wzorce VNC, “czarne overlaye”, zmiany Device Admin).
  • App hardening: utrudnianie overlayów, root/jailbreak/emulator detection, “tapjacking protection”, monitorowanie FLAG_SECURE bypass i anomalii Accessibility.
  • Fraud analytics: korelacja telemetrii transakcyjnej z sygnałami z urządzenia (nagłe wyciszenie UI, brak interakcji człowieka, przewijanie skryptowe).

Różnice / porównania z innymi przypadkami

  • W przeciwieństwie do wielu bankerów, Sturnus mocno inwestuje w pełny podwójny kanał C2 (HTTP+WSS) i sterowanie po drzewie UI, co zmniejsza zależność od samego streamingu ekranu i atrybutów wizualnych.
  • Podobnie jak Herodotus/Crocodilus, skupia się na Device Takeover, ale jego monitoring środowiska (SIM/ADB/SELinux/patch level) i rozbudowana obrona Device Admin są ponadprzeciętnie zaawansowane.

Podsumowanie / kluczowe wnioski

Sturnus nie łamie kryptografii E2EE — omija ją, kompromitując host i odczytując to, co widzi użytkownik. Dla obrony oznacza to przesunięcie nacisku z IoC sieciowych na behawior urządzenia: overlaye, nadużycia Accessibility, uprzywilejowania Device Admin i nietypowe sesje WSS/VNC. Wykrycie na wczesnym etapie i dyscyplina instalacyjna (zakaz sideloadingu) będą kluczowe.

Źródła / bibliografia

  1. ThreatFabric — Sturnus: Mobile Banking Malware bypassing WhatsApp, Telegram and Signal Encryption (20 listopada 2025). (ThreatFabric)
  2. SecurityWeek — New Sturnus Banking Trojan Targets WhatsApp, Telegram, Signal Messages (20 listopada 2025). (SecurityWeek)
  3. The Hacker News — New Sturnus Android Trojan Quietly Captures Encrypted Chats and Hijacks Devices (20 listopada 2025). (The Hacker News)
  4. BleepingComputer — Multi-threat Android malware Sturnus steals Signal, WhatsApp messages (20 listopada 2025). (Bleeping Computer)
  5. The Record — New Android malware can capture private messages, researchers warn (20 listopada 2025). (The Record from Recorded Future)

Salesforce bada kradzież danych klientów po incydencie z aplikacjami Gainsight

Wprowadzenie do problemu / definicja luki

Salesforce poinformował o „nietypowej aktywności” dotyczącej aplikacji publikowanych przez Gainsight (partnera z AppExchange), która mogła umożliwić nieautoryzowany dostęp do danych części klientów poprzez zewnętrzne połączenie aplikacji z instancjami Salesforce. W reakcji Salesforce unieważnił wszystkie aktywne access i refresh tokeny powiązane z tymi aplikacjami oraz tymczasowo usunął je z AppExchange na czas śledztwa. Firma podkreśla, że nie chodzi o lukę w samym rdzeniu platformy CRM, lecz o wektor przez integrację z aplikacją zewnętrzną. Źródła branżowe wiążą sprawę z aktywnością grupy ShinyHunters, która miała wykorzystać poświadczenia powiązane z wcześniejszą kampanią Salesloft/Drift.

W skrócie

  • Kiedy: komunikaty Salesforce oraz publikacje branżowe z 20–21 listopada 2025 r.
  • Co się stało: wykryto nietypową aktywność na aplikacjach Gainsight połączonych z Salesforce; możliwy dostęp do danych przez łącze aplikacyjne. Tokeny OAuth/refresh zostały unieważnione, aplikacje tymczasowo wycofane z AppExchange.
  • Skala: BleepingComputer relacjonuje deklaracje ShinyHunters o dostępie do ~285 instancji Salesforce; trwa weryfikacja.
  • Jakie dane: Gainsight wcześniej potwierdzał, że w incydencie powiązanym z Salesloft/Drift dostępne były głównie dane kontaktowe i treści części zgłoszeń wsparcia (bez załączników).

Kontekst / historia / powiązania

W sierpniu–wrześniu 2025 r. doszło do szerokiej kampanii kradzieży danych z instancji Salesforce przez kompromitację integracji Salesloft/Drift i kradzież tokenów OAuth. Wtedy ShinyHunters przypisywało sobie atak na setki firm. Obecny incydent z Gainsight ma podobny profil — wektor przez zaufane połączenie aplikacyjne, nie przez samą platformę Salesforce. Media odnotowują ciągłość taktyk: „przeskakiwanie” między SaaS-ami przez łańcuch integracji i nadmierne uprawnienia aplikacji.

Analiza techniczna / szczegóły luki

Kluczowym elementem jest OAuth oraz refresh tokeny wydawane dla aplikacji zewnętrznych (Connected Apps). Gdy aplikacja ma szerokie zakresy (scopes) i długowieczne refresh tokeny, atakujący, którzy zdobędą którykolwiek z sekretów (token, client secret, zapisane poświadczenia w logach/zgłoszeniach), mogą:

  1. Wydawać nowe access tokeny, nawet po wygaśnięciu poprzednich.
  2. Przeglądać/eksportować dane CRM przez API (np. obiekty Lead, Contact, Case, Opportunity).
  3. Omijać klasyczne kontrole użytkowników (MFA), bo autoryzacja odbywa się jako integracja aplikacyjna.

Salesforce zareagował zgodnie z najlepszą praktyką: całkowita revokacja tokenów dla dotkniętych aplikacji i ich czasowe wycofanie z AppExchange, aby przerwać łańcuch odświeżania. To minimalizuje możliwość dalszego „mintowania” access tokenów z przejętych refresh tokenów.

Praktyczne konsekwencje / ryzyko

  • Ryzyko dla prywatności i zgodności: możliwy wyciek danych klientów B2B (dane kontaktowe, kontekst wsparcia), co uruchamia obowiązki notyfikacyjne (RODO/GDPR) i ryzyka phishingu ukierunkowanego. (Wcześniejsze oświadczenie Gainsight wskazywało właśnie taki profil danych).
  • Ryzyko lateralne w SaaS: jeśli te same kontakty/poświadczenia są używane w innych systemach, możliwe kampanie spear-phishing/smishing na konta zespołów sprzedaży i success.
  • Ryzyko ciągłości działania: doraźne wyłączenie integracji Gainsight może wpływać na procesy CS/CRM, automatyzacje i raportowanie.

Rekomendacje operacyjne / co zrobić teraz

Dla administratorów Salesforce / SecOps:

  1. Inwentaryzuj i tymczasowo ogranicz wszystkie Connected Apps Gainsight (CS, PX, itp.) — sprawdź OAuth scopes, IP Relaxation, Permitted Users, Session Policies.
  2. Wymuś rotację: odłącz i ponownie autoryzuj integracje po oficjalnym przywróceniu; przeprowizjonuj klucze API/sekrety i zmień client secrets po stronie Gainsight.
  3. Przejrzyj logi: Event Monitoring (LoginEvent, ApiEvent, ConnectedAppUsage), Setup Audit Trail, Login History — filtruj po OAuth Client Id Gainsight i anomalie (nietypowe IP/ASN, masowe eksporty, SOQL z SELECT * / LIMIT high).
  4. Zastosuj polityki: High Assurance Sessions dla wrażliwych obiektów, Transaction Security Policies dla masowych zapytań API, MFA/step-up dla administracji integracjami.
  5. Zasada najmniejszych uprawnień: ogranicz scopes i profile integracji; rozdziel instancje/projekty dla środowisk (prod/sandbox).
  6. DLP i monitoring: reguły DLP na eksport CSV/Reports, alerty na nietypową objętość API.
  7. Higiena tokenów: krótszy TTL refresh tokenów, cykliczna rotacja, bez przechowywania sekretów w ticketach/jira/confluence; redakcja danych w zgłoszeniach.
  8. Komunikacja i zgodność: przygotuj notyfikacje do klientów/partnerów (szczególnie w UE), aktualizuj rejestry przetwarzania i oceny DPIA jeśli używasz Gainsight.
  9. Phishing readiness: przeszkol handlowców/CS pod kątem phishingu kontekstowego wykorzystującego realne dane wsparcia.

Różnice / porównania z innymi przypadkami

  • Salesloft/Drift (VIII–IX 2025): masowa kompromitacja tokenów OAuth integracji Drift → dostęp do danych w wielu instancjach Salesforce; nie była to luka w Salesforce, lecz łańcuch dostaw SaaS. Obecny przypadek wygląda podobnie w wektorze (OAuth + integracja), ale dotyczy aplikacji Gainsight i jest świeżo wykrywany/neutralizowany (revokacja tokenów i wycofanie z AppExchange).

Podsumowanie / kluczowe wnioski

  • To nie jest błąd w rdzeniu Salesforce, lecz kompromitacja łańcucha integracji poprzez aplikacje Gainsight.
  • Największym ryzykiem są tokeny odświeżania i szerokie uprawnienia Connected Apps.
  • Natychmiastowa revokacja tokenów przez Salesforce ogranicza skutki, ale zespoły muszą prześwietlić logi, zawęzić scopes i zrotować sekrety.
  • Firmy powinny traktować integracje SaaS jak tożsamości uprzywilejowane i objąć je taką samą dyscypliną bezpieczeństwa jak konta adminów.

Źródła / bibliografia

  • BleepingComputer: oficjalne podsumowanie incydentu i wypowiedzi Salesforce + deklaracje ShinyHunters (20 listopada 2025). (Bleeping Computer)
  • Salesforce Status: komunikat o nietypowej aktywności, revokacji tokenów i czasowym usunięciu aplikacji Gainsight z AppExchange. (status.salesforce.com)
  • Reuters: potwierdzenie dochodzenia Salesforce ws. możliwej ekspozycji danych (21 listopada 2025). (Reuters)
  • TechCrunch: ujęcie techniczno-biznesowe i kontekst wcześniejszej kampanii Salesloft/Drift. (TechCrunch)
  • Gainsight – Security / Alerts: zakres danych z wcześniejszego incydentu i współpraca z Salesforce. (Gainsight Software)

SolarWinds łatka trzy krytyczne luki RCE w Serv-U (CVE-2025-40547/48/49). Zaktualizuj do 15.5.3

Wprowadzenie do problemu / definicja luki

SolarWinds opublikował poprawki dla trzech krytycznych podatności w Serv-U (rozwiązanie MFT/SFTP), które mogą prowadzić do zdalnego wykonania kodu (RCE). Błędy oznaczono jako CVE-2025-40547 (logic error → RCE), CVE-2025-40548 (broken access control → RCE) oraz CVE-2025-40549 (path restriction bypass → RCE). Wszystkie wymagają uprawnień administratora Serv-U do nadużycia, a na Windows ich ryzyko oceniono niżej (z uwagi na domyślne, mniej uprzywilejowane konta usług). Poprawka dostępna jest w wydaniu Serv-U 15.5.3.

W skrócie

  • Wpływ: potencjalne RCE po stronie serwera Serv-U. Wymagane uprawnienia admina w produkcie.
  • Dotyczy wersji: 15.5.2.2.102. Naprawione w 15.5.3 (wydanie z 18 listopada 2025 r.).
  • CVSS: w advisory podano 9.1 (Critical/High); na Windows zaznaczono niższy poziom ryzyka operacyjnego.
  • Dodatkowo: SolarWinds załatał też podatności open redirect i XSS w Observability Self-Hosted (średnia waga).

Kontekst / historia / powiązania

Produkty SolarWinds – w tym Serv-U – były już wcześniej celem ataków; część ich luk widnieje w katalogu CISA Known Exploited Vulnerabilities (KEV), np. CVE-2024-28995 (path traversal w Serv-U). To potwierdza, że błędy w tym ekosystemie bywają szybko wykorzystywane i wymagają pilnych aktualizacji.

Analiza techniczna / szczegóły luki

Poniżej najważniejsze informacje z advisory producenta:

  • CVE-2025-40547 – Logic Abuse → RCE. Błąd logiki, którego nadużycie przez konto administratora Serv-U może skutkować wykonaniem dowolnego kodu. Na Windows ryzyko operacyjne niższe (często mniej-uprzywilejowane konta usług). Dotyczy: 15.5.2.2.102. Naprawa: 15.5.3. CVSS: 9.1.
  • CVE-2025-40548 – Broken Access Control → RCE. Braki w walidacji dostępu; wymagane uprawnienia admina Serv-U. Windows: niższe ryzyko z powodów jak wyżej. Dotyczy: 15.5.2.2.102. Naprawa: 15.5.3. CVSS: 9.1.
  • CVE-2025-40549 – Path Restriction Bypass → RCE. Obejście ograniczeń ścieżek mogące umożliwić wykonanie kodu w obrębie wskazanego katalogu; wymaga uprawnień admina Serv-U. Dotyczy: 15.5.2.2.102. Naprawa: 15.5.3. CVSS: 9.1 (na Windows zaklasyfikowane niżej).

Według notek wydania Serv-U 15.5.3 został opublikowany 18 listopada 2025 r. i stanowi wersję naprawczą dla tych luk.

Praktyczne konsekwencje / ryzyko

Choć nadużycie każdej z luk wymaga konta admina w Serv-U, w praktyce:

  • Lateral movement & post-exploitation: w środowiskach, gdzie napastnik uzyskał już pewne przywileje (np. po kradzieży poświadczeń), podatności te upraszczają eskalację skutków węzła MFT (np. do persistencji lub pivotu).
  • Wpływ na poufność i ciągłość: serwer MFT bywa centralnym punktem wymiany plików; RCE może oznaczać kradzież lub modyfikację transferowanych danych i zakłócenia procesów biznesowych. (Wniosek na podstawie charakteru RCE i roli Serv-U).
  • Ryzyko zgodności: organizacje regulowane (finanse, zdrowie, sektor publiczny) narażone są na niezgodność z wymogami bezpieczeństwa, gdy usterki RCE nie są łatane priorytetowo. (Wniosek ogólny dla klas podatności RCE).

Dodatkowo warto pamiętać, że luki SolarWinds trafiały już do CISA KEV, więc przy braku aktualizacji należy zakładać możliwość szybkiego weaponization przez grupy APT i cybercrime.

Rekomendacje operacyjne / co zrobić teraz

  1. Natychmiast zaktualizuj Serv-U do 15.5.3 na wszystkich hostach (Windows/Linux). Zweryfikuj wersję po aktualizacji.
  2. Przegląd uprawnień: ogranicz liczbę kont admin Serv-U do minimum; włącz MFA/klucze SSH, a tam gdzie możliwe – least privilege dla kont usług. (Dobre praktyki + wskazania advisory nt. mniejszego ryzyka na kontach mniej-uprzywilejowanych).
  3. Telemetria i detekcja: monitoruj procesy Serv-U i katalogi robocze pod kątem anomalii (nieoczekiwane binarki, skrypty, harmonogramy zadań, nowe usługi). Koreluj z logami uwierzytelniania adminów. (Wniosek operacyjny dla RCE).
  4. Segmentacja i hardening: izoluj serwer MFT w wydzielonej strefie, ograniczaj ruch administracyjny (VPN/jump host), wymuś TLS 1.2+/aktualne szyfry. (Wniosek operacyjny).
  5. Threat hunting poaktualizacyjny: sprawdź ślady potencjalnego nadużycia (nietypowe logowania adminów, modyfikacje konfiguracji, nowe eventy/zdarzenia Serv-U) w okresie przed wdrożeniem 15.5.3. (Wniosek operacyjny).
  6. Śledź komunikaty producenta/CISA: jeśli pojawią się sygnały o aktywnej eksploatacji, CISA doda wpisy do KEV – wtedy aktualizacja ma charakter pilny (emergency).

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

  • Wobec CVE-2024-28995 (path traversal, KEV): tegoroczne RCE różnią się wymaganiem PR=High (admin w produkcie), co podbija wpływ po przejęciu konta, ale zmniejsza ryzyko pre-auth. Z kolei CVE-2024-28995 był pre-auth read-only (odczyt plików), lecz z niższymi wymaganiami wstępnymi i został realnie eksploatowany.
  • Wobec wcześniejszych luk w SolarWinds (Orion/Web Help Desk/ARM): ekosystem SolarWinds historycznie przyciąga atakujących, a pojawienie się nowych RCE – nawet z PR=High – należy traktować priorytetowo w środowiskach o podwyższonych wymaganiach zgodności.

Podsumowanie / kluczowe wnioski

  • Trzy luki (CVE-2025-40547/48/49) w Serv-U umożliwiają RCE po stronie serwera, gdy atakujący ma uprawnienia admina Serv-U. Aktualizacja do 15.5.3 jest obecnie jedynym skutecznym remedium.
  • Historia wcześniejszych incydentów i wpisy w CISA KEV dotyczące SolarWinds sugerują, że opóźnianie poprawek znacząco zwiększa ryzyko.

Źródła / bibliografia

  • SecurityWeek: „SolarWinds Patches Three Critical Serv-U Vulnerabilities”, 20 listopada 2025. (SecurityWeek)
  • SolarWinds Trust Center – Advisory: CVE-2025-40547 (Serv-U Logic Abuse – RCE). (SolarWinds)
  • SolarWinds Trust Center – Advisory: CVE-2025-40548 (Serv-U Broken Access Control – RCE). (SolarWinds)
  • SolarWinds Trust Center – Advisory: CVE-2025-40549 (Serv-U Path Restriction Bypass – RCE). (SolarWinds)
  • SolarWinds Documentation – Serv-U 15.5.3 Release Notes (data wydania: 18.11.2025). (SolarWinds Documentation)

7-Zip pod ostrzałem: aktywne ataki na lukę RCE via symlinki (CVE-2025-11001) — co musisz zrobić teraz

Wprowadzenie do problemu / definicja luki

NHS England Digital poinformowało o aktywnym wykorzystywaniu luki w 7-Zip oznaczonej jako CVE-2025-11001. Błąd dotyczy sposobu obsługi symbolicznych linków (symlinków) w archiwach ZIP i może prowadzić do wykonania dowolnego kodu (RCE) po stronie ofiary w określonych warunkach. Luka została naprawiona w 7-Zip 25.00 (Windows), a dodatkowe wzmocnienia mechanizmów symlinków znalazły się w 25.01. Jeśli wciąż używasz wersji < 25.00, jesteś w strefie ryzyka.


W skrócie

  • Status: aktywnie eksploatowana (potwierdzone przez NHS England Digital 18 listopada 2025 r.).
  • Wpływ: możliwość zapisania plików poza docelowym katalogiem podczas rozpakowywania ZIP (directory traversal), co w sprzyjających warunkach prowadzi do RCE.
  • Platforma: praktycznie Windows; exploit wymaga kontekstu uprzywilejowanego (np. usługa/administrator) lub trybu deweloperskiego.
  • Wersje podatne: przedział 21.02–25.00 (wg autora PoC); oficjalnie łatka w 25.00, dalsze utwardzenie w 25.01.
  • Pilne działanie: aktualizacja do 25.00+ (zalecane 25.01+) oraz wdrożenie kontroli bezpieczeństwa opisanych niżej.

Kontekst / historia / powiązania

Zgłoszenie przygotowała Trend Micro ZDI (Ryota Shiga, GMO Flatt Security, z użyciem narzędzia takumi-san.ai). Publiczny advisory ZDI pojawił się 7 października 2025 r. i wskazuje na CVE-2025-11001 (CVSS 7.0) oraz bliźniaczą CVE-2025-11002 — obie związane z obsługą symlinków w ZIP. 7-Zip 25.00 (lipiec 2025) „naprawia błędy i podatności”, a 25.01 (sierpień 2025) dodatkowo modyfikuje kod obsługi symlinków „dla większego bezpieczeństwa” przy ekstrakcji. 18 listopada 2025 r. NHS potwierdziło aktywną eksploatację CVE-2025-11001.


Analiza techniczna / szczegóły luki

Sednem problemu jest niewłaściwe traktowanie linków symbolicznych znajdujących się w archiwum ZIP. Źle przygotowany ZIP może sprawić, że proces rozpakowywania „wyjdzie” poza katalog docelowy i zapisze pliki w miejscach niezamierzonych przez użytkownika (directory traversal). W kombinacji z uruchomieniem 7-Zip w uprzywilejowanym kontekście (np. jako usługa systemowa) taki zapis może prowadzić do nadpisania plików systemowych / ścieżek wykonywalnych, a w konsekwencji do wykonania kodu podczas późniejszego startu procesu/usługi. ZDI klasyfikuje to jako RCE, choć wektor CVSS to AV:L (wymagana lokalna interakcja/wywołanie). Autor publicznego PoC potwierdza, że eksploatacja sensowna jest głównie na Windows i wymaga uprawnień administracyjnych lub kontekstu konta usługi.


Praktyczne konsekwencje / ryzyko

  • Środowiska build/deploy i stacje narzędziowe (Dev/CI/CD), gdzie 7-Zip działa z wyższymi uprawnieniami, są najbardziej narażone. Atak może nadpisać pliki binarne/skrypty uruchamiane później przez pipeline lub usługę.
  • Serwery Windows wykonujące zadania rozpakowywania z uprawnieniami usługi mogą paść ofiarą eskalacji skutków do RCE poprzez „zatruwanie” ścieżek wykonywalnych lub miejsc ładowania DLL. (Wniosek na podstawie mechaniki luki i opisu ZDI.)
  • Użytkownicy końcowi zwykle są mniej zagrożeni pełnym RCE (brak uprzywilejowanego kontekstu), ale wciąż możliwy jest zapis poza docelowym katalogiem, co stanowi naruszenie integralności i wektory dalszych ataków (np. DLL search order hijacking).

Rekomendacje operacyjne / co zrobić teraz

1) Patch natychmiast:

  • Zaktualizuj 7-Zip na wszystkich hostach do ≥ 25.00; praktycznie rekomendujemy 25.01+, gdzie dodatkowo utwardzono logikę symlinków. Zweryfikuj wersję binarnie (hash/inventory), nie tylko deklarację w MDM/CMDB.

2) Hardening i polityki:

  • Na serwerach/agentach CI zabroń uruchamiania 7-Zip z uprawnieniami admin/system, chyba że jest to absolutnie konieczne; uruchamiaj w zwykłym kontekście użytkownika. (Wniosek wynikający z wymagań exploita.)
  • Waliduj pliki ZIP pochodzące z nieufnych źródeł: rozpakowuj do tymczasowych sandboxów i weryfikuj, czy ścieżki nie wychodzą poza katalog docelowy (kontrola normalizacji ścieżek). (Zgodne z opisem mechanizmu ataku.)
  • Jeżeli automatyzujesz ekstrakcję, odrzucaj wpisy będące symlinkami lub prowadzące do ścieżek absolutnych/„..”. (Best practice wynikająca z advisory ZDI.)

3) Detekcja i reagowanie:

  • Szukaj w EDR/SIEM zdarzeń tworzenia symlinków przez procesy 7-Zip oraz zapisu poza katalogiem docelowym w krótkim oknie czasowym po rozpakowaniu ZIP. (Wniosek z opisu wektora.)
  • Koreluj uruchomienia 7zFM.exe/7z.exe w kontekście kont usług (LocalSystem, gMSA, itp.) — to czerwone flagi dla tej luki.
  • Jeśli podejrzewasz nadużycie, sprawdź ostatnie zmiany w ścieżkach autostartu, usługach i katalogach binarnych systemu (np. C:\Windows\System32, katalogi usług). (Wniosek operacyjny zgodny z profilem ataku.)

4) Ograniczenie wektora:

  • Tam, gdzie to możliwe, zastąp wrażliwe zadania rozpakowywania mechanizmem, który ignoruje symlinki lub rozwiązuje je wyłącznie w bezpiecznym jailu (chroot-like/temp). (Dobór kontrolny wynikający z natury podatności.)

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

Istnieje pokrewna podatność CVE-2025-11002 (również CVSS 7.0), która dotyczy tej samej klasy problemów (symlinki w ZIP) i została naprawiona w tym samym wydaniu 7-Zip (25.00). W praktyce program naprawczy jest identyczny: przejście na 25.00+ i stosowanie dobrych praktyk z tej publikacji.


Podsumowanie / kluczowe wnioski

  • CVE-2025-11001 jest w aktywnych kampaniach. Zaktualizuj do 7-Zip 25.01+ i unikać uruchamiania 7-Zip z uprawnieniami admin/usługi.
  • Wektor to symlinki w ZIP + traversal. Największe ryzyko dotyczy środowisk, gdzie 7-Zip działa uprzywilejowanie lub w pipeline’ach automatyzacji.
  • Detekcja: logi tworzenia symlinków, zapisy poza katalogiem docelowym, użycie 7-Zip przez konta usług. Reakcja: weryfikacja krytycznych ścieżek i autostartów. (Wnioski operacyjne spójne z treścią advisory i PoC.)

Źródła / bibliografia

  1. NHS England Digital — Active Exploitation Reported for CVE-2025-11001 in 7-Zip (18 listopada 2025) — potwierdzenie aktywnej eksploatacji i zalecenia. (NHS England Digital)
  2. Trend Micro Zero Day Initiative — ZDI-25-949 / CVE-2025-11001 — opis luki, CVSS, timeline, „fixed in 25.00”. (zerodayinitiative.com)
  3. Trend Micro Zero Day Initiative — ZDI-25-950 / CVE-2025-11002 — podatność pokrewna, ten sam mechanizm i naprawa. (zerodayinitiative.com)
  4. 7-Zip — history.txt — wpisy dla 25.00 (lipiec 2025) i 25.01 (sierpień 2025) wskazujące poprawki i zaostrzenie obsługi symlinków. (7-zip.org)
  5. GitHub (pacbypass) — CVE-2025-11001 PoC — uwagi o wymogach exploita (Windows, kontekst admin/usługi) i zakres wersji podatnych 21.02–25.00. (GitHub)