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

ICS Cyber Security blog

ICS Cyber Security blog

ICS kiberbiztonsági tanfolyamok és minősítések II

SANS ICS410: ICS/SCADA Security Essentials

2016. december 24. - icscybersec

A SANS amerikai székhelyű képzőközpont nem először kerül szóba a blogon, többször hivatkoztam már cikkeket az ICS kiberbiztonsággal foglalkozó blogjukról, most pedig az ICS biztonsággal kapcsolatos képzéseik közül a belépő szintű tanfolyamot mutatom be röviden.

A SANS nem csak ICS témakörben tart tanfolyamokat, fejlesztőknek, általános IT biztonsággal foglalkozó szakembereknek és az IT menedzsmentben dolgozóknak is számos képzésük van, a teljesen kezdőktől a haladó szintig mindenki találhat a saját tudásához mérten újat mutató tanfolyamot - ennek azonban ára van, a SANS képzései jellemzően több ezer amerikai dollárért vagy euróért érhetőek el. Földrajzilag nagyon változatos helyeken tartják a képzéseket, a nagyobb érdeklődésre számot tartó képzések közül időnként egyet-kettőt még Budapestre is elhoznak, de a specializáltabbakért (ilyenek többek között az ICS-specifikus tanfolyamok is) bizony utazni kell - jobb esetben csak Nyugat-Európába (esetleg a Közel-Keletre), de vannak bizony olyan tanfolyamok, amikért az USA-ba kell menni.

Az ICS410 egy 5 napos képzés. Mint a SANS 400-as sorozatú tanfolyamai, ez is a belépő szint az adott témakörbe (a most következő leírás a 2016 végi állapotot mutatja be, mivel a képzést folyamatosan próbálják igazítani az ICS biztonság egyre gyorsabban változó világához, az idő múlásával egyre komolyabb eltérések is lehetnek).

Első nap

Lévén belépő szintű képzés, az ICS410 azzal kezdődik, hogy az első napon, az ICS rendszerek alapjainak ismertetésével megpróbálnak minden résztvevőnek egy szilárd alapot adni. Mivel ennek a tanfolyamnak az anyagából építkezik a GICSP minősítéshez (amiről korábban már itt írtam) tartozó vizsga is, ezért az első előadás a GICSP-ről szól. A folytatásban ismertetésre kerülnek az ICS rendszerek által vezérelt folyamatok és azok az iparágak, ahol ilyen rendszereket használnak, majd a legjellemzőbb eszközökről is szó esik, amelyek a hagyományos operációs rendszerekkel szemben valamilyen valós idejű OS-t futtatnak.

Ezután a PLC-k bemutatása következik, majd egy-egy Velocio PLC-n a PLC programozásba is egy futó betekintést kapnak a tanfolyam résztvevői és ki is próbálhatják, hogy nekik ez mennyire megy.

A következő előadásban a SCADA rendszerek felügyeleti komponenseinek bemutatása történik, külön tárgyalva a DCS-ek és SCADA-k közötti különbségeket.

Ezután az HMI programozást is érinti a tanfolyam résztvevői, a korábban programozott PLC által vezérelt folyamatot lehet egy (akár interaktívvá tehető) felületen megjeleníteni - merthogy ennek a Velocio PLC-nek nincs webes felülete, csak a beépített LED-eken lehet követni a működést, ha nem készítünk hozzá HMI-t.

A következő fejezetben az IT és az ICS közötti különbségeket mutatják be, majd az ICS rendszerek fizikai biztonságát is érinti a tanfolyam.

A nap utolsó fejezetében az ICS hálózatok tervezési alapelveivel ismertetik meg a résztvevőket, ehhez a Purdue referencia architektúra modellt használják (amiről szintén írtam már korábban).

Második nap

A második nap az ICS kiberbiztonságot a támadók szempontjából vizsgálja a képzés. Az első blokkban az ICS rendszerekkel kapcsolatos adatok megszerzésének lehetőségeit mutatják be, egyaránt használva szoftveres (Nmap) és Internetes (Shodan, Google) eszközöket. A továbbiakban az általános IT biztonsági (social enginnering, adathalászat, malware-ek, stb.) és ICS specifikus (ICS malware-ek, mint a Stuxnet/Duqu/Flamer malware-család, a Havex/Dragonfly vagy a Blackenergy-család, az HMI-ok és egyéb ICS komponensek elleni) fenyegetések bemutatása után a gyakorlatban is ki lehet próbálni olyan, az IT biztonságban már mindennaposnak számító támadásokat, mint a webes alkalmazások elleni különböző támadások (password fuzzing, SQL injection, stb.).

Ezután az ICS rendszerek szerveri elleni támadási lehetőségek áttekintése következik, majd az ICS rendszerek hálózati kommunikációja elleni támadások bemutatásával folytatják. Ennek a blokknak a végén ismét egy labor keretében lehet próbát tenni a Modbus kommunikáció módosításával, a nap végén pedig az ICS eszközök firmware-jeinek módosításával is megismerkednek a tanfolyam résztvevői.

Harmadik nap

A tanfolyam harmadik napja az ICS rendszerek munkaállomásain és szerverein használt operációs rendszereket mutatja be részletesebben. Ennek során a Windows-, Linux-, Unix-alapú operációs rendszerek ugyanúgy terítékre kerülnek, mint a mainframe rendszerek. Szóba kerülnek az egyes operációs rendszerek központi menedzsmentjének lehetőségei, a hardening során alkalmazható megoldások, az automatizáláshoz használható scirpt-nyelvek bemutatása mellett Windows Powershell gyakorlat és a Bastille Linux-szal történő ismerkedés is része ennek a napnak. Ezek mellett szó esik a tűzfalakról, a naplózásról és a különböző ICS adatbázisokról is.

Negyedik nap

A negyedik nap az ICS rendszerek hálózatairól szól, az Ethernet hálózatok és a TCP/IP protokoll bemutatása után a tanfolyam rátér a TCP/IP-alapú ICS-specifikus protokollok bemutatására - ehhez egy Modbus/TCP capture fájl szolgál alapul a gyakorlat során.

Ezután a Purdue-modellben az első napon már bemutatott zónák közötti forgalomellenőrzéshez használható eszközök (tűzfalak, egyirányú átjárók vagy más néven adat diódák) rövid ismertetése következik, majd az előadás áttér a honeypot-ok ICS rendszerekben történő alkalmazására.

A következő nagyobb blokk az ICS rendszerek esetén használt különböző vezeték nélküli kommunikációs protokollok (műholdas, Bluetooth, WiFi, stb.) és a hozzájuk kapcsolódó védelmi megoldások bemutatására koncentrál, ehhez a témához megint tartozik egy hálózati csomagok elemzésére épülő gyakorlat.

A nap utolsó részében az ICS rendszerek leginkább speciális eszközeivel (terepi/üzemi berendezések) és a hálózati titkosítás alapjaival ismertetik meg a tanfolyam hallgatóit.

Ötödik nap

A tanfolyam utolsó napja az ICS kiberbiztonság irányításával foglalkozik és ennek megfelelően az adatok osztályozásának ismertetésével kezdődik (ez egyébként egy érdekes része a tanfolyamnak, mert ahogy az első nap az IT és ICS közötti különbségek között elhangzott, az IT főleg az adatokra, az ICS pedig a folyamatokra koncentrál és a tanfolyam tematikája a folyamatok osztályozásáról nem beszél),  majd a mélységi védelem kialakításának fontosságát hangsúlyozzák.

Ezután a biztonsági szabályok, majd a üzletmenet-folytonosság tervezése, valamint a kockázatértékelés és az auditálás részleteit ismerteti a képzés.

A meglehetősen hosszú elméleti blokk után az első gyakorlat a támadási fa-elemzését gyakoroltatja a tanfolyam résztvevőivel, majd ezután a jelszavak és a különböző kiberbiztonsági incidensek kezelésének lehetőségeit ismertetik. Az incidenskezelés a témája a következő gyakorlati foglalkozásnak is. A képzés a legfontosabb amerikai és európai ICS kiberbiztonsággal foglalkozó szervezetek és információforrások ismertetésével zárul.

ICS sérülékenységek LXXVIII

Sérülékenységek Fidelix és WAGO ICS termékekben

Fidelix FX-20 sérülékenység

Semen Rozhkov, a Kaspersky Lab munkatársa egy könyvtár bejárásos sérülékenységet talált a Fidelix FX-20-as sorozatú épületautomatilázásban használt vezérlőiben. A hiba 11.50.19-nél régebbi verziókat érinti.

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

További részleteket a hibáról az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-357-01

WAGO Ethernet web-alapú menedzsment rendszer sérülékenységek

Maxim Rupp független biztonsági kutató ezúttal a németországi székhelyű WAGO Ethernet eszközeinek web-alapú menedzsment funkciójában talált egy authentikáció megkerülést lehetővé tevő hibát. A hiba az alábbi termékekben található meg:

- WAGO 750-8202/PFC200, FW04-nél korábbi verziók (az FW04 2015. augusztusban jelent meg);
- WAGO 750-881 FW09-nél korábbi verziók (az FW09 2016. augusztusban jelent meg), valamint
- WAGO 0758-0874-0000-0111;

A gyártó a hibával kapcsolatban az alábbi tanácsokat adta ügyfeleinek:

- Ha nincs külön jelezve, a WAGO Ethernet eszközeit csak helyi hálózatban történő használatra szánják;
- Vezérlő komponenseket vagy vezérlésre használt hálózatokat ne csatlakoztassanak nyílt vagy kevésbé védett hálózatokra (pl. Internet, irodai hálózatok, stb.). A WAGO ajánlása szerint a vezérlő komponenseket vagy vezérlésre használt hálózatokat tűzfalakkal kell védeni;
- Az automatizáláshoz használt komponensek fizikai vagy elektronikus hozzáférését az engedélyezett személyekre kell korlátozni;
- Az eszközök gyári jelszavait az első használatkor meg kell változtatni! Ez az intézkedés csökkenti az engedély nélküli hozzáférések kockázatát;
- Ha távoli hozzáférést kell biztosítani a vezérlő komponensekhez vagy vezérlésre használt hálózatokhoz, VPN-t kell használni!
- Rendszeresen fenyegetés-elemzéseket kell végezni és ellenőrizni kell, hogy az ellenintézkedések megfelelnek-e a szervezet biztonsági szabályzatainak!
- A mélységi védelem elveit kell követni a vezérlőrendszerek kialakítása és üzemeltetése során.

A hibával kapcsolatosan további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-357-02

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!

Újabb áramkimaradás Ukrajnában

Ismét kibertámadás állhat a háttérben?

Az Ukrenergo weboldalán egy ideig olyan hír volt olvasható (jelenleg csak egy karbantartásról szóló oldal érhető el az Ukrenergo webszerverén), amely szerint december 17-én, szombaton 23:53-kor a Kijev mellett található északi (Petrivtsi) 330 kV-os alállomáon történt üzemzavar miatt mintegy egy órán át az ukrán főváros egy részében és a környező régió egyes részeiben áramszünet volt. Az üzemzavar a Kyivenergo és a Kyivoblenergo áramszolgáltatók területeit érintette. Az üzemzavar viszonylag gyors elhárítását egyes források szerint ismét a manuális vezérlésre történő átállással oldották meg. Az esetről az Ukrenergo igazgatója saját Facebook-oldalán is írt.

Az üzemzavar okát jelenleg is vizsgálják, a nyilatkozat szerint egyes alállomási rendszerek meghibásodását és a kibertámadás lehetőségét sem zárták ki. A vizsgálatokba a rendőrséget is bevonták és a hivatalos vizsgálatok lezárultáig az Ukrenergo távvezérelt alállomásai esetén helyi vezérlésre váltottak.

A hír hallatán többeknek a tavaly december 23-i, nyugat-ukrajnai áramszolgáltatók elleni kibertámadás jutott eszébe, azonban a mostani esetnél még nincs bizonyíték erre - ezek az esetek azonban újra és újra arra hívják fel a figyelmet, hogy a kritikus infrastruktúrák védelme a kibertérből érkező fenyegetése ellen messze nem megfelelő.

A hír egyelőre a szaksajtót még nem igazán érte el, mindeddig csak a SecurityWeek oldalán láttam, hogy írtak róla: http://www.securityweek.com/ukraine-power-outage-possibly-caused-cyberattack

Szerk: A SANS ICS Security Blog-ja és Robert M. Lee is publikáltak egy-egy cikket a témában.

Szerk2: Mostanra több szakmai híroldal is átvette a hírt innen-onnnan: https://hotforsecurity.bitdefender.com/blog/hackers-suspected-of-causing-power-outage-in-ukraine-17419.html
http://securityaffairs.co/wordpress/54572/cyber-warfare-2/ukraine-power-outage.html
http://www.darkreading.com/attacks-breaches/ukraine-investigates-possible-cyberattack-in-kiev-blackout/d/d-id/1327771
http://www.theregister.co.uk/2016/12/21/ukraine_electricity_outage/
http://uawire.org/news/ukrenergo-claims-that-blackouts-in-kyiv-could-have-been-caused-by-hackers

ICS sérülékenységek LXXVII

Sérülékenységek Visonic, Moxa, Delta Electronics, OmniMetrix és Siemens rendszerekben

Ez a hét ismét több új ICS rendszerrel kapcsolatban hozott új sérülékenységeket.

Visonic PowerLink2 sérülékenységek

A Visonic PowerLink2 minden, 2016 októbere előtt megjelent firmware-verzióját érintő sérülékenységet Aditya K. Sood fedezte fel. A hibák között XSS és bizalmas rendszeradatokat hozzáférhetővé tevő hiba is található.

A gyártó a még támogatással rendelkező verziókat használó ügyfeleknek a 2016 októberinél későbbi firmware-re történő frissítést javasolják, a gyártói támogatással nem rendelkező verzióknál pedig a frissebb verzióra váltást ajánlják.

A hibákkal kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-348-01

Moxa DACenter sérülékenységek

Zhou Yu független biztonsági kutató a Moxa DACenter nevű OPC interfész-megoldásában talált több hibát. A hibák a DACenter 1.4 és ennél régebbi verzióit érinti. A sérülékenységek között program-összeomlást előidéző és nem megfelelően kezelt keresési feltételek okozta hibák találhatóak.

Mivel a DACenter termékvonal az életciklusa végén jár, a gyártó az MX-AOPC UA termékre történő váltást ajánlja minden, érintett terméket használó ügyfele számára. A DACenter számára a Moxa nem készít olyan frissítést, ami ezeket a hibákat javítaná. Azon ügyfelek számára, akik sérülékeny DACenter verziót használnak, a Moxa az ügyféltámogatási csoporttal történő kapcsolatfelvételt javasolja.

A sérülékenységekről további információkat az ICS-CERT publikációjából lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-16-348-02

Sérülékenységek Delta Electronics termékekben

A TrendMicro-hoz tartozó ZDI biztonsági kutatói, axt és Ariele Caltabiano több sérülékenységet találtak a Delta Electronics alábbi termékeiben:

- WPLSoft V2.42.11-nél korábbi verziói;
- ISPSoft 3.02.11-nél korábbi verziói és
- PMSoft 2.10.10-nél korábbi verziói.

A hibák között puffer-túlcsordulást illetve szabálytalan fájl olvasást és végrehajtást lehetővé tevő hiba is található.

A sérülékenységekkel kapcsolatban a gyártó az alábbi verziókra történő frissítést javasolja:

- ISPSoft V3.02.11;
- PMSoft V2.10.10;
- WPLSoft V2.42.11;

A hibákról több információt az ICS-CERT weboldalán és a ZDI alábbi publikációiban lehet olvasni:

http://www.zerodayinitiative.com/advisories/ZDI-16-672/
http://www.zerodayinitiative.com/advisories/ZDI-16-663/
http://www.zerodayinitiative.com/advisories/ZDI-16-662/
http://www.zerodayinitiative.com/advisories/ZDI-16-661/
http://www.zerodayinitiative.com/advisories/ZDI-16-660/
http://www.zerodayinitiative.com/advisories/ZDI-16-659/
http://www.zerodayinitiative.com/advisories/ZDI-16-658/
http://www.zerodayinitiative.com/advisories/ZDI-16-657/
http://www.zerodayinitiative.com/advisories/ZDI-16-656/
http://www.zerodayinitiative.com/advisories/ZDI-16-655/
http://www.zerodayinitiative.com/advisories/ZDI-16-654/
http://www.zerodayinitiative.com/advisories/ZDI-16-653/
http://www.zerodayinitiative.com/advisories/ZDI-16-652/
http://www.zerodayinitiative.com/advisories/ZDI-16-651/
http://www.zerodayinitiative.com/advisories/ZDI-16-650/
http://www.zerodayinitiative.com/advisories/ZDI-16-649/

OmniMetrix OmniView sérülékenységek

Az OmniMetrix OmniView nevű, vezérlőközpontokban használt rendszerében Bill Voltmer, az Elation Technologies LLC munkatársa talált két sérülékenységet is. A hibák az OmniView 1.2-es verzióját érintik. Az első hiba a webes bejelentkezési adatok titkosítás nélkül http-csatornán történő továbbítása, a második pedig lehetőséget ad támadóknak, hogy brute-force támadást hajtsanak végre a felhasználói jelszavak kitalálása érdekében.

A gyártó a hibákat a legújabb verzióban javította, ettől a verziótól kezdve az alkalmazás https protokollt használ és kötelező erős jelszavakat használni.

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

Siemens Desigo PX Web modul sérülékenységek

A Siemens Desigo PX webes moduljában Marcella Hastings, Joshua Fried és Nadia Heninger, a Pennsylvania Egyetem munkatársai találtak egy gyenge véletlenszám-generáló alkalmazás használatából adódó sérülékenységet. A hiba az alábbi termékeket érinti:

- Desigo PX PXC00-E.D, PXC50-E.D, PXC100-E.D, PXC200-E.D automatizálási vezérlők PXA40-W0, PXA40-W1, PXA40-W2 Desigo PX web moduljai, amik a V6.00.046-nál korábbi firmware verziókat használják;
- Desigo PX PXC00-U, PXC64-U, PXC128-U automatizálási vezérlők P PXA30-W0, PXA30-W1, PXA30-W2 Desigo PX web moduljai, amik a V6.00.046-nál korábbi firmware verziókat használják.

A sérülékenység abból adódik, hogy a nem kellően véletlenszerű véletlenszám-generáló alkalmazás használata miatt a https-titkosításhoz használt privát kulcsot egy támadó bizonyos körülmények között képes lehet megszerezni.

A hibát a Siemens a Desigo PX Web modulok V6.00.046-os firmware-verziójában javította.

A hibával kapcsolatban további információkat a Siemens ProductCERT publikációja tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-856492.pdf

Szerk: A hibával kapcsolatban megjelent az ICS-CERT publikációja is: https://ics-cert.us-cert.gov/advisories/ICSA-16-355-01

Fatek Automation PLC WinProladder sérülékenység

A Fatek Automation PLC WinProladder nevű termékében egy, a ZDI-vel együttműködő kutató talált puffer-túlcsordulást okozó hibát. A hiba a PLC WinProladder 3.11-es verziójának 14701-es build-jét érinti. A gyártó mindezidáig nem készített javítást a hibára, ezért a ZDI felvette a kapcsolatot az ICS-CERT-tel, majd saját szabályai szerint publikálta a sérülékenység részleteit.

További információkat a hibáról az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-350-01

A hibákkal kapcsolatban az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedések alkalmazását javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- 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!

ICS biztonsággal foglalkozó szakkönyvek I

Joseph Weiss: Protecting Industrial Control Systems from electronic threats

Az ICS biztonságról számos egészen jó szakkönyv jelent meg, ezek közül néhány szeretnék bemutatni itt a blogon. Sajnos magyarul tudomásom szerint egy sem érhető el - ez persze nem túl meglepő, hiszen az ICS biztonság itthon még az IT biztonsági szakmán belül is csak egy maroknyi ember figyelmét keltette fel.

Az első könyv, amit ebbe a sorozatba választottam Joe Weiss meghatározó kötete, amit a Momentum Press jelentetett meg. A könyv maga 327 számozott oldalból áll, 17 fejezetre, 5 függeléket, valamint 3 és fél oldalnyi ajánlott irodalmat tartalmaz.

A könyv az egyes fejezetekben bemutatja az ICS rendszerek felhasználási területeit, röviden ismerteti a legfontosabb, ICS-specifikus kifejezéseket és rövidítéseket, majd részletesen bemutatja a leginkább elterjedt ICS rendszerek (SCADA, DCS, RTU, stb.) működését. Ezután az ICS és IT rendszerek egyre szorosabb összefonódásai kerülnek bemutatásra, majd az ICS és IT rendszerek közötti különbségeket is megismerhetjük. A 6. fejezet az ICS rendszerek elektronikus fenyegetéseibe nyújt betekintést, a 7. fejezetben pedig a legelterjedtebb ICS biztonsági mítoszokat próblja meg eloszlatni. A következő fejezetekben az információmegosztás és az ICS kiberbiztonsági kockázatelemzés részleteivel ismerkedhet meg az olvasó, majd az ICS kiberbiztonsági trendeket és az ehhez kapcsolódó észrevételeit osztja velünk Joe. A könyv végén egy-egy fejezetben ártó szándékból illetve emberi hibákból eredő incidenseket ismerhetünk meg, majd az incidensek kategórizálása is szóba kerül. Az utolsó fejezetben Joe számos ajánlást fogalmaz meg az ICS rendszerek elektronikus biztonságával kapcsolatban, ezek között nem csak technikai javaslatok vannak, hanem adminisztratív, oktatási és minősítési, információmegosztással és incidenskezeléssel foglalkozó tanácsok egyaránt megtalálhatóak.

Ez a könyv, úgy vélem nem egy könnyű esti olvasmány, én azonban csak ajánlani tudom mindazoknak, akik most ismerkednek az ICS biztonság világával. A könyvet legegyszerűbben a különböző on-line értékesítő helyeken lehet beszerezni, általában 50-60 dollár körüli áron már lehet találni keményfedeles példányokat.

Vasúti jelzőrendszerek biztonsága II

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ó.

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