Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

ICS sérülékenységek - 2017 ICS sérülékenységi statisztikái

2018. január 03. - icscybersec

Hosszú idő óta az elmúlt egy héten nem jelentek meg új ICS sérülékenységi információk az általam követett forrásokban, ezért a heti ICS sérülékenységekről szóló posztot felhasználom arra, hogy egy rövid összefoglalást készítsek a 2017-ben általam újraközölt ICS sérülékenységekről.

2017-ben összesen 430 ICS rendszerekkel/berendezésekkel kapcsolatos sérülékenységről szóló információ adtam közre a blogon keresztül, ami közel 65%-os növekedést jelentett 2016-hoz képest. A CVSSv3 alapján történő besorolás szerint a kritikus sérülékenységek számában még ennél is nagyobb volt a növekedés, 2016-hoz képest 72%-kal több kritikus sérülékenység került publikálásra (2016-ban 47, 2017-ben 81), a magas besorolású sérülékenységek esetén ez a szám már 80% fölött van (107 és 193), a közepes kategóriájú sérülékenységeknél pedig 58% volt a növekedés (96 és 152). Csökkenést egyedül az alacsony besorolású sérülékenységeknél tapasztaltam (11 és 4).

A 2017-ben publikált sérülékenységek nagyon nagy többsége (95%-a) távolról is kihasználható. A sérülékenységek gyártók szerinti bontásában nincs nagy meglepetés, a nagy gyártók végeztek idén is az "élen".

Ahogy ezek a statisztikák is mutatják, az ICS rendszerek/berendezések sérülékenységi helyzete korántsem jó, azonban még ezt a képet is tovább rontja, ha azt nézzük, hogy a publikált sérülékenységekkel kapcsolatosan elérhetőek-e hibajavítások? A 430 sérülékenység több, mint harmadához a sérülékenység publikálásakor nem volt elérhető javítás, vagyis ezeket a sérülékenységeket 0. napi sérülékenységként kell kezelni és ezeknek az eseteknek egy igen tekintélyes hányadában a gyártó is kijelentette, hogy az adott termék/verzió támogatási ciklusa végére ért és soha nem fognak javítást kiadni az adott sérülékenységgel kapcsolatban (nagyon sok mindenért jogosan lehet kárhoztatni a Microsoft-ot, de amikor a redmond-i gyártó látta, hogy az EternalBlue sérülékenység milyen hihetetlen komoly károkat okoz a WannaCry ransomware-kampány idején, saját korábbi kijelentésével szembemenve is adott ki javítást egyes, már nem támogatott, de széles körben használt operációs rendszer verzióihoz). Tekintettel arra, hogy a legtöbb ICS rendszer/berendezés életciklusa 15-20 év is lehet, az ilyen, gyártói támogatással már nem rendelkező, de publikusan elérhető sérülékenységeket tartalmazó rendszerek még igen sokáig a mindennapjaink fontos folyamatait vezérlő szereplői lehetnek. Éppen ezért fontos, hogy foglalkozzunk az ICS rendszerek kiberbiztonsági kérdéseivel.

Mi vár az ICS biztonság világára 2018-ban?

Már a 2017 is elég mozgalmas év volt az ICS kiberbiztonságban dolgozók számára (elég csak a CrashOverride és Triton/Trisis ICS malware-ekre gondolni), de a jelek szerint 2018-ban sem fogunk unatkozni. Lássuk, milyen kihívásokat jósolnak a jövő évre az ICS világában dolgozóknak:

Az újabb ransomware-ek között már olyanok is lehetnek, amik kifejezetten ipari rendszereket céloznak.

2017-ben több nagy ransomware illetve ransomware/wiper malware-támadást éltünk át és már ezek között is több olyan volt, ami súlyos károkat okozott ipari környezetekben is. 2018-ra vannak olyan várakozások, hogy megjelennek az első, kifejezetten ipari rendszereket célzó zsarolóvírusok is - idén a Georgia Institute of Technology munkatársai kutatási céllal már készítettek egy olyan proof-of-concept malware-t (amit LogicLocker-nek nevezetek el), ami képes volt különböző gyártók vezérlőit megfertőzni. Ismerve az ICS eszközök gyakori biztonsági hiányosságait (most elsősorban a gyenge authentikációra és a hibajavítások hiányára vagy késedelmes telepítésére), egyáltalán nem túlzás egy ilyen malware-támadás lehetőségét komolynak, hatását pedig súlyosnak nevezni.

Az ipari dolgok Internete (IIoT) egyre nagyobb kihívásokat fog jelenti biztonsági szempontból

Az IIoT az elmúlt néhány évben egyre nagyobb teret nyer az ICS világában, ennek oka többnyire a modernizáció és a költséghatékonyság egyre nagyobb nyomása az ipari szereplők üzleti részlegei felől. Magyarországon egy további tényező erősítheti az IIoT alkalmazását, ez pedig az egyre több területen, így lassan az ipari szereplőknél is súlyosabbá váló, képzett munkaerő hiánya, amit például a gyártásban vagy akár a közmű szektorban egy ideig még ellensúlyozni lehet az automatizálás fokozásával.

Az automatizálás növelése azonban egyre jobban elmossa a (fizikai elkülönítés) jelentette határokat az üzleti/vállalati és az ipari hálózatok, illetve egyre gyakrabban az ipari hálózatok és az Internet illetve egyéb publikus hálózatok között, ami a korábbiaknál nagyságrendekkel nagyobb fenyegetéseket és támadási felületeket jelentenek az ICS rendszerek számára.

Az ICS kiberbiztonsági szakemberek hiánya egyre súlyosabb lesz

Bár világszerte már ezres nagyságrendben vannak minősített és tapasztalt ipari biztonsági szakemberek, az igény az ilyen, speciális biztonsági ismeretekkel rendelkező profikra sokkal gyorsabb ütemben nő, mint ahogy új szakemberek tudnak megjelenni a piacon. Ebből a szempontból a helyzet talán még rosszabb, mint (az egyébként szintén komoly hiányszakmának számító) IT biztonsági szakemberek esetében, hiszen az ICS világában gyakran azokat a technikákat és eszközöket sem lehet használni, amik az IT biztonság világában mindennaposnak számítanak.

Magyarországon jelenleg gyakorlatilag szó sem esik erről a témáról - nem véletlenül indítottam két éve a blogot, de egyelőre nem igazán látszik, hogy a hazai ICS közösség aktivizálná magát az ICS kiberbiztonság témájában. Az nyilvánvaló, hogy érdeklődés a téma iránt van (ez általában látható azokon a ritka előadásokon, amiket a témában néhányan időnként tartanak), de azok a szakemberek, akik az ICS kiberbiztonság területén tevékenykednek, továbbra is bezárkóznak a saját munkahelyük elefántcsont tornyába és még egymással sem igen osztják meg a tapasztalataikat.

Egyre nagyobb valószínűség egy súlyos ICS incidensre

Na nem mintha az elmúlt évek ICS incidensei (a Stuxnet, majd a német acélkohóban bekövetkezett incidens és a 2015-ös és 2016-os ukrán villamosenergia-rendszer elleni támadások) ne lettek volna önmagukban is súlyos incidensek, de a Triton/Trisis malware megjelenés és felhasználása egyre inkább abba az irányba mutat, hogy a különböző helyi és globális politikai konfliktusokban (a Közel-Keleten Szaúd-Arábia és Irán konfliktusában, a Távol-Keleten Észak-Korea és Dél-Korea illetve az USA egyre romló viszonya, illetve Oroszország egyre komolyabb kibertér-képességei, amiket mind több állítás szerint fel is használnak az orosz politikai érdekek érvényesítéséhez) egyre nagyobb esélye lehet egy olyan incidensnek, ami nagyon súlyos, akár végzetes hatással járhat az ICS rendszerek által felügyelt/vezérelt ipari folyamatokra, vagy akár (ahogy a Triton/Trisis malware esetén már az SIS rendszer volt a célpont) emberéletet is követelhet az incidens.

A rossz jelek és előérzetek mellett azért pozitív várakozások is vannak 2018 kapcsán. Az első és talán legfontosabb, hogy már érezhetően nő az ICS világban élő és dolgozó ipari automatizálási (OT) mérnökök biztonságtudatossága. Személy szerint is érzem, hogy az OT mérnökök már gondolnak olyan biztonsági szempontokra is, amiket néhány évvel ezelőtt még csak nem is értettek, miért fontosak ezek a dolgok. Ugyanígy kezdik megérteni az OT-ben az események átláthatóságának értékét is, így aztán egyre inkább magától értetődővé válik olyan, tradicionálisan az IT biztonság világából ismert megoldásoknak, mint például a SIEM (Security Incident and Event Management, naplóelemző) rendszerek.

Fókuszba kerül az épületautomatizálási rendszerek biztonsága

Sok éven át az épületautomatizálási rendszerek biztonsága nem került fókuszba, még azután a Stuxnet után a figyelem középpontjába került az ICS rendszerek biztonsága. Annak ellenére volt ez így, hogy általában az épületautomatizálási rendszerek felelnek a szervezetek szervertermeinek/szerverszobáinak hűtéséért és szünetmentes tápellátásáért, ezeken keresztül pedig a teljes vállalati IT rendelkezésre állására is hatással lehetnek.

Kiberbiztonsági keretrendszerek növekvő alkalmazása az ICS rendszereknél

Bár itthon és a világban is ritka, hogy törvényi kötelezettsége lenne az ICS rendszereket üzemeltető szervezeteknek a különböző ICS biztonsági keretrendszerek alkalmazására, mégis az elmúlt években egyre terjed a kifejezetten ICS rendszerek kiberbiztonságával foglalkozó keretrendszerek, mint pl. az NIST 800-82 vagy a NERC-CIP alkalmazása. Várhatóan ez a folyamat csak gyorsulni fog, még akkor is, ha a jogszabályok ezt továbbra sem fogják megkövetelni, de a különböző szervezetek egyre inkább felismerik, hogy ezeknek a keretrendszereknek az alkalmazásával nagy mértékben lehet javítani az ICS rendszerek kiberbiztonsági helyzetét.

Biztonságosabb ICS eszközök és rendszerek

Ahogy az ICS rendszereket használó szervezetek biztonságtudatossága is magasabb szintre lép, az ICS eszközöket és rendszereket gyártó vállalatok közül egyre több ismeri fel, hogy nem elég az ipari folyamatvezérlési funkciókban kiszolgálni az ügyfeleik igényeit, hanem ugyanígy fontossá vált az ICS rendszerek kiberbiztonsága is. Várhatóan egyre több ICS eszköz és rendszer lesz képes titkosított protokollokon keresztül kommunikálni és talán eljutunk végre ahhoz a régen várt állapothoz, hogy az ICS rendszerek biztonsági funkciói gyári alapértelmezés szerint be lesznek kapcsolva és akkor lehet kikapcsolni őket, ha az ügyfél kifejezetten ki akarja kapcsolni őket.

Bár ez egy kifejezetten örömteli fejlemény, azonban figyelembe kell venni, hogy a legtöbb ipari rendszert 15-20 éves életciklussal tervezték és helyezték üzembe, ezért még hosszú ideig nem lesz lehetőség minden régi ICS rendszert lecserélni az újabb, biztonságosabb verziókra. Emiatt még sokáig szükség lesz a mélységi védelem és a biztonságos ICS architektúra modellben leírt elvek gyakorlati alkalmazására.

ICS sérülékenységek CXLVI

Moxa és Schneider Electric rendszerek sérülékenységei

Sérülékenység Moxa NPort készülékekben

Federico Maggi egy, a felhasználói adatok nem megfelelő kezeléséből adódó sérülékenységet jelentett az ICS-CERT-nek, ami a Moxa alábbi eszközeit érinti:

- NPort W2150A 1.11-nél korábbi firmware-jei;
- NPort W2250A 1.11-nél korábbi firmware-jei.

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

A sérülékenységgel kapcsolatos további részleteket az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-17-355-01

Schneider Electric rendszerek sérülékenységei

Gjoko Krstic két sérülékenységet jelentett a Schneider Electric-nek, amik a francia gyártó Pelco VideoXpert Enterprise rendszerének 2.1-nél korábbi összes verzióját érinti.

A hibák között könyvtár-bejárásos támadást lehetővé tevő és nem megfelelő hozzáférés kontrollból adódó sérülékenység is található.

A gyártó a 2.1-es verzióban javította.

A sérülékenységről további információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-355-02

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.

Kriptovalutát bányászó malware a Transneft rendszereiben

Az orosz olajipar szállítási kapacitásainak jelentős részét felügyelő Transneft rendszereit a hírek szerint a Monero nevű kriptovaluta bányászatára fejlesztett malware fertőzte meg. A cég képviselői szerint a malware-fertőzés hatással lehetett volna a Transneft feldolgozó kapacitására. Az utóbbi idők kriptovaluta-árfolyamainak drasztikus kilengései nyomán lehetett arra számítani, hogy megnő a Bitcoin és más kriptovaluták bányászatára speciálizált malware-ekkel végrehajtott támadások száma, az azonban még mindig nem számít mindennapi hírnek, hogy ezek a kártevők viszonylag könnyen utat találnak az ipari folyamatok felügyeletéért és irányításáért felelős rendszerekbe is.

ICS sérülékenységek CXLV

Sérülékenységek WECON, Siemens, Ecava, PEPPERL+FUCHS/ecom instruments és ABB rendszerekben

WECON LeviStudio HMI sérülékenység

Michael DePlante a ZDI-vel együttműködve tájékoztatta az ICS-CERT-et egy, a WECON LeviStudio HMI berendezéseiben talált puffer túlcsordulásból eredő sérülékenységet. A hiba a LeviStudio HMI minden verziójában megtalálható.

A hibát a gyártó a legfrissebb, weboldalán

http://www.we-con.com.cn/en/download.aspx?id=45

elérhető verzióban javította.

A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT publikációjában lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-17-353-05

Siemens LOGO! Soft Comfort sérülékenység

Tobias Gebhardt egy integritás-ellenőrzés nélküli kódletöltésből adódó hibát jelentett a Siemens-nek, ami a LOGO! Soft Comfort V8.2-nél korábbi verzióiban található meg.

A hibát a gyártó a LOGO! Soft Comfort V8.2-es verziójában javította.

A sérülékenység részleteiről az ICS-CERT bejelentésében lehet bővebben olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-353-04

Sérülékenység Ecava Integraxor rendszerekben

Steven Seeley, Michael DePlante és Brad Taylor két SQL injection sérülékenységet fedeztek fel az Ecava Integraxor 6.1.1030.1 és korábbi verzióiban.

A gyártó a hibákat a 6.1.1215.0 verzióban javította.

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

Sérülékenység PEPPERL+FUCHS/ecom instruments eszközökben

A PEPPERL+FUCHS/ecom instruments a Mathy Vanhoef által felfedezett KRACK sérülékenységgel kapcsolatos információkat jelentett a CERT@VDE-nek. A KRACK sérülékenység az alábbi, vezeték nélküli kommunikációra képes eszközeiket érinti, amennyiben azok a WPA2 protokollt használják:

- Tab-Ex 01;
- Ex-Handy 09;
- Ex-Handy 209;
- Smart-Ex 01;
- Smart-Ex 201;
- Pad-Ex 01;
- i.roc Ci70-Ex;
- CK70A-ATEX;
- CK71A-ATEX;
- CN70A-ATEX;
- CN70E-ATEX.

Az Android alapú eszközök esetén a gyártó jelenleg is dolgozik a hiba javításán. A Microsoft Windows alapú eszközöket használó ügyfeleiknek azt tanácsolják, hogy telepítsék a Microsoft által kiadott patch-eket.

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-17-353-02

Sérülékenység ABB Ellipse rendszerekben

A gyártó a felhasználók bejelentkezési adatainak olvasható formában történő továbbításából adódó hibát jelzett az ICS-CERT-nek. A sérülékenység az alábbi verziókat érinti:

- Az Ellipse 8.3-tól 8.9-ig terjedő, 2017 december előtt kiadott verziói.

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

- Ellipse 8.5.26 Release 7, 2017 decemberi kiadás;
- Ellipse 8.6.21 Release 5, 2017 decemberi kiadás;
- Ellipse 8.7.18 Release 7, 2017 decemberi kiadás;
- Ellipse 8.8.12 Release 7, 2017 decemberi kiadás;
- Ellipse 8.9.6 Release 7, 2017 decemberi kiadás.

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-353-01

KRACK sérülékenység Siemens SIMATIC eszközökben

A Siemens ProductCERT által kiadott közlemény szerint 5 különböző, KRACK-hez kapcsolódó sérülékenységet azonosítottak az alábbi Siemens SIMATIC eszközökben:

- SIMATIC RF350M: minden Summit Client Utility-t tartalmazó verzió V22.3.5.16-nál korábbi verziók esetén;
- SIMATIC RF650M: minden Summit Client Utility-t tartalmazó verzió V22.3.5.16-nál korábbi verziók esetén.

A Siemens a hibákat a V22.3.5.16-os verzióban javította.

A sérülékenység részleteit a Siemens ProductCERT kiadványa tartalmazza: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-418456.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:

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.

Triton/Trisis malware

Felfedezték az ötödik, kifejezett ICS rendszerek ellen fejlesztett malware-t

December 14-én egymással párhuzamosan a FireEye és a Dragos, Inc. is publikált egy-egy elemzést az általuk Triton (FireEye) illetve Trisis (Dragos) névre keresztelt, kifejezetten ipari rendszerek ellen tervezett és fejlesztett malware-ről.

Az elemzések alapján a Triton/Trisis malware-t a Schneider Electric által gyártott Triconex SIS-re (Safety Instrumented System) fókuszálva írták. Mindkét biztonsági cég publikációja szerint a malware-t eddig egyetlen helyen azonosították, egy Közel-keleti ipari szereplőnél, ahol a támadás által érintett SIS vezérlők egy ún. "fail-safe" leállást (ilyen esetekben az SIS rendszer a fizikai folyamatok teljes leállítását hajtják végre annak érdekében, hogy megelőzzék egy nem biztonságos állapot kialakulását) hajtott végre, amikor az alkalmazás redundáns komponenseinek egyikében hibára futott a programkód ellenőrzése.

Az érintett Triconex SIS rendszert számos iparágban használják, tekintve azonban, hogy minden SIS rendszer különböző és a folyamatvezérlésre gyakorolt hatásuk megértéséhez az adott folyamat mélyreható ismerete szükséges, a szakértők nem számítanak arra, hogy a Triton/Trisis szélesebb körben is felbukkanna - akár csak más, Triconex-et használó szervezeteknél sem. A célzott támadás elméletét erősíti az is, hogy a FireEye elemzése szerint az SIS kompromittálása után nem sokkal a támadók fel is töltötték a Triton/Trisis malware-t a rendszerbe. Ez a FireEye munkatársai szerint arra enged következtetni, hogy már elő volt készítve a malware, aminek a megírásához hosszabb időre és nem mindenki számára hozzáférhető eszközökre is szükségük lehetett.

Az incidens esetén a célba vett szervezet az elemzések szerint legalább két, ICS biztonsági legjobb gyakorlatot is figyelmen kívül hagyott, az SIS rendszer össze volt kapcsolva a folyamatirányító hálózattal és a Triconex SIS "Run" mód helyett "Program" módban működött (a Triconex "Run" módban nem engedélyezi a programban változtatások végrehajtását, "Program" módban azonban lehetőség van erre, ezért volt lehetősége a Triton/Trisis malware-nek érdemi változtatásokat végrehajtani az SIS rendszerben). Bár az ICS biztonsági legjobb gyakorlatok betartása sem jelent 100%-os védelmet egy hasonló támadás esetén, mégis jelentősen megnehezíthetik a támadók dolgát és könnyebbé tehetik a megtámadott szervezet számára a támadás minél előbbi felfedezését.

Bár maga a Triton/Trisis malware nem alkalmas arra, hogy nagyobb volumenű támadásokhoz használják fel, most, hogy a malware részletei nyilvánosságra kerültek, várható, hogy más támadói csoportok is célba fognak venni különböző SIS rendszereket (mint ahogy a Stuxnet nyilvánosságra kerülése után is elszaporodtak az ICS rendszerek elleni támadási kísérletek).

Meg kell jegyezni, hogy egy SIS rendszer kompromittálása önmagában még nem jelenti azt, hogy az adott folyamatirányító rendszer biztonsági (safety) funkciói is sérülnének. A folyamatirányító rendszerek biztonsági funkcióinak tervezése számos egyedi képesség meglétét és szabványok betartását igényli annak érdekében, hogy az adott folyamat biztonsági szintje megfeleljen az elvárásoknak. Mindaddig, amíg (egy akár IT biztonsági szempontból kompromittált) SIS rendszer a tervezésének megfelelően látja el a biztonsági (safety) funkcióit és szükség esetén (mint ahogy a mostani publikációkban leírt esetben is történt) képes fail-safe állapotban megállítani a fizikai folyamatokat, egy ilyen incidens nem jelent veszélyt az emberéletre vagy a környezetre.

További részleteket a Triton/Trisis malware-ről a FireEye és a Dragos, Inc. publikációiban lehet olvasni.

Utasszállító repülőgépek vezérlő rendszereinek biztonságát tesztelték

A DHS emberei két nap alatt törtek be egy Boeing 757-es rendszereibe

Az elmúlt néhány évben többször lehetett hallani olyan híreket, hogy biztonsági kutatók autók motorvezérlő rendszereihez fértek hozzá távolról, pl. GSM-kapcsolaton keresztül. Nagyjából két évvel ezelőtt egy férfit azzal vádolt meg az FBI, hogy utazás közben, a fedélzeti szórakoztató rendszer borítását megbontva, majd az így hozzáférhetővé tett USB-csatlakozáson keresztül elért rendszereken át hozzáférést szerzett a repülőgép hajtóműveit vezérlő rendszerhez és képes volt módosítani a hajtómű működését repülés közben. Ezek az esetek általában kavartak valamekkora érdeklődést, de 1-2 nap után az újabb hírek miatt ezek a témák háttérbe szorultak.

Valamivel több, mint egy hónapja az amerikai belbiztonsági minisztérium (Department of Homeland Security, DHS) munkatársai egy Virginia államban tartott konferencián arról beszéltek, hogy egy 2016-ban végzett vizsgálat során két napnyi munka árán minden fajta belső segítség nélkül sikerült távolról kompromittálni egy Boeing 757-es repülőgép rendszereit és átvenni az irányítást a vezérlőrendszerei fölött.

Az esetről számos helyen írtak, amennyire én meg tudtam ítélni, az eredeti publikáció az Aviation Today cikke volt.

ICS sérülékenységek CXLIV

Sérülékenységek Phoenix Contact, Rockwell Automation, Xiongmai Technology és Schneider Electric rendszerekben

Az elmúlt héten ismét megjelent néhány új és érdekes ICS sérülékenységről szóló publikáció.

Sérülékenység Phoenix Contact rendszerekben

Maxim Rupp egy Cross-site scripting hibát fedezett fel a Phoenix Contact alábbi, ipari hálózati eszközeiben:

- FL COMSERVER BASIC 232/422/485;
- FL COMSERVER UNI 232/422/485;
- FL COMSERVER BAS 232/422/485-T;
- FL COMSERVER UNI 232/422/485-T;
- FL COM SERVER RS232;
- FL COM SERVER RS485;
- PSI-MODEM/ETH.

A felsorolt eszközök mindegyik sérülékeny, amennyiben az 1.99-es, 2.20-as vagy 2.40-esnél korábbi firmware-verziók valamelyikét futtatják.

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

A sérülékenységről bővebb információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-341-03

Rockwell Automation FactoryTalk sérülékenység

Egy meg nem nevezett petrolkémiai cég a bevitt adatok nem megfelelő ellenőrzéséből adódó sérülékenységet jelentett az ICS-CERT-nek. A hiba az alábbi rendszereket érinti:

- FactoryTalk Alarms and Events, 2.90 és korábbi verziók;
- FactoryTalk Services (RSLinx Enterprise), minden verzió;
- FactoryTalk View SE, 5.00 és korábbi verziók;
- Studio 5000 Logix Designer, 24-es és későbbi verziók.

A hibát az ICS-CERT publikációja szerint a Rockwell Automation a FactoryTalk 2.90-es verziójában illetve az újabb verziókban javította (ez némiképp ellentmond a sérülékeny verzióknál az első sorban írt információknak, ahol az érintett verziók között sorolják a 2.90-et és az ennél korábbi verziókat is).

Az ICS-CERT vonatkozó bejelentése itt érhető el: https://ics-cert.us-cert.gov/advisories/ICSA-17-341-02

Sérülékenység Xiongmai Technology IP kamerákban és digitális videórögzítő rendszerekben

Clinton Mielke, független biztonsági kutató egy puffer túlcsorduláson alapuló sérülékenységet fedezett fel a Xiongmai Technology által gyártott minden olyan IP kamerában és videórögzítő rendszerben, amik a NetSurveillance Web interfészt használják.

A gyártó nem reagált az ICS-CERT sérülékenységgel kapcsolatos megkeresésére, így jelenleg nem áll rendelkezésre semmilyen hivatalos gyártói információ a sérülékenységgel kapcsolatban.

Az ICS-CERT sérülékenységgel kapcsolatos kiadványát itt lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-17-341-01

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

A gyártó bejelentése szerint a Schneider Electric EcoStruxure nevű, alállomási felhasználói interfészében használt MySQL 5.5.56-os verzióban több sérülékenység is található, amiket kihasználva szolgáltatás-megtagadásos (DoS) támadást lehet végrehajtani a sérülékeny rendszerek ellen. A sérülékenység az EcoStruxure Substation Operation
User Interface (korábbi nevén EcoSUI) 2.1.17279 és korábbi verzióit érinti.

A gyártó a hibát a 2.1.17285-ös verzióban javította.

A sérülékenységgel kapcsolatban bővebb információkat a Schneider Electric publikációjában lehet olvasni.

Sérülékenységek Schneider Electric Pelco rendszerekben

A Schneider Electric által most közzétett három hibát Gjoko Krstic fedezte fel a Pelco VideoXpert Enterprise 2.1-nél korábbi verzióiban. A hibák között biztonsági intézkedések megkerülését lehetővé tevő, érzékeny adatokat felfedő és jogosultság-kiterjesztésre lehetősége adó hibák találhatóak.

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

További részleteket a Schneider Electric bejelentésében lehet találni.

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.

ICS sérülékenységek CXLIII

Sérülékenységek Ethicon Endo-Surgery, Geovap és Siemens rendszerekben

Ethicon Endo-Surgery rendszerek sérülékenysége

Az Ethicon anyavállalata, a Johnson&Johnson egy nem megfelelő authentikációból adódó sérülékenységet jelentett az ICS-CERT-nek. A hiba az Ethicon Endo-Surgery Generator Gen11 minden, 2017. november 29-e előtt kiadott verziójában megtalálható.

A gyártó a sérülékenységet javító verziót elérhetővé tette a hiba által érintett ügyfelei számára.

A sérülékenységgel kapcsolatban részletesebb információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-17-332-01

Geovap Reliance SCADA sérülékenység

Can Demirel egy cross-site scripting sérülékenységet jelentett az ICS-CERT-nek, amit a Geovap Reliance SCADA nevű rendszerének 4.7.3 Update 2 és korábbi verzióiban talált.

A gyártó a hibát a 4.7.3 Update 3 verzióban javította.

A sérülékenység részletei az ICS-CERT publikációjában olvashatóak: https://ics-cert.us-cert.gov/advisories/ICSA-17-334-02

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

A gyártó öt különböző sérülékenységet a SWT3000 berendezések EN100 moduljainka alábbi firmware-verzióiban:

- IEC61850 firmware V4.29.01-nél korábbi verziók;
- TPOP firmware: V01.01.00-nál korábbi verziók;

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

A sérülékenységgekről további részleteket az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-334-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.

ICS biztonsági konferenciák I

Az ICS Cyber Security Conference

Az ICS Cyber Security konferencia talán az egyik legnagyobb múltra visszatekintő, kifejezett ICS kiberbiztonságra fókuszáló konferencia, idén már 16. alkalommal rendezték meg.

A konferenciát mind a mai napig nem lehet elválasztani Joe Weiss-től, az Applied Control Solutions alapítójától, olyannnyira nem, hogy az első időkben a konferenciák is csak WeissCon-ként emlegették, ezzel is utalva az alapító Joe egészen elképesztő elhivatottságára az ICS biztonság témája iránt. Az elmúlt néhány évben a SecurityWeek átvette a konferencia szervezését, azóta egyre komolyabb fejlesztések történnek, idén első alkalommal a korábbi, atlanta-i Georgia Tech egyetemi helyszín után a szintén atlanta-i Buckhead-ben található Intercontinental-ba került áthelyezésre a rendezvény, ráadásul tavasszal első alkalommal már Szingapúrban is megrendezésre került az ICS Cyber Security Conference ázsiai rendezvénye is.

Az idei és az elmúlt két évben volt lehetőségem részt venni az ICS Cyber Security konferencián és mivel 2014-ben jártam ICS témájú európai rendezvényen is, már az első alkalommal volt összehasonlítási alapom. Részben ezek alapján azt kell mondanom, hogy jelenleg ez a konferencia talán a legjobb ár-érték arányú szakmai rendezvény azok közül, amik kifejezetten az ICS biztonságot helyezik témáik között az első helyre.

Egyrészt a résztvevők létszáma (idén egyes források szerint 400 résztvevője volt, szemben a 14-es európai rendezvénnyel, ahol maximum 30-an lehettünk) és az előadók között megjelenő "nagy neveken" (Joe Weiss évenként megtartott State of the State című előadása mellett tavaly pl. az NSA igazgató/US Cyber Command parancsnok Michael S. Rogers admirális tartotta a keynote előadást) túl elég egyértelműen látszik, hogy az ICS biztonsági szakterület aktuális trendjeit itt lehet a legkorábban és a legjobban felmérni. Erre egy példa, hogy Joe Weiss közel egy éve ír az Unfettered blogon arról, hogy a vállalati és az ipari IT-ban egyaránt használható hálózati monitoring és anomália-detektáló megoldások használata mellett javítani kell a lvl1 és lvl0 eszközök szintjén is az átláthatóságot. Az idei konferencián számomra meglepően sokan tartottak előadást ebben a témában és néhány gyártó már az ilyen megoldásaikat is elhozták bemutatni.

Néhány további fontos gondolat az idei konferenciáról:

- Jake Brodsky előadásában egy PLC-ben talált bug-ot mutatott be - eredetileg még csak abban sem lehetett biztos, hogy bug-ot és nem egy incidenst fedezett fel, minden esetre megkereste a gyártót, akik kiemelten kezelve a problémát, "gyorsan" (7 hónap alatt!) javították a hibát. Ez az előadás kiválóan mutatott rá arra, hogy az ICS eszközök és rendszerek gyártói még közel sem képesek olyan reakciókra, mint amit pl. a Microsoft mutatott be az EternalBlue sérülékenység már nem támogatott operációs rendszereik (XP, 2003) esetén történő javításával, amikor szembesültek a WannaCry terjedésének világméretű problémájával. ICS gyártóktól ilyen gyors reakcióidőt jelenleg nem várhatunk, pedig a kockázatok feltehetően sokkal nagyobbak, mint a vállalati IT területén.

- Ben Sterling egy erőművi rendszerben rosszul üzembe helyezett adat-dióda rendellenes működéséből adódó vezérlőrendszeri üzemzavarról tartott előadást, ami ismét hangsúlyozta az ICS rendszerek esetén az OT, a gyártó és az IT/ICS biztonsági szakterületek együttműködésének nélkülözhetetlenségét.

Összességében a saját tapasztalataim alapján úgy gondolom, hogy ez a rendezvény minden ICS területen dolgozó szakember számára hasznos és érdekes rendezvény lehet, még akkor is, ha Atlantába nem éppen egyszerű vagy olcsó eljutni Közép-Európából (bár azt is hozzá kell tennem, hogy az elmúlt két évben végzett kalkulációim alapján az európai ICS biztonsági konferenciák teljes költsége valamivel még magasabb is, mint az atlantai rendezvényé).

Az idei konferenciával kapcsolatos utózöngéket illetve idővel a jövő tavaszi szingapúri rendezvény részleteit a konferencia weboldalán lehet megtalálni: http://www.icscybersecurityconference.com/

süti beállítások módosítása