CVE-2025-3232 — Mitsubishi Electric Europe B.V. smartRTU

TL;DR

• CVE-2025-3232 dotyczy Mitsubishi Electric Europe B.V. smartRTU (≤ 3.37) i polega na braku uwierzytelnienia dla krytycznej funkcji (CWE-306) – w praktyce zdalny, nieuwierzytelniony atakujący może obejść kontrolę dostępu i przez konkretną trasę API doprowadzić do wykonania poleceń systemu operacyjnego.
• Ocena ryzyka (CNA/ICS-CERT): CVSS v3.1 7.5 (HIGH); NVD pokazuje też CVSS v4 8.7 (HIGH) (ocena NVD “not yet provided”, widoczna jest ocena CNA).
• To część pakietu problemów w smartRTU opisanego w ICSA-25-105-09 – obok CVE-2025-3128 (CWE-78, OS Command Injection, CVSS 9.8), który bywa opisywany jako kolejny krok po obejściu uwierzytelnienia.
• Najważniejsze działania defensywne (kompensacyjne): zdejmij ekspozycję z Internetu, ogranicz dostęp do zaufanych sieci, stosuj VPN / firewall, a jeżeli HTTP/HTTPS musi być wystawione – rozważ WAF.
• W materiałach CISA/CSAF (ICSA-25-105-09) wskazano, iż nie było raportów o publicznie znanej exploitacji ukierunkowanej na tę podatność (stan na publikację/rewizję advisory).

Krótka definicja techniczna

CVE-2025-3232 to podatność typu Missing Authentication for Critical Function (CWE-306) w smartRTU (≤ 3.37), umożliwiająca atakującemu z sieci wywołanie wrażliwej funkcji przez określoną trasę API bez poprawnego uwierzytelnienia, co według opisu CVE może skutkować wykonaniem dowolnych poleceń OS (impact wg CVSS: Integrity = High). W kontekście MITRE ATT&CK (ICS) najbliższe mapowanie to T0819 Exploit Public-Facing Application (Initial Access), często w praktyce łączone też z T0866 Exploitation of Remote Services oraz wykonaniem komend po przejęciu kontekstu (np. T0807 Command-Line Interface).

Gdzie występuje / przykłady platform

• ICS/OT: smartRTU (urządzenie/komponent RTU używany w środowiskach przemysłowych, zwykle z interfejsem web/API do zarządzania).
• Windows: pośrednio (stacje inżynierskie/HMI/jump hosty, z których administruje się smartRTU) – przydatne do korelacji EDR/SIEM.
• AD: zwykle nie dotyczy bezpośrednio (chyba iż integracja/SSO w warstwie IT).
• AWS / Azure / GCP: nie dotyczy samej podatności, ale może dotyczyć ekspozycji (np. reverse proxy/WAF w chmurze).
• K8s: nie dotyczy.
• ESXi: nie dotyczy.
• M365: nie dotyczy.

Szczegółowy opis techniki

Jak to działa (perspektywa defensywna)

W smartRTU istnieje funkcjonalność dostępna przez interfejs web/API, która powinna być chroniona uwierzytelnieniem/autoryzacją. W przypadku CVE-2025-3232 mechanizm ten jest niewystarczający: krytyczna funkcja (wywoływana przez “specific API route”) może zostać uruchomiona bez poprawnej autentykacji, co według opisu CVE prowadzi do wykonania poleceń OS.

Cele atakującego

W OT/ICS taki wektor wejścia jest atrakcyjny, bo:

• daje zdalny foothold na urządzeniu brzegowym (RTU), często stojącym na styku sieci (telemetria, zdalne zarządzanie),
• może umożliwić manipulację konfiguracją, “tampering” oraz potencjalnie przygotowanie gruntu pod kolejne kroki (ruch boczny, zmiana parametrów, sabotaż).

Dlaczego jest skuteczna

• Brak wymogu poświadczeń (PR:N) i niska złożoność (AC:L) w CVSS oznacza, iż przy złej ekspozycji (Internet / nieufne segmenty) ryzyko operacyjne gwałtownie rośnie.
• OT często ma ograniczony telemetry/EDR na urządzeniach embedded, więc “signal” detekcyjny bywa głównie sieciowy (FW/WAF/IDS) i z elementów pośredniczących.

Artefakty i logi

Źródło / warstwaEID (Windows)CloudTrail eventsK8s auditM365 operationsCo warto zbierać / na co patrzeć

Dostęp do interfejsu web/API smartRTU	N/A	N/A	N/A	N/A	Logi HTTP (reverse proxy/WAF), metoda POST/PUT/DELETE, nietypowe URI, skoki 4xx/5xx, nietypowe UA, duże payloady
Firewall / IDS/IPS	N/A	N/A	N/A	N/A	Inbound do panelu zarządzania (80/443 lub inne), źródła spoza allowlist, skanowanie, bursty requestów
Host/EDR na stacji inżynierskiej/jump hoście (jeśli zarządzanie z Windows)	4688, 4625/4624 (korelacje logowań)	N/A	N/A	N/A	Nietypowe procesy uruchomione w kontekście narzędzi admin/remote, “helper tools”, nowe połączenia sieciowe do RTU
Telemetria z urządzenia (jeśli dostępna)	N/A	N/A	N/A	N/A	Syslog/audit (o ile jest), historia poleceń, zmiany konfiguracji, restarty usług/urządzenia
WAF (jeśli publikujesz web)	N/A	(raczej) N/A	N/A	N/A	Reguły blokujące nietypowe requesty, anomalie w parametrach i nagłówkach; korelacja z ruchem zewnętrznym

Detekcja (praktyczne reguły)

Uwaga praktyczna: w OT często nie masz idealnych logów “z urządzenia”. Dlatego poniżej są reguły, które da się zastosować w warstwie pośredniej (WAF/reverse proxy) albo na hostach, które zbierają procesy (EDR). Nie używam tu żadnych “kroków exploitacji” ani nie podaję konkretnej trasy API – bo publiczne advisory mówi tylko o “specific API route”.

Sigma (gotowa reguła)

title: Possible Web/API Triggered OS Command Execution via Web Server Parent (smartRTU / CVE-2025-3232 context) id: 3b2b8e3a-3c3d-4d6a-9d7a-1f6b62b8d6c1 status: experimental description: | Detects suspicious shell/process execution spawned by common embedded/web server processes. Useful as compensating detection for scenarios where an unauthenticated API route may lead to OS command execution (e.g., smartRTU CVE-2025-3232 and related chains). references: - https://nvd.nist.gov/vuln/detail/CVE-2025-3232 - https://raw.githubusercontent.com/cisagov/CSAF/develop/csaf_files/OT/white/2025/icsa-25-105-09.json author: "Badacz CVE (SOC/Blue Team)" date: 2025/12/25 tags: - attack.initial_access - attack.t1190 - attack.execution logsource: category: process_creation product: linux detection: parent_websrv: ParentImage|endswith: - /nginx - /apache2 - /httpd - /lighttpd - /uhttpd - /boa child_shell: Image|endswith: - /sh - /bash - /ash - /busybox cmd_susp: CommandLine|contains: - " -c " - "wget " - "curl " - "nc " - "mkfifo " - "/dev/tcp/" condition: parent_websrv and (child_shell or cmd_susp) falsepositives: - Legitimate CGI scripts or admin maintenance jobs that spawn shells from web services - Firmware update routines implemented via web backend level: high

Splunk (SPL)

Wariant A – proxy/WAF access logs (szukamy nieautoryzowanych prób do panelu/API):

index=net* (sourcetype=nginx:access OR sourcetype=apache:access OR sourcetype=waf) dest_port IN (80,443) | eval uri=coalesce(uri_path, uri, request) | search http_method IN ("POST","PUT","DELETE") OR like(uri,"%api%") | where NOT cidrmatch("10.0.0.0/8", src_ip) AND NOT cidrmatch("192.168.0.0/16", src_ip) | stats count min(_time) as firstSeen max(_time) as lastSeen values(http_method) values(status) values(uri) by src_ip dest_ip | sort -count

Wariant B – EDR/host telemetry (webserver → shell):

index=edr* sourcetype=process* | where (parent_process_name IN ("nginx","httpd","apache2","lighttpd","uhttpd","boa")) | where (process_name IN ("sh","bash","ash","busybox") OR like(process_command_line,"% -c %")) | stats count min(_time) max(_time) values(process_command_line) by host user parent_process_name process_name | sort -count

KQL (Azure)

Defender for Endpoint (jeśli masz DeviceProcessEvents z hostów/jump hostów):

DeviceProcessEvents | where InitiatingProcessFileName in~ ("nginx","httpd","apache2","lighttpd","uhttpd","boa") | where FileName in~ ("sh","bash","ash","busybox") or ProcessCommandLine has " -c " | project Timestamp, DeviceName, AccountName, InitiatingProcessFileName, FileName, ProcessCommandLine | order by Timestamp desc

Azure WAF / App Gateway (jeśli smartRTU stoi za takim frontem):

AzureDiagnostics | where Category has "ApplicationGatewayFirewallLog" | where action_s == "Blocked" or ruleSetType_s =~ "OWASP" | project TimeGenerated, clientIp_s, requestUri_s, requestMethod_s, message_s, ruleId_s | order by TimeGenerated desc

CloudTrail query (AWS CLI/CloudWatch)

CloudTrail nie loguje ruchu HTTP do smartRTU (to nie są wywołania AWS API). o ile jednak wystawiasz smartRTU przez AWS WAF/ALB, sensowniejsze jest pytanie CloudWatch Logs Insights na logach WAF:

fields @timestamp, httpRequest.clientIp as srcIp, httpRequest.httpMethod as method, httpRequest.uri as uri, action, terminatingRuleId | filter method in ["POST","PUT","DELETE"] or uri like /api/ | stats count() as hits, min(@timestamp) as firstSeen, max(@timestamp) as lastSeen by srcIp, method, uri, action | sort hits desc

Elastic/EQL przykłady

process where host.os.type == "linux" and process.parent.name in ("nginx","httpd","apache2","lighttpd","uhttpd","boa") and ( process.name in ("sh","bash","ash","busybox") or process.command_line like "* -c *" )

Heurystyki / korelacje

1. Ruch sieciowy → objaw na hoście: burst requestów HTTP/HTTPS do interfejsu zarządzania + w krótkim oknie czasowym proces potomny typu shell (jeśli masz telemetrię).
2. Źródło spoza polityki dostępu: jakikolwiek request do panelu/API smartRTU z IP spoza allowlist (VPN/management VLAN).
3. Zmiany konfiguracyjne / restarty: anomalia w dostępności RTU, restart usług, zmiany parametrów – skorelowane czasowo z nietypowym ruchem do web/API.
4. Skanowanie: rozproszony ruch do portów zarządczych (80/443) poprzedzający adekwatne wywołania.

False positives / tuning

• Legalna administracja potrafi wyglądać “podejrzanie”, jeśli:
  • admin używa narzędzi automatyzujących (API),
  • są wykonywane update’y/backup/diagnostyka z panelu (może generować wywołania typu POST).
• Tuning praktyczny:
  • twarda allowlista źródeł (VPN, jump hosty, sieci adminów),
  • baseline “normalnych” URI i metod HTTP,
  • korelacja z oknami serwisowymi (maintenance windows),
  • w EDR: allowlist legalnych skryptów/agentów, które realnie mogą startować shell (jeśli to w ogóle dopuszczalne w Twoim środowisku).

Playbook reagowania (kroki + komendy)

1) Identyfikacja i triage

• Zrób inventory: gdzie stoi smartRTU i czy wersja jest ≤ 3.37 (to zakres “known affected” w advisory).
• Sprawdź ekspozycję: czy panel zarządzania jest dostępny z Internetu albo z segmentów nie-OT.

2) Natychmiastowe ograniczenie ekspozycji (kompensacja)

Zgodnie z zaleceniami w advisory:

• wymuś VPN / firewall przy dostępie zdalnym,
• ogranicz do LAN i blokuj sieci nieufne,
• jeśli HTTP/HTTPS musi działać – postaw WAF i ogranicz web client access do zaufanych sieci.

Przykład (Linux firewall na reverse proxy – tylko allowlista):

# tylko przykład – dopasuj interfejs/port sudo iptables -A INPUT -p tcp --dport 443 -s <TRUSTED_ADMIN_SUBNET_CIDR> -j ACCEPT sudo iptables -A INPUT -p tcp --dport 443 -j DROP

3) Polowanie (hunting)

• Szukaj anomalii w:
  • logach WAF/proxy: nietypowe metody, częste 4xx/5xx, requesty spoza allowlist,
  • FW/IDS: ruch do portów zarządczych z “dziwnych” źródeł,
  • EDR: webserver → shell (jeśli masz).

4) jeżeli podejrzenie kompromitacji

• Odizoluj urządzenie od sieci produkcyjnej (w OT zawsze z oceną wpływu na proces).
• Zabezpiecz logi i artefakty z elementów pośrednich (WAF/FW/jump host).
• Rotuj hasła/poświadczenia powiązane z dostępem administracyjnym i kanałami zdalnymi.
• Rozważ kontrolę integralności konfiguracji (co się zmieniło i kiedy).

Przykłady z kampanii / case studies

• Publiczne materiały dla smartRTU (ICSA-25-105-09 w formacie CSAF) wskazują, iż raportującym był Claroty Team82 (w acknowledgments), a w sekcji “Recommended Practices” pada stwierdzenie o braku znanej publicznej exploitacji ukierunkowanej na tę podatność (na moment publikacji/rewizji).

Lab (bezpieczne testy) — przykładowe komendy

Tylko w odseparowanym labie OT (VLAN/lab), za zgodą właściciela środowiska. Celem jest walidacja ekspozycji i detekcji, nie test exploitów.

Test 1: czy urządzenie/panel jest wystawiony tam, gdzie nie powinien

# skan usług (wersje) – tylko własna sieć/lab nmap -sV -p 80,443 <SMART_RTU_IP>

Test 2: szybka walidacja kontroli dostępu (bez exploitacji)

# sprawdzenie odpowiedzi HTTP nagłówkami (bez “payloadów”) curl -kI https://<SMART_RTU_IP>/

Test 3: walidacja segmentacji (czy blokuje z nieufnego segmentu)

# próba zestawienia TCP z sieci, która NIE powinna mieć dostępu nc -vz <SMART_RTU_IP> 443

Test 4: test reguły “webserver → shell” na hostach (symulacja benign)

Na hoście testowym (reverse proxy / lab VM) uruchom kontrolowany łańcuch procesów, żeby sprawdzić czy SIEM/EDR zareaguje:

# benign: tworzy plik, ale generuje charakterystyczny wzorzec "shell -c" sudo -u www-data /bin/sh -c 'echo healthcheck > /tmp/web-child-test'

Mapowania (Mitigations, Powiązane techniki)

MITRE ATT&CK (ICS) – techniki

• T0819 – Exploit Public-Facing Application (Initial Access)
• T0866 – Exploitation of Remote Services (Initial Access, Lateral Movement)
• T0807 – Command-Line Interface (Execution)

MITRE – przykładowe mitigacje dla T0819 (ICS)

Z karty T0819 jako szczególnie sensowne dla smartRTU:

• M0950 Exploit Protection (np. WAF)
• M0930 Network Segmentation (DMZ/segmentacja usług wystawionych)
• M0948 Application Isolation and Sandboxing (ograniczenie skutków exploitacji)
• M0926 Privileged Account Management (least privilege, kontrola kont uprzywilejowanych)

Powiązane konteksty podatności

• CWE-306 (Missing Authentication for Critical Function) dla CVE-2025-3232
• W tym samym advisory: CVE-2025-3128 (CWE-78, OS Command Injection) – często istotne w analizie łańcucha.

Źródła / dalsza literatura

• NVD: CVE-2025-3232 (opis, CVSS, CWE, daty publikacji) (NVD)
• CISA CSAF: ICSA-25-105-09 JSON (zakres wersji ≤3.37, mitigacje, kontekst, “no known public exploitation…”) (GitHub)
• Mitsubishi Electric Europe: raport PSIRT MEU_PSIRT_2025-3128 (pakiet podatności dla smartRTU) (MITSUBISHI ELECTRIC Europe)
• Claroty disclosure dashboard dla CVE-2025-3232 (zalecenia mitigacyjne w punktach)
• MITRE ATT&CK (ICS): T0819, T0866, T0807 (MITRE ATT&CK)

Checklisty dla SOC / CISO

SOC (operacyjnie)

• Znajdź wszystkie instancje smartRTU i potwierdź wersje (szczególnie ≤ 3.37).
• Zweryfikuj ekspozycję: czy panel/API nie jest dostępny z Internetu.
• Włącz logowanie i korelacje na FW/WAF/proxy (źródło IP, URI, metody, statusy).
• Dodaj reguły “webserver → shell” (jeśli masz telemetrię procesów).
• Ustal allowlistę źródeł administracyjnych i alertuj na odchylenia.

CISO / właściciel ryzyka

• Wymuś model dostępu: VPN + jump host + segmentacja (zamiast bezpośredniej ekspozycji).
• Zdefiniuj kompensacje (WAF, ACL, DMZ) i plan ciągłości działania OT.
• Oceń ryzyko łańcucha z CVE-2025-3128 (jeśli dotyczy Twojego wdrożenia).
• Ustal progi eskalacji (kiedy izolujemy RTU, kiedy zatrzymujemy zdalne zarządzanie).