Luki w konfiguratorze HMI Fuji Electric (V-SFT) narażają zakłady przemysłowe na ataki - Security Bez Tabu

Luki w konfiguratorze HMI Fuji Electric (V-SFT) narażają zakłady przemysłowe na ataki

Wprowadzenie do problemu / definicja luki

Fuji Electric udostępniło poprawki dla V-SFT – oprogramowania do tworzenia i konfiguracji interfejsów HMI serii MONITOUCH. Zidentyfikowane luki pozwalają napastnikowi doprowadzić do wycieku informacji, awarii aplikacji (ABEND) lub wykonania dowolnego kodu na stacji inżynierskiej, jeśli użytkownik otworzy złośliwy plik projektu. O podatnościach poinformował badacz Michael Heinzl; koordynację przeprowadziło JPCERT/CC.

W skrócie

  • Produkty: V-SFT (narzędzie konfiguracyjne HMI MONITOUCH).
  • Wersje podatne: do v6.2.7.0 włącznie; producent publikuje wydanie v6.2.9.0.
  • Wektor ataku: otwarcie spreparowanego pliku V-SFT (wymaga socjotechniki). Kod wykonuje się z uprawnieniami zalogowanego użytkownika.
  • Skutki: RCE/DoS/ujawnienie informacji; lokalna skala oddziaływania, ale z konsekwencjami dla całej sieci OT.

Kontekst / historia / powiązania

V-SFT nie po raz pierwszy trafia na listy ostrzeżeń. W latach 2024–2025 CISA kilkukrotnie publikowała porady bezpieczeństwa dla tego ekosystemu (V-SFT i powiązane narzędzia, m.in. Tellus Lite), wskazując na błędy prowadzące do wykonania kodu i zalecając aktualizacje oraz segmentację sieci. Nowe podatności wpisują się w ten ciąg problemów jakościowych.

Analiza techniczna / szczegóły luki

Według JVN (JPCERT/CC) bieżący pakiet obejmuje co najmniej dziewięć CVE w V-SFT ≤ 6.2.7.0, m.in.:

  • CVE-2025-61856 – stack-based buffer overflow w VS6ComFile!CV7BaseMap::WriteV7DataToRom
  • CVE-2025-61857/61858/61859 – out-of-bounds write w różnych funkcjach VS6ComFile
  • CVE-2025-61860/61861/61862/61863 – out-of-bounds read w modułach VS6MemInIF/VS6ComFile/CSaveData
  • CVE-2025-61864 – use-after-free w VS6ComFile!load_link_inf

Dla większości wpisów JVN podaje CVSS v4.0: 8.4 (lokalne/bez uprzywilejowania, interakcja użytkownika wymagana). NVD potwierdza opisy i podkreśla możliwość wykonania kodu po otwarciu specjalnie przygotowanego pliku. (jvn.jp)

Wydanie producenta V-SFT 6.2.9.0 jest dostępne na stronie „Improvement information”, choć nota wersji nie nazywa wprost poprawek bezpieczeństwa – to częsta praktyka w narzędziach OT. Zbieżność wersji i dat wskazuje, że to build łatający opisane CVE.

Praktyczne konsekwencje / ryzyko

Choć wektor jest „lokalny” (wymaga otwarcia pliku na stacji inżynierskiej), skuteczny RCE na EWS/eng. workstation daje atakującemu przyczółek w sieci OT: możliwość podmiany logiki HMI/PLC, kradzieży receptur, pivotu do segmentu IT i przerwania produkcji. Błędy w parserach projektów HMI są szczególnie groźne, bo pliki często krążą e-mailem/USB i bywają otwierane poza ścisłą kontrolą zmian. Źródła branżowe podkreślają konieczność edukacji użytkowników (socjotechnika) w parze z aktualizacjami.

Rekomendacje operacyjne / co zrobić teraz

  1. Zaktualizuj V-SFT do 6.2.9.0 lub nowszej – zgodnie z informacją producenta/JPCERT. Zweryfikuj wersję w całej organizacji (także u integratorów).
  2. Zakaz otwierania projektów z nieznanych źródeł. Wymuś obieg przez repozytorium inżynierskie z kontrolą wersji i podpisem. (Wektor: złośliwy plik projektu).
  3. Aplikacyjna kontrola uruchamiania i whitelisting na stacjach inżynierskich; blokuj procesy niebędące częścią łańcucha V-SFT. Również EDR z trybem tylko-monitoruj (zgodnie z wymaganiami dostawcy OT).
  4. Segmentacja i izolacja EWS (VLAN/zamek jednokierunkowy do IT, brak bezpośredniego Internetu), zasada najmniejszych uprawnień dla kont inżynierskich. Rekomendacje te są zbieżne z wcześniejszymi poradami CISA dla V-SFT.
  5. Kontrole detekcyjne: reguły SIEM/EDR na nietypowe uruchomienia V-SFT i odczyty plików projektu, monitorowanie tworzenia/ładowania DLL VS6*/V10*.
  6. Plan reagowania: w razie incydentu traktuj stację jako skompromitowaną, wykonaj „gold image” i przywróć projekt z zaufanego repozytorium.

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

Wcześniejsze porady CISA z 2024 r. dla V-SFT dotyczyły m.in. type confusion/out-of-bounds write. Obecna seria CVE rozszerza spektrum o stack overflow i use-after-free, ale wektor pozostaje ten sam: plik projektu otwierany przez operatora/inżyniera. Wnioski: nawet po „załataniu” pojedynczych funkcji parser pozostaje obszarem wysokiego ryzyka, wymagając dyscypliny w procedurach otwierania i podpisywania projektów.

Podsumowanie / kluczowe wnioski

  • Nowe CVE w V-SFT ≤ 6.2.7.0 umożliwiają RCE po otwarciu złośliwego projektu; producent udostępnił v6.2.9.0.
  • Stacje inżynierskie to krytyczny punkt bezpieczeństwa OT – jeden klik może przechylić szalę na korzyść napastnika.
  • Aktualizacja + kontrola łańcucha projektów + segmentacja EWS to minimum higieny. Porady CISA pozostają aktualne.

Źródła / bibliografia

  1. SecurityWeek: „Fuji Electric HMI Configurator Flaws Expose Industrial Organizations to Hacking” (16 października 2025). (SecurityWeek)
  2. JVN (JPCERT/CC): „Multiple vulnerabilities in FUJI Electric V-SFT” – lista CVE i metryki CVSS (8 października 2025). (jvn.jp)
  3. NVD: szczegóły wybranych CVE (np. CVE-2025-61856/61860/61859). (NVD)
  4. Fuji Electric – „Improvement information” (lista wersji V-SFT, m.in. 6.2.9.0). (Monitouch)
  5. CISA ICS Advisories dla Fuji Electric V-SFT / Tellus – tło i zalecenia dobrych praktyk ICS (2024–2025). (CISA)