Schneider Electric ProSoft Configurator sérülékenység

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet talált a Schneider Electric ProSoft Configurator PMEPXM0100 (H) moduljaiban a v1.002 és korábbi verziók használta esetén.

A gyártó a hibát a v1.003 verzióban javította. A sérülékenységgel kapcsolatban további információk a Schneider Electric publikációjában találhatóak.

Sérülékenységek Moxa OnCell eszközökben

Alexander Zaytsev, a Kaspersky Lab munkatársa 7 sérülékenységet fedezett fel a Moxa alábbi termékeiben:

- OnCell G3470A-LTE sorozatú eszközök 1.6-os és korábbi firmware-verziói;
- OnCell G3100-HSPA sorozatú eszközök 1.7-es és korábbi firmware-verziói.

A gyártó a hibákat a legújabb firmware-verziókban javította. A sérülékenységek részletei elérhetőek a Moxa weboldalán.

Siemens ipari tűzfalak sérülékenységei

Melih Berk Ekşioğlu három sérülékenységről közölt információkat a Siemens-szel, amik a SCALANCE S-600 ipari tűzfalcsalád alábbi tagjait érintik:

- SCALANCE S602 minden, v3.0 és újabb verziója;
- SCALANCE S612 minden, v3.0 és újabb verziója;
- SCALANCE S623 minden, v3.0 és újabb verziója;
- SCALANCE S627-2M minden, v3.0 és újabb verziója.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését illetve újabb termékre (SCALANCE SC-600 Industrial Security Appliance) történő váltást javasolja. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben olvashatóak.

Sérülékenység Siemens OZW webszerverekben

Maxim Rupp egy sérülékenységet fedezett fel a Siemens alábbi termékeiben:

- OZW672 webszerverek 10.0-nál korábbi verziói;
- OZW772 webszerverek 10.0-nál korábbi verziói.

A gyártó a hibát a 10.0 verzióban javította. A sérülékenységről további részleteket a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SIPORT MP sérülékenység

A Siemens egy sérülékenységről közölt információkat, ami a SIPORT MP 3.1.4-esnél korábbi verzióit érinti.

A gyártó kiadta a javítást a hibára. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenység Siemens SCALANCE X hálózati eszközökben

A Siemens egy sérülékenységgel kapcsolat adott át információkat a DHS CISA-nak, ami az alábbi, ipari környezetekbe tervezett hálózati eszközeit érinti:

- SCALANCE X-200 switch család (a SIPLUS NET változatok is érintettek) minden, 5.2.4-nél korábbi firmware-verziója;
- SCALANCE X-200IRT switch család (a SIPLUS NET változatok is érintettek) minden verziója;
- SCALANCE switch család ( az X408-as és SIPLUS NET változatok is érintettek) minden, 4.1.3-nál korábbi firmware-verziója.

A gyártó a hibát a legújabb, elérhető firmware-verzióban javította. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet elérni.

Siemens SIMATIC rendszerek sérülékenysége

Nicholas Miles, a Tenable munkatársa egy sérülékenységet talált a SIMATIC szoftvercsalád alábbi tagjaiban:

- OpenPCS 7 v8.1 minden verziója;
- OpenPCS 7 v8.2 minden verziója;
- OpenPCS 7 v9.0 minden verziója;
- SIMATIC BATCH v8.1 minden verziója;
- SIMATIC BATCH v8.2 minden verziója;
- SIMATIC BATCH v9.0 minden verziója;
- SIMATIC NET PC Software minden verziója;
- SIMATIC PCS 7 v8.1 minden verziója;
- SIMATIC PCS 7 v8.2 minden verziója;
- SIMATIC PCS 7 v9.0 minden verziója;
- SIMATIC Route Control v8.1 minden verziója;
- SIMATIC Route Control v8.2 minden verziója;
- SIMATIC Route Control v9.0 minden verziója;
- SIMATIC WinCC (TIA Portal) v13 minden, v13 SP2-nél korábbi verziója;
- SIMATIC WinCC (TIA Portal) v14.0.1 minden verziója;
- SIMATIC WinCC (TIA Portal) v15.1 minden verziója;
- SIMATIC WinCC (TIA Portal) v16 minden verziója;
- SIMATIC WinCC v7.3 minden verziója;
- SIMATIC WinCC v7.4 minden verziója;
- SIMATIC WinCC v7.5 minden, v7.5.1 Upd1-nél korábbi verziója.

A gyártó a WinCC (TIA Portal) v13-hoz és a WinCC v7.5-höz kiadta a hibát javító új verziókat, a többi érintett verzió esetén pedig kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatban részleteket a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SIMATIC S7 sérülékenység

A kínai ICS CERT (China Industrial Control Systems Cyber Emergency Response Team - CIC) egy sérülékenységet jelentett a Siemens-nek, ami az alábbi, SIMATIC S7 eszközöket érinti:

- SIMATIC S7-1200 CPU család (beleértve a SIPLUS változatokat is) minden, v4.1-nél korábbi verziója;
- SIMATIC S7-300 PN/DP CPU család (beleértve az ET200-as CPU-kat és a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 PN/DP v6 és korábbi CPU család (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 PN/DP v7 CPU család (beleértve a SIPLUS változatokat is) minden verziója.

A gyártó a SIMATIC S7-1200 CPU családhoz kiadta a hibát javító verziót, a többi érintett berendezést használó ügyfelüknek kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Sérülékenység a Siemens PROFINET-IO Stack-ben

Yuval Ardon és Matan Dobrushin, az OTORIO munkatársai egy sérülékenységet találtak a Siemens PROFINET-IO Stack-ben, amit az alábbi Siemens termékekben használnak:

- PROFINET IO fejlesztői/tesztelő csomagok:
- DK Standard Ethernet Controller minden verziója;
- EK-ERTEC 200 minden, 4.5-nél korábbi verziója;
- EK-ERTEC 200P minden, 4.6-nál korábbi verziója;
- PROFINET Driver for Controller minden, 2.1-nél korábbi verziója;
- RUGGEDCOM RM1224 minden, 4.3-nál korábbi verziója;
- SCALANCE M-800/S615 minden, 4.3-nál korábbi verziója;
- SCALANCE W700 IEEE 802.11n minden, 6.0.1-nél korábbi verziója;
- SCALANCE X-200 switch család (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SCALANCE X-200IRT switch család (beleértve a SIPLUS NET variánsokat is) minden, 5.3-nál korábbi verziója;
- SCALANCE X-300 switch család (beleértve az X408-as és a SIPLUS NET variánsokat is) minden verziója;
- SCALANCE XB-200, XC-200, XP-200, XF-200BA és XR-300WG minden, 3.0-nál korábbi verziója;
- SCALANCE XM-400 switch család minden, 6.0-nál korábbi verziója;
- SCALANCE XR-500 switch család minden, 6.0-nál korábbi verziója;
- SIMATIC CP 1616 és CP 1604 minden, 2.8-nál korábbi verziója;
- SIMATIC CP 343-1 (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 343-1 Advanced (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 343-1 ERPC minden verziója;
- SIMATIC CP 343-1 LEAN (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 443-1 (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 443-1 Advanced (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC CP 443-1 OPC UA minden verziója;
- SIMATIC ET200AL IM 157-1 PN minden verziója;
- SIMATIC ET200M IM153-4 PN IO HF (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200M IM153-4 PN IO ST (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200MP IM155-5 PN HF (beleértve a SIPLUS NET variánsokat is) minden, 4.2.0-nál korábbi verziója;
- SIMATIC ET200MP IM155-5 PN ST (beleértve a SIPLUS NET variánsokat is) minden, 4.1.0-nál korábbi verziója;
- SIMATIC ET200S (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200SP IM155-6 PN Basic (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC ET200SP IM155-6 PN HF (beleértve a SIPLUS NET variánsokat is) minden, 3.3.1-nél korábbi verziója;
- SIMATIC ET200SP IM155-6 PN ST (beleértve a SIPLUS NET variánsokat is) minden, 4.1.0-nál korábbi verziója;
- SIMATIC ET200ecoPN (kivéve a 6ES7148-6JD00-0AB0 és 6ES7146-6FF00-0AB0 sorozatszámú modelleket) minden verziója;
- SIMATIC ET200pro, IM 154-3 PN HF minden verziója;
- SIMATIC ET200pro, IM 154-4 PN HF minden verziója;
- SIMATIC IPC Support, Package for VxWorks minden verziója;
- SIMATIC MV400 család minden verziója;
- SIMATIC PN/PN Coupler 6ES7158-3AD01-0XA0 (beleértve a SIPLUS NET variánsokat is) minden verziója;
- SIMATIC RF180C minden verziója;
- SIMATIC RF182C minden verziója;
- SIMATIC RF600 minden, 3-asnál korábbi verziója;
- SINAMICS DCP minden, 1.3-nál korábbi verziója.

A hibával kapcsolatban a gyártó számos érintett termékhez kiadta a javítást tartalmazó újabb verziókat, a többi esetében pedig kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT lehet elérni.

Sérülékenységek Siemens SIMATIC kommunikáció processzorokban

A Siemens publikációja szerint két sérülékenységet találtak a SIMATIC CP 1543-1 típusú (beleértve a SIPLUS NET variánsokat is) kommunikációs processzorok 2.0-nél újabb és 2.2-nél régebbi verzióiban.

A gyártó a hibákat a 2.2-es verzióban javította. A sérülékenységekkel kapcsolatban részleteket a Siemens ProductCERT és az ICS-CERT lehet találni.

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.

Azok számára, akik olvassák egy ideje a blogot, nem titok, hogy sok szempontból előremutatónak tartom, ahogy az USA-ban a kritikus infrastruktúrák információ és IT biztonságával foglalkoznak.

Május közepén Texas államban két törvényt is hoztak, amik a villamosenergia-hálózat kiberbiztonságára vonatkozóan tartalmaznak előírásokat. A törvények alapján a Texas-i kormányzó megbízásából felállítanak egy testületet, aminek az alábbi feladatokat kell kidolgozniuk:

- Képzési programok és marketing anyagok a villamosenergia-hálózatban dolgozók információbiztonsági képzéséhez;
- Kiberbiztonsági program kidolgozása a villamosenergia-hálózat számára;
- Fel kell készülniük a villamosenergia-hálózatot érintő incidensekre;
- Az állami vészhelyzeti tervek frissítése a villamosenergia-hálózat kiberbiztonsági fenyegetéseivel.

A hatályba helyezett jogszabályok itt érhetőek el:

https://capitol.texas.gov/tlodocs/86R/billtext/html/SB00475S.htm
https://capitol.texas.gov/tlodocs/86R/billtext/html/SB00936I.htm

Az elmúlt kb. egy hétben számos egészen érdekes cikket olvastam ICS biztonság témában és sajnos nincs annyi időm, hogy mindegyikről írjak egy-egy teljes posztot, szóval most jött el a kiváló alkalom arra, hogy elindítsam az ICS biztonsági sajtófigyelő rovatot. Íme az első rész:

Hálózatok kompromittálása Philips Hue okos izzókon keresztül

A Check Point blogján egy egészen érdekes, bár kevésbé klasszikus ICS mint inkább okosotthonhoz kapcsolódó (ami azért valahol mégis csak digitális folyamatvezérlés) cikk jelent meg arról, hogyan lehet a Philips által gyártott okos izzókon keresztül kompromittálni az izzó által kommunikációra használt hálózatot. A Check Point PoC tesztjében a ZigBee protokoll egy sérülékenysége is szerepet kapott.

Ransomware támadás értel a Toll ausztrál szállítmányozási cég rendszereit

A BitDefender Hot For Security oldalán olvasható egy cikk a Toll nevű ausztrál szállítmányozási cég elleni ransomware-támadásról. A cikk ugyan nem említi, hogy ICS rendszerek érintettek lennének, de ha emlékszünk még a 2019. tavaszán történt Norsk Hydro-incidensre és az eset automatizált raktárkezelésre gyakorolt hatásáról készült videóra, akkor nem lehet kizárni, hogy a Toll több, mint ezer érintett szervere közül lehetnek olyanok, amik automatizált folyamatok irányításáért felelősek.

Az IBM X-Force tanulmánya szerint 2000%-kal nőtt az OT rendszerek elleni támadások száma 2019-ben

Az IBM-en belül működő X-Force biztonsági kutatócsoport idén is megjelentette az elmúlt év kiberbiztonsági fenyegetéseit összefoglaló jelentését (a 49 oldalas publikáció regisztráció után tölthető le), amely szerint 2019-ben több, mint 2000%-kal, vagyis hússzorosára nőtt az OT rendszerek elleni kibertámadások száma. A kutatók kiemelték, hogy a legtöbb támadás mögött, amit észleltek, feltehetően a Xenotime és a Magnallium/APT33 néven ismert APT-csoportok állhatnak. Az IBM X-Force munkatársai 2020-ban az OT rendszerek elleni támadások számának további növekedésére számítanak.

Az ipari hálózatok a legújabb geopolitikai csataterek

A 2020-as RSA konferencia felvezetéseként jelent meg egy cikk Galina Antova, a Claroty üzletfejlesztési vezetőjétől a SecurityWeek oldalán, amiben arról ír, hogyan váltak a kritikus infrastruktúrák ipari hálózatai geopolitikai csatatérré. A 2015-ös és 2016-os ukrán villamosenergia-rendszer elleni támadások, majd a WannaCry és a NotPetya incidenseken mutatja be az újfajta hadviselés fejlődését és vázolja, szerinte mi várható a közeli jövőben.

Sérülékenység AutomationDirect rendszerekben

Joel Langill, az Amentum Mission Engineering & Resilience munkatársa egy kritikus besorolású sérülékenységet talált az AutomationDirect C-More Touch Panels EA9 sorozatú eszközeinek 6.53-nál korábbi firmware-verzióiban.

A gyártó a hibát a 6.53-as firmware-verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-035-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 elmúlt években a zsaroló vírusok (ransomware-ek) váltak az egyik leggyakoribb kiberbiztonsági fenyegetéssé, azonban az ICS rendszereket jellemzően nem szándékosan, inkább csak járulékos veszteségként érték ransomware-támadások.

A Dragos és a Sentinel One cikkei alapján most ez is megváltozni látszik. A két biztonsági cég elemzői egyre több bizonyítékot találtak arra, hogy a Snake vagy ENAKS (ami ugye a snake visszafelé olvasva) ransomware-t alkotói kifejezetten ICS rendszerek elleni támadásokra tervezték.

A már megszokottnak nevezhető ransomware-támadásokkal ellentétben a Snake/ENAKS ransomware nem csak egyszerűen titkosítja a megtámadott eszközökön található fájlokat, képes 64 különböző szoftver folyamatait leállítani. Az érintett 64 folyamat között számos olyan található, amelyek az érintett ICS rendszerekben a fizikai folyamatok vezérléséért felelős.

A Dragos elemzése szerint a Snake/ENAKS nem az első, hanem a Megacortex nevű, 2019. tavaszán feltűnt ransomware után a második kártevő, ami ilyen módon működik és akár még a Snake/ENAKS elődje is lehet.

A kutatók egyelőre sötétben tapogatóznak azzal kapcsolatban, hogy kik állhatnak a Snake/ENAKS ransomware mögött, de már felmerültek olyan feltételezések, hogy nem állami hátterű APT csoportok, hanem kiberbűnözők közé tartozhatnak a zsarolóvírus alkotói. Ez pedig egy meglehetősen új és egyben aggasztó fejlemény, mert ha valóban bűnözői csoportok kezdik célba venni az ICS rendszereket, akkor a korábbinál nagyságrendekkel nagyobb fenyegetésekkel kell szembenézniük az ICS eszközök és rendszerek üzemeltetőinek és a biztonságukért felelős szakembereknek.

Egy viszonylag régi, de annál alaposabb cikket találtam a 2017-es, Szaúd-arábiai olajfinomító elleni kibertámadásról, ami később Triton/TriSIS néven vált ismertté.

A cikk alaposan bemutatja a megtámadott szaúdi olajcéget, a támadással gyanúsított iráni APT csoportot, a később felfedezett orosz kapcsolatot és a Dragos által feltárt, más célpontok ellen indított Triton/TriSIS támadásokat is.

Bár a cikkben sok új információt nem lehet olvasni, én korábban még nem találkoztam hasonlóan alapos írással, ami ezt az incidenst foglalná össze, ezért mindenképp hasznosnak tartom és érdemesnek egy olvasásra.

Sérülékenységek Honeywell MAXPRO rendszerekben

Joachim Kerschbaumer két sérülékenységet talált a Honeywell alábbi, videómenedzsmentre használt rendszereiben:

- HNMSWVMS VMS560 Build 595 T2-Patch-nél korábbi verziói;
- HNMSWVMSLT VMS560 Build 595 T2-Patch-nél korábbi verziói;
- MAXPRO NVR XE NVR 5.6 Build 595 T2-Patch-nél korábbi verziói;
- MAXPRO NVR SE NVR 5.6 Build 595 T2-Patch-nél korábbi verziói;
- MAXPRO NVR PE NVR 5.6 Build 595 T2-Patch-nél korábbi verziói;
- MPNVRSWXX NVR 5.6 Build 595 T2-Patch-nél korábbi verziói.

A gyártó a hibákat a legújabb elérhető firmware-verzióban javította. A sérülékenységek részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-021-01

Sérülékenységek GE orvostechnikai eszközökben

Elad Luz, a CyberMDX munkatársa 6 sérülékenységről közölt információkat a DHS CISA-val, amik a GE alábbi orvostechnikai rendszereit érintik:

- ApexPro Telemetry Server 4.2 és korábbi verziói;
- CARESCAPE Telemetry Server 4.2 és korábbi verziói;
- Clinical Information Center (CIC) 4.X és 5.X verziói;
- CARESCAPE Telemetry Server 4.3-as verziója (a CVE-2020-6962 és CVE-2020-6961 sérülékenységek érintik);
- CARESCAPE Central Station (CSCS) 1.X verziói;
- CARESCAPE Central Station (CSCS) 2.X verziói (a CVE-2020-6962 és CVE-2020-6964 sérülékenységek érintik);
- B450 2.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B650 1.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B650 2.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B850 1.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik);
- B850 2.X verziói (a CVE-2020-6962 és CVE-2020-6965 sérülékenységek érintik).

A sérülékenységekkel kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja, a hibákat javító újabb verziókról jelenleg nincs elérhető információ. A sérülékenységekről bővebb információk az ICS-CERT bejelentésében találhatóak: https://www.us-cert.gov/ics/advisories/icsma-20-023-01

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 IT kontra OT téma a 2018 elején megrendezett S4 konferencia óta az egyik népszerű vitája az ICS biztonsági közösségnek, én is többször írtam erről a blogon és a visszajelzések szerint ez az egyik leginkább érdekes téma.

Még novemberben Joe Slowik, a Dragos egyik veterán elemzője (aki, mint oly sokan az amerikai ICS bizotnsági közösségből, hosszabb időt töltött el a fegyveres erők - Joe esetében az amerikai haditengerészet - kötelékében) írt egy hosszabb blogbejegyzést a témában.

Ebben az írásban Joe (akivel október végén volt lehetőségem röviden személyesen is beszélgetni) a tőle megszokott stílusban, az elmúlt évek fontosabb ICS biztonsági incidensein (Industroyer/CrashOverride, Triton/TRISIS és a 2015-ös ukrán incidens) keresztül mutatja be, hogy szerinte miért rossz megközelítés, ha valaki választani akar az IT és az OT között, amikor az ICS biztonsági kihívások kezelésének módját keresi.

Kíváncsi vagyok, a hazai színtéren ki és mikor fog végre előrelépni és a hazai szakmai körök elé tárni a véleményét a témában? Én ugyan szívesen leírom a véleményemet erről (is), de úgy, hogy alig érkezik visszajelzés, vitáról nehéz beszélni. Pedig a vita jó (lenne), mert új gondolatokat, ötleteket szülhet, amiből mind profitálhatnánk.

Sérülékenység GE PACSystems RX3i termékekben

Jin Kyung Lee és Yeop Chang of NSR (National Security Research Institute) munkatársai egy sérülékenységet találtak a GE PACSystem alábbi termékeiben és verzióiban:

- CPE100: minden, R9.85-ösnél korábbi verzió;
- CPE115: minden, R9.85-ösnél korábbi verzió;
- CPE302: minden, R9.90-nél korábbi verzió;
- CPE305: minden, R9.90-nél korábbi verzió;
- CPE310: minden, R9.90-nél korábbi verzió;
- CRU320: (a termék elérte életciklusa végét, a gyártó javasolja a CPE330-asra történő váltást);
- CPE330: minden, R9.90-nél korábbi verzió;
- CPE400: minden, R9.90-nél korábbi verzió;
- CPL410: minden, R9.90-nél korábbi verzió.

A hibával kapcsolatban a gyártó a legújabb elérhető firmware-verziókra történő frissítést javasolja. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-014-01

Siemens SINEMA szerverek sérülékenysége

Antonin Rahon, az Agilicom munkatársa egy sérülékenységet fedezett fel a Siemens SINEMA Server nevű hálózatmenedzsment megoldásának minden, 14.0 SP2 Update 1-nél korábbi verziójában.

A gyártó a hibát javító új verziót már elérhetővé tette. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenység Siemens SCALANCE X hálózati eszközökben

Maxim Rupp egy sérülékenységet azonosított a Siemens SCALANCE X ipari switcheinek alábbi változataiban:

- SCALANCE X-200RNA termékcsalád minden verziója;
- SCALANCE X-300 termékcsalád (beleértve a SIPLUS NET változatokat is) minden, 4.1.3-nál korábbi verziója;
- SCALANCE X-408 minden, 4.1.3-nál korábbi verziója.

A gyártó a hibával kapcsolatban a SCALANCE X-200RNA termékcsalád tagjait használó ügyfeleinek kockázatcsökkentő intézkedések alkalmazását, az X-300-as és X-408-as termékcsaládok tagjaihoz pedig firmware-frissítés telepítését javasolja. A sérülékenységről bővebb információk a Siemens ProductCERT és az ICS-CERT weboldalain érhetőek el.

Siemens SINAMICS PERFECT HARMONY sérülékenység

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi feszültségszabályozó termékeiket érinti:

A SINAMICS PERFECT HARMONY GH180 típusú berendezések MLFB 6SR32-vel, MLFB 6SR4-gyel és MLFB 6SR5-tel kezdődő sorozatainak (utóbbinak az A30-as opcióval és 12 colos vagy nagyobb HMI-vel szerelt változatai) minden verziója, valamint az MLFB 6SR325-tel kezdődő sorozatának nagy rendelkezésre állást (HA) biztosító változatainak minden verziója.

A gyártó a hibához kapcsolódóan kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens TIA Portal sérülékenység

William Knowles, az Applied Risk munkatársa egy sérülékenységet talált a Siemens TIA Portal alábbi verzióiban:

- TIA Portal v14 minden verziója;
- TIA Portal v15 minden, v15.1 Upd 4-nél korábbi verziója;
- TIA Portal v16 minden verziója.

A gyártó a hibát a V15.1 Upd 4 verzióban javította és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiből lehet tájékozódni.

OSISoft PI Vision sérülékenységek

Az OSISoft négy sérülékenységet fedezett fel és jelentett a DHS CISA-nak, amik az alábbi termékeiket érintik:

- PI Vision 2019-nél korábbi összes verziója;
- PI Vision 2017 R2 és PI Vision 2017 R2 SP1;

A gyártó a hibákat a PI Vision 2019-es verziójában javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-20-014-06

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

Younes Dragoni, a Nozomi Networks munkatársa három sérülékenységet azonosított a Schneider Electric alábbi termékeiben:

- Modicon M580 minden, v2.80-nál korábbi firmware-verzió;
- Modicon M340 minden, v3.01-nél korábbi firmware-verzió;
- Modicon Premium minden, v3.20-nál korábbi firmware-verzió;
- Modicon Quantum minden, v3.60-nál korábbi firmware-verzió; (a háromból két sérülékenység csak a v3.52-nél korábbi verziókat érintik).

A gyártó a hibákat javító firmware-verziókat már elérhetővé tette a weboldalán. A sérülékenységekről részletek az ICS-CERT bejelentésében találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-016-01

Schneider Electric MSX Configurator sérülékenység

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet jelentett a Schneider Electric-nek, ami az MSX Configurator V1.0.8.1-nél korábbi verzióit érinti.

A gyártó a hibát az MSX Configurator V1.0.8.1-es verziójában javította. A sérülékenységről bővebb információkat a Schneider Electric publikációja tartalmaz.

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.

Január 6-án Joe Weiss az Unfettered blogon egy hosszabb posztban foglalta össze az ICS biztonság elmúlt két évtizedével kapcsolatos gondolatait. Ennek olvasása közben merült fel bennem a gondolat, hogy melyik megközelítésnek milyen előnyei és hátrányai lehet az ICS biztonság fejlesztése során?

Nem titok (hiszen én is többször írtam erről), hogy (főként az USA-ba) meglehetősen heves vita zajlik arról, hogy az ICS biztonság fejlesztése során hova kell, hova célszerű helyezni a hangsúlyt. Vannak, akik az OT hálózatok és rendszerek biztonságát tekintik elsődlegesen védendőnek és vannak mások (elsősorban, de nem kizárólag Joe), akik szerint az OT hálózatok mellett (időként helyett) a hangsúlyt főként az automatizálási eszközök biztonságára kellene helyezni és erősen helytelenítik, hogy ebben a kérdésben az elmúlt két évtizedben nem igazán történt előre lépés.

Az én személyes véleményem a témában az, hogy az OT hálózatok és eszközök biztonságának javítására több okból is célszerű jelentős erőforrásokat fordítani. Egyrészt ezek a rendszerek/hálózatok sokkal jobban hasonlítanak a hagyományos, nagyvállalati IT rendszerekre, így (bizonyos egyedi jellemzőket szem előtt tartva) sok IT biztonsági megoldás kisebb-nagyobb változtatásokkal használható az OT rendszerekben és hálózatokban is. Ezzel szemben az automatizálási eszközök, bár sok esetben az IT-ban megszokott komponensekhez többé vagy kevésbé hasonló komponensekből épülnek fel, mégsem egyszerű a hagyományos IT biztonsági megoldások implementálása (pl. a szűkre szabott erőforrások nem teszik lehetővé végpontvédelmi megoldás telepítését, stb.).

A másik ok pedig az, hogy ha az eddig nyilvánosságra került incidenseket vizsgáljuk, akkor elég jól lehet látni, hogy a legnagyobb kockázatokat jelentő, szándékos támadások a legtöbb esetben az Internetről érkezve, az IT és OT rendszeken keresztül jutott el az automatizálási eszközök (level1/level0 eszközök) szintjére és okozott kárt ezekben az eszközökben vagy az általuk vezérelt folyamatokban. Még a Stuxnet is, ami mind a mai napig az egyik legkinomultabb ICS rendszerek elleni támadásként van nyilvántartva, az OT hálózat irányából jutott el a fizikai folyamatokat közvetlenül irányító berendezésekig.

Ezzel nyilván nem azt mondom, hogy Joe Weiss téved, sőt. Biztos, hogy Joe-nak is igaza van és a level1/level0 eszközök biztonságán is dolgozni kell, de azt is gondolom, hogy ez egy jóval lassabb folyamat lesz, időnk pedig nem igazán van, tehát mindent meg kell tennünk a ma ismert civilizációnk alapjait képező rendszerek megvédése érdekében. Ezen az úton szerintem a leggyorsabban a legnagyobb javulást az ipari szervezetek IT és OT rendszereinek és hálózatainak védelmét fokozva érhetjük el, közben pedig az IT, IT biztonsági és OT szakemberek közötti együttműködés javításával meg kell teremtenünk a level1/level0 eszközök biztonsági szintjének javításához a lehetőségeket.

Ami engem igazán érdekelne, hogy mi a véleménye erről a témáról a hazai szakmának?