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

ICS Cyber Security blog

ICS Cyber Security blog

Vasúti jelzőrendszerek biztonsága II

2016. december 10. - icscybersec

Az előző heti posztban a vasúti vezérlésért felelős rendszerek biztonságát kezdtem el áttekinteni. Az általánosságok után most egy kicsit mélyebben fogom vizsgálni a vasúti vezérlőrendszerek egyedi komponenseit és fenyegetettségeit.

Vasúti rendszerek jellemző fenyegetései

A CBCS rendszerekkel kapcsolatban jellemzően három fő fenyegetési csoportot szoktak említeni:

- A vonatok mozgásának biztonságával kapcsolatos fenyegetéseket;
- Olyan fenyegetések, amelyek csökkenthetik vasúti kapacitások hatékony kihasználását, illetve egyéb gazdasági hatékonyságot rontó tényezők;
- A funkcionális biztonságot és megbízhatóságot rontó fenyegetések, amelyek indirekt módon hatnak a vasút üzemeltetésére és biztonságára.

A vasúti biztonság kompromittálása szakértők szerint az egyik legnehezebben elérhető cél a támadók számára, mert először meg kell kerülniük a számítógépes biztosító berendezések (Computer-based Interlocking, CBI) funkcionális biztonsági mechanizmusait. Ha ezeket nem tudják távolról (pl. rádiós kommunikációs csatornán keresztül) kompromittálni, akkor a biztosító rendszer moduljainak működési logikáját kell célba venniük, ami igen bonyolult. Ha azonban egy támadó el tud jutni idáig, akkor képes lehet manipulálni a jelző és vezérlő berendezéseket (pl. szabad jelzést adni egy pályaszakaszon, egy áthaladó szerelvény alatt működtetni a váltóberendezést vagy akár szerelvények összeütközéséhez vezető módosításokat végrehajtani).

Ezeket a fenyegetéseket nem csak a napjainkban egyre többször emlegetett, gyakran állami háttérrel rendelkezőnek feltételezett támadók jelentik, hanem a teljesen hétköznapi (bár egyáltalán nem barkács-módon fejlesztett) malware-ek (pl. Conficker) is elő tudják idézni (ahogy ezt láthattuk nemrég a németországi gudmingeni atomerőművet érinti incidens esetén is), ez akár még egy nem célzott támadás esetén is komoly üzemzavarhoz vezethetnek.

A számítógépes vasúti vezérlőrendszerek fenyegetéseinek modellezéséhez alapvető lépés, hogy a CBI rendszer komponenseinek, funkcionális moduljainak, ezek működésének illetve sérülékenységeinek megismerése. Ezek részletes ismertetése túlmutat a mai poszt keretein, ezért csak felsorolom a legfontosabb komponenseket és főbb funkcióikat:

- Központi feldolgozó egység (CP/CPU) - ez a komponens fogadja a munkaállomásoktól és egyéb rendszerektől érkező információkat, feldolgozza azokat és ellenőrzi, hogy az egyes utasítások elfogadhatóak-e a szerelvény helyzete és a jelző- és vezérlőrendszerek állapota alapján. A CP/CPU-k célszoftvereket futtatnak, azonban teljesen átlagos operációs rendszerekkel működnek - ezért is jelentenek a hétköznapi malware-ek fenyegetést számukra.
- A biztosítóberendezés feldolgozó egysége (Interlocking Processing Unit) gyakran része a CP/CPU-nak hajtja végre azokat a főbb utasításokat, amik a váltó- és jelzőrendszereket irányítják. Ezek biztosítják a vasútbiztonsági szabályoknak való megfelelést is.
- A berendezések vezérlői (Object Controllers, OC) fogadják a CP/CPU-tól érkező utasításokat és alakítják át őket vezérlési jelekké a vasúti pályán működő berendezések számára, majd küldik vissza a berendezések állapotáról szóló információkat.
- Az üzemeltető és kiszolgáló személyzet munkaállomásai a vasúti folyamatvezérlő rendszer HMI berendezései, ezekről tudják ellenőrizni a szerelvények helyzetét, a jelzőberendezések és váltók állapotát és utasításokat is küldeni ezeknek. Ezek a munkaállomások jellemzően specializált szoftvereket futtatnak, időként még beépített biztonsági funkciókkal is rendelkeznek, azonban itt is leginkább általános célú operációs rendszerek (gyakran Windows-t) használnak. Emiatt is meglehetősen nagy támadási felületet jelentenek, hiszen számos úton (hálózaton, USB portokon, stb.) lehetséges támadni őket.
- A hálózati kommunikáció ugyanúgy gyenge pontja a számítógépes vasúti vezérlőrendszereknek, mint minden más ICS rendszernek, ebben az esetben is szabványos és specializált (időnként elavult) protokollokon kommunikálnak a rendszerek elemei egymással. A távoli adminisztrációs lehetőségek szintén növelik ezeknek a rendszereknek a kockázatait.

A vasúti rendszerekkel kapcsolatos támadási lehetőségek elemzése során mindenképp szem előtt kell tartani, hogy ezeknek a rendszereknek számos komponense nem hasonlít az informatikában megszokott eszközökhöz - ez persze a különböző ipari rendszerek biztonságával foglalkozó szakemberek számára nem újdonság, de a vasúti rendszerek biztonságával foglalkozó emberek jellemzően nem más iparágakban már tapasztalatot szerző szakemberek, hanem általában a vállalati IT biztonság területéről érkeznek, nekik pedig ezek a különbségek elsőre meglepőek lehetnek. Ahogy korábbi posztokban már említettem, az ipari rendszereknél a biztonság (safety) elsődleges prioritás, minden más szempontnál fontosabbak, így a hiba esetén biztonságos állapotba történő visszatérésük (fail-safe mechanizmusok) is minden másnál fontosabbak, a központi feldolgozó egységek (CP/CPU-k) működése is ezt a funkciót célozza.

Ahhoz, hogy egyenszilárd kiberfenyegetettségi modellt lehessen kidolgozni a vasúti rendszerekre vonatkozóan, pontosan azonosítani kell a támadások során célba vett hozzáférési pontokat. A vasúti rendszerek esetén (hasonlóan más, legalább részben informatikai eszközökből épült rendszerekhez) a támadások legvalószínűbb célpontjai azok a külső interfészek lesznek, amiken keresztül a támadók hozzáférést szerezhetnek a rendszer egyes komponenseihez. A vasúti rendszerek, nagy földrajzi kiterjedésük miatt jelentős mértékben építhetnek a vezeték nélküli kommunikációs megoldásokra, illetve szintén a nagy távolságok miatt a fizikai távközlési vonalakra történő illegális rácsatlakozás sem lehetetlen.

A támadások egyaránt lehetnek helyi és távolról végrehajtott támadások. A helyileg végrehajtott támadások gyakran függnek attól, hogy milyen típusú interfészen keresztül próbálnak meg a támadók hozzáférni a rendszerhez. Ilyen támadási forma lehet például a jelzőberendezések áramellátásának manipulálása vagy a vasúti pálya mellett működő vezérlőberendezésekre történő fizikai rácsatlakozás. Ugyanakkor a vasúti pálya mellé telepített vezérlőberendezések egy része ma már rádiós kommunikációra is képes, ezeket akár távolról is lehet támadni. A kommunikációs csatornák és hálózati protokollok elleni támadásokhoz akár egy általános (pl. Windows) operációs rendszerre fejlesztett malware is elegendő lehet - erre is láttunk már példát a múltban.

Ahhoz, hogy egy ilyen támadás sikeres legyen, persze át kell jutni a CBI-t az ügyviteli hálózatoktól és az Internettől elválasztó átjárókon és egyéb határvédelmi megoldásokon, azonban ahogy egyre gyakrabban látható, hogy ICS rendszerek és komponenseik (RTU-k, PLC-k, soros-Ethernet átalakítók, stb.) lesznek elérhetőek az Internetről, egyre valószínűbbnek tartom, hogy már ma is hozzá lehetne férni egyes vasúti rendszerekhez - ha pedig tévedek és nincs így, akkor is napról-napra közelebb járunk ehhez. Mindennél fontosabb, hogy az emberéletek megóvásáért is felelős rendszerek izoláltsága fennmaradjon, ha pedig már sérült, akkor minél előbb legyen megszüntetve a kapcsolat a publikus hálózatok és a CBI/CBCS rendszerek között.

A CP/CPU-k és IPU-k rendelkeznek olyan mechanizmusokkal, amelyek a rendszerek működésének sértetlenségét hivatottak biztosítani és meg kell előzniük váltók jogosulatlan módosításait, ezek csökkentik ugyan egy sikeres támadás esélyét, de a kommunikációs csatornák és a vasúti pálya mentén működő eszközök elleni támadásokkal vagy egy közbeékelődéses támadással jóval könnyebben lehet a rendszer adatait manipulálni. Ugyanígy célpontot jelenthetnek a CBCS munkaállomásai, illetve a munkaállomások és a CP/CPU-k közötti kommunikációra hálózati protokollok is. A rendszerben használt operációs rendszerek (pl. a munkaállomásokon futó példányok) sérülékenységei szintén támadások célpontjává teheti magát a CBI rendszert is, ennek használhatatlanná tétele komoly fennakadásokat okozhat a vasúti közlekedésben, súlyosabb esetben a legfontosabb szempontok, a biztonság (safety) és a megbízhatóság is veszélybe kerülhetnek.

A CBCS modellek használatával végzett fenyegetés-elemzések segíthetnek feltárni a legvalószínűbb támadási formákat és azokat a biztonsági mechanizmusokat, amikkel meg lehet előzni, hogy a támadók sikerrel járjanak. A vasúti rendszerek kiberbiztonságának kialakításához egyszerre kell tanulmányozni a vasúti forgalom és funkcionális biztonság egyedi vonásait és az IT biztonság helyzetét, ezzel segítve annak megértését, hogyan működik a vasút és hogyan értékelik a vasúton dolgozók az olyan negatív hatású eseményeket, amik az emberek biztonságát és a vasút megbízható működését veszélyeztetik. Ezek együttes megértése és elemzése fogja lehetővé tenni, hogy a kiberbiztonsági eljárásokat hatékonyan integrálni lehessen a vasútbiztonsági és üzemeltetési eljárásokba.

ICS sérülékenységek LXXVI

Sérülékenységek Moxa, Sauter, Adcon Telemetry, INTERSCHALT és Siemens termékekben

A mai nap ismét erős volt, ami a különböző ICS rendszerek sérülékenységeit illeti, 5 különböző gyártó termékeivel kapcsolatban jelentek meg sérülékenységi információk.

Moxa MiiNePort sérülékenységek

Aditya Sood, független biztonsági kutató két hibát talált a Moxa MiiNePort alábbi verzióiban:

- MiiNePort E1 1.8-nál korábbi verziói;
- MiiNePort E2 1.4-nél korábbi verziói;
- MiiNePort E3 1.1-nél korábbi verziói.

Az egyik hibát az okozza, hogy a konfigurációs adatok az érintett MiiNePort rendszerekben titkosítás nélkül kerül tárolásra, a másik hiba pedig lehetővé teszi egy támadó számára, hogy brute-force támadást hajtson végre a rendszer által használt cookie-k ellen és ezen keresztül konfigurációs fájlokat töltsön le.

A gyártó az alábbi linkeken elérhetővé tette a hibákat javító firmware-verziókat:

- MiiNePort E1 sorozat - 1.8-as verzió;
- MiiNePort E2 sorozat - 1.4-as verzió;
- MiiNePort E3 sorozat - 1.1-as verzió;

Továbi információkat a hibákkal kapcsolatban az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-16-343-01

Sauter NovaWeb sérülékenység

Az ICS rendszerek sérülékenységeinek fáradhatatlan kutatója, Maxim Rupp fedezett fel egy authentikáció megkerülést lehetővé tevő hibát a Sauter NovaWeb nevű webes HMI alkalmazásában. A hiba a NovaWeb web HMI-k összes verziójában megtalálható és az általa használt cookie-k nem megfelelő ellenőrzése lehetőséget adhat egy támadónak a rendszerbe épített authentikációs mechanizmus megkerülésére.

A gyártó az érintett termékhez 2013 óta nem biztosít támogatást, ezért ezt a hibát sem fogják javítani.

A hibáról többet az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-16-343-02

Sérülékenységek az Adcon Telemetry A850 Telemetry Gateway bázisállomásában

Az Adcon Telemetry A850 Telemetry Gateway nevű termékében ismét Aditya Sood talált egy XSS hibát, ami az A850 Telemetry Gateway bázisállomások összes verzióját érinti.

A gyártó az A850 Telemetry Gateway-ekhez kiadott legfrissebb firmware-ben javította a hibát.

A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-343-03

INTERSCHALT VDR G4e sérülékenység

A német INTERSCHALT VDR G4e nevű, tengerhajózásban használt úti adatrögzítő rendszerében Maxim Rupp talált egy könyvtárbejárást lehetővé tevő hibát, ami az 5.220-as és ennél korábbi verziókat érinti.

A gyártó a hibát az 5.230-as verzióban javította és minden ügyfelének a mielőbbi frissítést javasolja.

A hibáról több információt az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-343-04

Az ICS-CERT a fenti hibákkal kapcsolatban ezúttal is a szokásos kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

Sérülékenységek Siemens SIMATIC WinCC, SIMATIC PCS7 rendszerekben, valamint S7-300 és S7-400 kommunikációs processzorokban

A SIMATIC WinCC és SIMATIC PCS7 rendszerekben Mingzheng Li, az Acorn Network Security Lab munkatársa talált egy olyan hibát, amit kihasználva az alkalmazások által használt memóriaterületeken lehet memóriaszivárgást előidézni egy kártékony ActiveX komponenssel. A hiba a SIMATIC WinCC V7.2-nél korábbi összes verzióját, valamint a SIMATIC PCS7 V8.0 SP1-nél régebbi összes verzióját érinti.

A gyártó a hibát a SIMATIC WinCC V7.2-es illetve a SIMATIC PCS7 V8.0 SP2-es és újabb verzióiban javította.

A hibáról bővebben a Siemens ProductCERT bejelentésében lehet olvasni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-693129.pdf

A Siemens SIMATIC S7-300 és S7-400 típusú kommunikációs processzoraiban Zhu WenZhe, a pekingi Acorn Network Technology munkatársa talált két hibát is. A hibák a SIMATIC S7-300 és S7-400 kommunikációs processzor-családok összes verzióját érintik.

Az első hiba kihasználásával egy támadó a sérülékeny rendszerek 80/tcp portjára küldött ártó szándékú TCP csomagokkal hibás üzemmódba tudják juttatni, amiből csak egy teljes leállás utáni újraindítással lehet ismét üzemképes állapotba hozni az érintett eszközöket. A másik hibát kihasználva egy támadó, aki eléri a sérülékeny eszközök 102/tcp portját (ISO-TSAP), hozzáférhet a PLC-k bejelentkezési adataihoz, ha az érintett eszközökön a 2-es védelmi szint be van konfigurálva.

A rendelkezésre álló információk alapján egyelőre nincs elérhető javítása a fenti hibákra. A gyártó ajánl néhány kockázatcsökkentő intézkedést:

- Az első sérülékenység által érintett eszközök esetén deaktiválják a webszervert;
- Alkalmazzák a Siemens cella-védelmi koncepcióját (cell protection concept);
- A második sérülékenység okozta kockázatok csökkentése érdekében konfigurálják be a 3-as védelmi szintet;
- Alkalmazzank mélységi védelmet.

A hibával kapcsolatban további részleteket az ICS-CERT bejelentéséből lehet megtudni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-731239.pdf

ICS sérülékenységek LXXV

Tesla és Locus Energy sérülékenységek

Tesla Gateway ECU sérülékenységek

A Tencent-hez tartozó Keen Security Lab munkatársai a Tesla Model S autók Gateway ECU-iban találtak egy kód-befecskendezést lehetővé tevő hibát. A hibát kihasználva egy támadó képes lehet üzeneteket küldeni a Model S-ek CAN buszára. A hiba a 7.1 (2.36.31)-nél korábbi firmware-verziók közül mindegyiket érinti, ha a webböngésző funkcionalitást engedélyezték.

A Tesla 2016. szeptember 18-án elkészítette a sérülékenységet javító frimware-t. Az ICS-CERT ezúttal is további védelmi intézkedéseket javasol:

- Ne használják a járművek webböngészőjét, amennyiben nem frissítették a firmware-t a legújabb verzióra;
- További információkért és a firmware-frissítéssel kapcsolatos részletekért vegyék fel a kapcsolatot a Tesla support-tal.

A sérülékenységgel kapcsolatos ICS-CERT bejelentés a következő linken érhető el: https://ics-cert.us-cert.gov/advisories/ICSA-16-341-01

Locus Energy LGate sérülékenység

Daniel Reich, független biztonsági kutató a Locus Energy LGate nevű, webes napenergia-mérő és adatgyűjtő rendszerében talált kód-befecskendezéses hibát. A hiba az LGate alábbi verzióiban található meg:

- LGate 1.05H előtti verziók;
- LGate 50;
- LGate 100;
- LGate 101;
- LGate 120;
- LGate 320.

A gyártó a hiba javításához elérhetővé tette a javított firmware-verziót és egy több lépéses útmutatót az LGate eszközök frissítéséhez:

1. Meg kell szakítani az LGate áramellátását. Ehhez szükség lehet a megszakítók működtetésére is.
2. Kapcsoljuk be az LGate-et és várjunk 5 percet.
3. Az LGate webes felületén a bekapcsolás utáni első 30 percben ellenőrizzük a firmware-verziót.
 3a. Ha az LGate csatlakozik a helyi hálózatra, akkor egy, az LGate-tel azonos alhálózatban üzemelő számítógépről nyissuk meg az LGate webes felületét.
 3b. Ha az LGate nem csatlakozik a helyi hálózatra, csatlakoztassunk egy számítógépet Ethernet hálózaton az LGate-hez. Várjuk meg, amíg a számítógép kap egy IP címet a 169.254.0.0/16-os tartományból, majd a 169.254.12.13-as IP címet használva csatlakozzunk az LGate webes felületéhez.
4. A weboldalon megjelenik az LGate modell típusa, IP címe, firmware-verziója (APP néven) és MAC címe.
5. Ellenőrizzük, hogy a firmware-verzió 1.05H_EM3 vagy ennél magasabb.
6. Ha a firmware-verzió alacsonyabb, mint 1.05H_EM3, küljünk e-mailt a support@locusenergy.com címre a következő tárggyal: URGENT FW UPDATE REQUEST: MAC: <ide kell beilleszteni az LGate MAC címét> TO 1.05H or higher FW.
7. A Locus Energy support meg fogja kísérelni távolról elvégezni a firmware-frissítést és ha sikerrel járnak, erről megerősítő e-mailt küldenek. Ha bármilyen akadályba ütköznek a frissítés során a support kapcsolatba fog lépni az érintett ügyfelekkel, hogy alternatív frissítési módról vagy az érintett LGate cseréjéről egyeztessenek.
8. Ha megérkezik a support visszaigazolása a firmware frissítéséről, célszerű az 1-5. lépésekkel újra ellenőrizni a firmware-verziót.

A hibával kapcsolatban további részleteket ezúttal is az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-231-01-0

Nem szoktam a saját gondolataimat hozzáfűzni a különböző ICS sérülékenységekről szóló posztokhoz, de a Locus Energy firmware-frissítési eljárása miatt most kivételt teszek. Az még egy dolog, hogy e-mailben kell kérni a firmware-frissítést egy (kis)ipari rendszerhez - bár már ez is elég komoly aggályokat ébreszthet egyesekben, hiszen ezek a levelek bárki számára olvashatóak, amíg a felhasználótól eljutnak a Locus Energy-hez -, de az, hogy ezek után Interneten keresztül, minden fajta érdemi hozzáférés-kontroll nélkül képesek lehetnek firmware-frissítést végezni az érintett eszközökön, az gyakorlatilag az összes, ICS biztonsági elvet alapjaiban rúgja fel (ne legyen az ICS rendszereknek Internet-kapcsolata, ne legyenek az ICS rendszereken alapértelmezett, gyári jelszavak).

Meg kéne végre mindenkinek (ide értve az ICS eszközök gyártóit is) értenie, hogy a legalapvetőbb biztonsági szabályok betartása nélkül lehetetlen akár csak minimálisan biztonságos ICS rendszereket üzemeltetni. Az ICS rendszerek elleni sikeres támadások következményei pedig elképzelhetetlenül súlyosabbak lehetnek, mint a nem megfelelően védett weboldalak elleni támadások esetén.

ICS sérülékenységek LXXIV

Sérükékenységek Smiths-Medical, Advantech, Mitsubishi Electric, Moxa és Siemens termékekben

December első napjaiban ismét számos ICS rendszerben felfedezett sérülékenységről adott ki tájékoztatókat az ICS-CERT.

Smiths-Medical CADD-Solis Medication Safety alkalmazás sérülékenységei

A CADD-Solis Medication Safety Software egy inzulin pumpák gyógyszeradagolásáért felelős alkalmazás, amiben Andrew Gothard, Newcastle-upon-Tyne-i kórházak munkatársa talált hibákat. A sérülékenységek a Smiths-Medical CADD-Solis Medication Safety alkalmazásának alábbi verzióit érintik:

- Smiths-Medical CADD-Solis Medication Safety Software, Version 1.0;
- Smiths-Medical CADD-Solis Medication Safety Software, Version 2.0;
- Smiths-Medical CADD-Solis Medication Safety Software, Version 3.0;
- Smiths-Medical CADD-Solis Medication Safety Software, Version 3.1.

Andrew Gothard egy jogosultságkezelési hibát és egy Man-in-the-middle sérülékenységet talált a fenti szoftverekben.

A gyártó kiadta a hibákat javító új szoftververziókat, az USA területén a Version 3.2, az USA-n kívül használt rendszerek számára a Version 4.1-et. A Smiths-Medical a javított verziókon túl az alábbi intékezdések végrehajtását javasolja az érintett szoftvereket használó ügyfeleinek:

- Biztonságosnak tekinthető jelszavakat használjanak (kis- és nagybetűk, számjegyek és speciális karakterek kombinálásával) és 8 vagy több karakterből álljanak;
- Hatékony Active Directory üzemeltetési eljárásokat kell kialakítani;
- A CADD-Solis Medication Safety Software számára service felhasználó kialakítása az SQL adatbázisban;
- Service felhasználókat kell használni a szervereken és az inzulin pumpáknál is;
- Használjanak VLAN tagging-et;
- Az SQL és Windows szerverek esetén hardening eljárásokat kell alkalmazni.

A sérülékenységekkel kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-16-306-01

Advantech SUSIAccess Server sérülékenységek

Korábban már több ICS sérülékenységgel kapcsolatban említetésre került rgod neve, aki ezúttal is a ZDI-vel együttműködve talált 3 hibát az Advantech SUISAccess Server Version 3.0 és korábbi verzióiban. A hibák között egy jogosulatlan információ-hozzáférést lehetővé tevő, egy könyvtár-bejárási támadást lehetővé tevő és egy statikus kulccsal titkosított, beégetett admin jelszót alkalmazó hiba is van.

A gyártó az SUISAccess termékvonalhoz már nem biztosít támogatást, ezeket a termékeket a WISE-PaaS/RMM termékvonallal helyettesítette, így a hibák javítása sem várható.

A hibákról bővebb információ az ICS-CERT weboldalán található: https://ics-cert.us-cert.gov/advisories/ICSA-16-336-04

Mitsubishi Electric MELSEC-Q sorozatú Ethernet Interface modulok sérülékenységei

A Mitsubishi Electric Ethernet-PLC interface modulokban Vladimir Dashchenko, a Kaspersky Lab Critical Infrastructure Defense Team munkatársa talált több sérülékenységet. A hibák a MELSEC-Q sorozat alábbi modelljeit érintik:

- QJ71E71-100, minden verzió;
- QJ71E71-B5, minden verzió;
- QJ71E71-B2, minden verzió.

A fenti eszközökben most felfedezett hibák közül az egyik a gyenge kriptográfiai algoritmus alkalmazásából adódik, a másik hiba pedig egy támadónak lehetőséget ad arra, hogy az 5002/tcp porton keresztül egy szolgáltatás-megtagadásos támadással elérhetetlenné tegye a PLC-t és csak annak újraindítása után lesz ismét használható.

A gyártó új szoftververziót adott ki a 18072 és későbbi sorozatszámú eszközökhöz, amivel egy IP cím szűrési funkciót is implementált a szoftverben a QJ71E71-100, QJ71E71-B5 és QJ71E71-B2 Ethernet Interface modulokhoz. Az IP cím szűrés a Mitsubishi Electric jelentése szerint javítja az eszközök külső forrásból történő hozzéférés-védelmét, azonban teljes védelmet nem biztosít. További intézkedésként javasolják a kommunikáció titkosítását, pl. IPSec alkalmazásával. A gyenge titkosítási algoritmus hibájával kapcsolatban mostanáig nem történt gyártói intézkedés.

A fenti hibákkal kapcsolatban az ICS-CERT további intézkedéseket is javasol:

- Biztosítani kell, hogy minden, használaton kívüli port le van tiltva;
- A kommunikációs útvonalak biztosítását javasolt IPSec titkosítással megvalósítani;
- Az érintett eszközök üzemeltetőinek javasolt megfontolni Bump-in-the-Wire (BitW) megoldás alkalmazásával javítani az eszközök kommunikációjának biztonságán.

A hibákkal kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-336-03

Moxa NPort eszközök sérülékenységei - újabb fejlemények

Még idén április 8-án jelentek meg információk a Moxa NPort eszközök súlyos sérülékenységeivel kapcsolatban (én is írtam róluk itt a blogon), most a Moxa megjelentette az érintett eszközökhöz a hibákat javító szoftver verziókat:

- NPort 5110 Version 2.6;
- NPort 5130/5150 Series Version 3.6;
- NPort 5200 Series Version 2.8;
- NPort 5400 Series Version 3.11;
- NPort 5600 Series Version 3.7;
- NPort 5100A Series & NPort P5150A Version 1.3;
- NPort 5200A Series Version 1.3;
- NPort 5150AI-M12 Series Version 1.2;
- NPort 5250AI-M12 Series Version 1.2;
- NPort 5450AI-M12 Series Version 1.2;
- NPort 5600-8-DT Series Version 2.4;
- NPort 5600-8-DTL Series Version 1.3;
- NPort 6x50 Series Version 1.14;
- NPort IA5450A Version 1.4;

A gyártó közlése szerint az NPort 6110-es eszközök 2008 december óta nem rendelkeznek gyártói támogatással, így a most megjelent patch-ek ehhez a típushoz nem kerülnek kiadásra. Az ICS-CERT az NPort eszközök sérülékenységeivel kapcsolatban további intézkedések bevezetését is javasolja:

- A 161/udp, 4800/udp és 4900/tcp portokat csak megbízható rendszerekből szabad elérhetővé tenni. A 4800/udp és 4900/tcp portok elérésének szigorítása kihatással lesz az érintett rendszerek távoli adminisztrálására!
- Meg kell bizonyosodni arról, hogy a nem használt portok legyenek letiltva.

Az áprilisi hibákkal kapcsolatban most megjelent információkról többet az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-16-336-02

Siemens SICAM PAS sérülékenységek

Ilya Karpov és Dmitry Sklyarov, a Positive Technologies, valamint Sergey Temnikov és Vladimir Dashchenko, a Kaspersky Lab Critical Infrastructure Defense Team munkatársai közös munkájuk során fedeztek fel 4 hibát a Siemens SICAM PAS eszközeiben.

A hibák között gyárilag beégetett jelszavak (a hiba SICAM PAS 8.00-nál régebbi verzióit érinti), jelszavak visszafejthető formában történő tárolása (a hiba SICAM PAS 8.00-nál régebbi verzióit érinti). További hibák lehetővé teszik, hogy támadók a 19235/tcp porton keresztül fájlokat töltsenek fel vagy le, illetve töröljenek az érintett rendszerekből, a 19234/tcp porton keresztül pedig szolgáltatás-megtagadásos támadást illetve authentikáció nélküli távoli kódfuttatást hajtsanak végre (mindkét hiba a SICAM PAS összes verzióját érinti). Ez utóbbi két hibát (és természetesen azokat is, amelyek csak a 8.00-nál régebbi verziókat érintik) a gyártó a SICAM PAS 8.08-as verzióban már javította.

További információkat a sérülékenységekkel kapcsolatban a Siement ProductCERT-en és az ICS-CERT bejelentésében lehet olvasni.

Az összes, december 1-jén megjelent sérülékenységgel kapcsolatban érvényesek az ICS-CERT általános kockázatcsökkentést célzó intézkedésekre vonatkozó javaslatai:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

Vasúti jelzőrendszerek biztonsága I

A tavalyi év utolsó napjaiban két posztban is téma volt itt a blogon a különböző vasúti irányító rendszerek biztonsága. A mai és a következő heti posztban ezt a témát próbálom egy kicsit alaposabban bemutatni.

A vasúti jelző és biztosítóberendezések digitalizálása során ugyanaz a folyamat játszódott le, mint az ipari/folyamatirányító rendszerek esetén általában. A folyamatos igény a kapacitások növelésére, a folyamatok (a vasút esetében a forgalom) optimalizálására és az ezzel járó költségek csökkentésére azzal járt, hogy ezen a területen is egyre nagyobb arányban kezdtek általános célú operációs rendszereket, alkalmazásokat és protokollokat használni, ezzel pedig a vasúti rendszerekben is megjelentek ugyanazok a sérülékenységek, amiket a vállalati IT rendszerekben már-már megszoktunk.

Az ipari/folyamatirányító rendszerek vizsgálata azt mutatja, hogy az átlag vállalati rendszerek esetén használt támadási módszerek és eszközök használatával minden komolyabb nehézség nélkül lehet kompromittálni az ipari rendszerek funkcionális biztonságát, megbízhatóságát és az ipari folyamatok biztonságát is.

A széles körben használt ICS/SCADA és számítógép-alapú vasúti irányító rendszerek (Computer-based Control Systems, CBCS) mélyreható elemzése azt mutatta ki, hogy olyan sérülékenységek vannak minden ilyen rendszerben, amiket kihasználva nem csak a legfontosabb megbízhatósági mutatókat lehet csökkenteni, hanem olyan kibertámadásokat is lehetővé tesznek, amelyek a vasúti közlekedés során közvetlenül a fizikai biztonságot veszélyeztetik. A cikk kiemeli, hogy ez annak ellenére van így, hogy ezek a rendszerek megfelelnek minden releváns IT biztonsági és funkcionális biztonsági előírásnak és mindegyik rendszer rendelkezik a szükséges iparági, nemzeti és nemzetközi tanúsításokkal. Mindezt figyelembe véve már a CBCS rendszerek tervezése során számolni kell az ilyen jellegű támadások lehetőségével. Ahogy korábban már többször szóba került, az ipari rendszerek esetén ugyanúgy, mint a CBCS rendszereknél a klasszikus CIA modell mellett kiemelten fontos szempont a megbízhatóság és a biztonság (safety). A legutóbbi időkig a vasúti rendszerek esetén is ez a két szempont nem csak a legfontosabb, de szinte az egyetlen kiemelt cél volt. Korábban az emberi tényezőn alapuló fenyegetések szintje alacsony volt, szinte kizárólag az operátorok és egyéb kisegítő személyzet által elkövetett, szinte minden esetben nem szándékos hibákból adódtak az ilyen esetek, ahogy azonban a vasúti irányítórendszerek összekapcsolásra kerültek más IT rendszerekkel, a távolról végrehajtható támadások lehetősége nagyságrendekkel megnőtt. A még mindig erős régi beidegződések miatt (ami nem csak a CBCS rendszerek, hanem nagyjából minden ICS rendszer esetén igaz a mai napig) jelenleg nem lehetséges elfogulatlan módon értékelni a vasúti közlekedés biztonságát, ezen belül a kiberbiztonsági helyzetét.

A vasúti közlekedésben használt iparági és nemzetközi biztonsági szabványok kivétel nélkül a megbízhatóságra és a véletlenszerű hibákból adódó veszélyes helyzetek számának csökkentésére fókuszálnak, amik ugyan részben átfedik a kiberbiztonság céljait, azonban az ezen szabványok alapján végzett kockázatelemzések nem számolnak a kiberbiztonsági incidensek jelentette fenyegetésekkel. A téma szakértői szerint a CBCS rendszereket közvetlenül célzó támadások elleni kiberbiztonsági folyamatok definiálásával kell biztosítani a CBCS rendszerek zavartalan működését, ezzel kizárva a veszélyes helyzeteket okozó hibákat. Javaslatuk szerint a vasútbiztonsági, funkcionális biztonsági és IT biztonsági metodológiákból merítve kell kidolgozni a vasúti irányítórendszerek kiberbiztonsági ajánlásait. Ennek a legnagyobb előnye a létező CBCS jelzőrendszerek és kiberbiztonsági eszközök/eljárások integrálásában jelentkezik, úgy, hogy nem kell feladni a már bizonyítottan jó eljárásokat.

A következő posztban a vasúti rendszerek más rendszerektől eltérő komponenseiről és a CBCS fenyegetettségekről lesz szó.

ICS sérülékenységek LXXIII

Emerson rendszerek sérülékenységei

Két nappal ezelőtt az Emerson három ICS rendszerével kapcsolatban is sérülékenységekről szóló publikációk jelentek meg.

Emerson Liebert SiteScan sérülékenység

Evgeny Ermakov, a Kaspersky Lab munkatársa egy XML External Entity (XEE) hibát talált az Emerson SiteScan Web 6.5 és korábbi verzióiban. A hiba a rendszer gyenge XML parser-ében van, amit kihasználva egy támadó képes lehet ártó szándékú XML fájlokkal adatokat bejuttatni a rendszerbe.

A gyártó az érintett verziókat használó ügyfeleinek az alábbiakat tanácsolja:

- SiteScan Web 6.1 verziót használók telepítsék a WS61_Security_Update.update frissítést;
- SiteScan Web 6.5 verziót használók telepítsék a WS65_Security_Update.update frissítést.

További részleteket a sérülékenységről az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-334-01

Emerson DeltaV Easy Security Management sérülékenység

A gyártó bejelentése alapján az Emerson DeltaV rendszereinek Easy Security Management alkalmazásában találtak egy hibát, ami a nem megfelelő jogosultság-kezelésből adódik. A hiba az alábbi verziókat érinti:

- DeltaV V12.3;
- DeltaV V12.3.1;
- DeltaV V13.3.

A gyártó a hibával kapcsolatban az Easy Security Management alkalmazás eltávolítását javasolja az érintett rendszerekből, aminek pontos leírását az Emereson a Guardian Support Knowledge Base NK-1600-0336-os cikke tartalmazza. Az eltávolítás egyszerűsített lépéseit és további információkat a sérülékenységről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-334-02

Emerson DeltaV Wireless I/O Card sérülékenység

Az utolsó Emerson-termék hibáját szintén a gyártó bejelentéséből ismerhetjük, a DeltaV Wireless I/O Card alábbi verzióiban szükségtelenül van nyitva az OpenSSH port és a hiba leírása alapján az authentikáció is hiányzik a bejelentkezésnél:

- SE4801T0X Redundant Wireless I/O Card V13.3;
- SE4801T1X Simplex Wireless I/O Card V13.3

A gyártó a hibával kapcsolatban a Guardian Support Knowledge Base NK-1500-0152-es számú bejegyzésének végrehajtását és a DeltaV_133_WIOC_02_CSS néven kiadott gyorsjavítás alkalmazását javasolja. További kockázat csökkentési intézkedésekként a DeltaV Security Manual-ban és az Emerson’s Wireless Security Whitepaper-ben leírtak beállítását javasolják.

A hibával kapcsolatban bővebb információkat ezúttal is az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-334-03

A sérülékenységekkel kapcsolatban az ICS-CERT mint általában, most is a kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

Hogyan javíthatunk az ipari rendszerek biztonságán? III

A végponti eszközök biztonsága - 2. rész

Múlt héten röviden áttekintettük az ipari végpontok biztonságát, ma pedig folytatjuk a témát és közelebbről is megvizsgáljuk, mit is lehet tenni ezeknek az eszközöknek a host-szintű biztonságáért.

Elsőként érdekesek lehetnek azok a védelmi intézkedések, amiket sokan alapigazságnak tekintenek még ma is, pedig már sok éve bizonyítottan téves feltételezéseken alapulnak.

"A víruskeresők/antivirus szoftverek önmagukban is megfelelő védelmet biztosítanak" - Tény, hogy a különböző antivirus megoldások képesek bizonyos szintű védelmet nyújtani, de ehhez mindenképp rendszeres vírus adatbázis frissítések és ütemezett vizsgálatok szükségesek. Az antivirus megoldásokkal ráadásul több probléma is adódhat (szinte minden jelentős AV-fejlesztővel kapcsolatban volt már legalább egyszer olyan hír, hogy egy hibás vírus adatbázis frissítés után az AV-szoftver fals pozitív találatokat produkált és fontos, gyakran rendszerfájlokat is karanténba helyezett vagy törölt), ami már az ügyviteli rendszerek esetén is nagyon súlyos problémákat jelenthetnek, de egy 7/24-es működésű folyamatirányító rendszer esetén egy ilyen hiba nem csak állásidőben és pénzben, de akár emberéletben mérhető károkat is okozhat. Gondok lehetnek az ütemezett vizsgálatok időzítésével is, mert az ipari rendszerek és különösen az ipari végpontok üzemeltetésében adott esetben sokkal nehezebb lehet olyan időszakokat találni, amikor akár több órán át futhat egy, a normálisnál jóval nagyobb performancia-igényű ütemezett víruskeresés. Az AV-szoftverek teljesítményigénye önmagában is jelenthet problémákat, hiszen az ipari végpontok tervezése során egészen a legutóbbi időkig nem számoltak végpontvédelmi/AV-megoldások használatával ezeken az eszközökön, így - főleg a régebbi modellek esetén - nagyon is valószínű, hogy a végpontok egyszerűen nem rendelkeznek az AV-szoftver alap funkciókat nem korlátozó futtatásához szükséges teljesítmény-többlettel.

"Nem kell minden végpontot védeni" - Az a gondolat, hogy elég egyes ipari végpontokat megfelelő védelemmel ellátni, ugyanolyan téves biztonságérzetre épül, mint az a régi tévhit, hogy az ipari eszközöket nem képesek a támadók kompromittálni, mert a) teljesen zárt hálózatokban működnek; b) a támadók számára ezek a rendszerek túl bonyolultak és nem képesek megérteni a működésüket. Napjainkban szinten már minden ipari végpont rendelkezik valamilyen hálózati vagy lokális (soros porti, USB) kapcsolattal, amiknél jobb támadási vektorra nincs is szüksége senkinek, aki kompromittálni akarja őket.

"A végpontvédelem önmagában is megfelelő biztonságot nyújt" - A vállalati rendszerek esetén már több, mint egy évtizede axióma, hogy mélységi védelmet kell kialakítani a hálózatbiztonsági és végponti megoldások megfelelő kombinálásával. A támadások elhárításában vagy legalább a negatív hatások csökkentésében elsődleges fontosságú a forrásuk felismerése és megértése.

"A felhasználók a legtöbb végpontot biztonságos módon használják" - Ez egy olyan feltételezés, amivel ismét a vállalati IT biztonság területén nagyon ritkán lehet találkozni. Az általános biztonságtudatossági képzések első szabálya az, hogy az IT biztonság leggyengébb pontja mindig az ember volt és várhatóan a jövőben is az ember lesz. Nincs ez máshogy az ipari rendszerek esetén sem - bár ebben az esetben az automatizáltság magasabb foka kisebb mozgásteret ad az embereknek és így az ebből fakadó hibáknak is. Sajnos tény az is, hogy az ipari rendszereket kezelő mérnökök biztonságtudatossága általában véve nem jobb, mint a vállalati hálózaton dolgozó felhasználóké. Éppen ezért tartom elsődleges fontosságúnak az ipari rendszerek felhasználói számára specifikus biztonságtudatossági képzések tartását, mert talán ezen a területen lehet a legtöbb eredményt viszonylag kisebb erőforrás-ráfordítással elérni.

"A végpontjaim Internet-kapcsolata biztonságos" - Kezdjük talán azon, hogy az ipari végpontoknak valóban kell-e Internet-kapcsolat? Az esetek döntően nagy hányadában a válasz minden bizonnyal nem, többnyire (jellemzően kényelmi vagy költség-csökkentési okok miatt) mégis elérhetővé teszik ezeket az eszközöket az Internet felől is. Jobb esetben csak valamilyen (biztonságosnak gondolt) távoli hozzáféréssel (pl. SSH, RDP, stb.) de számos eszköz használ olyan régebbi protokollokat (pl. telnet, rsh, rexec, stb.), amelyek semmilyen biztonsággal nem rendelkeznek. Nagyon fontos, hogy az ipari végpontok és rendszerek ne rendelkezzenek Internet-kapcsolattal, ha a felhasználóknak/üzemeltetőknek/támogatóknak távoli hozzáférést kell biztosítani, minden esetben csak biztonságos VPN-kapcsolaton keresztül és több faktoros authentikáció után lehessen elérni az ipari eszközöket!

"A végpontvédelmi megoldások rontják a felhasználói élményt" - az ipari rendszerek esetén a teljesítmény-problémák gyakran valós és igen súlyos gondot tudnak jelenteni. Így van ez néha még akkor is, ha egy adott végpontra még nem telepítettünk semmilyen végponti biztonsági megoldást és sajnos tény, hogy egyes AV-szoftverek képesek érezhető lassulást okozni az általuk futtatott rendszeren. Új telepítésű rendszerek esetén a legjobb megoldás a teljesítmény méretezésénél kellő performancia-tartalék beépítése, ami már biztosítja a végpontvédelmi megoldás által igényelt teljesítményt is a rendszer alapvető funkcióinak lassulása nélkül is. Elengedhetetlen az AV-szoftverek hangolása, a legtöbb modern végpont már olyan operációs rendszereket futtat, ahol lehet finomhangolni, hogy egy-egy alkalmazás mennyi erőforrást használhat, így elkerülhető, hogy a végpontvédelmi megoldás miatt az ipari végpont lelassuljon és alapvető funkciói ne működjenek az elvárásoknak megfelelően. Természetesen lehetnek olyan régi ipari végpontok is egy-egy rendszerben, amiknél ezek a lehetőségek nem állnak az OT üzemeltetők és biztonsági szakemberek rendelkezésére, itt vissza kell nyúlni az információbiztonság egyik legrégebbi megoldásához, a kompenzáló kontrollok alkalmazásához.

"A végpontvédelem minden problémánkat megoldja" - ahogy az IT biztonságban, úgy az ICS kiberbiztonságban sincsenek csodaszerek, amik egymaguk minden problémát megoldanának. Átfogó és integrált megoldások alkalmazásával, amik egyaránt magukban foglalnak hálózatbiztonsági és végpontvédelmi megoldásokat, lehetőséget adnak arra, hogy a támadások ellen egy hatékony védelmet építhessünk.

A különböző hardveres és szoftveres megoldások mellett azonban legalább ilyen fontosak a jó eljárások. Elsődlegesen fontos, hogy ismerni kell az ipari rendszerek elemeit, különösképpen az ipari végpontokat - hány darab van belőlük, hol helyezkednek el a rendszerben, milyen firmware-t, operációs rendszert, egyéb szoftvereket futtatnak, mi a pontos verziójuk és patch-szintjük, milyen ismert, de még nem javított hibák találhatóak bennük. Ezek milyen kockázatokat jelentenek az egyes eszközökre, a teljes rendszerre és az általuk befolyásolt folyamatokra nézve?

Ugyanilyen fontos a biztonságos és ellenőrzött konfiguráció- és változáskezelés - amit a normál üzemeltetés mellett az OT területen dolgozó mérnökök többnyire nagyon fegyelmezetten be is tartanak. Azonban folyamatosan ellenőrizni kell, hogy a végponti és egyéb rendszerelemeken milyen változások történtek és a nem dokumentált/engedélyezett változásokat minél előbb ki kell vizsgálni. Lehetséges, hogy egy kolléga egy tervezett és engedélyezett változtatást egyszerűen elfelejtett dokumentálni (pl. azért, mert egy sürgős hibaelhárítás elvonta a figyelmét a már elvégzett feladat teljes körű adminisztrációjáról), de ugyanígy lehetséges, hogy ezek az első jelei egy összetett és kifinomult támadásnak az ICS rendszer ellen.

Ahogy látszik, az ipari végpontok védelmének megteremtése egy roppant összetett téma. Elengedhetetlen, hogy az OT és IT biztonsági szakemberek minél jobban értsék és megértsék a másik fél feladatait, prioritásait és hatékonyan tudjanak együttműködni, különben az ipari rendszerek biztonságos működését lehetetlen lesz biztosítani.

ICS sérülékenységek LXXII

Sérülékenységek Siemens SIMATIC termékekben

A Siement ProductCERT (és ennek nyomán az ICS-CERT) publikációi alapján több hibát is azonosítottak a Siemens SIMATIC egyes kommunikációs processzoraiban. A hibák az alábbi terméeket és firmware-verziókat érintik:

- SIMATIC CP 343-1 Advanced, V3.0.53-nál korábbi verziók;
- SIMATIC CP 443-1 Advanced, minden verzió;
- SIMATIC S7-300 CPU család minden firmware-verziója és
- SIMATIC S7-400 CPU család minden firmware-verziója.

A sérülékenységek között az adatok hitelességének nem megfelelő ellenőrzését kihasználhatóvá tevő és 'secure' flag nélküli, érzékeny adatokat tartalmazó webes cookie is található.

A sérülékenységekkel kapcsolatban a Siemens az alábbiakat javasolja az érintett termékeket használó ügyfeleinek:

- A SIMATIC CP 343-1 Advanced típusú készülékeken frissítsenek V3.0.53 verziójú firmware-re;
- A SIMATIC CP 443-1 Advanced típusú eszközöknél a következő, kockázatcsökkentő intézkedések végrehajtása ajánlott:
  - A webszerver elérését csak belső hálózatról engedélyezzék;
  - Külső (nem megbízható) hálózati interfészek használata esetén a kommunikáció biztosítására használjanak VPN-megoldást;
- A SIMATIC S7-300/S7-400 CPU-k felhasználói számára a Siemens azt javasolja, hogy
  - alkalmazzák a Siemens cella-védelmi koncepcióját (cell protection concept);
  - használjanak VPN-t a cellák közötti kommunikáció védelmére;
  - alkalmazzanak mélységi védelmet.
 
A sérülékenységekkel kapcsolatban az ICS-CERT ismét kiemeli a szokásos kockázatcsökkentő intézkedések fontosságát:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

A fenti sérülékenységekről további információkat a Siemens ProductCERT és az ICS-CERT publikációi tartalmaznak.

ICS sérülékenységek LXXI

Sérülékenységek Lynxspring, Moxa és Siemens termékekben

A héten ismét több gyártó termékeivel kapcsolatban váltak ismertté különböző sérülékenységek.

Lynxspring JENEsys BAS Bridge sérülékenységek

A heti sort azok a sérülékenységek nyitották, amelyeket Maxim Rupp talált a Lynxspring BAS Bridge nevű, web-alapú SCADA rendszerének 1.1.8 és ennél korábbi verzióiban. A hibák a rendszer jogosultság- és felhasználó-kezelését érintik illetve egy CSRF is van közöttük.

A hibákkal kapcsolatban a gyártó nem fog javításokat kiadni a BAS Bridge termékvonalhoz (aminek a gyártói támogatása 2014-ben szűnt meg), a sérülékenységek által érintett verziókat használó ügyfelek számára azt javasolják, hogy migráljanak az OnyxxBridge termékvonal legfrissebb verziójára, ami a Lynxspring tesztjei szerint a most felfedezett hibákat már nem tartalmazza.

A hibákról bővebb információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-16-320-01

Moxa SoftCMS sérülékenységek

A Moxa SoftCMS nevű, megfigyelő rendszerek központi menedzsment feladataira használható megoldásában Zhou Yu, a ZDI és Gu Ziqiang, a Huawei Weiran Labs munkatársai találtak több hibát is, amelyek a SoftCMS 1.6-osnál korábbi verzióit érintik. A hibák között a bevitelre kerülő adatok nem megfelelő ellenőrzése, memóriakezelési problémák és SQLi egyaránt található. A hibákat a gyártó az 1.6-os verzióban javította, ez szabadon letölthető a Moxa weboldaláról.

A hibáról többet az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-322-02

Sérülékenységek Siemens termékekben

A Siemens termékpalettájáról több rendszerrel kapcsolatban is jelentek meg újonnan felfedezett hibák.

A Siemens márkanév alatt értékesített Vanderbilt IP-alapú CCTV kamerák esetén a nem megfelelően védett adminisztrátori fiókok okoznak problémát. A hiba az alábbi termékeket és firmware-verziókat érinti:

- CCMW3025, 1.41_SP18_S1-nél régebbi firmware-ek;
- CVMW3025-IR, 1.41_SP18_S1-nél régebbi firmware-ek;
- CFMW3025, 1.41_SP18_S1-nél régebbi firmware-ek;
- CCPW3025, 0.1.73_S1-nél régebbi firmware-ek;
- CCPW5025, 0.1.73_S1-nél régebbi firmware-ek;
- CCMD3025-DN18, v1.394_S1-nél régebbi firmware-ek;
- CCID1445-DN18, v2635-nél régebbi firmware-ek;
- CCID1445-DN28, v2635-nél régebbi firmware-ek;
- CCID1445-DN36, v2635-nél régebbi firmware-ek;
- CFIS1425, v2635-nél régebbi firmware-ek;
- CCIS1425, v2635-nél régebbi firmware-ek;
- CFMS2025, v2635-nél régebbi firmware-ek;
- CCMS2025, v2635-nél régebbi firmware-ek;
- CVMS2025-IR, v2635-nél régebbi firmware-ek;
- CFMW1025, v2635-nél régebbi firmware-ek és
- CCMW1025, v2635-nél régebbi firmware-ek használata esetén.
 
A hibával kapcsolatban a Vanderbilt elkészítette a javítást tartalmazó új firmware-verziót, amiről több információt a Siemens ProductCERT-en kiadott publikáció tartalmaz.

A hibával kapcsolatban további információkat a fenti linken vagy az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-16-322-01

Két sérülékenységet fedeztek fel a SIMATIC CP 1543-1-es típusú kommunikációs processzorok V2.0.28-nál korábbi firmware-verzióiban, részben jogosultság-kezelési problémából, részben eredetileg csak olvashatónak szánt SNMP változók írását lehetővé tevő hibából adódóan.

A gyártó a V2.0.28-as firmware-ben javította a hibákat, amikről további információkat a Siemens ProductCERT publikációja tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-672373.pdf

Az ICS-CERT a hibákkal kapcsolatban ezúttal is a szokásos kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

Hogyan javíthatunk az ipari rendszerek biztonságán? II

A végponti eszközök biztonsága - 1. rész

A múlt heti posztban az ICS hálózatok biztonságáról írtam, a mai és következő heti írásban pedig az ipari végponti eszközök biztonságát fogom egy kicsit részletesebben áttekinteni. Ma elsősorban az IT és az OT (Operations Technology, magyarra leginkább talán ICS működéstechnológia kifejezésként lehet lefordítani, az a szakterület az ipari környezetben működő szervezeteknél, akik az ipari és folyamatirányító berendezések és rendszerek üzemeltetésével és fejlesztésével foglalkoznak) közötti különbségekről lesz szó, központban a két terület által használt végponti berendezésekkel.

Több neves szervezet (ICS-CERT, SANS, stb.) kutatói vizsgálják az utóbbi években rendszeresen a különböző ipari eszközök biztonságát és ezek a vizsgálatok meglehetősen lehangoló képet festenek a végponti eszközök biztonságáról. A SANS 2016-os, ICS biztonsági felmérése szerint a számítógépes végpontok jelentik a legnagyobb kockázatot az ipari rendszerek esetében, mégis, az érintett szervezetek alig 50%-a végez sérülékenység vizsgálatokat az érintett végponti berendezéseken.

IT és OT végponti berendezések

Az ipari környezetekben az IT az OT végpontok között számos különbség van, mind a célokban, amire használják őket, mind a működésük során prioritásként kezelt szempontokban, ez utóbbi pedig meghatározza azt is, hogy az OT-ben dolgozó üzemeltetők nagyon máshogy állnak az ilyen eszközök üzemeltetéséhez.

Egy ipari területen tevékenykedő szervezetnél az IT elsősorban a vállalati/ügyviteli hálózatra koncentrál (a Purdue referencia architektúra szerinti 4. és 5. szintre). Ezek a rendszerek jellemzően üzleti információs rendszerek, tranzakciós rendszerek és szinte kizárólag az IT vezető felelősségi körébe tartoznak. Az informatikai végponti eszközök IP-alapú munkaállomások, mobil eszközök, adatbázisok, alkalmazás és webszerverek. Gyakran időszakos vagy állandó kapcsolatban állnak a szervezet partnereinek (beszállítók, ügyefelek) egyes rendszereivel. Az informatikai végpontok napjainkban egyre dinamikusabban változnak (elég arra gondolni, hogy bizonyos fejlesztők akár naponta adhatnak ki frissítéseket, hibajavításokat, de még a legnagyobb gyártók is havi gyakorisággal adnak ki frissítéseket a termékeikhez) és egyre több rendszer van az Internetre csatlakoztatva. Ez a dinamikus környezet az oka annak, hogy az IT területén dolgozó szakemberek egyre komolyabb figyelmet fordítanak az általuk üzemeltetett végponti eszközök biztonságára, hiszen a végpontok és az azokhoz rendelkezésre álló hozzáférési módok számos támadási vektort jelenthetnek.

Az OT rendszerek szintén számos végpontot tartalmaznak - gyakran az IT vépontokhoz nagyon hasonló kategóriájú eszközöket is - alkalmazás szerverek, adatbázis szerverek, HMI-ok, mérnöki munkaállomások és természetesen Level2 vezérlő rendszerek tartoznak ide. Minden ilyen eszközön fut egy operációs rendszer, rendelkeznek konfigurációs állományokkal, jellemző rájuk a jelszó-alapú authentikáció. Ahogy korábban már írtam róla, az OT területen dolgozó szakemberek nagyon sokáig egyáltalán nem aggódtak a logikai biztonság miatt, úgy gondolva, hogy az ipari környezetek egyedi kialakítása, protokolljai, kommunikációs csatornái és az egyes ICS gyártók szabadalmakkal védett hardverei, együtt a fizakai biztonsági intézkedésekkel, megóvják az OT eszközöket a kibertámadásoktól. Az elmúlt években aztán jó néhány olyan kiberbiztonsági incidens került napvilágra, ahol nem csak az érintett ipari szereplők ügyviteli hálózatait, hanem az OT rendszereket is sikerrel kompromittálták a támadók - elég csak a Stuxnetre, a németországi acélkohó vagy az ukrán áramszolgáltatók elleni kibertámadásokra gondolni. Az OT gondolkodás azonban továbbra is (érthető módon) a emberek biztonságát (safety) tartja elsődleges prioritásának, utána pedig jellemzően a rendelkezésre állás következik, szemben a hagyományos IT biztonsággal, ami az ügyviteli informatikai rendszerek esetén jellemzően a bizalmasságot és a sértetlenséget többnyire még a rendelkezésre állásnál is fontosabbnak tartja.
 
Az OT számos, csak ipari környezetekben előforduló végponti eszközzel dolgozik, ilyenek többek között a PLC-k, RTU-k, az intelligens electronikus eszközök (IED), az elosztott vezérlőrendszerek (DCS), a SCADA-rendszerek, a HMI-ok és MMI-ok valamint a digitális és analóg konverterek (DAC-ok) és különböző fizikai interfész-konverterek (pl. soros-Ethernet konverterek).

Az esetek döntő többségében az OT rendszerek egyáltalán nem változnak olyan dinamikusan, mint a vállalati IT rendszerek és az életciklusuk is jóval hosszabb, mint az IT rendszerek esetén (10-15 vagy akár 20 év 3-5 évvel szemben). Az OT rendszerek jellemzően olyan, hosszú ideje érintetlen régi rendszerek, amelyek ráadásul speciális (időnként szabadalmaztatott, egyedi) kommunikációs protokollokkal kommunikálnak és időnként (egyre ritkábban) fizikailag is teljesen el vannak választva a vállalat IT rendszereitől. Azonban ahogy az IT egyre több területen nélkülözhetetlenné válik, úgy terjednek el egyre jobban a PC-alapú végpontok is az OT területén, ma már egyre több OT végpont x86-alapú számítógépből kerül kialakításra, az HMI berendezések döntő többsége is x86 architektúrára épül. Ezeken az eszközökön aztán olyan operációs rendszerek és egyéb szoftverek futnak, amik számos új (és meglehetősen könnyen kihasználható) támadási vektort kinálnak a támadóknak. Ezek a változások oda vezetnek, hogy az ipari környezetekben minél előbb ki kell alakítani olyan hatékony, több rétegű végpontvédelmi megoldásokat, amikkel meg lehet előzni a sikeres támadásokat vagy legalább idejekorán észlelni lehet azokat.

A következő heti posztban a lehetséges eszközök és intézkedések közül fogok néhányat bemutatni, valamint néhány végponti biztonsággal kapcsolatos tévedést és olyan, OT-specifikus nehézséget, amikkel az ipari végpontok esetén találkozhatunk.

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