Co znajdziesz w tym artykule?
- 1 Wprowadzenie do problemu / definicja luki
- 2 W skrócie
- 3 Kontekst / historia / powiązania
- 4 Analiza techniczna / szczegóły luki
- 5 Praktyczne konsekwencje / ryzyko
- 6 Rekomendacje operacyjne / co zrobić teraz
- 7 Różnice / porównania z innymi przypadkami
- 8 Podsumowanie / kluczowe wnioski
- 9 Źródła / bibliografia
Wprowadzenie do problemu / definicja luki
W oprogramowaniu V-SFT (konfigurator HMI dla paneli MONITOUCH firmy Fuji Electric) ujawniono nowy pakiet podatności, które mogą prowadzić do wykonania dowolnego kodu na stacji inżynierskiej po otwarciu specjalnie spreparowanego pliku projektu. Luki dotyczą wersji 6.2.7.0 i starszych i zostały ujęte przez JPCERT/CC pod numerem JVNVU#90008453 (zestaw CVE-2025-61856 … 61864). Producent udostępnił aktualizację do V-SFT 6.2.9.0.
W skrócie
- Wpływ: wykonanie kodu, ujawnienie informacji, awaria aplikacji (ABEND) po otwarciu złośliwego pliku V-SFT.
- Wektor: atak wymaga interakcji użytkownika (socjotechnika / dostarczenie projektu V-SFT).
- Zakres: dotyczy stacji inżynierskich Windows w zespołach OT (inżynierowie HMI/SCADA).
- Łatki: aktualizacja do 6.2.9.0 (strona producenta nie nazywa wprost “security fix”, ale to wersja wskazana przez JPCERT).
Kontekst / historia / powiązania
To kolejny w tym roku pakiet luk w V-SFT. W maju 2025 JPCERT publikował JVNVU#97228144 (CVE-2025-47749 … 47760) dotyczący wersji 6.2.5.0 i starszych – również z ryzykiem RCE po otwarciu plików V7/V8. Zatem obserwujemy ciągłość problemów w parserach formatów projektu V-SFT.
Badacz Michael Heinzl opublikował własne advisories i wskazuje, że w ostatnich miesiącach załatano ponad 20 błędów w tym ekosystemie narzędziowym.
Analiza techniczna / szczegóły luki
Pakiet październikowy (JVNVU#90008453) obejmuje m.in.:
- CVE-2025-61856 – stack-based buffer overflow w
VS6ComFile!CV7BaseMap::WriteV7DataToRom. - CVE-2025-61857 … 61859 – out-of-bounds write w różnych ścieżkach przetwarzania obiektów/animacji.
- CVE-2025-61860 … 61863 – out-of-bounds read w modułach pamięci/serializacji.
- CVE-2025-61864 – use-after-free w
load_link_inf.
Wszystkie ocenione na CVSS v4.0: 8.4 (High) oraz CVSS v3.1: 7.8 (High). Warunkiem skuteczności jest otwarcie spreparowanego pliku przez operatora/inżyniera; wykonanie następuje z uprawnieniami zalogowanego użytkownika.
Zakres wersji: „V-SFT v6.2.7.0 i starsze” – oficjalna nota JPCERT. Producent publikuje „Improvement information” dla 6.2.9.0, która jest wskazywana jako docelowa przez JPCERT, mimo że release notes nie nazywają zmian „security”.
Praktyczne konsekwencje / ryzyko
- Przejęcie stacji inżynierskiej: wykonanie kodu pozwala na instalację narzędzi zdalnego dostępu, kradzież poświadczeń i pivot do sieci OT/IT.
- Łańcuch dostaw projektów HMI: atakujący mogą podszywać się pod integratorów/partnerów i dostarczać „aktualizację” projektu.
- Ataki bezpośrednio na środowisko produkcyjne: choć luki nie „dotykają” bezpośrednio paneli HMI, kompromitacja stacji inżynierskiej zwiększa ryzyko nieautoryzowanej zmiany logiki/ekranu HMI, a w konsekwencji wpływu na proces.
- Niski próg socjotechniczny: wystarczy nakłonić inżyniera do otwarcia pliku.
Rekomendacje operacyjne / co zrobić teraz
- Zaktualizuj V-SFT do 6.2.9.0 na wszystkich stacjach inżynierskich (zgodnie ze wskazaniem JPCERT). Zweryfikuj hash/pochodzenie instalatora.
- Zablokuj uruchamianie projektów z nieznanych źródeł. Wprowadź whitelisting dostawców/projektów HMI.
- Segmentacja OT: stacje inżynierskie w osobnej strefie, dostęp z IT tylko przez jump hosty i MFA.
- Polityka poczty i wymiany plików: sandboxing załączników, skanowanie na bramkach, blokada makr/nietypowych rozszerzeń projektów V-SFT.
- Uprawnienia minimalne: użytkownicy V-SFT bez praw administratora; włącz Application Control/SRP/WDAC.
- Monitoring: reguły EDR/SIEM pod kątem nieoczekiwanego uruchamiania procesów potomnych przez V-SFT, kompilatorów, PowerShell/WSH.
- Testy IR: scenariusz „złośliwy projekt HMI” w planach ćwiczeń blue teamu.
- Przegląd poprzednich ostrzeżeń: jeśli wciąż działają wersje ≤6.2.5.0, zastosuj zalecenia z wcześniejszego JVNVU#97228144.
Różnice / porównania z innymi przypadkami
- Ten sam wektor, nowe prymitywy: zarówno pakiet majowy (CVE-2025-47749…60), jak i październikowy (CVE-2025-61856…64) opierają się na błędach parsowania plików (OOB R/W, UAF, stack overflow), ale uderzają w inne komponenty DLL i ścieżki (np.
CV7BaseMap,CItemDraw,WinFont*). - Ścieżka łatania: w październiku wskazana wersja docelowa to 6.2.9.0; w maju – aktualizacja wyższa niż 6.2.5.0. Ciągła potrzeba aktualizacji podkreśla wagę zarządzania wersjami narzędzi inżynierskich w OT.
- Widoczność po stronie vendorów/CSIRT: SecurityWeek nagłaśnia, JPCERT formalnie koordynuje; CISA wcześniej publikowała advisories dla linii V-SFT/TELLUS, co pokazuje stałe zainteresowanie regulatorów ICS tym ekosystemem.
Podsumowanie / kluczowe wnioski
- Najnowszy pakiet CVE dla V-SFT ≤6.2.7.0 umożliwia RCE po otwarciu pliku; ryzyko wysokie (CVSS v4.0: 8.4).
- Aktualizacja do 6.2.9.0 jest w tej chwili kluczowym środkiem zaradczym, mimo niejednoznacznych not w „Improvement information”.
- Organizacje powinny traktować stacje inżynierskie jak systemy o podwyższonym ryzyku: twarda segmentacja, kontrola źródeł projektów, EDR i polityki wymiany plików.
Źródła / bibliografia
- SecurityWeek: „Fuji Electric HMI Configurator Flaws Expose Industrial Organizations to Hacking”, 16 października 2025. (SecurityWeek)
- JPCERT/CC (JVN): JVNVU#90008453 – Multiple vulnerabilities in FUJI Electric V-SFT, 8 października 2025. (Japan Vulnerability Notes)
- JPCERT/CC (JVN): JVNVU#97228144 – Multiple vulnerabilities in V-SFT, 14 maja 2025. (Japan Vulnerability Notes)
- Fuji Electric / Hakko: Improvement information (V-SFT-6) – lista wersji, w tym 6.2.9.0. (Monitouch)
- aweSEC (Michael Heinzl): lista advisories 2025 z pozycjami dotyczącymi Fuji Electric V-SFT. (awesec.com)