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

ICS Cyber Security blog

ICS Cyber Security blog

ICS sérülékenységek XL

Sérülékenység Moxa PT-7728 sorozatú switch-ekben

2016. június 17. - icscybersec

Az ICS-CERT tegnap publikált bejelentése szerint Can Demirel független biztonsági kutató fedezett fel hibát a Moxa PT-7728-as sorozatú ipari switch-eiben.

A hiba az alábbi eszközöket érinti:

- PT-7728 Series Version 3.4 build 15081113

A PT-7728 sorozatú eszközökben létezik egy gyárilag beállított, legkisebb szükséges jogosultsággal rendelkező felhasználói fiók, amivel azonban egy lokális proxy-val lehetőség nyílik a hálózati forgalom módosításával megváltoztatni az érintett sorozatú switch-ek konfigurációját.

A gyártó elkészítette a hibát javító patch-et, amit Can Demirel ellenőrzött és megerősítette, hogy a patch javítja a hibát.
Az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedések alkalmazására hívja fel a figyelmet a bejelentés végén:

- 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 sérülékenységgel kapcsolatban további részletek az ICS-CERT weboldalán olvashatóak: https://ics-cert.us-cert.gov/advisories/ICSA-16-168-01

ICS sérülékenységek XXXIX

Sérülékenységek OSIsoft PI termékekben

Az ICS-CERT két, OSIsoft PI rendszert érintő sérülékenységről adott közre bejelentést:

OSIsoft PI AF Server sérülékenység

Az első hiba a PI AF Server 2016-nál, illetve 2.8.0-nál régebbi verzióit érinti és a rendszerbe bevitt adatok nem megfelelő ellenőrzéséből ered. A hibából eredő kockázatok csökkentésére az OSIsoft az alábbiakat javasolja ügyfeleinek:

- Frissíteni kell a sérülékenység által érintett szoftvereket a PI AF Server 2016-os verziójára;
- Host tűzfalak alkalmazásával a feltétlenül szükséges mértékre kell csökkenteni azoknak a megbízható munkaállomásoknak a számát, amik PI SQL termékeket (pl. PI OLEDB Enterprise-t) futtatnak és a 5459/tcp porton próbálnak csatlakozni az AF szerverhez. Ezen a porton keresztül két termék használja a rendszer kereső funkcióját, a PI WebParts 2010-es és korábbi verziói, valamint a PI Coresight 2013 és korábbi verziói;
- Az AF szerverhez csak azoknak a felhasználók kapjanak hozzáférést, akiknek a feladataik miatt ez indokolt. A gyártó által közzétett biztonsági közlemény itt érhető el: https://techsupport.osisoft.com/Troubleshooting/PI-System-Cyber-Security, az ICS-CERT bejelentése pedig itt: https://ics-cert.us-cert.gov/advisories/ICSA-16-166-02

OSIsoft PI SQL Data Access Server sérülékenység

Ugyancsak a rendszerbe bevitt adatok nem megfelelő ellenőrzése miatt sérülékeny az OSIsoft PI Data Access Server megoldásának 2016 (1.5) korábbi verzióját tartalmazó két terméke:

- PI JDBC Driver 2015 (1.4.1.404) és korábbi verziók, valamint a
- PI ODBC Driver 2015 (3.5.403) és korábbi verziók.

A gyártó szerint a fenti termékek esetén az authentikált forrásból érkező adatok nem megfelelő kezelése miatt szolgáltatás-megtagadást (DoS) lehet előidézni a sérülékeny verziót futtató rendszereken.

A gyártó a hibát a PI SQL Data Access Server (OLE DB) 2016 (1.5) verzióban javította, az erre történő frissítés mellett további kockázatcsökkentő intézkedéseket is javasol a sérülékeny verziókat használó ügyfelek számára:

- Frissíteni kell a sérülékenység által érintett szoftvereket a PI SQL Data Access Server (OLE DB) 2016 (1.5) verziójára;
- Host tűzfalak alkalmazásával a feltétlenül szükséges mértékre kell csökkenteni azoknak a megbízható munkaállomásoknak a számát, amik PI SQL kliens termékeket (pl. PI JDBC Driver, PI ODBC Driver) futtatnak és a 5461/tcp vagy 5462/tcp portokon próbálnak csatlakozni a szerverhez;
- A PI SQL Data Access Server-hez csak azoknak a felhasználók kapjanak hozzáférést, akiknek a feladataik miatt ez indokolt. A gyártó által közzétett biztonsági közlemény itt érhető el: https://techsupport.osisoft.com/Troubleshooting/PI-System-Cyber-Security, az ICS-CERT bejelentése pedig itt: https://ics-cert.us-cert.gov/advisories/ICSA-16-166-01

Az ICS-CERT mindkét sérülékenységgel 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!

ICS rendszerek elleni kibertámadások a sajtóban

Robert M. Lee (a US Air Force egykori biztonsági szakértője, a SANS ICS biztonsági kurzusainak oktatója) blogjában egy nemrég a Huffington Post weboldalán megjelent, kritikus infrastruktúrák kiberbiztonsági helyzetével foglalkozó cikk kapcsán azzal a kérdéssel foglalkozik, hogy a különböző ipari rendszerek, folyamatirányító rendszerek elleni kibertámadásokról szóló cikkekben megjelenő megállapítások mennyire megalapozottak.

A blogbejegyzésben több példán keresztül mutatja be, hogy egy-egy kijelentés mögött gyakran mennyire nincs semmilyen bizonyíték, csak a szerző elképzelése (tévképzete) a témában. Erre vonatkozóan példának hozza a Huffington Post cikkében említett, 2003-as nagy észak-kelet USA-t érintő áramszünetet, amivel kapcsolatban a HuffPost cikkében olyan megállapítás is megjelent, ami szerint nem csak, hogy a 2003-as áramszünet kiváltó oka egy kibertámadás volt, hanem ezt az USA kormánya szándékosan eltitkolta.

A cikk egy másik állítása, amivel kapcsolatban Robert megfogalmazta kételyeit, az ukrán áramszolgáltatók elleni kibertámadás magas fokú kifinomultságára és a rendszerek tartós üzemképtelenségére vonatkoznak. Az ezekkel foglalkozó blogbejegyzés a www.robertmlee.org-on található.

Napjainakban minden, ipari rendszereket érintő incidens esetén felmerül a kérdés, hogy a kiváltó okok között volt-e a kibertámadás (ahogy ez az egyik első gondolata volt szinte mindenkinek a 2015-ben szinte egy időben bekövetkezett törökországi és amsterdami áramkimaradások esetén is - utólag a hivatalos álláspont egyébként mindkét esettel kapcsolatban az volt, hogy nincs köze kibertámadásnak az incidensekhez) és az eltérő véleményekkel sincs alapvetően baj. Az azonban jóval komolyabb probléma, hogy az ilyen incidensekkel kapcsolatban (hasonlóan ma már bármilyen fontosabb hírhez) a híradás gyorsasága fontosabbá válik a pontos információk biztosításánál is, ráadásul gyakran még a szaksajtóban publikáló újságírók egy része is komoly tárgyi tévedésekkel tűzdelt cikkeket közöl. Ezt legutóbb pont az ukrán áramkimaradások eseténél láttuk, egészen eltérő adatok is napvilágot láttak azzal kapcsolatban, hogy pl. hány embert érintettek az áramkimaradások vagy hogy a BlackEnergy melyik variánsát használták a támadás korai fázisában.

Meg kell találni azt az egyensúlyi pontot, ami biztosítja, hogy pontos információk a lehető leggyorsabban jussanak el azokhoz az illetékesekhez, akiknek feladatuk a nemzeti kritikus infrastruktúrák védelme. Igaz ez különösen most, hogy már látszik, ez a téma egyre fontosabb lesz, ami azt is jelenti, hogy egyre több emberi és anyagi erőforrás fog áramlani a kritikus infrastruktúrák kiberbiztonságába.

ICS sérülékenységek XXXVIII

Siemens SIMATIC S7-300 CPU, SIMATIC WinCC flexible, KMC Controls Conquest BACnet Router és Trihedral VTScada sérülékenységek

Jó termést eredményezett az elmúlt 24 óra a különböző ICS rendszerek sérülékenységei terén, ma három gyártó négy különböző termékéhez is publikáltak új sérülékenységeket.

Siemens SIMATIC S7-300 CPU sérülékenység

A Siemens S7-300 CPU termékcsaládjának alábbi verzióihoz jelent meg egy bejelentés:

SIMATIC S7-300 CPU típusú eszközök, Profinet támogatással, ha V3.2.12-nél régebbi verziójú firmware-t használnak;
SIMATIC S7-300 CPU típusú eszközök Profinet támogatás nélküli változatok, ha V3.2.12-nél régebbi verziójú firmware-t használnak.

A hiba kihasználásával a sérülékeny eszközöket hibás üzemmódba lehet jutattni, ahonnan csak egy leállítás-újraindítás végrehajtásával lehet helyreállítani a működőképes állapotot.

A hibát Csorba J. Máté, a Marine Cybernetics Services és Amund Sole, a Norvég Műszaki Tudományegyetem munkatársainak közreműködésével a V3.2.12-es firmware-ben javította a Siemens.

További részleteket a gyártó által közzétett bejelentés tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-818183.pdf

Siemens SIMATIC WinCC flexible sérülékenység

Maradva még a Siemens termékeinél, tegnap a WinCC flexible 2008 SP3 Up7-nél korábbi verzióval kapcsolatban jelent meg egy bejelentés, ami szerint az érintett eszközökben a bejelentkezési adatok védelme nem megfelelő szintű.

A hibát Gleb Gritsai és Roman Ilin, a Positive Technologies munkatársainak segítségével javította a Siemens az Update 7 verzióban.

Részleteket ezúttal is a Siemens ProductCERT-en elérhető eredeti bejelentés tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-526760.pdf

KMC Controls Conquest BACnet Router sérülékenységek

Az ICS-CERT tegnapi bejelentése szerint Maxim Rupp, független biztonsági kutató a KMC Controls BACnet routereiben talált két sérülékenységet. A BAC-5051E típusú eszközök, ha E0.2.0.2-nél régebbi firmware-t futtatnak, tartalmaznak egy CSRF sérülékenységet, illetve egy másik hiba miatt authentikáció nélkül lehet konfigurációs adatokat kiolvasni belőlük.

A KMC Controls a partner portálján elérhetővé tett E0.2.0.2-es verziójú firmware-ben javította a fenti hibákat. 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-159-01

Trihedral VTScada sérülékenységek

Egy meg nem nevezett biztonsági kutató talált sérülékenységeket a Trihedral VTScada nevű termékében és jelentette azt a ZDI-nek, amiket tegnap az ICS-CERT publikált. A hibák a VTScada 8-tól 11.2.02-ig terjedő verzióit érinti.

A hibák között van pufferen kívüli olvasás, jogosultság nélküli könyvtár- és fájlhozzáférést lehetővé tevő hiba és authentikáció megkerülés.

A gyártó az FTP szerverén elérhető 11.2.02-es firmware verzióban javította a hibákat. További információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-159-01

Szerk: Július 1-jén a ZDI megjelentette a hibák részletes leírásait, amiket az alábbi linkeken lehet elérni:
http://www.zerodayinitiative.com/advisories/ZDI-16-403/
http://www.zerodayinitiative.com/advisories/ZDI-16-404/
http://www.zerodayinitiative.com/advisories/ZDI-16-405/

Francia biztonsági tanúsítványt kapott a Siemens S7-1500 PLC

A francia l’Agence nationale de la sécurité des systemes d’information (ANSSI) a május 16-i héten adta ki azt a tanúsítást, amely szerint a Siemens S7-1500 típusú PLC berendezések teljesítik az ANSSI védelmi profiljában előírt, rövid távú biztonsági követelményeket. Az ANSSI védelmi profilja nem keverendő a Common Criteria Protection Profile-lal, de az alapelvek mindkettő esetén azonosak. A tanúsításra törekedő szervezetnek meg kell fogalmazni egy biztonsági célt és meg kell jelölnie, hogyan fogja teljesíteni a védelmi profil követelményeit. A konkrét esetben a cél az volt, hogy egy, már a felügyeleti hálózatba bejutott támadótól legyenek képesek megvédeni a PLC-t, a feladat sikeres végrehajtását egy független harmadik fél, az Amossys (francia kiberbiztonsági vállalat) ellenőrizte.

A vizsgált védelmi profil biztonsági követelményei között szerepel az aláírt firmware és a biztonságos boot-olás követelménye, a szándékosan hibás formátumú adatbevitel megfelelő kezelése valamint az authentikációs adatok és kulcsok biztonságos tárolása PLC-ken. Mindezek a követelmények (ahogy korábban már én is említettem), a rövid távú biztonsági követelményeket tartalmazó védelmi profilban vannak megadva, emellett létezik egy középtávú védelmi profil is, amiben megjelenik a naplóbejegyzések és riasztások integrált kezelése. A Siemens mellett más ipari berendezéseket gyártó vállalat is részt vett a védelmi profilok megalkotásában, többek között a Belden, a Phoenix Contact és a Schneider Electric, így minden bizonnyal a jövőben több gyártó termékeinél találkozhatunk majd ANSSI tanúsítványokkal.

A rövid távú védelmi profil részletes, 11 oldalas leírása itt érhető el (angol nyelven).

Irongate ICS malware

A Stuxnet példáját követő, ICS rendszerekre fókuszáló malware-t fedezett fel a FireEye

A tegnapi napon az IT biztonsági szaksajtó és az ICS kiberbiztonsággal foglalkozó blogok sorban hozták le a hírt, hogy a FireEye Labs Advanced Reverse Engineering (FLARE) csapata még 2015-ben több verziót is felfedezett egy kifejezett ICS rendszerekre specializált malware-családból, aminek elsődleges célja különböző ipari folyamatok manipulálása lehet.

 A FLARE-nél a malware-családnak az Irongate nevet adták (úgy látszik a marketingesek az ICS biztonsági eseményeknél is megvalósítják azt az IT biztonságban már elterjedt szokást, amit néhány éve Buherátor nagyon frappánsan foglalt össze az azóta jobblétre szenderült buhera blogon: "A biztonsági cégek nagyjából a Stuxnet óta néhány havonta iszonyatos marketing csinnadrattával ünneplik egy-egy új "APT" kártevő felfedezését, elemzéseket, sajtóközleményeket adnak ki, konferenciát szerveznek, a marketing osztálynak meg kiadják, hogy a legújabb "csodafegyver" márkanevétől ihletten rajzoljanak vagány illusztrációkat - így végül saját sikerükként adják el azt, hogy éveken keresztül nem voltak képesek elvégezni azt a feladatot, amiért az ügyfeleik fizettek nekik.")

Az Irongate-tel kapcsolatban több furcsa dologra is fel lehet figyelni, az első az, hogy a malware-t nem "aktív működés" közben találták és a szakértők szerint (jelenleg) nem jelent kiemelt kockázatot a produktív ipari rendszerek számára. A Siemens ProductCERT sietve erősítette meg, hogy az Irongate malware nem életképes produktív Siemens ICS rendszerek esetén és a működéséhez nem használ fel Siemens rendszerekben lévő ismert vagy 0-day sérülékenységeket. A FLARE jelenleg nem tudja az Irongate-családot bármilyen támadáshoz vagy támadóhoz kapcsolni, a rendelkezésükre álló információk alapján az Irongate egy proof-of-concept vagy kutatási célból létrehozott malware lehet, amivel különböző ICS rendszerek elleni támadási technikákat vizsgálhattak a mindezidáig ismeretlen alkotók.

A FLARE elemzése alapján az Irongate kulcs funkciója a megtévesztéshez használt Man-in-the-middle támadás, amivel a támadók manipulálni tudják az ICS rendszer és az operátor közötti adatforgalmat (ezzel egy Stuxnet-hez hasonló, adathamisítást előidéző támadást megvalósítva). Ennek eléréséhez a malware a legitim DLL-t egy saját változatra cseréli, ami innentől kezdve ügynökként beépül a PLC és a monitoring szoftver közé majd egy 5 másodperces normál forgalmat rögzít és ismétel a monitoring rendszer felé, miközben eltérő adatokat küld vissza a PLC-nek. Ezzel a módszerrel a támadónak lehetősége van az operátor tudta nélkül megváltoztatni a folyamatok vezérlését.

Az Irongate másik figyelemre méltó funkciója a sandbox-ban történő vizsgálat elkerülését szolgálja. Az Irongate malware dropperei közül több nem indul el, ha VmWare vagy Cuckoo Sandbox környezetben próbálják vizsgálni a működését. Ez a tulajdonság arra enged következtetni a kutatók szerint, hogy a malware-t, bár tesztelési céllal készíthették, ártó szándékkal tesztelhették az alkotói.

Ugyan a komplexitás vagy a terjedési módszerek terén az Irongate nem mérhető össze minden ICS incidensek mérföldkövével, a Stuxnet-tel, számos olyan módszert és funkciót használ, amiket a Stuxnet alkotói is használtak az iráni atomprogram urándúsító centrifugáinak tönkretétele során és új funkciók is megjelentek, amik eddig nem voltak jellemzőek az ICS-fókuszú malware-ekre.

- A malware minden változata egy-egy jól meghatározott folyamatot keres;
- Mindegyik egy DLL lecserélésével éri el a keresett folyamat manipulálhatóságát;
- A Stuxnet antivírus szoftvert kereső rutinjánhoz hasonlóan az Irongate figyeli, hogy tesztkörnyezetben/sandbox-ban fut-e;
- Az Irongate aktívan rögzíti és visszajátsza a folyamatok eredeti adatait, hogy elrejtse a manipuláció jeleit, szemben azzal, hogy a Stuxnet csak felfüggesztette az S7-315-ös eszközök normál működését, így az iráni operátorok előtt statikus adat jelent meg. Ehelyett az Irongate által rögzített és visszajátszott adatok továbbra is "élőnek" tűnnek, így még nehezebb felfedezni, hogy a háttérben valaki manipulálja a folyamatot.

A FireEye elemzése további, mélyen technikai részletekkel itt érhető el: https://www.fireeye.com/blog/threat-research/2016/06/irongate_ics_malware.html

ICS sérülékenységek XXXVII

GE MultiLink sorozatú switchek sérülékenysége

A GE egy kritikus súlyosságú (CVSSv3 szerint 10.0 pontszámú) sérülékenységet talált az alábbi MultiLink switch-ekben:

- GE ML800 Switch, Version 5.5.0-nál korábbi firmware verzió esetén;
- GE ML810 Switch, Version 5.5.0k-nál korábbi firmware verzió esetén;
- GE ML1200 Switch, Version 5.5.0-nál korábbi firmware verzió esetén;
- GE ML1600 Switch, Version 5.5.0-nál korábbi firmware verzió esetén;
- GE ML2400 Switch, Version 5.5.0-nál korábbi firmware verzió esetén;
- GE ML3000 Switch, Version 5.5.0k-nál korábbi firmware verzió esetén és
- GE ML3100 Switch, Version 5.5.0k-nál korábbi firmware verzió esetén.

A sérülékenységet a gyárilag beégetett jelszavak jelentik, amiket ismerve egy támadó jogosulatlanul adminisztrátori szintű hozzáférést szerezhet az érintett firmware verziókat futtató eszközökön.

A gyártó a hibát az ML800-as, ML1200-as, ML1600-as és ML2400-as típusú switch-ek esetén a Version 5.5.0 verziójú, az ML810-es, ML3000-es és ML3100-as switch-ekben pedig a Version 5.5.0k verziójú firmware-ben javította, amik a http://www.gegridsolutions.com weboldalről tölthetőek le.

További részleteket a sérülékenységgel kapcsolatban az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-16-154-01

A sérülékenységgel kapcsolatban az ICS-CERT a szokásos kockázatcsökkentő intézkedések bevezeté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!

ICS sérülékenységek XXXVI

ABB PCM600 és Moxa UC 7408-LX-Plus sérülékenységek

Tegnap az ICS-CERT két bejelentést publikált, amelyek az alábbi termékek sérülékenységeinek részleteit tartalmazták:

ABB PCM600 sérülékenységek

Ilya Karpov, a Positive Technologies munkatársa 4 különböző hibát talált az ABB PCM600-as típusú eszközeiben, amennyiben azok 2.6-os vagy korábbi verziójú szoftvert futtatnak. A hibák közül három a rendszer által használt jelszavak nem tárolását eredményezi bizonyos körülmények (például jelszóváltoztatás után) között, a negyedik hiba pedig a rendszer által az egyik jelszó esetén használt hash algoritmus gyengeségéből adódik, így a jelszóhasht rövid idő alatt lehet törni.

Ezeket a hibákat csak lokálisan és felhasználói interakció segítségével lehet kihasználni.

A gyártó a hibákat a 2.7-es szoftververzióban javította és minden ügyfelének a mielőbbi frissítést ajánlja, továbbá az alábbi kockázatcsökkentő intézkedések bevezetését:

- Fizika hozzáférési szabályokkal kell biztosítani, hogy a PCM600-asokhoz csak az erre jogosult személyek tudjanak hozzáférni;
- Nem szabad a vezérlőrendszerhez közvetlen Internet-kapcsolatot biztosítani;
- A vezérlőrendszer hálózatát tűzfalakkal el kell szeparálni minden más hálózati szegmenstől és a tűzfalakon csak a minimálisan szükséges portok forgalmát szabad engedélyezni;
- A folyamatvezérlési feladatokra használt rendszert nem szabad Internetböngészésre, azonnali üzenetküldésre vagy elektronikus levelezésre;
- Körültekintően ellenőrizni kell a hordozható számítógépeket és adathordozókat és teljes körű víruskeresést kell végezni rajtuk, mielőtt a vezélőrendszerhez csatlakoztatnánk őket.

Az ICS-CERT ezen túlmenően (a szokásos módon) felhívja a figyelmet a távoli elérések biztonságosabbá tételéhez használt VPN-megoldások esetleges sérülékenységeire és arra tényre, hogy minden VPN-megoldás csak annyira biztonságos, mint az azon keresztül csatlakoztatott eszközök.

A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-152-02

Moxa UC 7408-LX-Plus sérülékenység

Az ICS-CERT meg nem nevezett forrásból szerzett információi szerint a Moxa UC 7408-LX-Plus típusú beágyazott számítógépek minden verziója érintett egy olyan hiba által, aminek következtében authentikáció nélkül lehet felülírni a berendezések firmware-jét. Egy ilyen firmware-felülírást nem lehet javítani, amennyiben megtörtént a felülírás, az eszközt cserélni kell. A helyzetet súlyosbítja, hogy a gyártó már megszűntette az érintett típusú eszközök támogatását, így a hibával kapcsolatban nem várható javítás.

A Moxa számos javaslatot tesz a sérülékenység miatt megnövekedett kockázatok csökkentésére:

Erősebb authentikációt kell biztosítani az eszközök számára
 - Rendszeresen változtatni kell az adminisztrátori jogosultságú felhasználói fiókok jelszavait;
 - Erős jelszavakat kell használni;
 - A nem használt felhasználói fiókokat tiltani vagy törölni kell (én azért a törlést auditálhatósági okokból nem javaslom, egy nagyon hosszú és bonyolult, véletlenszerű jelszóval történő felülírás után inkább célszerű riasztást beállítani arra az esetre, ha az adott felhasználói fiókkal bejelentkezési kísérletet észlel a rendszer);
 - Le kell tiltani a nem létfontosságú szolgáltatások futását;
 - Engedélyezni kell a rendszernaplók monitorozását;
 - Naplózni kell a sikertelen bejelentkezési kísérleteket is;
 - Automatikusan ki kell jelentkeztetni az SSH és Telnet kapcsolatokon bejelentkezve maradt, inaktív felhasználókat (megint csak az én véleményem, hogy a Telnet használatától érdemes tartózkodni).
 
Erősíteni kell a hozzáférés-vezérlést
 - Meg kell szigorítani a különböző programkódok letölthetőségét és futtathatóságát;
 - Limitálni kell a párhuzamos munkafolyamatok, pl. SSH-kapcsolatok számát;
 - Audit okokból a hozzáférési logoknál időbélyeget kell használni (hozzátenném, hogy ha ezt teszi valaki, célszerű központi NTP-szinkronizálást is beállítani).

Fejleszteni kell az adatok integritásának megőrzését biztosító eljárásokat és technikákat
 - Ennek érdekében biztonságos protokollokat (pl. SSH, VPN, HTTPS, stb.) kell használni (ismét csak saját véleményem, hogy a titkosítás nélkül működő protokollok használatát, mint pl. Telnet, RSH, rexec, FTP, stb. már csak a bizalmasság megőrzése érdekében is érdemes kerülni, hiszen bármilyen biztonságos lehet egy jelszó, ha azt egy támadó a hálózati forgalom lehallgatása után simán olvashatja).
 
Fejleszteni kell az adatok integritásának megőrzését biztosító eljárásokat és technikákat
 - Minden olyan adatmegosztást meg kell szüntetni, amire már nincs szükség.
 
Szigorítani kell az adatok áramlására vonatkozó szabályokat
 - A tűzfalakon tiltani kell a minden forgalmat engedélyező szabályokat (nem sokat ér az a tűzfal, aminek a szabályláncában egy ACCEPT IP any any áll az utolsó sorban).
 
Az ICS-CERT ennek a sérülékenységnek az apropóján is a már jól megszokott kockázatcsökkentő intézkedéseket sorolja.

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

ICS Secure: CheckPoint-IBM összefogás fejlettebb ICS biztonsági eszközök létrehozására

Nem újdonság (én is írtam már róla), hogy az általános IT biztonsági termékek nem vagy csak nehézkesen használhatóak ipari környezetekben. Itt nem csak az ipari környezetekre jellemző mostoha fizikai körülményekre kell gondolni (bár vitathatatlan, hogy bizonyos iparágakban olyan szélsőséges fizikai körülményeket kell kiállniuk informatikai eszközöknek, amik speciális kialakítást igényelnek), hanem arra, hogy az ICS rendszerek működése sok esetben nagyon különbözik a vállalati IT rendszerek működésétől.

Ezt látszik felismerni az IT biztonsági piac két meghatározó szereplője, a CheckPoint és az IBM, akik együtt alkották meg legújabb terméküket ICS Secure néven. Erről szól az IBM által vezetett Securiy Intelligence blog legújabb bejegyzése.

Azt még nem látom, hogy ez a termék mennyire lesz használható és hatékony, az azonban mindenképp örvendetes, hogy egyre több biztonsági fejlesztő cég ismeri fel, hogy az ipari rendszerek biztonságára komolyabb figyelmet kell fordítani, mint ahogy azt eddig tették.

A Secuirty Intelligence blogbejegyzésének végén elérhető az X-Force (az IBM kiberbiztonsági kutatócsoportja) által írt 22 oldalas publikáció az ipari folyamatirányító rendszerek biztonságáról. Ez az összefoglaló nagyon jól bemutatja, hogyan változott az ICS rendszerek világa az elmúlt évtizedekben és milyen új kockázati tényezők jelentek meg az ipari rendszerek egyre nagyobb fokú digitalizálása nyomán.

ICS sérülékenységek XXXV

Black Box AlertWerks ServSensor, Sixnet BT Series és Environmental Systems Corporation Data Controllers sérülékenységek

Az ICS-CERT tegnapi bejelentései alapján megint mozgalmas napjuk lehetett, három különböző ICS gyártó termékeiről publikáltak ismert hibákat.

Black Box AlertWerks ServSensor sérülékenység

A Black Box termékében Lee Ryman független biztonsági kutató hibát, ami az AlertWerks ServSensor alábbi verzióit érinti, amennyiben azok a Version SP473-nál régebbi firmware-t használják:

- A Black Box’s AlertWerks ServSensor EME105A, EME106A, EME108A-R2, EME109A-R2 és EME110A-R2 modellszámú termékei;
- A Black Box’s AlertWerks ServSensor Junior EME102A-R2, EME103A-R2 és EME104A-R2 modellszámú termékei;
- A Black Box’s AlertWerks ServSensor Junior with PoE, EME152A, EME153A, EME154A, EME155A, and EME158A modellszámú termékei és
- A Black Box’s AlertWerks ServSensor Contact EME111A-20-R2, EME111A‑60-R2, EME112A-20-R2, EME112A-60-R2, EME113A-20-R2 és EME113A‑60-R2 modellszámú termékei.

A hiba meglehetősen banális, bármilyen sikeresen authentikált felhasználó képes lekérdezni az adminisztrátori fiók vagy bármelyik másik felhasználó jelszavát. A gyártó a hibát a Version SP473-as firmware-ben javította, ezt a következő FTP tárhelyről lehet letölteni: ftp://ftp.blackbox.com/AlertWerks%20Firmware/fw%20SP-473%20for%20EME102%20-EME113%20and%20EME152%20-%20EME158.zip

A sérülékenységről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-147-03

Sixnet BT-sorozatú mobil router sérülékenység

A Sixnet BT-sorozatú mobil routereiben Neil Smith független kutató talált hibát, ami a Sixnet BT-5xxx és BT-6xxx sorozatú M2M mobil routereit érinti, amennyiben azok 3.8.21-esnél régebbi firmware-t futtatnak. A hiba ebben az esetben sem rendkívüli, az érintett sorozatokba tartozó routerekben gyárilag beégetett felhasználói azonosítók vannak. A Sixnet ügyfelei az érintett eszközök hibáit a 3.8.21-es vagy 3.9.8-as verziójú firmware-ek egyikére történő frissítéssel javíthatják.

A hibáról további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-16-147-02

Environmental Systems Corporation Data Controllers sérülékenységek

A nap utolsó hibáját az Environmental Systems Corporation (ESC) Data Controller nevű webes SCADA rendszerében találta a blogon már sokszor emlegetett Maxim Rupp. Az eset érdekessége, hogy az ESC-től származó információ szerint ugyanezt a hibát Makány Balázs már jelentette feléjük 2015. február 18-án.

A hiba az ESC 8832-es típusú Data Controllerek 3.02-es és korábbi verziójú firmware-jeit futtató példányait érinti. A hibák között egy authentikáció-megkerülési lehetőséget biztosító van, a másik hibát kihasználva pedig egy az eszköz menürendszerében nem megjelenített funkciókhoz férhet hozzá a megfelelő paraméter brute force-olásával.

A gyártó szerint az érintett eszközökön nincs hely a további hibajavítások kódjai számára, így a firmware frissítése nem lehetséges! Az ESC mindezeket figyelembe véve az érintett eszközök upgrade-jét javasolja, illetve ahol ez nem megoldható, ott a kockázatok csökkentésére egyéb intézkedések bevezetését ajánlja, az eszközök 80/tcp portjához történő hozzáférés tűzfalas szűrését, illetve a webes operátori interfész használata helyett az eszköz által biztosított egyéb hozzáférési módok használatát. Részletesebb tanácsokat a gyártó weboldalán lehet találni (bejelentkezés után): www.envirosys.com.

A hibával kapcsolatos bővebb információkért megint csak az ICS-CERT bejelentését érdemes elolvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-147-01

Az ICS-CERT a fenti sérülékenységekkel kapcsolatban a szokásos javaslatokat teszi a kockázatok csökkentése érdekében:

- 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