2018. során több alkalommal is írtam a VPNFilter nevű malware-ről, amely (sok más incindens mellett) felelőssé tehető egy ukrán viziközmű cég ICS rendszerei elleni támadásért.

Két és fél (lassan inkább három) évvel az első blogposzt után újabb információk jelentek meg a VPNFilter-rel kapcsolatban, ezek szerint még mindig találhatóak az Interneten olyan eszközök, ahol a fertőzést még nem sikerült felszámolni.

Az elmúlt években számos olyan intézkedés történt (pl. C&C domainek lefoglalása), amiknek köszönhetően a VPNFilter gyakorlatilag lekapcsolt állapotba került, ráadásul a TrendMicro elemzése szerint egyes támadók az IoT botnetek építése során is hajlamosak a mások által már kompromittált eszközökről eltávolítani a riválisaik által telepített malware-eket és backdoorokat, hogy utána az adott eszközt a saját botnet-hálózatuk tagjaként használják tovább, ez is csökkentette a VPNFilter-rel fertőzött IoT eszközök számát.

A VPNFilter továbbélésével kapcsolatos további részleteket, technikai információkat és tanácsokat a TrendMicro fent hivatkozott cikkében lehet találni.

Siemens rendszerek sérülékenységei

Carsten Eiram, a Risk Based Security munkatársa, a ZDI-vel együttműködve öt sérülékenységről osztott meg részleteket a DHS CISA-val, amik a Siemens alábbi rendszereit érinti:

- JT2Go minden, V13.1.0.2-nél korábbi verziója;
- Teamcenter Visualization minden, V13.1.0.2-nél korábbi verziója.

A gyártó a hibákat az érintett rendszerek V13.1.0.2-es verzióiban javította. A sérülékenységekről további részleteket a Siemens ProductCERT publikációja tartalmaz.

VNC sérülékenységek Siemens SIMATIC HMI/WinCC termékekben

A Siemens bejelentése szerint a SmartVNC-t használó termékeikben 7, az UltraVNC-t használó termékeikben pedig 10 sérülékenységet találtak. Az érintett termékek és verzióik:

- SIMATIC HMI Comfort Outdoor panelek 7"-os és 15"-os változatainak (beleértve a SIPLUS változatokat is) minden, V16 Update 4-nél korábbi verziója;
- SIMATIC HMI Comfort panelek 4-től 22 colosig terjedő változatainak (beleértve a SIPLUS változatokat is) minden, V16 Update 4-nél korábbi verziója;
- SIMATIC HMI KTP Mobile panelek KTP400F, KTP700, KTP700F, KTP900 és KTP900F változatainak minden, V16 Update 4-nél korábbi verziója;
- SIMATIC WinCC Runtime Advanced minden, V16 Update 4-nél korábbi verziója.

A gyártó a hibát az érintett rendszerei V16 Update 4-es verziójában javította. A sérülékenységekkel kapcsolatos bővebb információkat a Siemens ProductCERT bejelentéseiben lehet megtalálni.

Siemens SCALANCE hálózati eszközök sérülékenységei

A Siemens weboldalán megjelent hírek szerint az alábbi, Aruba-alapokra épített termékeikben 19 sérülékenység található:

- SCALANCE W1750D minden, V8.7.0-nél korábbi verziója;
- SCALANCE W1750D V8.7.0 verziója (a 19-ből 12 sérülékenység érinti ezt a verziót).

A gyártó a hibák egy részét a V8.7.0 és későbbi verziókban javította, a többi esetén kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységek részleteiről a Siemens ProductCERT weboldalán lehet olvasni.

Sérülékenységek Emerson X-STREAM gázelemző szoftverekben

Az Emerson összesen hat sérülékenységről osztott meg információkat a DHS CISA-val, ami az X-STREAM gázelemző szoftvereinek alábbi verzióit érinti:

- X-STREAM enhanced XEGP minden revíziója;
- X-STREAM enhanced XEGK minden revíziója;
- X-STREAM enhanced XEFD minden revíziója;
- X-STREAM enhanced XEXF minden revíziója.

A gyártó a hibákkal kapcsolatban a legújabb elérhető firmware-verzióra történő frissítést javasolja. A sérülékenységekről további részleteket az ICS-CERT webodalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-138-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.

A floridai Oldsmar viziközmű vállalatának ICS rendszere elleni támadás meglehetősen nagy visszhangot keltett (én is írtam róla), most pedig a Dragos egy érdekes elemzést publikált, amiben arról írnak, hogy az Oldsmar-i incidens vizsgálata során egy olyan támadó nyomait fedezték fel, aki(k?) egy, a floridai vízmű-cégek számára szolgáltató vállalat weblapját használták fel egy watering hole támadás-sorozathoz, amelyben főként, de korántsem kizárólag floridai szervezektől érkező felhasználók adatait gyűjtötték a támadók. A vizsgálat során gyűjtött telemetriai adatok alapján az derült ki, hogy sok más szervezet munkatársai mellett az Oldsmar-i viziközmű cég egyik munkatársa is letöltötte a támadók által kártékony kóddal preparált weboldalt, ráadásul ugyanazon a napon, mint amikor a támadás történt. Vajon ez véletlen volt? (Valakitől, valahol egyszer azt hallottam, hogy nem szereti a véletleneket, túl sok szervezést igényelnek...)

A vizsgálatról készült részletes elemzés a Dragos blogján érhető el, engem most ez az eset azért késztetett posztírásra, hogy megpróbáljam kihangsúlyozni: a jelenkori kibertámadások és különösképpen az ICS/OT kibertámadások esetén célszerű óvakodni a gyorsan levont, sarkos következtetésekről, ilyen esetekben célszerű a megfelelő forensics szakértők bevonásával minél alaposabb elemzéseket készítenie az incidenst elszenvedett cégnek, akik pedig (hozzám hasonlóan) az ilyen incidensekről a partvonalról írnak, hasznos, ha a hangzatos következtetések levonásával megvárják a részletesebb információkat az adott esettel kapcsolatban.

Sérülékenység Schneider Electric Modicon switch-ekben

A Schneider Electric egy sérülékenységről közölt információkat, ami a Modicon Managed Switch termékei közül az MCSESM és MCSESP sorozatok V8.21-es és korábbi verzióit érinti.

A gyártó a hibát a 8.22-es verzióban javította. A sérülékenységről további információkat a Schneider Electric publikációjában lehet találni.

Sérülékenység Schneider Electric Harmony HMI-ok konfigurációs szoftvereiben

Jie Chen, az NSFOCUS munkatársa egy sérülékenységet talált a Schneider Electric alábbiakban felsorolt Harmony HMI termékeinek konfigurációjához használható, következő szoftverekben:

Vijeo Designer minden, V6.2 SP11-nél korábbi verziójával konfigurált HMI-ok:
- Harmony STO;
- Harmony STU;
- Harmony GTO;
- Harmony GTU;
- Harmony GTUX;
- Harmony GK;

EcoStruxure™ Machine Expert V2.0 és korábbi verzióival konfigurált HMI-ok:
- Harmony HMISCU.

A gyártó a hibát az érintett szoftverek újabb verzióiban javította. A sérülékenységgel kapcsolatos részleteket a Schneider Electric bejelentésében lehet elérni.

Schneider Electric Triconex sérülékenységek

A CNCERT/CC és a Kunlun Digital Technology Co.,Ltd munkatársai 6 sérülékenységet azonosítottak a Schneider Electric Tricon v11.3.x rendszereibe épített Triconex 3009 MP és TCM 4351B típusú eszközeiben.

A gyártó a hibákat az érintett termékek legújabb verzióiban javította. A sérülékenységekről bővebben a Schneider Electric weboldalán lehet olvasni.

Sérülékenységek Schneider Electric homeLYnk és spaceLYnk rendszerekben

Sharon Brizinov, a Claroty munkatársa 9 sérülékenységet fedezett fel a Schneider Electric alábbi termékeiben:

- homeLYnk (Wiser For KNX) V2.60 és korábbi verziói;
- spaceLYnk V2.60 és korábbi verziói.

A kilencből hat sérülékenységet a gyártó az érintett termékek V2.61-es verziójában javította, a többi három sérülékenységgel kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről további részleteket a Schneider Electric publikációja tartalmaz.

Sérülékenység Schneider Electric Modicon PLC-kben

Marcin Dudek, Kinga Staszkiewicz, Jakub Suchorab és Joanna Walkiewicz, a lengyel Nemzeti Nukleáris Kutatóintézet munkatársai egy sérülékenységet jelentettek a Schneider Electric-nek, ami a gyártó Modicon M241/M251 típusú vezérlőinek V5.1.9.1-esnél korábbi verzióit érinti.

A gyártó a hibát az érintett rendszerekhez kiadott legújabb verziókban javította. A sérülékenység részleteit a Schneider Electric bejelentésében lehet megtalálni.

Sérülékenységek Schneider Electric termékekben

A Schneider Electric által nyilvánosságra hozott információk szerint 6 sérülékenység, amiket a 3S CODESYS Schneider Electric által az alábbi termékeibe beépített komponenseiben találtak, érinti ezeket a rendszereket is:

- EcoStruxure Machine Expert minden, V2.0-nál korábbi verziója;
- Modicon M218 minden, V5.1.0.6-nál korábbi verziója;
- Modicon M241 minden, V5.1.9.14-nél korábbi verziója;
- Modicon M251 minden, V5.1.9.14-nél korábbi verziója;
- Modicon M262 minden, V5.1.5.30-nál korábbi verziója;
- LMC PacDrive Eco/Pro/Pro2 minden, V1.64.18.26-nál korábbi verziója;
- Vijeo Designer and HMISCU, minden V6.2 SP11-nél korábbi verziója;
- ATV IMC minden verziója;
- SoMachine/SoMachine Motion minden verziója.

A gyártó a hibákat az ATV IMC vezérlők esetén már nem javítja, a többi érintett termék esetén a legújabb verzió tartalmazza a javításokat. A sérülékenységekkel kapcsolatban további részleteket a Schneider Electric weboldalán lehet elérni.

Schneider Electric EcoStruxure Geo SCADA Expert sérülékenység

Nicholas Hobbs egy sérülékenységet talált a Schneider Electric alábbi termékeiben:

- ClearSCADA minden verziója;
- EcoStruxure Geo SCADA Expert 2019 minden verziója;
- EcoStruxure Geo SCADA Expert 2020 V83.7742.1-es és korábbi verziói.

A gyártó a hibát az EcoStruxure Geo SCADA Expert 2020 83.7787.1-es verziójában javította. A sérülékenységgel kapcsolatos részleteket a Schneider Electric publikációjában lehet elolvasni.

Sérülékenység Siemens SCALANCE eszközökben

A Siemens egy sérülékenységről közölt információkat a DHS CISA-val, ami a SCALANCE termékvonal alábbi tagjait érinti:

- SCALANCE XM-400 család minden, v6.4-nél korábbi verziója;
- SCALANCE XR-500 család minden, v6.4-nél korábbi verziója.

A gyártó a hibát a v6.4-es és újabb verziókban javította. A sérülékenység részleteiről és további kockázatcsökkentést célzó javaslatokról a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet tájékozódni.

Siemens Mendix Excel importáló modul sérülékenysége

A Siemens egy sérülékenységet jelentett a DHS CISA-nak a Mendix alkalmazás Excel importáló moduljának v9.0.3-asnál régebbi verzióiban.

A gyártó a hibát a v9.0.3-as verzióban javította. A sérülékenységgel kapcsolatos további információkat a Siemens ProductCERT és az ICS-CERT weboldalaink lehet találni.

Siemens Tecnomatix Plant Simulation rendszerek sérülékenységei

Francis Provencher, a ZDI-vel együttműködve három sérülékenységet jelentett a DHS CISA-nak a Siemens Tecnomatix Plant Simulation nevű megoldásának minden, 16.0.5-ösnél korábbi verzióiban.

A gyártó a hibákat a 16.0.5-ös és újabb verziókban javította. A sérülékenységekről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenység Siemens SIMATIC eszközökben

A Siemens egy sérülékenységről osztott meg részleteket a DHS CISA-val, ami az alábbi, SIMATIC termékcsaládba tartozó eszközeiket érinti:

- SIMATIC NET CP 343-1 Advanced (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC NET CP 343-1 Lean (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC NET CP 343-1 Standard (beleértve a SIPLUS változatokat is) minden verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatos további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet elérni.

SNMP sérülékenység Siemens WinCC rendszerekben

Younes Dragoni és Alessandro Di Pinto, a Nozomi Networks munkatársai egy, az SNMP szolgáltatáshoz kapcsolódó sérülékenységet jelentettek a Siemens-nek a WinCC Runtime alábbi komponenseiben:

- Első generációs SIMATIC HMI Comfort Panelek (beleértve a SIPLUS változatokat is) minden, v16 update 4-nél korábbi verziója;
- SIMATIC HMI KTP Mobile Panelek minden, v16 update 4-nél korábbi verziója.

A hibát a gyártó az érintett termékek 16 update 4 és újabb verzióiban javította. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Siemens Mendix adatbázis replikációs modul sérülékenysége

A Siemens egy sérülékenységről osztott meg információkat a DHS CISA-val, ami a Mendix adatbázis replikációs moduljának v7.0.1-nél korábbi verzióit érinti.

A gyártó a hibát a v7.0.1-es és újabb verziókban javította. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT publikációiból lehet tájékozódni.

Sérülékenység Siemens SINAMICS középfeszültségű termékekben

A Siemens egy sérülékenységről közölt információkat a DHS CISA-val, ami az alábbi SINAMICS HMI Comfort paneleket érinti:

- SINAMICS SL150 minden verziója;
- SINAMICS SM150 minden verziója;
- SINAMICS SM150i minden verziója.

A gyártó a hibát javító újabb verziót már elérhetővé tette. A sérülékenységgel kapcsolatos bővebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet megtalálni.

Linux-alapú Siemens termékek sérülékenysége

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi, Linux-alapú termékeikben található meg:

- RUGGEDCOM RM1224 minden, v5.0 és v6.4 közötti verziója;
- SCALANCE M-800 minden, v5.0 és v6.4 közötti verziója;
- SCALANCE S615 minden, v5.0 és v6.4 közötti verziója;
- SCALANCE SC-600 minden, v2.1.3-nál korábbi verziója;
- SCALANCE W1750D v8.3.0.1-es, v8.6.0 és v8.7.0 verziói;
- SIMATIC Cloud Connect 7 minden verziója;
- SIMATIC MV500 család minden verziója;
- SIMATIC NET CP 1243-1 (beleértve a SIPLUS változatokat is) 3.1.39-es és későbbi verziói;
- SIMATIC NET CP 1243-7 LTE EU 3.1.39-es és későbbi verziói;
- SIMATIC NET CP 1243-7 LTE US 3.1.39-es és későbbi verziói;
- SIMATIC NET CP 1243-7 3.1.39-es és későbbi verziói;
- SIMATIC NET CP 1243-8 IRC 3.1.39-es és későbbi verziói;
- SIMATIC NET CP 1542SP-1 IRC (beleértve a SIPLUS változatokat is) 2.0 és későbbi verziói;
- SIMATIC NET CP 1542SP-1 2.0 és későbbi verziói;
- SIMATIC NET CP 1543-1 (beleértve a SIPLUS változatokat is) 2.2 és későbbi verziói;
- SIMATIC NET CP 1543SP-1 (beleértve a SIPLUS változatokat is) 2.0 és későbbi verziói;
- SIMATIC NET CP 1545-1 minden verziója;
- SINEMA Remote Connect Server minden, v3.0 SP1-nél korábbi verziója;
- TIM 1531 IRC (beleértve a SIPLUS változatokat is) minden verziója.

A gyártó az alábbi, sérülékenység által érintett termékek esetében adott ki javítást a hibára:

- RUGGEDCOM RM1224;
- SCALANCE M-800;
- SCALANCE S615;
- SCALANCE SC-600;
- SINEMA Remote Connect Server.

A sérülékenység részleteit a Siemens ProductCERT és az ICS-CERT weboldalain lehet elolvasni.

Sérülékenység Mitsubishi Electric rendszerekben

Parul Sindhwad és Dr. Faruk Kazi, a Mumbai-i COE-CNDS Lab munkatársai egy sérülékenységet találtak a Mitsubishi Electric alábbi rendszereiben:

- GOT2000 sorozat
- GT27 modell 01.19.000-tól 01.38.000-ig terjedő verziói;
- GT25 modell 01.19.000-tól 01.38.000-ig terjedő verziói;
- GT23 modell 01.19.000-tól 01.38.000-ig terjedő verziói;
- GT21 modell 01.21.000-tól 01.39.000-ig terjedő verziói;
- GOT SIMPLE sorozat
- GS21 modell 01.21.000-tól 01.39.000-ig terjedő verziói;
- GT SoftGOT2000 1.170C-től 1.250L-ig terjedő verziói;
- LE7-40GU-L: Screen package data for MODBUS/TCP v1.00.

A gyártó a hibát javító új verziókat már elérhetővé tette. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-131-02

Omron CX-One rendszerek sérülékenysége

rgod a ZDI-vel együttműködve egy sérülékenységet jelentett a DHS CISA-nak, ami az Omron alábbi rendszereit érinti:

- CX-One 4.60-as és korábbi verziói, beleértve a CX-Server 5.0.29.0 és korábbi verzióit.

A gyártó a hibát az érintett megoldások újabb verzióiban javította. A sérülékenység részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-131-01

Sérülékenység OPC UA termékekben

Eran Jacob, az Otorio Research Team munkatársa egy sérülékenységről közölt információkat a DHS CISA-val, ami az OPC alábbi rendszereit érinti:

- A .NET-alapú OPC UA Client/Server SDK csomag V3.0.7 és korábbi (.NET 4.5, 4.0 és 3.5 Framework) verziók.

A gyártó a hibát javító újabb verziót elérhetővé tette a weboldalán. A sérülékenységről bővebben az ICS-CERT webodlalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-133-04

OPC UA Server sérülékenység

Eran Jacob, az Otorio Research Team munkatársa egy sérülékenységet talált az OPC alábbi termékeiben:

- OPC UA .NET Standard 1.4.365.48-nál korábbi verziói;
- OPC UA .NET Legacy.

A gyártó a hiba javítását már elérhetővé tette. A sérülékenység részleteit az ICS-CERT publikációjából lehet megismerni: https://us-cert.cisa.gov/ics/advisories/icsa-21-133-03

Sérülékenység Sensormatic Electronics rendszerekben

A Johnson Controls, a Sensormatic Electronics anyavállalata egy sérülékenység részleteiről tájékoztatta a DHS CISA-t, ami a Tyco AI nevű Sensormatic Electronics-megoldás v1.2 és korábbi változatait érinti.

A gyártó a Tyco AI v1.3-ban javította a most megtalált hibát. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-133-02

Sérülékenységek Rockwell Automation rendszerekben

Mashav Sapir, a Claroty munkatársa három sérülékenységet fedezett fel a Rockwell Automation alábbi rendszereiben:

- Connected Components Workbench v12.00.00 és korábbi verziói.

A gyártó a hibát a v13.00.00 és újabb verziókban javította. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-133-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.

Az APT10 (Dragos terminológia szerint Talonite) az egyik legrégebben aktív, ICS rendszereket támadó csoport. Módszereik közé kártékony kódot tartalmazó csatolmányokkal ellátott adathalász e-mailek és egyedi malware-ek tartoznak, célpontjaik pedig főként amerikai, japán és tajvani villamosenergia-ipari cégek.

Bár az egyes csoportok nemzetiségéről nem szokás megemlékezni, az APT10 esete ebből a szempontból különleges, mert az FBI nem csak, hogy Kínához kötötte a csoportot, de két tagjukról névvel és fényképpel ellátott körözést is kiadott (márpedig az FBI körözési listájára azért még ma sem olyan könnyű felkerülni): https://www.fbi.gov/wanted/cyber/apt-10-group

Az évek során az APT10/Talonite csoportról számos hosszabb rövidebb elemzés jelent meg, néhány ezek közül:

Cysiv
Dragos
FireEye
MalwareBytes

Számos hírforrás hozta le a mai nap folyamán a hírt, miszerint kibertámadás érte a Colonial Pipeline nevű amerikai cég (amely naponta közel félmillió liter üzemanyagot szállít csővezetékein) rendszereit pénteken. A támadás (egyelőre ransomware-támadásról lehet hallani) "egyes IT rendszereiket" érte, és "elővigyázatosságból ideiglenesen leállították bizonyos rendszereiket, köztük egyes, a csővezetékek üzemeltetésében érintett rendszereket is."

További részletek egyelőre nem ismertek, de az már a tavalyi évben is tisztán látszott, hogy már nincs olyan iparág, amit ne vennének célba a különböző ransomware-ek - vajon a magyar vállalatok mennyire felkészültek az ilyen fenyegetésekre?

Szerk (2021.05.10.): Még mindig keveset tudunk, de egy ismerősömtől (aki igencsak otthonosan mozog az USA kritikus infrastruktúrájának kiberbiztonsági kérdéseiben) azt a véleményt hallottam, hogy az ügyviteli IT rendszerek érintettsége (ha például a üzemanyag-kereskedéshez használt rendszerek is érintettek) miatt is dönthettek úgy, hogy inkább leállítják a csővezeték rendszer irányításáért felelős rendszereket és ezzel magát a vezetékeket is. Egy ilyen döntéshez az én meglátásom szerint nagyon komoly pénzügyi kockázatelemzési képességekkel kell rendelkezni, hiszen az egyik kockázatot (a teljes csővezeték leállítása okozta pénzügyi veszteséget) kell szembeállítani a másik kockázattal (a nem működő kereskedéshez használt rendszer nélkül történő üzemanyag-szállításból eredeztethető anyagi veszteséggel). A forrásom szerint egyébként nem ez az első ilyen, csővezeték-hálózat IT/OT rendszereit érintő kiberbiztonsági incidens.

Ezzel párhuzamosan a blogon már jó néhányszor hivatkozott Robert M. Lee is megszólalt az incidens kapcsán, a Twitteren az alábbiakat írta (nem szoktam angol forrásokat hosszan idézni a blogon, de ebben a gondolatmenetben több olyan dolog is megjelenik, amikről a következő hetekben lehetne és kéne kicsit részletesebben írni - remélem lesz időm, de ha bárkinek van ehhez vagy bármelyik másik részhez kapcsolódóan véleménye, csak bátran, akár a kommentek között is elindulhat egy érdekes beszélgetés):

"In my opinion there's some bad takes out there but overall it's completely reasonable that folk are paying attention. This is the most disruptive incident we've seen on US energy infrastructure from cyber instrusions. Colonial Pipeline is the victim and has done a lot right. They contacted a top tier incident response firm (FireEye/Mandiant) for the enterprise compromise (only IT impacted it seems) to lead the response. They informed the USG [US Government - szerk.] who had great folks form CISA/FBI/DOE supporting. They focused on safety and took operations down proactively.

Congress and others will reasonably ask: "If a criminal can do this, what more could a state adversary do?" While we should avoid hype this is a very reasonable question. The reality is our infrastructure is undergoing a rapid digital transformation. While the ransomware was confined to IT this could have been much worse if it had hit OT and at Dragos we have handled such cases and they candidly suck. AS our industries change the historical mindset of "segment and disconnect OT" just isn't practical in most cases. 75+% of many of the standards/regulations/frameworks/etc. push for preventive controls (segmentation, authentication, anti malware, patching, etc.) all good controls but that leaves an under investment in detection and response. As our infrastructure changes, so will our threats.

What we see most commonly is without visibility and monitoring in OT networks the preventive controls are not applied everywhere and atrophy over time unkowningly to the defenders. Many realize this though. The current White House administration has rightfully pushed for a 100 day action plan to encourage visibility, detection, and response enchancements in OT in the electricity sector and likely following suit in water and natural gas to raise awareness.

To the practitioners out there thinking about their OT networks I would encourage engaging firms with OT/ICS incident response experience. Conduct a TTX to reherse. Use burn down to do an Architecture Review of what you have today and it's state. Then move into monitoring in OT. For the executives out there realize your IT and Security staff are usually already under invested in. Picking up a whole new mission set with focus (OT) requires additional resources. Elevate the conversation in your org and invest in your people to enable your business."

Szerk2: A hírek továbbra is csordogálnak, most a Waterfall és a Dragos incidenssel kapcsolatos posztjaiba futottam bele, mint érdekesebb forrásokba illetve egy hazai, légiközlekedéssel foglalkozó oldal, az AirPortal.hu cikke érdekes még, ami szerint a Colonial Pipeline ideiglenes csővezeték-leállítása már 2-3 nap után komolyan érezteti a hatását az USA egyes déli és keleti szövetségi államaiban található repülőterek kerozin-ellátásában.

Még egy érdekesség: Miközben a Dragos blogposzt linkjét kerestem, találtam egy másik, 2020. elején született írásukat, ahol egy földgáz szállításra használt másik csővezetéket üzemeltető vállalat elleni ransomware-támadásról írnak (ez annak idején az én figyelmemet is elkerülte). Szóval a forrásomnak teljes mértékben igaza volt, amikor azt mondta, nem ez volt az első eset, amikor az USA energiaszektorában használt csővezetékeket üzemeltető céget ért zsarolóvírus-támadás.

Az IBM (és X-Force néven ismert biztonsági kutatócsapata) nem túl gyakran kerülnek szóba az ICS kiberbiztonsággal kapcsolatban, pedig egy alapvetően jó és tapasztalt csoportról van szó. A még március végén megjelent Threat Intelligence Index nevű éves kiadványukban számunkra most az az igazán érdekes, hogy az általuk feltárt kutatási adatok alapján a három dobogós szektor közül (akiket a legtöbb célzott kibertámadás ért 2020-ban), kettő (a második és harmadik helyezett, az első még mindig a pénzügyi szektor) ipari szektor. A második helyre a gyártóvállalatok kerültek, a harmadik helyen pedig már az energiaszektor, vagyis a nemzeti kritikus infrastruktúrák alfája és omegája került.

A gyártóvállalatok elleni támadások egy jelentős része zsarolóvírus-támadás volt, amik számos esetben jelentős veszteséggel járó, hosszabb-rövidebb leállásokat okoztak a termelésirányítási és készletezési-raktározási rendszerekben.

Az energiaszektorban tapasztalt támadások valamivel több, mint harmada (35%-a) adatlopási kísérlet volt, itt a ransomware-ek "csak" 6%-ot tettek ki.

Hasonló tendenciákat lehet látni a Kaspersky 2020 második félévet felölelő ICS biztonsági összefoglalójában, ami az egyes országok ICS rendszerei és berendezései elleni zsarolóvírus-támadások növekedéséről számol be.

A hivatkozott összefoglalók kiválóan illeszkednek a többi, hasonló kiadvány sorába és mutatja, hogy az ipari szervezetek és ezek ICS rendszerei egyre nagyobb kiberbiztonsági kockázatokkal működnek, amikre ezeknek a szervezeteknek hatékony és gyors válaszokat kell adniuk. Ez nem fog működni máshogy, mint az IT és OT szakterületek soha korábban nem látott hatékonyságú együttműködésével - ez azonban nem vagy csak fájdalmasan lassan fog megvalósulni, ha alulról építkezve, az IT-s és OT-s mérnökök által kezdeményezve akarják a szervezetek felépíteni az együttműködést és a vállalati menedzsment nem vállal ebben (is) vezető szerepet.

Sérülékenységek Moxa NPort készülékekben

Alexander Nochvay, a Kaspersky Lab ICS CERT részlegének munkatársa négy sérülékenységet fedezett fel a Moxa alábbi termékeiben:

- NPort IA5150A/IA5250A sorozatú berendezések 1.4-es és korábbi firmware-verziói;
- NPort IA5450A sorozetú eszközök 1.7-es és korábbi firmware-verziói.

A hibákkal kapcsolatban a gyártó javításokat és kockázatcsökkentő intézkedésekre vonatkozó javaslatokat adott ki. A sérülékenységek részleteiről a Moxa bejelentéséből lehet tájékozódni.

Johnson Controls exacqVision sérülékenység

A Johnson Controls egy sérülékenységről közölt információkat a DHS CISA-val, ami az Exacq Technologies nevű leányvállalatuk alábbi, Ubuntu-alapú rendszereit érinti:

- a Linux-alapú Z- és A-sorozatú termékeik;
- Q-sorozat;
- G-sorozat;
- Legacy LC-sorozat;
- Legacy ELP-sorozat;
- exacqVision Network Video Recorders (NVR);
- a Linux-alapú C-sorozatú munkaállomások;
- S-sorozatú storage szerverek.

A gyártó a hibával kapcsolatban a megfelelő Ubuntu biztonsági javítások telepítését javasolja. A sérülékenységről további információkat az ICS-CERT publikációja: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-03

Sérülékenység Cassia Networks rendszerekben

Amir Preminger és Sharon Brizinov, a Claroty munkatársai egy sérülékenységet találtak a Cassia Networks Access Controllereinek 2.0.1-nél korábbi verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette. A sérülékenységgel kapcsolatos részleteket az ICS-CERT weboldalán lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-02

Texas Instruments rendszerek sérülékenységei

David Atch és Omri Ben Bassat, a Microsoft munkatársai öt sérülékenységet azonosítottak a Texas Instruments alábbi termékeiben:

- SimpleLink MSP432E4 SDK v4.20.00.12 és korábbi verziói;
- SimpleLink CC32XX SDK v4.30.00.06 és korábbi verziói;
- SimpleLink CC13X0 SDK v4.10.03-nál korábbi verziói;
- SimpleLink CC13X2 SDK v4.40.00-nál korábbi verziói;
- SimpleLink CC26XX SDK v4.40.00-nál korábbi verziói;
- CC3200 SDK v1.5.0 és korábbi verziói;
- CC3100 SDK v1.3.0 és korábbi verziói.

A hibákat a gyártó az érintett termékek legújabb verzióiban javította. A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-01

Delta Electronics CNCSoft ScreenEditor sérülékenység

Kimiya, a ZDI-vel együttműködve egy sérülékenységről közölt információkat a DHS CISA-val, ami a Delta Electronics CNCSoft ScreenEditor nevű megoldásának v1.01.28-nál korábbi verzióit érinti.

A gyártó a hibát a v.1.01.30-as verzióban javította. A sérülékenységgel kapcsolatos további részleteket az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-124-02

Sérülékenység Advantech rendszerekben

Chizuru Toyama, a TXOne IoT/ICS Security Research Labs munkatársa a ZDI-vel közösen egy sérülékenységet jelentett a DHS CISA-nak, ami az Advantech WISE-PaaS/RMM 9.0.1-nél korábbi verzióit érinti.

A gyártó az érintett termék forgalmazását és támogatását megszüntette, így a hibához javítás sem várható. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-124-01

Sérülékenységek valós idejű operációs rendszerekben (RTOS)

David Atch, Omri Ben Bassat és Tamir Ariel, a Microsoft Section 52 munkatársai, valamint az Azure Defender for IoT research group munkatársai összesen 23 sérülékenységről osztottak meg információkat a DHS CISA-val, amik az alábbi valós idejű operációs rendszereket (Real-Time Operating System, RTOS) érintik:

- Amazon FreeRTOS 10.4.1-es verziója;
- Apache Nuttx OS 9.1.0 verziója;
- ARM CMSIS-RTOS2 2.1.3-nál korábbi verziója;
- ARM Mbed OS 6.3.0 verziója;
- ARM mbed-uallaoc 1.3.0 verziója;
- Cesanta Software Mongoose OS v2.17.0 verziója;
- eCosCentric eCosPro RTOS 2.0.1-től 4.5.3-ig terjedő verziói;
- Google Cloud IoT Device SDK 1.0.2 verziója;
- Linux Zephyr RTOS 2.4.0-nál korábbi verziói;
- Media Tek LinkIt SDK 4.6.1-nél korábbi verziói;
- Micrium OS 5.10.1-es és korábbi verziói;
- Micrium uCOS II/uCOS III 1.39.0 és korábbi verziói;
- NXP MCUXpresso SDK 2.8.2-nél korábbi verziói;
- NXP MQX 5.1 és korábbi verziói;
- Redhat newlib 4.0.0-nál korábbi verziói;
- RIOT OS 2020.01.1 verziója;
- Samsung Tizen RT RTOS 3.0.GBB-nél korábbi verziói;
- TencentOS-tiny 3.1.0 verziója;
- Texas Instruments CC32XX 4.40.00.07-nél korábbi verziói;
- Texas Instruments SimpleLink MSP432E4XX
- Texas Instruments SimpleLink-CC13XX 4.40.00-nál korábbi verziói;
- Texas Instruments SimpleLink-CC26XX 4.40.00-nál korábbi verziói;
- Texas Instruments SimpleLink-CC32XX 4.10.03-nál korábbi verziói;
- Uclibc-NG 1.0.36-nál korábbi verziói;
- Windriver VxWorks 7.0-nál korábbi verziói.

A hibákra az egyes gyártók által kiadott javításokért és további részletekért az ICS-CERT publikációját érdemes átnézni: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-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.

Az okosmérők az ICS biztonság egyik méltatlanul háttérbe szorult komponens-csoportját alkotják, éppen ezért örültem, hogy nemrég a FireEye (illetve a FireEye-hoz tartozó Mandiant) kutatói egy okosmérők biztonsági teszteléséről szóló cikket publikáltak.

Az okosmérők egyre gyorsabban terjednek, ha valaki pl. "villanyóra" cserét kér az áramszolgáltatójától (akár csak bővítés, akár háztáji naperőmű kiépítése miatt), szinte biztos, hogy ilyen berendezést fognak felszerelni nála, vagyis a hazai mérőórák (nem csak az áramszolgáltatók mérői, de azok talán a legnagyobb mértékben) egyre nagyobb hányada képes már kommunikálni valamilyen (többnyire publikus) hálózaton. Azt pedig tudjuk, hogy ami képes publikus hálózaton, szabványos protokollon kommunikálni, azt előbb vagy utóbb meg fogják találni azok az emberek is, akik vagy szakmai kíváncsiságtól hajtva és kizárólag a legjobb szándékkal vagy kevésbé jó szándékkal és saját céljaiktól (bármik is legyenek azok) vezérelve elkezdenek hibákat keresni ezekben a berendezésekben. Hibák viszont minden, szoftver-vezérelt eszközben lesznek, ezt ma már szinte senki sem vitatja, ami azt jelenti, hogy ezeket az eszközöket lehet informatikai eszközökkel és módszerekkel támadni, el lehet lehetetleníteni a működésüket illetve át lehet venni felettük az irányítást.

Itt most térjünk ki egy kicst Marc Elsberg Blackout című könyvére, amit én még 2016-ban olvastam és aminek a története azzal indul, hogy valakik kompromittálnak nagyszámú okos villamosenergia-mérőt Európai országokban, majd azokat egyszerre lekapcsolva a kontinens nagy részére kiterjedő üzemzavart idéznek elő. Amikor ezt a könyvet olvastam, beszélgettem néhány emberrel a villamosenergia-szektorból, akik határozottan állították, hogy ilyen módon nem lehet üzemzavart előidézni, én azonban már akkor és most is úgy gondolom, hogy néhány tényező együttállása esetén bizony nem is olyan lehetetlen egy hasonló forgatókönyv.

Egyrészt az nem igazán lehet kérdés, hogy az okosmérők szoftveresen ugyanolyan sérülékenyek lehetnek, mint bármilyen más "okos" eszköz, a fitnesz-karkötőtől az okoshűtőn keresztül az ipari IoT (IIoT) eszközökig.

Másrészt, amennyire én tudom (vajon jól tudom?) nincs olyan nagyon sok különböző gyártótól származó, eltérő firmware-családdal működő okosmérő egy-egy közüzemi szektorban, így a villamosenergia-szektorban is okkal feltételezhetjük, hogy nem túl sok különböző modell működik ezekből az okosmérőkből.

Ezek után már csak néhány olyan (0-day, vagyis javítást még nem kapott) sérülékenységre van szükség, valamint némi háttérre és szervezőkészségre, hogy egy támadói csoport nagy mennyiségű okosmérő kompromittálása után egy összehangolt akcióval már rendszer szinten érezhető fogyasztást tűntessen el egyik pillanatról a másikra a villamosenergia-rendszerből. Ekkor pedig már az áramszolgáltató, rosszabb esetben a villamos teherelosztó felkészültségén múlik, hogy egy ilyen incidenshez társul-e üzemzavar is?

Így talán már látható, miért érzem fontosnak az ilyen teszteket, publikációkat és kíváncsian várom, hogy hazai kutatók, IT és/vagy OT biztonsággal foglalkozó cégek mikor jelentkeznek olyan publikációkkal, amikben a hazai okosmérők biztonsági teszteléséről szóló tapasztalataikat osztják meg. Diplomamunka szintén született már színvonalas dolgozat a témában, de (amint a FireEye kutatóinak publikációjából is látszik) bőven van még hova fejlődni ebben a témában is.

Sérülékenységek Eaton rendszerekben

Amir Preminger, a Claroty munkatársa hat sérülékenységet fedezett fel az Eaton alábbi rendszereiben:

- Eaton Intelligent Power Manager (IPM) minden, 1.69-nél korábbi verziója;
- Eaton Intelligent Power Manager Virtual Appliance (IPM VA) minden, 1.69-nél korábbi verziója;
- Eaton Intelligent Power Protector (IPP) minden, 1.68-nál korábbi verziója.

A gyártó a hibákat az érintett termékek újabb verzióiban javította. A sérülékenységek részletiről az ICS-CERT publikációjából lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-06

Delta Electronics CNCSoft-B szoftverek sérülékenységei

Natnael Samson, a ZDI-vel együttműködve két sérülékenységet jelentett a DHS CISA-nak a Delta Electronics CNCSoft-B nevű szoftver-menedzsment platformjának 1.0.0.3-as és korábbi verzióiban.

A gyártó a hibákat az 1.0.0.4-es verzióban javította. A sérülékenységekkel kapcsolatos további információkat az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-05

Sérülékenység Delta Electronics CNCSoft ScreenEditor szoftverekben

Ugyancsak Natnael Samson találta azt a sérülékenységet, ami a CNCSoft 1.01.28-as és korábbi verziói közül a ScreenEditor 1.01.2-vel működő telepítéseit érinti.

A gyártó a hibát a CNCSoft 1.01.30-as verzióban javította. A sérülékenységről bővebb információkat az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-04

Delta Industrial Automation COMMGR sérülékenység

Peter Cheng, az Elex CyberSecurity CyberSpace Non-Attack Research Institute nevű kutatóközpontjának munkatársa egy sérülékenységet azonosított a Delta Industrial Automation COMMGR nevű kommunikáció-menedzsment szoftverének és az ahoz tartozó PLC-szimulátorának 1.12-es és korábbi verzióiban.

A gyártó a hibát az 1.13-as verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-03

Sérülékenységek Rockwell Automation Stratix hálózati eszközökben

A Cisco összesen 7 sérülékenységről közölt információkat a Rockwell Automation-nel, amik a gyártó Stratix nevű, ipari környezetekbe szánt hálózati eszközei közül az alábbiakat érintik:

- Stratix 5800 16.12.01 és korábbi verziói;
- Stratix 8000 15.2(7)E3 és korábbi verziói;
- Stratix 5700 15.2(7)E3 és korábbi verziói;
- Stratix 5410 15.2(7)E3 és korábbi verziói;
- Stratix 5400 15.2(7)E3 és korábbi verziói.

A gyártó a hibákat a Stratix 5800-asok esetén a 17.04.01-es és újabb verziókban javította, a többi érintett termék esetén kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatos további részleteket az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-02

Hitachi ABB Power Grids rendszerek sérülékenysége

A Hitachi ABB Power Grids egy sérülékenységről közölt információkat a DHS CISA-val, ami az Ellipse APM nevű termékeik alábbi verzióit érinti:

- Ellipse APM 5.3.0.1 és korábbi verziói;
- Ellipse APM 5.2.0.3 és korábbi verziói;
- Ellipse APM 5.1.0.6 és korábbi verziói.

A gyártó a hibát az 5.3.0.2-es, 5.2.0.4-es és 5.1.0.7-es verziókban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-01

Sérülékenység Mitsubishi Electric rendszerekben

A Mitsubishi Electric egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi, GOT termékeiket érinti:

- GOT2000 sorozat
  - GT27 modell minden verziója;
  - GT25 modell minden verziója;
  - GT21 modell minden verziója;
   - GT2107-WTBD modell minden verziója;
   - GT2107-WTSD modell minden verziója;
- GOT SIMPLE sorozat
  - GS21 model.
   - GS2110-WTBD-N modell minden verziója;
   - GS2107-WTBD-N modell minden verziója.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-112-02

Sérülékenységek Horner Automation Cscape szoftverekben

Sharon Brizinov, a Claroty munkatársa két sérülékenységet talált a Horner Automation Cscape nevű, vezérlő rendszerek fejlesztésére használt szoftverének minden, 9.90 SP4-nél korábbi verziójában.

A gyártó a hibákat a Cscape legújabb verziójában javította. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-112-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.