Karn Ganeshen, az egyik legtermékenyebb ICS sérülékenységekre vadászó biztonsági kutató a brazil LCDA (Leao Consultoria e Desenvolvimento de Sistemas LTDA ME) SCADA rendszerében talált egy nem megfelelő hozzáférés-vezérlésből eredő hibát. A sérülékenység a LAquis SCADA 4.1 és minden, 2017. január 20-a előtt megjelent verzióját érinti.

A gyártó a hiba javítását elérhetővé tette a weboldalán: http://laquisscada.com/instale1.php

A sérülékenységről további részleteket ezúttal is az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-075-01

Az ICS-CERT szokásos módon ezúttal is a 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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az ICS-CERT tegnapi publikációja szerint az alábbi Fatek Automation PLC-kben használt Ether_cfg szoftverkonfigurációs eszközben puffer túlcsordulási hibát fedezett fel egy meg nem nevezett biztonsági kutató:

- CBEH V3.6 Build 170215-nél korábbi verziók;
- CBE V3.6 Build 170215-nél korábbi verziók;
- CM55E V3.6 Build 170215-nél korábbi verziók;
- CM25E V3.6 Build 170215-nél korábbi verziók.

A gyártó a hibát az Ether_cfg szoftverkonfigurációs eszköz új verziójában javította, amit a weboldaláról lehet letölteni: http://www.fatek.com/en/technical.php?act=software&catId=12

A sérülékenységgel kapcsolat további információkat a Fatek Automation és az ICS-CERT publikációi tartalmaznak.

A fenti sérülékenység és általában az ICS 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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az elmúlt néhány napban több Schneider Electric termékkel kapcsolatban jelentek meg friss sérülékenységi információk.

Schneider Electric Wonderware Intelligence sérülékenység

A Schneider Electric házon belül talált egy, a felhasználói adatok kezelésével kapcsolatos hibát a Wonderware Intelligence 2014R3 és korábbi verzióiba beágyazottan használt Tableau Server/Desktop szoftver 7.0-tól 10.1.3-ig terjedő verzióiban. A hibát kihasználva egy támadó adminisztrátori szintű jogosultságot szerezhet a sérülékeny rendszereken.

A gyártó a hibát az alább felsorolt verziókban javította:

Tableau Analytics Dashboard Server v10.1.4
Tableau Analytics Client v10.1.4
Wonderware Intelligence 2014 R3

A sérülékenységről további információkat a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

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

Sergey Temnikov és Vladimir Dashchenko, a Kapersky Lab Critical Infrastructure Defense Team-jének munkatársai fedeztek fel egy sérülékenységet a Schneider Electric ClearSCADA termékének alábbi verzióiban:

- ClearSCADA 2014 R1 (build 75.5210) és minden korábbi verziója;
- ClearSCADA 2014 R1.1 (build 75.5387) és minden korábbi verziója;
- ClearSCADA 2015 R1 (build 76.5648) és minden korábbi verziója;
- ClearSCADA 2015 R2 (build 77.5882) és minden korábbi verziója.

A hiba lehetővé teszi, hogy a sérülékeny rendszerek a bevitt adatokat bármilyen ellenőrzés nélkül dolgozzák fel, ezzel lehetővé válik egy támadó számára, hogy megzavarja vagy akár meg is szakítsa a sérülékeny rendszer üzemszerű működését.

A gyártó a hibát az alábbi verziókban javította:

- ClearSCADA 2014 R1.1 hotfix build 75.6239
- ClearSCADA 2015 R1.1 Service Pack (build 76.6191)
- ClearSCADA 2015 R2 hotfix build 77.6181

A ClearSCADA 2013R2 és ennél korábbi verzióit futtató felhasználók számára a Schneider Electric azt javasolja, hogy frissítsenek a ClearSCADA 2015R2 verzióra a hiba javítása érdekében.

A hibajavítás alkalmazása mellett a gyártó az alábbi kockázatcsökkentő intézkedések alkalmazását is javasolja a ClearSCADA termékcsaládot használó ügyfeleinek:

- Gondoskodjanak a ClearSCADA rendszerek és hálózati interfészeik fizikai biztonságáról;
- Megfelelően konfigurált tűzfalak alkalmazásával korlátozzák az egyes hálózati szegmensek közötti forgalmat a feltétlenül szükséges portokra és protokollokra;
- Minden külső hozzáférés esetén használjanak VPN-megoldást;
- A felhazsnálói biztonsági beállítások használatával és rendszeres auditálásával csökkentsék a DoS-támadások kockázatait;
- A ClearSCADA rendszerek kulcsfelhasználói fiókjainál a megfelelő biztonsági szabályok konfigurálásával tegyék minél nehezebbé a jogosulatlan bejelentkezéseket.

A sérülékenységről bővebb információkat a Schneider Electric és az ICS-CERT bejelentéseiben lehet olvasni.

A fenti sérülékenységekkel kapcsolatban az ICS-CERT ezúttal is az általános kockázatcsökkentési intézkedések alkalmazására hívja fel a figyelmet:

- 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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az elmúlt bő egy évben már többször írtam már a SCADA Strangelove csoport munkáiról. A SCADA Strangelove egy orosz kutatókból álló csoport, ami elsősorban a különböző ICS/SCADA rendszerek biztonságát vizsgálja. Összesen 29-en vannak, név szerint:

- Alexander Timorin
- Alexander Tlyapov
- Alexander Zaitsev
- Alexey Osipov
- Andrey Medov
- Artem Chaykin
- Denis Baranov
- Dmitry Efanov
- Dmitry Nagibin
- Dmitry Serebryannikov
- Dmitry Sklyarov
- Evgeny Ermakov
- Gleb Gritsai
- Ilya Karpov
- Ivan Poliyanchuk
- Kirill Nesterov
- Roman Ilin
- Roman Polushin
- Sergey Bobrov
- Sergey Drozdov
- Sergey Gordeychik
- Sergey Scherbel
- Sergey Sidorov
- Timur Yunusov
- Valentin Shilnenkov
- Vladimir Kochetkov
- Vyacheslav Egoshin
- Yuri Goltsev
- Yuriy Dyachenko

Céljuk, saját bevallásuk szerint az, hogy megmentsék az emberiséget az ipari katasztrófáktól és (az ő szóhasználatukkal "megőrizzék a lényeg tisztaságát"). Elmondásuk szerint a Stuxnet nyilvánosságra kerülése után kezdtek foglalkozni az ICS rendszerek biztonságával és elég gyorsan felmérték, hogy az ICS rendszerek már az élet minden területén jelen vannak. További megállapításaik:

- Jellemzően régi technológiát képviselnek, a klasszikus vagy modern biztonsági alapelvek bármilyen alkalmazása nélkül;
- Az ICS rendszerek (elvileg) izolált hálózatokban működnek, de idővel mindig kiderül, hogy ezek a hálózatok más hálózatokhoz vannak csatlakoztatva, ezek a "más hálózatok" pedig már gyakran rendelkeznek Internet-kapcsolattal is;
- Ma már több, nyilvánosan elérhető eszköz (Shodan és Censys keresők, zmap, masscan) érhető el az Internetre csatlakoztatott ICS rendszerek felderítésére
- Az ICS rendszereket üzemeltető mérnökök a mai napig azzal érvelnek, hogy "Ez már nagyon régen így működik - ne nyúlj hozzá!";
- A valóság azonban az, hogy a támadók igenis képesek és készek hozzányúlni az ICS rendszerekhez;
- A SCADA Strangelove alapítóit ezek a tények aggodalommal töltötték el;
- Nem voltak hajlandóak elfogadni a korábbi megközelítéseket, így  hát elhatározták, hogy változtatnak a helyzeten - és 2012-ben, 4 taggal megszületett a SCADA Strangelove.

2013 és 2016 között jelentős fejlődésen ment át a csapat, a taglétszám 30 fő fölé nőtt, több, mint 100 0. napi sérülékenységet azonosítottak a legkülönbözőbb iparágakban (közlekedéstől a megújuló energia-rendszerekig) használt ICS rendszerekben. A feltárt hibák között voltak memóriakezeléssel kapcsolatos, webes, ipari protokollokat érintő hibák, backdoor-ok, hibás kriptográfiai modulok és beégetett gyári jelszavak is. A felfedezett sérülékenységek egyetlen nagyobb ICS gyártók termékeit sem kímélték - SCADA szerverek és kliensek, PLC-k, HMI-ok és MMI-ok, RTU, védelmi relék, konverterek, okosmérők, ipari switch-ek és GSM/GPRS-modemek egyaránt voltak a SCADA Strangelove által vizsgált és sérülékenynek talált ipari eszközök között.

A SCADA Strangelove tagjai különböző cégeknél dolgoznak és megvannak a saját projektjeik, de a csapatnak vannak hosszú távú projektjei is, ilyenek a SCADAPASS és a SCADASOS.

SCADAPASS

A SCADAPASS a különböző ICS eszközök gyári, beégetett jelszavainak gyűjtésére fókuszáló projekt. Legutóbb 2015. december 27-én tették közzé a gyűjtemény utolsó verzióját (erről egyébként anno én is hírt adtam, mindmáig ez a poszt a legolvasottabb a blogon)

SCADASOS

A SCADASOS ((in)Secure Open SmartGrids) projekt célja, hogy minél nagyobb mértékben csökkentse az olyan SmartGrid eszközök számát, amik Internet-kapcsolattal rendelkeznek. Az elmúlt években több, mint 80.000-rel csökkent azoknak az eszközöknek a száma, amiket az Internetről el lehet érni. Ez azonban még mindig csak csepp a tengerben, hiszen újabb és újabb gyártók és ICS rendszerek kerülnek elő, ahol nem csak a rendszert telepítő és üzemeltető szakemberek tudatlansága vagy nemtörődömsége, de adott esetben a gyártó ajánlása is ahhoz vezet, hogy az ICS rendszert vagy egyes komponenseit az Internetre csatlakoztassák (igen jó példa erre a december elején az ICS-CERT által publikált Locus Energy berendezések sérülékenységéről szóló bejegyzés is).

A SCADASOS projekt célja a SmartGrid, valamint a fotovoltalikus (napenergia) és szélerőmű-farmok kiberbiztonsági helyzetének javítása.

A SCADA Strangelove-ról további információkat a weboldalukon lehet megtudni.

Sérülékenység az Eaton xComfort Ethernet Communication Interface-ben

Maxim Rupp, az egyik legismertebb ICS biztonsági kutató az ICS-CERT bejelentése szerint egy hozzáférés-kezelési hibát fedezett fel az Eaton xComfort ECI 1.07-es és korábbi verzióiban. A hibát kihasználva egy támadó a megfelelő URL-en authentikáció nélkül férhető hozzá a sérülékeny rendszerek fájljaihoz.

A gyártó a sérülékeny verziót használói ügyfelei számára azt javasolja, hogy frissítsenek a legújabb verzióra, amiben a hibát már javították.

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-17-061-01

Schneider Electric Conext ComBox sérülékenység

Arik Kublanov és Mark Liapustin, a Nation-E Ltd. munkatársai a Schneider Electric Conext ComBox, model 865-1058-as eszközein használt V3.03 BN 830-nál korábbi firmware-verzióiban találtak hibát, amit kihasználva a sérülékeny eszközök túlterhelhetőek, aminek hatására újraindulhatnak.

A gyártó a hiba javítását a V3.03 BN 830-as firmware-ben már elérhetővé tette.

A sérülékenységről további információkat az ICS-CERT bejelentésében és a Schneider Electric publikációjában lehet olvasni.

A fenti hibákkal kapcsolatban az ICS-CERT ezúttal is az általános kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Ez a poszt a 2016.12.31-én megjelent, Egészségügyi folyamatvezérlő rendszerek kiberbiztonsága című írásom második része.

2013-14 során az FDA útmutatókat jelentetett meg az egészségügyi rendszerek biztonságával kapcsolatban, a végleges útmutató végül 2014 októberben vált elérhetővé. Az FDA útmutatója elsősorban az egészségügyi folyamatvezérlő eszközök biztonsági funkcióonak tervezési és fejlesztési fázisban történő alkalmazását hangsúlyozza. Részletesen az alábbi intézkedéseket nevesítik (nem meglepő módon ezek sokszor egybevágnak az ICS rendszerek biztonsága kapcsán már megismert intézkedésekkel):

- Eszközök, fenyegetések és sérülékenységek azonosítása;
- Az egészségügyi eszközök funkcionalitását és/vagy a pácienseket/végfelhasználókat érintő fenyegetések és sérülékenységek értékelése;
- A fenyegetések és a sérülékenységek kihasználásának valószínűségeinek értékelése;
- A kockázati szintek és a megfelelő kockázatcsökkentési stratégiák meghatározása;
- A maradványkockázatok és a kockázat elfogadási feltételek értékelése.

Az egészségügyi rendszerek biztonsági helyzete a jelenben

Napjainkra már megkezdődött az a folyamat, aminek során biztonsági szakértők bevonásával és egy átfogó megközelítés alkalmazásával probálják javítani az egészségügyi eszközök biztonsági szintjét. A problémák sokrétűek, hardver és szoftverhibák, a rádiós kommunikációs csatornák elleni támadások, malware-ek és a különböző sérülékenységek kihasználása egyaránt ide tartoznak. Egy, a témában 2014-ben készített felmérés az mutatta ki, hogy az egészségügyi eszközök biztonságával kapcsolatos fejlesztések elsősorban a telemetriai interfészek elleni támadásokra koncentráltak. Ezek a telemetriai interfészek döntő részben a rádiós kommunikációhoz kapcsolódnak. A felmérésből tisztán látszik, hogy a vezeték nélküli telemetriai adatforgalmazásnak öt fontos területe van: a biometrikus authentikáció, a rádióhullámokon keresztül távolról végrehajtott authentikáció, a többfaktoros authentikáció, a külső eszközök és az anomáliák észlelése.

Az egészségügyi rendszerek jövője

A ma hozott intézkedések nagy mértékben meghatározzák az egészségügyi rendszerek biztonságának jövőjét is. A biztonság mindig a kompromisszumokról szól és a tét az egészségügyi rendszerek esetén az egyik legnagyobb. Azonban így sem szabad hagyni, hogy az egészségügyi eszközök biztonságával kapcsolatos esetekből szenzációt kreáljanak, ehelyett józan, racionális és szisztematikus megközelítéssel meg kell érteni és csökkenteni kell a biztonsági kockázatokat. Az FDA javaslatai az NIST kiberbiztonsági keretrendszere alapján a következők:

- Azonosítani kell a védelemre szoruló folyamatokat és eszközöket;
- Definiálni kell az elérhető védelmi intézkedéseket;
- Incidens-felismerési technikákat kell kidolgozni;
- Intézkedési terveket kell kialakítani az incidensek kezelésére;
- Formalizált helyreállítási tervet kell készíteni.

Az egészségügyi rendszerekre leselkedő fenyegetések kiemelkedőek és az elkerülhetetlennek látszó nulladik napi támadásokkal is az egészségügyi eszközök teljes életciklusa alatt foglalkozni kell. Ez egy olyan feladat, amin az egészségügyi szolgáltatóknak, az eszközök gyártóinak, a szoftverek fejlesztőinek és a biztonsági szakembereknek együttműködve kell dolgozniuk - gyakran a páciensek bevonásával.

A Siemens ProductCERT tegnapi bejelentése szerint a SINUMERIK termékcsalád alábbi tagjaiban Man-in-The-Middle támadást lehetővé tevő hibát fedeztek fel:

- A SINUMERIK Integrate Access MyMachine/Ethernet AMM  Service  Engineer  Client  (ActiveX)-szel használt összes verziója;
- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Integrate  Operate Client-tel használt verziói 2.0.3.00.016-tól a 2.0.6 előtti verzióig;
- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Integrate  Operate Client-tel használt verziói 3.0.4.00.032-tól a 3.0.6 előtti verzióig;

A hiba által érintett SINUMERIK Integrate Operate kliensek:
- V4.5 SP6-tól a V4.5  SP6  Hotfix  8 előtti verzióig;
- V4.7 SP2 Hotfix 1-től a V4.7  SP4 előtti verzióig.

A hibát a Siemens az érintett szoftverek alábbi verzióiban javította:

- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Operate V4.7 SP4 vagy SINUMERIK Integrate Operate Client V3.0.6;
- SINUMERIK Operate V4.5 SP6 Hotfix 8 vagy SINUMERIK Integrate Operate Client V2.0.6;
- A SINUMERIK Integrate Access MyMachine/Ethernet AMM  Service  Engineer  Client  (ActiveX)-szel használt szoftvereket az AMM  Service Client V4.1.0.5-tel javasolják kiváltani.

A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT publikációjában lehet olvasni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-934525.pdf

Az elmúlt hét ismét elég erős termést hozott az ICS rendszerek sérülékenységei terén.

Siemens RuggedCom NMS webes sérülékenységek

A Siemens ProductCERT bejelentése alapján a RuggedCom NMS rendszer V2.1-nél korábbi minden (Windows-on és Linux-on futó) verziója tartalmaz egy-egy CSRF és XSS sérülékenységet.

A gyártó a hibákat a V2.1-es NMS verzióban javította és az új verzió telepítése mellett a weboldalán elérhető üzemeltetési útmutatóban leírtak alkalmazását javasolja.

A hibákkal kapcsolatban további információkat a Siemens ProductCERT bejelentése tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-363881.pdf

VIPA Controls WinPLC7 sérülékenység

A TrendMicro-hoz tartozó ZDI kutatója, Ariele Caltabiano (kimiya) egy puffer túlcsordulásos hibát talált a VIPA Controls nevű ICS gyártó WinPLC7 termékének 5.0.45.5921 és ennél korábbi verzióiban. A gyártó közzétett a hibával kapcsolatban egy javítást, ami innen tölthető le.

A sérülékenységről további információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-054-01

Red Lion Controls termékek sérülékenységei

Mark Cross, a RIoT Solutions munkatársa beégetett titkosítási kulcsokat fedezett fel a Red Lion Controls alábbi termékeiben:

- Sixnet-Managed Industrial Switches, ha 5.0.196 vagy korábbi firmware-verziókat futtatnak;
- Az AutomationDirect által forgalmazott, de Red Lion Controls által gyártott Stride-Managed Ethernet Switches, ha 5.0.190 vagy korábbi firmware-verziókat futtatnak.

A gyártó a hibák javítására kiadta az SLX nevű firmware 5.3.174-es verzióját, amit innen lehet letölteni. Az AutomationDirect a Stride-Managed Ethernet Switches-hez használható firmware bináris itt érhető el: http://support.automationdirect.com/firmware/binaries.html

A hibával kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-054-02

Schneider Electric Modicon M340 PLC sérülékenység

Luis Francisco Martin Liras jelentette a Schneider Electric-nek azt a hibát, amit a Modicon M340 PLC-család alábbi tagjainak 2.9-esnél korábbi firmware-verzióiban talált:

- BMXNOC0401;
- BMXNOE0100;
- BMXNOE0110;
- BMXNOE0110H;
- BMXNOR0200H;
- BMXP341000;
- BMXP342000;
- BMXP3420102;
- BMXP3420102CL;
- BMXP342020;
- BMXP342020H;
- BMXP342030;
- BMXP3420302;
- BMXP3420302H;
- BMXP342030H.

A hibát kihasználva egy támadó megfelelően kialakított hálózati csomagokkal képes lehet a PLC-ket lefagyasztani, ami után csak a fizikai újraindítással lehet ismét használható állapotba hozni az érintett berendezéseket.

A gyártó a hiba hatását csökkentő új (2.9-es) firmware-verziót elérhetővé tette a weboldalán: http://www.schneider-electric.com/en/download/document/BMXP342000_V29/

A hibával kapcsolatban részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-054-03

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A különböző folyamatvezérlő rendszerek között külön csoportot képeznek az egészségügyben használt vezérlőrendszerek. Már a ’80-as években elterjedtek a különböző, szoftverekkel vezérelt, félig-meddig automatizáltan működő orvosi berendezések, például a terápiás röntgentgépek, inzulin és egyéb gyógyszeradagoló pumpák.

Ezek a rendszerek meglehetősen hosszú múltra tekintenek vissza és bizony számos súlyos incidensről is tudunk. Az 1980-as és 90-es években több súlyos, nem egy esetben halálesettel végződő incidens is történt (részletesebben a LEMIL blog General Protection Fault című sorozatának második részében lehet ezekről olvasni). Persze ezek az incidensek jellemzően tervezési/fejlesztési hibákra voltak visszavezethetőek, mert ekkor (még) senkinek nem jutott eszébe a különböző számítógép-vezérelte orvosi eszközöket Internetre vagy vezeték nélküli hálózatokra csatlakoztatni. Aztán ahogy az évek változtak, az Internet és a különböző vezeték nélküli kommunikációs megoldások egyre kényelmesebbé tették a mindennapi életet, elkezdték ezeket a technológiákat az ICS rendszerek mellett az egészségügyi folyamatvezérlők esetén is használni. Ezzel párhuzamosan megjelentek az implantálható egészségügyi folyamatvezérlő rendszerek is, például szívritmus-szabályozók, kisméretű inzulin-pumpák, stb. Ez a két technológiai fejleszts aztán azt eredményezte, hogy gyorsan elterjedtek a pánciensek testébe beépített, vezeték nélküli kommunikációt használó egészségügyi folyamatvezérlő rendszerek. Ez persze valahol érthető, hiszen mennyivel jobb és egyszerűbb mind az orvos, mind a páciens szempontjából, ha pl. a beépített szívritmus-szabályozóról WiFi-n keresztül tudja az orvos letölteni az összes fontos diagnosztikai adatot, mint ha ehhez mindenféle kábeleket kell csatlakoztatni a beteg testébe beépített gépre? Kényelmesnek természetesen kényelmes, azonban ha a fejlesztők nem foglalkoztak kellően alapos (vagy bármilyen) authentikációs eljárás leprogramozásával, akkor már közel sem ilyen jó a helyzet, hiszen ki tudja garantálni, hogy egy vezeték nélküli hálózaton csak azok az orvosok/kórházi alkalmazottak fognak gyengén védett eszközöket keresni, akik a pánciens gyógyulását akarják?

Azt, hogy ez a feltételezés mennyire nem légből kapott és paranoid gondolat, már a 2000-es évek közepén bemutatták biztonsági kutatók, amikor az implantálható egészségügyi eszközök szoftveres hibajavításaival kapcsolatos kutatások során azt találták, hogy ezek az eszközök különösen érzékenyek man-in-the-middle támadásokkal szemben.

2008-ban biztonsági kutatók egy ICD eszközben (Implantable Cardiatic Defibrillator - implantálható defibrillátor) olyan sérülékenységeket találtak, amelyeket kihasználva nem csak lehallgatható volt az ICD eszköz kommunikációja, de akár a defibrillátort arra is lehetett utasítani, hogy sokkolja a páciens szívét.

Szintén 2008-ban az USA legfelsőbb bírósága olyan ítéletet hozott, amely szerint az FDA (az USA Szövetségi Gyógyszer és Élelmiszerfelügyeleti Hatósága) által engedélyezett implantálható egészségügyi rendszerek által okozott károk esetén a gyártóknak csak korlátozott felelősségük van.

2011-ben számos implantálható inzulin-pumpával kapcsolatban jelentek meg biztonsági sérülékenységi információk, a legnagyobb nyilvánosságot kapott esetek Jerome Radcliffe Black Hat 2011-en, illetve Barnaby Jack Hacker Halted-on tartott előadásai voltak. Mindketten olyan kutatásokról számoltak be, amelyek során képesek voltak az implantálható inzulin-pumpák vezeték nélküli kommunikációs funkcióján keresztül az eszközök jogosultsági rendszerét megkerülve olyan műveletek végrehajtására utasítani az eszközöket, amik akár a pánciens halálához is vezethetnek.

2012 októberében, a melbourne-i Ruxcon Breakpoint biztonsági konferencián megint Barnaby Jack adott elő az implantálható egészségügyi rendszerek biztonságáról, ekkor az általa vizsgált pacemaker-ekben talált hibákról számolt be. Olyan hibákat is bemutatott, amikkel akár halálos mértékű áramütésre is képes lett volna utasítani egy szívbeteg páciensbe beültetett pacemaker-t - ismét csak az eszköz vezeték nélküli kommunikáció segítségével. Barnaby Jack a következő évben, a 2013-as Black Hat-re készülve, 35 éves korában halt meg kábítószer és gyógyszer túladagolásban San Francisco-ban.

A poszt második részében a 2013 után történt eseményeket, az egészségügyi rendszerek jelenét és jövőjét fogom áttekinteni.

Az elmúlt 1-2 évben új fogalmak jelentek meg az iparban: a negyedik ipari forradalomról vagy az ipari dolgok Internetéről (Industrial Internet of Things, IIoT) egyre gyakrabban lehet olvasni és hallani. Ahogy a konzumer IoT eszközök megváltoztatták a mindennapi életünket, úgy változtatják meg az IIoT rendszerek az ipari környezetek mostanáig meglehetősen statikus világát. Ezek változások azonban új kockázatokat és fenyegetéseket is magukkal hoznak, amelyeket értékelni és szükség esetén csökkenteni kell. Annál is inkább így van ez, mert az üzleti és pénzügyi szakterületek többnyire az IIoT bevezetése alapján tapasztalható hatékonyságnövelés és költségcsökkentés lehetőségeit látják, azzal azonban már jóval kevésbé vannak tisztában, milyen problémákat okozhat az új technológiák és a különböző eszközök fokozott méretű összekapcsolása. Az IoT kiberbiztonsági problémáinak legjobb példája a 2016. október 21-i, DynDNS elleni DDoS-támadás, amit a nem megfelelően üzembe helyezett és kompromittált IoT eszközök százezreivel hajtottak végre. Ezek az eszközök (pl. vezeték nélküli CCTV rendszerek) is egyre jobban terjednek az ipari környezetekben, de ezeket még nem nevezhetjük IIoT-nek.

Az előrejelzések szerint az IIoT eszközök 2015-2020 között 228%-os növekedést fognak produkálni, 2030-ra pedig várhatóan a 2015-ös érték 15-szörösére fognak nőni. Ez a mértékű növekedés várhatóan azt is fogja jelenteni, hogy a fenyegetések száma is exponenciálisan fog nőni.

Az ipari rendszerek biztonsága ma

Az ipari szektorban már az Internet megjelenése és térnyerése, valamint a vállalati és ipari hálózatok egyre gyakoribb és egyre szorosabb összekapcsolása is sok évtizedes beidegződések és szokások megváltoztatását követelte. Ezek a változások sok helyen a mai napig nem vagy csak nehezen indultak meg - a különböző ICS kiberbiztonsági konferenciákon és előadásokon még mindig alapvető mondanivaló az IT és OT szakterületek közötti együttműködés javításának fontossága. Ahogy látható, a legtöbb szervezet még ezeknek a kihívásoknak sem képes megfelelni, most pedig az IIoT térnyerésével a kockázatok és fenyegetések egy újabb, még magasabb szintre fognak lépni.

2010-ig, a Stuxnet nyilvánosságra kerüléséig az ICS kiberbiztonság egy nagyon szűk és nagyon megválogatott kör témája volt, éppen ezért szinte senki más nem is tudott róla. Az elmúlt közel 7 évben a helyzet alapjaiban változott meg, nem utolsó sorban a különböző ICS rendszerek izoláltságának fokozatos megszűnése miatt és ez korábban nem látott növekedést hozott a kockázatok és fenyegetések terén az ICS rendszerek számára. Az IIoT megjelenésével ugyanez a folyamat játszódik le újra - az IIoT alkalmazásától remélt pozitív hatások mellett a biztonsági megfontolások legjobb esetben is csak másodlagosak a döntéshozók szemében. További probléma, hogy a különböző rendszerek fokozottabb összekapcsolása miatt korábban nem látott fenyegetések kerülnek egyre közelebb az ICS rendszerekhez is. Elég a tavaly november végén, San Francisco-ban történt incidenst említeni, amikor egy zsaroló vírus miatt a tömegközlekedési vállalatnak - annak ellenére, hogy az ICS rendszereikig nem ért el a malware - jelentős kieséseket okozott a támadás. Ráadásul a támadók motivációi is sokszínűek lehetnek, az állami háttérrel rendelkező (kvázi kiberháborús műveleteket végrehajtó) csoportok mellett az IoT és IIoT eszközöket tisztán pénzszerzési céllal támadó csoportok is kezdik felfedezni az ipari környezetek biztonsági hiányosságait.

Mi lehet a megoldás?

Annak érdekében, hogy az IIoT térnyerése ne rontsa tovább az ICS kiberbiztonság egyébként sem magas szintjét, két vonalon kell mielőbb fejlődést elérni. Ezek egyáltalán nem új gondolatok, az IT rendszereknél ezeket már több, mint egy évtizede ismerik és sok esetben használják is.  Egyrészt az IIoT fejlesztések során a rendszertervezési fázistól foglalkozni kell a kiberbiztonság kérdéseivel és a biztonságot a rendszer elválaszthatatlan részeként kell kezelni. Másrészt az elkészült rendzsereket a teljes életciklus során rendszeresen biztonsági teszteknek kell alávetni és a feltárt sérülékenységeket kezelni kell. Nem lehet elégszer kiemelni, hogy az ICS rendszerek életciklus az IT rendszerekénél sokkal hosszabb, gyakran akár 15-20 év is lehet, így az ICS fejlesztőknek sokkal hosszabb támogatási ciklusokkal kell számolniuk - az IIoT fejlesztőkre ez fokozottan igaz, hiszen amíg egy, a gyártó által már nem támogatott ICS rendszer esetén megfelelő kompenzáló kontroll lehet a rendszer minden elemének egy zárt és biztonságosnak tekintett hálózatba történő használata, az IIoT rendszereknél ez sokkal nehezebb - ha egyáltalán megvalósítható.

A tendenciákat figyelve csak idő kérdése, hogy a támadók (és a különböző exploit kit-eknek köszönhetően akár az egészen alacsony technikai tudású támadók is) célba vegyék az IIoT rendszereket. Az ipari rendszerek, folyamatok és elsősorban az emberek biztonságának biztosítása az üzemeltetők és fejlesztők felelőssége, ezért fontos, hogy az együttműködésük a biztonságosabb IIoT rendszerek kialakításáért minél előbb elkezdődjön.