2017 júniusában egy magát csak “C10H15N1”-nek nevezett személy egy érdekes (és egyáltalán meg nem erősített) incidensről számolt be, ami egy petrolkémiai cég termelésirányító rendszerét ért zsarolóvírus támadás hátterét mutatta be.

A teljes történetet a hackread.com oldalán lehet elolvasni, a történet lényege (ismét) annyi, hogy az ICS rendszerek esetén szigorúan be kell tartani a hálózati szegmentálásra vonatkozó ajánlásokat (ahogy arról korábban a Biztonságos ICS architektúra modell című posztban korábban már írtam), a konkrét esetben pedig az üzembe vásárolt "okos" kávéfőzőket a belső szabályozással ellentétben (ami előírta, hogy az IoT kávéfőzőket a saját, megfelelően szeparált WiFi-hálozatukra kell csatlakoztatni) a termelésirányító rendszer belső hálózatára csatlakoztatták - de "természetesen" a megfelelő működésükhöz szükséges Internet-csatlakozással.

Ahogy napjainkban mindenkinek tudomásul kell vennie, hogy az Internet egyre több veszélyt rejt, úgy kell felismerni annak a szükségszerűségét, hogy a már kidolgozott ajánlások és jó gyakorlatok mentén, a megfelelő tervezéssel, kivitelezéssel és fegyelmezett, biztonságtudatos üzemeltetői és felhasználói viselkedéssel az ICS rendszerek döntő többségét meg lehet védeni a támadásoktól. Ehhez azonban első lépésként el kell ismerni, hogy az ICS rendszerek elleni támadások lehetősége valós kockázat.

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

Egy névtelenségbe burkolózó biztonsági kutató a ZDI-vel együttműködve jelentett egy puffer-túlcsordulást okozó hibát, ami a Delta Electronics alábbi termékeit érinti:

- a COMMGR kommunikációs menedzsment szoftver 1.08 és korábbi verziói, amiket a következő PLC szimulátorokban használnak:
- DVPSimulator EH2, EH3, ES2, SE, SS2;
- AHSIM_5x0, AHSIM_5x1.

A gyártó a hibát a COMMGR 1.09-es verziójában javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-172-01

Sérülékenység Rockwell Automation Allen-Bradley termékekben

Alexey Perepechko, az Applied Risk munkatársa egy, a bevitt adatok nem megfelelő ellenőrzéséből adódó hibát jelentett a gyártónak, ami az alábbi termékeiket érintik:

- Allen-Bradley CompactLogix 5370 L1 vezérlők 30.012 és korábbi verziói;
- Allen-Bradley CompactLogix 5370 L2 vezérlők 30.012 és korábbi verziói;
- Allen-Bradley CompactLogix 5370 L3 vezérlők 30.012 és korábbi verziói;
- Allen-Bradley Armor CompactLogix 5370 L3 vezérlők 30.012 és korábbi verziói;
- Allen-Bradley Compact GuardLogix 5370 vezérlők 30.012 és korábbi verziói;
- Allen-Bradley Armor Compact GuardLogix 5370 vezérlők 30.012 és korábbi verziói.

A gyártó a hibát a 31.011 és későbbi firmware-revíziókban javította. A sérülékenység részleteit az ICS-CERT publikációjában lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-172-02

Sérülékenység Siemens rendszerekben

A Siemens ProductCERT bejelentése szerint Chris Bellows és HD Moore, az Atredis Partners munkatársai, valamint Austin Scott, a San Diego-i Gáz- és Elektromos Művek munkatársa egy sérülékenységet azonosítottak a Siemens alábbi termékeiben:

- az IEC 61850 rendszer konfigurátor szoftver V5.80-nál korábbi verziói;
- a DIGSI 5 V7.80-nál korábbi verziói;
- a DIGSI 4 minden verziója;
- a SICAM PAS/PQS V8.11-nél korábbi összes verziója;
- a SICAM PQ Analyzer V3.11-nél korábbi összes verziója és
- a SICAM SCC minden verziója.

A gyártó a hibával kapcsolatban 4 érintett termékhez adott ki javítást (az IEC 61850 rendszer konfigurátor szoftverhez, a DIGSI 5, SICAM PAS/PQS és SICAM PQ Analyzer berendezésekhez), két termékhez (DIGSI 4 és SICAM SCC) csak kockázatcsökkentő intézkedésekre tett javaslatot a Siemens. A sérülékenységről további részleteket a Siemens ProductCERT bejelentésében lehet olvasni.

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 mindennapi életben számos olyan terület van, ahol kevesen keresnék az informatikai vagy ipari informatikai eszközöket - ilyen lehet sok egyéb mellett egy benzinkút is, azonban nemrég több olyan cikket is találtam, ahol ezek ellenkezője bizonyosodott be.

HD Moore, a Rapid7 kutatója még 2015-ben kezdett ezzel a témával foglalkozni, végül több, mint 5000 Internetre kötött benzinkúti eszközt (automatizált töltőállomási mérőórákat, ATG-ket) talált és több súlyos sérülékenységet is felfedezett különböző gyártók termékeiben. Még súlyosabb az eset amiatt, mert olyan benzinkutakat is érintenek ezek az esetek, amik a PCI-DSS hatálya alá tartoznak, mégsem tudott senki ezekről a sérülékenységekről - nagyon jól megmutatva, hogy az ipari folyamatvezérlő rendszerek IT és IT biztonsági szabványok alapján történő auditálása minden további nélkül képes lehet átsiklani az ICS berendezések és rendszerek hibáin és hiányosságain.

Egy másik hír Oroszországból arról számolt be, hogy a Szövetségi Biztonsági Szolgálat (FSZB) egy dél-oroszországi bűnbandát számolt fel, aminek tagjai a benzinkutak szoftvereit egy olyan saját verzióra cserélték, amivel meghamisították a járművekbe töltött üzemanyagok mennyiségét, a kiszámlázottnál kevesebb üzemanyagot tankolva. Egy tankolásnál átlagosan 3-7%-nyi üzemanyagot csaltak el a vásárlóktól, ilyen módon több száz millió orosz rubeles bevételre tettek szert.

Mit lehet tenni az ilyen esetek megelőzésére vagy ha a megelőzés nem sikeres, akkor az incidensek mielőbbi észlelése érdekében? Nagyjából a szakmában és itt a blogon is már számos alkalommal említett biztonsági intézkedéseket célszerű bevezetni:

- ICS rendszereket és berendezéseket soha, semmilyen körülmények között ne csatlakoztassunk közvetlenül publikus hálózatokra!
- Alakítsunk ki mélységi védelmet az ICS rendszerek hálózataiban!
- Az ICS rendszerek fejlesztőinek, üzemeltetőinek és felhasználóinak biztonságtudatossági képzése az egyik legfontosabb terület - de ezek mellett ne feledkezzünk meg az IT biztonsági szakemberek továbbképzéséről sem, ennek legyen része az ipari folyamatok és az ICS rendszerek alaposabb megismerése. Enélkül nem várható el, hogy az általuk javasolt biztonsági intézkedések a lehető legkisebb mértékben legyenek negatív hatással a folyamatvezérlő rendszerek megbízható működésére!

Az ICS-CERT az elmúlt héten több ICS rendszerekkel kapcsolatos sérülékenységet publikált, ezek közül (az egyes gyártók bejelentései alapján) a Schneider Electric U.motion Builder és több Siemens termék sérülékenységeiről az előző hetekben már én is beszámoltam.

A Natus Xltek NeuroWorks EEG rendszerének 8-as verzióját érintő hibákat (összesen 8 különböző sérülékenységről van szó, többnyire puffer-túlcsordulásokról és memóriakezelési hibákról) Cory Duplantis, a Cisco Talos munkatársa fedezte fel. A gyártó a hibákat a euroWorks/SleepWorks 8.5 GMA 3 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://ics-cert.us-cert.gov/advisories/ICSMA-18-165-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 Kaspersky Lab világszinten is az egyik legjelentősebb, ICS biztonsággal is foglalkozó IT biztonsági cég. 2017-ben ötödik alkalommal rendezték meg Szentpéterváron az ICS kiberbiztonságra koncentráló konferenciájukat. Jelenleg erről a konferenciáról sajnos csak az Interneten elérhető információk állnak rendelkezésemre, ezek alapján viszont nagyon úgy látszik, hogy a szeptember közepén tartott rendezvény talán a legnagyobb ilyen tematikájú konferencia Kelet-Európában. Érthetően az előadók és panel beszélgetéseken résztvevők többsége orosz, de rajtuk kívül több amerikai és ázsiai szakértő előadását is meg lehet nézni - akár utólag is, mert a három napos rendezvény második és harmadik napjainak előadásairól mind a prezentációk (PDF-formátumban), mind videófelvételek (a YouTube-on) elérhetőek!

A konferenciáról bővebb információkat ezen a weboldalon lehet olvasni: https://ics.kaspersky.com/conference/

Az oldal legalján pedig megtalálhatóak a tavaly szeptemberi rendezvény előadásainak anyagai.

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.