ABB Welcome IP-Gateway sérülékenységek

A gyártó bejelentése szerint az alábbi termékeikben több sérülékenységet is azonosítottak Florian Grunow, az ERNW GmbH munkatársának és Maxim Rupp segítségével. A sérülékenységek az alábbi verziókat érintik:

- ABB Welcome System Device 3.39 és korábbi verziók;
- Busch-Jaeger Systemgerät 3.39 és korábbi verziók.

A gyártó a hibákat a 3.40-es verzióban már javította, ennek ellenére az érintett verziókat használó ügyfeleinek a legújabb, 3.48-as verzióra történő frissítést javasolja.

A sérülékenységekről további részleteket az ABB weboldalán lehet olvasni.

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

Az ICS-CERT publikációja szerint Gjoko Krstic, a Zero Science Lab munkatársa egy korábban ismeretlen hibát fedezett fel a Rockwell Automation alábbi rendszereiben:

- RSLinx Classic 3.90.01 és korábbi verziók;
- FactoryTalk Linx Gateway 3.90.00 és korábbi verziók.

A gyártó a hibát az RSLinx Classic v4.00.01 és későbbi verzióban illetve a FactoryTalk Linx Gateway v6.00.00 és későbbi verzióiban javította.

A sérülékenységgel kapcsolatos további információkat az ICS-CERT bejelentése tartalmazza: https://ics-cert.us-cert.gov/advisories/ICSA-18-158-01

Sérülékenység Siemens rendszerekben

A gyártó bejelentése szerint két magas és egy kritikus besorolású sérülékenységet azonosítottak az alábbi, épületautomatizálási termékeikben:

- License Management System (LMS) V2.1 és korábbi verziói;
- Annual Shading V1.0.4 és V1.1 verziók;
- Desigo ABT V3.1.0, V3.0.1 és korábbi verziók 12.10.318, 12.0.850.0, 11.10.55.0, 11.0.360.0, 10.10.845.0 és 10.0.830.0 build-jei;
- Desigo Configuration Manager (DCM) V6.1 SP2 és korábbi verziói valamint a V6.0 SP1 és korábbi verziói;
- Desigo XWP V6.1 és korábbi verziók;
- SiteIQ Analytics V1.1, V1.2 és V1.3 verziók;
- Siveillance Identity V1.1 verzió.

A Siemens a hibák által érintett összes termékéhez elérhetővé tette a javításokat.

A sérülékenységekkel kapcsolatos részletesebb információk a Siemens ProductCERT weboldalán találhatóak: https://cert-portal.siemens.com/productcert/pdf/ssa-566773.pdf

Sérülékenységek Siemens SCALANCE rendszerekben

A Siemens ProductCERT publikációja szerint a SCALANCE M875 típusú eszközök összes verziója érintett az által a 6 sérülékenység által, amit nemrég azonosítottak. A gyártó a hibákat a SCALANCE M876-4 és a RUGGEDCOM RM1224 modellekben már javította illetve kockázatcsökkentő intézkedések bevezetését is javasolja az érintett rendszereket használó ügyfeleinek.

A sérülékenységekről további részleteket a Siemens ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-977428.pdf

Sérülékenységek Siemens SCALANCE X ipari switch-ekben

A gyártó két Cross-site scripting sérülékenységről közölt információkat a mai napon kiadott publikációjában. A sérülékenységek az alábbi termékeiket érintik:

- SCALANCE X-200, V5.2.3-nál régebbi összes verzió;
- SCALANCE X-200 IRT V5.4.1-nél régebbi összes verzió;
- SCALANCE X300 minden verziója.

A gyártó az X-200-as és X-200 IRT termékekhez kiadta a hibákat javító verziókat, az X300-asokat használó ügyfelek számára pedig kockázatcsökkentő intézkedésekre vonatkozó ajánlásokat publikáltak.

A sérülékenységekről bővebb információt a Siemens ProductCERT publikációjában lehet találni: https://cert-portal.siemens.com/productcert/pdf/ssa-480829.pdf

Sérülékenység Siemens termékekben

Dr. Ang Cui és Joseph Pantoga, a Red Balloon Security munkatársai egy puffer-túlcsordulásos sérülékenységet jelentettek a Siemens-nek, ami az alábbi termékeiket érinti:

- RFID 181-EIP minden verziója;
- RUGGEDCOM WiMAX V4.4 és V4.5 verziók;
- SCALANCE X-200, a V5.2.3-nál régebbi összes verzió;
- SCALANCE X-200 IRT V5.4.1-nél régebbi összes verzió;
- SCALANCE X-204RNA minden verziója;
- SCALANCE X-300 minden verziója;
- SCALANCE X408 minden verziója;
- SCALANCE X414 minden verziója;
- SIMATIC RF182C minden verziója.

A gyártó az X-200-as és X-200 IRT termékekhez kiadta a hibákat javító verziókat, a többi érintett terméküket használó ügyfeleik számára pedig kockázatcsökkentő intézkedésekre vonatkozó ajánlásokat publikáltak.

A sérülékenységgel kapcsolatos részletek a Siemens ProductCERT bejelentésében olvashatóak: https://cert-portal.siemens.com/productcert/pdf/ssa-181018.pdf

Sérülékenység Siemens egészségügyi rendszerekben

A Siemens Healthineers két sérülékenységet azonosított, amik az alábbi vérgáz-elemző rendszereiket érintik:

- RAPIDLab 1200, RAPIDPoint 400 és RAPIDPoint 500 rendszerek minden verziója, amiknél nem használják a Siemens Healthineers Informatics termékeit;
- RAPIDLab 1200-as sorozat minden, V3.3-nál korábbi verziója, ha a Siemens Healthineers Informatics termékeivel használják őket;
- RAPIDPoint 500 rendszerek minden, V3.0-nál későbbi verziója, ha a Siemens Healthineers Informatics termékeivel használják őket;
- APIDPoint 500 rendszerek V2.4.X verziója, ha a Siemens Healthineers Informatics termékeivel használják őket;
- RAPIDPoint 500 rendszerek minden, V2.3-nál régebbi verziója, ha a Siemens Healthineers Informatics termékeivel használják őket;
- RAPIDPoint 400 rendszerek, ha a Siemens Healthineers Informatics termékeivel használják őket.

A gyártó a sérülékenységekkel kapcsolatban kockázatcsökkentő intézkedések bevezetésére tett javaslatot.

A sérülékenységek részleteit a Siemens ProductCERT weboldalán találhatóak: https://cert-portal.siemens.com/productcert/pdf/ssa-755010.pdf

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.

Alig több, mint két héttel ezelőtt a CyberScoop több cikkében arról írt, hogy a Dragos által Xenotime-nak nevezett támadói csoport, amit a Szaúd-arábiai Triton/TriSIS támadás feltételezett elkövetőjének tartanak, több ipari létesítmény ellen is támadást indítottak.

Ahogy korábban többször is írtam róla, a Triton/TriSIS (hasonlóan a Stuxnet-hez), újabb mérföldkövet jelentett az ICS kiberbiztonsági incidensek történetében, ez volt az első olyan támadás, ahol a cél a feltételezések szerint a korábbiaknál (Stuxnet, ukrán villamosenergia-rendszer elleni támadások) sokkal nagyobb mértékű pusztítás és az emberélet veszélybe sodrása lehetett.

A kutatók szerint az amerikai támadásoknál talált malware számos hasonlóságot mutat a Triton/TriSIS malware-rel, azzal ellentétben azonban az új malware-t nem egyetlen safety instrumented system (SIS) ellen tervezték, hanem több különböző SIS rendszert képes támadni. Egyelőre azzal kapcsolatban nincsenek információk, hogy a Xenotime-nak nevezett támadói csoport hogyan volt képes létrehozni egy ilyen összetett malware-t.

Bár a Dragos munkatársai fontos részleteket nem publikáltak, annyit tudni lehet, hogy a támadók a célba vett ipari szervezetek IT rendszereit vették célba, jellemzően adathalász és ún. waterin-hole támadásokkal. Ez persze válaszok helyett inkább csak újabb kérdéseket vet fel, hiszen ahogy azt már a Triton/TriSIS részletesebb elemzéseiben olvashattuk, a szaúdi incidenshez nagy mértékben hozzájárult az a hiba, hogy az SIS rendszer össze volt kapcsolva az adott létesítmény folyamatirányító rendszerének hálózatával, ami az ICS biztonsági jó gyakorlatok szerint az egyik leginkább ellenjavalt gyakorlat. Így azonban adódik a kérdés, hogy az amerikai támadások esetén vajon a támadók nem jutottak el az SIS rendszerekig vagy az ilyen (nem ajánlott) kapcsolatok az ICS és SIS rendszerek között sokkal általánosabbnak számítanak, mint azt gondolnánk?

A jelek szerint eljött az ideje annak, hogy az ipari folyamatirányító rendszerek és berendezések auditálása után az SIS rendszerekre vonatkozó audit módszertanokat dolgozzunk ki. Tisztán látszik, hogy ez nem lesz könnyű, az OT szakterületen dolgozó mérnökök ellenállása az SIS rendszereknél az eddig megszokottnál is erősebb lehet és tekintettel arra, hogy ezeknek a rendszereknek az elsődleges célja az emberélet megóvása, úgy gondolom, hogy ezeket az észrevételeket nagyon alaposan számításba kell venni.

A másik nagy feladat az érintett szakemberek (OT mérnökök és IT biztonsági mérnökök) képzése. Az OT mérnökök biztonságtudatossági képzésére való igényt én személy szerint már látom megjelenni, ennek igen jó jele, hogy a Magyar Elektrotechnikai Egyesület évek óta egyre nagyobb hangsúlyt igyekszik helyezni a témára, de az IT biztonsági szakemberek ipari folyamatvezérlési szaktudással történő felvértezéséhez az egyes ipari szereplőknek, esetleg az iparági szereplőknek kell hangsúlyt fektetni, hiszen az iparági folyamatvezérlés szektorspecifikus tudása náluk található.

A mai napon a Talos újabb információkat tett közzé a VPNFilter malware-rel kapcsolatos kutatásaikról. A blogbejegyzés szerint a korábban már azonosított gyártók mellett további gyártók (ASUS, D-Link, Huawei, Ubiquiti, UPVEL, ZTE) hálózati eszközeiről és korábban már említett gyártók (Linksys, MikroTik, Netgear, TP-Link) újabb modelljeiről derült ki, hogy célpontjai a VPNFilter-nek.

Az érintett hálózati eszközök körének bővülése mellett a Talos kutatói beszámoltak egy új, 3. szintű modulról a malware-rel kapcsolatban, ami kártékony tartalmat ad a kompromittált hálózati eszközön átmenő hálózati forgalomhoz, amivel egy man-in-the-middle támadáshoz hasonlóan képesek a támadók a végponti eszközök ellen támadásokat intézni.

Fontos és részletes újabb információk is napvilágot láttak a malware csomagszűrő funkciójával kapcsolatban, amivel a Modbus forgalmat keresi a megfertőzött hálózati eszközökön.

Az újabb részletek és frissített eszközlistát, valamint frissített IoC-ket tartalmazó blogposztot itt lehet megtalálni: https://blog.talosintelligence.com/2018/06/vpnfilter-update.html

Schneider Electric U.motion sérülékenységek

A gyártó két biztonsági kutatóval (bigric3, a 360A-TEAM tagja és Wei Gao (az Ixia A Keysight Business munkatársa) való együttműködés során 4 sérülékenységet azonosítottak, amik a U.motion
Builder 1.3.4-nél korábbi összes verzióját érintik.

A gyártó a hibákat a weboldalán elérhető tett 1.3.4-es verzióban javította.

A sérülékenységek részleteiről a Schneider Electric weboldalán lehet bővebb információkat találni.

Sérülékenységek Delta Industrial Automation DOPSoft rendszerekben

A Delta DOPSoft 4.00.04 és korábbi verzióiban 3 különböző sérülékenységet talált egy B0nd nevű biztonsági kutató (aki a ZDI-vel együttműködésben jelentette a talált hibákat). A sérülékenységeket a gyártó a DOPSoft legújabb verziójában javította.

A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-151-01

GE rendszerek sérülékenységei

Az rgod néven ismert biztonsági kutató az ZDI-vel együttműködve jelentett 3 sérülékenységet, amik a GE MDS PulseNET termékcsaládjának alábbi tagjait érintik:

- PulseNET Version 3.2.1 és korábbi verziók;
- PulseNET Enterprise Version 3.2.1 és korábbi verziók.

A gyártó módosította az érintett termékek kialakítását és PulseNET szoftverét, ezzel javítva a hibákat, minden érintett ügyfelüknek azt javasolják, hogy használják a PulseNET 4.1 vagy újabb verzióit.

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-18-151-02

Sérülékenység Yokogawa STARDOM vezérlőkben

A Venustech-hez tartozó VDLab és a Dongfang Electric Corporation (DEC) egy beégetett felhasználói azonosítókhoz kapcsolódó hibát jelentettek az NCCIC-nek. A hiba a Yokogawa STARDOM vezérlők alábbi verzióit érintik:

- FCJ (R4.02 és korábbi verziók);
- FCN-100 (R4.02 és korábbi verziók);
- FCN-RTU (R4.02 és korábbi verziók);
- FCN-500 (R4.02 és korábbi verziók).

A gyártó a hibákat az R4.10 és későbbi verziókban javította.

A sérülékenységek részletei az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-151-03

ABB IP Gateway sérülékenységek

Maxim Rupp 3 sérülékenységet azoosított az ABB IP Gateway termékének 3.39 és korábbi verzióiban.

A gyártó a hibákat javító verziót elérhetővé tette a weboldalán. A sérülékenységek részleteiről az ABB és az ICS-CERT publikációiban lehet olvasni.

Philips egészségügyi rendszerek sérülékenységei

Oran Avraham, a Medigate munkatársa a gyártóval együttműködésben 3 sérülékenységet hozott az ICS-CERT tudomására, ami az alábbi rendszereket érinti:

- IntelliVue Patient Monitors MP sorozat (MP2/X2/MP30/MP50/MP70/NP90/MX700/800 modellek);
- IntelliVue Patient Monitors MX (MX400-550 és X3/MX100 modellek);
- Avalon Fetal/Maternal Monitors FM20/FM30/FM40/FM50 F.0, G.0 és J.3 szoftver-verziói.

A gyártó jelenleg is kiadásra készíti elő a hibákat javító verziót. A sérülékenységekról további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-18-156-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.

A szoftveres hibajavítások alkalmazása az ICS rendszerek világában mind a mai napig meglehetősen heves vitákat szokott kiváltani az IT biztonsági szakemberek és az OT mérnökök között. Alapvető filozófiai különbségek vannak a két szakterület között, az OT mérnököket az első munkanapjuktól kezdve arra tanítják, hogy egy működő rendszert csakis a legsúlyosabb indok esetén szabad módosítani. Ráadásul ugyanazok az idősebb, több évtizedes tapasztalattal rendelkező mérnökök, akik ezt tanították nekik, még bőven a Stuxnet megjelenése után is meggyőződéssel vallották (és néha még ma is meggyőződésük), hogy a folyamatvezérlő rendszereikhez nem lehet hozzáférni a vállalati vagy publikus hálózatokról. Harmadrészt igen sokáig az ICS rendszerek gyártói is azt az álláspontot képviselték, hogy az általuk fejlesztett folyamatirányító rendszerekben és eszközökben feltárt hibákat nem szükséges javítani, amennyiben azok valós kockázatnövekedést okoznak a felhasználó rendszerében, azt tökéletesen lehet kompenzáló kontrollok (pl. tűzfalak és egyéb hálózatbiztonsági megoldások) alkalmazásával ellensúlyozni.

Az elmúlt néhány évben (ahogy az ICS kiberbiztonsági incidensek és publikált sérülékenységek száma egyre gyorsabban nőtt), már nem csak a nagy és széles körben ismert gyártók (pl. Siemens, ABB, Schneider Electric, stb.) fordítanak egyre nagyobb figyelmet a termékeik hibajavításaira, hanem a kisebb és kevésbé ismert fejlesztőcégek is egyre gyakrabban működnek együtt az ICS-CERT-tel és a hibákat felfedező kutatókkal.

Az OT mérnököknek egy dologban azonban igazuk van: egy ICS rendszer esetén a hibajavítás sokkal nagyobb körültekintést igényel, mint egy mégoly fontos vállalati IT rendszeré. Ehhez próbálok a mai posztban egy rövid útmutatót adni (ami nyilván nem az egyetlen és nem is a tökéletes ICS patch menedzsment eljárás, de talán alapnak jó lehet, ha valaki a saját eljárását kell, hogy kialakítsa).

Ahogy az IT és az ICS rendszerek és folyamatok esetén sokszor, az ICS patch menedzsment esetében is ciklikus körforgásról beszélhetünk, aminek ebben az esetben 6 fázisa van.

1. Eszközök és fontosabb szoftverek azonosítása: Az ICS biztonság egyik alappillére, hogy naprakész nyilvántartással rendelkezzünk az alkalmazott eszközeinkről és a rajtuk futó fontosabb szoftver verziókról. Ez egy meglehetősen összetett, idő- és energiaigényes feladat tud lenni, de jelentősen segít az ICS rendszerek biztonsági szintjének növelésében, méghozzá anélkül, hogy a változások emelnék az ICS rendszerek üzembiztonsági kockázatait.

2. Az elérhető patch-ek ellenőrzése: Ha már tudjuk, pontosan milyen eszközeinken milyen verziókat használunk, ellenőrizni lehet, hogy milyen frissítések és hibajavítások érhetőek el a gyártónál.

3. Az elérhető patch-ek alkalmazhatóságának ellenőrzése: Mivel nem minden, a gyártó által kiadott frissítést lehet alkalmazni (pl. a rendszerünkben meglévő egyedi módosítások miatt), minden esetben külön ellenőrizni kell, hogy az adott patch-et lehet-e és szabad-e telepíteni. Ide tartozik a gyártó által kiadott, a telepítést kifejezett engedélyező nyilatkozat, ami nélkül súlyosabb esetben akár a gyártói garanciát is elveszíthetjük az adott rendszeren (gyakran éppen ettől tartva tiltakoznak az OT-s mérnök kollégák a hibajavítások telepítése ellen).

4. A patch-ek beszerzése: Az ICS világban a patch-ek beszerzése nem mindig olyan egyszerű, mint amihez az IT világban hozzá lehetett szokni az elmúlt évtizedekben. Számos esetben a gyártók még az elérhetővé tett patch-ek hash-eit sem adják közre, így pedig nehezebb ellenőrizni, hogy valóban a gyártó által kiadott javítást töltöttük-e le.

5. A letöltött patch-ek tesztelése és ellenőrzése: Ahogy a 4. pontban is írtam, mindenképp meg kell győződni arról, hogy a letöltött patch-ek valóban azokat a változásokat hozzák a rendszerbe, amire számítunk, ugyanakkor még ha a gyártó által kiadott eredeti patch-et is töltöttük le, akkor sem garantálható, hogy a telepítés nem fog valamilyen nem várt változást okozni az ICS rendszerünkben. Mivel minden ICS rendszer egyedi, ezért minden körülmények között célszerű labor körülmények között tesztelni a patch telepítésének hatásait és hogy a telepítéssel járó változások magukkal hoznak-e további legitim változási igényeket (pl. tűzfal szabályok módosításait, változásokat a végpont védelmi szoftver kivétel listájában, stb.).

6. Telepítés: Az 5. pontban leírt tesztelési és ellenőrzési folyamat során el kell készíteni az éles (és ha van, tartalék) környezetben használható telepítő csomagot, ami tartalmazza a telepítési leírást és azoknak az eszközöknek a listáját is, amikre a telepítő csomagot telepíteni kell.

 Ahogy már írtam a poszt elején, ezek a lépések nyilván nem adnak egy teljes útmutatót az ICS rendszerek patch-eléséhez, de nem is ez volt a célom. Ha azonban csak egy kollégának is tudok segíteni az elindulásban, már megérte megírni ezt a posztot.

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.