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.

A december 30-án napvilágot látott, ukrán villamosenergia-rendszer elleni kibertámadással kapcsolatos legújabb fejlemény, hogy Robert M. Lee, a SANS ICS biztonsági képzéseinek oktatója blogjában megjelent írása alapján a SANS szerzett egy mintát az ukrán áramszolgáltatók elleni támadáshoz használt malware-ből. Robert egy hosszabb blogposztban veszi sorra a tényeket, feltételezéseket és következtetéseket, illetve egy nagyon rövid, statikus elemzést is közread a malware-ről.

Az első vizsgálatok alapján a malware egy 32 bites Windows program és feltételezik, hogy egy komplex malware egyik modulja lehet. A SANS munkatársai a kapott minta elemzésébe több, különböző helyen dolgozó szakembert vontak be, így valószínű, hogy rövidesen részletes elemzések fognak megjelenni a témában.

További részletekért érdemes figyelemmel kísérni a SANS ICS blogját.

Ebben a posztban a ICS rendszerek biztonsági problémáinak általános áttekintését kezdem el. A tervek szerint ez egy több részes sorozat lesz - ebből is látható, hogy a ICS rendszerekkel bőven van probléma.

Protokollok biztonsági problémái

Ahogy a korábbi három posztban ismertetett, ICS rendszerekben használt protokolloknál lehet látni, ezek rendszerek gyakran évtizedekkel ezelőtt kidolgozott protokollokat használnak a mindennapi működésük során. Ezeknek a protokolloknak egy jelentős hányadát (elsősorban a ICS-specifikus protokollokat) jellemzően nem nyílt hálózatokon történő használatra tervezték, ezért ezek szinte soha nem tartalmaznak biztonsági funkciókat. Például a Modbus és a Modbus/TCP protokollok nem ismerik a felhasználónév/jelszó vagy bármilyen más authentikációs forma használatát a ICS szerver és a PLC/RTU közötti kommunikáció során, vagyis ha valaki kommunikálni tud egy Modbus szerverrel vagy klienssel és ismeri a megfelelő parancsokat, akkor irányítani is tudja az adott eszközt. Ez a legtöbb, hasonló korú ICS protokoll esetén sincs másként. Ez a probléma később még vissza fog térni néhányszor, nemzetközi ICS-biztonsági körökben a ICS rendszerek egyik fő ismérve, hogy nincs semmilyen authentikáció.

Jelszóproblémák

Ahogy a protokolloknál már érintettük, a ICS rendszerek egyik gyenge pontja az authentikáció (ami gyakran teljesen hiányzik a rendszerből), még akkor is, ha maga az authentikáció lehetőség adott. Nem ritka, hogy egyes (jellemzően távoli eszközökön, RTU-kon, PLC-ken) egy adott felhasználóhoz (akár root/adminisztrátor felhasználói fiókhoz is!) nincs jelszó beállítva, ha pedig van az adott fióknak jelszava, akkor az jellemzően könnyen kitalálható/törhető. Ha pedig ritka kivételként az üzemeltetők jó jelszót adtak meg, a legtöbb ICS rendszer esetén azt is pillanatok alatt meg lehet szerezni, hiszen ahogy a protokollokat tárgyaló korábbi részekből látni lehet, a ICS rendszerek elvétve használnak titkosított protokollokat, így az összes jelszó plain text formában utazik a hálózaton.

A ICS rendszerek életciklusa

Aki informatikai területen dolgozik (legyen akár üzemeltető, akár fejlesztő vagy bármilyen más terület szakértője), biztosan találkozott már az SDLC rövidítéssel, ami a szoftver-/rendszerfejlesztési életciklust jelöli. ICS rendszerek esetén az SDLC egy ciklusa sokkal nagyobb időtávot, gyakran évtizedeket ölel fel, szemben az általános informatikai gyakorlattal, ami napjainkra egyre gyorsuló ciklusokkal dolgozik (elég csak megnézni a népszerű böngészőprogramok vagy Linux-disztribúciók kiadási ütemét).
Egy ICS rendszer teljes életciklusa akár 20-30 év is lehet, ez azonban azt jelenti, hogy míg egy tervezési hibát egy átlagos szoftver vagy rendszer esetén a következő verzióban viszonylag gyorsan (akár napokon belül) lehet javítani. Ugyanez egy ICS rendszernél jobb esetben is hónapokat, rosszabb esetben akár éveket is igénybe vehet és eközben a rendszert napi szinten, gyakran 7/24-es üzemben kell használni olyan környezetben, ahol egy ismert hibát kihasználva a támadók jelentős anyagi károkat okozhatnak vagy akár emberéleteket veszélyeztethetnek.

Sajnálatos módon nagyon sokáig ez igaz volt a ICS rendszerek komponenseiben talált hibák javítására is. A Stuxnet előtt csak elvétve telepítették a ICS rendszerekre azokat az operációs rendszereket és adatbázisokat érintő hibajavításokat, amik minden más rendszer esetén az üzemeltetői rutin részeként kezelnek már több, mint egy évtizede. A Stuxnet okozta megrázkódtatás után egyes ICS rendzsereket fejlesztő cégek változtattak a korábbi hozzáállásukon és ma már készek (egy, más rendszerekéhez képes lassúnak és konzervatívnak tűnú) patch-menedzsment eljárást nyújtani a ICS üzemeltetőknek. Ennek ellenére mind a mai napig a ICS rendszerek rendszeres patch-elése nem elterjedt gyakorlat, volt olyan, ICS-rendszeren végzet penteszt, ahol 10 éves, javítatlan Solaris hibát találtak a biztonsági szakemberek.

A tegnapi napon számos szakmai híroldalon jelent meg az Ukrán Biztonsági Szolgálat (Security Service of Ukraine, SBU) által megfogalmazott vád, hogy a karácsony esti, egyes nyugat-ukrajnai területeket érintő áramkimaradásokat az orosz különleges szolgálatok által végrehajtott kibertámadások okozták.
 
Egyelőre nem lehet tudni, hogy az ukrán szolgálatok azon állítását, hogy az áramkimaradásokat egy kibertámadás okozta, alá lehet-e támasztani bizonyítékokkal, de vannak, akik összefüggést látnak a tavaly nyáron nyilvánosságra került, szintén orosz hacker-csoportoknak tulajdonított, európai energia-szektort célzó, Dragonfly néven ismertté vált kiberkémkedési eset és a mostani ukrajnai események között.

Update: Az ESET blogján megjelent cikk szerint az ukrán áramszolgáltatókat támadó malware egyértelműen a korábban többször látott Blackenergy malware-hez kapcsolható.

A tegnap posztban  említett SCADA Strangelove kutatócsapat tagjai a 32C3-on tartott előadásukban a vasúti közlekedésben használt ipari rendszerek biztonságával kapcsolatos vizsgálataik eredményeiről számoltak be.
 
A modern vasúti közlekedés számos ponton épít a digitális rendszerekre, sok más egyéb mellett ilyen rendszerek vezérlik a vonatok különböző funkcióit (sok egyéb mellett utastér jelzőberendezéseit, a vonatok irányító rendszereit és az utastájékoztató rendszert is). Számítógépekkel történik a vasúti pályán és az állomásokon használt biztosító berendezések (computer-based interlocking, CBI) vezérlése, a központi forgalomirányítás és a vasúti átjárók vezérlése, valamint a váltókat is ilyen rendszerek felügyelik és irányítják, de a mozdonyokról sem hiányzik a digitális technológia (egy modern mozdony, pl. egy Trax teljes újraindítása akár 5 percig is tarthat!).

A SCADA Strangelove kutatói az elmúlt három évben az ENISA-val és több, meg nem nevezett vasúttársasággal dolgoztak együtt a vasúti közlekedésben használt rendszerek biztonsági vizsgálata során és számos hibát fedeztek fel a biztosítóberendezésekben és vonatvezérlő rendszerekben. Tapasztalataik szerint ezekbe a rendszerekbe nem nehéz betörni, azonban a feladat az egyedi vasútautomatizálási rendszerek ismeretét és egy, a támadók rendelkezésére álló tesztkörnyezet meglétét igényli.

Bár a kutatók szerint a vasúti rendszerek publikusan nem elérhetőek, azért érdekes lenne látni egy statisztikát arról, hogy hány vasúti irányítórendszer van összekötve a vállalati hálózattal, aminek egyes elemei már elérhetőek az Internet irányából?

A C3-on elhangzott előadás prezentációja elérhető a Slideshare-en, további részletek pedig a különböző szakmai oldalak összefoglalóiban találhatóak.

A SCADA Strangelove egy független orosz biztonsági kutatókból álló csapat, akik ICS rendszerek és egyéb ipari környzetekben használt informatikai eszközök biztonságával foglalkozik. Az idei, 32. C3-ra (Chaos Communication Congress) időzítve december 27-én tették közzé a github-on egy listát 112 ICS rendszer/ipari eszköz gyári beégetett felhasználóneveivel és jelszavaival.

A listán 35 gyártó száznál is több terméke szerepel és a jelszavakat nézve az embernek az az érzése támad, mintha ezek a gyártók az évente publikált 20 legrosszabb jelszó listájáról választanák az eszközeikben a gyári felhasználók jelszavait.

Aki szeretne egy közelebbi pillantást vetni a gyűjteményre, itt találja a feltöltött fájlokat: https://github.com/scadastrangelove/SCADAPASS

Természetesen ha valaki talál olyan eszközt a sajátjai között, ami szerepel a listán, nagyon ajánlott minél előbb jelszót cserélni, ahol ez lehetséges - egyáltalán nem fogok meglepődni, ha a következő napokban-hetekben megszaporodnak azok a támadások kísérletek, ahol ezeket az adatokat próbálják meg majd felhasználni.

A nap másik komoly híre: nyugodj békében, Lemmy!

A mai napon egy új blogposzt-típust indítok útjára, más, ICS kiberbiztonsági témákkal foglalkozó blogokról fogok posztokat ajánlani. Az első ilyen az Unfettered blog, a sorszám oka pedig az, hogy várakozásaim szerint ezt a blogot még sokszor fogom hivatkozni.

Az Unfettered blog a www.controlglobal.com közösségen belül működő blogok egyike (a szerzők között többek között a magyar származású Lipták Béla is megtalálható), amit Joseph M. Weiss, az ICS kiberbiztonsági téma egyik legismertebb alakja ír. Joe, akit van szerencsém személyesen ismerni, lelkes kutatója az ICS biztonság kiberbiztonsági vonalának és elismert tagja az ICS biztonsági szakértők szűk körének.

Legújabb blogposztjában az amerikai Haditengerészeti Posztgraduális Iskola Belbiztonsági Központjának (Naval PostGraduate School Center for Homeland Defense and Security) újságjában megjelent cikkét vizsgálja és ad hangot annak a véleményének , hogy a cikkben olvasható megállapítások számos területen nem értékelik megfelelően az ICS rendszerek kiberbiztonsági incidenseinek (legyenek azok szándékos támadások vagy véletlen hibákból bekövetkező események) hatásait.

A teljes poszt, benne Joe saját adatainak és az NPS cikkének összehasonlítása itt olvasható.

A Siemens december 22-én jelentette az ICS-CERT felé, hogy a RuggedCom ROX-alapú eszközei közül a ROX I. firmware minden verziója és a ROX II. firmware-sorozat 2.9.0 előtti összes verziója több (a mostani bejelentés alapján 4), az NTP daemon-hoz kapcsolódó, távolról is kihasználható sérülékenységet tartalmaz.

Az első sérülékenységet kihasználva authentikáció nélkül lehet az eszközökön frissíteni az idő-beállításokat, a másik három sérülékenység pedig a bevitt adatok nem megfelelő ellenőrzéséből adódik.

A ROX II-alapú eszközökhöz a gyártó elérhetővé tette a hibákat javító új firmware-verziót. Azok számára, akik sérülékeny firmware-t használnak, több, a kockázatokat csökkentő intézkedést javasol a Siemens:

- A tűzfalakon javasolt blokkolni az ismeretlen forrásból származó NTP-csomagokat;
- NTP időszinkronizálást csak megbízható hálózaton javasolt alkalmazni;
- Javasolt az NTP funkciót kikapcsolni, ha nem létkérdés az alkalmazása;
- Javasolt az NTP konfigurációs fájlban beállítani a "noquery" flag-et a nem helyi eszközök esetén;
- Javasolt beállítani az NTP-authentikációt és az NTP konfigurációs fájlban beállítani a "notrust" flag-et a nem helyi eszközök esetén (ez utóbbit csak a ROX II-sorozatú eszközökön lehet megtenni).

Az ICS-CERT bejelentése teljes terjedelmében itt olvasható.

A mai posztban olyan, ICS rendszerekben is használt protkollokról lesz szó, amik széles körben ismertek. Ezeket a protokollokat a modern informatikai rendszerekben már többnyire nem használják, azonban a ICS rendszerben még mindig széles körben használatban vannak. Bár ezeket a protokollokat a legtöbb informatikus jól ismeri, a teljesség kedvéért röviden (itt-ott akár csak távirati stílusban) ezeket is áttekintem.

FTP

Az FTP (File Transfer Protocol) egy szabványos hálózati protokoll, amelyet TCP-alapú hálózatokban fájlok egyik számítógépről a másikra mozgatására szoktak használni.

Az FTP protokoll kliens-szerver architektúrára épül és elkülönülnek benne a kapcsolatvezérlő és adatkapcsolati funkciók. Az protokollban a felhasználóknak (klienseknek) egy clear-text authentikációs protokollal kell azonosítaniuk magunkat, de ha a szerver konfigurációja engedi, az anonim bejelentkezésre is van lehetőség. Az FTP protokoll biztonságosabb tételéhez, a felhasználói azonosítók és jelszavak, valamint a adattartalom titkosításához jellemzően SSL/TLS-t szoktak használni (az FTP-nek ezt a változatát ismerik FTPS-ként), illetve időnként SSH-t is, ekkor SFTP-ről beszélünk.

TFTP

A TFTP (Trivial File Transfer Protocol) egy egyszerű FTP protokoll, ami lehetővé teszi a kliensek számára, hogy fájlokat másoljanak fel és töltsenek szerverekről. A TFTP egyik elsődleges felhasználási formája a hálózatban kötött számítógépek LAN-ról történő boot-olásának biztosítása. A TFTP használatának egyik fő oka az egyszerű használat. A TFTP biztonsági szempontból gyenge protokollnak számít, az parancsok, adatok és a felhasználói authentikáció adatai is titkosítatlanul kerülnek továbbításra a hálózaton. Hiányoznak belőle azok a fejlett funkciók is, amik a jobb FTP protokollok sajátja. Mindezekkel együtt sok (főleg régebbi rendszerben és jellemzően régebbi (hálózati) eszközök firmware-jében még sok helyen ma is használatban van.

A TFTP-t először 1981-ben szabványosították, a protokoll jelenlegi specifikációját az RFC 1350-ben található.

rsh

Az rsh (remote shell) egy parancssori program, amivel shell parancsokat lehet végrehajtani a hálózaton található számítógépeken egy másik felhasználó nevében. A távoli rendszer, amihez az rsh csatlakozik, futtatja az rsh daemon-t (rshd). Az rsh daemon jellemzően az 514/tcp porton fut. Az rsh használata során a kiadott parancsok, valamint a felhasználói azonosítók és jelszavak titkosítatlanul kerülnek továbbításra a hálózaton.

Az rsh eredetileg a BSD Unix operációs rendszer 4.2-es verziójában jelent meg először, 1983-ban, együtt az rcp-vel, az rlogin csomagjában.

Az rsh-nak egyezik a neve egy másik gyakran használt UNIX paranccsal, a restricted shell-lel, ami először a PWB/UNIX-ban, a System V Release 4-ben jelent meg. A restricted shell általában a /usr/bin/rsh útvonalon található.

rlogin

Az rlogin egyszerre a szoftver és a szoftver által használt alkalmazás rétegbeli protokoll neve. Az authentikált felhasználók úgy tudnak dolgozni, mintha fizikailag is a távoli számítógép előtt ülnének. Az rlogin-t az RFC 1282 definiálták. Az rlogin az rlogind daemon-nal kommunikál a távoli számítógépen és a felhasználói authentikáció adatai ennél a protokollnál is clear text formában utaznak a hálózaton. Az rlogin hasonlít a telnet parancshoz, de ahhoz képest rendelkezik azzal hátránnyal, hogy nem testre szabható és csak Unix szerverekhez lehet csatlakozni vele.

rexec

Az rexec (remote execute) hasonló funkcionalitással rendelkezik, mint az rsh - más számítógépeken tesz lehetővé távoli parancsvégrehajtást.

telnet

A Telnet egy, az OSI modell együttműködési (session) rétegében működő protokoll, ami az Interneten és helyi hálózatokon biztosít kétirányú, interaktív, szöveges kommunikációs lehetőséget. A Telnet protokoll három fő alapelvre épül, az első a hálózati virtuális terminálok koncepciója, a második a "tárgyalásos lehetőségek" elve, a harmadik pedig a terminálok és folyamatok szimmetrikus nézete.

A Telnet mind a mai napig széles körben használt protokoll, azonban nem felel meg a modern biztonsági elvárásoknak.

A most bemutatott, általánosan használt protokollokon túl természetesen számos más protokollt is használnak ICS rendszerekben, ezzel a rövid bemutatással inkább azokra a protokollokra próbáltunk koncentrálni, amelyek gyakran előfordulnak és biztonsági szempontból komoly kihívást jelentenek.

Az Associated Press tegnap megjelent cikkében részletesen ír arról, hogy az elmúlt években megszaporodtak az amerikai kritikus infrastruktúra, elsősorban a villamosenergia-rendszerben érintett cégek elleni kibertámadások. A támadók több esetben hozzáfértek az infrastruktúra irányításához használt ICS/SCADA rendszerekhez is.

A cikkben részletesen tárgyalja a Calpine nevű, az Egyesült Államokban (a Wikipedia szerint) első számú villamosenergia-ipari vállalat elleni, 2013-ban végrehajtott kibertámadást, ami során a támadók nem csupán felhasználóneveket és jelszavakat, hanem tervrajzokat és a cég hálózatában történő adatátviteli utakat és diagrammokat is megszereztek.

2014-ben egy nagyobb szélerőmű-farmot ért támadás, a hacker nem csak bejutott a szélerőművet irányító ICS rendszerbe, hanem az automata feszültség-szabályozót is automata működésről kézire állította.

A támadások nyomainak vizsgálata arra mutat, hogy iráni, orosz és kínai csoportok egyaránt komoly érdeklődést mutatnak az amerikai kritikus infrastruktúra informatikai rendszerei iránt, de ahogy korábban, egyértelmű bizonyítékok most sem állnak rendelkezésre.

Az ilyen támadásokban a legveszélyesebb (ahogy ezt az AP által megkérdezett szakértők, Robert M. Lee, Lillian Ablon és a Calpine elleni támadást vizsgáló Brian Wallace is elmondták), hogy nagyon sokáig észrevétlenek tudnak maradni, így a támadóknak van idejük kiismerni az adott rendszer működését és ennek a tudásnak a birtokában amikor például a nemzetközi diplomáciai helyzet romlik, képesek nagyon komoly károkat okozó támadásokat indítani.

A problémákat nem csak az elavult és számos ismert biztonsági hiányosságot hordozó szoftverek jelentik, sajnos az emberi tényező ugyanolyan komoly, ha nem komolyabb kockázatokat jelent a kritikus infrastruktúra biztonságára, egyáltalán nem ritkák a cikkben is említett, post-it-ekre írt jelszavak a különböző vezérlőtermekben - és ez csak egy példa arra, hogy a gyanútlan felhasználók és/vagy üzemeltetők felelőtlen viselkedése milyen veszélyeket rejthet. Az AP cikkében írnak egy másik esetről, amikor az American Electric Power, egy 38 amerikai államban szolgáltató cég egyik alkalmazottja a céges számítógépen egy CryptoLocker malware-fertőzést okozó e-mailt nyitott meg.

Egy másik, a Wall Street Journal-ban két napja, december 20-án megjelent cikk szintén arról ír, hogy feltételezhetően iráni hackerek egy New York városától 20 mérföldre fekvő kisebb gát és vízerőmű ICS rendszeréhez szereztek hozzáférést.

Ezek az esetek is azt mutatják, hogy a különböző szervezetek (állami hátterű csoportok, hacktivisták, bűnözők) egyre komolyabb érdeklődést mutatnak a kritikus infrastruktúrákat irányító ICS rendszerek iránt és egyelőre senkinek nincs érdemi javaslata, hogy hogyan is lehetne nagyobb biztonságban tudni ezeket a rendszereket. Ahogy Sean Parcel, az American Electric Power forensics szakértője nyilatkozta az AP cikkének végén, ha a támadók elszántak és megfelelő anyagi háttérrel rendelkeznek, előbb vagy utóbb utat fognak találni ezekbe a rendszerekbe.