A tegnapi napon a CAREL PlantVisor Enhanced termékével kapcsolatban jelent meg egy bejelentés az ICS-CERT weboldalán. Maxim Rupp, független biztonsági tanácsadó egy authentikáció megkerülését lehetővé tevő sérülékenységet fedezett fel.

A hibát távolról is ki lehet használni és bár jelenleg még nincs információ a hibát kihasználó exploit-ról, de figyelembe véve, hogy egy, ezt a hibát kihasználó exploit elkészítése nem igényel komoly technikai tudást, a sérülékeny szoftvert használók számára a kockázatok nem elhanyagolhatóak. Tovább rontja a helyzetet, hogy a gyártó az érintett PlantVisorEnhanced termékvonalat 2007 óta már nem fejleszti, így hibajavítás sem várható ezekhez. Helyett a CAREL a PlantVisorEnhanced utódjaként megjelent PlantVisorPRO termékre történő frissítést javasolja.

Az ICS-CERT azok számára, akik valamilyen oknál fogva kénytelenek továbbra is a sérülékeny verziót használni, a szokásos tanácsokat adja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettl;
- 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.

Január 18-án a SANS ICS Security blogjában megjelent Chris Sistrunk villamosenergia-átviteli és elosztó rendszerekkel kapcsolatos biztonsági sorozatának második része (az első részről itt írtam).

Ebben a részben Chris áttekinti a lehetséges támadási vektorokat, példákat mutat be a való életből és további olvasnivalóakat javasol az villamosenergia-rendszer alállomásainak témájában.

Az ICS-CERT tegnapi bejelentése szerint Aditya Sood, független biztonsági kutató XSS sérülékenységet talált a Siemens OZW672-es és 772-es típusú eszközeiben. A sérülékenység minden, v6.00 és korábbi verziójú szoftvert futtató eszközt érinti, a hiba kihasználásával egy támadó adatokat és beállításokat változtathat meg a sérülékeny eszközökön.

A Siemens mindkét terméktípushoz elérhetővé tette a hibát javító új firmware verziót. Azoknak a felhasználóknak, akik valamilyen ok miatt nem tudják frissíteni a firmware-t, az ICS-CERT az alábbi kompenzáló kontrollokat javasolja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettl;
- 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!

Az elmúlt héten számos olyan cikk jelent meg, amelyek egy-egy, jellemzően a nemzeti kritikus infrastruktúrák közé sorolt iparág kiberbiztonsági helyzetét vizsgálja. A mai posztban ezekből a cikkekből fogok szemlézni.

Atomenergia-szektor

Több helyen jelent meg cikk azzal a Nuclear Threat Initiative (NTI) által 2013-ban készített és ez év elején aktualizált tanulmánnyal kapcsolatban, ami 47 országban üzemelő atomerőművek kiberbiztonsági állapotát mérte fel.

A felmérés szerint a nukleáris létesítmények informatikai hálózataiban történt kiberbiztonsági incidensek száma az átlagos (kormányzati szervezeteknél regisztrált incidensek) 9,7%-os emelkedésével szemben 18% növekedést mutatott. A vizsgált 47 országból 24 olyan volt, amelyekben akár atomfegyverekhez használható hasadóanyagot is elő lehet állítani, a másik 23 ország atomerőművei pedig csak békés célú felhasználásra alkalmas létesítmények.

A 2013-as vizsgált 47 országból mindössze 13 ország (köztük Magyarország is, ezúton szeretnék gratulálni a paski és csillebérci reaktorok környékén dolgozó biztonsági szakembereknek) ért el tökéletes eredményt, azonban 20 ország eredménye lett nulla pontos (köztük számomra meglepő módon Belgium, Olaszország, Szlovákia és Spanyolország is!). Ezek közül az országok közül az elmúlt két évben 8 jelentős javulást ért el a kiberbiztonság területén.

Villamosenergia-ipar

Szintén több, IT biztonsággal foglalkozó híroldal hozta le az ICS-CERT-nél dolgozó Marty Edwards S4 konferencián tartott előadásának összefoglalóját, amiben arról beszélt, hogy a kritikus infrastruktúráknál dolgozó informatikusok és vezetők nagyon gyakran kapcsolják össze az ICS hálózatokat a vállalati hálózatokkal, időnként az Internettel is, mert úgy gondolják, hogy ezzel üzleti/technológiai előnyökre tehetnek szert, azonban az ezzel járó kockázatokkal már nem foglalkoznak.

Kőolaj- és földgáz-szektor

Ugyancsak múlt heti a hír, hogy a Tripwire felmérése szerint jelentősen (82% felett) nőtt az olaj és gázipari cégek hálózataiban történt kiberbiztonsági incidensek száma. Ami igazán aggasztó a felmérésben, hogy a válaszadók 69%-a szerint a vállalatok nincsenek megfelelően felkészülve egy esetleges kibertámadás észlelésére (arra nem tér ki a felmérés, hogy akik észlelni tudják, azoknál vajon megvan-e a képesség az észlelt támadások elhárítására).

Egy másik érdekesség a felmérésben, hogy a válaszadók szerint az ICS hálózatok és a vállalati, Internet-kapcsolattal rendelkező hálózatok az esetek többségében nincsenek összekapcsolva egymással, így egy támadás során annak a kockázata, hogy a támadók képesek eljutni az ICS rendszerekig, meglehetősen kicsi (ez mondjuk az elmúlt évek során a legkülönbözőbb ICS biztonsági körökben általam hallottaknak ellentmond, én sokkal gyakrabban hallottam mostanáig azt, hogy különböző okok miatt, pl. jogszabályi, üzleti, technológiai okok miatt, bár nem akarták, mégis össze kellett kapcsolniuk az ICS és vállalati hálózatokat).

Most mondhatja bárki azt, hogy ezekben a cikkekben nincs semmi újdonság (vagy legalábbis nem sok) azok számára, akik figyelemmel követik az ICS biztonság témáját, de annyit biztos, hogy amint egyre többet fogunk tudni a Nyugat-ukrajnai áramkimaradás hátteréről, a különböző ICS rendszereket üzemeltető vállalatoknak újra kell értékelniük az ezekkel a rendszerekkel kapcsolatos kockázataikat. Ezt persze már a Stuxnet nyilvánosságra kerülése után is meg kellett volna tenni, de a kritikus infrastruktúrákat üzemeltetők, legyünk őszinték, nagyon kevés kivételtől eltekintve) elpazarolták az elmúlt 5 évet.

2016.01.14-én az ICS-CERT számos, az Advantech WebAccess 8.0 és azt megelőző verzióit érintő sérülékenységet hozott nyilvánosságra. Az Advantech érintett termékcsaládja egy webes ICS/SCADA rendszer HMI modullal.  A sérülékenységek meglehetősen széles skálán mozognak:

- Jogosulatlan memória-hozzáférés;
- Korlátozás és hitelesítés nélküli fájlfeltöltés;
- Jogosulatlan könyvtár-hozzáférés;
- Különböző stack- és heap-based puffer-túlcsordulások;
- Nem megfelelő hozzáférés-vezérlés;
- Nem megfelelő bevitt adat-ellenőrzés;
- Cross-site scripting;
- SQL injection;
- Cross-site request forgery;
- Bizalmas adatok olvasható szöveges formában tárolása;
- Távoli kódfuttatás böngészú plug-in alkalmazásával.

A gyártó a hibákat a WebAccess 8.1-es verzióban javította, ami elérhető a vállalat weboldalán keresztül. Az ICS-CERT a frissítés telepítése mellett tanácsokkal szolgál a sérülékenységek jelentette kockázatok csökkentése érdekében:

Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettl;
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!

Az ICS-CERT tanácsai sokaknak maguktól értetődőek lehetnek (legalábbis erősen remélem, hogy ezek a legtöbb informatikus számára nem jelentenek újdonságot), mégis az, hogy az ICS-CERT egy teljesen átlagos (bár az egy szoftverrel kapcsolatban bejelentett hibák száma ebben az esetben nem mindennapos) esetben ezeket az intézkedéseket javasolja, jól mutatja, hogy mlyen alapvető biztonsági problémák vannak nagyon sok ipari rendszerben/hálózatban.

A SANS ICS Security Blog-ját az ukrán áramszolgáltatók elleni kibertámadás kapcsán már hivatkoztam itt a blogon, múlt héten pénteken pedig  Chris Sistrunk tollából egy két részes blogbejegyzés első része jelent meg, ahol a villamosenergia-szektor elleni kibertámadásokkal foglalkoznak részletesen.

Chris a Mandiant tanácsadója, a kritikus infrastruktúrák kiberbiztonsági kérdéseire, elsősorban ICS/SCADA biztonságra specializálódott. Korábban 11 évig volt mérnök az Entergy-nél, azt megelőzően pedig átviteli és villamosenergia-elosztó rendszereket vezérlő ICS/SCADA rendszerek szakértőjeként dolgozott.

A blogbejegyzés első részében egy rövid villamosenergia-ipari történeti áttekintés után az alállomásokon használt eszközöket, azok védelmét, felügyeletét és vezérlését mutatja be, majd zárásként a Smart Grid-ről is hosszabban ír.

A blogbejegyzést ajánlom minden olyan IT biztonsággal foglalkozó szakember figyelmébe, akiket érdekel az ICS biztonság, de nagyon hasznos lehet az ICS/SCADA üzemeltetésben dolgozóknak is, mert az Ő aktív részvételük nélkül nem lehet hatékony védelmet biztosítani ezeknek a rendszereknek.

2013-ban az USA Szövetségi Energetikai Szabályozó Bizottsága (Federal Energy Regulatory Commission, FERC) egy tanulmányában arra a következtetésre jutott, hogy 9 alállomás elleni támadással az Egyesült Államok területének jelentős részén lehet áramkimaradásokat okozni.

Ebből a tanulmányból kiindulva, hasonlóan a Digital Pearl Harbor, illetve az annak nyomán Dr. Kovács Lajos alezredes és Dr. Krasznay Csaba által készített Digitális Mohács kutatásokhoz, az iSight kutatócsoportja azt vizsgálta, hogy egy kis terrorista csoport képes lenne-e csak publikusan elérhető információkra építve azonosítani a 9 kulcsfontosságú alállomást, amelyeket ezek után már érdemes (fizikai eszközökkel vagy a kibertéren keresztül vagy akár a kettő kombinálásával) támadni annak érdekében, hogy egy jelentős áramkimaradást idézzenek elő?

A kutatás során, aminek a Gridstrike nevet adták, publikusan elérhető adatokat kerestek az átviteli rendszer alállomásairól, térképeket, a Google Earth adatait és az átviteli hálózat túlterhelődéséről szóló dokumentációkat használtak fel és ezeket vetették össze a 10 legnagyobb amerikai várost kiszolgáló alállomások adataival. Végül képesek voltak beazonosítani 15 alállomást, amelyek az amerikai villamosenergia-rendszer gerincét alkotják - ezek kiiktatásával állításuk szerint országos áramszünetet lehetne előidézni.

A Gridstrike részleteiről a kutatók a Miami-ban holnap kezdődő S4x16 ICS biztonsági konferencián fognak beszámolni, részben ennek felvezetéseként nyilatkoztak a Darkreading.com kiberbiztonsági híroldalnak . Abban biztos vagyok, hogy ennek a kutatásnak még komoly visszhangja lesz, ha máshol nem is, de az ICS kiberbiztonsággal foglalkozó szakemberek között biztosan - különösen most, hogy alig több, mint két hete minden szakmabelit a karácsony előtti, ukrajnai áramszünet kiberbiztonsági kérdései és az incidens lehetséges utóélete foglalkoztat.

A SANS ICS blogján a szervezet szakterület igazgatójának írása foglalja össze a legújabb fejleményeket a 2015. december 23-i, ukrán áramszolgáltatók elleni kibertámadással kapcsolatos vizsgálatról. A SANS vizsgálatát az érintett áramszolgáltatóktól kapott információk is segítik, ezek alapján egyre nagyobb biztonsággal állítják, hogy a támadás egy jól szervezett, szándékosan előidézett incidens volt (az ICS rendszerek esetén egyáltalán nem számít ritkának a véletlenül előidézett incidens, de ebben az esetben a vizsgálat során eddig gyűjtött információk egyértelműen a szándékosságot támasztják alá).

A támadók nem csak magas szintű szervezési és koordinációs képességekkel rendelkeztek, de képesek voltak malware-ekkel és feltételezhetően közvetlen távoli hozzáféréssel lehetetlenné tenni, hogy a megtámadott áramszolgáltatók diszpécserei irányításuk alatt tudják tartani a villamosenergia-rendszert. Az áramszolgáltatóktól származó információk alapján egyre pontosabban lehet látni a támadások idővonalát. Ezek alapján a Kyivoblenergo rendszerében 2015 december 23-án 15:35 és 16:30 között hajtottak végre sikeres támadást a 35-110 kV-os rendszert vezérlő alállomási SCADA-rendszer ellen. Miután előidézték az áramszünetet, a KillDisk modullal használhatatlanná tették a vezérlő rendszert, ezzel is tovább növelve a támadás utáni helyreálláshoz szükséges időt és növelve az áramszünet időtartamát - a Kyivoblenergo munkatársai elismerésre méltó gyorsasággal váltottak manuális vezérlésre, de az áramszolgáltatás ennek ellenére csak helyi idő szerint 18:56-ra állt helyre mindenhol. A számítógépes rendszerek elleni támadással egyidőben DDoS-támadást indítottak az áramszolgáltatók weboldalai és call centerei ellen, így nehezítve az ügyfelek számára a hibabejelentéseket és megosztva a támadás elhárításán dolgozó szakemberek figyelmét.

További részletek a SANS ICS blogján olvashatóak.

A mai posztban folytatom a múlt héten elkezdett gondolatot az ICS rendszerek általános biztonsági problémáiról.

Üzemeltetés kontra biztonság

ICS rendszerek esetén a klasszikus CIA-modell nagyon jelentősen el tud és el is szokott tolódni a rendelkezésre állás felé. Ez nem csoda, hiszen a ICS rendszerek jellemzően olyan kritikus infrastruktúra-elemek központi folyamatvezérléséért felelnek, amelyek esetében nem engedhető meg a legkisebb üzemzavar vagy szolgáltatás-kiesés sem, sőt, nagyon gyakran egy ilyen, üzembiztonsági incidens akár személyi sérüléshez is vezethet. Mindezekt végiggondolva belátható, hogy a ICS rendszerek esetén a rendelkezésre állás valóban kiemelt fontosságú szempont és ezért van az, hogy a ICS rendszerek üzemeltetőit hosszú évtizedek óta úgy képezik, hogy a rendelkezésre állási mutatók az egyik (ha nem a) legfontosabb mutatószáma legyen a rendszereik működésének értékelése során.

Azonban pont emiatt az üzemeltetők jellemzően újabb akadályát jelentik a ICS rendszerek biztonságosabbá tételének. A legtöbb ICS rendszer üzemeltető a fentiekben leírtak miatt mind a mai napig csak és kizárólag a rendszerek rendelkezésre állására  koncentrál és ezt szem előtt tartva az esetek igen jelentős hányadában elvetik a hibajavítások telepítésének és az éppen éles konfiguráció módosításának a lehetőségét is. Még rosszabb a helyzet amiatt, hogy a ICS rendszert üzemeltetők többsége meggyőződéssel vallja, hogy az általa üzemeltetett rendszer már azért sem lehet célpontja sikeres támadásnak, mert csak az ért hozzá, akinek ez feladata, akinek pedig nincs dolga az adott ICS rendszerrel, annak esélye sincs átlátni és megérteni a működését, így pedig nem képes sikeres támadást indítani ellene (ezzel a tévhittel kapcsolatban mindenkinek szeretettel ajánlom Marina Krotofil előadásait).

Ugyanez a tévhit az oka egy másik biztonsági hiányosságnak. A legtöbb ICS rendszer esetén a hálózatbiztonság, a határvédelem és a végponti védelem nincs olyan szinten, mint az átlagos vállalati hálózatok és rendszerek esetén. Többnyire azzal érvelnek a ICS rendszereket üzemeltető informatikusok, hogy nincs szükség ilyen eszközökre és intézkedésekre, hiszen a ICS rendszerek nincsenek összekapcsolva semmilyen más rendszerrel vagy hálózattal. Ez a tévhit még abból az időből ered, amikor a vállalati informatika gyerekcipőben járt, azonban mióta az IT az élet és a vállalati mindennapok elválaszthatatlan része lett, üzleti vagy technológiai okok miatt szinte minden ICS rendszernek van valamilyen szintű kapcsolata az egyéb, vállalaton belüli informatikai rendszerekkel. Ilyen formán pedig ezek a rendszerek igenis támadhatóvá válnak pl. az Internet vagy a vállalat irodai WiFi hálózata felől.

Fejlesztés kontra biztonság

Azok számára, akik IT biztonsággal foglalkoznak, nem újdonság, hogy a fejlesztők jellemzően nem a biztonság szem előtt tartásával készítik a különböző szoftvereket. Ennek számos oka lehet, az érdektelenségtől az időhiányon át a hozzá nem értésig és ez alól nem jelentenek kivételt a ICS rendszerek sem. A ICS fejlesztők (hasonlóan az üzemeltetőkhöz) hosszú ideig abban a tévhitben éltek, hogy nem szükséges biztonságos protokollokat alkalmazva biztonságra törekedniük a fejlesztés során, hiszen a rendszer működését úgyis csak azok értik, akiknek érteniük kell és egyébként sem fér hozzá senki illetéktelen az általuk írt kódot futtató rendszerekhez. Ehhez társult még az a probléma, hogy (jellemzően költséghatékonysági okokból) a ICS fejlesztők egyre gyakrabban használnak különböző széles körben ismert és használt megoldásokat, amiknek a hibái is széles körben ismertté válnak, szinte azonnal (ilyenek voltak többek között a Heartbleed és a Shellshock néven elhíresült sérülékenységek, amik bizony számos ICS rendszert is érintettek).

A ICS-felhasználók jelentette biztonsági probléma

Minden informatikai rendszer esetén a felhasználó jelenti az egyik legkomolyabb biztonsági kockázatot, nincs ez másként a ICS rendszerek esetén sem. A legtöbb ICS rendszer esetén a felhasználó informatikai és informatikai biztonsági tudása és képességei nem haladják meg az átlag felhasználó szintjét. Feladataikhoz ez többnyire nem is szükséges, az adott ICS rendszert a feladataik elvégzéséhez szükséges mértékben ismerik, azonban pont ez vezethet ahhoz, hogy rajtuk keresztül könnyen lehet kompromittálni az adott rendszert (ez történt a Stuxnet esetében is).

Joe Weiss ma megjelent blogposztjában részletesen áttekinti a december 23-i, nyugat-ukrajnai áramszünetet okozó kibertámadáshoz használt Blackenergy malware-ről eddig megtudott részleteket. Meglehetősen nyugtalanító megállapításai vannak azzal kapcsolatban, hogy a Blackenergy nyomait az USA villamosenergia-rendszereiben is több helyen beazonosították és felteszi a kérdést, hogy ha a decemberi ukrajnai támadás valójában üzenet volt a támadók részéről ("Látjátok, bármikor képesek vagyunk kiütni a kritikus rendszereiteket?"), akkor vajon kinek vagy kiknek szánták a figyelmeztetést?
 
 Amit egyelőre nem tudunk, az az, hogy pontosan hogyan okoztak áramkimaradást a támadók? A Blackenergy, a KillDisk és más malware-ek, amik az elmúlt években többek között a villamosenergia-rendszert vették célba (pl. a Havex.A) jellemzően információgyűjtésre és/vagy rombolásra specializálódtak, nem pedig arra, hogy módosítsák a kritikus infrastruktúrák működését. Felmerül a kérdés, hogy vajon a támadók már évek óta hozzáférnek a kritikus infrastruktúrákat vezérlő ICS rendszerekhez és az eltelt időt arra használták, hogy tanuljanak és tapasztalatokat szerezzenek a rendszerek működési sajátosságairól (ahogyan erről a tavalyi Hacktivity-n Marina Krotofil kiváló előadást tartott)?

A helyzet annyiban még rosszabb, hogy bár vannak olyan szabványok (többek között a NERC CIP, ezekről valamikor majd részletesebb áttekintést tervezek), amik pont a kritikus infrastruktúrák biztonságának fejlesztésére fókuszálnak, sajnos az ezeknek való megfelelés gyakorlatilag nem jelent semmit. Ahogy Joe is megemlíti a blogbejegyzésben, a tavaly októberi ICS Cyber Security konferencián volt egy előadás, ahol a Washington állami Nemzeti Gárda és a Snohomish Public Utility Department mutatta be azokat a tapasztalatokat, amiket a közösen végrehajtott penetration teszt során gyűjtöttek. Nos, NERC CIP-nek minden szempontból megfelelő közműszolgáltató rendszerébe a Nemzeti Gárda kiberbiztonsági szakemberei kevesebb, mint 30 perc alatt törtek be...

A jelek szerint szembe kell néznünk azzal a ténnyel, hogy a Stuxnet nyilvánosságra kerülése óta eltelt időben a kritikus infrastruktúrákat kiszolgáló informatikai rendszereket üzemeltetők és azok biztonságáért felelős emberek és szervezetek nem tudtak felnőni az új helyzet jelentette kihívásokhoz. Sem az USA-ban, sem Európában nem jól használták fel az eltelt több, mint 5 évet. Tartok tőle, hogy a jövőben több hasonló esetre lehet számítani, mielőtt a felelős (állami) döntéshozók végre érdemi lépéseket tennének a helyzet javítására.