Schneider Electric Floating License Manager sérülékenységek

A gyártó 3 különböző sérülékenységet talált a Floating License Manager platformjában, amit az alábbi termékeinél használ:

- SCADA Expert Vijeo Citect / CitectSCADA Version 7.30, 7.40;
- CitectSCADA Version 2015, 2016;
- Vijeo Historian/CitectHistorian Version 4.40, 4.50;
- CitectHistorian Version 2016;
- Citect Anywhere;
- PlantStruxure PES V4.3 SP1 és korábbi verziók;
- EcoStruxure Modicon Builder V3.0 és korábbi verziók.

A három hibából az alábbi termékeket csak a memóriakezelési hiba érinti:

- EcoStruxure Power Monitoring Expert 8.2 (Standard, DC, HC Editions);
- StruxureWare Power Monitoring Expert 8.1 (Standard, DC, HC Editions);
- StruxureWare Power Monitoring Expert 8.0 (Standard, DC, HC, Buildings Editions);
- StruxureWare Power Monitoring Expert 7.2.x;
- Energy Expert 1.x (a korábban Power Manager néven futó termék);
- EcoStruxure Power SCADA Operations 8.x (a korábbi PowerSCADA Expert nevű termék, csak az Advanced Reports és Dashboards modulok).

A gyártó a hibát az érintett termékek újabb verzióiban javította.

A sérülékenységekről további részleteket az ICS-CERT és a Schneider Electric publikációiban lehet találni.

Sérülékenységek BeaconMedaes rendszerekben

Maxim Rupp három sérülékenységet talált a BeaconMedaes TotalAlert Scroll Medical Air Systems nevű rendszerének 4107600010.23 és korábbi szoftververzióit futtatják.

A gyártó a hibákat (amelyek álláspontjuk szerint sem a páciensek egészségügyi adatainak bizalmasságát, sem az érintett rendszerek NFPA 99 szabványnak való megfelelését nem érinti) a 4107600010.24-es verzióban javította.

A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-144-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.

A héten szerdán, május 23-án a Talos egy publikációjában írt először az általuk VPNFilter-nek nevezett malware-támadásról, ami minimum 54 országban legkevesebb fél millió eszközt érinthet. A malware-kampány részleteiről a Talos cikke alapján részleteket közölt az ArsTechnica is, mindkét cikk közölte az érintett eszközök (Linksys, Mikrotik, Netgear, QNAP és TP-Link berendezések bizonyos típusairól van szó) listáját.

Felmerülhet, hogy mi köze lehet a VPNFilter-nek az ICS rendszerekhez - nos, több is, mint azt elsőre gondolnánk. Az első kapcsolódási pont az lehet, hogy a Talos kutatói szerint a VPNFilter malware karakterisztikájában több ponton az ukrán villamosenergia-rendszer elleni támadásoknál használt BlackEnergy malware-rel mutat hasonlóság. A másik, igen érdekes gondolatot egy ismerősömtől hallottam először: az európai villamosenergia-rendszerben számos olyan szereplő lehet, akik költséghatékonysági okokból nem nagyvállalati, hanem SOHO eszközökkel oldanak meg egyes LAN/WAN hálózati feladatokat - ilyen formán pedig a villamosenergia-rendszer szereplői is könnyedén érintettek lehetnek.

A téma súlyát mutatja, hogy pénteken a US-CERT külön publikációban (TA18-145A) foglalta össze a legfontosabb tudnivalókat. Az FBI és a DHS közös összefoglalója elsődleges intézkedésként azt javaslolja minden, érintett eszközt üzemeltető szervezetnek és magánszemélynek, hogy indítsák újra az eszközeiket - ez ugyan még nem fogja megvédeni őket a sérülékeny berendezések ismételt kompromittálásától, de legalább átmenetileg meg tudják szakítani a malware működését az eszközeiken.

Az ICS rendszereket üzemeltető szervezeteknek én ezen túlmenően még annyit javaslok, hogy ha eddig nem tették meg, építsenek minél előbb olyan képességeket, amikkel képesek a fenti forrásokban megadott adatok alapján felismerni, ha a rendszereik érintettek a VPNFilter-támadásokban. Az első lépés egy támadás elhárítása során még mindig az, hogy vegyük észre a támadók tevékenységeit - akár bejutottak már a hálózatunkba, akár még csak most keresik az utat befelé.

A különböző víruskereső és vírusírtó szoftverek legalább két évtizede részét képezik az IT-val foglalkozók napi rutinjának. Ezerszer elmondott alapigazság az IT biztonság területén, hogy egy AV megoldás használata elengedhetetlen, de nem elégséges a különböző informatikai eszközök és rendszerek elvárt szintű biztonságának megteremtéséhez és fenntartásához.

Az ICS rendszerek esetén ez az alapvetés nagyon sokáig nem érvényesült, a korábban itt a blogon is többször tárgyalt, teljes körű fizikai elkülönítésre alapozott biztonságra történő hivatkozással. Ahogy szinte minden, ez is részben a Stuxnet nyilvánosságra kerülésével változott meg, az az incidens mutatta meg, hogy a teljes hálózati elkülönítés esetén is viszonylag könnyű kártékony kódokat bejuttatni az ICS rendszerek hálózataiba. Ezzel párhuzamosan pedig a legtöbb ICS eszközöket üzemeltető szervezet előbb lassan, majd egyre gyorsabban kezdte összekapcsolni az ipari rendszerek hálózatait a vállalati IT hálózatokkal - erről is volt már szó néhányszor.

A fenti változások miatt egyre több szervezet kezdett antivírus termékeket telepíteni az ipari rendszereiket kiszolgáló eszközökre. A Windows-alapú rendszereknél ez még nem is olyan nagyon meglepő lépés, azonban vannak, akik ennél messzebbre mennek és Linux-, de akár Unix-alapú rendszerekre is telepítenek AV-megoldásokat. A mai blogposztnak nem célja az ilyen döntések megalapozottságának vizsgálata, inkább a telepített AV-megoldások mintafrissítésének legjobb gyakorlatát fogom bemutatni.

Ahogy korábban, a Purdue-alapú biztonságos ICS architektúra modell bemutatásáról szóló blogposztban írtam, az ICS rendszereknél használt AV- és patch-menedzsment szervereket hagyományosan az ICS DMZ hálózatba célszerű telepíteni, így a legtöbb olyan eszköz, amikre érdemes lehet és viszonylag könnyedén lehetséges AV-megoldást telepíteni, a Purdue-modell alapszabályát (minden eszköz csak a saját szintjével közvetlenül szomszédos szinteken elhelyezett eszközökkel kommunikálhat, ha ez szükséges) betartva tudnak vírusadatbázis frissítéseket letölteni.

Az AV-szoftverek frissítése során az alábbi lépéseket ajánlott minden körülmények között betartani:

- Minden alkalommal ellenőrizni kell a vírusadatbázis letöltésének forrását;
- A letöltött vírusadatbázis frissítés fájlján végezzünk vírusellenőrzést;
- Ellenőrizzük a letöltött fájl hash-ét;
- Telepítsük az új vírusadatbázist nem kritikus komponensekre (praktikusan fejlesztői és/vagy teszt rendszerekre);
- A nem kritikus (teszt/fejlesztői) eszközökön a szervezetnél meghatározott ideig történő használat után telepítsük az új vírusadatbázist az éles rendszerre. Amennyiben vannak duplikált elemek a rendszerben (pl. szerver clusterek), ne frissítsük egy időben az összes cluster-tag vírusadatbázisát;
- A éles rendszer eszközein a szervezetnél meghatározott ideig történő használat után telepítsük az új vírusadatbázist a többi, még nem frissített rendszerre;
- Folyamatosan ellenőrizzük a rendszereket szokatlan eseményeket keresve és a normális ICS folyamatokat figyelve.

Ahogy a fent leírt lépésekből is látszik, a tesztelés és a vírusadatbázis terítésének kontrollálása az egyik legfontosabb feladat az ICS rendszerek AV-megoldásainak frissítése során. Ennek oka, hogy az AV-megoldások használatának oka ICS környezetekben a folyamatvezérlési funkciók zavartalan működésének biztosítása, azonban az elmúlt több, mint egy évtizedben számos esetben (nagyjából minden nagy AV-megoldást gyártó cég termékénel legalább egyszer) láttunk már olyan példát, amik a nem megfelelő minőségbiztosításból és fejlesztési hibából bekövetkező incidensek során nagy számú rendszert tettek használhatatlanná. Nyilván ez minden érintett szervezet számára nagyon kellemetlen volt, de pl. egy erőmű vagy egy gyártósor-vezérlő rendszer esetében sokkal súlyosabb következményei is lehetnek, mint pl. egy pénzügyi vagy tanácsadó cég esetében.

Advantech WebAccess sérülékenységek

A Zero Day Initiative számos biztonsági kutatóval folytatott együttműködése 11 különböző hiba felfedezését eredményezte, amik az alábbi Advantech termékeket érintik:

- WebAccess V8.2_20170817 és korábbi verziói;
- WebAccess V8.3.0 és korábbi verziói;
- WebAccess Dashboard V.2.0.15 and prior,
- WebAccess Scada Node 8.3.1-nél korábbi verziói;
- WebAccess/NMS 2.0.3 és korábbi verziói.

A gyártó a hibákat a WebAccess 8.3.1-es verziójában javította.

A sérülékenységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-135-01

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

Szintén a ZDI-vel együttműködve talált egy sérülékenységet a Delta Electronics Delta Industrial Automation TPEditor 1.89 és korábbi verzióiban egy ThePotato néven hivatkozott személy.

A gyártó a hibát a legújabb verzióban javította.

A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-137-04

Sérülékenység Siemens SINAMIC S7-400-as berendezésekben

A Siemens ProductCERT bejelentése (majd ennek nyomán az ICS-CERT) egy újonnan felfedezett hibáról szól, ami a SINAMIC S7-400-as folyamatvezérlő berendezések alábbi változatait érinti:

- SIMATIC S7-400 (incl. F) CPU, V4.0 és annál korábbi összes hardver-verziója;
- SIMATIC S7-400 (incl. F) CPU V5.0 verziója a V5.2-nél korábbi firmware-verziókkal használva;
- SIMATIC S7-400H CPU, a V4.5-nél korábbi összes hardver-verzió.

A gyártó már elérhetővé tette a hibát javító firmware-verziókat.

A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Phoenix Contact switchek sérülékenységei

A Positive Technologies és a CERT@VDE munkatársai 3 sérülékenységet azonosítottak a Phoenix Contact alábbi termékeiben:

- 3xxx, 4xxx, és 48xx-as sorozatú switchek, amik 1.0 és 1.32 közötti verziójú firmware-t futtatnak.

A gyártó a hibákat az 1.34-es és újabb firmware-verziókban 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-18-137-02

Sérülékenység GE rendszerekben

Younes Dragoni, a Nozomi Networks munkatársa egy sérülékenységet azonosított a GE alábbi rendszereiben:

- PACSystems RX3i CPE305/310 9.20 és korábbi verziói;
- RX3i CPE330 9.21 és korábbi verziói;
- RX3i CPE 400 9.30 és korábbi verziói;
- PACSystems RSTi-EP CPE 100, minden verzió;
- PACSystems CPU320/CRU320 és RXi, minden verzió.

A GE már elérhetővé tette a sérülékenységet javító verziókat.

A sérülékenységről részletei az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-137-01

Medtronic N'Vision rendszerek sérülékenysége

Billy Rios, a Whitescope LLC munkatársa egy sérülékenységet azonosított a Medtronic alábbi termékeiben:

- 8840 N’Vision Clinician Programmer, minden verzió;
- 8870 N’Vision removable Application Card, minden verzió.

A gyártó nem adott ki javítást a hibához, de kockázatcsökkentő intézkedésekre vonatkozó javaslatokat tett közzé.

A sérülékenységről további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-18-137-01

Sérülékenység Becton, Dickinson and Company rendszerekben

A Becton, Dickinson and Company két sérülékenységet fedezett fel és jelentett az ICS-CERT-nek az alábbi termékeiben:

- BD Kiestra TLA;
- BD Kiestra WCA;
- BD InoqulA+ specimen processor

Mindhárom felsorolt rendszerben az alábbi, sérülékeny alkalmazásokat használják:

- Database (DB) Manager, 3.0.1.0 verzió;
- ReadA Overview 1.1.0.2 és korábbi verziók;
- PerformA 3.0.0.0 és korábbi verziók.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedésekre fog javaslatot tenni, várhatóan július folyamán.

A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-142-01

Martem TELEM temérkek sérülékenységei

Bernhards Blumbergs és Arturs Danilevics, a lett CERT (CERT.LV) munkatársai három sérülékenységet fedeztek fel a Martem alábbi, TELEM termékcsaládba tartozó eszközeiben:

- GW6, 2018.04.18-linux_4-01-601cb47 és korábbi verziói;
- GWM, 2018.04.18-linux_4-01-601cb47 és korábbi verziói.

A gyártó a hibákkal kapcsolatban újabb firmware-verzió telepítését illetve kockázatcsökkentő intézkedések bevezetését javasolja.

A sérülékenységekkel kapcsolatosan további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-142-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.

Még február elején találtam egy tanulmányt a kínai ICS biztonsági nemzeti kutatólabor és fenyegetéselemző központ weboldalán, ami az ICS rendszerek biztonságának kínai szempontból történő elemzését tartalmazza.

A tanulmány főbb megállapításai:

- Az IT és OT rendszerek egyre nagyobb integrációja miatt az ICS rendszerek egyre szélesebb körű használata mellett megjelentek azok a hálózatbiztonsági problémák, amik korábban ismeretlenek voltak az ipari informatika területén. Az ICS rendszerek többé nem különálló rendszerek, az ipari folyamatok hatékonyságnövelése érdekében egyre több ponton kell összekapcsolni ezeket különböző IT rendszerekkel, egyes esetekben akár az Internettel is, ami miatt megjelent az ipari informatikai rendszereket érő kibertámadások kockzatai.
- Az IT biztonság területén a tanulmány szerint hagyományosan a bizalmasság volt a fő szempont a CIA-háromszögből, ezt követte a sértetlenség és a rendelkezésre állás, az ICS rendszerek esetén azonban ez a fontossági sorrend nyilvánvalóan eltérő. Az ICS rendszerek esetén a rendelkezésre állás és a valósidejű teljesítmény sokkal fontosabb szempontok (itt jegyezném meg, hogy a tanulmány - már amennyire én a kínaiból fordított angolból le tudtam szűrni, itt nem említi a safety-t, ami minden esetben a legfontosabb szempont kell, hogy legyen egy ICS rendszer esetén).
- Az IT/OT konvergencia és az ipari dolgok Internete (IIoT, erről a témáról a múlt héten írtam) számos újabb biztonsági kihívást fog hozni az ICS rendszerek és az azokat üzemeltető illetve azok biztonságáért felelős mérnökök életébe. Ezeknek a kihívásoknak egy jelentős része külső kihívás lesz: a támadási felületek egyre nagyobbak lesznek, az operációs rendszerekben felfedezett hibák javítása nehéz, a szoftveres hibák kihasználása viszont egyre könnyebb. A másik oldalon az ICS rendszerek biztonsági hiányosságai vannak. Nem csak az egyre növekvő számú sérülékenységekről van szó, hanem az ICS eszközök nyilvántartásainak hiányosságait, a beépített biztonsági funkciók és eljárások hiányát is említi a tanulmány.

A publikációban megfogalmaznak néhány javaslatot is:

- Az ICS rendszereket üzemeltető szervezeteknek az IT biztonsági műveleti központok (SOC) mellett ipari biztonsági műveleti központok (ISOC) felállítását javasolják.
- Fel kell mérni, hogy az IT/OT konvergencia milyen IT kockázatokat hozott be az ICS világába és ezeket a kockázatokat már egy integrált megközelítés mentén kell kezelni.
- Közös IT/OT biztonsági csoportokat kell felállítani, amik az ICS rendszerekkel kapcsolatos biztonsági műveletekért lesznek felelősek.
- Fokozni kell a védelmi képességeket műszaki, hálózati és szabályozási szinten egyaránt. Az ICS-specifikus intézkedések mellett nem szabad megfeletkezni az adatok és rendszerek helyreállítását célzó műszaki és eljárásrendi intézkedésekről sem.

Maga a tanulmány 37 oldal és a fordítása sem egyszerű feladat, de mindenképp nagyon érdekesnek tartom már a lehetőségét is annak, hogy bepillantást nyerhetünk, hogyan gondolkodnak Kínában az ICS rendszerek biztonságáról.

Sérülékenységek Selix és GE Healthcare rendszerekben

Az ICS-CERT publikációja szerint Eric Evenchick, az Atredis Partners munkatársa két sérülékenységet talált a Selix alábbi rendszereiben:

- GEH-500 1.54 és korábbi verziói;
- SX-500 minden verziója (a termék gyártói támogatása 2011-ben megszűnt);
- GEH-SD-320AN, GEH-1.1-es és korábbi verziók;
- SD-320AN, 2.01-s és korábbi verziók (a termék gyártói támogatása 2017-ben megszűnt).

A GEH-500-as és GEH-SD-320AN eszközöket az alábbi GE Healthcare rendszerekben is felhasználták, így a sérülékenységek ezeket is érintik:

- MAC 3500;
- MAC 5000 (a termék gyártói támogatása 2012-ben megszűnt);
- MAC 5500;
- MAC 5500 HD.

A gyártók a hibák javításán jelenleg is dolgoznak. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet bővebb információkat találni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-128-01

Rockwell Automation FactoryTalk Activation Manager sérülékenységek

Az ICS-CERT bejelentése szerint a Rockwell Automation két sérülékenységet azonosított a FactoryTalk Activation Manager nevű megoldásában. A hibák az alábbi verziókat és a velük érkező termékeiket érintik:

- FactoryTalk Activation Manager v4.00 és v4.01, amiket a Wibu-Systems CodeMeter v6.50b és korábbi verzióihoz használnak;
- FactoryTalk Activation Manager v4.00, amit a FlexNet Publisher v11.11.1.1 és korábbi verzióinál alkalmaznak.

A gyártó a hibákat javító újabb verziókat már elérhetővé tette.

A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-102-02

Sérülékenység Rockwell Automation Arena rendszerekben

Az ICS-CERT publikációja szerint Ariele Caltabiano, a ZDI-vel együttműködve egy memóriakezelési hibát jelentett az NCCIC-nek, ami a Rockwell Automation Arena rendszereinek 15.10.00 és korábbi verzióit érinti.

A gyártó a hibát az Arena 15.10.01-es verzióban javította.

A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-130-02

Sérülékenység MatrikonOPC rendszerekben

Ilya Karpov, a Positive Technologies munkatársa egy sérülékenységet jelentett a MatrikonOPC-nek, ami a MatrikonOPC Explorer 5.0 és korábbi verzióit érinti és amit kihasználva egy támadó a rendszer fájljaihoz és könyvtáraihoz szerezhet hozzáférést.

A hibát a gyártó a V5.1.0.0 verzióban javította.

A sérülékenységről további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-130-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.

Manapság az ICS világában egyre többször lehet hallani az IIoT kifejezést és bár az IoT (Internet of Things) mára a mindennapjaink részévé vált, a többség nem igazán érti, hogy mit is jelent az ipari dolgok Internete, ezért úgy döntöttem, hogy a mai posztban ezt fogom egy kicsit körüljárni (egyébként is úgy látszik a blog statisztikáiból, hogy az alapfogalmak posztjai stabilan a leginkább látogatott oldalak, nem ide számítva néhány nagy érdeklődésre számot tartó esetet, mint például az ICS rendszerben talált cryptobányász malware-ről szóló poszt).

Szóval az IoT-t már minden kisgyerek is ismeri (láttam már alig másfél éves gyereket olyan biztonsággal tabletet kezelni, hogy az döbbenet) és lassan minden második nagymamánál is okostelefon van, de mi is az az IIoT?

Az ipari dolgok Internete kifejezés röviden azoknak az alkalmazásoknak, eszközöknek és szenzoroknak az összessége, amiket ipari környezetekben (például a szállítmányozásban, az energia és közműszektorban, különböző termelőüzemekben és hasonló ipari területeken) használnak, hogy az automatizálás egy új szintjét tudják megvalósítani (ez az, amiről Industry 4.0-ként vagy negyedik ipari forradalomként is szoktak beszélni, aminek a minél nagyobb fokú automatizálás a lényege, bulvárosan szólva a gépek elveszik a munkánkat...).

A gyakorlatban az IIoT lefed mindent a legegyszerűbb ipari automatizálástól a legbonyolultabb önműködő gyártósorokig, ahol akár még a karbantartási ciklusokat is a szenzoroktól gyűjtött adatok alapján tervezi és hajtja végre a rendszer, minimális emberi beavatkozást igényelve.

Miben más és miben hasonlít egymásra az IIoT és az IoT?

Kezdjük talán azzal, miben hasonlít az IIoT és az IoT: nagyon röviden fogalmazva ez a működési elv és mód. Jellemzően nagyon hasonló kommunikációs módokat használnak (bár az ipari eszközöknek van néhány csak rájuk jellemző vezeték nélküli kommunikációs protokollja, ilyen pl. a BGAN, a VSAT, a ZigBee vagy a WirelessHART) és - sajnos - a biztonsági hibák és hiányosságok területén is nagyon sok hasonlóságot lehet felfedezni.

Különbségből viszont már jóval több van. Az IIoT elsősorban a különböző gépek és berendezések összekapcsolására koncentrál, szemben az IoT eszközökkel, amik jellemzően az átlag fogyasztók igényeinek kiszolgálására fókuszálnak (ide értve az okostelefonoktól a fitnesz-karkötőkön át az okoshűtőig nagyjából minden, hálózaton kommunikálni képes eszközt). A legfontosabb különbség, hogy az IoT eszközök hibás működése vagy működésképtelensége nem okoz vészhelyzetet - szemben egyes ipari rendszerekkel, ahol egy rendszerhiba vagy leállás magas kockázatú vagy akár életveszélyes helyzeteket is teremthet, de jobb esetben is nagyon súlyos anyagi veszteségek okozója lehet.

Ugyancsak nagy különbség van az IoT és IIoT eszközök élettartamában. Az IoT esetében egy két éves eszköz már elavultnak számít, gondolom mindenki ismer legalább egy olyan embert, aki pl. évente cserél telefont, mert az újabb mindig jobb(?), az ipari eszközöknél viszont mind a mai napig bevett szokás 10-15-20 évre tervezni egy-egy nagyobb értékű berendezéssel és ez alól az IIoT eszközök sem kivételek.

A jóval hosszabb élettartam mellett figyelemmel kell lenni arra is, hogy az IIoT eszközöknek gyakran sokkal mostohább környezetben (szélsőséges hidegben vagy melegben, porban, vizes vagy más folyadékokkal szennyezet környezetben, stb.) kell működniük megbízhatóan. Egyes eszköz-kategóriákban (pl. hálózati eszközök) már régóta létezik az ún. ruggedized kategória, ami kifejezetten az ipari környezetbe tervezett eszközök kategóriáját jelenti.

Jellemzően milyen területeken használják az IIoT-t?

Az Industrial IoT Consortium összeállított egy 15 tételes listát az IIoT lehetséges felhasználási területeiről, ezek a következők:

- Okosgyárak raktározási alkalmazásai;
- Prediktív és távoli karbantartás;
- Áruszállítás nyomonkövetése;
- Hálózatintegrált logisztika;
- Okosmérés és okos villamosenergia-hálózat;
- Okosvárosok alkalmazásai;
- Okosfarmok és állatállomány felügyelete;
- Ipari biztonsági (security) berendezések;
- Energia-felhasználás optimalizálása;
- Ipari fűtés, szellőztetés és légkondícionálás;
- Gyártásellenőrzés;
- Eszközkövetés és okoslogisztika;
- Ipari környezetekben gáz- és hőmérsékletellenőrzés;
- Biztonsági (safety) és egészségügyi ellenőzés;
- Eszközök teljesítmény menedzsmentje.

Az IIoT kihívásai

Lévén ICS kiberbiztonsági blog, talán megbocsátható, ha ezzel a témával kezdem az IIoT eszközök kihívásainak felsorolását. Az IIoT berendezések, hasonlóan az IoT termékekhez, sajnos meglehetősen komoly hiányosságokkal rendelkeznek kiberbiztonsági szempontból, elég csak a 2016 októberi Mirai botnet által végrehajtott DDoS-támadásokra gondolni, ahol egyes információk szerint számos gyengén védett és kompromittált ipari biztonsági kamerát is felhasználtak a támadók. Ugyanígy kompromittált IIoT eszközökön keresztül értékes adatokat lehet ellopni vagy akár jelentős károkat (akár emberéletet is követelő incidenseket) is lehet előidézni - itt szeretnék mindenkit emlékeztetni, hogy még mindig nem tudjuk, vajon mi is volt a pontos célja a Triton/TriSIS ICS malware-t fejlesztő és felhasználó csoportnak...

Meglepő módon pont az IoT irányából érkezik egy olyan módszer, ami egyes szakértők szerint segíthet javítani az IIoT eszközök biztonsági problémáin, ez pedig az automatizált, háttérben történő frissítés. Én azonban ezzel kapcsolatban szkeptikus vagyok, hiszen az ICS világ egy legnagyobb kihívása mind a mai napig a lassú hibajavítás vagy éppen a javítások telepítésének teljes hiánya. Nem érzem életszerűnek, hogy egy változatlan gondolkodású és hozzáállású OT-s mérnökcsapat, akik a DCS/SCADA rendszerek esetén minden rendelkezésükre álló érvvel és eszközzel a patch-ek telepítése ellen van, hajlandó lesz az IIoT eszközöknél engedélyezni az automatikus frissítések telepítését.

A biztonsági problémákon túl két további komoly kihívás is nehezíti az IIoT elterjedését:

- A szabványok és a szabványosítás hiánya;
- A régi technológiákkal történő integráció nehézkessége.

Sérülékenységek Lantech IDS 2102 berendezésekben

Florian Adamsky két sérülékenységet jelentett az NCCIC-nek, amik a Lantech IDS 2102 berendezéseinek 2.0 és korábbi verzióit érinti.

A gyártó nem reagált az NCCIC sérülékenységekkel kapcsolatos megkeresésére, így egyelőre nincs javítás a hibákra.

A sérülékenységek részleteiről az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-123-01

Sérülékenységek Philips Brilliance komputer tomográfokban

A gyártó 3 sérülékenységről tett jelentést az NCCIC-nek, amik a Brilliance komputer tomográf berendezéseik alábbi modelljeit és verzióit érintik:

- Brilliance 64, 2.6.2 és korábbi verziók;
- Brilliance iCT, 4.1.6 és korábbi verziók;
- Brillance iCT SP 3.2.4 és korábbi verziók;
- Brilliance CT Big Bore 2.3.5 és korábbi verziók.

A Philips kockázatcsökkentő intézkedések bevezetését javasolja és az egyik hibához (beégetett felhasználónevek és jelszavak) javítást is kiadott.

A sérülékenységekkel kapcsolatos bővebb információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-18-123-01

Siemens Siveillance VMS sérülékenységek

A Siemens ProductCERT egy friss sérülékenységről publikált részleteket, amik a Siveillance VMS (IP alapú videó menedzsment rendszer) alábbi verzióit érinti:

- Siveillance VMS 2016 R1 és korábbi kiadások V10.0a-nál korábbi firmware verzió használata esetén;
- Siveillance VMS 2016 R2, V10.1a-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2016 R3, V10.2b-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2017 R1, V11.1a-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2017 R2, V11.2a-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2018 R1, V12.1a-nél korábbi firmware verzió használata esetén.

A hiba javítását a gyártó már elérhetővé tette. A sérülékenységről további információkat a Siemens ProductCERT weboldalán lehet találni: https://cert-portal.siemens.com/productcert/pdf/ssa-457058.pdf

Sérülékenység a Siemens Siveillance VMS mobil alkalmazásokban

A Siemens ProductCERT bejelentése szerint Karsten Sohr, a TZI Bremen munkatársa egy nem megfelelő tanúsítvány-ellenőrzésből adódó hibát azonosított a Siveillance VMS Video mobil alkalmazások alábbi verzióiban:

Siveillance VMS Video for Android, V12.1a-nál korábbi összes verzió;
Siveillance VMS Video for iOS, V12.1a-nál korábbi összes verzió.

A gyártó a hibát a V12.1a verzióban javította. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT publikációja tartalmaz: https://cert-portal.siemens.com/productcert/pdf/ssa-468514.pdf

Sérülékenységek Siemens SINAMICS termékekben

A Siemens ProductCERT publikációja szerint két sérülékenységet azonosítottak a SINAMICS középfeszültségű berendezések következő verzióiban:

SINAMICS GH150 V4.7 (PROFINET-es változat), V4.7 SP5 HF7-nél korábbi verziói;
SINAMICS GL150 V4.7 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS GM150 V4.7 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SL150 V4.7.0 (PROFINET-es változat), V4.7 HF30-nál korábbi verziói;
SINAMICS SL150 V4.7.4 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SL150 V4.7.5 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SM120 V4.7 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SM150 V4.7 (PROFINET-es és SIMOTION-ös változatok) minden verziója.

A gyártó a sérülékenységek javításait már elérhetővé tette. A sérülékenységekről részletesebben a Siemes ProductCERT weboldalán lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-546832.pdf

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.

Alig két hete egy nagyon érdekes cikk jelent meg a golem.de oldalon. A tiroli Patscherkofel hegy síliftjének vezérlőrendszerét két biztonsági kutató, Sebastian Neef és Tim Philipp Schäfers még márciusban fedezték fel, amikor Internetre csatlakoztatott, sérülékeny rendszereket kerestek.

Az egyébként is elavult vezérlőrendszerrel kapcsolatban számos egyéb (ICS rendszerek esetében sajnos általánosnak nevezhető) hibát is azonosítottak. Amellett, hogy sílift vezérlőrendszerét az Internetről is el lehetett érni, semmilyen titkosítást (pl. TLS) nem használtak a vezérlési utasítások kiadása során, nem volt szükség authentikációra a rendszerbe történő bejelentkezéshez, Cross-site scripting támadást lehetett végrehajtani a rendszer ellen és további, az OWASP Top10-ben is megtalálható sérülékenységet is ki lehetett használni a rendszer elleni támadások során.

Az osztrák CERT tájékoztatása szerint a sílift vezérlőrendszerét mindaddig nem fogja használni az IKB, az Innsbruck-i városi közműszolgáltató, amíg megfelelő biztonsági intézkedéseket nem vezetnek be a rendszerrel kapcsolatban. Így végül is a történetet tekinthetjük pozitív végkifejletűnek, azonban nem lehet elégszer hangsúlyozni: nem szabad folyamatvezérlő rendszereket publikus hálózatokra csatlakoztatni! Ahogy ebből az esetből is látszik, gyakorlatilag a szerencsén múlt, hogy két olyan ember találta meg a sílift vezérlőrendszerét az Interneten, akik kellően megfontoltak és felelősségteljesek voltak és eszükbe sem jutott kipróbálni, hogy "mi lesz, ha megnyomom ezt a gombot?"

A teljes történetet (németül) a golem.de oldalán lehet olvasni: https://www.golem.de/news/patscherkofel-gondelbahn-mit-sicherheitsluecken-1804-133930.html

Az esettel kapcsolatban a CERT.at is kiadott egy közleményt: http://www.cert.at/services/blog/20180420131015-2180.html

Sérülékenység Siemens WinCC iOS alkalmazásban

Alexander Bolshev, az IOActive és Ivan Yushkevich, az Embedi munkatársai egy információszivárgáshoz vezető hibát azonosítottak a SIMATIC WinCC OA Operator iOS alkalmazás összes verziójában.

A hibával kapcsolatban nincs hír javítást hozó verzióról, a Siemens kompenzáló kontrollok alkalmazását javasolja az érintett szoftvert használó ügyfeleinek és azt, hogy kiemelt biztonságú környezetekben ne használják az alkalmazást.

A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Delta Electronics PMSoft sérülékenység

Ghirmay Desta a TrendMicro ZDI-vel együttműködve talált egy puffer-túlcsordulást a Delta Electronics PMSoft nevű, mozgásvezérlő rendszerek fejlesztő környezeteként használt rendszer 2.10-es és korábbi verzióiban.

A gyártó a hibát a 2.11-es és későbbi verziókban javította.

A sérülékenységről bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-116-01

Sérülékenységek WECON rendszerekben

Sergey Zelenyuk, az RVRT és Michael DePlante, a Champlain Főiskola munkatársai, a TrendMicro ZDI-vel együttműködve azonosítottak egy puffer-túlcsordulásos hibát a WECON alábbi rendszereiben:

- WECON LeviStudioU 1.10-es verzió, a WECON LeviStudioU 1.8.29 és korábbi verzióiban megtalálható szoftver;
- PI Studio HMI Project Programmer 2017. november 11-i és korábbi build-ek.

A gyártó a hibát az itt elérhető verzióban javította.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-116-02

Advantech WebAccess sérülékenységek

Steven Seeley, a Source Incite munkatársa a ZDI-vel közösen publikált több, az Advantech WebAccess HMI Designer 2.1.7.32-es és korábbi verzióit érintő sérülékenységet.

Jelenleg nincs információ olyan újabb verzióról, ami javítaná a hibákat, a gyártó az NCCIC-vel közösen dolgozik kockázatcsökkentő intézkedéseken.

A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-114-03

Vecna VGo Robot sérülékenységek

Dan Regalado, a Zingbox munkatársa két hibát azonosított a Vecna VGo Robot 3.0.3.52164-esnél korábbi verzióiban.

A gyártó a hibák javítására szolgáló patch-et már elérhetővé tette az ügyfelei számára.

A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-114-01

Becton, Dickinson and Company termékek sérülékenysége

Mathy Vanhoef, az imec-DistriNet és a Leuven-i Katolikus Egyetem munkatársa több, a KRACK sérülékenységhez kapcsolódó hibát talált a Becton, Dickinson and Company alábbi termékeiben:

- BD Pyxis Anesthesia ES;
- BD Pyxis Anesthesia System 4000;
- BD Pyxis Anesthesia System 3500;
- BD Pyxis MedStation 4000 T2;
- BD Pyxis MedStation ES;
- BD Pyxis SupplyStation;
- BD Pyxis Supply Roller;
- BD Pyxis ParAssist System;
- BD Pyxis PARx;
- BD Pyxis CIISafe – Workstation;
- BD Pyxis StockStation System;
- BD Pyxis Parx handheld

A gyártó a hibákat harmadik féltől származó javítás alkalmazásával javítja a termékeiben.

A sérülékenységről további részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-114-01

Intel 2G Modem sérülékenység

Dr. Ralph Phillip Weinmann és Dr. Nico Golde a Comsecuris munkatársai egy puffer-túlcsordulásos hibát találtak az Intel alábbi, 2G képes és engedélyezett ETWS funkcióval működő modemjeiben:

- Intel XMM71xx;
- Intel XMM72xx;
- Intel XMM73xx;
- Intel XMM74xx;
- Sofia 3G;
- Sofia 3G-R;
- Sofia 3G-R W.

Az Intel a hibát javító patch-et azoknak a gyártó partnereinek fogja elérhetővé tenni, akik ezeket a modemeket beépítik a saját eszközeikbe, a végfelhasználók az egyes gyártóknál tudnak érdeklődni a javításokról.

A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-114-02

Moxa EDR-810 ipari routerek sérülékenységei

Carlos Pacho, a Cisco Talos laborjának munkatársa több sérülékenységet fedezett fel a Moxa EDR-810 ipari routereinek V4.1 build 17030317 verziójában. A Talos publikációja szerint feltételezhető, de nem megerősített, hogy a sérülékenységek a korábbi verziókat is érintik.

A gyártó a hibát a v4.2-es firmware-verzióban javította.

A sérülékenységek részleteiről a Talos és a Moxa weboldalain lehet olvasni.

Sérülékenységek Schneider Electric Pelco Sarix Pro 1 kamerákban

A Schneider Electric publikációja szerint a Pelco Sarix Pro első generációs kamerák firmware-jének 3.29.69-nél korábbi verzióiban. A második generációs Pelco Sarix Pro kamerákat a hibák nem érintik.

A sérülékenységeket a gyártó a 3.29.69-es firmware-verzióban javította.

A hibákról részletesebben a Schneider Electric publikációjában lehet olvasni.

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.