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

ICS Cyber Security blog

ICS Cyber Security blog

SFG/Furtim

Európai villamosenergia-szektorban működő céget célzó malware-t találtak a DarkWeb-en

2016. július 13. - icscybersec

A SentinelOne, egy izraeli kiberbiztonsági cég munkatársai egy olyan malware-t találtak a DarkWeb egyik fórumán, ami a vizsgálatok alapján feltételezhetően egy európai villamosenergia-szektorban működő szervezet elleni támadáshoz lett fejlesztve. A kutatók feltételezései szerint a Furtim idén május óta lehet aktív és két ismert exploit-ot (CVE-2014-4113 és CVE-2015-1701), valamint UAC-megkerülési technikát is alkalmaz. A malware fejlesztői jelentős erőfeszítéseket tettek annak érdekében, hogy ne csak a hagyományos antivirus és modern (next-gen) tűzfal-termékekkel ne lehessen észlelni az általuk fejlesztett malware-t, de a különböző sandbox-okat (pl. GFI, Joe Sandbox) is nagyon hatékonyan képes észlelni és ilyen környezetekben inaktív marad. Még érdekesebb a kutatóknak az a feltételezése, hogy a malware-t olyan létesítmény vagy létesítmények ellen tervezték, ahol nem csak a szoftveres, de a fizikai védelem szintje is magas. Ha a malware a ZKTeco nevű globális fizikai biztonsági rendszereket (arcfelismerő, ujjlenyomat olvasó és RFID rendszereket) gyártó cég szoftverét észleli a célba vett számítógépen, azonnal leállítja a működését, mivel ezeket a rendszereket az üzemeltetőik jellemzően szigorú felügyelet alatt tartják, így egy malware-fertőzés valószínűleg nem maradna észrevétlen.

A malware alacsony szintű API-kat (Nt* és Rtl*) és közvetlen rendszerhívásokat (INT 2Eh és CALL ntdll!KiFastSystemCall) használ, így kerülve el, hogy  antivirus szoftverekkel vagy sandbox-okkal felfedezzék. A SentinelOne munkatársai szerint ezeknek az eszközöknek a használata egyértelműen bizonyítja, hogy a Furtim fejlesztői igen alapos ismeretekkel rendelkeznek a Windows Driver Developement Kit használatával kapcsolatban. Az indirekt szubrutin hívások használatával a statikus manuális elemzéseket tették gyakorlatilag lehetetlenné, a dinamikus elemzések pedig fájdalmasak és lassúak. A kutatók által vizsgált malware-minta végső célja (a célba vett rendszeren talált antivirus szoftver csendes eltávolítása után) a lényegi kódjának futtatása.

A malware-t vizsgáló kutatók egyebek mellett ezek alapján azt feltételezik, hogy a fejlesztők mögött egy nemzetállam állhat, feltételezéseik szerint Kelet-Európából. Arról egyelőre nincsenek pontosabb információk, hogy milyen villamosenergia-ipari szervezettel kapcsolatban fedezték fel a Furtim-ot, azonban az európai villamosenergia-hálózattal kapcsolatban egyre gyakrabban látnak napvilágot különböző súlyú kiberbiztonsági incidensek és fenyegetések, amik nem ígérnek sok jót a jövőre nézve.

Az SFG/Furtim részletes elemzését a SentinelOne weboldalán lehet elolvasni: https://sentinelone.com/blogs/sfg-furtims-parent/

A SentinelOne elemzése nyomán számos biztonsági híroldal hozta le a saját összefoglalóját:

http://www.theregister.co.uk/2016/07/12/scada_malware/
http://securityaffairs.co/wordpress/49332/cyber-warfare-2/government-malware-dark-web.html
https://www.helpnetsecurity.com/2016/07/13/malware-backdoor-critical-infrastructure-targets/
http://thehackernews.com/2016/07/scada-malware-energy.html

Szerk: Robert M. Lee gondolatai a SentinelOne elemzéséről és a szakmai reakcióiról.

Ipari rendszerek kiberbiztonsági statisztikái a Kaspersky Lab-tól

Július 11-én a Kaspesky Lab Security Intelligence csapata két PDF-et publikált. Az elsőben az ICS rendszerek rendelkezésre állási statisztikáit, a másodikban az ICS sérülékenységek statisztikáit összegezték. A mai posztban ezeket fogom röviden áttekinteni, illetve az ICS sérülékenységi adatoknál a saját, 2016-ra vonatkozó gyűjtéseimmel kiegészíteni.

A Kaspersky kutatása alapvetően a nyílt forrású adatokra (Open Source Intelligence, OSINT) és publikusan elérhető információkra (pl. ICS-CERT publikációk, különböző ICS gyártók publikációi, stb.) épített és a 2015-ös évre fókuszált.

Annak ellenére, hogy az ICS biztonság területén a mai napig alapvetésnek számít, hogy ipari eszközöket és rendszereket ne csatlakoztassunk az Internetre, a kutatók több, mint 188 ezer ICS eszközt (és ezekben több, mint 220 ezer ICS komponenst) találtak az Interneten keresve (ez egyáltalán nem tűnik nehéz feladatnak, pl. a Shodan keresőjét használva). Az Interneten elérhetó ICS eszközök a világ 170 országában üzemelnek, vagyis globálisan létező rossz gyakorlatról beszélhetünk, azonban első helyen az USA áll (a kutatás során vizsgált ~13 ezer rendszer 30,5%-a itt üzemel). Európában az első helyen Németország (13,9%-kal), a második helyen Spanyolország (5,9%-kal), a harmadik helyen pedig Franciaország (5,6%-kal) áll (Magyarország a Top20-as listán nem szerepel).

A legtöbb, Interneten elérhető ICS rendszer az alábbi 10 gyártó termékei közül kerül ki:

1. Tridium (24446)
2. Sierra Wireless (17908)
3. Beck IPC (14837)
4. Digi International (12367)
5. SMA (11904)
6. Siemens (11232)
7. Moxa (11208)
8. HMS Industrial Networks AB (7680)
9. Lantronix (7533)
10. Westermo (5908)

Az ICS rendszerek komponensei közül a legtöbb sérülékenységet az alábbi 5 kategóriában találták:

1. ICS hálózati eszközök (61355)
2. PLC-k (33080)
3. SCADA rendszerek (22624)
4. Inverterek (19530)
5. HMI-k (15549)

Szintén régóta ismert probléma, hogy a legtöbb ipari rendszerek elavult és/vagy titkosítás nélküli protokollokat használ, ami tovább növeli az egyébként sem alacsony kockázatokat. A Kaspersky kutatási eredményei is mutatják, hogy a legnagyobb számban használt, problémás protokollok között még mindig túlsúlyban vannak a nem ICS-specifikus (vagyis elvileg könnyebben biztonságosabbra cserélhető) protokollok:

1. HTTP (116900)
2. Telnet (29586)
3. Niagara Fox (20622)
4. SNMP (16752)
5. Modbus (16233)

A Kaspersky kutatásából az is nagyon jól látszik, hogy a Stuxnet 2010-es nyilvánosságra kerülése után alig másfél év kellett ahhoz, hogy az ICS rendszerekben felfedezett sérülékenységek megtízszereződjenek. Ez a szám az azóta eltelt években sem csökkent számottevően, jellemzően 150 és 190 közötti sérülékenységet találnak a gyártók és kutatók minden évben a különböző ICS rendszerekben (ebből a szempontból várhatóan a 2016-os év sem fog javulást hozni, már amennyire ezt a saját gyűjtésem alapján látom, az év első 6 hónapjában 66 különböző bejelentésben 135 ICS sérülékenység jelent meg és ennél minden bizonnyal többet fedeztek fel, csak én nem tudok mindegyikről). Tovább árnyalja a képet, hogy a 2015-ben felfedezett sérülékenységek 49%-a magas, további 42%-a közepes kockázati besorolást kapott (CVSSv2 és CVSSv3 pontozások alapján) és közel 92%-uk távolról is kihasználható - ugyanez a megoszlás a 2016. első féléves adataim alapján az idei sérülékenységek 51%-a magas, 42%-a pedig közepes kockázatú és 88%-uk volt távolról is kihasználható.

Komponensek szerint bontásban a legtöbb sérülékenységet az alábbi ICS komponensekben találták:

1. HMI-k
2. Elektromos eszközök (ebbe a kategóriába többek között gázdetektorok, szivattyúk, relévezérlők, stb. tartoznak)
3. SCADA rendszerek
4. ICS hálózati eszközök

Már hosszú évek óta nyilvánvaló tény, hogy a különböző ipari rendszerek esetén az izoláció nem elégséges biztonsági intézkedés, különösképpen nem úgy, hogy ez a fajta izoláció gyakran csak az üzemeltetők/fejlesztők/biztonsági szakemberek fejében létezik és különböző (üzleti, technológiai, stb.) indokok miatt az ICS rendszerek már régen össze lettek kapcsolva a vállalati hálózattal, sok esetben pedig az Internettel is. Ez azt eredményezte, hogy az ICS rendszerek kockázatai nagyságrendekkel megnőttek, a különböző kritikus infrastruktúrák elleni támadások pedig azt is bizonyítják, hogy ezek a rendszerek egyre inkább a támadók érdeklődésének homlokterébe kerülnek (ezt láttuk a 2015 decemberi ukrajnai incidens során is). Ezeket a kockázatokat csak az ICS rendszerek üzemeltetői és fejlesztői közötti szorosabb és sokkal aktívabb együttműködéssel lehet elfogadható mértékűre csökkenteni.

ICS sérülékenységek XLVII

Moxa Device Server Web Console sérülékenység

Az ICS-CERT július 7-i publikációja szerint Maxim Rupp a Moxa Device Web Console nevű, soros-Ethernet átalakító eszközében talált hibát, ami a Device Server Web Console 5232-N típusú eszközök minden verzióját érinti.

A hibát kihasználva egy támadó képes lehet megkerülni a rendszer jogosultságkezelő eljárását.

A hibával kapcsolatban a gyártó minden érintett ügyfelének azt javasolja, hogy ne használják az eszközök 80/TCP és 23/TCP portjait, valamint a 161/UDP, 4800/UDP, és 4900/TCP portokat csak megbízható eszközökről lehessen elérni.

Az ICS-CERT ezen túlmenően a szokásos kockázatcsökkentő intézkedéseket javasolja:
- 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!

További részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-189-02

Kiberbiztonsági kockázatelemzés ICS infrastruktúráknál

Minden információ/IT-biztonsági intézkedés első lépése egy megalapozott kockázatelemzés elkészítése, ezzel lehet meghatározni, hogy melyek azok a kockázatok, amelyek túl magasak a rendszerre/szervezetre nézve és amelyek csökkentésére különböző intézkedéseket kell hozni. A különböző ipari rendszerek kiberbiztonsági kockázatelemzései, hasonlóan az ICS biztonság más területeihez, egy meglehetősen egyedi téma, amiről most Rebekah Mohrtól jelent meg egy rövidebb írás a SANS ICS Security Blog-ján.

Az ipari folyamatokkal kapcsolatban az általános kockázatelemzésnek nagyon komoly múltja és hagyományai vannak és az ezzel foglalkozó szakemberek nagyon jó munkát is végeznek. Problémát a kockázatelemzés szempontjából is az ICS rendszerek információ/IT-biztonsági kockázatelemzése jelent, nem utolsósorban azért, mert a klasszikus ipari kockázatelemzéssel foglalkozó szakemberek jellemzően nem ismerik és nem érint az IT és IT biztonsági kockázatok sajátosságait, az információ/IT-biztonsági kockázatelemzéssel foglalkozó kollégák pedig többnyire nincsenek tisztában az ICS rendszerek sehol máshol nem jelentkező egyedi tulajdonságaival.

Az ipari kockázatelemzések során több kockázatelemzési eszközt is használnak annak érdekében, hogy minél pontosabban tudják meghatározni a működési és emberéletet érintő biztonsági kockázatokat, ilyen többek között a Bow-Tie modell és kockázatelemzési mátrix (Risk Assessment Matrix, RAM), így határozva meg, hogy a maradványkockázatok elfogadhatóan alacsonyak-e (As Low As Reasonably Practicable, ALARP). Ezeket az eszközöket néhány kisebb változtatással az ipari rendszerek kiberbiztonsági kockázatelemzéséhez is hatékonyan lehet használni. Ennek a megoldásnak van egy további előnye, ilyen módon nem az egyes fenyegetések múltbeli előfordulása alapján próbáljuk megbecsülni a bekövetkezés valószínűségét (ahogy ez jellemzően az IT kockázatértékelések során szokott történni), hanem a támadáshoz szükséges erőforrások értékelése alapján. Erről a módszerről szól a SANS Reading Room-ban "Evaluating Cyber Risk in Engineering Environments: A Proposed Framework & Methodology" címmel elérhető útmutató.

ICS sérülékenységek XLVI

Rexroth Bosch BLADEcontrol-WebVIS sérülékenységek

Az ICS-CERT július 5-én kiadott figyelmeztetése szerint Maxim Rupp, független biztonsági kutató több hibát is talált a Rexroth Bosch által gyártott BLADEcontrol-WebVIS webes HMI rendszerben, amit elsősorban az energiaszektorban működő cégek használnak.

A hibák a BLADEcontrol-WebVIS Version 3.0.2 és ennél korábbi verzióit érinti.

A hibák között egy SQLi és egy XSS van, a CVSSv3 alapján mindkettő közepes súlyosságú besorolást kapott.

A gyártó a hibákat a legújabb szoftververzióban javította, ami innen tölthető le.

Az ICS-CERT ezzel a hibával kapcsolatban is a szokásos kockázatcsökkentő intézkedéseket javasolja:

- 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 hibával kapcsolatban részletesebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-187-01

Biztonsági alapelvek az ICS rendszerek világában

Aki valaha is közel került az információbiztonság témaköréhez, elég gyorsan szembe találta magát a csak CIA-modellként emlegetett alapelv-hármassal. A bizalmasság (confidentiality), sértetlenség (integrity), rendelkezésre állás (availability) természetesen az ICS rendszerekre is vonatkoztathatóak, azonban az általános információ- és IT-biztonsági gyakorlattol kissé eltérő módon történik az értékelésük az ipari rendszerek világában.

Rendelkezésre állás

Az ICS rendszerek terén az első üzembe helyezés óta a legfontosabb szempont a rendelkezésre állás. ICS/SCADA üzemeltetők nagyon gyakran (és egyáltalán nem alaptalanul) hallatlanul büszkék arra, hogy milyen sok kilences rendelkezésre állási mutatóik vannak az általuk üzemeltetett rendszereknek. Ez természetesen érthető is, hiszen ezeket a rendszereket kritikus infrastruktúrák, nagy értékű gyártósorok és más, hasonló rendszerek üzemeltetésére használják, ahol akár egy néhány perces üzemzavar is jelentős veszteségeket okozhat.

Sértetlenség

Nagyon sokáig a sértetlenség egy magától értetődő, adottságként kezelt témakör volt az ICS rendszerek világában, kérdésként maximum olyankor merült fel, amikor egy ICS rendszerben olyan szintű üzemzavar keletkezett, ami már a tárolt adatok sérülésével járt, ilyenkor azonban a mentések szinte mindig rendelkezésre álltak és ezzel meg lehetett előzni a komolyabb incidensek kialakulását.
Így volt ez egészen a Stuxnet színre lépéséig, amikor először merültek fel kételyek azzal kapcsolatban, ahogy az ICS/SCADA rendszerben látható adatok valósnak és hitelesnek tekinthetőek-e. Azóta az ICS rendszerek esetén is megnőtt a sértetlenség fontossága, bár mind a mai napig vannak, akik ezt a kérdést nem kezelik súlyának megfelelően.

Bizalmasság

A bizalmasság kérdése már jobban megosztotta az ICS üzemeltető szervezeteket, mert számos olyan iparág van, ahol az ICS rendszerekben kezelt egyes adatok bizalmassága nem kiemelt szempont, míg más adatok bizalmassága nagyon fontos lehet, azonban vannak olyan szervezetek (a legjobb példa erre egy gyógyszergyár lehet, ami a legújabb készítményének kifejlesztésére akár dollár milliárdokat is fordíthatott), ahol az ICS rendszer működéséhez szükséges adatok a legféltettebb üzleti titkok közé tartoznak.

Ezek azok a biztonsági alapelvek, amelyeket az ICS rendszerek esetén ugyanúgy alkalmazni kell, mint bármilyen IT rendszer esetén. Azonban az ICS rendszerek világában van két további alapelv, amelyek legalább annyira (ha nem jobban) fontosak, mint a CIA-modell.

Biztonság (safety)

Nehéz magyarra fordítani a safety-t, mert ahogy én is tettem, elsőre biztonság jut az ember eszébe (és a különböző szótárak és fordító alkalmazások is így fordítják). Ipari környezetekre vonatkoztatva én a Nemzetközi Atomenergia Ügynökség (IAEA) definícióját találtam a legjobbnak:

"The definition of safety as usually employed is the achievement of proper operating conditions, prevention of accidents or mitigation of accident consequences, resulting in protection of workers, the public and the environment from undue radiation hazards. (IAEA definition)

Nuclear security is the means and ways of preventing, detecting, and responding to theft, sabotage and unauthorized access to or illegal transfer of nuclear material and other radioactive substances, as well as their associated facilities. (IAEA definition)"
(Forrás: http://www.win-europe.org/faq?tmpl=component&faqid=28)

Azzal kapcsolatban úgy vélem senkinek nincs kétsége, hogy az ipari környezetek veszélyesek az ott dolgozó emberekre, ezért különösen elővigyázatosnak kell lennie mindenkinek, aki ilyen helyeken dolgozik. Kiemelten igaz ez a magas fokú automatizáltság esetén, hiszen a gépek a beléjük programozott logika szerint végzik a feladataikat és míg egy ember képes a számára kiadott utasításokat felülbírálni (pl. ha annak végrehajtása egy másik ember életének vagy testi épségének veszélyeztetését jelentené), a gépek és ICS rendszerek jellemzően erre nem vagy csak korlátozottan képesek.

Megbízhatóság (reliability)

A megbízhatóság az ICS rendszereknél még a rendelkezésre állásnál is fontosabb. Ezeknek a rendszereknek minden körülmények között pontosan azt és akkor kell tenniük, amire építették és programozták őket, egyes rendszerek esetén akár ezredmásodpercre pontosan. A megbízhatóság biztonsági kérdés is, hiszen látható, hogy akár napi rendszerességgel jelennek meg újabb sérülékenységek és az azokat javító gyártói frissítések a különböző rendszerekhez és egy-egy hibajavítás után a teljeskörű tesztelés nagyon időigényles, összetett folyamat. Ennek ellenére ezeket a teszteléseket nem szabad elmulasztani, mert az ICS rendszerek patch-elése (adódóan a rendszerek nagy mértékben egyedi voltából) minden esetben megbízhatósági problémákat okozhatnak.

ICS sérülékenységek XLV

Eaton ELCSoft sérülékenység

Sűrű a hét, ha az ICS sérülékenységeket nézzük, 5 nap alatt a negyedik posztot írom a témában, ma az ICS-CERT (a tegnapi Siemens SICAM PAS sérülékenység mellett) az Eaton ELCSoft sérülékenységéről adott ki publikációt.

A hibák (heap és stack-based puffer túlcsordulások) az ELCSoft 2.4.01 és korábbi verzióit érintik. A gyártó a weboldalán közzétett hibajavítás telepítését javasolja minden ügyfelének: https://eatonfilesharing.box.com/s/r4ulykfay2x5nlai9pqijivdh1zyks98
Fontos, hogy a jelenlegi firmware verziókat előbb el kell távolítani az eszközről, csak ezután lehet alkalmazni az új verziót!

Bővebb információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-182-01

Ugyanitt a szokásos kockázatcsökkentő intézkedéseket is el lehet olvasni:

- 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!

ICS sérülékenységek XLIV

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

A mai napon ismét több ICS rendszerrel kapcsolatos sérülékenység látott napvilágot.

WECON LeviStudio sérülékenységek

A ZDI 10 különböző, a WECON kínai ICS gyártó LeviStudio termékcsaládját érintő sérülékenységet hozott nyilvánosságra a tegnapi napon. A hibákat Rocco Calvi és a HPE ZDI csapatának tagjai fedezték fel.

A hibák minden érintett termékben távoli kódfuttatásra lehetőséget adó puffer túlcsordulásból származnak, a ZDI szerint a hiba jellege miatt az egyetlen használható kockázatcsökkentési intézkedés, ha az érintett alkalmazások csak megbízható állományokhoz rendelkeznek hozzáféréssel.

További információkat a ZDI bejelentései tartalmaznak:
http://www.zerodayinitiative.com/advisories/ZDI-16-390/
http://www.zerodayinitiative.com/advisories/ZDI-16-389/
http://www.zerodayinitiative.com/advisories/ZDI-16-388/
http://www.zerodayinitiative.com/advisories/ZDI-16-387/
http://www.zerodayinitiative.com/advisories/ZDI-16-386/
http://www.zerodayinitiative.com/advisories/ZDI-16-385/
http://www.zerodayinitiative.com/advisories/ZDI-16-384/
http://www.zerodayinitiative.com/advisories/ZDI-16-383/
http://www.zerodayinitiative.com/advisories/ZDI-16-382/
http://www.zerodayinitiative.com/advisories/ZDI-16-381/

Szerk: Időközben az ICS-CERT is publikálta a hibát: https://ics-cert.us-cert.gov/advisories/ICSA-16-189-01

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

A Siemens ProductCERT ma tette közzé, hogy Ilya Karpov és Dmitry Sklyarov, a Positiv Technologies munkatársai két, információszivárgást lehetővé tevő hibát találtak a SICAM PAS termékekben. Az első hibát (ami a 8.07-nél korábbi verziókat érinti) kihasználva egy sikeresen authentikált felhasználó képes lehet kinyerni a SICAM PAS adatbázisában tárolt felhasználói jelszavakat. A második hiba (ami minden SICAM PAS verziót érint) lehetővé teszi egy támadó számára, hogy érzékeny adatokat szerezzen a SICAM PAS adatbázis fájljából, ha az adatbázis le van állítva.

A gyártó az első hiba javítását a SICAM PAS 8.07-es verziójában már elérhetővé tette az ügyfelei számára, a második hiba javításán jelenleg is dolgoznak, amíg ezzel elkészülnek, a support.energy@siemens.com ügyfélszolgálati elérhetőségen adnak tanácsokat arra nézve, hogy milyen átmeneti intézkedések bevezetésével lehet csökkenteni a sérülékenység okozta kockázatokat.

További részleteket itt lehet olvasni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-444217.pdf

Szerk: Az ICS-CERT bejelentése a sérülékenységgel kapcsolatban: https://ics-cert.us-cert.gov/advisories/ICSA-16-182-02

ICS sérülékenységek XLIII

Sierra Wireless AirLink Raven XE Industrial 3G Gateway sérülékenységek

Karn Ganeshen (ő sem ismeretlen az ICS biztonsággal foglalkozók körében, korábban több általa felfedezett, ICS rendszereket érintő hibáról írtam én is) a seclist.org-on tette közzé, hogy a Sierra Wireless AirLink Raven XE ipari környezetbe szánt termékcsalád egyes eszközeiben talált 4 különböző hibát.

Az első hiba a bejelentkezési adatok nem megfelelő kezelésére vezethető vissza, ez a sérülékenység a bejelentés szerint az alábbi eszközöket érinti:

- Raven XE HSPA sorozat;
- GX400-as sorozat;
- GX440-es sorozat és potenciálisan minden GX sorozat.

A második hiba egy CSRF (Cross-site Request Forgery), ami az Ace Manager szoftverben található és az összes Raven XE (Ethernet) illetve XT (soros) porttal rendelkező eszközt érinti.

A harmadik hiba miatt egy megfelelően összeállított GET HTTP kéréssel érzékeny információkat lehet szerezni az érintett eszközökről. Ez a hiba szintén jelen van az összes Raven XE (Ethernet) illetve XT (soros) porttal rendelkező eszközben.

Az utolsó hiba authentikáció nélküli hozzáférést és korlátozás nélküli fájlfeltöltést tesz lehetővé az összes Raven XE és XT sorozatú eszközön.

További információkat és a gyártó Sierra Wireless hibákhoz kapcsolódó megjegyzéseit a Full Disclosure-ön lehet olvasni: http://seclists.org/fulldisclosure/2016/Jun/60

ICS sérülékenységek XLII

Rockwell Automation Allen-Bradley Stratix, Unitronics VisiLogic és Meinberg NTP Time Server sérülékenységek

Június 23-án ismét termékeny napja volt az ICS-CERT-nek, három különböző gyártó termékeivel kapcsolatos sérülékenységi bejelentést is publikáltak.

Rockwell Automation Allen-Bradley Stratix 5400 and 5410 csomag korrupciós sérülékenység

A Rockwell Automation a Cisco nemrégiben bejelentett, ipari switch-eit érintő hiba nyomán fedezte fel, hogy a saját, Allen-Bradley Stratix ipari switch-ei közül az alábbi verziók érintettek a hibában, ami az ICMP IPv4 csomagok nem megfelelő feldolgozásából adódik:

- Allen-Bradley Stratix 5400 Industrial Ethernet Switch 15.2(2)EA1 és 15.2(2)EA2 firmware verzió futtatása esetén, valamint
- Allen-Bradley Stratix 5410 Industrial Distribution Switch 15.2(2)EA2 firmware verzió használata esetén.

A hibát a gyártó a 15.2(4)EA3 verziójú firmware-ben javította, ami (authentikáció után) innen tölthető le: http://compatibility.rockwellautomation.com/Pages/MultiProductDownload.aspx?famID=5

További információk a hibával kapcsolatban az ICS-CERT bejelentésében találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-16-175-01

Unitronics VisiLogic OPLC IDE vlp sérülékenység

Steven Seeley, a Source Incite munkatársa fedezett egy puffer túlcsorduláson alapuló hibát a Unitronics VisiLogic 9.8.30-as verziónál régebbi firmware-t futtató termékeiben.

A hibát a 9.8.30-as vagy újabb verziójú firmware-ek telepítésével lehet javítani, amik a gyártó weboldalán érhetőek el: http://unitronicsplc.com/software-visilogic/

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

Meinberg NTP Time Server sérülékenységek

A Meinberg NTP szerver termékeiben Ryan Wincey független kutató fedezett fel több hibát is. A hibák az alábbi termékeket és szoftververziókat érintik:

- IMS-LANTIME M3000 Version 6.0 és korábbi verziók,
- IMS-LANTIME M1000 Version 6.0 és korábbi verziók,
- IMS-LANTIME M500 Version 6.0 és korábbi verziók,
- LANTIME M900 Version 6.0 és korábbi verziók,
- LANTIME M600 Version 6.0 és korábbi verziók,
- LANTIME M400 Version 6.0 és korábbi verziók,
- LANTIME M300 Version 6.0 és korábbi verziók,
- LANTIME M200 Version 6.0 és korábbi verziók,
- LANTIME M100 Version 6.0 és korábbi verziók,
- SyncFire 1100 Version 6.0 és korábbi verziók, és
- LCES Version 6.0 és korábbi verziók.

A hibák között két stack-based puffer túlcsordulás és egy gyenge hozzáférés kontrollon alapuló jogosultsági szint emelést lehetővé tevő (nobody user-ből root) hiba található.

A Meinberg a fenti hibákat a VErsion 6.20.004-es verziójú firmware-ben javította, amit a gyártó weboldaláról lehet letölteni.

További információkat ezúttal is az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-175-03

Az ICS-CERT mindhárom hibával kapcsolatban a szokásos kockázatcsökkentő intézkedések alkalmazását javasolja:

- 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üti beállítások módosítása
Mobil