Archiwa: SIEM - Strona 29 z 46 - Security Bez Tabu

CVE-2019-18935 — Progress Telerik UI for ASP.NET AJAX RCE (RadAsyncUpload / .NET deserialization)

TL;DR

Krytyczna podatność w Telerik UI for ASP.NET AJAX (do 2019.3.1023) pozwala na zdalne wykonanie kodu poprzez niezabezpieczoną deserializację JSON w komponencie RadAsyncUpload, zwykle w kontekście procesu w3wp.exe. Często wymaga znajomości kluczy szyfrujących (np. MachineKey) — możliwych do pozyskania m.in. przez starsze luki CVE‑2017‑11317/11357 — i jest powszechnie wykorzystywana w łańcuchach ataku (CISA KEV). Zalecenie: aktualizacja co najmniej do R1 2020 (2020.1.114), rotacja kluczy, włączenie WAF oraz proaktywna detekcja ruchu do Telerik.Web.UI.WebResource.axd?type=rau i procesów potomnych w3wp.exe.


Krótka definicja techniczna

CVE‑2019‑18935 to luka typu .NET deserialization w RadAsyncUpload (Telerik UI for ASP.NET AJAX), prowadząca do RCE po dostarczeniu specjalnie przygotowanych danych do endpointu m.in. Telerik.Web.UI.WebResource.axd?type=rau. Od wersji 2020.1.114 domyślne ustawienie łagodzi błąd; w 2019.3.1023 istnieje ustawienie niefabryczne ograniczające wektor. Często wykorzystywana łącznie z CVE‑2017‑11317/11357, które ułatwiają pozyskanie kluczy szyfrujących uploadera.


Gdzie występuje / przykłady platform

  • Windows / IIS – typowe środowisko dla aplikacji ASP.NET korzystających z Telerik UI (komponenty front‑end na serwerze).
  • Aplikacje firm trzecich (np. platformy CMS/CRM, jak Sitecore w starszych buildach, które pakowały Telerik UI) – ryzyko pośrednie, gdy komponent jest zależnością.
  • Chmura (IaaS/PaaS) – instancje IIS za ALB/WAF (AWS) lub Application Gateway/WAF (Azure); sama luka jest aplikacyjna, ale ślady widać w dziennikach WAF/ALB.

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

  • Wektor: żądanie HTTP (zwykle POST) do /Telerik.Web.UI.WebResource.axd?type=rau z ładunkiem, który po stronie serwera trafia do deserializacji przez JavaScriptSerializer, umożliwiając wstrzyknięcie obiektu prowadzące do RCE.
  • Warunek sprzyjający: atak jest trivialny, gdy napastnik zna/odzyska klucze szyfrowania uploadera (MachineKey, parametry RadAsyncUpload) — często poprzez wcześniejsze błędy CVE‑2017‑11317/11357 (słaba kryptografia RAU) lub wyciek web.config.
  • Efekt: wykonanie kodu w kontekście IIS Worker Process (w3wp.exe), często skutkujące uruchomieniem cmd.exe/powershell.exe, zrzutem webshella lub ściągnięciem narzędzi.
  • Dlaczego skuteczna:
    1. komponent szeroko rozpowszechniony (często “ukryty” jako zależność),
    2. endpoint RAU bywa rzadko monitorowany,
    3. łatwo ukryć się w normalnym ruchu HTTP(S),
    4. luka jest w KEV, więc aktywnie skanowana/wykorzystywana przez wiele grup.
  • Remediacja producenta: w R1 2020 (2020.1.114) dodano bezpieczne domyślne ustawienia, starsze łatki nie wystarczają — zalecana aktualizacja do ≥ 2020.1.114.

Artefakty i logi

ŹródłoCo szukaćPrzykłady pól / EIDUwaga
IIS W3CŻądania do Telerik.Web.UI.WebResource.axd?type=rau, nietypowe POST z dużym cs-bytes, 4xx/5xx przy próbachcs-uri-stem, cs-uri-query, cs-method, sc-status, time-taken, c-ipACSC wskazuje, że ruch do ...WebResource.axd?type=rau jest wart analizy.
Windows SecurityProcesy potomne w3wp.execmd.exe/powershell.exeEID 4688 (Process Creation)Koreluj z kontem serwisowym aplikacji.
SysmonUtworzenie podejrzanych plików w webroot (np. *.aspx, *.ashx), potomne procesy w3wp.exeEID 1 (ProcessCreate), EID 11 (FileCreate)Szukaj plików w C:\inetpub\wwwroot\ lub App_Data\RadUploadTemp\.
WAF/ALB (AWS)HTTP do ...WebResource.axd z type=rauWAF logs (httpRequest.uri,httpRequest.args)CloudTrail nie loguje treści HTTP — analizuj WAF/ALB.
Azure WAF / AppGWJak wyżejrequestUri_s, requestQuery_s, httpMethod_sWłącz diagnostykę do Log Analytics.
EDR (MDE/Elastic/…)w3wp.exe spawnuje interpreterynazwy procesów, dow. rodz.Wysoka wartość korelacyjna.
K8s audit / M365 UAL / ESXi[nie dotyczy]Aplikacyjna luka .NET na IIS.

Detekcja (praktyczne reguły)

Sigma (IIS – próby RAU)

title: Telerik RAU Endpoint POST Indicative of CVE-2019-18935
id: 7f2a3e27-2e2c-4b8a-9c9f-rau-iis
status: experimental
description: Wykrywa POST na Telerik.Web.UI.WebResource.axd?type=rau (RadAsyncUpload)
references:
  - https://www.cyber.gov.au/.../advisory-2020-004-remote-code-execution...  # ACSC
logsource:
  category: webserver
  product: iis
detection:
  sel_uri:
    cs-uri-stem|contains: 'Telerik.Web.UI.WebResource.axd'
  sel_query:
    cs-uri-query|contains: 'type=rau'
  sel_method:
    cs-method: 'POST'
  condition: sel_uri and sel_query and sel_method
fields:
  - c-ip
  - cs-method
  - cs-uri-stem
  - cs-uri-query
  - sc-status
  - time-taken
falsepositives:
  - Legalny RadAsyncUpload w aplikacjach używających Telerik (zwłaszcza stare wersje)
level: high

Sigma (Windows – potomne procesy w3wp.exe)

title: Suspicious Interpreter Spawned by w3wp.exe
id: e6b6b494-8c6e-4c22-9e63-w3wp-spawn
status: stable
logsource:
  product: windows
  category: process_creation
detection:
  parent:
    ParentImage|endswith: '\w3wp.exe'
  child:
    Image|endswith:
      - '\cmd.exe'
      - '\powershell.exe'
      - '\mshta.exe'
      - '\rundll32.exe'
      - '\cscript.exe'
      - '\wscript.exe'
  condition: parent and child
fields:
  - UtcTime
  - User
  - CommandLine
  - ParentCommandLine
  - Image
  - ParentImage
level: high

Splunk (SPL)

IIS / WAF – próby RAU:

(index=web OR sourcetype=iis* OR sourcetype="aws:waf" OR sourcetype="azure:appgw")
| eval method=coalesce(cs_method, httpMethod_s, httpRequest.httpMethod, method)
| eval uri_stem=coalesce(cs_uri_stem, uri, requestUri_s, httpRequest.uri)
| eval uri_query=coalesce(cs_uri_query, query, requestQuery_s, httpRequest.args)
| search uri_stem="*Telerik.Web.UI.WebResource.axd*" (uri_query="*type=rau*" OR uri_stem="*DialogHandler.aspx*") method=POST
| stats count min(_time) as first max(_time) as last by method uri_stem uri_query src c_ip httpRequest.clientIp sc_status

Windows Security (4688) – potomne interpretery:

source="WinEventLog:Security" EventCode=4688
ParentProcessName="*\\w3wp.exe"
(NewProcessName="*\\cmd.exe" OR NewProcessName="*\\powershell.exe" OR NewProcessName="*\\mshta.exe" OR NewProcessName="*\\rundll32.exe" OR NewProcessName="*\\cscript.exe" OR NewProcessName="*\\wscript.exe")
| stats count by ComputerName, SubjectUserName, ParentProcessName, NewProcessName, CommandLine, ParentCommandLine

KQL (Defender for Endpoint / Azure)

MDE – procesy potomne:

DeviceProcessEvents
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","cscript.exe","wscript.exe")
| project Timestamp, DeviceName, InitiatingProcessAccountName, FileName, ProcessCommandLine, InitiatingProcessCommandLine

Azure WAF / AppGW (Log Analytics):

AzureDiagnostics
| where ResourceType == "APPLICATIONGATEWAYS"
| where requestUri_s has "Telerik.Web.UI.WebResource.axd"
| where requestQuery_s has "type=rau" and httpMethod_s == "POST"
| project TimeGenerated, clientIp_s, httpMethod_s, requestUri_s, requestQuery_s, ruleSetType_s, action_s

CloudTrail / CloudWatch (AWS)

Uwaga: CloudTrail nie rejestruje treści HTTP aplikacji. Do detekcji użyj AWS WAF logs (CloudWatch Logs) lub ALB access logs.
CloudWatch Logs Insights (WAF):

fields @timestamp, httpRequest.clientIp, httpRequest.uri, httpRequest.args, httpRequest.httpMethod, action
| filter httpRequest.uri like /Telerik\.Web\.UI\.WebResource\.axd/ 
  and httpRequest.args like /type=rau/ 
  and httpRequest.httpMethod = "POST"
| sort @timestamp desc
| limit 200

Elastic (KQL/EQL)

HTTP (Elastic APM / ingest):

url.path:"/Telerik.Web.UI.WebResource.axd" and url.query:*type\=rau* and http.request.method:POST

EQL – potomne procesy:

process where process.parent.name == "w3wp.exe" and
        process.name in ("cmd.exe","powershell.exe","mshta.exe","rundll32.exe","cscript.exe","wscript.exe")

Heurystyki / korelacje

  • Korelacja 1: IIS RAU POST(±5 min)w3wp.exe -> cmd.exe/powershell.exe(±5 min) ➜ nowe pliki .aspx/.ashx w webroot.
  • Korelacja 2: Ten sam IP źródłowy generuje wiele 4xx/5xx na RAU i inne ścieżki eksploracyjne.
  • Korelacja 3: Nowe połączenia wychodzące z serwera WWW (który normalnie nie inicjuje ruchu) po RAU‑POST.
  • Korelacja 4: RAU‑POST + znany User‑Agent skanera + rzadkie geolokalizacje.
  • Korelacja 5: W środowiskach z WAF – zdarzenia “allowed but matched rule” dla WebResource.axd + POST.

ACSC i CISA opisują użycie CVE‑2019‑18935 w kampaniach, gdzie po eksploatacji dochodziło do dalszych etapów (webshelle, narzędzia).


False positives / tuning

  • FP: legalne użycie RadAsyncUpload w Twojej aplikacji (stary Telerik), testy QA.
  • Tuning:
    • Ogranicz do method=POST + type=rau.
    • Biała lista znanych klientów (adresy IP, CIDR) lub kont użytkowników aplikacji.
    • Podnieś priorytet, gdy sc-status ∈ {500, 400, 404} lub time‑taken & cs-bytes nienaturalnie duże.
    • W procesach – alertuj tylko, gdy rodzicem jest w3wp.exe i dzieckiem interpreter/skryptor.

Playbook reagowania (IR)

  1. Triage i izolacja: odizoluj host IIS z ruchu wychodzącego (segmentacja/egress filter).
  2. Zabezpieczenie dowodów:
    • zrzut pamięci w3wp.exe i kopia logów IIS/WAF/EDR,
    • kopia webroot (hashy) i web.config.
  3. Szybka analiza:
    • wyszukaj artefakty wg sekcji 6 (procesy potomne, nowe pliki w webroot),
    • przejrzyj żądania ...WebResource.axd?type=rau (czas, źródła).
  4. Eradykacja: usuń webshelle, backdoory, zaplanuj aktualizację Telerik ≥ 2020.1.114, rotację MachineKey, wymuś redeploy.
  5. Hunting w domenie: sprawdź lateral movement od konta serwisowego aplikacji.
  6. Hardening:
    • WAF reguły na RAU, blokada publicznego dostępu do uploadów,
    • minimalne uprawnienia konta aplikacyjnego, App_Data bez exec,
    • monitoring w3wp.exe ➜ interpretery.
  7. Zgłoszenie i lessons learned: KEV/CSIRT, aktualizacja runbooków.

Przydatne polecenia (PowerShell, bezpieczne):

# Nowe pliki skryptowe w webroot z ostatnich 7 dni
Get-ChildItem -Recurse "C:\inetpub\wwwroot" -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-7) } | Select FullName,Length,LastWriteTime

# Procesy potomne w3wp.exe (MDE lub lokalnie)
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 |
  Where-Object { $_.Properties[1].Value -like '*\w3wp.exe' } |
  Select TimeCreated, @{n='NewProcess';e={$_.Properties[5].Value}}, @{n='Cmd';e={$_.Properties[8].Value}}

Przykłady z kampanii / case studies

  • CISA AA23‑074A: aktorzy APT eksploatowali CVE‑2019‑18935 w środowisku rządowym USA (IIS), często łącząc z CVE‑2017‑11317/11357.
  • Blue Mockingbird (Red Canary): w logach IIS widoczny RAU; po eksploatacji uruchamiano cmd.exe/powershell.exe, kończąc na kopaniu kryptowalut.
  • Raporty 2025 (eSentire): luka nadal popularnym wektorem wejścia do dostarczenia reverse shelli i eskalacji uprawnień.
  • ACSC (2020): wskazówki detekcyjne i dowody aktywnej eksploatacji — analiza ruchu do ...WebResource.axd?type=rau.

Lab (bezpieczne testy)

Tylko w odizolowanym środowisku testowym i na załatanych instancjach:

  1. Symulacja hałasu detekcyjnego (IIS/WAF): curl -X POST "https://twoj-serwer.test/Telerik.Web.UI.WebResource.axd?type=rau" \ -H "Content-Type: application/x-www-form-urlencoded" \ --data "probe=1" Sprawdź, czy pipeline logów/warnów (IIS/WAF/SIEM) wyłapuje zdarzenie (bez żadnej próby eksploatacji).
  2. Symulacja anomalii procesów:
    Uruchom prosty skrypt deployu aplikacji, który nie powinien generować w3wp.exe -> cmd.exe. Zweryfikuj, że reguła z 7.2 nie alarmuje (kalibracja FP).
  3. Testy WAF: utwórz regułę blokującą WebResource.axd + type=rau, potwierdź zadziałanie w logach.

Mapowania (Mitigations, Powiązane techniki)

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

Powiązane techniki po eksploatacji:

  • T1505.003 – Web Shell (utrwalenie/remote admin przez .aspx).
  • T1059.001 – PowerShell.
  • T1059.003 – Windows Command Shell.
  • T1105 – Ingress Tool Transfer.

Mitigations (ATT&CK):

  • M1051 – Update Software (patchowanie komponentu do ≥ 2020.1.114).
  • M1050 – Exploit Protection (OS mitigation, hardening, DEP/CFG, itd.).
  • M1037 – Filter Network Traffic (WAF; filtrowanie warstwy 7).
  • M1047 – Audit (systematyczny przegląd konfiguracji i logów).

Źródła / dalsza literatura

  • NVD CVE‑2019‑18935 – opis, wersje, noty o ustawieniach w 2019.3.1023/2020.1.114. (NVD)
  • Telerik KBAllows JavaScriptSerializer Deserialization; Unrestricted File Upload (RAU); rekomendacja upgrade do R1 2020. (Telerik.com)
  • CISA AA23‑074A – kampanie wykorzystujące CVE‑2019‑18935 (IIS w agencji FCEB). (CISA)
  • ACSC 2020‑004 – wskazówki detekcyjne dla ...WebResource.axd?type=rau. (Cyber.gov.au)
  • Red Canary (Blue Mockingbird) – wskazówki huntingowe (IIS + potomne procesy). (Red Canary)
  • Bishop Fox – przegląd techniczny deserializacji w Telerik UI. (Bishop Fox)
  • CISA Top Routinely Exploited Vulns / KEV – kontekst operacyjny i priorytetyzacja. (CISA)
  • MITRE ATT&CK v18 – wersjonowanie i matryca Enterprise. (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC:

  • Reguły na WebResource.axd?type=rau + POST w IIS/WAF/ALB.
  • Korelacja: w3wp.exe → interpretery (cmd/PowerShell/mshta/rundll32).
  • Monitoring nowych plików w webroot (rozszerzenia .aspx/.ashx).
  • Blokady WAF + alerty “match but allow” dla RAU.
  • Threat hunting na źródła z KEV i znane UA skanerów.

CISO / właściciel usługi:

  • Upgrade Telerik ≥ 2020.1.114, weryfikacja zależności pośrednich.
  • Rotacja MachineKey i tajemnic aplikacji po incydencie.
  • WAF w trybie blokującym dla uploadów; brak exec w katalogach upload.
  • Minimalne uprawnienia konta aplikacji IIS.
  • Testy regresyjne i skany zewnętrzne po patchu.

Fluent Bit: 5 nowych luk pozwala przejąć usługi w chmurze (CVE-2025-12969/70/72/77/78)

Wprowadzenie do problemu / definicja luki

Oligo Security opisało łańcuch pięciu podatności we Fluent Bit – popularnym, lekkim agencie telemetrii do logów/metryk/tras – który może prowadzić do przejęcia usług chmurowych. Luki obejmują m.in. path traversal z zapisem plików, przepełnienie bufora w wtyczce Docker, fałszowanie i korupcję tagów oraz bypass uwierzytelniania w protokole forward. Producent wydał poprawki w gałęziach 4.1.x i 4.0.x.


W skrócie

  • CVE-2025-12972 – brak sanityzacji tagów przy generowaniu nazw plików w out_filepath traversal i potencjalny RCE.
  • CVE-2025-12970stack buffer overflow w wejściu Docker przy ekstremalnie długich nazwach kontenerów → DoS/RCE.
  • CVE-2025-12978 – częściowe porównanie Tag_Keyspoofing tagów i obchodzenie filtrów/routingu.
  • CVE-2025-12977 – niewłaściwa walidacja wejścia dla tagów z pól użytkownika → korupcja logów/atak na wyjścia.
  • CVE-2025-12969bypass uwierzytelniania w in_forward, gdy ustawiono tylko Security.Users.
  • Wersje naprawcze: zaktualizuj do Fluent Bit 4.1.1 lub 4.0.12 (LTS) – poprawki backportowane.

Kontekst / historia / powiązania

Fluent Bit jest szeroko wykorzystywany (AI-labsy, bankowość, dostawcy chmury). To nie pierwsze problemy bezpieczeństwa: w 2024 r. głośna była luka CVE-2024-4323 „Linguistic Lumberjack” w wbudowanym serwerze HTTP (DoS/ujawnienie informacji/RCE). Nowy zestaw CVE uderza w inną powierzchnię ataku (tagowanie, plikowe wyjścia, wejścia Docker/forward/Splunk/Elasticsearch) i może być łączony w łańcuchy do pełnego przejęcia pipeline’u logów.


Analiza techniczna / szczegóły luki

1) CVE-2025-12972 – Path traversal w out_file

  • Błąd: tag (często kontrolowany przez klienta) jest używany do budowy nazwy pliku, gdy brak klucza File; brak filtracji ../.
  • Skutek: zapis/nadpisanie dowolnych ścieżek → tampering logów lub RCE (np. przez zapis pliku konfig./skryptu w wykonywalnej lokalizacji).
  • Dotyczy: konfiguracji z dynamicznymi tagami + out_file bez File.

2) CVE-2025-12970 – Przepełnienie bufora w wejściu Docker

  • Błąd: kopiowanie nazwy kontenera do stałego bufora 256B bez weryfikacji długości.
  • Skutek: DoS agenta lub RCE na hostowym procesie Fluent Bit.
  • Warunek: atakujący może utworzyć kontener / wpływać na jego nazwę.

3) CVE-2025-12978 – Częściowe dopasowanie Tag_Key

  • Błąd: porównanie tylko pierwszego znaku klucza pola JSON skonfigurowanego w Tag_Key (HTTP/Splunk/Elasticsearch).
  • Skutek: spoofing tagów, obchodzenie filtrów i przekierowanie strumieni.

4) CVE-2025-12977 – Niewłaściwa walidacja wejścia dla tagów

  • Błąd: tagi tworzone z pól użytkownika omijają sanityzację (wstrzyknięcia znaków sterujących, sekwencji).
  • Skutek: korupcja logów lub ataki na wyjścia downstream.

5) CVE-2025-12969 – Bypass uwierzytelniania w in_forward

  • Błąd: przy konfiguracji tylko Security.Users uwierzytelnianie nie jest egzekwowane; dopiero Shared_Key +/- Security.Users działa poprawnie.
  • Skutek: nieautoryzowana injekcja logów, flood alertów, zatruwanie telemetrii.

Wersje z poprawkami

Wydania 4.1.1 i 4.0.12 zawierają m.in. poprawki: „sanitize incoming Tag to prevent path traversal”, „fix tag_key lookup”, „Fix user authentication…”, „add helper for container name parsing”.


Praktyczne konsekwencje / ryzyko

  • Ukrywanie śladów: nadpisywanie/usuwanie artefaktów w logach oraz przekierowanie do „bezpiecznych” destination.
  • Eskalacja węzłowa: RCE w kontekście agenta → pivot do hosta/pods.
  • Ataki na procesy bezpieczeństwa: zalew fałszywych zdarzeń, zatruwanie źródeł danych SIEM/UEBA.
  • Wpływ na SLO/observability: DoS na agencie → utrata widoczności/monitoringu w krytycznych usługach.

Rekomendacje operacyjne / co zrobić teraz

1) Aktualizacje (priorytet krytyczny)

  • Produkcja: natychmiast 4.1.1 (gałąź 4.1) lub 4.0.12 (gałąź 4.0).
  • Dla obrazów AWS aws-for-fluent-bit: użyj wersji wskazanej przez AWS po migracji do 4.1.1.

2) Twarde zabezpieczenie konfiguracji

  • out_file: zawsze ustawiaj File (konkretna nazwa), nie opieraj nazwy pliku na tagu; rozważ separację katalogów i brak uprawnień do wykonywania.
  • Wejścia HTTP/Splunk/Elasticsearch: ogranicz Tag_Key lub wyłącz dynamiczne tagowanie od klienta; filtruj dopuszczalne wartości (regex allow-list).
  • in_forward: wymuś Shared_Key oraz – jeśli potrzebne – dopiero Security.Users dodatkowo; nigdy Security.Users solo.
  • in_docker: polityka nazw kontenerów (np. długość < 128, zestaw znaków), walidacja po stronie orkiestratora/CI.

3) Redukcja powierzchni ataku

  • Ogranicz dostęp sieciowy do portów wejściowych Fluent Bit (np. HTTP/forward/Splunk/Elasticsearch) do zaufanych CIDR/ServiceAccount/Namespace; w K8s egzekwuj NetworkPolicy.
  • Uruchamiaj agenta z least privilege (read-only FS, no-new-privileges, seccomp, ograniczone capabilities).
  • Oddziel dane/konfigurację w wolumenach nie-wykonywalnych.

4) Monitoring i detekcja (pod rękę dla SOC)

  • Szukaj tagów z ../, znakami sterującymi, nowymi liniami, lub podejrzanie długich nazw kontenerów.
  • Alertuj na nieoczekiwane tworzenie plików przez proces Fluent Bit poza ścieżką docelową (FIM/eBPF).
  • Telemetria: wzrost błędów routingu/tagowania, skoki 5xx w wejściu HTTP, nagłe przełączenia destination.
  • Logika korelacyjna: burst zdarzeń z in_forward bez poprawnego Shared_Key. (zob. opisy błędów i fixów)

5) Hardening łańcucha dostaw

  • „Pin” obrazy Fluent Bit do konkretnych tagów (4.1.1/4.0.12+) i digestów; skanuj SBOM; egzekwuj PodSecurityStandards.

Różnice / porównania z innymi przypadkami

  • vs. CVE-2024-4323 (Linguistic Lumberjack): tam rdzeniem był błąd parsera HTTP i pamięci w serwerze wbudowanym; obecny zestaw uderza w logikę tagów/IO oraz autoryzację i może zostać złączony w łańcuch prowadzący do trwałej manipulacji pipeline’em (m.in. przez out_file).

Podsumowanie / kluczowe wnioski

  • Pięć nowych CVE we Fluent Bit umożliwia RCE, DoS, spoofing tagów i bypass auth – realne ryzyko przejęcia i ukrycia działań atakującego.
  • Patch now: 4.1.1 / 4.0.12 + twarde zasady konfiguracji (File w out_file, Shared_Key w in_forward, ograniczenie Tag_Key).
  • Zaimplementuj monitoring anomalii tagów/plików i politykę nazw kontenerów.
  • Potraktuj agenta logów jako komponent wysokiego ryzyka, nie „neutralną rurę”.

Źródła / bibliografia

  1. SecurityWeek – omówienie 5 CVE, wersje naprawcze i wpływ na chmurę. (SecurityWeek)
  2. Oligo Security – raport techniczny z PoV, wektory ataku i porady. (Oligo Security)
  3. GitHub (Fluent Bit v4.1.1) – changelog zawierający poprawki: sanitacja tagów, fix tag_key, auth w in_forward, zmiany dla Docker. (GitHub)
  4. Fluent Bit – Release Notes v4.0.12 (gałąź 4.0.x z backportami poprawek). (fluentbit.io)
  5. The Hacker News – dodatkowy kontekst i wpływ (RCE, DoS, manipulacja tagami). (The Hacker News)

CrowdStrike: „insider” pomógł przestępcom sfabrykować rzekome włamanie. Co naprawdę się stało?

Wprowadzenie do problemu / definicja incydentu

CrowdStrike potwierdził, że rozwiązał współpracę z „podejrzanym insiderem”, który udostępnił przestępcom zrzuty ekranu ze swojego firmowego komputera. Obrazy (m.in. panel Okta SSO) trafiły na kanał Telegram grupy „Scattered Lapsus$ Hunters” i zostały wykorzystane do fałszywego sugerowania włamania do systemów CrowdStrike. Firma zaprzecza jakiejkolwiek kompromitacji oraz informuje, że sprawę przekazano organom ścigania.

W skrócie

  • Nie było włamania do systemów CrowdStrike – to, co obiegło media społecznościowe, to zrzuty ekranu udostępnione przez osobę z dostępem, a nie ślady intruzów w infrastrukturze.
  • Insider miał sprzedać zrzuty i – według relacji przestępców – oferować ciasteczka SSO; pada kwota 25 000 USD. CrowdStrike utrzymuje, że dostęp insidera został wcześniej zablokowany.
  • Hakerzy wiązali tę sprawę z rzekomym łańcuchem nadużyć wokół Gainsight/Salesforce, co firma określiła jako nieprawdziwe w kontekście CrowdStrike.

Kontekst / historia / powiązania

„Scattered Lapsus$ Hunters” to sojusz znanych grup (m.in. ShinyHunters, Scattered Spider i Lapsus$) nastawionych na socjotechnikę, wyłudzanie dostępów i ekshibicjonizm medialny. W ostatnich miesiącach przypisywali sobie fale kradzieży danych u klientów ekosystemu Salesforce i prowadzili głośne publikacje „dowodów” na Telegramie. W tym samym nurcie znalazła się narracja o Gainsight, która miała posłużyć do zbudowania wiarygodnej — ale w tym przypadku fałszywej — historii o kompromitacji CrowdStrike.

Analiza techniczna / szczegóły incydentu

Co pokazują zrzuty? Według opisów mediów, obrazy przedstawiały wewnętrzne pulpity i link do panelu Okta SSO, czyli punktu wejścia do aplikacji wewnętrznych. Same w sobie nie stanowią dowodu intruzji, a jedynie potwierdzają, że autor zrzutów miał autoryzowany dostęp (insider). To klasyczny przykład, gdy artefakt wizualny zostaje użyty jako narzędzie dezinformacji.

Wątek ciasteczek SSO i dostępu: Przestępcy twierdzili, że otrzymali ciasteczka uwierzytelniające SSO i próbowali kupować dodatkowe materiały (np. raporty dotyczące samych grup). BleepingComputer zaznacza, że zanim doszło do eskalacji, CrowdStrike już zidentyfikował insidera i odciął dostęp. To ograniczyło potencjalne skutki operacyjne.

Czym to nie jest: Brak potwierdzeń o ruchu lateralnym, wyciekach danych klientów czy uruchamianiu złośliwego kodu w środowiskach CrowdStrike. Firma konsekwentnie podkreśla brak kompromitacji systemów.

Praktyczne konsekwencje / ryzyko

  • Reputacyjne i rynkowe ryzyko „teatru włamania”: pojedyncze obrazki z paneli wewnętrznych mogą posłużyć do budowania fałszywych narracji o hacku, wywołując presję na ofiarę i jej klientów.
  • Ryzyko insiderów: nawet bez „prawdziwego” włamania, niewłaściwe ujawnienie widoku systemów (UI, nazwy zasobów, integracje) może ułatwiać przyszły OSINT, phishing ukierunkowany i sprzęganie socjotechniki (np. pod Okta/SSO).
  • Eskalacja przez łańcuch dostaw: równoległe kampanie przeciw organizacjom w ekosystemie Salesforce/Gainsight pokazują, że kontekst third-party bywa wykorzystywany do uwiarygadniania fałszywych roszczeń wobec firm trzecich.

Rekomendacje operacyjne / co zrobić teraz

  1. Twarde higieny SSO/IdP (Okta/ADFS/Azure AD):
    • Wymuś MFA odporne na phishing (FIDO2/WebAuthn, klucze sprzętowe).
    • Włącz reauth przy wrażliwych akcjach i krótkie TTL dla ciasteczek sesyjnych.
    • Ustaw detekcję anomalii sesji (geolokacja, nietypowe urządzenia, „impossible travel”).
  2. Program Insider Threat (HR + SecOps + Legal):
    • Sygnalizacja behawioralna w EDR/SIEM (masowe zrzuty ekranu, nietypowe narzędzia, przesyłki do komunikatorów).
    • Zasada najmniejszych uprawnień + szybkie offboarding i rotacja tokenów po zmianach personalnych.
  3. DLP i kontrola ekranu:
    • Blokady/ostrzeżenia dla narzędzi przechwytywania ekranu na stacjach z dostępem do systemów krytycznych.
    • Znak wodny i tagowanie środowiska (by łatwiej identyfikować źródło wycieku obrazów).
  4. Playbook na „fałszywe włamanie”:
    • Procedura szybkiego dementi z faktami technicznymi (czasy, zakres, brak IOC), koordynacja z PR i prawnikami.
    • Zabezpieczenie dowodów i notyfikacja organów ścigania – nawet jeśli incydent nie spełnia progu „breach”.
  5. Monitoring łańcucha dostaw (SaaS-to-SaaS):
    • Inwentaryzacja integracji (np. Gainsight/Salesforce) i warunkowe tokeny z minimalnymi scopes.
    • Kontrole kontraktowe: obowiązkowe MFA, logowanie, czasowe klucze, testy socjotechniki u dostawcy.

(Rekomendacje wynikają z charakteru incydentu opisanego w źródłach oraz dobrych praktyk zarządzania tożsamością i zagrożeniami insiderskimi).

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

  • Prawdziwe naruszenie: ślady włamywacza w telemetrii (IOC/TTP), nieautoryzowane sesje, exfiltracja, zmiany konfiguracyjne.
  • „Teatr włamania” (jak tutaj): autoryzowane ekrany sfotografowane przez insidera + narracja przestępców (np. „wykorzystaliśmy Gainsight”), bez potwierdzonych śladów w systemach ofiary. Takie operacje mają cel propagandowy i wymuszeniowy.

Podsumowanie / kluczowe wnioski

  • Sprawa CrowdStrike to insider misuse, a nie „external breach”. Zrzuty ekranu stały się narzędziem dezinformacji.
  • Sojusze typu „Scattered Lapsus$ Hunters” budują wiarygodne opowieści wokół realnych kampanii (np. Gainsight/Salesforce), by windować presję i żądania — nawet jeśli fakty nie potwierdzają ich roszczeń wobec konkretnej firmy.
  • Dyscyplina tożsamości (SSO/MFA), programy Insider Threat i playbook komunikacyjny to dziś obowiązkowe elementy cyberodporności.

Źródła / bibliografia

  • SecurityWeek: potwierdzenie działań CrowdStrike, opis zrzutów, dementi kompromitacji. (SecurityWeek)
  • TechCrunch: oświadczenie rzecznika CrowdStrike, kontekst Gainsight/Salesforce, charakter zrzutów. (TechCrunch)
  • BleepingComputer: szczegóły o rzekomej płatności 25 tys. USD i ciasteczkach SSO, tło „Scattered Lapsus$ Hunters”. (BleepingComputer)
  • CSO Online: zwięzłe potwierdzenie kluczowych faktów i odwołanie do materiału TechCrunch. (CSO Online)


Microsoft ostrzega: agentowe funkcje AI w Windows 11 wprowadzają nowe ryzyka bezpieczeństwa

Wprowadzenie do problemu / definicja luki

Microsoft rozpoczął testy eksperymentalnych funkcji agentowych w Windows 11 (m.in. agent workspace i Copilot Actions). Firma jednocześnie ostrzega, że nieprawidłowe zabezpieczenie agentów może przynieść więcej szkód niż korzyści—w tym eksfiltrację danych i instalację złośliwego oprogramowania. Funkcje te są wyłączone domyślnie i przeznaczone dla świadomych ryzyk użytkowników/administratorów.

W skrócie

  • Agent workspace to odizolowana przestrzeń systemowa, w której agent działa na własnym koncie i z ograniczonym dostępem do plików/aplikacji; dostęp rozszerzany jest wyłącznie za zgodą użytkownika.
  • Najistotniejsze nowe wektory to cross-prompt injection (XPIA), błędy uprawnień oraz brak containmentu działań agenta. Microsoft definiuje zasady bezpieczeństwa i prywatności (m.in. least privilege, nadzór i audyt niepodważalny) jako warunek korzystania z funkcji.
  • Copilot Actions zaczęło trafiać do Windows Insiders 17 listopada 2025 r. i korzysta z agent workspace do działań na lokalnych plikach.
  • Windows wzmacnia także warstwę protokołu Model Context Protocol (MCP)—z kontrolami proxy, autoryzacją narzędzi i wymogiem podpisu kodu—aby ograniczać ryzyka agentów i „tool poisoning”.

Kontekst / historia / powiązania

Artykuł SecurityWeek z 24 listopada 2025 r. podsumowuje komunikaty Microsoftu: agent workspace działa w osobnej sesji Windows równolegle do sesji użytkownika, a włączenie funkcji tworzy konta agentów i umożliwia aplikacjom agentowym (np. Copilot) żądanie dostępu do folderów użytkownika (Dokumenty, Pobrane, Pulpit, Muzyka, Obrazy, Wideo).
Dokumentacja Microsoftu (zaktualizowana 17–18 listopada 2025 r.) rozwija zasady bezpieczeństwa, transparentności i kontroli użytkownika, a wpis na Windows Insider Blog potwierdza stopniowy rollout Copilot Actions w kanale Insider.
Równolegle, w maju 2025 r. Microsoft ogłosił wzmacnianie MCP jako warstwy interoperacyjnej dla agentów—z akcentem na proxy egzekwujące polityki, audyt i centralny rejestr serwerów MCP spełniających kryteria bezpieczeństwa.

Analiza techniczna / szczegóły luki

Izolacja i tożsamość

  • Każdy agent działa na oddzielnym koncie standardowym; umożliwia to odrębne polityki i jasne granice uprawnień. Działania agenta są odróżnialne od działań użytkownika.
  • Agent workspace to „lekka” sesja równoległa, zapewniająca runtime isolation i ograniczoną widoczność pulpitu użytkownika; efektywniejsza niż pełna maszyna wirtualna, ale oparta o uznane granice bezpieczeństwa Windows.

Uprawnienia i dostęp do danych

  • Dostęp do plików jest grantowany explicite; początkowo agent może sięgać tylko do znanych folderów użytkownika i zasobów dostępnych dla wszystkich kont. Rozszerzenia wymagają autoryzacji.

Nadzór i audyt

  • Microsoft wymaga możliwości nadzoru planu i kroków agenta, dodatkowych potwierdzeń przy wrażliwych operacjach oraz logów odpornych na manipulacje (tamper-evident audit log).

Nowe wektory ataku (przykłady)

  • Cross-Prompt Injection (XPIA): złośliwa treść w dokumentach/elementach UI może nadpisać instrukcje agenta i skutkować np. eksfiltracją danych lub instalacją malware.
  • Tool/MCP poisoning i luki autoryzacji: niezweryfikowane serwery MCP, słabe uwierzytelnienie lub wycieki poświadczeń agenta mogą prowadzić do przejęcia pełnej kontroli (RCE) przez błędnie zdefiniowane narzędzia.

Praktyczne konsekwencje / ryzyko

Dla SOC/Blue Team oznacza to nową klasę „użytkowników nie-ludzkich” działających w systemie i wykonujących akcje na danych lokalnych, aplikacjach i usługach. Błędy konfiguracji (zbyt szerokie uprawnienia), brak audytu lub brak rozdzielenia tożsamości mogą umożliwić:

  • eskalację uprawnień przez agenta lub jego narzędzia,
  • nieautoryzowany dostęp do danych wrażliwych i ich wypływ,
  • trwałą persystencję i lateral movement w sieci przez łańcuch agent → narzędzie → aplikacja.
    Ryzyka te Microsoft samodzielnie wymienia jako kluczowe i adresuje mechanizmami least-privilege, kontroli użytkownika i izolacji w Windows 11.

Rekomendacje operacyjne / co zrobić teraz

  1. Włączaj funkcje agentowe tylko celowo (domyślnie są wyłączone). Zanim włączysz „Experimental agentic features”, zdefiniuj scopingi uprawnień i ownera agenta.
  2. Tożsamość i dostęp
    • Traktuj konta agentów jak konta techniczne: least-privilege, brak praw admina, TTL dla przyznanych dostępów, regularny przegląd ACL.
  3. Segmentacja i hardening
    • Ogranicz dostęp agent workspace do minimalnego zestawu folderów/aplikacji; rozważ aplikacje instalowane „per-user”, by nie dziedziczyły ich wszystkie konta.
  4. Nadzór i audyt
    • Wymuś HITL dla wrażliwych operacji; integruj logi agenta z SIEM; ustaw alerty na działania wysokiego ryzyka (masowe kopiowanie/archiwizacje, instalacje binariów, modyfikacje polityk).
  5. Higiena treści i XPIA
    • Skany i sanitizacja otwieranych przez agentów dokumentów/stron; ogranicz automatyczne wykonywanie „planów” na treściach pochodzących z niezaufanych źródeł. (Microsoft podkreśla XPIA jako zagrożenie nr 1 dla agentów).
  6. Łańcuch narzędzi (MCP)
    • Dopuszczaj wyłącznie podpisane i zweryfikowane serwery MCP; egzekwuj autoryzację client–tool i rejestrowanie akcji przez warstwę proxy. Unikaj „dzikich” narzędzi bez deklaracji uprawnień.
  7. Testy bezpieczeństwa
    • Zaplanuj red teaming agentów: scenariusze XPIA, „tool poisoning”, wycieki tokenów; testuj przechwytywanie i weryfikację działań przez audyt.

Różnice / porównania z innymi przypadkami

W porównaniu z klasycznymi asystentami (bez zdolności działania w systemie) oraz z automatyzacjami typu RPA, agenci Windows:

  • działają bliżej powierzchni ataku endpointu (klikają, piszą, przewijają jak użytkownik),
  • operują w osobnej sesji i na odrębnym koncie (co daje lepszy containment niż typowe uruchamianie pod kontem użytkownika),
  • wspierają centralne zasady (proxy MCP, podpis kodu, rejestr serwerów), co zbliża je do modeli „zero trust” dla narzędzi.

Podsumowanie / kluczowe wnioski

  • Agentowe AI w Windows 11 to duży skok funkcjonalny—i równie duży skok ryzyka.
  • Microsoft dostarcza ramy bezpieczeństwa: izolacja sesji, osobne konta, least-privilege, autoryzacja, audyt—ale konfiguracja i governance pozostają po stronie organizacji.
  • Kluczem jest świadome włączenie funkcji, ścisłe scope’owanie uprawnień, monitoring i testy ofensywne pod kątem XPIA i łańcucha narzędzi.

Źródła / bibliografia

  1. SecurityWeek — Microsoft Highlights Security Risks Introduced by New Agentic AI Feature (24 listopada 2025). (SecurityWeek)
  2. Microsoft Support — Experimental Agentic Features (akt. 17 listopada 2025). (Microsoft Support)
  3. Microsoft Learn — Securing AI agents on Windows (akt. 18 listopada 2025). (Microsoft Learn)
  4. Windows Experience Blog — Securing the Model Context Protocol (19 maja 2025). (Windows Blog)
  5. Windows Insider Blog — Copilot Actions begins rolling out to Windows Insiders (17 listopada 2025). (Windows Blog)

WhatsApp: luka w API pozwoliła zeskrobać 3,5 mld kont. Co to oznacza dla prywatności?

Wprowadzenie do problemu / definicja luki

Zespół badawczy z Uniwersytetu Wiedeńskiego wykazał, że mechanizm contact discovery w WhatsApp (czyli sprawdzanie, czy dany numer jest zarejestrowany) można było automatycznie „odpytywać” na masową skalę, bez skutecznych limitów zapytań. To umożliwiło enumerację numerów i zbudowanie katalogu ok. 3,5 mld kont wraz z publicznie dostępnymi metadanymi profili (np. zdjęcie, opis „O mnie”, znacznik konta firmowego). Meta (właściciel WhatsAppa) po zgłoszeniu wprowadziła dodatkowe ograniczenia tempa zapytań (rate limiting).

W skrócie

  • Zakres: możliwa enumeracja ~3,5 mld numerów powiązanych z kontami WhatsApp i pobranie publicznych danych profili.
  • Wektor: nadużycie funkcji contact discovery przez automatyczne testowanie dużych zakresów numerów (brak skutecznego rate limiting).
  • Status naprawy: Meta wdrożyła dodatkowe zabezpieczenia po zgłoszeniu badaczy.
  • E2EE: Szyfrowanie wiadomości end-to-end nie zostało złamane, ale ekspozycja numerów i metadanych zwiększa ryzyko nadużyć (phishing, doxing, OSINT).

Kontekst / historia / powiązania

Enumeracja poprzez „sprawdzanie dostępności” numeru to znany problem projektowy w aplikacjach opartych o telefon jako identyfikator. Podobne zjawiska obserwowano w przeszłości w innych komunikatorach i serwisach społecznościowych; ostrzegano też, że telefon jako główny identyfikator ułatwia łączenie tożsamości i tworzenie baz OSINT. Sprawa WhatsAppa jest jednak wyjątkowa skalą — badacze mówią o „najszerszej ekspozycji numerów telefonów w historii”.

Analiza techniczna / szczegóły luki

Badacze generowali i testowali masowo zakresy numerów telefonów z wielu krajów. Każde zapytanie do mechanizmu contact discovery pozwalało ustalić, czy numer jest kontem WhatsApp — a jeśli tak, zaciągnąć publicznie udostępnione dane profilu (np. avatar, opis, znacznik „Business”), znaczniki czasu i inne elementy. Brak twardych limitów zapytań umożliwiał bardzo szybkie tempo enumeracji. Po odpowiedzialnym ujawnieniu Meta uszczelniła ograniczenia (rate limiting), utrudniając masowe skanowanie.

Dlaczego to działa?

  • WhatsApp musi odpowiedzieć, czy kontakt istnieje — inaczej nie da się wygodnie budować list znajomych.
  • Jeśli endpoint odpowiada bez adekwatnych limitów i heurystyk anty-automatyzacyjnych, napastnik może „przelecieć” ogromne przestrzenie numeracji.
  • Każdy dodatkowy bit publicznej informacji (avatar, opis) zwiększa entropię identyfikacyjną i wartość danych dla ataków socjotechnicznych.

Praktyczne konsekwencje / ryzyko

  • Targetowany phishing/Smishing: precyzyjne listy numerów WhatsApp, z lokalizacją krajową i metadanymi profilu, ułatwiają kampanie podszywania.
  • Doxing i nękanie: skojarzenie numeru z wizerunkiem i statusem konta pomaga w identyfikacji osoby.
  • Fraudy „na firmę”: oznaczenia Business mogą prowadzić do podszywania się pod firmy/klientów w łańcuchach dostaw.
  • OSINT na masową skalę: budowa grafów społecznych i wzbogacanie baz marketingowych/szpiegowskich.

Uwaga: według Meta, treść komunikacji pozostała zaszyfrowana E2E; mówimy o wycieku informacji o kontach/identyfikatorach, nie o odszyfrowaniu rozmów.

Rekomendacje operacyjne / co zrobić teraz

Dla użytkowników:

  1. Ustawienia prywatności → ogranicz widoczność zdjęcia profilowego, „O mnie”, statusu i informacji „Kto może zobaczyć…?” do „Moje kontakty” lub „Nikt”.
  2. Rozważ oddzielenie numeru do komunikatorów od numeru „urzędowego”/bankowego.
  3. Weryfikuj wiadomości: nie klikaj linków z nieznanych źródeł; potwierdzaj tożsamość innym kanałem.
  4. Zgłaszaj nadużycia w aplikacji; blokuj nieznane numery.

Dla firm/SOC:

  1. Polityka BYOD/komunikatorów: ograniczaj użycie numerów pracowników jako oficjalnych identyfikatorów; rozważ konta firmowe z kontrolami prywatności.
  2. Reguły detekcji: w SIEM/SOAR dodaj wzorce smishingu i kampanii podszywania z WhatsApp (URL shortenery, popularne domeny phishingowe).
  3. Szkolenia phishingowe ukierunkowane na WhatsApp/sms.
  4. DLP/OSINT: monitoruj paste’y i rynki danych pod kątem list „WhatsApp leads”.
  5. Weryfikacja klientów: w procesach obsługi klienta nie polegaj wyłącznie na identyfikacji numerem/WhatsApp.

Różnice / porównania z innymi przypadkami

  • Projekt vs. exploit: To nie był „remote code execution”, lecz problem projektowy (design flaw) + niedostateczny rate limiting — podobnie jak znane w przeszłości wycieki z mechanizmów „czy ten e-mail istnieje?”.
  • Unikalna skala: rzadko spotykamy możliwość enumeracji globalnej bazy użytkowników popularnego komunikatora w tak krótkim czasie.

Podsumowanie / kluczowe wnioski

  • WhatsApp naprawił lukę po zgłoszeniu, jednak numer telefonu jako identyfikator pozostaje podatnym punktem wielu usług.
  • Organizacje powinny zakładać, że „publiczne metadane” (avatar, opis, obecność w usłudze) mogą zostać zebrane hurtowo i wykorzystane w atakach.
  • Twarde rate limiting + heurystyki anty-botowe + telemetryjne sygnały nadużyć to obowiązek przy funkcjach „discovery”.

Źródła / bibliografia

  • BleepingComputer: „WhatsApp API flaw let researchers scrape 3.5 billion accounts” (22 listopada 2025). (BleepingComputer)
  • University of Vienna — komunikat o badaniach (listopad 2025). (Universität Wien)
  • WIRED: „A Simple WhatsApp Security Flaw Exposed 3.5 Billion Phone Numbers” (listopad 2025). (WIRED)
  • SecurityWeek: „Vulnerability Allowed Scraping of 3.5 Billion WhatsApp Accounts” (20 listopada 2025). (SecurityWeek)
  • CSO Online: „WhatsApp flaw allowed discovery of the 3.5 billion mobile numbers…” (listopad 2025). (csoonline.com)

CVE-2025-0111 — PAN‑OS: Authenticated File Read w interfejsie zarządzania (web)

TL;DR

Luka CVE‑2025‑0111 pozwala uwierzytelnionemu napastnikowi z dostępem sieciowym do interfejsu zarządzania PAN‑OS odczytywać pliki systemowe czytelne przez użytkownika nobody. Ryzyko rośnie przy wystawieniu interfejsu na Internet (np. port 4443 na interfejsie dataplane z profilem management). Producent udostępnił wydania naprawcze oraz sygnatury Threat ID 510000/510001 (pakiet Apps&Threats ≥ 8943). W praktyce: załataj, ogranicz źródła IP do zaufanych, sprawdź, czy nie doszło do łańcuchowej eksploatacji z CVE‑2025‑0108/CVE‑2024‑9474, i zrotuj sekrety, jeśli masz podejrzenie naruszenia.


Krótka definicja techniczna

Authenticated File Read w portalu zarządzania PAN‑OS: błąd kontroli ścieżki (CWE‑73), który umożliwia po zalogowaniu oraz z dostępem sieciowym do UI odczyt plików z systemu plików urządzenia, o ile są one czytelne przez konto systemowe nobody. To naruszenie poufności bez bezpośredniego wpływu na integralność/ dostępność.


Gdzie występuje / przykłady platform

  • Fizyczne NGFW (PA‑Series) oraz VM‑Series (on‑prem/ESXi, AWS/Azure/GCP) — jeśli interfejs zarządzania dostępny z niezaufanej sieci.
  • CN‑Series (Kubernetes) — gdy profil management nadany interfejsowi dataplane/Service LB i port mgmt (typ. 4443) dostępny publicznie.
  • Nie dotyczy: Cloud NGFW i Prisma Access.

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

Wadliwa walidacja/normalizacja ścieżek w webowym interfejsie zarządzania PAN‑OS pozwala po pomyślnym uwierzytelnieniu wykonywać zapytania skutkujące odczytem plików (zakres: pliki czytelne przez nobody). Skuteczność ataku rośnie, gdy:

  1. Interfejs mgmt jest osiągalny z Internetu (bez filtrów źródeł); 2) napastnik dysponuje ważnymi poświadczeniami (np. uzyskanymi inną techniką); 3) podatność jest łączona w łańcuch z innymi błędami (np. CVE‑2025‑0108 i CVE‑2024‑9474), co obserwowano w praktyce. Ujawnione pliki mogą zawierać metadane/konfiguracje ułatwiające eskalację i dalsze działania (rekonesans, wyciek).

Status i ocena producenta: CVSS‑BT 7.1 (HIGH), Exploitation: ATTACKED. Producent wydał poprawki dla gałęzi 10.1, 10.2, 11.1, 11.2 oraz wskazał, że starsze EoL (9.x/10.0/11.0) uznaje się za podatne i nie będą łatane.


Artefakty i logi

Źródło/warstwaTyp/plik/logWskaźniki/kluczeUwagi
PAN‑OS Threat logSygnatury Threat ID 510000/510001threatid, action, src, dst, app, ruleWydane w Apps&Threats ≥ 8943 — blokada/alert prób eksploatacji.
PAN‑OS System logZdarzenia logowania/administracjianomalne logowania do UI, zmiany w profilu mgmtDo korelacji z dostępem z zewnętrznych ASN.
PAN‑OS web‑server access (mp‑log)Dostępy do /php/* / UINietypowe źródła, wzorce żądańW praktyce forwardowane przez syslog lub inspekcja na urządzeniu.
PAN‑OS Traffic logRuch do portów 443/4443 na IP zarządzaniadst_port in (443,4443), action=allow, źródła spoza RFC1918Służy do wykrywania ekspozycji/nieautoryzowanych źródeł.
AWS CloudTrailAuthorizeSecurityGroupIngress, CreateLoadBalancerListenersOtworzenie 443/4443 na 0.0.0.0/0Wczesny sygnał błędnej ekspozycji UI w chmurze.
K8s auditcreate/patch Service/IngressService typu LoadBalancer/NodePort eksponujący 4443Dot. CN‑Series/środowisk PoC.
M365/Entra[brak danych]Nie dotyczy tej luki.
Windows (EID)[brak danych]Nie dotyczy — luka po stronie urządzenia PAN‑OS.

Detekcja (praktyczne reguły)

Sigma — wykrycie sygnatur producenta (Threat log)

title: PAN-OS CVE-2025-0111 — Threat ID detection
id: 0d6b9c2a-5d0e-4e77-98a7-24d0a1c9a111
status: experimental
logsource:
  product: pan-os
  service: threat
detection:
  sel_ids:
    threatid|endswith:
      - '510000'
      - '510001'
  sel_text:
    threatname|contains: 'CVE-2025-0111'
  condition: sel_ids or sel_text
fields:
  - src
  - dst
  - app
  - rule
  - action
  - threatid
level: high
tags:
  - cve.CVE-2025-0111
  - attack.T1190

Sigma — dostęp do UI zarządzania z Internetu (Traffic log)

title: PAN-OS Management UI from External IPs (443/4443)
id: 3b1aaf9e-1f76-4e4d-9b86-b3c59a4d4443
status: experimental
logsource:
  product: pan-os
  service: traffic
detection:
  sel:
    action: 'allow'
    dst_port|in:
      - 443
      - 4443
  not_internal_src:
    src_ip|cidr:
      - '10.0.0.0/8'
      - '172.16.0.0/12'
      - '192.168.0.0/16'
  condition: sel and not not_internal_src
fields:
  - src_ip
  - dst_ip
  - rule
  - app
  - vsys
level: medium
tags:
  - hardening.exposure

Splunk (SPL)

Wykrycie Threat ID / prób eksploatacji:

(index=pan* sourcetype=pan:threat)
| eval threatid_str=tostring(threatid)
| where threatid_str IN ("510000","510001") OR like(threat_name, "%CVE-2025-0111%")
| stats count min(_time) as first_seen max(_time) as last_seen by src dst app rule action threatid threat_name vsys

Dostęp do UI mgmt z Internetu:

(index=pan* sourcetype=pan:traffic action=allowed)
  (dest_port IN (443,4443))
  NOT (cidrmatch("10.0.0.0/8", src_ip) OR cidrmatch("172.16.0.0/12", src_ip) OR cidrmatch("192.168.0.0/16", src_ip))
| lookup firewall_mgmt_ips ip as dest_ip OUTPUTNEW device role
| search role="mgmt"
| stats dc(src_ip) as uniq_sources values(src_ip) as sources count by dest_ip rule app vsys

KQL (Microsoft Sentinel / AMA + CEF)

// Threat IDs 510000/510001 (CEF -> DeviceEventClassID)
CommonSecurityLog
| where DeviceVendor =~ "Palo Alto Networks"
| where DeviceEventClassID in ("510000","510001") or AdditionalExtensions contains "CVE-2025-0111"
| summarize count(), min(TimeGenerated), max(TimeGenerated) by SourceIP, DestinationIP, DeviceEventClassID, Activity, DeviceAction
// Ruch do UI mgmt z Internetu (443/4443) -> wymaga listy IP mgmt w watchliście
let MgmtIPs = dynamic(["198.51.100.10","203.0.113.5"]); // przykład
CommonSecurityLog
| where DeviceVendor =~ "Palo Alto Networks" and Activity has_cs "TRAFFIC"
| where DestinationPort in ("443","4443") and DestinationIP in (MgmtIPs)
| where ipv4_is_private(SourceIP) == false
| summarize by TimeGenerated, SourceIP, DestinationIP, DestinationPort, DeviceAction

AWS CloudTrail Lake (SQL) — ekspozycja mgmt przez SG/ELB

-- Zmiany otwierające 443/4443 na 0.0.0.0/0
SELECT eventTime, eventSource, eventName,
       userIdentity.sessionContext.sessionIssuer.arn AS actor,
       requestParameters
FROM aws_cloudtrail_events
WHERE eventName IN ('AuthorizeSecurityGroupIngress','CreateSecurityGroup','CreateLoadBalancerListeners','ModifyLoadBalancerAttributes')
  AND (requestParameters LIKE '%0.0.0.0/0%')
  AND (requestParameters LIKE '%443%' OR requestParameters LIKE '%4443%')
ORDER BY eventTime DESC;

Elastic / EQL

any where event.dataset == "panw.threat" and
         (panw.threat.id in ("510000","510001") or message =~ "CVE-2025-0111")

Heurystyki / korelacje

  • Dostęp do UI z zewnętrznych ASNlogowanie adminaodczyt/zmiany konfiguracji (System log).
  • Wyzwolenie Threat ID 510000/510001ciągłe próby z jednego źródłabrak wcześniejszej aktywności tego IP.
  • Nagłe upublicznienie portu 4443/443 (CloudTrail/K8s audit) ⟺ nowe alerty Threatzmiany haseł/kluczy w krótkim oknie czasu.

False positives / tuning

  • Ruch z monitoringu/NAC/VPN podszywający się pod „zewnętrzny” (np. testy dostępności).
  • Maintenance (serwis dostawcy) — jednorazowy dostęp spoza korp.
  • Dla sygnatur — testowe skanery i pentesty w labie.
    Tuning: listy zaufanych źródeł, mapowanie IP mgmt w SIEM, korelacja z oknami serwisowymi.

Playbook reagowania (IR)

  1. Triage/izolacja ekspozycji
    • Zidentyfikuj, czy UI mgmt jest publicznie dostępny; jeśli tak, zablokuj/ogranicz źródła (ACL, SG, WAF) do zaufanych IP.
  2. Patching
    • Zaktualizuj do wersji naprawczej: 10.1.14‑h9+, 10.2.x‑h21/h24/h14/h12/h6/… (wg tabeli), 11.1.6‑h1+/11.1.4‑h13+/11.1.2‑h18+, 11.2.4‑h4+ lub 11.2.5+. Starsze EoL — migracja/wymiana.
  3. Zabezpieczenia prewencyjne
    • Włącz/zweryfikuj subskrypcję Threat Prevention i sygnatury Threat ID 510000/510001 (Apps&Threats ≥ 8943).
  4. Hunting
    • Przejrzyj logi Threat/System/Traffic pod kątem prób/udanych dostępów.
    • Oceń korelację z CVE‑2025‑0108/CVE‑2024‑9474 (możliwe łańcuchy).
  5. Remediacja sekrety (gdy podejrzenie nadużycia):
    • Zmień master key (AES‑256‑GCM), hasła/PSK/secrety, unieważnij i wydaj ponownie certyfikaty z kluczami prywatnymi na urządzeniu.
  6. Edukacja i kontrola zmian
    • Wymuś politykę „jump‑box only” do UI mgmt; przegląd SG/ACL/Ingress.

Przykłady z kampanii / case studies

  • Eksploatacja łańcuchowa: producent i niezależne raporty wskazały próby łączenia CVE‑2025‑0108 + CVE‑2024‑9474 + CVE‑2025‑0111 na niezałatanych i źle zabezpieczonych interfejsach mgmt.
  • Advisory/monitoring: Armis i HKCERT klasyfikują ryzyko jako wysokie; zalecają priorytetowy patching i ograniczenie ekspozycji.
  • Bazy podatności: NVD/CVE.org/Tenable/Rapid7 dokumentują charakter luki, wektor i brak wpływu na Cloud NGFW/Prisma Access.

Lab (bezpieczne testy) — przykładowe kroki/komendy

Tylko w odizolowanym labie. Nie wykonuj testów wobec cudzych systemów. Scenariusz ma zweryfikować detekcje i hardening, nie eksploatować luki.

  1. Weryfikacja wersji i contentu (CLI PAN‑OS):
    • show system info → sprawdź sw-version.
    • request content upgrade check / request content upgrade download latest / request content upgrade install version <>=8943 (upewnij się, że Threat ID 510000/510001 są obecne).
  2. Tymczasowe logowanie dostępu do UI
    • Skonfiguruj forwarding System/Threat/Traffic do SIEM.
    • Z dozwolonego hosta wewnętrznego wygeneruj benign ruch do UI: curl -k https://<fw-mgmt>:4443/ (sprawdź, czy powstają zapisy w Traffic/System).
  3. Testy detekcji w SIEM
    • Uruchom podane zapytania Splunk/KQL/Elastic; w razie braku rzeczywistych zdarzeń skorzystaj z generatorów logów testowych (np. sample CEF) z symbolicznym threatid=510000 (bez faktycznej próby eksploatacji).
  4. Hardening
    • Zaimplementuj listę zaufanych źródeł (ACL/SG) i regułę „jump‑box only”; potwierdź, że ruch spoza listy nie dociera do UI.

Mapowania (Mitigations, powiązane techniki)

Mitigations (ATT&CK)

  • M1051 — Update Software (aktualizacje PAN‑OS do wersji naprawczych).
  • M1037 — Filter Network Traffic (restrykcja źródeł do UI, tylko zaufane IP).
  • M1030 — Network Segmentation (dostęp przez jump‑host/VPN).
  • M1042 — Disable or Remove Feature or Program (wyłączenie profilu mgmt na interfejsach dataplane, jeśli zbędny).
  • M1027 — Password Policies / M1026 — Privileged Account Management (rotacja sekretów/mk, least privilege).

Techniki (ATT&CK)

T1190 — Exploit Public‑Facing Application

Dotyczy nadużycia błędu w aplikacji web wystawionej publicznie (UI mgmt). Tu: wymaga PR:L (zalogowanego aktora), ale wektor nadal AV:N i kanał webowy.

T1078 — Valid Accounts

Warunek konieczny: ważne konto z dostępem do UI mgmt (np. po phishingu/wycieku). Korelować logowania z nietypowych ASN.

T1005 — Data from Local System

Odczyt plików z systemu plików urządzenia w celu pozyskania informacji pomocnych do dalszych faz ataku.


Źródła / dalsza lektura

  • Palo Alto Networks — Advisory (CVE‑2025‑0111): opis, wersje naprawcze, Threat ID 510000/510001, zalecenia dot. master key/rotacji sekretów. (Palo Alto Networks Security)
  • NVD (nist.gov) — karta CVE. (NVD)
  • CVE.org — rekord producenta. (CVE)
  • Tenable / Rapid7 — podsumowania ryzyka i przypomnienie o ograniczeniu dostępu do UI. (Tenable®)
  • FortiGuard / H‑ISAC / HKCERT / Armis — doniesienia o łańcuchach eksploatacyjnych i „in‑the‑wild”. (FortiGuard)
  • MITRE ATT&CK — Version history (v18.1). (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjne):

  • Czy posiadamy watchlistę IP mgmt i aktywne reguły dla portów 443/4443?
  • Czy SIEM odbiera Threat/System/Traffic z NGFW i wzbogaca o ASN/CIDR?
  • Czy alertujemy na Threat ID 510000/510001 (wysoki priorytet)?
  • Czy działają korelacje: zdalny dostęp do UIlogowanie adminazmiana config?
  • Czy przeprowadzono hunt pod kątem prób łańcuchowych (CVE‑2025‑0108/2024‑9474/2025‑0111)?

CISO / właściciel ryzyka:

  • Czy interfejs mgmt nie jest dostępny z Internetu (architektura „jump‑box only”)?
  • Czy wszystkie instancje mają wersje naprawcze (wg tabeli producenta)?
  • Czy mamy proces rotacji sekretów/master key/certyfikatów po incydencie?
  • Czy SLA na Apps&Threats content gwarantuje ≥ 8943 i autoupdate?
  • Czy polityki least privilege dotyczą również kont administracyjnych NGFW?

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.