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.

A mai posztban folytatom az elterjedtebb ICS-specifikus protokollok rövid bemutatását.

DNP3

A DNP3 (Distributed Network Protocol) egy olyan kommunikációs protokoll, amit jellemzően folyamat-automatizálási és folyamatirányítási rendszerek (főként a villamosenergia illetve a vízellátást biztosító rendszerek) kommunikációjához használnak. Más iparágakban használt ICS rendszereknél a DNP3 protokoll használata nem elterjedt. A DNP3 protokoll különböző ICS rendszerelemek közötti kommunikációra fejlesztették, így kiemelt szerepe van a ICS rendszerek vezérlő központja és az RTU-k, illetve a különböző intelligens elektronikus eszközök közötti kommunikáció során. A ICS rendszerek vezérlő központjai közötti kommunikáció egy másik protokollt, az ICCP felhasználásával történik.

A DNP3 tervezése és fejlesztése során a kiemelt megbízhatóság volt a legfontosabb szempont, de nem fordítottak komoly figyelmet a protokoll biztonságos kialakítására (ahogy más, ICS-specifikus protokollok esetén sem), ezért később jelentős erőfeszítéseket kellett tenni, hogy a DNP3 ne csak megbízható, hanem biztonságos kommunikációt tegyen lehetővé az ezt a protokollt használó ICS rendszerek számára.

A DNP3 egy robosztus, a régebbi ICS protokollokkal (pl. Modbus) szemben hatékonyabb és más rendszerekkel könnyebb együttműködést lehetővé tevő protokoll - ennek ára a bonyolultabb felépítés.

Az OSI modell szerint a DNP3 egy layer 2 (vagy adatkapcsolati) protokoll, azonban definiál egy, a szállítási réteghez (layer 4) hasonló funkciót és egy alkalmazási réteget (layer 7), ami egy általános, a ICS rendszerekhez illeszkedő funkciókat és adattípusokat definiál.

A DNP3 protokoll specifikációja megtalálható a http://www.dnp.org weboldalon.

ICCP

Az ICCP (Inter-Control Center Communications Protocol) protokollt közműveket üzemeltető vállalatok kezdeményezésére fejlesztették. Elsődleges célja egy olyan protokoll megteremtése volt, ami támogatja a nagy hálózatokon keresztül történő adatcserét közművek vezérlőközpontjai és regionális vezérlők között. Mára az ICCP nemzetközi szabvánnyá is vált (IEC 60870-6/TASE.2)

Az ICCP alapvetően kliens-szerver környezetekben történő felhasználásra lett kifejlesztve, ahol az egyes vezérlőközpontok kliensként és szerverként is működhetnek. Az ICCP protokoll az OSI modell alkalmazási rétegében működik, emiatt az ICCP bármilyen fizikai interfészt, bármilyen hálózati szolgáltatást képes támogatni, ami illeszkedik az OSI modellhez, de a TCP/IP és az Ethernet (802.3) a leginkább elterjedt.

Eredetileg az ICCP protokoll nem támogatott semmilyen titkosítást vagy authentikációt, azonban a 2000-es évek közepére az USA-ban elindult egy kezdeményezés, aminek célja az ICCP protokoll biztonságosabbá tétele volt, ennek eredményeként jelent meg az amerikai energiaügyi minisztérium (Department of Energy, DoE) támogatásával a Secure ICCP Integration Consideration and Recommendations című Sandia National Laboratories kiadvány.

Az ICCP protokoll leírása megtalálható a Wikipedian.

Bacnet

A Bacnet egy épületfelügyeleti és automatizálási protokoll, amit az ASHRAE (American Society of Heating, Refrigerating and Air-Conditioning Engineers) égisze alatt fejlesztettek ki és mára amerikai szabvánnyá vált (Európában pedig a szabvánnyá minősítés előtt áll). A Bacnet protokoll szabványos módot biztosít az egyes eszközök funkcióinak megjelenítésére, többek között analóg és digitális bemeneti és kimeneti adatok, ütemezések és riasztások számára. Az egyes eszközök szabványosított modellje jeleníti meg az eszközről összegyűjtött adatokat, amiket objektumnak nevez és minden objektumnak több tulajdonsága van, amik leírják az adott objektumot.

A Bacnet protokollról többet a http://bacnet.org weboldalon lehet olvasni.

Az eddig bemutatott ICS-specifikus protokollokon túl természetesen vannak más, elsősorban ICS rendszerekre jellemző protokollok is, ebben a két posztban csak a legismertebbeket és leginkább elterjedteket próbáltam röviden bemutatni.

Az elmúlt napokban ismét egészen szép termés volt az ICS rendszerek sérülékenységei terén:

 Adcon Telemetry A840 Gateway Base Station

2015. december 15-én az Adcon Telemetry nevű osztrák gyártó A840 Telemetry Gateway Base Station nevű termékében talált Aditya K. Sood számos hibát. A legsúlyosabb (a CVSS v3 alapján 10 pontos hiba) egy olyan beégetett felhasználónév/jelszó páros, amivel távolról bejelentkezve adminisztrátori szintű jogosultságot lehet szerezni. A gyártó bejelentése szerint nem fogják javítani a hibát, helyette az újabb verziókra frissítést javasolják (ebből a szempontból kicsit ellentmondásosnak érzem az ICS-CERT bejelentését, mert azt írják, hogy a gyártó a stabilabb és biztonságosabb verziókra frissítést javasolja, de 5 sorral lejjebb már arról van szó, hogy a termék minden verziója érintett).

A bejelentésben a hard coded jelszó mellett írnak még az SSL titkosítás hiánya miatt minden hálózati forgalom egyszerű szöveges formátumban történik, a Java kliens pedig a szerveren tárolt naplófájlok teljes elérési útvonalát kiolvashatóan tárolja.

Az ICS-CERT bejelentése a hibáról itt olvasható: https://ics-cert.us-cert.gov/advisories/ICSA-15-349-01

eWON firmware sérülékenységek

2015. december 17-én kerültek nyilvánosságra a Karn Ganeshen, független biztonsági kutató által az eWON 10.1s0-nál régebbi firmware-jeiben talált hibák:

Hiba a session-kezelésben - a kijelentkezés funkció hibája miatt kijelentkezés után is lehetőség van a korábban authentikációra használt böngészőből kapcsolatot kezdeményezni a sérülékeny firmware-t futtató eszközökkel.

Cross-Site Request Forgery - a hiba típusa (feltételezem) nem szorul magyarázatra, sikeres kihasználása esetén firmware-feltöltésre, az eszköz újraindítására vagy az aktuális konfiguráció törlésére nyílik lehetősége a támadónak.

Gyenge Role-based access control (RBAC) - a hibásan implementált RBAC miatt authentikáció nélkül is információkat lehet szerezni az I/O szerverek állapotáról.

Stored XSS - a hiba kihasználásával a támadó kliens oldalról tud kódot bejuttatni a web vagy az alkalmazásszerverbe, hogy utána ezzel a kártékony kóddal más felhasználókat lehessen támadni.

Nem biztonságos jelszókezelés - a sérülékeny firmware-ek egyszerű szöveges formmában továbbítják a jelszavakat, így egy támadó a hálózati forgalom lehallgatásával megismerheti ezeket. A firmware-ben használt űrlapokon működő automatikus kiegészítés funkció miatt a böngészőből is kinyerhetőek a felhasználói jelszavak.

HTTP POST/GET probléma - az eWON firmware-be épített webszerver lehetőséget ad a POST parancs helyett a kevésbé biztonságos GET használatára.

A hibák egy részét (Session-kezelési hiba, jelszókezelési hibák némelyike) javította a legújabb firmware-verzióban, a többi hibával kapcsolatban pedig tanácsokat ad a weboldalán: http://ewon.biz/support/news/support/ewon-security-enhancement-7529-01

A ICS-CERT bejelentése teljes terjedelemben itt olvasható: https://ics-cert.us-cert.gov/advisories/ICSA-15-351-03

Motorola MOSCAD SCADA IP Gateway

Aditya K. Sood két hibát talált a Motorola MOSCAD SCADA IP Gateway nevű termékében, ezekről 2015. december 17-én jelent meg az ICS-CERT közleménye. https://ics-cert.us-cert.gov/advisories/ICSA-15-351-02 A hibák a termék minden verzióját érintik. Az első hibát kihasználva authentikáció nélkül lehet távolról a rendszer fájljaihoz hozzáférni, a második hibát (CRSF) kihasználva pedig a token használatának mellőzése miatt egy támadó át tudja írni az éppen bejelentkezett felhasználó jelszavát.

A termékhez 2012 óta nem jelentek meg frissítések, az ICS-CERT tanácsa szerint a felhasználók számára javasolt egyeztetni a Motorola ügyfélszolgálatával.

Puffer túlcsordulási hiba a Schneider Electric Modicon M340 PLC-iben

A 2015. december 17-én nyilvánosságra került bejelentés alapján Nir Giller független biztonsági kutató egy puffer túlcsordulási hibát talált a Schneider Electric Modicon M340-es sorozatú PLC-iben, amivel egy támadó távoli kódfuttatási lehetőséget szerezhet. A hiba az alábbi termékeket érinti az M340-es PLC-termékcsaládon belül (zárójelben, hogy az egyes típusokhoz melyik napon jelent meg a hibát javító firmware-verzió):
BMXNOC0401 (2015.12.15.), BMXNOE0100, BMXNOE0100H(2015.12.15.), BMXNOE0110, BMXNOE0110H(2015.12.15.), BMXNOR0200, BMXNOR0200H(2015.12.16.), BMXP342020(2015.12.16.), BMXP342020H, BMXP342030, BMXP3420302(2015.12.16.), BMXP3420302H és BMXPRA0100(2015.12.16.).

További információk a gyártó weboldalán vagy az ICS-CERT bejelentésében olvashatóak