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

A következő néhány posztban az elterjedtebb, ICS rendszerek által használt protokollokat fogom röviden áttekinteni.

Modbus:

A Modbus egy soros porti kommunikációs protokoll, amit a Modicon (ma Schneider Electric) publikált 1979-ben PLC berendezésekhez. Az eltelt több, mint 35 évben kvázi standard lett az ipari rendszerek fejlesztése során, az eredetileg RS-232-re és RS-485-re tervezett protokollt az Ethernet hálózatok terjedésével átdolgozták TCP-re is. Népszerűségének és elterjedtségének számos oka van, többek között, hogy a fejlesztése során az ipari alkalmazásokra optimalizálták, könnyű alkalmazni és karbantartni, valamint publikusan elérhető a specifikáció és kevés megkötést tesz a ipari rendszerek fejlesztői és szállítói felé.

A Modbus protokoll specifikációja itt érhető el: http://www.modbus.org/specs.php

RP-570

Az RP-570 egy ICS rendszerekben használt kommunikációs protokoll, amit a front-end számítógépek és az alállomások közötti kapcsolatokban használják, elsősorban az ABB nevű, ipari automatizálási és vezérlő rendszereket gyártó vállalat termékeiben.

Az RP-570 protokoll specifikációja az ABB weboldalán publikusan elérhető.

Profibus

A Profibus (Process Field Bus) egy szabvány fieldbus kommunikációs protokoll, amit 1989-ben mutatott be a BMBF (a német oktatási és kutatási tanszék) és a Siemens kezdte használni egyes folyamatirányító termékeiben. A 2010-es években a Profibus protokoll két változata van használatban, a Profibus DP (Decentralised Peripherals) és a Profibus PA (Process Automation), a kettő közül a Profibus DP az elterjedtebb.

A Profibus DP-t leginkább szenzorok és gyártósorok vezérlésére, míg a Profibus PA-t a folyamatautomatizálás és folyamatirányítás során a mérőberendezések felügyeletére használják.

A Profibus specifikációját jelenleg nem ismerem ingyenesen hozzáférhető változatát, kereskedelmi forgalomban az IEC-nél lehet megvásárolni (összesen 82 darab PDF, átlagosan 250 CHF/PDF áron).

Conitel

A Conitel egy számos ICS rendszerben használt aszinkron kommunikációs protokoll, amelyet a Leeds&Northrup fejlesztett ki a saját ICS rendszerük és RTU-ik közötti kommunikáció céljára. A Conitel protokoll message blokkja 31 bites, ehhez tartozik egy szinkronizáló "indító bit" a message blokk elején és egy üzenet vége (EoM) bit minden üzenet blokk végén. A protokollt egyaránt lehet pont-pont kommunikációban és multi-drop konfigurációban, valamint half-duplex és full-duplex módban. A Conitel protokoll használata esetén minden esetben a host kezdeményezi a kommunikációt, az RTU csak a host-tól érkező kérésekre képes válaszokat küldeni. Ez alól egyetlen kivételt a broadcast üzenetek képeznek. A host-tól érkező üzeneteket az RTU-k egy 5-bites Bose-Chaudhuri ciklikus kódolás használatával ellenőrzik. A BCH kód minden üzenetben megtalálható, ha ennek alapján az üzenet nem érvényessége nem ellenőrizhető, az RTU figyelmen kívül fogja hagyni az üzenetet és nem küld rá választ.

A Conitel protokoll leírása itt található: http://www.miille.com/conitel.pdf

IEC 60870-5-101

Az IEC 68870-5-ös szabvány szerinti 101-es protokollt elsősorban a villamosenergia-rendszerben használják a villamosenergia-rendszer telekommunikációs kapcsolatainak monitorozására és ellenőrzésére. A 101-es protokoll tökéletesen kompatibilis az IEC-60870-5-1-től 5-ig terjedő szabványokkal és többféle konfiurációt is támogatni (pl. pont-pont, csillag, stb.). A 101-es protokoll frame-ek egy start bit-ből, egy stop bit-ből, egy paritás bit-ből és 8 adat bit-ből állnak. A protokoll három féle frame formátumot tud használni, a változó hosszúságú formátumot, a fix hosszúságú frame-eket és az egyetlen karakteres frame-eket. Az egyetlen karakteres frame-eket visszaigazolásokra , a fix hosszúságú frame-eket parancsok kiadására, a változó hosszúságú frame-eket pedig adatküldésre használja a protokoll.

IEC 60870-5-104

A 104-es protokoll a 101-es protokoll kiegészítése. A kiegészítés célja, hogy a 101-es protokoll minél inkább illeszkedjen az IP hálózatok felépítéséhez, emiatt az OSI modell átviteli, hálózati, adatkapcsolati és fizikai rétegeihez kapcsolódó kiegészítéseket tartalmaz. A 104-es protokoll TCP/IP interface-eken keresztül tud csatlakozni a helyi hálózatokra és routereken keresztül, különböző technológiák (pl. ISDN, X.25, Frame relay) felhasználásával tud kapcsolódni nagyobb hálózatokhoz.

Az IEC 60870-5-ös protokoll-családnak egészen jó leírása található meg a Wikipedia-n.

A mai posztban az ICS rendszerekkel kapcsolatban gyakran használt kifejezéseket és rövidítéseket fogom röviden áttekinteni.

SCADA (Supervisory Control And Data Aquisition) - A SCADA rövidítés a folyamatirányító és adatgyűjtő kifejezés angol rövidítéséből származik. A SCADA rendszerek olyan számítógép alapú rendszerek, amelyek kódolt jelek használatával biztosítják a távoli (jellemzően ipari) berendezések felügyeletét. Amennyiben ezen a csatornán adatokat is fogadnak a végponti berendezésektől, akkor beszélünk adatgyűjtő rendszerről. A SCADA rendszerek alkotják az ICS rendszerek (lásd később ebben a posztban) egyik nagy csoportját. A SCADA rendszereket felhasználásuktól függően jellemzően három csoportba szokták besorolni, ipari folyamatok, infrastruktúra-folyamatok és létesítmény-folyamatok felügyeletére, irányítására és adatgyűjtésére használva őket. (http://en.wikipedia.org/wiki/SCADA)


ICS - Az ICS az Industrial Control System gyűjtőkifejezés rövidítése. ICS-nek neveznek ipari környezetben minden olyan informatikai rendszert, amelyek felügyeleti és adatgyűjtő feladatokat látnak el, ugyanígy ICS-nek tekintik az elosztott irányító rendszereket (DCS) és a PLC-ket is. (http://en.wikipedia.org/wiki/Industrial_control_system)

DCS (Distributed Control System) - A DCS kifejezés az elosztott irányítórendszer angol rövidítéséből származik. A DCS rendszereket jellemzően olyan folyamatok vagy üzemek (gyárak, erőművek, stb.) irányítására használják, ahol az irányítás egyes elemei elosztottan találhatóak meg a rendszerben. Ez az egyik jelentős különbség a DCS rendszerek és az egy nagy, központi helyen elhelyezkedő irányító berendezésből álló rendszerek között. A DCS rendszerek néhány jellemző felhasználási területe: vegyi üzemek, olajfinomítók, nukleáris létesítmények, fémmegmunkáló üzemek, gyógyszergyárak, nagy teherszállító hajók, pl. tankerek, stb. (http://en.wikipedia.org/wiki/Distributed_control_system)

PLC (Programmable Logic Controller) – A PLC-k olyan ipari számítógépek, amelyek a beléjük programozott logika alapján, a kapott értékekből és a saját állapotukból kiindulva hoznak döntéseket gépek vagy folyamatok automatizálása során. Hasonlóan az RTU-khoz, a PLC-ket is tekinthetjük egyfajta interfésznek a számítógépek és az irányított rendszerek között. (http://en.wikipedia.org/wiki/Programmable_logic_controller)

RTU (Remote terminal unit) – A ICS rendszerekben az RTU-k csatlakoznak a különböző ipari berendezésekhez, interfészt képezve a számítógépes rendszer és az irányított rendszer között. Általában az RTU-k végzik a számítógépes rendszerek digitális jeleinek át- és visszaalakítását az irányított rendszerek elektronikus jeleire (pl. egy kapcsoló állása, nyomás, feszültség, stb.). (http://en.wikipedia.org/wiki/Remote_Terminal_Unit)

Telemetria - A telemetria egy nagymértékben automatizált, távoli mérési és egyéb adatok összegyűjtését megvalósító folyamat. A kifejezést jellemzően vezeték nélküli kommunikációs formák (pl. rádió, ultrahang vagy infravörös adatátvitel) esetén használják, léteznek megvalósításai telefonvonalon, számítógépes hálózaton, optikai és réz kábelen egyaránt. A modern telemetriai rendszerek gyakran használják a GSM hálózatokat (pl. SMS-ben elküldve az adatokat).

HMI (Human-Machine Interface) – A HMI a ICS rendszerekben az a berendezés, ami megjeleníti a különböző folyamatok adatait a ICS rendszert felügyelő felhasználóknak.

MMI (Man-Machine Interface) - http://program-plc.blogspot.hu/2012/01/difference-between-hmi-and-mmi.html

Felügyeleti rendszer – Azoknak a szervereknek és szoftvereknek az összefoglaló megne-vezése, amelyek felelősek a különböző interfész-eszközök (RTU-k, PLC-k, stb.) és a HMI-k között történő kommunikációért. http://en.wikipedia.org/wiki/Supervisory_control

Kommunikációs infrastruktúra – A ICS rendszerek esetén hagyományosan rádióhullámokon vagy közvetlen kábeles kapcsolaton alapuló összeköttetést használtak, ugyanakkor bizonyos területeken elterjedt a SONET (Synchronous Optical Networking) és az SDH (Synchronous Digital Hierarchy) kapcsolat, illetve újabb az SDH helyett NG-SDH-t is használnak.

Különböző folyamatszabályozó és elemző műszerek – Ezek azok az elemek egy ICS rendszerben, amik a különböző interfész-eszközök (RTU-k, PLC-k, stb.) számára az irányított rendszert elérhetővé teszik. Ezeken keresztül érkeznek a különböző mérési adatok és ezeken keresztül lehet szabályozni a rendszereket.

Az ICS-CERT december 10-én közzétett bejelentése szerint DLL hijacking sérülékenység található az Open Automation Software OPC System NET nevű termékeiben. A hibát Ivan Sanchez, a Nullcode Team kutatója fedezte fel. A szoftver 8.00.0023 és korábbi verzióit érintő hiba kihasználásával egy támadó ugyanolyan jogosultsági szintet szerezhet a megtámadott rendszeren, mint amilyen jogosultságokkal az OPC System NET fut. A hibát nem lehet távolról illetve felhasználói interakció nélkül kihasználni, csak olyan esetekben támadható a sérülékenység, ha egy helyi felhasználó futtatja az alkalmazást és betölti a támadáshoz használt, hibát kihasználó DLL-t.

Mostanáig nem bukkant fel a hibát kihasználó exploit és egy működő exploit megírása valószínűleg nem egyszerű feladat, programozói tudáson kívül ügyesnek kell lenni a felhasználó átverésében is, hogy rá lehessen venni a hibát kihasználó DLL letöltésére, majd ennek a DLL-nek a betöltésére az alkalmazásba, mindezek együtt várhatóan csökkentik a hiba kihasználásával végrehajtott sikeres támadások esélyeit. A hiba javításáról egyelőre nincs információ. Az ICS-CERT ajánlása szerint azok az Open Automation Software-ügyfelek, akik sérülékeny verziójú alkalmazást használnak és feltételezik, hogy kompromittálhatták a rendszerüket, lépjenek kapcsolatba a gyártóval.

A hibával kapcsolatban további információk az ICS-CERT bejelentésében olvashatóak.

Ugyancsak hibát találtak az Advantech EKI-1200-as Modbus gateway-sorozat EKI-132x típusú termékeiben. Az EKI-1200-as sorozatú gateway-eket Modbus/RTU és Modbus/ASCII soros interfésszel rendelkező eszközök TCP/IP hálózatokban üzemelő eszközökkel történő integrálására használják, jellemzően automatizált ipari környezetekben. A hibát a Rapid7 munkatársa, Tod Beardsley fedezte fel. A sérülékenység tulajdonképpen a tavaly nagy port kavart Shellshock-hiba, aminek kihasználásával az EKI-1200-as sorozatú eszközökön tetszőleges kód futtatására, tanúsítványok privát kulcsainak megszerzésére nyílik lehetősége a támadónak és egy authentikált felhasználót megszemélyesítve akár Man-in-the-middle típusú támadásokat is végre lehet hajtani. A hibát távolról is ki lehet használni és számos publikus exploit elérhető, amivel akár egy kevésbé képzett támadó is sikeresen kompromittálhatja a sérülékeny eszközöket.

Az Advantech december végére ígéri a hiba javítását az érintett termékek firmware-ében. A javított firmware megjelenéséig az ICS-CERT több intézkedést is javasol az Advantech ügyfeleli számára, ezek, a sérülékenységről szóló további információkkal a bejelentésben érhetőek el.

A mai napon az ICS-CERT két, ICS rendszereket érintő hibáról szóló bejelentést tett közzé. Az elsőt a Loytec nevű németországi központú cég ipari routereiben találta Maxim Rupp, független biztonsági kutató. A hiba (akár távoli) kihasználásával a routereken hozzáférhető a felhasználók jelszavaiból képzett hash-eket tároló backup fájl. A hiba a LIP-3ECTB 6.0.1-es verzióját, valamint a LINX-100, LVIS-3E100 és LIP-ME201 típusú eszközöket érinti. A hibát kihasználó exploitról eddig még nincs hír, a gyártó pedig a weboldalán már elérhetővé tette a hibát javító friss firmware-t (innen tölthető le), így célszerű a felhasználóknak (természetesen a szükséges tesztek elvégzése után) mielőbb telepíteni a javított verziót.

Az ICS-CERT bejelentése a sérülékenységről itt található: https://ics-cert.us-cert.gov/advisories/ICSA-15-342-02

A másik hibát, egy Cross-Site Request Forgery-t, az XZERES 442SR típusú szélerőművi turbina operációs rendszerének webes interfészében találta Kam Ganeshen független kutató. Az XZERES kis teljesítményű (2,4-10kW) szélerőművi turbinákat gyárt. A hibát kihasználva ki lehet nyerni a felhasználói azonosítót a böngészőből és lehetőség nyílik az alapértelemezett felhasználói azonosító módosítására is. A hibát távolról is ki lehet használni. Ismert exploit egyelőre nem került napvilágra, annak ellenére, hogy nem nehéz működő exploitot írni az ilyen hibákra. Az XZERES elérhetővé tett ügyfelei számára egy manuálisan telepíthető patch-et.

Az ICS-CERT bejelentése a sérülékenységről itt található: https://ics-cert.us-cert.gov/advisories/ICSA-15-342-01

Az XPD AB és az Assured AB, két svéd biztonsági tanácsadó cég bejelentését a svéd CERT tette közzé. A bejelentés alapján a Pacom 1000 CCU bázisállomásai és RTU-i közötti kommunikáció titkosításában több súlyos sérülékenységet találtak, amelyeket kihasználva kompromittálni lehet a rendszert és ezáltal csökkenteni által felügyelt távoli helyszínek fizikai biztonsági szintjét, a legrosszabb esetben a teljes riasztórendszert használhatatlanná téve.

A sérülékenységet okozó hibákról részletesen az XPD bejelentésében lehet olvasni: https://xpd.se/advisories/XPD-2015-001.txt

A sérülékenység a Pacom 1000 (CCU & RTU) minden verzióját érinti és a gyártó bejelentése alapján ebben a termékben nem fogják javítani, az érintett felhasználóknak azt javasolják, váltsanak az EMCS (Pacom .is) platformra. A sérülékenység az EMCS (Pacom .is) termék minden 1.3-nál korábbi verzióját is érinti. Az 1.3-as és újabb verziók már nem érintettek.

A Pacom termékeit világszerte számos területen használják, ügyfeleik egyaránt megtalálhatóak többek között a pénzügyi szektorban, az oktatásban, a közigazgatásban, tömegközlekedésben, közműszolgáltatásban és az egészségügyben.

(Megjegyzés: Eredetileg úgy terveztem, hogy az első néhány poszt általános áttekintés lesz a különböző ICS rendszerekkel kapcsolatos történelmi, protokoll és biztonsági témákról, röviden megnézzük, kik azok a gyártók, akikkel jellemzően találkozni lehet az ICS rendszerek piacán és csak utána indítom útjára az ICS rendszerekben felfedezett sérülékenységekről hírt adó blogposzt-sorozatot. Aztán az élet közbeszólt, de ez jól is van így, legalább mindenki láthatja, mennyire megváltozott a 2010 előtt végtelenül statikusnak látszó ICS-világ.)

A modern társadalmak lakói a nap minden percében úgy élik az életüket, hogy közben számos ICS rendszert használnak tudtukon kívül. ICS rendszerek segítségével jut el az otthonokba és munkahelyekre az ivóvíz, az elektromos áram, a földgáz, ICS rendszerek vezérlik a hő- és vízerőműveket, a közlekedési lámpák hálózatát és a vasúti jelzőberendezéseket, a nagyobb épületek működését, a légiközlekedést és még sok minden mást.

Az első ICS rendszereket az 1960-as években hozták létre. Az akkor alkalmazott módszerek és tervezési elvek közül nagyon sok még ma, közel 50 évvel később is alapjait képezik a ICS rendszerek fejlesztésének és üzemeltetésének, annak ellenére, hogy az eltelt fél évszázad, de különösképpen az elmúlt 10-15 évben az Internet és az informatika fejlődése soha nem látott méreteket öltött. A ICS rendszereket fejlesztő és üzemeltető szervezetek azonban nagyon sokáig nem vettek tudomást ezekről a változásokról. Részben ez vezetett oda, hogy a ICS rendszerek elleni támadások napjainkban egyre nagyobb méreteket öltenek, az ezeknek a rendszereknek a védelméért felelős szakemberek pedig olyan kihívással találták szemben magukat, mint korábban még soha.

Az első generációs ICS rendszerek mainframe-ekből épített, monolitikus rendszerek voltak, amelyek semmilyen más rendszerrel nem álltak kapcsolatban. Később, az RTU-k megjelenésével szükségessé vált a WAN (Wide Area Network) kialakítása annak érdekében, hogy az RTU-k/PLC-k és a felügyeleti rendszer tudjon kommunikálni. Az első generációs ICS rendszerek esetén a mainframe számítógépen kívül jellemzően nem léteztek más számítógép-elemek a rendszerben, egyes esetekben a nagy rendelkezésre állás biztosítása érdekében egy tartalék mainframe volt adatbuszon keresztül az elsődleges mainframe-re csatlakoztatva. Az első generációs ICS rendszerek által használt protokollok nagyon nagy többségükben zárt forrásúak voltak.

A második generációs ICS rendszerek már több számítógépből épültek fel, amelyek a LAN-on (Local Area Network) keresztül kommunikáltak egymással és valós időben cseréltek adatokat. Minden, a hálózatba kötött számítógép jól meghatározott feladatot látott el. A második generációs ICS rendszerek által használt protokollok döntő része még zárt forrású volt, amit a kis számú fejlesztőn kívül alig néhányan ismertek, ez jelentősen megnehezítette a különböző ICS rendszerek biztonságának meghatározását, mindamellett kialakította azt a nézetet, hogy „a ICS rendszerek pedig már azért is biztonságosak, mert csak az ért hozzá, akinek értenie kell.” Az informatikában és az IT biztonság területén a security through obscurity-megközelítés hatékonyságával kapcsolatban ma már keveseknek vannak kétségeik.

A harmadik generációs ICS rendszereket nevezik hálózatos ICS rendszereknek is. Ezek már olyan ICS rendszerek, amelyek a jellemzően ICS rendszerekben használt protokollok (Modbus, DNP3, ICCP, stb.) mellett számos szabványosított és széles körűen használt protokollt is alkalmaznak (pl. TCP/IP, http, Telnet, stb.). Ez, valamint az a tény, hogy sok ICS rendszer az Internettel is közvetett vagy közvetlen összeköttetésbe került, jelentősen megnövelte az esélyét a sikeres, ICS rendszerek elleni támadásoknak.

Az ipari irányító-/folyamatirányító (angol rövidítéssel ICS/SCADA vagy még rövidebben ICS) rendszerekkel kapcsolatos biztonsági vonatkozású kérdések az elmúlt valamivel több, mint öt évben (a Stuxnet, az iráni atomprogram lelassítása érdekében fejlesztett és bevetett kiberfegyver felfedezése, 2010 óta) reflektorfénybe kerültek, ennek ellenére a témáról magyar nyelven nagyon kevesen írnak. Bár a különböző ICS/SCADA rendszerekről több százezernyi magyar nyelvű találatot adnak a különböző keresőoldalak, tehát az ipari irányítórendszerek magyar nyelvű szakirodalma létezik, azonban az ICS/SCADA rendszerek biztonságáról csak nagyon kevés magyar nyelvű publikáció hozzáférhető és az informatikai biztonsággal foglalkozó vállalatok között is csak elvétve akad olyan, amely nevesítené a folyamatirányító rendszerek biztonságát a tevékenységei között. Pedig Magyarország, mint minden fejlett infrastruktúrával rendelkező ország, nagymértékben hagyatkozik a különböző folyamatirányító rendszerek zavartalan működésére.

A blog elsődleges célja, hogy az információ- és IT biztonsági szakmában tevékenykedő, valamint a ICS rendszerek üzemeltetésével és fejlesztésével foglalkozó magyar szakemberek számára rendszeresen a témába vágó információkat és gondolatokat közvetítsen és közöttük elindítson egy olyan szakmai párbeszédet, aminek eredményeként az ország szempontjából kiemelten fontos informatikai rendszerek biztonsága remélhetőleg növekedni fog. Ebből következik, hogy mindazok hozzászólásaira, reakcióira számítunk, aki ICS rendszerek fejlesztésével, üzemeltetésével vagy azok biztonsági kérdéseivel foglalkozik vagy csak egyszerűen érdekli ez a téma.

A blogot az Önkéntes Kibervédelmi Összefogás üzemelteti, ennek ellenére a blogon megjelenő posztok nem tükrözik a KIBEV teljes tagságának álláspontját az adott témában.

Az első posztokban a tervek szerint a ICS rendszerek (a blogon az egyszerűség kedvéért a ICS kifejezést fogom használni minden ICS/SCADA rendszerre) történetéről és generációiról, valamint a témában fontosabb kifejezések/rövidítések ismertetésével és a jelenleg leginkább elterjedt protokollok rövid bemutatásával fogok foglalkozni, utána pedig az élet és a szakma majd alakítják az aktuális témákat.