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

December közepén én is írtam a arról a malware-támadásról, ami a hírek szerint egy szaúdi ipari szervezet Schneider Electric által gyártó SIS rendszerét (Safety Instrumented System) érte. A Triconex nevű SIS rendszer elleni támadásról a gyártó az elmúlt héten (január 16-a és 18-a között) Miami-ban tartott S4x18 konferencián osztott meg újabb részleteket. Vizsgálataik alapján a támadók egy nulladik napi sérülékenységet találtak a Triconex SIS rendszerben és ezt kihasználva juttattak egy RAT (Remote Access Trojan) kártevőt a megtámadott SIS rendszerbe. A Schneider Electric szakemberei szerint ez a malware az első RAT a malware-ek sorában ami képest volt SIS rendszert megfertőzni.

Az S4x18 konferencián a témában elhangzott további részletekről a DarkReading cikkében lehet olvasni: https://www.darkreading.com/vulnerabilities---threats/schneider-electric-triton-trisis-attack-used-0-day-flaw-in-its-safety-controller-system-and-a-rat/d/d-id/1330845

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

Több biztonsági kutató összesen hét különböző sérülékenységet fedezett fel az Advantech WebAccess 8.3-nál korábbi verzióiban. A hibák között Untrusted Pointer Dereference, puffer-túlcsordulás, könyvtárbejárást lehetővé tevő hiba, SQL injection, a bevitt adatok nem megfelelő ellenőrzése, a feltöltött fájlok nem megfelelő ellenőrzése és memóriakezelési hiba is található.

A hibákat a gyártó a WebAccess 8.3-as verziójában javította.

A sérülékenységekkel kapcsolatos részletekről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-004-02A

Delta Electronics rendszerek sérülékenységei

Steven Seeley, a Source Incite munkatársa 4 sérülékenységet azonosított a Delta Industrial Automation Screen Editor 2.00.23.00 és korábbi verzióiban. A hibák között puffer-túlcsordulás, különböző memóriakezelési hibák is találhatóak.

A gyártó a hibákat a DOPSoft Version 2-ben javította.

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

Sérülékenységek General Motors és Shanghai OnStar iOS kliensekben

Charles Gans három sérülékenységet fedezett fel a GM által is használt Shanghai OnStar rendszerek iOS klienseinek 7.1-es verziójában. A hibák között érzékeny adatok olvasható formában történő tárolása, man-in-the-middle támadásra lehetőséget adó hiba és nem megfelelő authentikáció is található.

A rendelkezésre álló információk alapján javítás a fenti hibákra még nem érhető el. A GM kockázatcsökkentő intézkedéseket javasol ügyfelei számára. A kockázatcsökkentő intézkedések és a sérülékenységek részletei az ICS-CERT bejelentésében olvashatóak: https://ics-cert.us-cert.gov/advisories/ICSA-17-234-04

Rockwell Automation kontrollerek sérülékenysége

Thiago Alves, az alabamai egyetem munkatársa jelentett egy puffer-túlcsordulási hibát, ami az Allen-Bradley MicroLogix 1400-as sorozatú kontrollereinek B és C sorozatú verzióit érinti, amennyiben a 21.002 vagy korábbi firmware-verziók valamelyikét futtatják:

- 1766-L32AWA
- 1766-L32AWAA
- 1766-L32BWA
- 1766-L32BWAA
- 1766-L32BXB
- 1766-L32BXBA

A hibát a gyártó a 21.003-as verziójú firmware-ben javította.

A sérülékenységgel kapcsolatos részletek az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-009-01

Sérülékenységek Phoenix Contact hálózati eszközökben

Ilya Karpov és Evgeniy Druzhinin, a Positive Technologies munkatársai két sérülékenységet azonosítottak, amik a Phoenix Contact 3xxx, 4xxx és 48xxx sorozatú switch-einek 1.0-tól 1.32-ig terjedő firmware-verzióiban találhatóak meg. A hibákat kihasználva lehetőség van authentikációs hibákat kihasználni és bizalmas adatokhoz hozzáférni.

A hibákat a gyártó az 1.33 és későbbi verziókban javította.

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-011-03

Sérülékenység Moxa MXView hálózatmenedzsment szoftverekben

Karn Ganeshen egy könyvtárbejárást lehetővé tevő hibát azonosított a Moxa MXview v2.8 és korábbi verzióiban. A gyártó a hibát a v2.9-es verzióban 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-18-011-02

Sérülékenységek WECON rendszerekben

Több biztonsági kutató munkájaképpen két, puffer-túlcsorduláson alapuló sérülékenységet azonosítottak a WECON LEVI Studio HMI Editor nevű termékének v1.8.29 és korábbi verzióiban. A gyártó a hibákat a legújabb verzióban javította.

A sérülékenységekkel kapcsolatos további információkat az ICS-CERT vonatkozó publikációjában lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-011-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.

December utolsó napjaiban ismét megrendezték a német Chaos Computer Club éves konferenciáját, a Chaos Computer Conference-t, rövidebb nevén a C3-at. Az idei volt a 34. alkalom, ezért a tradícionális elnevezés, 34C3.

Idén egyetlen ICS témájú előadást találtam, ami elérhető YouTube-on, ezt Thomas Roth tartotta, aki a különböző ICS gateway-ek sérülékenységeiről és az ezek kihasználásához szükséges támadási módokról beszélt. Az előadás felvételét itt lehet megtalálni: https://www.youtube.com/watch?v=Itgwb3rn7gE

A héten két, az IT biztonsági szakma és a mainstream sajtó által egyaránt széles körben tárgyalt sérülékenységről publikáltak részleteket. Az x86-os architektúrájú CPU-k (jellemzően Intel és AMD) mellett az ARM processzorok is érintettek, ez pedig azt jelenti, hogy az IT eszközök bőven több, mint 90%-a érintett lehet. A legnagyobb operációs rendszer gyártók némelyike (Microsoft, RedHat, a Google az Android esetén, stb.) már kiadta vagy kiadni készül olyen frissítéseket, amikben javítják a hibákat, de ismerve az egyes szervezetek és felhasználók patch-elési szokásait, ezek a hibajavítások még jó esetben is hetekig, rosszabb esetben évekig nem lesznek telepítve - és ez is csak azokra a platformokra vonatkozik, ahol van/lesz elérhető frissítés (elég a különböző, nagy mobil eszköz gyártó vállalatok egyedi Andoid-verzióira gondolni, amikhez viszonylag gyorsan, kb. a következő modell megjelenésekor megszűnik a támogatás).

Mit is jelent ez a két sérülékenység az ICS rendszerek/eszközök üzemeltetői számára? Mivel a legtöbb ICS berendezés és rendszer az érintett CPU architektúrákra épül, ezért nagyjából biztosan állíthatjuk, hogy az ICS rendszerek döntő többsége érintett lehet. Tovább rontja a helyzetet, hogy az ICS rendszerek esetén még abban az esetben is lassan szoktak hibajavításokat telepíteni, ha a gyártó kiad hibajavításokat az adott eszközökhöz (és ahogy a héten korábban erről már írtam, az ICS világában az IT-nál sokkal gyakoribb a gyártói támogatással már nem rendelkező eszközök akár hosszú éveken át történő használata). Ráadásul napjainkban a SCADA és DCS rendszerek túlnyomó többsége már x86-os CPU-kra és Windows/Linux operációs rendszerekre épül, amikhez ugyan a hírek szerint legalábbis részben már elérhetőek a javítások, de a SCADA/DCS-gyártók jellemzően csak a saját, laborban végzett teszteléseik után szoktak engedélyt adni az ügyfeleiknek a patch-ek SCADA/DCS rendszerekre történő telepítésére, az üzemeltetők pedig ezt szinte minden esetben megvárják, mert nem akarják a rendszereik gyártói garanciáját kockázatatni egy, a gyártó által jóvá nem hagyott patch telepítésével. Sajnos az is nagyon elterjedt gyakorlat az ICS rendszerek világában, hogy a patch-eket még az esetlegesen már meglévő gyártói jóváhagyás esetén sem telepítik, úgy gondolva, hogy ezeket a rendszereket az ilyen sérülékenységeket kihasználó malware-ek és támadók úgy sem lesznek képesek elérni - arról pedig már számtalanszor írtam én is itt a blogon, hogy ezek a hiedelmek milyen károsak és hány esetben bizonyították sikeres támadások ennek az ellenkezőjét.

Ebben az esetben (illetve esetekben) tovább bonyolítja a helyzetet, hogy ez első hírek szerint a már elérhető patch-ek alkalmazása után az érintett rendszereknél jelentős (a hírek 5-30, időnként 50%-os) performancia-vesztés jelentkezett a hibajavítás előtti állapothoz képest, márpedig az ICS rendszerek döntő többsége jellemzően nem rendelkezik ekkora performancia-tartalékkal. Egyes SCADA és DCS rendszereknél láttam olyan méretezést, ahol a rendszer névleges teljesítménye legalább a rendszer tervezett csúcsteljesíményének a kétszerese, de egyrészt ezek a performancia-tartalékok azért vannak az adott rendszerekben, hogy a stabil működést garantálják minden esetben, másrészt számos olyan eszköz van (különösen a lvl1-lvl0 eszközök), ahol alig valamekkora performancia tartalék áll rendelkezésre. Ebbe a kicsi tartalékba az 5% talán még beleférhet egyes eszközöknél, de a 30-50% biztosan nem. Ismerve az ICS fejlesztők és üzemeltetők gondolkodását, ezeknél a rendszereknél és eszközöknél el fognak tekinteni a sérülékenységek patch-elésétől, ekkor pedig csak az ICS sérülékenységeknél gyakran ismételt kockázatcsökkentő intézkedések maradnak lehetőségként, hogy a sérülékeny rendszereket valahogyan megpróbálják a szakemberek megvédeni azoktól a támadási kísérletektől, amit az IT biztonsági szakma már most biztosra vesz a következő néhány hétben-hónapban.

Én minden esetre azt javaslom minden ICS rendszert üzemeltető kollégának, hogy vizsgálja meg a rendszereit és egyeztessen a gyártókkal, hogy az általa használt rendszerek/berendezések érintettek-e és elérhetőek-e már a javítások. Ha pedig van a gyártó által jóváhagyott javítás, kezdjen egyeztetéseket az érintett szakterületekkel a javítások telepítésének a lehetőségeiről.