Évek óta lehet hallani ICS biztonsági szakértőktől (és én is többször írtam már a blogon), hogy az ICS rendszerek kiberbiztonságának első és leginkább hatékony eleme, ha nem tesszük elérhetővé az ipari rendszereket az Internetről, ennek ellenére évről-évre nő az Interneten található ICS rendszerek száma.

Néhány hete a Positive Technologies munkatársai publikálták annak a 2017-ben végzett kutatásuknak az eredményét, aminek keretében több, mint 175.000 Internetre csatlakoztatott ICS rendszert találtak Shodan, Censys és Google keresésekkel.

Protokollok szerinti bontásban a legtöbb Internetről elérhető ICS rendszer HTTP protokollon volt elérhető, ezt követték a Fox épületautomatizálási protokollt és a Honeywell Niagara keretrendszerét használó rendszerek, az Ethernet/IP (ebben az esetben az IP Industrial Protocol-t jelöl), a BACnet és a Lantronix Discovery Protocol-t használó rendszerek.

Gyártók szerint nézve a legtöbb Interneten elérhető eszközt a Honeywell gyártotta , majd a Lantronix, az SMA, a Beck IPC, a Siemens és a Rockwell Automation rendszerei jöttek sorban.

A Positive Technologies publikációja itt érhető el: https://www.ptsecurity.com/upload/corporate/ww-en/analytics/ICS-Security-2017-eng.pdf

GE D60 Line Distance Relay sérülékenységek

Kirill Nesterov, a Kaspersky Lab munkatársa két sérülékenységet azonosított a General Electric D60 Line Distance Relay berendezéseinek 7.11-es és korábbi firmware-verzióiban. Az első hiba egy puffer-túlcsordulás, a második pedig egy memóriakezelési hiba. Mindkét sérülékenység távoli kódfuttatási lehetőséget ad egy, a hibát sikeresen kihasználó támadónak.

A gyártó a hibákat a legújabb firmware-verzióban javítottam, amit már elérhetővé tett a weboldalán.

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

Sérülékenység Nortek rendszerekben

Evgeny Ermakov és Sergey Gordeychik egy 'command injection' sérülékenységet találtak a Nortek Linear eMerge E3 sorozatú eszközeinek V0.32-07e és korábbi verzióiban. A sérülékenységet kihasználva egy támadó magas jogosultsági szintű kódfuttatásra lehet képes.

A gyártó az E3-as eszközök felhasználói programozási útmutatójában (a 47. oldalon) leírt eljárás szerint frissítését javasolja minden, érintett verziót használó ügyfelének.

A sérülékenységről bővebben információkat az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-046-01

Sérülékenységek Cisco ipari tűzfalakban

A Cisco bejelentése szerint egy, a tűzfal-szoftvereiben (mind a régebbi Security Appliance-ekben, mind az új, FirePower termékcsalád modelljeiben) használt XML parser olyan hibát tartalmaz, ami authentikáció nélkül biztosít lehetőséget egy támadónak távoli kódfuttatásra vagy a rendszer újraindítására. A sérülékenység az alábbi verziókat érinti:

- 8.x (a gyártói támogatás már megszűnt);
- 9.0 (a gyártói támogatás már megszűnt);
- 9.1;
- 9.2;
- 9.3;
- 9.4;
- 9.5;
- 9.6;
- 9.7;
- 9.8;
- 9.9.

A hibát a gyártó a következő verziókban javította:

- 9.1.7.23;
- 9.2.4.27;
- 9.4.4.16;
- 9.6.4.3;
- 9.7.1.21;
- 9.8.2.20;
- 9.9.1.2.

A sérülékenységgel kapcsolatban számos további részletet a Cisco publikációjában lehet találni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180129-asa1#vulnerable

Schneider Electric Floating License Manager sérülékenységek

A gyártó bejelentése szerint az alábbi, Schneider Electric Floating License Manager-t használó termékeiben három sérülékenységet azonosítottak:

- SCADA Expert Vijeo Citect / CitectSCADA 7.30-as és 7.40-es verziók;
- CitectSCADA 2015 és 2016;
- Vijeo Historian / Citect Historian 4.40 és 4.50;
- CitectHistorian 2016;
- Citect Anywhere.

A gyártó a hibákat a Floating License Manager v2.1.0.0 verzióban javította.

A sérülékenységről bővebben a Schneider Electric weboldalán lehet olvasni.

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

A Schneider Electric által kiadott biztonsági figyelmeztetés szerint sérülékenység található a Flexera FlexNet Publisher komponensben, amit az alábbi Schneider Electric termékekben használnak:

- EcoStruxure Power Monitoring Expert 8.2 (Standard, DC, HC kiadások);
- StruxureWare Power Monitoring Expert 8.1 (Standard, DC, HC kiadások);
- StruxureWare Power Monitoring Expert 8.0 (Standard, DC, HC, kiadások);
- StruxureWare Power Monitoring Expert 7.2.x;
- Energy Expert 1.x (korábbi nevén Power Manager);
- EcoStruxure Power SCADA Operations 8.x (korábbi nevén PowerSCADA Expert), csak az Advanced Reports and Dashboards modul.

A gyártó a hibát javító patch-eket elérhetővé tette a weboldalán.

A sérülékenység részleteiről a Schneider Electric bejelentésében 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.

Január közepén az AV-TEST antivirus megoldásokat tesztelő cég kiadott egy összefoglalót a kutatásaikról, ami szerint a Spectre/Meltdown néven ismertté vált CPU-sérülékenységekhez megjelent proof-of-concept exploitra építve mostanra több, mint 130 különböző malware-mintát találtak. Bár a minták többsége az eredeti PoC kódra épül, már találtak olyan variánstis, amit JavaScript-ben írtak, így az elterjedtebb böngészők (Internet Explorer, Firefox, Chrome) is támadási kísérletek eszközei lehetnek.

A kutatók szerint az eddig talált malware-minták alapján a támadók még a kódjaik tesztelésénél tartanak, azonban ez azt is jelenti, hogy néhány hónapon belül készen állhatnak, hogy a céljaik (bármi is legyen) elérése érdekében felhasználják a most tökéletesítés alatt álló malware-eket.

A processzor gyártók és operációs rendszer fejlesztők az elmúlt egy hónapban számos mikrokód és szoftverfrissítést adtak ki, amivel próbálják csökkenteni a sérülékenységek jelentette kockázatokat, azonban ezek számos esetben igen komoly stabilitási problémákat okoztak (visszavont frissítései a Microsoft-nak és a RedHat-nek is voltak, a Microsoft pedig soron kívüli patch-et adott ki, hogy a Windows operációs rendszerek blokkolni tudják az Intel x86-os mikrokód frissítését, miután kiderült, hogy a Windows operációs rendszereknél működési zavarok jelentkezhetnek, ha az operációs rendszer nincs felkészítve a processzor mikrokód frissítésére).

Az ICS rendszerek frissítése ilyen körülmények között érthető okokból majdnem biztos, hogy többnyire még a gyártóknál sem kezdődött el, ez pedig azt jelenti, hogy nagyon jó eséllyel ezek a rendszerek önmagukban teljesen védtelenek lesznek, amikor megjelennek az első célzott vagy tömeges támadásokhoz használt malware-ek. Ahhoz, hogy ezt meg lehessen előzni, jelenleg csak egyetlen megoldás látszik, a már unalomig ismételt kockázatcsökkentő intézkedéseket kell mielőbb alkalmazni, elsődlegesen az ICS rendszerek szeparálását a vállalati és nyilvános hálózatoktól.

Vyaire Medical CareFusion Upgrade Utility sérülékenység

Mark Cross független biztonsági kutató egy DLL injectiont lehetővé tevő hibát fedezett fel a Vyaire Medical CareFusion Upgrade Utility nevű, Windows XP-n futó megoldásának 2.0.2.2 és korábbi verzióiban.

A gyártó a 2.0.2.2-es verziót és a Windows XP platformot már nem támogatja, ebben a verzióban és platformon a hibát nem is fogják javítani, helyette a 2.0.3.0 verziót ajánlják, ami Windows 7 és újabb operációs rendszer verziókon fut.

A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-037-01

Schneider Electric IGSS SCADA sérülékenység

Ivan Sanchez, a Nullcode munkatársa helytelenül implementált ASLR (Address Space Layout Randomization) és DEP (Data Execution Prevention) memóriakezelési eljárásokból adódó sérülékenységet talált a Schneider Electric IGSS SCADA V12 és korábbi verzióiban.

A gyártó a hibát a V13-as verzióban javította.

A sérülékenységről bővebb információkat az ICS-CERT és a Schneider Electric publikációiban lehet találni.

Sérülékenység WAGO PFC200 sorozatú berendezésekben

Reid Wightman, a CODESYS munkatársa egy nem megfelelő authentikációból adódó sérülékenységet fedezett fel a CODESYS Runtime alkalmazás alábbi verzióiban:

- CoDeSys Version 2.3.X;
- CoDeSys Version 2.4.X.

A CoDeSys Runtime az alábbi WAGO berendezéseket is érinti, amennyiben azok a 02.07.07(10)-nél korábbi firmware verziót futtatják:

- 750-8202;
- 750-8202/025-000;
- 750-8202/025-001;
- 750-8202/025-002;
- 750-8202/040-001;
- 750-8203;
- 750-8203/025-000;
- 750-8204;
- 750-8204/025-000;
- 750-8206;
- 750-8206/025-000;
- 750-8206/025-001;
- 750-8207;
- 750-8207/025-000;
- 750-8207/025-001;
- 750-8208;
- 750-8208/025-000.

A WAGO a hibákat javító patch-et a FW11-gyel elérhetővé tette.

A sérülékenység további részletei az ICS-CERT publikációjában érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-044-01

Schneider Electric IGSS Mobile (for Andriod and iOS) sérülékenységek

A gyártó két sérülékenységről publikált részleteket, amik az IGSS Mobile for Android 3.01-es és korábbi illetve IGSS Mobile for iOS 3.01-es és korábbi verzióit érintik. Az első sérülékenység egy man-in-the-middle támadást tesz lehetővé, a második pedig a jelszavak olvasható formában történő tárolásából adódik.

A hibát javító verziók már elérhetőek a Google Play illetve Apple Store-okban.

A sérülékenységek részleteit a Schneider Electric által kiadott tájékoztató tartalmazza.

Sérülékenység Schneider Electric StruxureOn Gateway-ekben

A gyártó által kiadott bejelentés alapján a StruxureOn Gateway minden, 1.2-esnél korábbi verziójában megtalálható az a sérülékenység, aminek kihasználásával egy támadó tetszőleges fájlt tölthet fel a sérülékeny rendszerekre és ezen keresztül távoli kódfuttatási jogosultságot szerezhet.

A hibát a gyártó a StruxureOn Gateway 1.2-es verziójában javította.

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

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.

A tegnap reggeli poszt után néhány órával látott napvilágot a hír, hogy a moszkvai nukleáris kutatóközpontban (ahol egyébként az orosz nukleáris fegyverekkel kapcsolatos kutatásokat is végzik), a kutatásokhoz használt szuperszámítógépen találtak cryptovalutát bányászó szoftvert.

Az incidens ebben az esetben a jelek szerint nem egy sikeres támadáskövetkezménye volt, hanem a központban dolgozó mérnökök közül néhányan úgy gondolták, hogy nem probléma, ha a kutatásokhoz használt szuperszámítógép teljesítményének egy részét cryptovaluta bányászatára fordítják. Az incidensért felelős mérnököket a hírek szerint akkor kapták rajta, amikor a szuperszámítógépet az Internetre próbálták csatlakoztatni - ez nem volt kifejezetten jó ötlet a részükről, mert ennek köszönhetően kerültek az orosz Szövetségi Biztonsági Szolgálat, az FSZB őrizetébe.

Ez az eset is kiválóan mutatja, hogy bár nagyon fontosak azok a műszaki biztonsági intézkedések, amikről én is rendszeresen írok a blogon, az egész nem sokat ér, ha a kritikus infrastruktúrákat üzemeltető emberek biztonságtudatossága nem megfelelő - és ez egy olyan feladat, aminek soha nem lehet a végére érni.

A részletekről számos különböző hírforrás beszámolt, többek között:

BBC - http://www.bbc.com

TheHackerNews - https://thehackernews.com

ArsTechnica - https://arstechnica.com

Ahogy az elmúlt év végén a cryptovaluták értéke soha nem látott magasságokba emelkedett, úgy nőtt az azt bányászó malware-ek és a velük végrehajtott támadások száma is. Egyes hírek szerint a WannaCry néven elhíresült (és több ICS rendszer leállításában is szerepet játszó) malware-hez hasonlóan az EternalBlue exploitot kihasználva terjedő, de ezúttal nem ransomware-ként, hanem cryptobányászként viselkedő malware kezd terjedni, aminek az IT biztonsági szakma a WannaMiner nevet adta. Mostanáig ezek a cryptobányász malware-támadások nem érintettek ICS rendszereket (vagy legalábbis publikusan ilyen hír nem volt elérhető), a héten azonban ez is megváltozott. Egy európai szennyvízkezelő cég Windows XP-alapú GE Digital CIMPLICITY SCADA szerverein a Monero cryptovalutát bányászó malware-t talált a Radiflow nevű IT biztonsági cég.

Az incidenssel kapcsolatban már több cikk is megjelent, a részleteket az eWeek és a SecurtiyWeek oldalain lehet olvasni.

Kérdésből persze több is felmerül az emberben, de a válaszok egyáltalán nem adnak okot bizakodásra.

1. Meglepő-e, hogy az ICS rendszereket is elérték a cryptobányász malware-ek? A válasz röviden: nem. Ahogy ebben az esetben is látható, a SCADA szoftver egy kb. 5 éve nem támogatott operációs rendszerre volt telepítve, vagyis a rendszerben számos olyan ismert és nem javított hiba van, amit egy támadó kihasználhat, hogy saját kódot futtasson. Ha ehhez hozzátesszük azt a tényt, hogy az ICS biztonsági szakma minden erőfeszítése ellenére folyamatosan nő az Internetről elérhető ICS rendszerek és berendezések száma, csak az meglepő ebben az incidensben, hogy nem került napvilágra jóval korábban egy hasonló eset.

2. Mire lehet számítani a jövőben? Véleményem szerint a hasonló incidensek száma nőni fog - az persze nem világos, hogy ezek mekkora hányada lesz publikálva, de abban biztos vagyok, hogy a helyzet nem fog javulni, sőt romlani fog.

Mit lehet tenni, hogy megelőzzünk egy hasonló incidenst?

Elsősorban az ICS biztonsági szakértők által gyakran hangoztatott intézkedéseket kell bevezetni illetve fenntartani, ha már bevezették:

- Az ICS berendezéseket és rendszereket nem szabad publikus hálózatokra csatlakoztatni!
- Az ICS és vállalati IT rendszereket megfelelő hálózati szegmentálással kell egymástól elválasztani! Ennek tervezéséhez és megvalósításához a Purdue-modell ad némi kapaszkodót.
- A megfelelő hálózati szegmentálás után mélységi védelmet kell kiépíteni! Ehhez én célszerűnek tartom különböző gyártók különböző működési elvre épülő megoldásainak kombinálását (pl. eltérő gyártó végpontvédelmi megoldásainak alkalmazását a vállalati és ipari hálózatokban működő számítógépeken, különböző gyártóktól származó tűzfalak, stb. használatát).
- A megelőzés mellett fel kell készülni arra is, ha a támadók bizonyulnak jobbnak és átjutnak a kiépített védelmi vonalakon, megfelelő incidens észlelési képességeket kell kialakítani! Az ICS rendszerek nagyfokú statikussága ebben az esetben nagy segítség lehet, hiszen a jóval ritkább és kisebb számú változás mindegyikét ki lehet vizsgálni, ha a megfelelően képzett szakemberekből álló csapat rendelkezésre áll.
- Jól átgondolt és rendszeresen tesztelt incidenskezelési eljárásokat kell kialakítani és begyakoroltatni az abban résztvevő munkatársakkal!

A fenti (értelemszerűen nem teljes) lista persze nem fog senkit 100%-os biztonsággal megmenteni egy hasonló incidenstől, de esélyt biztosít arra, hogy a támadási kísérletek nagyobb hányadát tudják elhárítani és ha a támadók mégis bejutnának az ICS rendszerekbe, minél előbb képesek legyenek észlelni az incidenst, kizárni a támadókat és megszüntetni a tevékenységük negatív hatásait.

Fuji Electric V-Server sérülékenység

Ariele Caltabiano, a kimiya néven is ismert biztonsági kutató a ZDI-vel együttműködve publikált egy puffer-túlcsordulásra visszavezethető sérülékenységet, ami a Fuji Electric V-Server VPR adatgyűjtő és kezelő rendszerének 4.0.1.0 és korábbi verzióit érinti.

A gyártó a hibát a 4.0.3.0 verzióban javította.

A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-032-01

Sérülékenység CODESYS webszerverekben

Zhu WenZhe, az Istury IOT biztonsági labor munkatársa szintén egy puffer-túlcsordulásos hibát fedezett fel a 3S-Smart Software Solutions GmbH által gyártó CODESYS webszerverének minden, 2.3-nál korábbi Windows-alapú verziójában. A hiba a CODESYS runtime system minden, V1.1.9.19-nél korábbi verzióját is érinti.

A sérülékenységet a gyártó a V1.1.9.19-es patch-ben és a CODESYS V2.3 web server for Windows verziókban fogja javítani.

A sérülékenységgel kapcsolatos további információkat az ICS-CERT publikációjában található: https://ics-cert.us-cert.gov/advisories/ICSA-18-032-02

Sérülékenységek Gemalto Sentinel License Manager-ben

A Kaspersky Lab munkatársai több hibát is találtak a Gemalto Sentinel License Manager termékében. A sérülékenységek minden HSP SRM, Sentinel HASP és Sentinel LDK terméket érintenek, ha azokon a Sentinel LDK RTE 7.55-nél korábbi verzió fut.

A hibák között DoS-támadáshoz használható null pointer hivatkozás, több puffer-túlcsordulás és nem megfelelő hozzáférés-kezelés is található.

A gyártó a hibákkal kapcsolatban azt javasolja az érintett verziókat használó ügyfeleinek, hogy frissítsék az általuk hasznlát Sentinel LDK RTE verzióját 7.6-ra vagy az elérhető legújabb verzióra.

A sérülékenységről bővebben az ICS-CERT bejelentésében vagy a Kaspersky Lab cikkében lehet olvasni.

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Tavaly decemberben elég nagy port kavart ICS biztonsági körökben a hír, hogy egy meg nem nevezett Közel-keleti országban egy olyan ICS malware-t fedeztek fel, ami a Schneider Electric Triconex SIS rendszerét fertőzte meg. Ezt volt az ICS malware-ek sorában az első olyan kártevő, ami kifejezetten SIS rendszer ellen készült.

A hét elején egy nagyon érdekes kérdéseket feszegető blogposzt jelent meg a SANS Industrial Control Systems Security Blogon.

A legnyilvánvalóbb kérdés továbbra is az, hogy vajon miért az SIS rendszert vették célba a támadók? Amennyire a jelenleg rendelkezésre álló információk alapján meg lehet ítélni, ennek a támadásnak csak kétféle célja lehetett:

1. Az SIS által felügyelt folyamatok teljes leállítása
2. A biztonsági leállítási folyamatok akadályozása, szabotálása

Az igazán érdekes kérdés pedig az: hol van a Triton/TriSIS DCS-t, a létesítmény vezérlő rendszerét célzó párja?

További részleteket és a blogbejegyzéshez hasonlóan érdekes hozzászólásokat a fent hivatkozott bejegyzésben lehet olvasni.

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

A ZDI-nek az rgod néven tevékenykedő biztonsági kutató jelentett két, eddig nem ismert sérülékenységet, amik az Advantech WebAccess/SCADA (korábban WebAccess) V8.2_20170817-nál korábbi verzióit érintik.

A hibák között egy könyvtárbejárásos támadást lehetővé tevő és egy SQL injection sérülékenység található.

Az Advantech a hibákat a WebAccess/SCADA 8.3.0 verziójában javította.

A sérülékenységgel kapcsolatos részleteket az ICS-CERT bejelentése tartalmazza: https://ics-cert.us-cert.gov/advisories/ICSA-18-023-01

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

Az ICS-CERT bejelentése szerint egy, a nem megfelelő munkamenet lejáratból adódó hibát azonosítottak a Philips által gyártott, szív- és érrendszeri képalkotó és adatkezelő rendszereinek 2.3.0 és korábbi verzióiban.

A gyártó jelenleg is dolgozik a hiba javítását tartalmazó új verzión.

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

Siemens Desigo PXC berendezések sérülékenysége

Can Demirel és Melih Berk Eksioglu a Biznet Bilisim munkatársai egy nem megfelelő authentikációból adódó sérülékenységet azonosítottak a Siemens Desigo PXC V6.00.204-nél korábbi verziójú termékei:

- Desigo Automation Controllers Compact PXC12/22/36-E.D;
- Desigo Automation Controllers Modular PXC00/50/100/200-E.D;
- Desigo Automation Controllers PXC00/64/128-U Web modullal;
- Desigo Automation Controllers for Integration PXC001-E.D;
- Desigo Operator Unit PXM20-E.

A Siemens a hibát a V6.00.204 és újabb verziókban javította.

A sérülékenységről további részleteket az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-025-02

Sérülékenység Nari rendszerekben

Kirill Nesterov és Alexey Osipov Kaspersky Labs munkatársai egy, a bevitt adatok nem megfelelő ellenőrzéséből adódó sérülékenységet azonosítottak a Nari PCS-9611-es relé, vezérlő és monitoring berendezéseiben.

A gyártó mostanáig semmilyen információt vagy javítást nem adott ki a sérülékenységgel kapcsolatban.

A sérülékenységről az ICS-CERT bejelentése tartalmaz bővebb információkat: https://ics-cert.us-cert.gov/advisories/ICSA-18-025-01

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

A Siemens ProductCERT három sérülékenységet azonosított a TeleControl Server Basic nevű termékének V3.1-nél korábbi verzióiban. A hibák között authentikáció megkerülést lehetővé tevő, jogosultság kezelést érintő és szolgáltatás-megtagadásos támadást lehetővé tevő hiba is található.

A gyártó a hibák javítása érdekében a legújabb elérhető TeleControl Server Basic verzióra történő frissítést javasolja.

A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenység Phoenix Compact mGuard ipari hálózati eszközökben

A Phoenix Contact egy nem megfelelő integritás-ellenőrzésből adódó hibát azonosított az mGuard firmware-ek 7.2-től 8.6.0-ig terjedő verzióiban.

A hibát a gyártó a 8.6.1-es firmware-verzióban javította, amit az alábbi termékekhez a weboldaláról lehet letölteni:

- MGUARD CENTERPORT;
- MGUARD DELTA TX/TX;
- MGUARD DELTA TX/TX VPN;
- MGUARD GT/GT;
- MGUARD GT/GT VPN;
- MGUARD PCI4000 VPN;
- MGUARD PCIE4000 VPN;
- MGUARD RS2000 TX/TX VPN;
- MGUARD RS2000 TX/TX-B;
- MGUARD RS2005 TX VPN;
- MGUARD RS4000 TX/TX;
- MGUARD RS4000 TX/TX VPN;
- MGUARD RS4000 TX/TX VPN-M;
- MGUARD RS4000 TX/TX-P;
- MGUARD RS4004 TX/DTX;
- MGUARD RS4004 TX/DTX VPN;
- MGUARD SMART2;
- MGUARD SMART2 VPN;
- MGUARD RS2000 3G VPN;
- MGUARD RS4000 3G VPN;
- MGUARD CORE TX VPN;
- MGUARD RS2000 4G VPN;
- MGUARD RS4000 4G VPN.

A sérülékenység részletei az ICS-CERT bejelentésében találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-030-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.

Az IOActive nevű kiberbiztonsági cég munkatársai nemrég egy új tanulmányukat tették elérhetővé, amiben a különböző gyártók mobil eszközökre, tabletekre és okostelefonokra írt ICS alkalmazásainak sérülékenységeit vizsgálták.

Az ICS kiberbiztonsági szakemberek elég gyakran síkra szállnak amellett, hogy az ICS rendszerek ne jelenjenek meg az Interneten, ennek ellenére a nevesebb gyártók (és minden bizonnyal a kevésbé ismertek is) szoftverek minden gond nélkül elérhetőek a nagyobb alkalmazás-áruházakban.

A kutatás során az IOActive munkatársai a 34 legnépszerűbb Android-ra elérhető alkalmazásban nem kevesebb, mint 147 különböző sérülékenységet azonosítottak. Ha abból indulunk ki, hogy a tavalyi évben itt a blogon egész évben alig háromszor ennyi ICS sérülékenységről írtam (és ahogy néhány hete a statisztikákat néztem, már ez a szám is egy nagyon erős, több, mint 150%-os növekedés után lett ennyi), akkor a 147 mobilos ICS alkalmazás sérülékenység egy hihetetlenül magas szám.

A teljes tanulmány elérhető az IOActive blogján: http://blog.ioactive.com/2018/01/scada-and-mobile-security-in-iot-era.html