Advantech WebAccess/SCADA sérülékenységek

Mat Powell, Natnael Samson és EljahLG hat különböző sérülékenységet azonosítottak az Advantech WebAccess/SCADA 8.3.5-ös és korábbi verzióiban. A gyártó a hibákat a 8.4.1-es verzióban javította. A sérülékenységekről további részleteket az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-178-05

Sérülékenység SICK PLC-kben

Tri Quach, az Amazon Customer Fulfillment Technology Security csoportjának munkatársa egy sérülékenységet talált a SICK MSC800-as típusú PLC-inek 4.0-nál korábbi firmware-verzióiban. A gyártó a hibát a legújabb firmware-verzióban javította. A sérülékenységről bővebb információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-178-04

ABB HMI-ok sérülékenysége

Az ABB egy sérülékenységet jelentett az NCCIC-nek, ami az alábbi HMI-ait érinti:

- CP635 termékcsalád:
  - CP620, rendelési kód: 1SAP520100R0001, v1.76 és korábbi verziók;
  - CP620, rendelési kód: 1SAP520100R4001, v1.76 és korábbi verziók;
  - CP620-WEB, rendelési kód: 1SAP520200R0001, v1.76 és korábbi verziók;
  - CP630, rendelési kód: 1SAP530100R0001, v1.76 és korábbi verziók;
  - CP630-WEB, rendelési kód: 1SAP530200R0001, v1.76 és korábbi verziók;
  - CP635, rendelési kód: 1SAP535100R0001, v1.76 és korábbi verziók;
  - CP635, rendelési kód: 1SAP535100R5001, v1.76 és korábbi verziók;
  - CP635-B, rendelési kód: 1SAP535100R2001, v1.76 és korábbi verziók;
  - CP635-WEB, rendelési kód: 1SAP535200R0001, v1.76 és korábbi verziók.

- CP651 termékcsalád:
  - CP651, rendelési kód: 1SAP551100R0001, v1.76 és korábbi verziók;
  - CP651-WEB, rendelési kód: 1SAP551200R0001, v1.76 és korábbi verziók;
  - CP661, rendelési kód: 1SAP561100R0001, v1.76 és korábbi verziók;
  - CP661-WEB, rendelési kód: 1SAP561200R0001, v1.76 és korábbi verziók;
  - CP665, rendelési kód: 1SAP565100R0001, v1.76 és korábbi verziók;
  - CP665-WEB, rendelési kód: 1SAP565200R0001, v1.76 és korábbi verziók;
  - CP676, rendelési kód: 1SAP576100R0001, v1.76 és korábbi verziók;
  - CP676-WEB, rendelési kód: 1SAP576200R0001, v1.76 és korábbi verziók.

A gyártó a hibát a CP600 vezérlőpanelekhez kiadott v2.8.0.424-es verzióban javította. A sérülékenységről további információk az ICS-CERT bejelentéseiben érhetőek el: https://www.us-cert.gov/ics/advisories/icsa-19-178-03 és https://www.us-cert.gov/ics/advisories/icsa-19-178-02

Sérülékenységek ABB HMI programozási eszközökben

A Xen1thLabs, egy DarkMatter-höz tartozó vállalkozás hét sérülékenységet azonosított az ABB PB610 Panel Builder 600 rendszerének 1.91-es verziójában. A gyártó a hibákat a PB610 Panel Builder 600 v2.8.0.424-es verziójában javította. A sérülékenységekről részletesebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-178-01

Sérülékenység Medtronic inzulin pumpákban

Nathanael Paul, Jay Radcliffe és Barnaby Jack korábbi munkáira építve Billy Rios, Jonathan Butts és Jesse Young egy eddig nem ismert hibát találtak a Medtronic alábbi inzulin pumpáiban:

- MiniMed 508 minden verziója;
- MiniMed Paradigm 511 minden verziója;
- MiniMed Paradigm 512/712 minden verziója;
- MiniMed Paradigm 712E minden verziója;
- MiniMed Paradigm 515/715 minden verziója;
- MiniMed Paradigm 522/722 minden verziója;
- MiniMed Paradigm 522K/722K minden verziója;
- MiniMed Paradigm 523/723 minden verziója;
- MiniMed Paradigm 523K/723K minden verziója;
- MiniMed Paradigm Veo 554/754 2.6A és korábbi verziók;
- MiniMed Paradigm Veo 554CM és 754CM modellek 2.7A és korábbi szoftver verziói.

A gyártó a hibával kapcsolatban kockázatcsökkentõ intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatban bővebb információt az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsma-19-178-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.

Az okosmérés az elmúlt évek során az egyik olyan téma az ICS világában, amiről egyre többen, egyre többször beszélnek. Ennek több oka is van, a legfontosabb (a közüzemi szolgáltatások végfelhasználói számára) az, hogy (elvileg) megtakarításokat érhetnek el pl. a villamosenergia-felhasználásuk optimalizálásával.

Ehhez olyan mérőórák telepítése szükséges a villamosenergia-rendszerbe, amik képesek különböző kommunikációs csatornákat (jellemzően valamilyen vezeték nélküli kommunikációs formát, többnyire LTE hálózatokat) használva a lehető legtöbb adatot tudják átadni a szolgáltatóknak a fogyasztók szokásairól. Biztonsági szempontból a problémát éppen a publikus kommunikációs csatornák használata okozza, mert ez azt is jelenti, hogy gyakorlatilag bárki képes lehet lehallgatni az okos mérőórák és a mérési központok közötti kommunikációt illetve a vezeték nélküli kommunikációs lehetőséget (és egy vagy több sérülékenységet) kihasználva hozzáférést szerezhet a mérőórához (Marc Elsberg Blackout - Holnap már túl késő című könyve pont egy ilyen támadásból kialakuló fiktív krízisről szól). Ennek annál is nagyobb az esélye, mert az okosmérők végeredményben nem igazán különböznek egy mobil hálózatokon kommunikáló számítógéptől, ami azt is jelenti, hogy a klasszikus IT biztonsági sérülékenységek nem számítanak rendkívülinek.

Az okos mérőórák még nagyon újnak számítanak (itthon is csak néhány éve kezdtek foglalkozni a témával a különböző közmű szolgáltatók) és meglepő módon a "hagyományos" ICS vagy például az orvostechnikai rendszerekkel szemben az okos mérőórák biztonságával kapcsolatban komoly kutatásokat folytatnak Európában, az USA-ban és Magyarországon is különböző szakértők és minősítő laborok, ami mindenképp egy örvendetes fejlemény.

Sérülékenységek Phoenix Contact rendszerekben

A 9sg biztonsági kutató csapat három sérülékenységről publikált részleteket a ZDI-vel együttműködésben, amik a Phoenix Contact Automation Worx szoftvercsomagjának alábbi rendszereit érintik:

- PC Worx 1.86-os és korábbi verziói;
- PC Worx Express 1.86-os és korábbi verziói;
- Config+ 1.86-os és korábbi verziói.

A gyártó jelenleg is dolgozik a hibák javításán, azok kiadásáig kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről további részleteket az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-171-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.

Az elmúlt években többször jelentek meg hírek arról, hogy az orosz (jellemzően különböző titkosszolgálatokhoz tartozónak feltételezett) támadók az USA villamosenergia-rendszere elleni támadásokat hajtottak/hajtanak végre. Ezek közül némelyikről én is írtam a blogon.

A New York Times múlt héten megjelent cikke szerint jelentős változások történtek az USA-ban ezzel a témával kapcsolatban, a US Cyber Command parancsnoka felhatalmazást kapott különböző szoftverkódok orosz villamosenergia-rendszerben történő elhelyezésére, mindezt az esetenkénti előzetes elnöki jóváhagyás nélkül!

Maga a cikk elég részletesen tárgyalja az új fejleményeket, én most inkább arra térnék ki, hogy milyen következményei lehetnek annak, ha az USA az elmúlt években az orosz államhoz kötött támadások után felveszi a kesztyűt és hasonló műveletekbe kezd.

Nyilvánvalóan a kibertámadások jellege miatt az USA egyértelmű felelősségét ugyanúgy nehéz illetve lehetetlen lesz megállapítani, mint az oroszok, irániak vagy egyéb támadók felelősségét az amerikai kritikus infrastruktúrák elleni támadások során - részben ez teszi olyan hatékonnyá és népszerűvé az ötödik hadszíntéren (angol terominológiával ötödik domainben) végzett műveleteket.

Ugyanakkor nagyon komoly következményei lehetnek és nagyon rossz üzenete van annak, ha a világ vezető hatalmai békeidőben gyakorlatilag katonai műveleteket hajtanak végre más nemzetek civil infrastruktúráit irányító rendszerek ellen. Mostanáig azok az ICS rendszerek elleni támadások, amikről publikusan elérhető információnk vannak, nem szedtek emberi áldozatokat (már amennyire tudhatjuk), de ha az ötödik domain-ben eindul egy, a jelenleginél intenzívebb adok-kapok a nagyhatalmak között, valószínűleg nem kell sokáig várni arra, hogy sérültjei vagy akár halottjai legyenek az ilyen incidenseknek. Gondoljunk bele abba, hogy vajon hány olyan kórház van akár az USA-ban, akár Oroszországban (de kérdezhetném Magyarországot is), ahol egy nagyobb áramkimaradás esetén (elvégre a villamosenergia-rendszerek elleni kibertámadások végcélja mi más lehet?) a generátorok tesztelésére nincs pénz, ember vagy éppen csak egy adott menedzser fontossági listáján ez a tétel alacsonyabbra került?

Annyit minden esetre biztosnak látok, hogy az ilyen fejlemények nem a helyes irányba viszik az ICS rendszerek biztonságának kérdését. Ezek fényében egyre fontosabbnak látom, hogy a hazai döntéshozók minél előbb érdemben foglalkozzanak a témával.

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

Christopher Wade, a Pen Test Partners munkatársa egy sérülékenységet jelentett a Siemens-nak, ami a SCALANCE X termékcsalád alábbi tagjait érinti:

- SCALANCE X-200 v5.2.4 verziónál korábbi összes verziója;
- SCALANCE X-200IRT minden verziója;
- SCALANCE X-300 minden verziója;
- SCALANCE X-414-3E minden verziója.

A hibát a gyártó a SCALANCE X-200-as eszközök esetében a v5.2.4 verzióban javította. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet találni.

Sérülékenységek Siemens LOGO!8 eszközökben

Thomas Meesters, Christian Siemers és Irakli Edjibia két sérülékenységet fedeztek fel a Siemens LOGO!8 eszközeinek alábbi verzióiban:

- SIEMENS LOGO!8: 6ED1052-xyyxx-0BA8 FS:01-től FS:06-ig illetve a v1.80.xx és v1.81.xx firmware-verziók;
- SIEMENS LOGO!8: 6ED1052-xyy08-0BA0 FS:01 és a v1.82.02-nél korábbi firmware-verziók.

A hibákat a gyártó a v1.82.02-es firmware-verzióban javította. A sérülékenységekkel kapcsolatban részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenységek a SIMATIC Ident termékcsaládban

A Siemens két sérülékenységet azonosított az Ident termékcsalád alábbi tagjaiban:

- MV420 minden verziója;
- MV440 minden verziója.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről további információk a Siemens ProductCERT és az ICS-CERT weboldalain érhetőek el.

Siemens Siveillance sérülékenységek

A Siemens ProductCERT 3 sérülékenységről hozott nyilvánosságra információkat, amik a Siveillance eszközök alábbi verzióit érintik:

- 2017 R2 minden, v11.2a-nál korábbi verziója;
- 2018 R1 minden, v12.1a-nál korábbi verziója;
- 2018 R2 minden, v12.2a-nál korábbi verziója;
- 2018 R3 minden, v12.3a-nál korábbi verziója;
- 2019 R1 minden, v13.1a-nál korábbi verziója.

A gyártó a hibákat az érintett berendezések legújabb verzióiban 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égek BD Alaris rendszerekben

Elad Luz, CyberMDX munkatársa két sérülékenységet fedezett fel a BD Alaris egyes rendszereiben. Az első sérülékenység a helytelen hozzáférés-vezérlésből adódik és az Alaris Gateway Workstation alábbi verzióit érinti 1.3.2-es illetve 1.6.1-esnél korábbi firmware-verziók használata esetén:

- 1.0.13;
- 1.1.3 Build 10;
- 1.1.3 MR Build 11;
- 1.1.5;
- 1.1.6.

A második sérülékenység egyes fájltípusok nem megfelelően ellenőrzött feltöltéséből származik és az alábbi verziókat érinti 1.3.2-es illetve 1.6.1-esnél korábbi firmware-verziók használata esetén:

- 1.1.3 Build 10;
- 1.1.3 MR Build 11;
- 1.2 Build 15;
- 1.3.0 Build 14;
- 1.3.1 Build 13.

Érintettek továbbá az alábbi Alaris termékek 2.3.6-nál korábbi verziói:

- Alaris GS;
- Alaris GH;
- Alaris CC;
- Alaris TIVA.

A hibákat a gyártó az 1.3.2-es illetve 1.6.1-es firmware-verziókban javította, a 2.3.6-osnál korábbi Alaris GS/GH/CC/TIVA termékek esetén nincs hír javításról. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-164-01

Johnson Controls rendszerek sérülékenysége

Egy @bzyo_ név mögé rejtőző személy egy sérülékenységet jelentett a Johnson Controls-nak, ami az exacqVision ESM v5.12.2-es és korábbi verzióit érinti.

A gyártó a hibát a legújabb verzióban javította. A sérülékenységről további információkat az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-19-164-01

Sérülékenységek WAGO ipari switch-ekben

T. Weber, a SEC Consult Vulnerability Lab munkatársa 3 sérülékenységet fedezett fel a WAGO alábbi, ipari környezetekbe szánt switch-eiben:

- 852-303 minden, v1.2.2.S0-nál korábbi verziója;
- 852-1305 minden, v1.1.6.S0-nál korábbi verziója;
- 852-1505 minden, v1.1.5.S0-nál korábbi verziója.

A gyártó a hibákat az érintett eszközök legújabb firmware-verzióiban javította. A sérülékenységekről részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-164-02

Schneider Electric PowerSCADA sérülékenység

A Schneider Electric publikációja szerint egy sérülékenységet találtak a PowerSCADA alábbi verzióiban:

- PowerSCADA Expert 7.30;
- PowerSCADA Expert 7.40;
- PowerSCADA Expert 8.0 Service Release 1 előtti verziói.

A PowerLogic SCADA 7.20 és korábbi verziók, a PowerSCADA Expert 8.0 Service Release 1 verziója, a PowerSCADA Expert 8.1-es, 8.2-es és a Power SCADA Operation 9.0 nem érintettek a sérülékenység által.

A gyártó a hibát a Power SCADA Operation 9.0 verziójá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égek Schneider Electric ProClima rendszerekben

Kushal Arvind Shah, a Fortinet munkatársa, a Telus és Haojun Hou valamint Yongjun Liu, az NSFOCUS csoport tagjai három sérülékenységet jelentettek a Schneider Electric-nek, amik a ProClima 8.0.0-nál korábbi verzióit érintik.

A hibát a gyártó a legújabb verzióban javította. A sérülékenységekkel kapcsolatban részleteket a Schneider Electric bejelentése tartalmaz.

Cisco Industrial Network Director sérülékenységek

A Cisco publikációi alapján három sérülékenységet találtak az ipari hálózatok kezelésére készített Industrial Network Director termékében.

Jelenleg számomra Cisco ID nélkül nem érhető el részletesebb információ, a sérülékenységekről az alábbi Cisco bejelentésekben lehet részleteket találni:

Cisco Industrial Network Director Cross-Site Request Forgery sérülékenység

Cisco Industrial Network Director távoli kódfuttatás sérülékenység

Cisco Industrial Network Director Stored Cross-Site Scripting sérülékenység

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.

Néhány hónapja volt egy szombati posztom "Hogyan építsünk ICS biztonsági programot és csapatot?" címmel, amiben Dale Peterson gondolatai nyomán tettem fel a kérdést, hogy hogyan lehet fejleszteni az ICS biztonság jelenleg sajnos igen lesújtó helyzetét.

Az abban a poszban hivatkozott Dale Peterson cikk számos visszajelzést kapott különböző felületeken és igen sokan nehezményezték Dale azon megállapítását, hogy az IT (és az IT biztonság) győzött az IT-OT szembenállásban. Ezzel kapcsolatban két gondolatom van:

1. Szerintem az ICS biztonságot nem az IT és az OT vetélkedéseként kéne felfogni és kezelni. Sajnos itthon mind a mai napig elvétve lehet olyan vezetőt találni, aki képes lenne elvonatkoztatni a hazai nagyvállalatok és különsen közmű cégek esetén a silós működés és szervezeti struktúra rendszerétől, ezért az ICS biztonságot is csak fekete-fehéren tudják megítélni és múltjuk, tapasztalataik alapján döntik el, ha megkérdezik őket, hogy hova kéne tartoznia az ICS biztonságnak. Érdekes megfigyelni, hogy mind az IT, mind az OT menedzserek hajlamosak ezt az OT problémájának tekinteni és csak kevesen (jellemzően, bár nem kizárólag IT biztonsági háttérrel rendelkezők) ismerik fel, hogy a hatékony ICS biztonsági programhoz nagyon jó IT-OT-IT biztonsági hármas együttműködésre van szükség. Ahogy ma már nem lehet szigorú (és fizikai) elkülönítést alkalmazni az IT és az OT között, ugyanúgy nem lehet az ICS biztonságot csak az egyik vagy csak a másik szakterület feladatául szabni, mert igenis mindhárom területet értő és ismerő szakemberek nagyon magas színvonalú együttműködése adhat csak esélyt arra, hogy a folyamatvezérlő rendszereket és végső soron a fizikai folyamatokat meg lehessen védeni a kibertér felől érkező fenyegetésektől.

2. Jelenleg Magyarországon az IT és az IT biztonság területén is hatalmas hiány van a jól képzett és tapasztalt szakemberek terén, ez az ICS biztonság területén hatványozottan igaz. Ezen a szakember hiányon az IT-OT szembenállás hangoztatásával és minden irányból történő táplálásával nem lehet változtatni, igenis tudomásul kell venni, hogy ICS biztonsági szakember senkiből nem lesz úgy, hogy kilép valamelyik felsőoktatási intézményből a frissen megkapott diplomáját szorongatva (mondjuk az a kérdés is megérne egy posztot - talán néhány héten belül nekiülök és összerántom a gondolataimat a témában -, hogy miért csak diplomás mérnökökben gondolkodik a szakma?). Az általam ismert ICS biztonsági szakemberek pontosan 100%-a érkezett vagy az IT/IT biztonság vagy az OT területéről - én sem vagyok kivétel, jó néhány éves IT/IT biztonsági múlttal a hátam mögött kezdtem beletanulni az ICS biztonság szép, de időnként piszok nehéz és komoly buktatókat rejtő világába. Amíg az IT/IT biztonsági és OT mérnökök kölcsönös gyanakvással, nem pedig egymást segítő kollégaként tekintenek egymásra, ne várjuk, hogy lesz elég ICS biztonsági szakemberünk.

Ezt helyzetet tovább rontja, hogy akik értenek a témához, nem beszélnek róla, mintegy ülnek a munkahelyük elefántcsont tornyában és egyedül próbálnak javítani valamit a saját rendszereik biztonsági helyzetén. Nagyon nagy szükség van a SeConSys-hez hasonló kezdeményezésekre, ahol az ICS biztonságot értő és a területen tevékenykedő szakemberek tudnak találkozni és tapasztalatot cserélni, vagy akár csak megvitatni az elmúlt időszak eseményeit. Nagyon hasznosnak tartanám, ha a nagyobb hazai IT biztonsági rendezvények (ITBN, ISACA konferencia, Sec-TOUR, Hacktivity, stb.) tudnának a témának egy-egy (akár zárt körű, meghívásos) szekciót szervezni, mert sajnos az látszik, hogy az állam ebben a témában nem igazán aktív (legjobb esetben is csak elfogadja az alulról jövő kezdeményezéseket).

Sérülékenységek Phoenix Contact eszközökben

Zahra Khani, a Firmalyzer munkatársa és OPC Alapítvány több sérülékenységet azonosítottak a Phoenix Contact alábbi eszközeiben:

- AXC F 2152 2404267-es cikkszámú változatai;
- AXC F 2152 1046568-as cikkszámú változatai.

A gyártó a hibákkal kapcsolatban a legfrissebb elérhető firmware-verzió telepítését és kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-155-01

Sérülékenység Phoenix Contact ipari switch-ekben

Maxim Rupp és a CERT@VDE a gyártóval együttműködve egy sérülékenységet találtak a Phoenix Contact alábbi ipari Ethernet switch-eiben:

- FL NAT SMN 8TX-M (2702443);
- FL NAT SMN 8TX-M-DMG (2989352);
- FL NAT SMN 8TX (2989365);
- FL NAT SMCS 8TX (2989378).

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedésekre tett javaslatot, a hibát javító új firmware-verzióról jelenleg nincs hír. A sérülékenységgel kapcsolatban részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-155-02

Geutebrück kamerák sérülékenységei

Romain Luyer és Guillaume Gronnier, a CEIS, valamint Davy Douhine, RandoriSec munkatársai két sérülékenységet jelentettek az NCCIC-nek a Geutebrück alábbi eszközeivel kapcsolatban:

- G-Code Encoder EEC-2xxx sorozatának eszközei 1.12.0.25 és korábbi firmware-verziók esetén;
- G-Cam kamerák 1.12.0.25 és korábbi firmware-verziók esetén:
- EBC-21xx;
- EFD-22xx;
- ETHC-22xx;
- EWPC-22xx.

A hibákat a gyártó az 1.12.13.2-es firmware-verzióban javította. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-155-03

Sérülékenységek Optergy épületmenedzsment rendszerekben

Gjoko Krstic, az Applied Risk munkatársa hét sérülékenységet azonosított az Optergy Proton/Enterprise épületmenedzsment rendszereinek 2.3.0a és korábbi verzióiban.

A gyártó a hibákat a Proton/Enterprise 2.4.5-ös és későbbi verzióiban javította. A sérülékenységekkel kapcsolatban részletesebb információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-157-01

Panasonic rendszerek sérülékenységei

A 9sg Security Team a ZDI-vel együttműködve két sérülékenységről publikált információkat, amik a Panasonic FPWIN Pro 7.3.0.0 és korábbi verzióit érintik.

A gyártó a hibákat az FPWIN Pro 7.3.1.0 és későbbi verzióiban javította. A sérülékenységekről az ICS-CERT publikációjában lehet több információt találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-157-02

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

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

A Norsk Hydro elleni márciusi ransomware-támadás után lehetett tudni, hogy a cég 2019 elsõ negyedéves profitjára nagyon negatív hatással lesz az incidens, most azonban megérkeztek a konkrét számok. A Reuters cikke szerint a Norsk Hydro 2019 elsõ negyedéves profitja 559 millió norvég korona volt (nagyjából 64,3 millió amerikai dollár), ami 82 százalékos csökkenést jelent az elõzõ év azonos idõszakához mérve (és még így is 123 millió koronával magasabb érték volt, mint amit a Reuters által készített felmérésben résztvevõ elemezõk vártak).

Az incidens után a Norsk Hydro részvényei 20%-ot estek.

Ezek az adatok az ICS kiberbiztonság egy olyan aspektusát mutatják meg, amivel az OT és OT biztonsági mérnökök jóval ritkábban szoktak foglalkozni (és én sem igazán szoktam hangsúlyt helyezni egy-egy ICS biztonsági incidens pénzügyi következményeire), hiszen a kritikus infrastruktúrák és egyéb folyamatvezérlõ rendszerek elleni támadások elsõdleges hatásai szinte soha nem pénzügyiek és a legsúlyosabb következmények sem az anyagi veszteségben mutatkozhatnak meg, de ezek ellenére sem lehet figyelmen kívül hagyni.

Sérülékenységek Emerson Ovation vezérlőkben

A VDLab két sérülékenységet jelentett az NCCIC-nek, amik az Emerson Ovation OCR400 Controller-ek 3.3.1-es és korábbi verzióit érintik.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekkel kapcsolatban további információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-148-01

AVEVA sérülékenység

A VAPT Team, a C3i Center és az IIT Kanpur egy sérülékenység részleteiről adott információkat az AVEVA-nak, ami a gyártó alábbi rendszereit érinti:

- Vijeo Citect 7.30 és 7.40-es verziói;
- CitectSCADA 7.30 és 7.40- es verziói.

A gyártó a hibával kapcsolatban a CitectSCADA 2018-ra történő frissítést javasolja. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-150-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.

Egy érdekes tanulmány jelent meg a Vermont-i Jogi Egyetem (Vermont Law School) Energetikai és környezettudományi intézetétől, amiben az amerikai villamosenergia-hálózat biztonságával kapcsolatos, hat hónapos vizsgálatuk kutatási eredményeit foglalják össze.