CVE-2025-14733 (WatchGuard Fireware OS / Firebox)

TL;DR

• Co to jest: krytyczne RCE bez uwierzytelnienia (out-of-bounds write / CWE-787) w procesie iked w WatchGuard Fireware OS.
• Kiedy boli najbardziej: gdy Firebox ma włączone IKEv2 VPN (Mobile User VPN IKEv2 oraz BOVPN IKEv2 z dynamic gateway peer).
• Wersje podatne (wg NVD): Fireware OS 11.10.2–11.12.4_Update1, 12.0–12.11.5, 2025.1–2025.1.3.
• Fixy (wg WatchGuard): 2025.1.4, 12.11.6, 12.5.15 (T15/T35), 12.3.1_Update4 (FIPS); 11.x = EoL.
• Status operacyjny: WatchGuard potwierdza aktywne próby eksploatacji, a NVD odnotowuje dodanie do KEV (terminy dla FCEB w USA wg wpisu w NVD).
• Mapowanie ATT&CK: T1190 – Exploit Public-Facing Application (taktika: Initial Access, v2.8, Last Modified 24 Oct 2025).
• Co robić teraz: patch/upgrade, zawężenie ekspozycji UDP 500/4500 (tylko znane peer’y), hunting po logach iked (CERT > 2000, chain > 8), rotacja sekretów po IoA/IOC.

Krótka definicja techniczna

T1190 (Exploit Public-Facing Application) opisuje scenariusz, w którym atakujący wykorzystuje błąd w usłudze wystawionej do Internetu, aby uzyskać initial access; CVE-2025-14733 to praktyczny przykład tej techniki na urządzeniu brzegowym (WatchGuard Firebox), gdzie podatność w IKEv2 (iked) umożliwia zdalne wykonanie kodu bez logowania, jeżeli usługa VPN jest wystawiona i skonfigurowana w określony sposób.

Gdzie występuje / przykłady platform (Windows, AD, AWS, Azure, GCP, K8s, ESXi, M365)

• Network Devices / Edge (najważniejsze): WatchGuard Firebox (Fireware OS) wystawiony do Internetu na IKEv2.
• Windows / AD: zwykle kolejny etap po initial access (pivot przez VPN, kradzież poświadczeń, ruch lateralny). [brak danych / do uzupełnienia] dla konkretnej kampanii powiązanej z CVE-2025-14733 (brak publicznie potwierdzonego kill-chain per-actor w źródłach vendorowych).
• AWS / Azure / GCP: jeżeli Firebox działa jako appliance w chmurze (np. Firebox Cloud) — dochodzi warstwa kontroli ekspozycji przez Security Group/NSG i logi cloudowe (CloudTrail/Activity Log) do wykrywania nagle otwartych UDP 500/4500.
• K8s: nie dotyczy bezpośrednio (to nie jest podatność kontenerowa).
• ESXi: nie dotyczy bezpośrednio (chyba iż Firebox jest elementem segmentacji/DMZ).
• M365: nie dotyczy bezpośrednio; ewentualnie telemetria logowań po kompromitacji.

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

W praktyce CVE-2025-14733 wpisuje się w T1190, bo:

• Punkt wejścia to usługa brzegowa: IKEv2 VPN na Fireboxie (Mobile User VPN i/lub Branch Office VPN).
• Klasa błędu: out-of-bounds write (CWE-787), co typowo daje spektrum skutków od crash/hang po RCE.
• Warunki podatności (ważne dla SOC): WatchGuard wskazuje zależność od konfiguracji IKEv2 (w tym dynamic gateway peer) oraz fakt, iż choćby po usunięciu konfiguracji dynamic peer urządzenie może przez cały czas pozostać podatne w określonych przypadkach (istniejące BOVPN do static peer).
• Dlaczego skuteczne operacyjnie: edge urządzenia są często wystawione do Internetu i mają ograniczone host-based controls; do tego dochodzi presja “VPN musi działać”, więc okno patchowania bywa realnie dłuższe niż w serwerach aplikacyjnych. To jest dokładnie kontekst, który MITRE opisuje dla T1190 (również w odniesieniu do urządzeń sieciowych).

Artefakty i logi (tabela — EID, CloudTrail events, K8s audit, M365 operations)

Artefakt / sygnałEID (Windows)CloudTrail events (AWS)K8s auditM365 operationsGdzie szukać / komentarz

iked: “Received peer certificate chain is longer than 8…”	—	—	—	—	Syslog/Traffic Monitor z Firebox (domyślny error level). To vendor opisuje jako medium indicator of attack.
iked: “IKE_AUTH request … CERT(sz=3000) …” i CERT > 2000	—	—	—	—	Syslog przy info logging; WatchGuard wskazuje >2000 jako strong indicator.
IKED hang (VPN re-key/negocjacje “stają”)	—	—	—	—	Zachowanie urządzenia: przerwane negocjacje, istniejące tunele mogą działać.
IKED crash + fault report	—	—	—	—	WatchGuard: crash po udanej/nieudanej próbie (weak indicator).
Ruch outbound z Firebox do wskazanych IP (IoA)	—	—	—	—	WatchGuard: outbound do tych IP to mocny sygnał kompromitacji; inbound może oznaczać recon/attempt.
Nagle otwarte UDP 500/4500 do Internetu (Firebox Cloud)	—	AuthorizeSecurityGroupIngress / zmiany NACL	—	—	Dla wdrożeń w AWS: koreluj zmiany ekspozycji z aktywnością iked. (Detekcja “okołopodatnościowa”, ale praktyczna).

Detekcja (praktyczne reguły)

Sigma (gotowa reguła)

Założenie: logi Firebox (syslog) trafiają do SIEM jako tekst (np. message). Dopasuj logsource do swojego pipeline’u (np. Syslog/CEF).

title: WatchGuard Firebox CVE-2025-14733 - IKEv2 iked Indicators id: 3f3a8a7c-5b0c-4b56-9c1d-4a5a54f6d2f1 status: experimental description: | Detects WatchGuard Firebox iked log patterns associated with CVE-2025-14733 exploitation attempts: - peer certificate chain longer than 8 - IKE_AUTH requests with abnormally large CERT payload size (>=2000 bytes) references: - https://nvd.nist.gov/vuln/detail/CVE-2025-14733 - https://www.watchguard.com/wgrd-psirt/advisory/wgsa-2025-00027 author: SOC/Blue Team date: 2025/12/23 logsource: category: firewall product: watchguard detection: sel_chain_long: message|contains: - 'Received peer certificate chain is longer than 8' - 'Reject this certificate chain' sel_cert_big: message|contains: - 'IKE_AUTH request' - 'CERT(sz=' sel_cert_big_re: message|re: 'CERT\(sz=(2[0-9]{3}|[3-9][0-9]{3,})\)' condition: sel_chain_long or (sel_cert_big and sel_cert_big_re) falsepositives: - Unusual but legitimate certificate chains from misconfigured peers - Large certificate payloads in rare enterprise PKI setups level: high tags: - attack.initial_access - attack.t1190

Wzorce logów i progi (chain > 8, CERT > 2000) są oparte o wskaźniki opisane przez WatchGuard.

Splunk (SPL)

1) IoA w logach iked (CERT/chain):

index=network (sourcetype=syslog OR sourcetype=watchguard*) ("iked" AND ("Received peer certificate chain is longer than 8" OR "IKE_AUTH request")) | rex field=_raw "CERT\(sz=(?<cert_sz>\d+)\)" | eval cert_sz=tonumber(cert_sz) | where like(_raw,"%Received peer certificate chain is longer than 8%") OR cert_sz>=2000 | stats count earliest(_time) as firstSeen latest(_time) as lastSeen values(host) as devices values(src) as src_ip values(cert_sz) as cert_sizes by dest | convert ctime(firstSeen) ctime(lastSeen)

2) Ruch do IP z advisory (outbound = silniejszy sygnał):

index=network (sourcetype=pan:traffic OR sourcetype=netflow OR sourcetype=watchguard*) (dest_ip IN ("45.95.19.50","51.15.17.89","172.93.107.67","199.247.7.82") OR src_ip IN ("45.95.19.50","51.15.17.89","172.93.107.67","199.247.7.82")) | stats count earliest(_time) as firstSeen latest(_time) as lastSeen values(action) as actions values(dest_port) as ports by src_ip dest_ip | convert ctime(firstSeen) ctime(lastSeen)

Lista IP i interpretacja inbound/outbound pochodzą z WatchGuard IoA.

KQL (Azure / Microsoft Sentinel)

Syslog (Syslog table) — CERT > 2000 / chain > 8:

Syslog | where ProcessName has "iked" or SyslogMessage has "iked" | extend CertSz = toint(extract(@"CERT\(sz=(\d+)\)", 1, SyslogMessage)) | where SyslogMessage has "Received peer certificate chain is longer than 8" or (SyslogMessage has "IKE_AUTH request" and CertSz >= 2000) | project TimeGenerated, Computer, Facility, SeverityLevel, ProcessName, CertSz, SyslogMessage | order by TimeGenerated desc

CommonSecurityLog / firewall telemetry — IoA IP:

let ioc_ips = dynamic(["45.95.19.50","51.15.17.89","172.93.107.67","199.247.7.82"]); CommonSecurityLog | where DestinationIP in (ioc_ips) or SourceIP in (ioc_ips) | project TimeGenerated, DeviceVendor, DeviceProduct, SourceIP, DestinationIP, DestinationPort, Activity, Message | order by TimeGenerated desc

IoA IP i log-patterny: WatchGuard advisory.

CloudTrail query (AWS CLI/CloudWatch)

Scenariusz: Firebox Cloud w AWS — polujemy na “nagłe wystawienie” UDP 500/4500 do Internetu.

AWS CLI (CloudTrail LookupEvents) — SG ingress na 500/4500 (wymaga jq):

aws cloudtrail lookup-events \ --lookup-attributes AttributeKey=EventName,AttributeValue=AuthorizeSecurityGroupIngress \ --max-results 50 \ | jq -r ' .Events[] | (.CloudTrailEvent | fromjson) | select(.requestParameters.ipPermissions.items[]? | (.fromPort==500 or .fromPort==4500)) | {eventTime, userIdentity: .userIdentity.arn, groupId: .requestParameters.groupId, ipPermissions: .requestParameters.ipPermissions.items} '

Jeśli zamiast CloudTrail trzymasz telemetrię w innych źródłach, oznacz to jako [brak danych / do uzupełnienia] w swoim runbooku.

Elastic/EQL przykłady

Kibana KQL (syslog z Firebox):

(event.dataset: syslog OR event.dataset: "watchguard*") and (message: "*Received peer certificate chain is longer than 8*" or (message: "*IKE_AUTH request*" and message: "*CERT(sz=2*") or (message: "*IKE_AUTH request*" and message: "*CERT(sz=3*"))

EQL (jeśli masz ustandaryzowane pola):

any where event.category == "network" and (process.name == "iked" or message like "*iked*") and ( message like "*Received peer certificate chain is longer than 8*" or (message like "*IKE_AUTH request*" and message regex "CERT\\(sz=(2[0-9]{3}|[3-9][0-9]{3,})\\)") )

Heurystyki / korelacje

Dla SOC sensownie działa korelacja “multi-signal”, zgodna z duchem MITRE (request → error → post-exploit).

Proponowane łańcuchy:

1. IKE_AUTH (CERT > 2000) lub chain > 8 → w oknie 1–5 min IKED hang/crash → w oknie 5–30 min outbound do podejrzanych IP / nowy egress z urządzenia.
2. Spike w inbound UDP 500/4500 z AS/geo nietypowego dla Twoich peerów + równoległy wzrost błędów iked.
3. Dla static BOVPN: obecność “allow from all” na UDP 500 (domyślne polityki) + ruch z Internetu + anomalie iked → priorytet P1 (bo tu “hardening” jest realnym workaroundiem).

False positives / tuning

• “certificate chain longer than 8” może się zdarzyć przy źle złożonym łańcuchu certów po stronie peera (PKI, błędy klienta) — traktuj jako średni sygnał, dopóki nie ma korelacji z crash/hang lub CERT > 2000.
• CERT > 2000: vendor opisuje jako strong indicator, ale w dużych środowiskach (długie łańcuchy, nietypowe certy) warto whitelistingować znane peer IP i/lub profile, zamiast obniżać próg.
• Crash iked: WatchGuard podkreśla, iż są inne przyczyny crashy → traktuj jako weak indicator sam w sobie.
• Tuning praktyczny: ogranicz ekspozycję do znanych peerów (alias) i wyłącz domyślne “allow IKE from all” — wtedy większość FP znika, bo “Internet noise” przestaje docierać do usługi.

Playbook reagowania (kroki + komendy)

Krok 0 — triage (czy jesteśmy w zakresie?)

1. Sprawdź wersję Fireware i porównaj z listą podatnych/fix.
2. Sprawdź, czy masz IKEv2 (Mobile VPN IKEv2 / BOVPN IKEv2, dynamic peer).
3. Hunting po IoA logach (iked) i połączeniach do IP z advisory.

Krok 1 — containment (minimalizuj powierzchnię ataku)

• Jeśli biznes pozwala: czasowo wyłącz IKEv2 VPN lub ogranicz go do stałych peerów.
• Jeśli masz tylko static peer BOVPN i nie możesz od razu patchować: zastosuj hardening wg WatchGuard:
  1. wyłącz dynamic peer VPN,
  2. utwórz alias ze stałymi IP peerów,
  3. dodaj polityki dopuszczające UDP 500/4500 tylko z aliasu,
  4. wyłącz domyślne polityki IPSec “allow all”.

Krok 2 — eradication (patch/upgrade)

• Wgraj wersje naprawione:
  • 2025.1.4+, 12.11.6+, 12.5.15 (T15/T35), 12.3.1_Update4 (FIPS).
• Jeśli jesteś na 11.x: to gałąź EoL — plan migracji jest obowiązkowy (w praktyce “nie ma co czekać na fix”).

Krok 3 — recovery (po podejrzeniu kompromitacji: rotacja sekretów)

WatchGuard zaleca rotację lokalnie przechowywanych sekretów. Przykładowa lista do odhaczenia:

• credentials do zarządzania Firebox,
• Firebox-DB,
• importowane certyfikaty i klucze prywatne,
• IPsec PSK (BOVPN/L2TP/mobile IPsec),
• Log Server PSK,
• SNMP community / SNMPv3 auth,
• RADIUS shared secrets,
• LDAP/AD “searching user” password,
• DDNS creds, PPPoE creds, itp.

Krok 4 — post-incident hardening

• Wprowadź stały proces: vuln scanning + szybkie patchowanie dla edge (MITRE mitigation: Update Software, Vulnerability Scanning, Limit Access…).

Przykłady z kampanii / case studies

• WatchGuard wprost wskazuje, iż obserwuje aktywną próbę eksploatacji w środowiskach produkcyjnych.
• Różne źródła branżowe raportują dużą liczbę wystawionych/podatnych instancji (rzędu ~115k–125k) na podstawie skanów/obserwacji (np. Shadowserver) — to podbija ryzyko “spray-and-pray” na UDP 500/4500.
• NVD odnotowuje powiązanie z KEV (wpisy dot. “Date Added / Due Date / Required Action” pojawiają się w szczegółach CVE), co w praktyce często koreluje z dojrzałą eksploatacją.

Lab (bezpieczne testy) — przykładowe komendy

A) Test detekcji w SIEM przez “wstrzyknięcie” przykładowego sysloga

Na systemie, który wysyła syslog do SIEM:

logger -p local3.err 'iked[1234]: (203.0.113.1<->203.0.113.2) Received peer certificate chain is longer than 8. Reject this certificate chain' logger -p local3.info 'iked (203.0.113.1<->203.0.113.2)"IKE_AUTH request" message has 6 payloads [ IDi(sz=21) CERT(sz=3000) SA(sz=44) TSi(sz=24) TSr(sz=24) N(sz=8)]'

Wzorce komunikatów są zgodne z przykładami z advisory.

B) Test “ekspozycji” portów tylko na własnym publicznym IP Firebox

nmap -sU -p 500,4500 -Pn <PUBLIC_IP_FIREBOX>

Cel: potwierdzenie, czy UDP 500/4500 jest wystawione szeroko, czy ograniczone politykami do znanych peerów (hardening).

C) Walidacja hardeningu (bez patcha, doraźnie)

Wykonaj kroki z KB: aliasy + nowe polityki + wyłączenie systemowych “allow IKE”.

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (technika główna)

• T1190 — Exploit Public-Facing Application
  • Taktika: Initial Access
  • ATT&CK (strona techniki): Version 2.8, Last Modified 24 Oct 2025

MITRE Mitigations (praktyczne dla CVE-2025-14733)

Z listy mitigacji przypisanych do T1190 (wybrane, najbardziej operacyjne dla Firebox/edge):

• M1051 Update Software (patch management edge)
• M1016 Vulnerability Scanning (zewnętrzne skany + szybkie okna patchy)
• M1035 Limit Access to Resource Over Network (zawężenie UDP 500/4500 do znanych peerów)
• M1037 Filter Network Traffic (kontrola egress, blokady IoA)
• M1030 Network Segmentation (DMZ/segmentacja od reszty)

Powiązane techniki (kontekstowe)

• Exploitation for Defense Evasion (gdy exploit jednocześnie omija kontrolki) oraz Exploitation for Client Execution — MITRE wskazuje, iż T1190 może się z tym łączyć zależnie od podatności.

Źródła / dalsza literatura

• WatchGuard PSIRT Advisory WGSA-2025-00027 (IoA/IoC, wersje naprawione, logi iked). (watchguard.com)
• WatchGuard blog (lista wydań firmware i nacisk na pilną aktualizację). (watchguard.com)
• NVD: CVE-2025-14733 (opis, zakres wersji, CWE-787, CVSS). (NVD)
• CSA Singapore alert (potwierdzenie krytyczności i informacji o eksploatacji). (Cyber Security Agency of Singapore)
• WatchGuard KB: hardening BOVPN/IKEv2 (aliasy + polityki + wyłączenie systemowych “allow”). (techsearch.watchguard.com)
• WatchGuard KB: lista sekretów do rotacji po podejrzeniu kompromitacji. (techsearch.watchguard.com)
• MITRE ATT&CK: T1190 (definicja, platformy, mitigacje, detection strategy). (MITRE ATT&CK)
• Doniesienia branżowe o skali ekspozycji i atakach: BleepingComputer / SecurityWeek / TheHackerNews. (BleepingComputer)

Checklisty dla SOC / CISO

SOC (operacyjnie)

• Zidentyfikuj wszystkie Fireboxy i ich wersje Fireware; oznacz EoL 11.x jako P0 do migracji.
• Sprawdź konfiguracje: Mobile VPN IKEv2 / BOVPN IKEv2 (dynamic peer) + “pozostałości” po konfiguracjach historycznych.
• Włącz/zbierz logi iked do SIEM; reguły na chain > 8 i CERT > 2000.
• Koreluj z iked hang/crash oraz ruchem outbound do IoA IP.
• Po IoA/IOC: uruchom procedurę rotacji sekretów (lista wg KB).

CISO / właściciel ryzyka

• Wymuś patch/upgrade do wersji naprawionych (SLA “edge”).
• Zmień standard: IKEv2 nie jest “publiczny dla świata” — tylko znane peer’y (aliasy/polityki).
• Włącz stałe vulnerability scanning + szybkie okna patchy na urządzeniach brzegowych.