2017 decemberben és 2018 januárban én is többször írtam a Triton/TriSIS (később Hatman) néven elhíresült malware-ről, ami egy Szaúd-arábiai olajipari vállalat safety (SIS) rendszere elleni támadáshoz használt kártékony kód. A héten a FireEye kutatói (ők adták a malware-nek a Triton nevet) újabb információkat hoztak nyilvánosságra, amelyek szerint a Triton/TriSIS malware mögött álló támadók (akikről a Dragos Xenotime név alatt már számos jellemző eszközt és technikát publikált) egy újabb kritikus infrastruktúra elleni támadásnál használták fel a Szaúd-Arábiában már látott malware-t.

A FireEye elemzése szerint a támadók a széles körben használt eszközök (pl. Mimikatz) mellett számos egyedi, saját fejlesztésű eszközt is használnak a támadások végrehajtása során, ezek funkcionalitásban nem nagyon különböznek a már ismert, hasonló eszközöktől, de az egyedi fejlesztés lehetővé teszi, hogy nagyobb eséllyel kerüljék el a kártékony kódok észlelését a hagyományos, mintaillesztéssel dolgozó biztonsági rendszerek esetén.

A támadók tevékenységét elemző kutatók úgy vélik, hogy a Triton/TriSIS mögött álló csoport 2014 óta lehet aktív, de a módszereik és eszközeik miatt képesek volt sokáig elkerülni, hogy felfedezzék a tevékenységüket, egészen addig, amíg Szaúd-Arábiában egy hiba következtében le nem állították az olajipari létesítmény egyes folyamatait.

Sérülékenység PHOENIX CONTACT rendszerekben

Maxim Rupp egy Command Injection sérülékenységet jelentett a PHOENIX CONTACT-nak, ami a gyártó alábbi rendszereit érinti:

- RAD-80211-XD (2885728);
- RAD-80211-XD/HP-BUS (2900047).

A gyártó a sérülékenységgel kapcsolatban az érintett termékek támogatásának korábbi megszünése miatt kockázatcsökkentő intézkedéseket javasol. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-085-02

ENTTEC rendszerek sérülékenysége

Ankit Anubhav, a NewSky Security munkatársa egy kritikus funkciókhoz tartozó authentikáció hiányát fedezte fel az ENTTEC alábbi rendszereiben:

- a Datagate MK2 minden, 70044_update_05032019-482-nél korábbi firmware-verziója;
- a Storm 24 minden, 70050_update_05032019-482-nél korábbi firmware-verziója;
- a Pixelator minden, 70060_update_05032019-482-nél korábbi firmware-verziója.

A gyártó a hibát a legújabb firmware-verziókban javította. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-085-03-0

Sérülékenységek Advantech WebAccess/SCADA rendszerekben

Mat Powell és Natnael Samson a ZDI-vel együttműködve három sérülékenységet találtak az Advantech WebAccess/SCADA rendszerének 8.3.5-ös és korábbi verzióiban.

A gyártó a sérülékenységeket a 8.4.0 verzióban javította. A sérülékenységekkel kapcsolatban részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-092-01

Sérülékenységek különböző Rockwell Automation rendszerekben

Az elmúlt 2 hétben 4 bejelentésben is különböző Rockwell Automation rendszerek sérülékenységi információi jelentek meg. Az elsőt Nicolas Merle, az Applied Risk munkatársa találta a Rockwell Automation beágyazott EtherNet/IP és Safety protokollal ellátott PowerFlex 525 AC drive berendezéseinek 5.001 és korábbi verzióiban.

A gyártó a hibát a legújabb firmware-verzióban javította. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-087-01

A következő hibát a gyártó jelezte az NCCIC-nek, ez a sérülékenység a bevitt adatok nem megfelelő ellenőrzéséből adódik és az Allen-Bradly Stratix 5950-es biztonsági appliance-ek alábbi verzióit érinti:

- 1783-SAD4T0SBK9;
- 1783-SAD4T0SPK9;
- 1783-SAD2T2SBK9;
- 1783-SAD2T2SPK9.

A hibával kapcsolatban a gyártó a berendezésekbe épített Cisco IPSec VPN használatának mellőzését és további kockázatcsökkentő intézkedéseket javasol. A sérülékenységről bővebben az ICS-CERT-nek ebben a bejelentésében lehet információkat találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-04

Szintén a gyártó jelezte az NCCIC-nek, hogy az alábbi termékeiben két sérülékenységet is azonosítottak:

- Allen-Bradley Stratix 5400, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 5410, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 5700, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley ArmorStratix 5700, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 8000, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 8300, a 15.2(4)EA7 és korábbi verziói.

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

- FRN 15.2(6)E2a:
- Allen-Bradley Stratix 5400 esetén;
- Allen-Bradley Stratix 5410 esetén;
- Allen-Bradley Stratix 5700 esetén;
- Allen-Bradley ArmorStratix 5700 esetén;
- Allen-Bradley Stratix 8000 esetén.
- FRN 15.2(4)EA7:
- Allen-Bradley Stratix 8300 esetén.

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-19-094-03

A Rockwell Automation egy ugyancsak Cisco komponensekből eredeztethető hibát jelentett az NCCIC-nek az alábbi termékeivel kapcsolatban:

- Allen-Bradley Stratix 5400 minden 15.2(6)E2a-nál korábbi verzió;
- Allen-Bradley Stratix 5410 minden 15.2(6)E2a-nál korábbi verzió;
- Allen-Bradley Stratix 5700 minden 15.2(6)E2a-nál korábbi verzió;
- Allen-Bradley ArmorStratix 5700 minden 15.2(6)E2a-nál korábbi verzió.

A gyártó a hibát a 15.2(6)E2a és később verziókban javította. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-02

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

Esteban Ruiz, a Source Incite munkatársa a ZDI-vel együttműködve egy sérülékenységet talált az Omron alábbi termékeiben:

- CX-Programmer v9.70 és korábbi verziói;
- Common Components January 2019 és korábbi verziók.

A gyártó a hibát az érintett rendszerek legújabb verzióiban javította. A sérülékenységről részleteket az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-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.

Ahogy a tisztán elektromos és plug-in hibrid meghajtású autók terjednek, egyre nyilvánvalóbbá válik, hogy a elektromos árammal történő feltöltésük a tömeges elterjedésük egyik legnagyobb akadálya. Jelenleg a legtöbb országban még a nem kellően sűrű töltőhálózat okoz problémát, amit a gyártók részben az otthoni, távolról is kezelhető házi töltőállomások elterjesztésével is próbálnak orvosolni.

A mai posztban két olyan, még 2018 végén publikált cikkre szeretném felhívni a figyelmet, amik azt mutatják be, mennyire hétköznapi, triviális sérülékenységek találhatóak ezekben a rendszerekben, amik, ha a háztartási elektromos autó töltők nagy tömegben terjednek el, adott esetben komoly hatással lehetnek a villamosenergia-rendszer nagyobb szegmenseire is (emlékezzünk csak a méltán elhíresült Black out - holnap már túl késő című könyvben az európai villamosenergia-rendszer ellen elkövetett - szerencsére csak fiktív - támadásra).

Az első cikkben a Kaspersky Lab munkatársai foglalták össze, hogy milyen sérülékenységeket találtak a ChargePoint által gyártott ChargePoint Home rendszerben, a 30 oldalas jelentés a rendszerben talált (és a gyártó által még tavaly év végén javított) sérülékenységekről itt érhető el.

Néhány nappal a Kaspersky fenti publikációja után a SecurityAffairs.co weboldalon kerültek nyilvánosságra a Schneider Electric EVLink Parking rendszerben a Positive Technologies munkatársai által talált sérülékenységek. Mindkét eset azt példázza (és nem először), hogy amint a gyártók között felerősödik a verseny egy új termékkel kapcsolatban történő piacszerzés során, úgy az új termékek (elsősorban IT biztonsági) minőségellenőrzése háttérbe szorul. Így volt ez néhány éve az IoT eszközök robbanásszerű terjedésének elején is, ezúttal azonban előfordulhat, hogy a következmények sokkal súlyosabbak lesznek, mint amikor a fitnesz-karkötőket lehetett nem túl bonyolult módon kompromittálni.

A héten újabb hírek láttak napvilágot, amik egy része a Norsk Hydro-t ért, másfél héttel ezelőtti támadás mértékét világítják meg (a hírek szerint a részleges leállást okoztó incidens első hete mintegy 35-40 millió amerikai dollárnyi veszteséget generált a cégnek). Más források szerint két amerikai vegyipari vállalatot (amelyek ugyanannak a befektetési alapnak a tulajdonásban vannak) szintén LockerGoga-támadás ért, még március 12-én. Ennek a hírnek a leginkább érdekes momentuma az a feltevés, hogy a LockerGoga ransomware-t irányító támadók nem igazán hatékonyak a váltságdíjak megszerzésében, ezért már felmerült az az elmélet is, hogy a LockerGoga nem is igazán ransomware, inkább egy wiper malware (inkább a NotPetya-ra és nem a WannaCry-ra hasonlít) és elsődleges célja a rombolás és nem a pénzszerzés.

Még év elején írtam egy posztot, amiben a TrendMicro által végzett, IIoT biztonsági kutatás eredményeiről írtam. Most a TrendMicro egy újabb kutatása eredményeiről lesz szó, ezúttal azonban azt vizsgálták, hogy a különböző Deep/DarkWeb-en megforduló egyének és csoportok milyen információkat és milyen céllal próbálnak összegyűjteni az Internet mélyebb rétegeiben.

A Deep/DarkWeb fórumain folytatott beszélgetések vizsgálata alapján a TrendMicro munkatársai az általános, ICS/SCADA rendszerekkel ismerkedő embereket (akik lehet, hogy csak a saját munkakörükhöz szükséges tudást próbálták a hivatalos tanfolyamoknál sokkal olcsóbban - ingyen - megszerezni,) éppúgy találtak, mint olyanokat, akik a Shodan és Censys keresők használatáról érdeklődtek és persze olyanokat is, akik a különböző (I)IoT eszközökön keresztül megszerezhető profit vezérelt. Túl ezeken a motivációkon, találtak olyan személyeket is, akik nem voltak hajlandóak elárulni, milyen cél elérése érdekében akarnak többet megtudni különböző ICS/SCADA rendszerekről, míg mások kifejezett Proof-of-concept kódokat, sérülékenységeket és a sérülékenységeket kihasználó éles exploit-okat kerestek.

A kutatók számára nagy nehézséget okozott megállapítani, hogy ezek az információgyűjtő tevékenységek előre jelezhetnek-e készülő vagy már folyamatban lévő támadásokat, viszont ezek a jelzések mind határozottabban mutatják, hogy a közműszektorban működő cégeknek alaposabb és pontosabb kockázatelemzésekkel kell készülniük az IIoT eszközök egyre nagyobb számban történő bevezetésére és ezzel egyidőben minél hatékonyabb eljárásokat kell kidolgozniuk a már üzemelő rendszereik biztonsági kockázatainak csökkentésére. Ebben továbbra is a már unalomig ismételt, de még mindig számos helyen és esetben megszegett, alapvető kockázatcsökkentési intézkedéseké lehet a főszerep:

- Minimálisra kell csökkenteni az ICS/SCADA 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 ICS/SCADA rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ICS/SCADA 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 TrendMicro teljes, 70 oldalas elemzése itt érhető el.

Sérülékenységek Columbia Weather Systems rendszerekben

John Elder és Tom Westenberg, az Applied Risk munkatársai hat sérülékenységet azonosítottak a Columbia Weather Systems Weather MicroServer nevű termékének MS_2.6.9900-as és korábbi firmware-verzióiban.

A gyártó a hibákat az MS_2.7.9973-as firmware-verzióban javította. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-078-02

AVEVA rendszerek sérülékenysége

A Venustech-hez tartozó ADLab munkatársai a Gemalto Sentinel UltraPro korábban már általam is jelzett sérülékenységét találták meg az AVEVA alábbi rendszereiben:

- InduSoft Web Studio v8.1 SP3-nál korábbi verziók;
- InTouch Edge HMI 2017 Update 3-nál korábbi verziók.

A gyártó a hibát az érintett termékek legújabb verzióiban javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-078-01

Sérülékenységek Medtronic eszközök által használt protokollban

Egy számos kutatóból álló csapat (Peter Morgan, a Clever Security munkatársa, Dave Singelée és Bart Preneel, a Leuven-i Katolikus Egyetem munkatársai, Eduard Marin a Leuven-i Katolikus Egyetem korábbi, jelenleg a Birmingham-i egyetem munkatársa, Flavio D. Garcia, Tom Chothia a Birmingham-i egyetem munkatársa, és Rik Willems a Leuven-i Gasthuisberg Egyetemi kórház munkatársa) két sérülékenységet fedeztek fel az alábbi Medtronic eszközök által használt rádiófrekvenciás telemetriai protokollban:

- MyCareLink Monitor 24950-es és 24952-es verziói;
- CareLink Monitor 2490C verzió;
- CareLink 2090 Programmer,
- Amplia CRT-D minden modell;
- Claria CRT-D minden modell;
- Compia CRT-D minden modell;
- Concerto CRT-D minden modell;
- Concerto II CRT-D minden modell;
- Consulta CRT-D minden modell;
- Evera ICD minden modell;
- Maximo II CRT-D and ICD minden modell;
- Mirro ICD minden modell;
- Nayamed ND ICD minden modell;
- Primo ICD minden modell;
- Protecta ICD and CRT-D minden modell;
- Secura ICD minden modell;
- Virtuoso ICD minden modell;
- Virtuoso II ICD minden modell;
- Visia AF ICD minden modell; and
- Viva CRT-D minden modell.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja és jelenleg is dolgozik a sérülékenységek javításán. A sérülékenységekről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-080-01

Sérülékenység Schneider Electric Triconex rendszerekben

Az Applied Risk munkatársai egy DoS-támadást lehetővé tevő sérülékenységet találtak a Schneider Electric Triconex TriStation Emulator 1.2.0 verziójában, ami a Triconex TriStation 1131 4.9.0 verziójának egyik komponense. A 2017 végén nyilvánosságra került TriSIS/Triton/Hatman malware-támadás is ezt a terméket érintette.

A gyártó a hibát javító verziót tervei szerint 2019 júliusában fogja kiadni. A sérülékenységről bővebben az Applied Risk és a Schneider Electric kiadványaiban lehet olvasni.

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.

Dale Peterson gondolatai és a kérdés magyar vetülete

Még tavaly év végén Dale Peterson írt egy rövidebb blogbejegyzést arról, hogy hogyan érdemes ICS (OT) biztonsági programot és csapatot építeni. Posztjában Dale, évtizedes ICS biztonsági tapasztalat alapján amellett teszi le voksát, hogy elsősorban az IT illetve az IT biztonság területéről érkező szakemberekre célszerű építeni, mert az ICS biztonsági programok és csapatok elsődleges prioritása, hogy csökkentsék egy sikeres támadás bekövetkezési valószínűségét és ezt leggyorsabban olyan IT biztonsági szakértőkkel lehet elérni, akiknek az OT megtanítja az ICS rendszerek és berendezések üzemeltetésének alapvető szempontjait és sajátosságait.

Dale második érve az, hogy egy általános IT biztonsági szakembert egy tapasztalt OT mérnökkel párba állítva és az alapvető OT prioritásokat megértetve nagyon gyorsan hatékony résztvevője lehet az ICS rendszerek és berendezések biztonságosabbá tételét célzó erőfeszítéseknek.

Fontos érv továbbá Dale posztjában, hogy egyre több folyamatvezérlési folyamat és eszköz használ egyre nagyobb mértékben IT megoldásokat, így számára egyre inkább tűnik úgy, hogy az IT-OT szembenállás már a múlté és az IT győzött, csak ezt sokan még nem ismerték fel. Az ipari folyamatvezérlést használó vállalatok felsővezetői egyre tisztábban látják, hogy az ICS biztonsággal kapcsolatban a kockázatelemzés az egyik leghatékonyabb eszköz és ezt a kockázatelemzést az informatikai illetve az információbiztonsági menedzserektől várják, ugyanúgy, mint bármelyik IT rendszer esetén.

Számomra az ilyen gondolatok olvasása mindig nagyon érdekes és többször próbáltam már párbeszédet kezdeményezni ebben a témában a hazai szakma képviselői között itt, a blogon. Most, hogy a tavalyi év végén elindult a SeConSys együttműködés (és amennyire tudom, a januári első workshopon még a blog egyik-másik posztja is előkerült), talán eljön végre az ideje, hogy egy ilyen beszélgetés is elinduljon. Minden esetre a kérdés adott: ki mit gondol, hogyan lehet egy ipari szervezet ICS biztonságát a leginkább hatékonyan fejleszteni?

PEPPERL+FUCHS WirelessHART átjárók sérülékenysége

Az ICS-CERT bejelentése szerint a PEPPERL+FUCHS egy sérülékenységet javított a WirelessHART protokollhoz ajánlott átjáróinak minden verziójában.

A gyártó a hibát az érintett eszközök WHA-GW-*-ETH 03.00.08-as és WHA-GW-*-ETH.EIP 02.00.01-es firmware-verzióiban javította. A sérülékenységről további információk az ICS-CERT bejelentésében találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-19-073-03

Sérülékenység Gemalto Sentinel UltraPro rendszerekben

A Venustech-hez tartozó ADLab munkatársai egy sérülékenységet azonosítottak a Sentinel UltraPro 1.3.0, 1.3.1 és 1.3.2-es verzióiban.

A gyártó a hibát a Sentinel UtraPro v1.3.3-as verzióban javította. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-073-02

LCDS LAquis SCADA sérülékenység

Mat Powell a ZDI-vel együttműködve egy memóriakezelési hibát talált az LCDS LAquis SCADA SCADA 4.1.0.4150-es verziójában.

A gyártó a hibát a termék 4.3.1.71-es verziójában javította. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-073-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.

Ma reggel érkeztek az első hírek arról, hogy a Norsk Hydro nevű, norvég központú alumíniumgyártó vállalat rendszereit támadás érte. Az első hírekből még nem lehetett tudni a támadás jellegét, azt viszont igen, hogy az ügyviteli rendszerek mellett a termelésirányításért felelős rendszerek egy részét is érintette az incidens, az első cikkek manuális vezérlésre történő átállásról szóltak.

Mostanra több részlet is nyilvánosságra került, ezek szerint a LockerGoga nevű zsarolóvírus okozta az incidenst, aminek következtében a Norsk Hydro leállította több alumínium-megmunkáló gyártósorát és izolálták a gyárak termelésirányítási rendszereit a vállalat ügyviteli hálózataitól.

Az esetről további részleteket a Reuters és a DarkReading oldalain lehet olvasni.

Szerk: Ahogy azt sejteni lehetett a szaksajtó igen komoly érdeklődéssel követi az eseményeket, cikkek a témában:

The Register

HelpNet Security

SecurityWeek

SecurityWeek2

SecurityAffairs

Recorded Future

SecurityWeek3

Bleeping Computer

Kaspersky

HelpNet Security2

Lassan már nekem is kezd gyanúsan soknak tűnni, hogy az utóbbi időben a TrendMicro munkatársai milyen sok, ICS biztonsággal kapcsolatos publikációt jelentetnek meg (eddig a nagy biztonsági gyártók közül a Kaspersky volt az éltanuló, de ugye őket az utóbbi időben a nyugati világban IT biztonsági illetve politikai döntéshozói nem igazán kedvelik).

A nemrég talált tanulmányukban a TrendMicro munkatársai a rádiótávirányítással működtetett ipari daruk (főként építkezéseken és összeszerelő üzemekben használt változatok) biztonságát vizsgálták. Megállapításaik szerint ezeknek a berendezéseknek a biztonsága jelenleg a távirányítható garázsajtók biztonsági szintjét sem érik el. Ráadásul, ahogy a TrendMicro egyik munkatársa a tanulmány megjelenése nyomán érdeklődő szaksajtó kérdésére elmondta, van olyan gyártó, akit egy ügyfele kifejezetten azzal a kéréssel keresett meg, hogy tegyék a daruk vezérlését teljesen automatizálttá és egyáltalán ne kelljen fizikai gombokat megnyomni a távirányításhoz, ehelyett számítógépek a teljes folyamatot, emberi beavatkozás nélkül tudják vezérelni. Bár ez a kérés egyértelműen illeszkedik az IIoT és az Ipar 4.0 tendenciákba, elég ijesztő belegondolni, hogy milyen következményei lehetnek, ha egy illetéktelen személy vagy csoport nem kellő körültekintéssel végez változtatásokat a távirányított berendezéseket vezérlő számítógépen - vagy éppen egy, a WannaCry-hoz vagy a NotPetya-hoz hasonló ransomware- vagy wiper-malware zavarja meg a távírányításért felelős számítógépet.

További problémaként jelzi a tanulmány, hogy a rádiótávirányításhoz használt készülékek és a daruk rádiófrekvenciás társítási folyamatába, az egyetlen ellenőrzési funkció arra szolgál, hogy el lehessen kerülni a protokoll-szintű interferenciákat és több eszköz tudjon párhuzamosan dolgozni az emberek életének és testi épségének veszélyeztetése nélkül.

Ahogy azt számos más ICS eszköznél már-már megszokottként említhetünk, az ipari daruk esetében is viszonylag könnyű lehet egy támadónak rögzíteni és később visszajátszani egy eredetileg legitim parancsot (replay-attack), illegális utasításokat kiadni (command injection), szolgáltatás-megtagadást (Denial-of-Service) előidézni vagy akár ártó szándékkal a berendezések teljes programját megváltoztatni.

A TrendMicro tanulmányát itt lehet megtalálni, a témáról Bruce Schneier is írt a blogján, ahol több érdekes hozzászólást is lehet olvasni.