Augusztus elején a FireEye egy 12 oldalas PDF-et publikált, amiben összefoglalták az általuk 2000 óta összegyűjtött, publikusan elérhető, ICS rendszereket érintő sérülékenységekkel kapcsolatos elemzéseiket.

A publikált adatokból tisztán látszik, hogy 2008 előtt elenyésző számú ICS sérülékenység vált publikussá, de igazán a Stuxnet 2010-es felfedézése után nőtt meg ugrásszerűen az ilyen sérülékenységek száma (egészen pontosan 2011-ben négyszer annyi sérülékenységet publikáltak ICS rendszerekkel kapcsolatban, mint 2010-ben) és ez a növekedés (2014-et kivéve, amikor kismértékű csökkenés volt tapasztalható az előző évben napvilágra került sérülékenységek számához képest) folyamatosan növekszik. 2015-ben már több, mint 400 különböző ICS rendszereket érintő sérülékenység jelent meg. A FireEye kutatóinak várakozása szerint a következő években átlagos évi 5%-kal fog nőni az ICS rendszerekkel kapcsolatos sérülékenységek száma.

Az elemzésben egy szűkebb, közel 3 éves időszakot vizsgálva arra a megállapításra jutottak, hogy a sérülékenységek 58%-a a Purdue ICS architektúrában leírt második szinten működő elemeket érinti (a Purdue nagyvállalati referencia architektúra ICS rendszerekre alkalmazott változatáról itt írtam), ezen a szinten kerül meghatározásra, hogy az egyes ipari céleszközök hogyan és milyen interfészeken keresztül kommunikálnak számítógépekkel. A FireEye kutatói szerint ennek az lehet az oka, hogy a második szinten található eszközökhöz könnyebb hozzáférni és a sérülékenységeket kereső szakemberek számára sokkal ismertebbek, mint az első szinten működő ipari céleszközök.

Ami a publikált statisztikák közül szerintem a leginkább aggasztó az az, hogy az  ICS sérülékenységek átlag 33%-a gyakorlatilag publikus nulladik napi sérülékenységként lát napvilágot és többet ezek közül később sem javít a gyártó, többnyire azért, mert már nem ad támogatást az adott rendszerhez vagy eszközhöz, de volt olyan eset is (én is írtam róla), amikor az eszköz egyszerűen nem tette lehetővé a javítás telepítését, mert a codespace-ben ehhez már nincsen elég hely!

A sorozat mai részében egy Jalal Bouhdada és Erwin Paternotte előadásáról készült videót ajánlok, amiben bemutatják, hogy a vezeték nélküli szenzorok hálózati protokolljának gyenge pontjait kihasználva hogyan lehet támadást intézni egy ipari vezérlőrendszer ellen.

A WirelessHART egy vezetéknélküli szenzor hálózati protokoll, ami a HART (Highway Addressable Remote Transducer) protokollból lett kifejlesztve. A WirelessHART egy több gyártó által támogatott vezetéknélküli szabvány, amit kifejezetten az ipari hálózatok terepi/gyári eszközeihez fejlesztettek.

A kutatók legfontosabb megállapításai a következők:

- A legfontosabb titkosító kulcs, a Join Key általában a gyári alapértelmezett beállításokkal van használva a legtöbb WirelessHART-tal működő rendszeren. Ezek az alapértelmezett Join Key-ek többnyire publikusan elérhetőek a gyártói kézikönyvekben, ha pedig mégsem, akkor viszonylag egyszerűen lehet megtalálni őket az Interneten;

- Az 5 vizsgált WirelessHART gyártó összes firmware-jét ki lehetett tömöríteni JTAG használatával és így meg lehetett találni bennük a Join Key-eket, amik ugyan titkosítottak voltak, de ez nem akadályozta meg, hogy le lehessen másolni őket majd ezeket a Join Key-eket használva csatlakoztatni lehessen egy saját WirelessHART készüléket a hálózathoz.

A videó megtekinthető itt: https://youtu.be/AlEpgutwZvc

A Siemens ProductCERT bejelentése szerint Kiril Nesterov és Anatoly Katushin, a Kaspersky Lab munkatársainak segítségével több hibát is azonosítottak a SIPROTEC 4 és SIPROTEC Compact eszközökben. A hibák a SIPROTEC 4 és SIPROTEC Compact eszközöknél opcionális EN100 Ethernet modul összes, V4.29-nél korábbi verziójú firmware-ben megtalálható.

Az első hiba (CVE-2016-7112) lehetővé teszi, hogy az eszközök webes interfészén keresztül támadók megkerüljék a beépített authentikációs folyamatot és hozzáférést szerezzenek bizonyos (a bejelentésben nem részletezett) adminisztrátori funkciókhoz.

A második hiba (CVE-2016-7113) lehtővé teszi, hogy speciálisan kialakított TCP csomagokkal a sérülékeny eszközöket hibás állapotba juttassák.

A harmadik hiba (CVE-2016-7114) kihasználásával egy támadó az eszközök webes interfészén keresztül megkerülje a beépített authentikációs folyamatot és hozzáférést szerezzen bizonyos (a bejelentésben nem részletezett) adminisztrátori funkciókhoz. Ennek a hibának a kihasználásához szükséges, hogy egy legitim felhasználó be legyen jelentkezve a sérülékeny SIPROTEC eszközön.

Mindhárom hiba kihasználásához szükséges, hogy a támadó hálózaton keresztül elérje a sérülékeny eszközöket.

A Siemens a hiba által érintett SIPROTEC berendezéseket használó ügyfeleinek a mielőbb firmware-frissítést javasolja, az elérhető legfrissebb, V4.29-es verziójú firmware-ben javították a hibákat.

További részleteket a Siemens ProductCERT bejelentése tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-630413.pdf

Szerk: 2016.09.06-án az ICS-CERT is publikálta ezeket a hibákat: https://ics-cert.us-cert.gov/advisories/ICSA-16-250-01

A biztonságos ICS architektúrát leíró tanulmány 2015-ben készült és a SANS Reading Room ICS whitepaper publikációi között érhető el. Alapját az 1990-ben a Purdue egyetemen kidolgozott nagyvállalati referencia architektúra ISA-99 bizottsága által készített vezérlési hierarchia-modellje adja. A vezérlési hierarchia Purdue modellje 4 zónát és 5 szintet különböztet meg (egy gyártóvállalat példáján keresztül):

Vállalati zóna
  5. szint: Vállalat
  Ebben a zónában helyezkednek el a vállalati IT infrastruktúra elemei, a különböző IT rendszerek és alkalmazások. Ebben a zónában mindennaposnak számítanak a VPN-en keresztüli távoli elérések és az Internet használata (pl. egyes alkalmazásszerverek licenc-ellenőrzése folyamatos Internet-kapcsolatot igényel). Az ebben a zónában elhelyezkedő rendszerek számára nem ajánlott közvetlen kommunikációs lehetőséget biztosítani az ICS rendszerekkel, ehelyett célszerű egy belső DMZ-n keresztül lehetővé tenni a hozzáférést az ICS rendszerek hálózatához.
 
  4. szint: Helyszíni üzleti tervezés és logisztika
  A 4. szint nagyon gyakran az 5. szintből kerül kialakításra, itt üzemelnek azok az üzleti rendszerek, amelyek fontos belső folyamatokat támogatnak (ilyenek lehetnek többek között kapacitás-tervezésben, készlet-nyilvántartásban, stb. érintett rendszerek).
 
Gyártási zóna
  3. szint: Helyszíni gyártási műveletek és vezérlés
  Ezen a szinten üzemelnek azok a rendszerek, amik a gyártási folyamatok üzemirányításának támogatását biztosítják (pl. hálózati fájlszerverek, általános IT szolgáltatások, mint a DNS, DHCP, NTP, stb., a mérnöki munkahelyek, történeti adatokat tároló rendszerek, jelentések előállítását és ütemezéseket végző rendszerek, stb.). Az ezen a szinten üzemelő rendszerek egy DMZ-n keresztül kommunikálnak a Vállalati zóna szintjein működő rendszerekkel - a DMZ-t megkerülő direkt eléréseket célszerű kerülni.
  Továbbá a 3. szinten található rendszerek kommunikálhatnak az 1. és 0. szinten található rendszerekkel is (pl. hálózati időszinkronizálás vagy DNS névfeloldás miatt erre szükség lehet).
 
Ipari zóna
  2. szint: Ipari felügyelet és vezérlés
  A 2. szinten működő rendszerek közé olyanok tartoznak, amelyek jellemzően az 1. szinten található rendszerekkel kell kommunikálniuk (ilyenek pl. a vezérlőtermi munkaállomások), illetve amik interfészként szolgálnak az 1. szintű eszközök és a gyártási vagy vállalati zónákban található rendszerek között (pl. monitoring és riasztó rendszerek vagy HMI-k).
 
  1. szint: Alapvető vezérlés
  Ezen a szinten olyan eszközök találhatóak, amelyek feladata a folyamatvezérlés biztosítása. Ezek az eszközök fogadják és dolgozzák fel a különböző szenzoroktól érkező adatokat. Ezek az eszközök (többnyire DCS-ek, PLC-k, RTU-k) felelősek a folyamatos, szekvenciális, kötegelt és diszkrét vezérlésekért. Ezek az eszközök jellemzően gyártó-specifikus operációs rendszereket/firmware-eket futtatnak és a mérnöki munkaállomásokról lehet őket programozni és konfigurálni.
 
  0. szint: Folyamatok
  A 0. szinten üzemelnek azok a szenzorok és műszerek, amelyek az ipari folyamatok közvetlen ellenőrzését végzik. Ezeket az eszközök az 1. szinten működő rendszerek vezérlik.
 
Biztonsági (safety) zóna
  Ebben a zónában olyan rendszerek működnek, amelyek az ipari folyamatok biztonsági ellenőrzését végzik és az előre bekonfigurált határértékek elérése vagy átlépése esetén az operátor értesítése mellett beavatkozik a biztonságos állapot helyreállítása érdekében. Ezeket a rendszerek az esetek többségében teljesen izolálják minden más rendszertől.
 
A tanulmány a referencia architektúra-modellen túl részletes javaslatokat is tartalmaz, amik minden ICS rendszerek kiberbiztonságáért, üzemeltetéséért és fejlesztéséért felelős szakembernek hasznosak lehetnek. Az eredeti, angol nyelvű tanulmány a SANS Reading Roomban érhető el: https://www.sans.org/reading-room/whitepapers/ICS/secure-architecture-industrial-control-systems-36327

Kína napi szinten szerepel a különböző kiberbiztonsággal kapcsolatos hírekben (bár az utóbbi időben az orosz és amerikai, egyes feltételezések szerint állami háttérrel rendelkező csapatok jóval komolyabb figyelmet kapnak), de többnyire inkább a támadókat feltételezik kínainak és sokkal ritkábban a célpontokat azonosítják Kínában.

Ez természetesen nem jelenti azt, hogy a kínai kritikus infrastruktúra informamatikai rendszereit nem támadnák hasonló volumennel, mint az európai vagy Észak-amerikai hasonló rendszereket, legfeljebb erről ritkán vagy szinte egyáltalán nem jutnak el hírek a Nagy Kínai Tűzfal túloldaláról.

Itt a blogon már többször hivatkoztam az orosz kutatók által alapított SCADA Strangelove csapat munkáit és publikációit, legutóbbi blogbejegyzésükben egy igen érdekes, kínai fenyegetéselemzéssel kapcsolatos prezentációjukat tették elérhetővé, aminek egy része (a 19. diától) a kínai ICS rendszerek biztonságával foglalkozik.

A prezentáció itt érhető el: http://scadastrangelove.blogspot.hu/2016/08/greater-china-cyber-threat-landscape.html

Az ICS-CERT tegnapi bejelentése szerint Maxim Rupp független biztonsági kutató a Moxa OnCell termékeiben azonosított több sérülékenységet. A hibák az alábbi típusokat és szoftververziókat érintik:

- OnCell G3100V2 sorozatú eszközök, Version 2.8-nál korábbi firmware verziók esetén és
- OnCell G3111/G3151/G3211/G3251 sorozatú eszközök, Version 1.7-nél régebbi firmware verziók alkalmazása esetén.

A sérülékenységeket az egyik konfigurációs állományban szövegesen tárolt jelszavak, illetve az authentikációs folyamat nem megfelelő brute force támadások elleni védelme okozzák.

A gyártó ügyfelei számára elérhetővé tette a hibákat javító firmware verziót.

Az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedéseket 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!

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

Az ICS-CERT által kiadott publikáció szerint a Navis WebAccess nevű, szállítmányozási szektorban használt termékében talált SQL injection sérülékenységet egy bRpsd néven ismert személy és tette közzé a hibát, együtt, az azt kihasználó proof-of-concept (PoC) programkóddal együtt. A hiba a Navis WebAccess minden, 2016. augusztus 10-e előtti verziójában megtalálható.

A gyártó az augusztus 10-én kiadott verzióban javította a hibát és értesítette erről az érintett szoftvert használó ügyfeleket (szám szerint 13 ilyen ügyfelük van, ebből 5 az USA-ban).

Az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedések bevezetését javasolja:

- A sikeres SQL injection támadások hatásait csökkenteni kell a különböző adatbázis felhasználói fiókok jogosultsági szintjének a feladatvégzéshez szükséges minimumra csökkentésével;
- 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!

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

Az IT és IT biztonsági szakterületeken hosszú ideje bevett megoldás, hogy a döntések előkészítéséhez szükséges adatokat publikus forrásokból, különböző teszteken mért referenciaértékekből szerezzük. Az ICS kiberbiztonság  területén jóval nehezebb publikus adatokat találni, a mai posztban ilyen forrásokat próbálok röviden felsorolni.

NCCIC/ICS-CERT

Az első és vitathatatlanul az egyik legfontosabb a US-CERT-en belül, a DHS által működtetett ICS-CERT, aminek a publikációiból nagyon gyakran én is idézek a blogon. A különböző ICS rendszerekre vonatkozó sérülékenységeken túl jellemzően kéthavonta jelenteti meg az ICS-CERT azokat az összefoglaló riportokat, amikben átfogó(bb) képet próbálnak nyújtani az ICS kiberbiztonság helyzetéről.

SANS

A másik általam többször hivatkozott forrás a SANS, akik éves rendszerességgel készítenek felmérést az ICS kiberbiztonság állapotáról, majd ezeket egy riportban és egy webcast-on teszik elérhetővé. A legutóbbi, SANS 2016 ICS Servey itt érhető el: https://www.sans.org/reading-room/whitepapers/analyst/2016-state-ics-security-survey-37067

RISI

A RISI rövidítés a Repository of Industrial Security Incidents, vagyis az ipari biztonsági incidensek gyűjteménye kifejezést takarja, ami a 2008-tól kb. 2014-ig tartó időszakban bekövetkezett incidenseket gyűjtötte össze. A RISI nem kizárólag az ICS kiberbiztonsági incidensekre koncentrált és szándékosan előidézett események mellett a nem szándékos, véletlenül bekövetkezett incidenseket is listázták. A RISI online incidens adatbázisa még ma is kereshető, iparágra, országra és évszámra keresve egyaránt elérhetőek a múltbeli incidensek adatai. A RISI adatbázis ezen a weboldalon található: http://www.risidata.com/Database

Egyéb, IT biztonsági források

A kifejezetten ICS biztonsággal foglalkozó források mellett számos olyan publikusan elérhető anyag érhető el, ami többek között az egyre gyakoribb ICS kiberbiztonsági incidensekkel is foglalkozik, ilyen kiadványokkal időről-időre jelentkezik többek között a Verizon Enterprise, a Kaspersky, a Mandiant vagy akár a Microsoft is.

A TippingPoint-hoz tartozó ZDI tegnap publikált egy, az ABB DataManagerPro-t érintő 0-day sérülékenységet, amit egy rgod néven ismert biztonsági szakember fedezett fel.

A sérülékenységet a DataManagerPro hibás fájlszintű jogosultságkezelése okozza, ennek következtében egy authentikált felhasználó alacsony szintű jogosultságok birtokában képes lehet a rendszer binárisait tartalmazó könyvtárban olyan fájlokat lecserélni, amiket a rendszer üzemeltetése során adminisztrátori jogosultsággal kell futtatni.

A hibát a ZDI először idén januárban jelezte az ICS-CERT-nek, a gyártó június/júliusra ígérte a javítást. A ZDI végül a standard 120 napos várakozási időszak után publikálta a hibát. Tekintettel arra, hogy jelenleg az érintett rendszerekhez nincs elérhető patch, ami a hibát javítaná valamint a hiba jellegére, a sérülékenység jelentette kockázatokat csak az érintett rendszerekhez történő hozzáférések szigorítása tudja csökkenteni.

Tvoábbi információkat a ZDI bejelentése tartalmaz: http://www.zerodayinitiative.com/advisories/ZDI-16-479/

Az ipari rendszerek és kritikus infrastruktúrák biztonságával foglalkozó cikkek és blogok ritkán foglalkoznak azzal, hogy a kínai szakértők tudása és tapasztalata hol helyezkedik el ebben a témában, a legtöbb, Európában és Észak-Amerikában megjelenő publikáció jellemzően amerikai és európai szerzőtől származik, rajtuk kívül leginkább orosz szakemberek jeleskednek a témában (ilyen pl. a SCADA Strangelove csapata és Maxim Rupp, akinek különböző ICS rendszerekben felfedezett sérülékenységeiről én is rendszeresen hírt adok a blogon). Ez persze nem jelenti azt, hogy Kínában ne foglalkoznának a témával, ennek egyik jó példája a plcsan.org blog, ahol tegnap jelent meg egy 21 oldalas tanulmány a kritikus infrastruktúrákról a kibertérben gyűjteni információk témájában (elérhető PDF és HTML formátumban egyaránt).

A téma több, mint időszerű, hiszen az elmúlt években több olyan, publikusan elérhető kereső megoldás jelent meg, amelyek vagy kifejezetten az ipari rendszerekre koncentráltak (mint pl. a Shodan Search Engine) vagy a korábban elérhetőeknél nagyságrendekkel gyorsabb scannelési lehetőséget biztosítanak (pl. ZMap), amikkel már a teljes IPv4 címtér gyors átvizsgálása is lehetséges például a kritikus infrastruktúrák működésében nélkülözhetetlen eszközök utáni keresés során.

Az Interneten elérhető ipari rendszerek meglehetősen könnyen azonosíthatóak az általuk használt egyedi portok (pl. 102/tcp - Modbus, 47808/tcp, BACNet, stb.) alapján, ugyanígy az egyes gyártók szabadalmaztatott protokolljait is könnyen és gyorsan lehet az általuk használt portok alapján azonosítani. Számos olyan, Nmap NSE script érhető el publikusan, amelyek kifejezetten a különböző ICS rendszerek scannelésére készültek. Újabban egy-egy ICS sérülékenység nyilvánosságra kerülése után gyorsan (jellemzően órák alatt) jelennek meg az új sérülékenységet kereső NSE scriptek.

A tanulmány számos kínai belföldi és nemzetközi keresőszolgáltatást és kutatási projektet sorol fel, majd ezeket a keresőket és kutatási projekteket elemzi részletesen érettségi szint és egyéb szempontok alapján.