Bejelentés dátuma: 2025.03.25.
Gyártó: ABB
Érintett rendszer(ek):
- Engedélyezett REST interfésszel működő RMC-100 berendezések 2105457-036-tól 2105457-044-ig terjedő verziói;
- Engedélyezett REST interfésszel működő RMC-100 LITE berendezések 2106229-010-től 2106229-016-ig terjedő verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Prototype Pollution (CVE-2022-24999)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-084-01

Bejelentés dátuma: 2025.03.25.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- Verve Asset Manager 1.39-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Validation of Specified Type of Input (CVE-2025-1449)/kritikus;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-084-02

Bejelentés dátuma: 2025.03.25.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- 440G TLS-Z v6.001-es verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Neutralization of Special Elements in Output Used by a Downstream Component (CVE-2020-27212)/súlyos;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-084-03

Bejelentés dátuma: 2025.03.25.
Gyártó: Inaba Denki Sangyo
Érintett rendszer(ek):
- CHOCO TEI WATCHER mini (IB-MCT001) minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Use of Client-Side Authentication (CVE-2025-24517)/súlyos;
- Storing Passwords in a Recoverable Format (CVE-2025-24852)/közepes;
- Weak Password Requirements (CVE-2025-25211)/kritikus;
- Forced Browsing (CVE-2025-26689)/kritikus;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-084-04

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A VLAN-okat sokáig kiválóan megfelelő eszköznek tekintették a hálózatbiztonság megteremtéséhez. Szokás szerint ez előbb az IT hálózatokban vált meghaladott gondolkodássá (bár mind a mai napig lehet olyan IT hálózati mérnökökkel találkozni, akik erről nem hajlandóak tudomást venni, de ezt gondolkodást most talán hadd ne kommentáljam), az ICS/OT világban sokkal később. Én személy szerint életem első, ipari rendszereket (is) érintő konferenciájána, Kuala Lumpurban láttam olyan előadást, ahol az arab (talán egyiptomi?) származású előadó a VLAN-ok alkalmazásáról beszélt, mint OT hálózatok hálózatszegmentálásához használható eszközéről - ez 2014-ben volt, de még manapság is hallani olyan érveket OT hálózatok kapcsán, hogy "de az egy külön VLAN-ban van, ezért van hálózati szeparáció."

Még tavaly novemberben jelent meg egy cikk a LinkedIn-en Andre Froneman tollából, amiben a VLAN hopping, VLAN double tagging, switch spoofing támadások ICS/OT és IoT hálózatok elleni felhasználhatóságáról és ezek kockázatairól szól.

Bejelentés dátuma: 2025.03.11.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- EcoStruxure Panel Server v2.0 és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Insertion of Sensitive Information into Log File (CVE-2025-2002)/közepes;
Javítás: Elérhető
Link a publikációhoz: Schneider Electric, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- EcoStruxure Power Automation System User Interface (EPAS-UI) v2.1-től v2.9-ig (a v2.9 is) terjedő verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Authentication (CVE-2025-0813)/közepes;
Javítás: Elérhető
Link a publikációhoz: Schneider Electric, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- EcoStruxure Power Automation System 2.6.30.19-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Initialization of a Resource with an Insecure Default (CVE-2025-1960)/kritikus;
Javítás: Elérhető
Link a publikációhoz: Schneider Electric, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- Schneider Electric ASCO 5310 Single-Channel Remote Annunciator minden verziója;
- Schneider Electric ASCO 5350 Eight Channel Remote Annunciator minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Download of Code Without Integrity Check (CVE-2025-1058)/súlyos;
- Allocation of Resources Without Limits or Throttling (CVE-2025-1059)/súlyos;
- Cleartext Transmission of Sensitive Information (CVE-2025-1060)/súlyos;
- Unrestricted Upload of File with Dangerous Type (CVE-2025-1070)/súlyos;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: Schneider Electric, ICS-CERT

Bejelentés dátuma: 2025.03.18.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- VMware-en futtatott Industrial Data Center (IDC) 1-től 4-ig tartó generációi;
- VMware-en futtatott VersaVirtual Appliance (VVA) A és B sorozatai;
- VMware-en futtatott Threat Detection Managed Services (TDMS) minden verziója;
- VMware-en futtatott Endpoint Protection Service with RA Proxy minden verziója;
- VMware-en futtatott Engineered and Integrated Solutions minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Time-of-check Time-of-use (TOCTOU) Race Condition (CVE-2025-22224)/kritikus;
- Write-what-where Condition (CVE-2025-22225)/súlyos;
- Out-of-bounds Read (CVE-2025-22226)/súlyos;
Javítás: Nincs információ, a gyártó meg fogja keresni az érintett felhasználókat a kockázatcsökkentés lehetséges módszereiről.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-077-02

Bejelentés dátuma: 2025.03.20.
Gyártó: SMA
Érintett rendszer(ek):
- Sunny Portal minden, 2024.12.19-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Unrestricted Upload of File with Dangerous Type (CVE-2025-0731)/közepes;
Javítás: Megtörtént
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-079-04

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Azok számára, akik IT irányból érkeztek az ICS/OT kiberbiztonság világába, egyáltalán nem újdonság, hogy az ipari rendszerek esetén a titkosított protokollok és kommunikáció használata egyáltalán nem olyan elterjedt, mint az IT rendszerek és hálózatok esetében (ahol ma már gyakorlatilag alig lehet titkosítatlan kommunikációt találni vagy ha mégis, akkor azokat, akik nem használnak titkosítást, minimum súlyosan felelőtlennek tartja a szakma jelentős része).

Az ICS/OT rendszerek esetében azonban gyorsan szembesülhet az ember azzal, hogy a titkosítás hiánya nem a felelőtlenség vagy a tudatlanság egyértelmű megnyilvánulása, sokkal inkább az eltérő szemléletből és eltérő prioritásokból következik. Valamikor régen én is írtam arról, hogy az IT világban megszokott Confidentiality-Integrity-Availability biztonsági "szentháromság" az ICS/OT világban egyrészt három helyett 5 szempontból áll és a bizalmasság még csak nincs is ebből az ötből a fontosabbak között. A legfontosabb biztonsági szempont egyértelműen a safety, a vezérelt folyamatokkal kapcsolatban kerülő emberek illetve a környezet biztonsága (hogy ne sérüljön vagy haljon meg senki és ne történjen környezetszennyezés) illetve a folyamat biztonsága (process safety, hogy a vezérelt folyamat az elvárások szerint működjön). A második a fontossági sorban már vitatható, bizonyos esetekben a folyamatirányítással kapcsolatos adatok megbízhatósága (reliability), más esetekben a rendelkezdésre állás következik. Harmadikként jön a "másik", majd még mindig a folyamatirányítási adatok sértetlensége és csak ötödik helyen beszélhetünk ezeknek az adatoknak a bizalmasságáról (kivéve azokat az eseteket, amikor pl. egy gyógyszergyár esetén az új készítmény receptúrája olyan szintű értéket képvisel a versenypiacon, hogy ennek az információnak a védelmén nem csak a vállalat jövedelmezősége, de adott esetben a fennmaradása is múlhat).

Fentiekből következik, hogy az ICS/OT rendszerek esetén más szempontrendszer szerint kell vizsgálni, hogy az egyes ICS komponensek közötti kommunikációk titkosításának milyen pozitív és negatív következményei lehetnek?

- Titkosított OT hálózati kommunikáció esetén nehezebben (vagy éppen sehogy sem) tudjuk azonosítani a működési problémákat;
- Tudván, hogy az ICS/OT rendszerek IT-tól jelentősen eltérő (hosszabb) életciklussal rendelkeznek, a különböző titkosítási algoritmusok az IT-ban megszokottnál sokkal gyakrabban okozhatnak sokkal komolyabb kompatibilitási problémákat - mindezt olyan környezetekben, ahol egy leállás akár percek alatt is súlyos milliókban (és nem feltétlenül magyar Forintban számolt milliókban!) mérhető veszteségeket generálhatnak;
- Még mindig az ICS/OT berendezések életciklusánál, illetve az IT rendszerekénél sokkal inkább az adott célra történő tervezésénél/építésénél maradva, egyáltalán nem kizárt, hogy egy adott ICS berendezésben nincsenek meg a titkosított protokollok használatához szükséges plusz teljesítmény tartalékai - hardveresen. Ilyenkor pedig nincs más mód, mint a teljes (egyébként funkcionális szempontból tökéletesen működő) berendezést cserélni - aminek viszont ismét súlyos dollár/Euró tíz- vagy százezrekben mérhető hatása lesz.
- A kommunikáció küldő oldalon történő betitkosítása, majd a fogadó oldalon a titkosítás visszafejtése időigényes. IT oldalon az a néhány tized- vagy századmásodperc, amibe ez a be-, majd kititkosítás kerül, nem igazán szokott számítani, de az ipari folyamatirányításban gyakran nem csak tized- vagy századmásodperceken múlhat egy igen súlyos következmény, de például a villamosenergia-iparban már nem csak milisecundumos, hanem microsecundumos válaszidő követelményekről is hallottam. Évekkel ezelőtt...
- A fentiek után az, hogy ha az ICS/OT rendszerekben az IT hálózatokhoz hasonlóan mindenhol titkosítanánk minden kommunikációt, elveszítenénk a még leginkább elfogadott, hálózati forgalom-figyelésen alapuló monitoring megoldás használhatóságát.

Mi is akkor a megoldás? Titkosítsuk vagy sem a kommunikációt ICS/OT rendszerekben?

A válasz szerintem, mint oly sokszor ebben a világban, nem fekete vagy fehér, hanem "attól függ".

Olvastam veterán folyamatirányítás mérnököktől olyan véleményt, hogy ha vezetéknélküli kommunikációt használunk ipari környezetben, használjunk titkosítást. Ha különböző biztonsági szintű hálózati zónák közötti kommunikációról van szó, használjunk titkosítást, de ha ugyanazon a biztonsági szinten lévő zónán belüli kommunikációról van szó, ne küzdjünk a titkosítással/titkosításért, főleg, mert gyakran akadályozhatja majd a különböző diagnosztikai vizsgálatokat.

Én emellett úgy gondolom, a válasz főleg attól függ, mennyire értékes az információ, amit át akarunk küldeni egyik ICS komponenstől a másiknak, mekkora a kockázata annak, ha egy illetéktelen harmadik fél (akár ártó szándékkal) megismerheti a kommunikáció tárgyát képező információt? Ha ezeknél az adatoknál a a bizalmassági követelmény nem értelmezhető vagy a kockázat az adatgazda szerint elhanyagolható vagy az elfogadható szint alatt marad, érdemesebb lehet nem küzdeni a titkosítással.

Viszont, ha az adatok bizalmassága bármilyen szempontból fontos a folyamatvezérlésért felelős szakembereknek vagy olyan adatokról van szó, amiket minden körülmények között védeni kell (pl. a folyamatirányító rendszerekbe történő bejelentkezéshez használt jelszavak vagy privát kulcsok védelme), akkor meg kell fontolni a titkosítás alkalmazását. Ilyenkor következhet egy olyan, minden fontos szempontra kiterjedő hatásvizsgálat, amibe legalább annyira fontos (ha nem fontosabb) bevonni a folyamatirányítási mérnök kollégákat, mint a biztonságért felelős szakembereket.

Jake Brodsky-tól olvastam egy nagyszerű gondolatot a témában: Az OT biztonság feladata, hogy fejlessze az OT rendszerek rendelkezésre állását [az én értelmezésemben az ellenálló-képességét], nem pedig az, hogy hátráltassa azt. Ha a biztonsági szakemberek [vagyis mi] ezt nem veszik figyelembe, csak ártani fognak, nem segíteni."

Bejelentés dátuma: 2025.03.06.
Gyártó: Moxa
Érintett rendszer(ek):
- PT-508 sorozatú eszközök 3.8-as és korábbi firmware-verziói;
- PT-510 sorozatú eszközök 3.8-as és korábbi firmware-verziói;
- PT-7528 sorozatú eszközök 5.0 és korábbi firmware-verziói;
- PT-7728 sorozatú eszközök 3.9-es és korábbi firmware-verziói;
- PT-7828 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- PT-G503 sorozatú eszközök 5.3-as és korábbi firmware-verziói;
- PT-G510 sorozatú eszközök 6.5-ös és korábbi firmware-verziói;
- PT-G7728 sorozatú eszközök 6.5-ös és korábbi firmware-verziói;
- PT-G7828 sorozatú eszközök 6.5-ös és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Reliance on Security Through Obscurity (CVE-2024-12297)/kritikus;
Javítás: Elérhető a Moxa Technical Support-nál.
Link a publikációhoz: Moxa

Bejelentés dátuma: 2025.03.11.
Gyártó: ABB
Érintett rendszer(ek):
- RMC-100-as 2105457-036-tól 2105457-044-ig tartó verziói;
- RMC-100 LITE 2106229-010-től 2106229-016-ig tartó verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Proto-type Pollution (CVE-2022-24999)/súlyos;
Javítás: Elérhető
Link a publikációhoz: ABB

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Teamcenter Visualization V14.3 V14.3.0.13-nál korábbi verziói;
- Teamcenter Visualization V2312 V2312.0009-nél korábbi verziói;
- Teamcenter Visualization V2406 V2406.0007-nél korábbi verziói;
- Teamcenter Visualization V2412 V2412.0002-nél korábbi verziói;
- Tecnomatix Plant Simulation V2302 V2302.0021-nél korábbi verziói;
- Tecnomatix Plant Simulation V2404 V2404.0010-nél korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Out-of-bounds Write (CVE-2025-23396)/súlyos;
- Improper Restriction of Operations within the Bounds of a Memory Buffer (CVE-2025-23397)/súlyos;
- Improper Restriction of Operations within the Bounds of a Memory Buffer (CVE-2025-23398)/súlyos;
- Out-of-bounds Read (CVE-2025-23399)/súlyos;
- Improper Restriction of Operations within the Bounds of a Memory Buffer (CVE-2025-23400)/súlyos;
- Out-of-bounds Read (CVE-2025-23401)/súlyos;
- Use After Free (CVE-2025-23402)/súlyos;
- Out-of-bounds Read (CVE-2025-27438)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- SINEMA Remote Connect Server V3.2 SP3-nál korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Output Neutralization for Logs (CVE-2024-5594)/közepes;
- Missing Release of Resource after Effective Lifetime (CVE-2024-28882)/közepes;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- SIMATIC S7-1500 TM MFP - BIOS minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Double Free (CVE-2024-41046)/közepes;
- Use After Free (CVE-2024-41049)/súlyos;
- NULL Pointer Dereference (CVE-2024-41055)/közepes;
- Buffer Access with Incorrect Length Value (CVE-2024-42154)/közepes;
- Use of Uninitialized Variable (CVE-2024-42161)/súlyos;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Siemens SiPass integrated AC5102 (ACC-G2) minden, V6.4.9-nél korábbi verziója;
- Siemens SiPass integrated ACC-AP minden, V6.4.9-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Missing Authentication for Critical Function (CVE-2024-52285)/közepes;
- Improper Input Validation (CVE-2025-27493)/súlyos;
- Improper Input Validation (CVE-2025-27494)/kritikus;
Javítás: Részben elérhető.
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Siemens SINAMICS S200 minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Authentication (CVE-2024-56336)/kritikus;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- SCALANCE LPE9403 (6GK5998-3GS00-2AC2) V4.0-nál korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- OS Command Injection (CVE-2025-27392)/súlyos;
- OS Command Injection (CVE-2025-27393)/súlyos;
- OS Command Injection (CVE-2025-27394)/súlyos;
- Path Traversal (CVE-2025-27395)/súlyos;
- Improper Check for Dropped Privileges (CVE-2025-27396)/súlyos;
- Path Traversal (CVE-2025-27397)/alacsony;
- OS Command Injection (CVE-2025-27398)/alacsony;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Siemens SCALANCE SC-600 family minden verziója;
- Siemens RUGGEDCOM RM1224 LTE(4G) EU (6GK6108-4AM00-2BA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M876-3 (6GK5876-3AA02-2BA2): vers minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M876-3 (ROK) (6GK5876-3AA02-2EA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M876-4 (6GK5876-4AA10-2BA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M876-4 (EU) (6GK5876-4AA00-2BA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M876-4 (NAM) (6GK5876-4AA00-2DA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUB852-1 (A1) (6GK5852-1EA10-1AA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUB852-1 (B1) (6GK5852-1EA10-1BA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM853-1 (A1) (6GK5853-2EA10-2AA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM853-1 (B1) (6GK5853-2EA10-2BA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM853-1 (EU) (6GK5853-2EA00-2DA1) minden, V8.2.1-nél korábbi verziója;
- Siemens RUGGEDCOM RM1224 LTE(4G) NAM (6GK6108-4AM00-2DA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM856-1 (A1) (6GK5856-2EA10-3AA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM856-1 (B1) (6GK5856-2EA10-3BA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM856-1 (CN) (6GK5856-2EA00-3FA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM856-1 (EU) (6GK5856-2EA00-3DA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE MUM856-1 (RoW) (6GK5856-2EA00-3AA1) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE S615 EEC LAN-Router (6GK5615-0AA01-2AA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE S615 LAN-Router (6GK5615-0AA00-2AA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M804PB (6GK5804-0AP00-2AA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M812-1 ADSL-Router family minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M816-1 ADSL-Router family minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M826-2 SHDSL-Router (6GK5826-2AB00-2AB2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M874-2 (6GK5874-2AA00-2AA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M874-3 3G-Router (CN) (6GK5874-3AA00-2FA2) minden, V8.2.1-nél korábbi verziója;
- Siemens SCALANCE M874-3 (6GK5874-3AA00-2AA2) minden, V8.2.1-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Partial String Comparison (CVE-2025-23384)/alacsony;
Javítás: Részben elérhető.
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Siemens Tecnomatix Plant Simulation V2302 minden, V2302.0021-nél korábbi verziója;
- Siemens Tecnomatix Plant Simulation V2404 minden, V2404.0010-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Files or Directories Accessible to External Parties (CVE-2025-25266)/közepes;
- Files or Directories Accessible to External Parties (CVE-2025-25267)/közepes;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Industrial Edge for Machine Tools (korábbi nevén "SINUMERIK Edge") minden verziója;
- SIMIT V11 minden verziója;
- SIMATIC BRAUMAT minden, V8.0 SP1-től V8.1-ig terjedő verziója;
- SIMATIC Energy Manager PRO minden, V7.5-től V7.5 Update 2-ig terjedő verziója;
- SIMATIC Energy Manager PRO minden V7.2 Update 6 utáni verziója;
- SIMATIC IPC DiagMonitor minden verziója;
- SIMATIC SISTAR minden, V8.0 SP1-től V8.1-ig terjedő verziója;
- SIMATIC WinCC Unified V18 minden verziója;
- SIMATIC WinCC Unified V19 minden, V19 Update 4-nél korábbi verziója;
- SIMATIC WinCC V8.0 minden, V8.0 Update 3-nál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Observable Timing Discrepancy (CVE-2024-42512)/súlyos;
- Authentication Bypass by Primary Weakness (CVE-2024-42513)/kritikus;
Javítás: Részben elérhető.
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Siemens SINEMA Remote Connect Client minden, V3.2 SP3-nál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Integer Overflow or Wraparound (CVE-2024-1305)/kritikus;
- Unprotected Alternate Channel (CVE-2024-4877)/közepes;
- Improper Restriction of Communication Channel to Intended Endpoints (CVE-2024-24974)/súlyos;
- Stack-based Buffer Overflow (CVE-2024-27459)/súlyos;
- Unrestricted Upload of File with Dangerous Type (CVE-2024-27903)/kritikus;
- Missing Release of Resource after Effective Lifetime (CVE-2024-28882)/közepes;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.11.
Gyártó: Siemens
Érintett rendszer(ek):
- Siemens SIMATIC Field PG M5 minden verziója;
- Siemens SIMATIC IPC377G minden verziója;
- Siemens SIMATIC IPC427E minden verziója;
- Siemens SIMATIC IPC477E minden verziója;
- Siemens SIMATIC IPC477E PRO minden verziója;
- Siemens SIMATIC IPC527G minden verziója;
- Siemens SIMATIC IPC627E minden, 25.02.15-nél korábbi verziója;
- Siemens SIMATIC IPC647E25.02.15-nél korábbi verziói;
- Siemens SIMATIC IPC677E25.02.15-nél korábbi verziói;
- Siemens SIMATIC IPC847E25.02.15-nél korábbi verziói;
- Siemens SIMATIC IPC3000 SMART V3 minden verziója;
- Siemens SIMATIC Field PG M6 V26.01.12-nél korábbi verziói; (CVE-2024-56182)
- Siemens SIMATIC IPC BX-21A V31.01.07-nél korábbi verziói;
- Siemens SIMATIC IPC BX-32A V29.01.07-nél korábbi verziói;
- Siemens SIMATIC IPC BX-39A V29.01.07-nél korábbi verziói;
- Siemens SIMATIC IPC BX-59A V32.01.04-nél korábbi verziói;
- Siemens SIMATIC IPC PX-32A V29.01.07-nél korábbi verziói;
- Siemens SIMATIC IPC PX-39A V29.01.07-nél korábbi verziói;
- Siemens SIMATIC IPC PX-39A PRO V29.01.07-nél korábbi verziói;
- Siemens SIMATIC IPC RC-543B minden verziója;
- Siemens SIMATIC IPC RW-543A minden verziója;
- Siemens SIMATIC ITP1000 minden verziója;
- Siemens SIMATIC IPC127E minden verziója;
- Siemens SIMATIC IPC277G PRO minden verziója;
- Siemens SIMATIC IPC227E minden verziója;
- Siemens SIMATIC IPC227G minden verziója;
- Siemens SIMATIC IPC277E minden verziója;
- Siemens SIMATIC IPC277G minden verziója;
- Siemens SIMATIC IPC327G minden verziója;
- Siemens SIMATIC IPC347G minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Protection Mechanism Failure (CVE-2024-56181)/súlyos;
- Protection Mechanism Failure (CVE-2024-56182)/súlyos;
Javítás: Részben elérhető.
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2025.03.13.
Gyártó: Siemens
Érintett rendszer(ek):
- Simcenter Femap V2401 minden, V2401.0003-nál korábbi verziója;
- Simcenter Femap V2406 minden, V2406.0002-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Restriction of Operations within the Bounds of a Memory Buffer (CVE-2025-25175)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT

Bejelentés dátuma: 2025.03.13.
Gyártó: Sungrow
Érintett rendszer(ek):
- iSolarCloud Android App 2.1.6-os és korábbi verziói;
- WiNet Firmware minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Certificate Validation (CVE-2024-50691)/közepes;
- Use of a Broken or Risky Cryptographic Algorithm (CVE-2024-50684)/közepes;
- Authorization Bypass Through User-Controlled Key (CVE-2024-50685)/közepes;
- Authorization Bypass Through User-Controlled Key (CVE-2024-50693)/súlyos;
- Authorization Bypass Through User-Controlled Key (CVE-2024-50689)/súlyos;
- Authorization Bypass Through User-Controlled Key (CVE-2024-50686)/közepes;
- Authorization Bypass Through User-Controlled Key (CVE-2024-50687)/közepes;
- User of Hard-Coded Credentials (CVE-2024-50688)/közepes;
- User of Hard-Coded Credentials (CVE-2024-50692)/súlyos;
- User of Hard-Coded Password (CVE-2024-50690)/közepes;
- Stack-Based Buffer Overflow (CVE-2024-50694)/súlyos;
- Stack-Based Buffer Overflow (CVE-2024-50697)/súlyos;
- Stack-Based Buffer Overflow (CVE-2024-50695)/súlyos;
- Heap-Based Buffer Overflow (CVE-2024-50698)/súlyos;
- Download of Code without Integrity Check (CVE-2024-50696)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-072-12

A sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Nemrég egy egészen érdekes cikket találtam a Tripwire oldalán, amiben a naperőművek elleni lehetséges kibetámadásokat mutatják be. Elsősorban az invertereket említik, amik ugye a DC-AC konverziót végzik és amiket ma már egy bármilyen okostelefonról, távolról lehet ellenőrizni, hogy működik-e és éppen mennyit termel egy-egy inverter, mindehhez pedig csak egy (WiFi- vagy UTP-kapcsolaton keresztül) egy Internet-hozzáférésre van szükség az inverter oldalán. Ez pedig rögtön el is hozza az első támadási vektort az inverterekkel kapcsolatban, hiszen az a távoli hozzáférés, amin keresztül a tulajdonos képes felügyelni az inverterét, az (a még nem ismert vagy már ismert, de nem javított) sérülékenységen keresztül a támadóknak is elérhetővé válik.

A második fontosabb téma a microgrid-ek vagy energiaközösségek kérdése, amikor egy-egy kisebb közösség (Európában például néhány háztömb) összefog és így nem csak a naperőmű(vek) környezetbarát villamosenergia-termelését oldják meg, hanem egy fokkal (talán?) jobban meg lehet oldani a rendszer egyensúlyban tartását - mondjuk ehhez nem értek, ezt talán majd kifejtik az itt néha megforduló villamosmérnök kollégák. Viszont a microgrid-ekhez/energiaközösségekhez csatlakoztatott IoT eszközök tovább növelik a napelemes rendszerek biztonsági kockázatait.

A cikkben említett harmadik támadási vektort a DoS-támadások jelentik, amikkel a napelemes rendszerek működését változatos módokon lehet hatékonyan megzavarni.

Ezeket a kockázatokat hozza a cikk, de én is hozzá tudok tenni még néhány gondolatot a saját szakmai tapasztalataim alapján:

Az első gondolatom arra vonatkozik, hogy az ipari méretű naperőművek (amik jellemzően sok száz kW-os vagy akár több tíz MW-os termelési kapacitással rendelkeznek) esetén a létesítést végző cégek ugyanazokat az inverter típusokat használják (persze egy darab helyett több tucatnyi vagy akár százas nagyságrendben), mint amiket a Háztartási Méretű Kis Erőművek (HMKE-k) esetén az átlagember otthonába is beépítenek. Ráadásul ezeket az erőműveket gyakran minden komolyabb hálózatbiztonsági/határvédelmi intézkedés nélkül üzemeltetnek távolról, természetesen az Interneten keresztül. Na most, ha végiggondoljuk azt, hogy egy-egy ilyen inverternél milyen gyakran látunk elérhető firmware-frissítést (nekem 2 invertem is van, 2 különböző gyártó modelljei, évek óta üzemelnek és még soha nem láttam, hogy lenne hozzájuk elérhető, telepíthető firmware-frissítés...), akkor sejthetjük a választ arra a kérdésre, hogy vajon van-e ezekben kihasználható sérülékenység?

Ha pedig abból a gondolatkísérletből indulunk ki, hogy ma Magyarországon (de egyébként az EU-s dekarbonizációs törekvések miatt a többi európai ország nagyrészében is) mekkora naperőművi termelői kapacitás van ilyen (vagy nagyon hasonló) módon kiépítve, akkor már sejthetjük, hogy egy jól szervezett (APT) támadónak nem lenne túl nehéz dolga tömegével kompromittálni a nagyobb naperőművek (vagy akár sok-sok ezer HMKE) invertereit. Így pedig már ott is van a lehetőség a kezükben, hogy egy verőfényes május-június-júliusi napon, amikor (a tavalyi publikációk szerint) Magyarországon akár 1 GW-nál nagyobb volt a naperőművi termelés az országban, hogy jelentős ellátásbiztonsági problémát okozzanak az elosztói- és átviteli rendszerirányítók számára.

Ráadásul a kormányzat nemrég nyilvánosságra hozott tervei szerint kötelezni fogják a HMKE-k tulajdonosait is, hogy központilag monitorozhatóvá tegyék az invertereiket, vagyis ezután már minden inverter biztosan elérhető lesz az Internetről.

Eddig ugye kifejezetten a naperőművekről írtam, de viszonylag kis módosításokkal ugyanezt a szélerőművekre is alkalmazni lehet.

Mik a Tripwire cikk javaslatai a kockázatok csökkentésére?

1. Biztonságtudatossági oktatás: a szerző szerint a HMKE-k tulajdonosait és a nagyobb naperőművek üzleti vezetőit kell képezni a témában.

(Szerintem egyébként nem is igazán a tulajdonosokat - legyenek azok magánemberek vagy üzleti vezetők - kell képezni, hanem pl. a létesítést végző cégeknek kéne megtanítani, hogy mit tudnak tenni a saját hatáskörükben.)

2. Szoftverfrissítések rendszeres telepítése - elvileg az inverterek gyártóinak van lehetőségük arra, hogy Over-The-Air (vagyis a felhasználó beavatkozása nélkül) töltsenek fel patch-eket az inverterekre, de én azért erősen szkeptikus vagyok azzal kapcsolatban, hogy azok a (főleg kínai) gyártók, akik az inverterekhez hasonlóan a legtöbb IoT eszközt is gyártják, fognak ezzel foglalkozni...

3. Hatékony tűzfalas védelem alkalmazása - ez kéne, hogy legyen az alap, de az én tapasztalataim szerint ezt még a 40-50 MW-os naperőművek esetén sem teszik meg (részben a beruházó cég költségminimalizáló hozzáállása miatt), ráadásul nem is csak a tűzfal beszerzése és beüzemelése jelentene költséget, hanem utána a tűzfal üzemeltetése is hónapról-hónapra kiadásként jelentkezne. Éppen ezért nem csak a HMKE-k esetén, de még nagy (közvetlenül vagy virtuális erőművön/szabályozóközponton keresztül az átviteli rendszerirányítóval kapcsolatban lévő) naperőművek esetén is láttam már olyat, hogy maximum egy all-in-one hálózati eszköz volt az egyetlen védvonal a naperőmű inverterei és az Internet között. A rajta futó ACL-ről meg inkább ne is beszéljünk.

Összességében a naperőművek ICS/OT biztonságán bőven lenne mit fejleszteni, ha van rá igény, később még születhet poszt a témában.

Bejelentés dátuma: 2025.03.04.
Gyártó: Carrier
Érintett rendszer(ek):
- Block Load HVAC terhelés-kalkuláló alkalmazás 4.00 és v4.10-től 4.16-ig terjedő verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Uncontrolled Search Path Element (CVE-2024-10930)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-01

Bejelentés dátuma: 2025.03.04.
Gyártó: Keysight
Érintett rendszer(ek):
- Ixia Vision termékcsalád 6.3.1-es verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Path Traversal (CVE-2025-24494)/súlyos;
- Improper Restriction of XML External Entity Reference (CVE-2025-24521)/közepes;
- Path Traversal (CVE-2025-21095)/közepes;
- Path Traversal (CVE-2025-23416)/közepes;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-02

Bejelentés dátuma: 2025.03.04.
Gyártó: Hitachi Energy
Érintett rendszer(ek):
- MACH PS700 v2-es verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Uncontrolled Search Path Element (CVE-2023-28388)/közepes;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-03

Bejelentés dátuma: 2025.03.04.
Gyártó: Hitachi Energy
Érintett rendszer(ek):
- XMC20 R15A és korábbi verziói (beleértve az alverziókat is);
- XMC20 R15B verziója;
- XMC20 R16A verziója;
- XMC20 R16B C revíziója (cent2_r16b04_02, co5ne_r16b04_02) és korábbi verziói (beleértve az alverziókat is);
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Relative Path Traversal (CVE-2024-2461)/közepes;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-04

Bejelentés dátuma: 2025.03.04.
Gyártó: Hitachi Energy
Érintett rendszer(ek):
- XMC20 R16B-nél korábbi verziói;
- ECST 16.2.1-nél korábbi verziói;
- UNEM R15A-nál korábbi verziói;
- UNEM R15A;
- UNEM R15B PC4 és korábbi verziói;
- UNEM: R16A;
- UNEM: R16B PC2 és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Validation of Certificate with Host Mismatch (közepes);
Javítás: Részben elérhető.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-05

Bejelentés dátuma: 2025.03.04.
Gyártó: Delta Electronics
Érintett rendszer(ek):
- CNCSoft-G2 HMI V2.1.0.10-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Heap-based Buffer Overflow (CVE-2025-22881)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-06

Bejelentés dátuma: 2025.03.04.
Gyártó: GMOD
Érintett rendszer(ek):
- Apollo minden, 2.8.0-nál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Incorrect Privilege Assignment (CVE-2025-21092)/közepes;
- Relative Path Traversal (CVE-2025-23410)/kritikus;
- Missing Authentication for Critical Function (CVE-2025-24924)/kritikus;
- Generation of Error Message Containing Sensitive Information (CVE-2025-20002)/közepes;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-07

Bejelentés dátuma: 2025.03.04.
Gyártó: Edimax
Érintett rendszer(ek):
- IC-7100 IP kamerák minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- OS Command Injection (CVE-2025-1316)/kritikus;
Javítás: Nincs információ.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-063-08

Bejelentés dátuma: 2025.03.06.
Gyártó: Moxa
Érintett rendszer(ek):
- PT-508 sorozatú eszközök 3.8-as és korábbi firmware-verziói;
- PT-510 sorozatú eszközök 3.8-as és korábbi firmware-verziói;
- PT-7528 sorozatú eszközök 5.0 és korábbi firmware-verziói;
- PT-7728 sorozatú eszközök 3.9-es és korábbi firmware-verziói;
- PT-7828 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- PT-G503 sorozatú eszközök 5.3-as és korábbi firmware-verziói;
- PT-G510 sorozatú eszközök 6.5-ös és korábbi firmware-verziói;
- PT-G7728 sorozatú eszközök 6.5-ös és korábbi firmware-verziói;
- PT-G7828 sorozatú eszközök 6.5-ös és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Reliance on Security Through Obscurity (CVE-2024-12297)/kritikus;
Javítás: A sérülékenység okozta kockázatok kezelésével kapcsolatban a Moxa support tud részletekkel szolgálni.
Link a publikációhoz: Moxa

Bejelentés dátuma: 2025.03.06.
Gyártó: Hitachi Energy
Érintett rendszer(ek):
- PCU400 6.5 K és korábbi verziói;
- PCU400 9.4.1 és korábbi verziói;
- PCULogger 1.1.0 és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Type Confusion (CVE-2023-0286)/súlyos;
- NULL Pointer Dereference (CVE-2023-0217)/súlyos;
- NULL Pointer Dereference (CVE-2023-0216)/súlyos;
- NULL Pointer Dereference (CVE-2023-0401)/súlyos;
- Use After Free (CVE-2023-0215)/súlyos;
- Double Free (CVE-2022-4450)/súlyos;
- Observable Discrepancy (CVE-2022-4304)/közepes;
- Out-of-bounds Read (CVE-2022-4203)/közepes;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-065-01

Bejelentés dátuma: 2025.03.06.
Gyártó: Hitachi Energy
Érintett rendszer(ek):
- Relion 670/650 sorozatú eszközök 2.2.0 verziójának minden revíziója;
- Relion 670/650/SAM600-IO sorozatú eszközök 2.2.1 verziójának minden, 2.2.1.8-nál korábbi revíziója;
- Relion 670 sorozatú eszközök 2.2.2 verziójának minden, 2.2.2.5-nél korábbi revíziója;
- Relion 670 sorozatú eszközök 2.2.3 verziójának minden, 2.2.3.4-nél korábbi revíziója;
- Relion 670/650 sorozatú eszközök 2.2.4 verziójának minden, 2.2.4.3-nál korábbi revíziója;
- Relion 670/650/SAM600-IO sorozatú eszközök 2.2.5 verziójának minden, 2.2.5.1-ig tartó revíziója;
- Relion 670/650 sorozatú eszközök 2.1 verziójának minden, 2.1.0.5-nél korábbi revíziója;
- Relion 670 sorozatú eszközök 2.0 minden, 2.0.0.14-nél korábbi revíziója;
- Relion 650 sorozatú eszközök 1.3 verziójának minden, 1.3.0.8-nál korábbi revíziója;
- Relion 650 sorozatú eszközök 1.2 verziójának minden revíziója;
- Relion 650 sorozatú eszközök 1.1 verziójának minden revíziója;
- Relion 650 sorozatú eszközök 1.0 verziójának minden revíziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Handling of Insufficient Privileges (CVE-2021-35534)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-065-02

Bejelentés dátuma: 2025.03.11.
Gyártó: Optigo Networks
Érintett rendszer(ek):
- Visual BACnet Capture Tool 3.1.2rc1-es verziója;
- Optigo Visual Networks Capture Tool 3.1.2rc11-es verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Use of Hard-coded (CVE-2025-2079)/súlyos;
- Security-relevant Constants (CVE-2025-2080)/kritikus;
- Authentication Bypass Using an Alternate Path or Channel (CVE-2025-2081)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-070-02

Bejelentés dátuma: 2025.03.11.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- Schneider Electric Uni-Telway Driver minden verziója;
- Schneider Electric Uni-Telway Driver installed on Control Expert minden verziója;
- Schneider Electric Uni-Telway Driver installed on Process Expert minden verziója;
- Schneider Electric Uni-Telway Driver installed on Process Expert for AVEVA System Platform minden verziója;
- Schneider Electric Uni-Telway Driver installed on OPC Factory Server minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Input Validation (CVE-2024-10083)/közepes;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-070-01

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Egy hónapja sincs, hogy a kiberbiztonsági szakmában széles körben ismert és használt (azt most hagyjuk, hogy szerintem mennyire pontos és hasznos) Gartner Magic Quadrant kiadvány-sorozatának új tagjaként megjelent a Cyber-Physical Systems Protection Platform nevű rész. 

Ez ugyan önmagában is érdekes hír lehet, de ami nekem igazán érdekessé tette, hogy Dale Peterson is írt erről a kiadványról a blogján. Dale igen régóta foglalkozik az OT hálózatmonitoring megoldások fejlődésével, így az ő véleménye számomra kellően hitelesnek tűnik. Dióhéjban: Dale szerint a Gartner által felsorolt 5 piacvezető gyártó közül 4-et (Claroty, Dragos, Nozomi és az Armis) helyesen emeltek ki, az ötödiket azonban (a Microsoft-ot) nem. A kategória elnevezését viszont kifejezetten rossznak gondolja, ahogy a piacvezető kategórián kívül az összes többinek sem látja sok értelmét.

Bejelentés dátuma: 2025.02.22.
Gyártó: Moxa
Érintett rendszer(ek):
- TN-G4500 sorozatú eszközök 5.3-as és korábbi firmware-verziói;
- TN-G6500 sorozatú eszközök 5.4-es és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Out-of-bounds Write (CVE-2024-7695)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Moxa

Bejelentés dátuma: 2025.02.25.
Gyártó: Hitachi Energy
Érintett rendszer(ek):
- Gateway Station 3.0.0.0-tól 3.3.0.0-ig terjedő verziói;
- Gateway Station 2.1.0.0 verziója;
- Gateway Station 2.2.0.0-tól 2.4.0.0-ig terjedő verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Neutralization of Special Elements in Data Query Logic (CVE-2024-4872)/kritikus;
- Path Traversal (CVE-2024-3980)/kritikus;
- Authentication Bypass by Capture-replay (CVE-2024-3982)/súlyos;
- Missing Authentication for Critical Function (CVE-2024-7940)/súlyos;
Javítás: Nincs információ.
Link a publikációhoz: Hitachi Energy

Bejelentés dátuma: 2025.02.25.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- PowerFlex 755-ös rendszerek 16.002.279-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Cleartext Transmission of Sensitive Information (CVE-2025-0631)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-25-056-01

Bejelentés dátuma: 2025.02.24.
Gyártó: MITRE
Érintett rendszer(ek):
- Caldera minden, 35bc06e commit-jánál korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Remote Code Execution (CVE-2025-27364)/kritikus;
Javítás: Elérhető
Link a publikációhoz: medium.com

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Még mindig S4x25 - ugyan Sarah Fluchs előadását nem láttam Tampában, de ott jelentette be, hogy az Admerita nevű német cég (ahol Sarah a CTO) egy új, Cyber Decision Diagrams (CDD) nevű, ingyenesen elérhető, webes eszközt tett elérhetővé.

Az eszköz (az Admerita publikációja szerint) nem tárol semmilyen adatot, amit a felhasználók a weboldalon megadnak, az elkészült diagrammokat pedig PDF-formátumban lehet letölteni későbbi felhasználásra.

Az új eszköz 5 lépésen vezeti végig a felhasználót, meg kell határozni egy nagy hatású eseményt (high-consequence event, HCE), ami a legrosszabb forgatókönyvet feltételezi. Következő lépésként meg kell adni azt a valós világban megfogható rendszert, ami a lehet legközelebb van a HCE-hez és ami lehet egy kliens számítógép, egy mezőgép, SCADA vagy DCS rendszer, egy vezérlő vagy más eszköz.

A következő lépésben további kapcsolódó elemeket kell hozzáadni (más rendszerek, szerepkörök, mint üzemeltető, külső szolgáltató, felhasználó, folyamatirányítási mérnök, stb.), majd a negyedik lépésben definiálni kell azokat a támadási vektorokat, amikkel a leghatékonyabban lehet támadni a korábban hozzáadott elemeket annak érdekében, hogy ki lehessen váltani a HCE-t. Az ötödik lépésben meg kell adni azokat a biztonsági követelményeket (az öt legfontosabbat), amikkel meg lehet előzni a HCE-t vagy csökkenteni lehet a hatását.

A CDD hátteréről bővebben lehet olvasni Sarah medium.com-on megjelent tanulmányában.

A végére egy szolgálati közlemény: megjelentek az S4x YouTube csatornáján az első idei videók, amiket a múlt pénteki posztba elkezdtem belinkelni, szóval érdemes lesz néha visszanézni oda is, ha valakit nem csak az általam (hevenyészett jegyzeteimből készített) összefoglalóm érdekelt, hanem megnézne néhány előadást is.