Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

Az egyszer létező hálózati csomagok problémája

2026. január 31. - icscybersec

A mai poszt témáját azok a hálózati csomagok adják, amik a különböző IoT és beágyazott rendszerekben egyetlen egyszer, az első bekapcsolásuk és konfigurálásuk során születnek és többet soha nem lehet látni őket. Ezek között olyan hálózati csomagok vannak, amik az alábbi műveletekhez kötődnek:

- gyártói felhővel történő kommunikáció az első regisztrációhoz;
- titkosításhoz kapcsolódó adatok (secrets) generálásával kapcsolatos kommunikáció;
- firmware vagy konfigurációs blob-ok letöltése;
- "hazatelefonálás", olyan módon, ahogy később már nem teszi az eszköz;

Az ilyen és hasonló kommunikációkból számos, kiberbiztonsági szempontból fontos információt lehet megtudni, ehhez pedig két dolog kell:

Egyrészt egy eszköz, ami képes rögzíteni az IoT és beágyazott rendszerek kezdeti kommunikációjának maradéktalan rögzítésére, másrészt pedig egy jól kidolgozott és fegyelmezetten követett üzembe helyezési eljárásra. Az első még csak-csak létezhet a legtöbb szervezetnél, de a második gyakran hiányzik - hiszen az ilyen megoldásokat üzembe helyező szakemberek (bár saját területükön lehet, hogy tapasztaltak és jók, de) nincsenek tisztában az első kommunikáció információtartalmának fontosságával és megismételhetetlenségével.

Figyelembe véve, hogy nem csak a beágyazott rendszerek, hanem az IoT megoldások is milyen, egyre gyorsuló sebességgel nyernek teret a kritikus infrastruktúrákban és az ipari folyamatirányítás terén is, talán hasznos lenne ezekre az egyszer létező és nem reprodukálható hálózati forgalmakra nagyobb figyelmet fordítani.

Lengyel DER incidens akták IV

CERT Polska jelentés

A mai napon a lengyel központi CERT (CERT Polska) publikálta a december 29-i támadások részletes beszámolóját. Bár a héten már nem terveztem több, soron kívüli posztot, de ez a jelentés annyival részletesebbnek és pontosabbnak tűnik, mint bármelyik korábbi (akár hivatkoztam a korábbi posztokban, akár nem), hogy nem engedhettem meg magamnak, hogy ne olvassam át és ha már elolvastam, ne írjak róla. A konkrét jelentés itt érhető el.

Amit korábban is lehetett már olvasni, legalább 30 nap- és szélerőmű volt érintett a támadásban. Szintén lehetett tudni, hogy legalább egy CHP (Combined Heat and Power) hőerőművet is támadás ért. Viszont arról most először van információ, hogy egy gyártócég automatizálási rendszerei is érintettek voltak.

Szintén volt információ arról, hogy a támadók a megújuló erőművek site-jai és a DSO control center közötti kommunikációt támadták. A wiper malware-ek emlegetése a korábbi cikkekben adott arra vonatkozóan sejtetést, hogy a támadók a kommunikáció megzavarásán túl is szereztek hozzáféréseket a megtámadott rendszerekben, de a CERT Polska elemzése minden korábbinál sokkal részletesebb.

Az elemzés szerint a támadás NEM a megújuló erőművek rendszereit érte, hanem az elosztói rendszerirányító alállomásán (Grid Connection Point, GCP) működő berendezéseket - ez új információ, eddig mindenhol arról lehetett olvasni, hogy az erőművek rendszerei voltak a támadás célpontjai!

Minden megtámadott GCP-ben egy adott gyártó (Fortinet) adott terméke (FortiGate tűzfal) volt az első behatolási pont. A leírás szerint a FortiGate tűzfalak egyszerre szolgáltak tűzfalként és VPN-koncentrátorként, utóbbi szerepkörükben Internet irányból elérhető volt az authentikációt biztosító funkciójuk (multi-faktor authentikációval megerősítve). Eddig a CERT Polska elemzésből származó megállapítások. Azt már én teszem hozzá, hogy ez a konfiguráció teljesen normális és megfelel a (gyártófüggetlen) biztonsági ajánlásoknak. Azonban az is tény, hogy alig több, mint egy hete jelent meg egy hír pont az érintett gyártó tűzfalainak felhős menedzsment megoldásával kapcsolatban, amiben egy teljesen naprakészre frissített FortiGate tűzfalakat is támadhatóvá tevő sérülékenységről írtak (ezzel nem azt mondom, hogy ugyanez ne történhetett volna meg bármelyik másik gyártó tűzfalainak alkalmazása esetén - sajnos tudomásul kell vennünk, hogy az állami hátterű APT-csoportok gyakorlatilag bármelyik gyártó bármilyen eszközében rendelkezhetnek olyan 0-day sérülékenységi információval, amiről rajtuk kívül senki sem tud, márpedig ha valamikor érdemes lehet ilyen sérülékenységeket egy támadáshoz kihasználni, az pont az ilyen, nagyon nagy értékű - kritikus infrastruktúrákhoz tartozó - célpontok elleni támadások).

A kérdés minden külső határvédelmi rendszer sérülékenysége esetén az hogy a) mikor biztosít javítást a sérülékenységhez a gyártó és b) a publikálás után mennyi idővel telepíti a javítást az üzemeltető? (Ma már gyakorlatilag legkésőbb a javítás publikálása után néhány órával aktív támadási kísérletek indulnak a feltételezhetően sérülékeny és publikus hálózatokon elérhető rendszerek ellen, így a javításra rendelkezésre álló időablak egyre kisebb. Nem gondolom, hogy tovább kéne bizonygatnom, hogy ez a kritikus infrastruktúrák esetén mennyivel növeli a kockázatokat.

Ráadásul a támadók a kompromittált rendszerekben adminisztratív jogokat szereztek (ez szintén azt a teóriámat erősíti, hogy reaális esélye van annak, hogy a fenti cikkben linkelt sérülékenységet használhatták ki).

Arról a jelentés nem tesz említést, hogy a támadók mennyi ideig rendelkeztek az így szerzett hozzáférésekkel a megtámadott létesítmények rendszereiben.

A támadók a támadás napján (december 29-én) minden érintett eszközt gyári alapállapotban állították, amivel minden bizonnyal a normál működés helyreállítási idejének növelése volt a céljuk.

A támadók azonban nem álltak meg a kommunikáció szempontjából központi szerepet betöltő tűzfalaknál, hanem az alállomások és az erőművek közötti kommunikációban még fontosabb szekunder(????) berendezéseket is célba vették. Hitachi (korábban Hitachi-ABB, aztán a japán cég teljesen kivásárolta a svájciakat a közös vállalatból) és Mikronika RTU-k, Hitachi védelmek és vezérlések, Mikronika HMI-ok és Moxa soros-Ethernet átalakítók szintén a támadások áldozataivá váltak. Ezekben az esetekben a lengyel kollégák már korántsem voltak annyira precízek, mint a tűzfalak esetén, szinte az összes szekunder berendezés-típusnál megemlíti a jelentés, hogy gyári alapértelmezett jelszavakat felhasználva szereztek hozzáférést a támadók - ez pedig egy eléggé alapvető hiba, amit 2025-ben már nagyon nem lett volna szabad elkövetni (ennek ellenére ne legyenek illúzióink, okkal gyaníthatjuk, hogy majd minden ipari folyamatirányító rendszerben van legalább 1 olyan berendezés, amin nem módosították a gyári jelszót egy adminisztrátori szintű jogosultsággal rendelkező fiókhoz - ezek a jelszavak pedig publikusan elérhetőek a gyártók weboldaláról letölthető kézikönyvekben...).

A CHP elleni támadás a jelentés alapján más volt. Hosszú ideig tartó művelet (bár egyelőre nincs bizonyíték arra, hogy a 2025 márciusa és júliusa közötti gyanús események közvetlenül a decemberi támadást elkövető APT csoporthoz köthetőek, kizárni sem lehet ezt) során szerezhettek bizalmas információkat az erőmű működéséről és ezek között voltak olyanok is, amikkel emelt szintű jogosultsághoz jutottak az erőmű Active Directory címtárában. Ezekkel a jogokkal aztán csoportházirendeken keresztül indították el a wiper malware-t, amit azonban az erőművi rendszerekben működő Endpoint Detection and Response rendszer képes volt észlelni és blokkolni (a blokkolás kérdése érdekes, mert tapasztalataim szerint az OT rendszerekben gyakran nem engedélyezik a biztonsági rendszer aktív beavatkozását, bár láttam már ennek az ellenkezőjére is példát).

Ebben a támadásban is egy FortiGate tűzfal volt az első kompromittált rendszer, majd innen egy Windows jump hoston keresztül fértek hozzá a támadók további rendszerekhez (köztük a tartományvezérlőkhöz).

Támadás a gyártóvállalat ellen

Ennél a szervezetnél a CERT Polska jelentése nem lát kapcsolatot az erőművi és alállomási rendszerek elleni támadással, azonban a támadás jellemzői és időzítése a valószínűbbnél erősebben sugallják, hogy ugyanaz a támadói csoport lehet a felelős ezért az incidensért is.

A támadók ebben az esetben is a FortiGate külső határvédelmi eszközön keresztül jutottak be a célpont hálózatába, ráadásul ez a tűzfal érintett volt korábbi incidensben, az akkori konfigurációját publikálták is! A megszerzett, adminisztrátori szintű hozzáférés után SSL-VPN kapcsolaton keresztül mozogtak tovább a támadók a megtámadott rendszerben. Ebben az esetben is sikerült a támadóknak tartományi rendszergazda jogosultsági szintet szerezniük a megtámadott szervezet rendszereiben és itt is ezt felhasználva, csoportházirendekkel terítették a wiper malware-jüket (LazyWiper, amit egy külön fejezetben elemez a jelentés).

A tartományi rendszergazdai jogosultságok megszerzése sokkal komolyabb jövőbeli fenyegetéseket jelent a most érintett szervezetekre nézve, mint csupán a wiper malware-ek terítése. A jelentés szerint a támadók a megszerzett jogosultságok birtokában számos, OT hálózati fejlesztésekkel, SCADA rendszerekkel és más műszaki részletekkel kapcsolatos dokumentumokat töltöttek le a megtámadott szervezetek M365 fiókjaiból. Ez szerintem nem csak az érintett szervezetek jövőbeli kockázatait emeli meg jelentősen, hanem elég jó képet fest a támadók számára arról is, hogy az ezeket a dokumentumokat létrehozó vagy azokban közreműködő ICS/OT gyártó vagy integrátor cégek nagy valószínűséggel milyen gyakorlatok mentén tervezik más ügyfeleik rendszereit is!

Ami viszont érdekes, hogy az eddigi forrásokkal (amik miatt eddig én is így tettem) ellentétben a CERT Polska jelentésében, az Atribution fejezetben NEM a Sandworm APT csoportot (amivel kapcsolatban kb. közmegegyezés van, hogy a GRU, az orosz katonai hírszerzéshez köthető csoport) jelölik meg, hanem a Dragonfly néven azonosított, feltételezések szerint az orosz FSZB-hez (az orosz polgári hírszerzéshez) köthető APT-csoportot.

Ez a jelentés sok részletet tisztábban mutat, mint eddig bármi és nagyon jól rávilágít több régóta hangoztatott alapigazságra:

1. Minden szoftver sérülékeny, ezért azt kell feltételeznünk a biztonság tervezése során, hogy a támadók meg fognak találni már ismert és nem javított, vagy még nem ismert (0-day) és így nem is javítható sérülékenységeket a rendszereinkben.

2. Mindig (nem tudom eléggé hangsúlyozni, MINDIG) meg kell változtatni a gyári, alapértelmezett jelszavakat. Nyilván ez sem állít meg egy képzett és elhivatott támadót, de minden kicsi előnyre szükség van a védekezés során, a kritikus infrastruktúrák esetén ez fokozottan igaz.

3. A mélységi védelem (defense-in-depth) képes javítani a védelem esélyeit még egy top ligás támadói csoport ellen is. Az, hogy a CHP elleni támadás esetén az EDR rendszer képes volt detektálni és blokkolni a wiper malware-t, arra bizonyíték, hogy bár igaz a kb. másfél évtizede már magyar IT biztonsági konferenciákon is bizonyított feltevés (azt hiszem, talán Buherátortól láttam ilyen előadást, amiben azt mutatta meg, milyen könnyen lehet úgy obfuscálni egy Virustotal-on kezdetben majd 100%-ban detektált malware-t úgy, hogy a végén kb. 40 AV engine-ből alig 1-2 ismerte fel, mit is lát), mégis van kézzelfogható haszna egy (természetesen az OT gyártó/integrátor által támogatott) végpontvédelmi megoldást telepíteni.

Lengyel DER-incidens akták III

További elemzések a lengyel DER elleni kibertámadásról - kiegészítve néhány saját gondolattal

Nem meglepő módon a december végi, lengyel DER elleni kibertámadás témája továbbra is uralja a (főként európai) ICS/OT kiberbiztonsági közösség beszélgetéseit.

A tegnapi napon a Dragos (nem túl meglepő módon) kiadott egy rövid elemzést (regisztráció után érhető el) az incidensről. Ebben egyebek mellett azt is megemlítik, hogy a Dragos munkatársai is részt vettek az incidens kivizsgálásában egy (vagy több?) érintett lengyel szervezetnél. Részben ezt a jelentést is taglalja Reuben Santamarta is a lengyel incidensről készült cikk-sorozata legújabb (ötödik) részében és további, főként villamosmérnöki szemmel nézve érdekes részletekről is ír (még akkor is, ha Reuben gondolatainak egy része inkább csak ötletelés).

Most azonban én nem ezekről gondoltam soron kívül néhány gondolatot megosztani, hanem arról a tényről, hogy az állami hátterű kibertámadások egy új mérföldkövét látjuk ebben az incidensben. Ahogy a világon minden felé, de különösen Európában (és bár kisebb mértékben, de az USA-ban is, Kínára most nem térnék ki, az egy nagyon más környezet) egyre nagyobb a megújuló (nap- és szélerőművi) villamosenergia-termelés, ráadásul ezek (ahogy Lengyelországban is) nagyon elszórtan és elosztottan lettek telepítve, felmerül a kérdés, hogyan lehet ezeket az erőművi rendszereket (és ami legalább ilyen fontos, a távközlési kapcsolataikat a távoli vezénylő központtal!) megvédeni egy bármilyen szintű kibertámadástól.

Az első probléma rögtön az, hogy (az én személyes tapasztalataim szerint) a legtöbb, kis és közepes termelési kapacitású megújuló erőmű irányítástechnikai hálózata és távközlése kapcsán a legfontosabb (gyakran egyetlen) szempont a költséghatékonyság. Láttam én (sok éve már) olyan magyar naperőművet, ahol a helyi irányítástechnikai rendszereket az Internettől egyetlen, SOHO-kategóriájú, all-in-one hálózati eszköz választotta le. Meg akarjuk tippelni, hogy egy ilyen kialakítás során egy, a Sandworm-höz hasonló képességekkel rendelkező támadót meddig lehet feltartani?

Nem tehetjük meg azonban azt sem, hogy a biztonságra hivatkozva nem veszünk tudomást a megújuló erőművek pénzügyi/megtérülési szempontjairól. Ez pedig visszavezet minket oda, amiről a SeConSys kézikönyv 87. oldalán található koncepció-alaphoz. (Bár ennek a koncepciónak az alapötlete részben az enyém, én nem erre vagyok büszke, hanem arra, hogy olyan, sok évtizedes villamosmérnöki tapasztalattal rendelkező kollégák tartották elég jónak ahhoz, hogy segítsenek továbbgondolni a tanácsaikkal, mint Görgey Péter, Kapás Mihály, Kovács Gábor, Orlay Imre, Oroszki Lajos és Tari Gábor, akik közül többen kollégáim és vezetőim voltak korábban.) Mert ebből az incidensből is tisztán látszik, hogy a kibertámadások gyorsan és hatékonyan változtatják a célpontjaikat a legkisebb ellenállás elve mentén választva, vagyis egyre valószínűbb, hogy a jövőben a DER erőművek nem kevesebb, hanem több (akár jóval több) és súlyosabb kiberbiztonsági fenyegetéssel kell, hogy szembenézzenek. Ezt pedig a legjobban egy kombinált, a villamosenergia-rendszer egészét értékelő kockázatelemzésből levezetett és ráfordítás-haszon optimalizált kibervédelmi programmal lehet csak a kellő hatékonysággal megvédeni. Talán a SeConSys Energetikai Kiberbiztonsági Egyesület még pont időben alakult meg ahhoz, hogy az ezt lehetővé tevő keretrendszer kidolgozását célzó munka minél előbb el tudjon kezdődni.

Lengyel DER-incidens akták II

Új elemzések a lengyel villamosenergia-rendszer elleni kibertámadásról

A múlt heti posztban is tárgyalt, lengyel megújuló villamosenergia-erőművek elleni kibertámadásról sorban jelennek meg az újabb elemzések, a mai poszt témáját a múlt héten már hivatkozott Ruben Santamarta, független biztonsági kutató újabb cikkei adják.

A már hivatkozott első elemzés (ami január 16-án jelent meg) után 19-én Ruben publikálta a második részt, amiben az alábbi témákat vizsgálta:

- Bemutatkozás (a szkepticizmus és kritikai gondolkodás haszna a kiber-fizikai incidensek vizsgálata során)
- A támadás jellemzőinek bemutatása
- A támadás kézzelfogható eredményei
- Kapcsolat az ibériai blackout (ami, nem lehet eléggé hangsúlyozni, közel kilenc hónappal az eset után sem nevezhető kibertámadás okozta incidensnek, mert semmilyen bizonyíték nincs arra, hogy lett volna kiberbiztonsági komponense a kiváltó okoknak) és a lengyel kibertámadás között
- Hogyan hajtották végre a támadást? (Spoiler: a cikk írása pillanatában még nagyon voltak ezzel kapcsolatban elérhető hiteles információk.)
- Mi történhetett volna egy sikeres támadást követően?
- Következtetések

A cikksorozat harmadik részében pedig a szerző azt járja körbe, hogy a lengyel villamosenergia-rendszer elleni támadás hogyan és miben mutat erős hasonlóságokat az Industroyer ICS-malware-rel.

Úgy érzem, ahogy egyre több információt lehet majd megismerni az incidensről, úgy fogok még én is újabb részleteket hivatkozni itt, a blogon.

Szerk: ezt a posztot eredetileg néhány napja kezdtem írni, de azóta (ahogy a fenti bekezdésben írva vártam) új részletek jelentek meg. Az ESET vezető kutatója Robert Lipovsky csapatával vizsgálta a lengyel rendszerek elleni támadásban használt malware-t (amit DynoWiper-nek neveztek el) és arra a következtetésre jutottak, hogy az nagyfokú hasonlóságot mutat a 2015-ben a Nyugat-ukrajnai áramszolgáltatók ellen végrehajtott BlackEnergy-támadásokkal, ahol a Sandworm néven hivatkozott, orosz katonai titkoszolgálathoz tartozóként emlegetett APT-csoport volt a támadó (ahogy egyébként 2016-ban, az Ukrenergo, az ukrán TSO Kijev-északi alállomása elleni támadásnál is, amihez kapcsolódóan szintén az ESET elemezte elsőként az Industroyer néven ismert ICS-malware-t).

Részleteket az új fejleményről Kim Zetter itt, az ESET WeLiveSecurity blogja pedig itt ír.

Sajnos egyre inkább beigazolódni látszik az a feltevésem, hogy ahogy az oroszok a harctéren nem képesek többé jelentős sikereket elérni, úgy fognak fokozódni az európai kritikus infrastruktúrák elleni kibertámadások, úgy számosságban, mint súlyosságban. Ez szerintem egy jó darabig még akkor is így lesz, ha egyszer lesz fegyverszünet (én békére még jó ideig nem számítok) Ukrajnában.

Szerk2: Alig néhány órája megjelent Ruben Santamarta negyedik cikke is a témában. Ebben pedig ismét érdekes részletekről ír a szerző:

- A lengyel villamosenergia-rendszer egyensúlya elleni támadás (ez az a fejezet, amihez én annyira nem értek, de majd a villamosmérnök kollégák elmondják, nekik mi is olvasható ki ebből a fejezetből illetve a Ruben által hivatkozott forrásokból);
- A még mindig hiányzó részletek (ebben a fejezetben már Ruben is hivatkozza az ESET és Robert Lipovsky elemzését, illetve Kim Zetter általam is belinkelt cikkét).
- Következtetések (ahol szóba kerül egy 2021-es, emberi hibából eredő jelentős, termelési oldalon kialakult üzemzavar, aminek következtében 3,3 GW szénerőművi termelés esett ki a lengyel rendszerből, amit a PSE így is képes volt a biztonsági határokon belül tartani - ezúton is hatalmas elismerés a lengyel kollégáknak. Mindig is tudtam, hogy jók, de ez azért korántsem mindennapi erőfeszítés lehetett a részükről. Ez még egy hozzám hasonló, a kezdők között is amatőr laikus is látja/érzi.)

(2026.02.23. szerkesztés: A poszt címét - tekintettel a témában a blogon az elmúlt hetekben megjelent posztok nagy számára - módosítottam.)

ICS sérülékenységek CDXCVI

Sérülékenységek Siemens, Festo, Schneider Electric és AVEVA rendszerekben

Bejelentés dátuma: 2026.01.13.
Gyártó: Siemens
Érintett rendszer(ek):
- TeleControl Server Basic V3.1.2.4-nél korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Execution with Unnecessary Privileges (CVE-2025-40942)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2026.01.13.
Gyártó: Siemens
Érintett rendszer(ek):
- SIMATIC ET 200AL IM 157-1 PN (6ES7157-1AB00-0AB0) minden verziója;
- SIMATIC ET 200MP IM 155-5 PN HF (6ES7155-5AA00-0AC0) minden verziója;
- SIMATIC ET 200SP IM 155-6 MF HF (6ES7155-6MU00-0CN0) minden verziója;
- SIMATIC ET 200SP IM 155-6 PN HA (incl. SIPLUS variants) minden verziója;
- SIMATIC ET 200SP IM 155-6 PN R1 (6ES7155-6AU00-0HM0) minden verziója;
- SIMATIC ET 200SP IM 155-6 PN/2 HF (6ES7155-6AU01-0CN0) minden verziója;
- SIMATIC ET 200SP IM 155-6 PN/3 HF (6ES7155-6AU30-0CN0) minden verziója;
- SIMATIC PN/MF Coupler (6ES7158-3MU10-0XA0) minden verziója;
- SIMATIC PN/PN Coupler (6ES7158-3AD10-0XA0) minden verziója;
- SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-2AC0) minden verziója;
- SIPLUS ET 200MP IM 155-5 PN HF (6AG1155-5AA00-7AC0) minden verziója;
- SIPLUS ET 200MP IM 155-5 PN HF T1 RAIL (6AG2155-5AA00-1AC0) minden verziója;
- SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-2CN0) minden verziója;
- SIPLUS ET 200SP IM 155-6 PN HF (6AG1155-6AU01-7CN0) minden verziója;
- SIPLUS ET 200SP IM 155-6 PN HF T1 RAIL (6AG2155-6AU01-1CN0) minden verziója;
- SIPLUS ET 200SP IM 155-6 PN HF TX RAIL (6AG2155-6AU01-4CN0) minden verziója;
- SIPLUS NET PN/PN Coupler (6AG2158-3AD10-4XA0) minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Uncontrolled Resource Consumption (CVE-2025-40944)/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: 2026.01.13.
Gyártó: Siemens
Érintett rendszer(ek):
- RUGGEDCOM APE1808 minden verziója;;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Cross-site Scripting (CVE-2025-40891)/közepes;
- Cross-site Scripting (CVE-2025-40892)/súlyos;
- Cross-site Scripting (CVE-2025-40893)/közepes;
- Path Traversal (CVE-2025-40898)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Siemens ProductCERT, ICS-CERT

Bejelentés dátuma: 2026.01.13.
Gyártó: Siemens
Érintett rendszer(ek):
- Industrial Edge Cloud Device (IECD) minden verziója;
- Industrial Edge Own Device (IEOD) minden verziója;
- Industrial Edge Virtual Device (IEVD) minden verziója;
- SCALANCE LPE9413 (6GK5998-3GS01-2AC2) minden verziója;
- SCALANCE LPE9433 (6GK5998-3GS11-2AC2) minden verziója;
- SIMATIC Automation Workstation 19" (6AV7256-6CA01-0FP0) minden verziója;
- SIMATIC Automation Workstation 24" (6AV7256-6CA00-0FP0) minden verziója;
- SIMATIC HMI MTP1000 Unified Comfort Panel (6AV2128-3KB06-0AX1) minden verziója;
- SIMATIC HMI MTP1000 Unified Comfort Panel hygienic (6AV2128-3KB40-0AX0) minden verziója;
- SIMATIC HMI MTP1000 Unified Comfort Panel hygienic neutral design (6AV2128-3KB70-0AX0) minden verziója;
- SIMATIC HMI MTP1000, Unified Comfort Panel neutral (6AV2128-3KB36-0AX1) minden verziója;
- SIMATIC HMI MTP1200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3MB27-1BX0) minden verziója;
- SIMATIC HMI MTP1200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3MB27-0BX0) minden verziója;
- SIMATIC HMI MTP1200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3MB27-0AX0) minden verziója;
- SIMATIC HMI MTP1200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3MB57-1BX0) minden verziója;
- SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3MB57-0BX0) minden verziója;
- SIMATIC HMI MTP1200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3MB57-0AX0) minden verziója;
- SIMATIC HMI MTP1200 Unified Comfort Panel (6AV2128-3MB06-0AX1) minden verziója;
- SIMATIC HMI MTP1200 Unified Comfort Panel hygienic (6AV2128-3MB40-0AX0) minden verziója;
- SIMATIC HMI MTP1200 Unified Comfort Panel hygienic neutral design (6AV2128-3MB70-0AX0) minden verziója;
- SIMATIC HMI MTP1200 Unified Comfort Panel neutral design (6AV2128-3MB36-0AX1) minden verziója;
- SIMATIC HMI MTP1500 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3QB27-1BX0) minden verziója;
- SIMATIC HMI MTP1500 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3QB27-0BX0) minden verziója;
- SIMATIC HMI MTP1500 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3QB27-0AX0) minden verziója;
- SIMATIC HMI MTP1500 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3QB57-1BX0) minden verziója;
- SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3QB57-0BX0) minden verziója;
- SIMATIC HMI MTP1500 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3QB57-0AX0) minden verziója;
- SIMATIC HMI MTP1500 Unified Comfort Panel (6AV2128-3QB06-0AX1) minden verziója;
- SIMATIC HMI MTP1500 Unified Comfort Panel hygienic (6AV2128-3QB40-0AX0) minden verziója;
- SIMATIC HMI MTP1500 Unified Comfort Panel hygienic neutral design (6AV2128-3QB70-0AX0) minden verziója;
- SIMATIC HMI MTP1500 Unified Comfort Panel neutral design (6AV2128-3QB36-0AX1) minden verziója;
- SIMATIC HMI MTP1900 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3UB27-1BX0) minden verziója;
- SIMATIC HMI MTP1900 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3UB27-0BX0) minden verziója;
- SIMATIC HMI MTP1900 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3UB27-0AX0) minden verziója;
- SIMATIC HMI MTP1900 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3UB57-1BX0) minden verziója;
- SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3UB57-0BX0) minden verziója;
- SIMATIC HMI MTP1900 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3UB57-0AX0) minden verziója;
- SIMATIC HMI MTP1900 Unified Comfort Panel (6AV2128-3UB06-0AX1) minden verziója;
- SIMATIC HMI MTP1900 Unified Comfort Panel hygienic (6AV2128-3UB40-0AX0) minden verziója;
- SIMATIC HMI MTP1900 Unified Comfort Panel hygienic neutral design (6AV2128-3UB70-0AX0) minden verziója;
- SIMATIC HMI MTP1900 Unified Comfort Panel neutral design (6AV2128-3UB36-0AX1) minden verziója;
- SIMATIC HMI MTP2200 Comfort Pro for stand (expandable, flange at the bottom) (6AV2128-3XB27-1BX0) minden verziója;
- SIMATIC HMI MTP2200 Comfort Pro for support arm (expandable, round tube) and extension unit (6AV2128-3XB27-0BX0) minden verziója;
- SIMATIC HMI MTP2200 Comfort Pro for support arm (not extendable, flange on top) (6AV2128-3XB27-0AX0) minden verziója;
- SIMATIC HMI MTP2200 Comfort Pro neutral design for stand (expandable, flange at the bottom) (6AV2128-3XB57-1BX0) minden verziója;
- SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (expandable, round tube) and extensio (6AV2128-3XB57-0BX0) minden verziója;
- SIMATIC HMI MTP2200 Comfort Pro neutral design for support arm (not extendable, flange on top) (6AV2128-3XB57-0AX0) minden verziója;
- SIMATIC HMI MTP2200 Unified Comfort Hygienic (6AV2128-3XB40-0AX0) minden verziója;
- SIMATIC HMI MTP2200 Unified Comfort Hygienic neutral design (6AV2128-3XB70-0AX0) minden verziója;
- SIMATIC HMI MTP2200 Unified Comfort Panel (6AV2128-3XB06-0AX1) minden verziója;
- SIMATIC HMI MTP2200 Unified Comfort Panel neutral design (6AV2128-3XB36-0AX1) minden verziója;
- SIMATIC HMI MTP700 Unified Comfort Panel (6AV2128-3GB06-0AX1) minden verziója;
- SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB40-0AX0) minden verziója;
- SIMATIC HMI MTP700 Unified Comfort Panel hygienic neutral design (6AV2128-3GB70-0AX0) minden verziója;
- SIMATIC HMI MTP700, Unified Comfort Panel neutral design (6AV2128-3GB36-0AX1) minden verziója;
- SIMATIC IOT2050 (6ES7647-0BA00-1YA2) minden verziója;
- SIMATIC IPC BX-39A Industrial Edge Device minden verziója;
- SIMATIC IPC BX-59A Industrial Edge Device minden verziója;
- SIMATIC IPC127E Industrial Edge Device minden verziója;
- SIMATIC IPC227E Industrial Edge Device minden verziója;
- SIMATIC IPC227G Industrial Edge Device minden verziója;
- SIMATIC IPC427E Industrial Edge Device minden verziója;
- SIMATIC IPC847E Industrial Edge Device minden verziója;
- SIPLUS HMI MTP1000 Unified Comfort (6AG1128-3KB06-4AX1) minden verziója;
- SIPLUS HMI MTP1200 Unified Comfort (6AG1128-3MB06-4AX1) minden verziója;
- SIPLUS HMI MTP700 Unified Comfort (6AG1128-3GB06-4AX1) minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Authorization Bypass Through User-Controlled Key (CVE-2025-40805)/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: 2026.01.13.
Gyártó: Siemens
Érintett rendszer(ek):
- Industrial Edge Device Kit - arm64 V1.10 verziója;
- Industrial Edge Device Kit - arm64 V1.11 verziója;
- Industrial Edge Device Kit - arm64 V1.12 verziója;
- Industrial Edge Device Kit - arm64 V1.13 verziója;
- Industrial Edge Device Kit - arm64 V1.14 verziója;
- Industrial Edge Device Kit - arm64 V1.15 verziója;
- Industrial Edge Device Kit - arm64 V1.16 verziója;
- Industrial Edge Device Kit - arm64 V1.17 verziója;
- Industrial Edge Device Kit - arm64 V1.18 verziója;
- Industrial Edge Device Kit - arm64 V1.19 verziója;
- Industrial Edge Device Kit - arm64 V1.20 verziója;
- Industrial Edge Device Kit - arm64 V1.21 verziója;
- Industrial Edge Device Kit - arm64 V1.22 verziója;
- Industrial Edge Device Kit - arm64 V1.23 verziója;
- Industrial Edge Device Kit - arm64 V1.24 verziója;
- Industrial Edge Device Kit - arm64 V1.25 verziója;
- Industrial Edge Device Kit - arm64 V1.5 verziója;
- Industrial Edge Device Kit - arm64 V1.6 verziója;
- Industrial Edge Device Kit - arm64 V1.7 verziója;
- Industrial Edge Device Kit - arm64 V1.8 verziója;
- Industrial Edge Device Kit - arm64 V1.9 verziója;
- Industrial Edge Device Kit - x86-64 V1.10 verziója;
- Industrial Edge Device Kit - x86-64 V1.11 verziója;
- Industrial Edge Device Kit - x86-64 V1.12 verziója;
- Industrial Edge Device Kit - x86-64 V1.13 verziója;
- Industrial Edge Device Kit - x86-64 V1.14 verziója;
- Industrial Edge Device Kit - x86-64 V1.15 verziója;
- Industrial Edge Device Kit - x86-64 V1.16 verziója;
- Industrial Edge Device Kit - x86-64 V1.17 verziója;
- Industrial Edge Device Kit - x86-64 V1.18 verziója;
- Industrial Edge Device Kit - x86-64 V1.19 verziója;
- Industrial Edge Device Kit - x86-64 V1.20 verziója;
- Industrial Edge Device Kit - x86-64 V1.21 verziója;
- Industrial Edge Device Kit - x86-64 V1.22 verziója;
- Industrial Edge Device Kit - x86-64 V1.23 verziója;
- Industrial Edge Device Kit - x86-64 V1.24 verziója;
- Industrial Edge Device Kit - x86-64 V1.25 verziója;
- Industrial Edge Device Kit - x86-64 V1.5 verziója;
- Industrial Edge Device Kit - x86-64 V1.6 verziója;
- Industrial Edge Device Kit - x86-64 V1.7 verziója;
- Industrial Edge Device Kit - x86-64 V1.8 verziója;
- Industrial Edge Device Kit - x86-64 V1.9 verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Authorization Bypass Through User-Controlled Key (CVE-2025-40805)/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: 2026.01.13.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- EcoStruxure Power Build Rapsody software FR V2.8.1-es és korábbi verziói;
- EcoStruxure Power Build Rapsody software INT V2.8.6-os és korábbi verziói;
- EcoStruxure Power Build Rapsody software ES V2.8.5-ös és korábbi verziói;
- EcoStruxure Power Build Rapsody software BEL (NL) V2.8.3-as és korábbi verziói;
- EcoStruxure Power Build Rapsody software BEL (FR) V2.8.8-as és korábbi verziói;
- EcoStruxure Power Build Rapsody software ESP V2.8.5.0200 és korábbi verziói;
- EcoStruxure Power Build Rapsody software PT V2.8.7.0100 és korábbi verziói;
- EcoStruxure Power Build Rapsody software NL V2.8.2.0000 és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Double Free (CVE-2025-13844)/közepes;
- Use After Free (CVE-2025-13845)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Schneider Electric, ICS-CERT

Bejelentés dátuma: 2026.01.13.
Gyártó: Schneider Electric
Érintett rendszer(ek):
- EcoStruxure™ Process Expert 2025-ösnél korábbi verziója;
- EcoStruxure™ Process Expert for AVEVA System Platform minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Incorrect Default Permissions (CVE-2025-13905)/súlyos;
Javítás: Részben elérhető.
Link a publikációhoz: Schneider Electric

Bejelentés dátuma: 2026.01.14.
Gyártó: Festo
Érintett rendszer(ek):
- Bus module CPX-E-EP minden verziója;
- Bus module CPX-E-PN minden verziója;
- Bus node CPX-FB32 minden verziója;
- Bus node CPX-FB33 minden verziója;
- Bus node CPX-FB36 minden verziója;
- Bus node CPX-FB37 minden verziója;
- Bus node CPX-FB39 minden verziója;
- Bus node CPX-FB40 minden verziója;
- Bus node CPX-FB43 minden verziója;
- Bus node CPX-M-FB34 minden verziója;
- Bus node CPX-M-FB35 minden verziója;
- Bus node CPX-M-FB44 minden verziója;
- Bus node CPX-M-FB45 minden verziója;
- Bus node CTEU-EP minden verziója;
- Bus node CTEU-PN minden verziója;
- Bus node CTEU-PN-EX1C minden verziója;
- Camera system CHB-C-N minden verziója;
- Compact Vision System SBO*-C-* minden verziója;
- Compact Vision System SBO*-M-* minden verziója;
- Compact Vision System SBO*-Q-* minden verziója;
- Control block CPX-CEC minden verziója;
- Control block CPX-CEC-C1 minden verziója;
- Control block CPX-CEC-C1-V3 minden verziója;
- Control block CPX-CEC-M1 minden verziója;
- Control block CPX-CEC-M1-V3 minden verziója;
- Control block CPX-CEC-S1-V3 minden verziója;
- Control block CPX-CMXX minden verziója;
- Control block CPX-FEC-1-IE minden verziója;
- Controller CECC-D minden verziója;
- Controller CECC-D-BA minden verziója;
- Controller CECC-LK minden verziója;
- Controller CECC-S minden verziója;
- Controller CECC-X-* minden verziója;
- Controller CECX-X-C1 minden verziója;
- Controller CECX-X-M1 minden verziója;
- Controller CMXH-ST2-C5-7-DIOP minden verziója;
- Controller CPX-E-CEC-* minden verziója;
- Controller SBRD-Q minden verziója;
- EtherNet/IP interface CPX-AP-I-EP-M12 minden verziója;
- EtherNet/IP interface CPX-AP-I-PN-M12 minden verziója;
- Gateway CPX-IOT minden verziója;
- Integrated drive EMCA-EC-67-* minden verziója;
- Motor controller CMMO-ST-C5-1-DION minden verziója;
- Motor controller CMMO-ST-C5-1-DIOP minden verziója;
- Motor controller CMMO-ST-C5-1-LKP minden verziója;
- Motor controller CMMP-AS-* minden verziója;
- Motor controller CMMT-AS-* minden verziója;
- Operator unit CDPX-X-A-S-10 minden verziója;
- Operator unit CDPX-X-A-W-13 minden verziója;
- Operator unit CDPX-X-A-W-4 minden verziója;
- Operator unit CDPX-X-A-W-7 minden verziója;
- Planar surface gantry EXCM-* minden verziója;
- Servo drive CMMT-ST-C8-1C-EP-S0 minden verziója;
- Servo drive CMMT-ST-C8-1C-PN-S0 minden verziója;
- VTEM-S1-* minden verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Insufficient Technical Documentation (CVE-2022-3270)/kritikus;
Javítás: A hiányosság pótlása a következő verzióban várható.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-26-015-02

Bejelentés dátuma: 2025.01.15.
Gyártó: AVEVA
Érintett rendszer(ek):
- AVEVA Process Optimization 2024.1-es és korábbi verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
Code Injection (CVE-2025-61937)/kritikus;
Code Injection (CVE-2025-64691)/súlyos;
SQL Injection (CVE-2025-61943)/súlyos;
Uncontrolled Search Path Element (CVE-2025-65118)/súlyos;
Missing Authorization (CVE-2025-64729)/súlyos;
Use of Potentially Dangerous Function (CVE-2025-65117)/súlyos;
Cleartext Transmission of Sensitive Information (CVE-2025-64769)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-26-015-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.

Lengyel DER-incidens akták I

A felkészültség előnyei

Az elmúlt 15-20 év a kritikus infrastruktúrák és ipari folyamatirányító rendszerek kiberbiztonsági fenyegetettségének korábban soha nem látott mértékű növekedését okozták. A 2007-es Aurora-teszt után gyorsan jelentek meg az újabb incidensekről szóló hírek:

- Stuxnet (2010)
- Shamoon (2012)
- Havex (2013)
- Német acélkohó elleni támadás (2014)
- BlackEnergy (2015)
- Industroyer (2016)
- TriSIS/Triton (2017)
- EKANS (2019)

A COVID alatt sem csökkent a fenyegetettség, a 2020-as, Ladakh-környéki kínai-indiai határvillongások után 2021-ben támadás érte az indiai villamosenergia-szektor több cégét is.

2022-ben aztán, Oroszország Ukrajna ellen indított nyílt háborúja a kiberbiztonság terén is új szintre emelte a konfliktust. A háború februári kitörése után már áprilisban jöttek az első hírek az Industroyer2 nevű újabb ICS malware-ről, majd alig néhány nappal később a Pipedream nevű malware framework-ről jelentett meg információkat a Dragos. Ezekről itt írtam.

2023-ban a Mandiant (Google) publikált egy elemzést a COSMICENERGY nevű ICS malware-ről, a következő évben pedig két ICS-specifikus kártevő is előkerült, a Fuxnet orosz, a FrostyGoop pedig ukrán célpontokat támadott.

A kifejezetten ICS-rendszerekre fejlesztett malware-ek mellett pedig további fenyegetésekkel is számolni kell, a Living-off-the-Land, vagyis a támadott rendszerekre telepített legitim eszközöket felhasználó támadások is folyamatosan terjednek.

Azt sem lehet mondani, hogy csak bizonyos országok/csoportok tennének ilyeneket, hiszen a Stuxnet amerikai/izraeli háttere ma már nem lehet kérdés, az orosz GRU-hoz kötött Sandworm nevű APT-csoport is megalapozottan gyanúsítható több ilyen támadással (elég csak Andy Greenberg könyvét elolvasni), de tudjuk, hogy a kínai, iráni, angol, állami hátterű csoportok is gyakran nyúlnak a szürke zónába tartozóként emlegetett kibertámadások eszközeihez.

Ebben a (korántsem teljes) incidens-felsorolásban a (mai napon) utolsó eset a héten nyilvánosságra hozott, tavaly december végén történt lengyel villamosenergia-ipari létesítmények elleni (feltételezetten orosz) kibertámadás. A támadási kísérlet, ami a lengyel megújuló villamosenergia-termelés (nap- és szélerőművek) létesítményei (erőművek és vezézlő-központok) közötti távközlési kapcsolatokat célozata, az elérhető információk szerint kudarcot vallott. Részleteket az incidensről itt lehet olvasni

Az incidensről olvasva pedig eszembe jutott egy régi emlék: még valamikor 2018-ban a lengyel villamosenergia-ipari rendszerirányító, a PSE (Polskie Sieci Elektroenergetyczne S.A. - a MAVIR lengyel megfelelője és partnere) az amerikai belbiztonsági minisztériummal (DHS), az FBI-jal és a SANS Institute-tal közösen rendezte meg (az amerikai GridEx, egy kétévente megrendezésre kerülő, célzottan a amerikai villamosenergia-rendszer cégei számára szervezett kiberbiztonsági gyakorlat mintájára) az első PolEx-et (Polish gridEx). Sajnos, bár volt meghívóm a gyakorlat második napjára (az első napon a lengyel villamosenergia-rendszer cégein kívül kizárólag a szervezésben segítséget nyújtó amerikaiak lehettek jelen), az akkori munkahelyi vezetőim nem támogatták a részvételemet, így csak másodkézből hallottam, hogy mennyire jó és hasznos gyakorlat volt. De a PSE vezetői itt nem álltak meg, a későbbi években többször is megismételték a PolEx-et.

Ez pedig most számomra minden korábbinál egyértelműbben mutatja meg, hogy milyen sokat tud számítani a megfelelő felkészültség, amikor a nemzeti kritikus infrastruktúra legalapvetőbb rendszerei elleni kibertámadások elhárításáról van szó. A kérdés már csak az, tanulunk-e lengyel barátaink jó példájából?

(2026.02.23. szerkesztés: A poszt címét - tekintettel a témában a blogon az elmúlt hetekben megjelent posztok nagy számára - módosítottam.)

ICS sérülékenységek CDXCV

Sérülékenységek Moxa, Phoenix Contact, Rockwell Automation és YoSmart rendszerekben

Bejelentés dátuma: 2025.12.31.
Gyártó: Moxa
Érintett rendszer(ek):
- NPort 6100-G2/6200-G2 sorozatú eszközök v1.0.0 firmware-verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Execution with Unnecessary Privileges (CVE-2025-1977)/súlyos;
- Improper Null Termination (CVE-2025-2026)/súlyos
Javítás: Elérhető
Link a publikációhoz: Moxa

Bejelentés dátuma: 2026.01.09.
Gyártó: Moxa
Érintett rendszer(ek):
- EDS-4008 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- EDS-4009 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- EDS-4012 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- EDS-4014 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- EDS-G4008 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- EDS-G4012 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- EDS-G4014 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- RKS-G4028 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
- RKS-G4028-L3 sorozatú eszközök v4.1-es és korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Unquoted Search Path or Element (CVE-2023-38408)/kritikus;
Javítás: Elérhető
Link a publikációhoz: Moxa

Bejelentés dátuma: 2026.01.13.
Gyártó: Phoenix Contact
Érintett rendszer(ek):
- CLOUD CLIENT 1101T-TX/TX FW 3.07.7-nél korábbi firmware-verziói;
- TC CLOUD CLIENT 1002-4G ATT FW 3.08.8-nál korábbi firmware-verziói;
- TC CLOUD CLIENT 1002-TX/TX FW 3.07.7-nél korábbi firmware-verziói;
- TC ROUTER 2002T-3G FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 2002T-4G FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 3002T-3G FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 3002T-4G FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 3002T-4G ATT FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 3002T-4G GL FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 3002T-4G VZW FW 3.08.8-nál korábbi firmware-verziói;
- TC ROUTER 5004T-5G EU FW 1.06.23-nál korábbi firmware-verziói;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Code Injection (CVE-2025-41717)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://certvde.com/en/advisories/VDE-2025-073

Bejelentés dátuma: 2026.01.13.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- Rockwell Automation 432ES-IG3 A sorozatú eszközeinek V1.001 verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Allocation of Resources Without Limits or Throttling (CVE-2025-9368)/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-26-013-01

Bejelentés dátuma: 2026.01.13.
Gyártó: Rockwell Automation
Érintett rendszer(ek):
- Rockwell Automation FactoryTalk DataMosaix Private Cloud 7.11-es verziója;
- Rockwell Automation FactoryTalk DataMosaix Private Cloud 8.00 verziója;
- Rockwell Automation FactoryTalk DataMosaix Private Cloud 8.01-es verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- SQL Injection (CVE-2025-12807)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-26-013-02

Bejelentés dátuma: 2026.01.13.
Gyártó: YoSmart
Érintett rendszer(ek):
- YoSmart server minden verziója;
- YoLink Smart Hub 0382-es verziója;
- YoLink Mobile Appication v1.40.45-nél korábbi verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Incorrect Authorization (CVE-2025-59449)/közepes;
- Generation of Predictable Numbers or Identifiers (CVE-2025-59452)/közepes;
- Cleartext Transmission of Sensitive Information (CVE-2025-59448)/közepes;
- Incorrect Authorization (CVE-2025-59451)/alacsony;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-26-013-03

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.

Az ibériai üzemzavar kiberbiztonsági tanulságai

A tavaly április 28-án bekövetkezett ibériai villamosenergia-rendszer üzemzavar és az azt követő, Európában régóta nem látott hosszúság áramkimaradás már a közvetlenül utána következő napokban számos olyan kérdést generált, amik azt feszegették, hogy lehetett-e kibertámadás az üzemzavar kiváltó oka. Az azóta eltelt időben megjelentek egészen alapos elemzések (pl. az ENTSO-E szakértői csoportjától, amiben magyar szakemberek is aktívan dolgoztak), az ezekben foglaltak elég egyértelművé tették, hogy a konkrét esetben nem volt semmilyen kiberbiztonsági kiváltó ok.

Ez azonban nem jelenti azt, hogy egy hasonló méretű és súlyosságú üzemzavart ne lehetne előidézni egy kibertámadással (különösen az áprilisihoz hasonló, a villamosenergia-rendszer egyensúlya szempontjából kritikus időszakban történő kibertámadások esetén).

Erről írt Sinclair Koelemij még tavaly novemberben egy, a LinkedIn-en megjelent írásában. Ebben a cikkében Sinclair ír a villamosenergia-rendszer kialakítását évtizedek óta meghatározó N-1 alapelvről, a kínai gyártmányú naperőművi rendszerek egyes komponenseiben talált, nem dokumentált kommunikációs berendezéseiről, az ebből eredő ellátási-lánc kockázatokról és az egész helyzet hatásáról az egyre nagyobb megújuló energia-termelési hányaddal rendelkező európai villamosenergia-rendszerre nézve.

Nem mondom, hogy a témát rendszeresen figyelemmel követő kollégák számára ez a cikk sok újdonságot fog tartalmazni, de nagyon jól összefoglalja és kontextusba helyezi a külön-külön több helyen elérhető információkat.

A kérdés már csak az, ki, mikor és mit fog tenni ezeknek a kockázatoknak a csökkentése érdekében? Vagy kell-e egyáltalán csökkenteni ezeket a kockázatokat? Tudjuk-e (egy formális kockázatelemzésből), hogy valójában mekkora kockázatokat jelentenek az elmúlt évek változásai az európai villamosenergia-ellátásra?

ICS sérülékenységek CDXCIV

Sérülékenységek WHILL, Moxa és Columbia Weather Systems rendszerekben

Bejelentés dátuma: 2025.12.30.
Gyártó: WHILL
Érintett rendszer(ek):
- Model C2 elektromos kerekesszék;
- Model F Power Chair;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Missing Authentication for Critical Function (CVE-2025-14346)/kritikus;
Javítás: Nincs, a DHS CISA kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: https://www.cisa.gov/news-events/ics-medical-advisories/icsma-25-364-01

Bejelentés dátuma: 2025.12.31.
Gyártó: Moxa
Érintett rendszer(ek):
- NPort 6100-G2/6200-G2 sorozatú eszközök v1.0.0 firmware-verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Execution with Unnecessary Privileges (CVE-2025-1977)/súlyos;
- Improper Null Termination (CVE-2025-2026)/súlyos;
Javítás: Elérhető
Link a publikációhoz: Moxa

Bejelentés dátuma: 2025.12.31.
Gyártó: Moxa
Érintett rendszer(ek):
- NPort 5000AI-M12 sorozatú eszközök minden firmware-verziója;
- NPort 5100 sorozatú eszközök minden firmware-verziója;
- NPort 5100A sorozatú eszközök minden firmware-verziója;
- NPort 5200 sorozatú eszközök minden firmware-verziója;
- NPort 5200A sorozatú eszközök minden firmware-verziója;
- NPort 5400 sorozatú eszközök minden firmware-verziója;
- NPort 5600 sorozatú eszközök minden firmware-verziója;
- NPort 5600-DT sorozatú eszközök minden firmware-verziója;
- NPort IA5000 sorozatú eszközök minden firmware-verziója;
- NPort IA5000A sorozatú eszközök minden firmware-verziója;
- NPort IA5000-G2 sorozatú eszközök minden firmware-verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Active Debug Code (CVE-2025-15017)/súlyos;
Javítás: Nincs, a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.
Link a publikációhoz: Moxa

Bejelentés dátuma: 2026.01.06.
Gyártó: Columbia Weather Systems
Érintett rendszer(ek):
- MicroServer minden firmware-verziója;
Sérülékenység(ek) neve/CVSSv3.1 szerinti besorolása:
- Improper Restriction of Communication Channel to Intended Endpoints (CVE-2025-61939)/súlyos;
- Cleartext Storage in a File or on Disk (CVE-2025-64305)/közepes;
- Command Shell in Externally Accessible Directory (CVE-2025-66620)/súlyos;
Javítás: Elérhető
Link a publikációhoz: https://www.cisa.gov/news-events/ics-advisories/icsa-26-006-01

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.

Kibertámadás a venezuelai villamosenergia-rendszer ellen

A január 3-i, Venezuela elleni amerikai támadások után nem sokkal (még aznap este) megjelent az első olyan hír (Maggie Miller tollából) a Politico.com-on, amely szerint Trump elnök azt sejtette a szombati sajtótájékoztatón, hogy "kibertámadásokkal vagy más műszaki képességekkel" idéztek elő áramkimaradást Caracas-ban a katonai csapások idején.

Az elnöki kijelentésen kívül (ami meglehetősen homályosan lett megfogalmazva) jelenleg más bizonyíték nincs arra vonatkozóan, hogy valóban történt volna kibertámadás a Caracas-i vagy venezuelai villamosenergia-rendszer ellen - így aztán kénytelenek vagyunk szétválasztani, mi az, amit biztosan tudunk és mi az, amit (bizonyítékok hiányában) csak feltételezhetünk.

Amit tudunk:

1. Az amerikai fegyveres erők nagyjából minden fegyvernemének (hadsereg, haditengerészet, légierő) és a tengerészgyalogságnak is megvannak a saját kiberhadviselési egységei és képességei, nem is beszélve a kiterjedt amerikai hírszerzési szervezetekről (a lista elején rögtön ott az NSA és a CIA, de ugye jó hosszan lehetne még sorolni a különböző szerveket).

2. Az amerikai fegyveres erők nem csak a képességekkel rendelkeznek egy kibertérben végrehajtott támadáshoz, hanem a tervekkel is, hogy ilyen jellegű támadásokkal támogassanak egy kinetikus hadműveletet.

Amit viszont csak feltételezhetünk:

Ha történt ilyen támadás, mi lehetett a célja? Egyrészt egy kiterjedt (akár "csak" Caracas-ra korlátozott) áramkimaradás képes lehet jelentősen csökkenteni a támadó erőkre (legyenek azok akár a légitámadásokat végrehajtó repülőgépek vagy helikopterek, akár a Nicolas Maduro-ért induló Delta Force alakulat) veszélyt jelentő venezuelai alakulatok képességeit, másrészt ezt olyan módon tudják elérni, hogy később ne kelljen a szétlőtt/felrobbantott infrastruktúra-elemek (pl. villamosenergia-alállomások) újjáépítésével foglalkozni. Mivel Trump elnök nem sokkal később már "Venezuela irányításának átvételéről" is beszélt, ez is reális motiváció lehetett egy kibertámadással történő üzemzavar előidézésére.

Nem lehet szó nélkül elmenni az alig 3 hete történt kibertámadás mellett, ami a venezuelai állami olajtársaság, a PDVSA rendszereit érte. Bár akkor a venezuelai kormány állítása szerint a PDVSA folyamatirányító rendszereit nem érintette az incidens és azonnal az USA-t vádolták a támadásokkal (ami kb. annyira volt várható, mint amikor egy iráni létesítmény üzemzavaráért Teherán azonnal Izraelt és az USA-t vádolja mindennel, a kibertámadástól a kalózkodásig), Trump elnök mostani sejtetése ezt is más megvilágításba helyezheti.

Szintén nem lehetek biztos a következő feltételezéseimben, de tartok tőle, hogy ez az incidens (a fegyveres támadás és a feltételezhető kibertámadás) ugyanolyan mérföldköve lehet a kritikus infrastruktúrák elleni támadásoknak, mint amilyen a Stuxnet és a 2015-ös ukrán áramszolgáltatók elleni támadások voltak. Sajnos egyáltalán nem lennék meglepve, ha a közeljövő politikai és katonai konfliktusai során egy nyíltabbá válnának a kibertámadások is (amiket eddig minden, ebben érdekelt és ezért felelős kormány hivatalosan tagadott). A kritikus infrastruktúrák biztonsági helyzete tovább romlik és egyre kevésbé látom, hogy lehetne ilyen kaliberű támadásokkal szemben megvédeni őket - lehet, hogy nem marad más hátra, mint felkészülni a digitális folyamatirányító rendszerek elvesztésére és ilyen esetekben felkészülten visszatérni a manuális vezénylésre. Már ahol erre van lehetőség...

Update: a kérdőjel az ebben a cikkben írtak alapján feleslegessé vált, ezért ki is töröltem. Dan Caine tábornok, az USA vezérkari főnökei egyesített bizottságának vezetője egyértelműen megerősítette, hogy a Caracas-i villamosenergia-rendszer üzemzavarát kibertámadás idézte elő, amit az USA fegyveres erőihez tartozó egységek (Cyber Command, Space Command) katonái hajtottak végre, ezzel támogatva a Nicolas Maduro elfogására induló Delta Force operátorokat.

süti beállítások módosítása