DoS sérülékenység Siemens SCALANCE S tűzfalakban

A Siemens ProductCERT-je által nyilvánosságra hozott hibát kihasználva egy támadó közelebbről nem definiált körülmények között képes lehet szolgáltatás megtagadásos támadást indítani a SCALANCE S613 típusú, ipari környezetekbe tervezett tűzfalakban található webszerver ellen. A hiba kihasználásához a támadónak hozzá kell férnie a SCALANCE S613 hálózatához, majd megfelelően formázott üzeneteket kell küldenie a tűzfal 443/tcp portjára. A hiba a CVSSv3 szerint 5.3 pontot kapott. A gyártó a SCALANCE-felhasználóknak azt javasolja, hogy lépjenek kapcsolatba a Siemens ügyfélszolgálati központjával. További részleteket a Siemens ProductCERT bejelentése tartalmaz.

GNU C sérülékenység több ipari termékben

A CVE-2015-7547-ben. 2015.09.29-én nyilvánosságra hozott GNU C sérülékenység (nem túl meglepő módon) nem kerülte el a Simens több ipari termékét sem. Röpke fél év kellett, hogy nyilvánosságra hozzák, mit lehet tenni az alábbi, érintett termékeikkel:

- ROX II (V2.3.0-V2.9.0 verziók);
- APE (Linux): minden verzió;
- SINEMA Remote Connect (minden verzió);
- SCALANCE M-800/S615 (minden verzió);
- Basic RT V13 (minden verzió);

Két esetben már javították a hibát:

- A ROX II esetén a hibát a V2.9.1-es verzióra történő frissítés javítja;
- APE (Linux) termékek esetén a http://support.automation.siemens.com/WW/view/en/109485761 oldalon elérhető feljegyzésben leírtakat kell végrehajtani;

A SINEMA Remote Connect, SCALANCE M-800/S615, Basic RT V13 termékek esetén továbbra sincs elérhető javítás a sérülékenységre, az ezeket a termékeket használó szervezeteknek a Siemens az alábbi, kockázatcsökkentő intézkedéseket javasolja bevezetni:

- Kapcsolják ki az érintett eszközökön a DNS szolgáltatást, vagy
- Használjanak megbízható DNS szervereket, hálózatokat/szolgáltatókat és DNS domain-eket a sérülékeny eszközök konfigurálásához, vagy
- Limitálják a DNS válaszok méretét UDP üzeneteknél 512 byte-ra, TCP üzeneteknél 1024 byte-ra.

További részleteket a Siemens bejelentésében lehet olvasni.

DROWN sérülékenység Siemens ipari rendszerekben

A DROWN sérülékenység sem éppen friss (már közel 4 hónapja, hogy ettől volt hangos az IT biztonsági szakma), a Siemens most közzétett bejelentése szerint az alábbi termékeiket érinti a hiba:

- SCALANCE X300 család (minden verzió);
- SCALANCE  X414 (minden verzió);
- SCALANCE  X200 IRT család (minden verzió);
- SCALANCE  X200 RNA család (minden verzió);
- SCALANCE  X200 család (minden verzió);
- ROX I (minden verzió);

A hiba javításáig a Siemens ezeknél a termékeket használó ügyfeleinek is azt javasolja, hogy különböző intézkedésekkel csökkentsék a sérülékenységek jelentette kockázatokat:

- Korlátozni kell a sérülékeny eszközök esetén a webszerver elérését (443/tcp port, ROX I esetén a 10000/tcp port, amennyiben a gyári beállításokat nem változtatták meg);
- Korlátozni kell a menedzsment portok elérését a belső hálózatra (én azért ennél is tovább mennék és ha már az eszköznek van dedikált menedzsment interface-e, aztán talán kössük egy dedikált és megfelelően szeparált és védett menedzsment hálózat - már ha van menedzsment hálózat);
- Mélységi védelmet kell kialakítani;

További részleteket a Siemens ProductCERT oldalán elérhető PDF tartalmaz.

Lemur Vehicle Monitors BlueDriver LSB2 sérülékenység

Hogy ne csak a Siemens termékeinek hibáiról szóljon a mai poszt, zárásnak egy kicsit egzotikusabb hibát találtam. A Carnegie Mellon Egyetem Szoftverfejlesztési Intézete (CMU-SEI) a cert.org-on hozta nyilvánosságra, hogy Lemur Vehicle Monitors BlueDriver LSB2 nevű, autoipari Bluetooth-kommunikációs megoldása, ami az autók OBD-II portjára képes csatlakozni és információkat kinyerni a jármű teljesítményéről, nem kér felhasználói authentikációt (PIN kódot) a Bluetooth-on történő csatlakozáskor. A hibát ugyan Bluetooth működési sajátosságai miatt csak kis távolságról lehet kihasználni, azonban egy korábban kompromittált telefont proxy-ként használva meg lehet növelni a támadás hatótávolságát.
A CERT/CC-nek jelenleg nincs tudomása a hiba érdemi javítási lehetőségeiről és workaround-ként azt javasolja, hogy ne használják az érintett járműveket csatlakoztatott LSB2-vel.

A hibáról részleteket a cert.org oldalán lehet olvasni.

Termékeny napja volt tegnap az ICS-CERT-nek, 3 különböző ICS gyártó termékeivel kapcsolatos hibát is publikáltak.

Rockwell Automation Integrated Architecture Builder sérülékenységek

A Rockwell Automation Integrated Architecture Builder 9.6.0.7 és annál korábbi, valamint a 9.7.0.0 és 9.7.0.1-es verzióiban Ivan Sanchez, a Nullcode Team tagja fedezett fel memória-hozzáférési hibát. A sérülékenységet kihasználva a támadó az alkalmazás jogosultságával futtathat tetszőleges kódot a rendszeren. A hibát nem lehet távolról, illetve felhasználói interakció nélkül kihasználni.

A gyártó elérhetővé tette a hibát javító verziókat és számos egyéb tanácsot is ad, amivel csökkenteni lehet a sérülékeny rendszerek kockázatait:

- Nem szabad ismeretlen forrásból származó projekt fájlokat megnyitni az IAB.exe alkalmazással;
- Az alkalmazást korlátozott (felhasználói szintű) jogosultságokkal kell futtatni adminisztrátori jogosultságok helyett (itt tenném hozzá, hogy számos helyen láttam már, hogy egyenes local system-ként futnak az alkalmazások, nem is "csupán" adminisztrátori jogokkal - gondolom nem én vagyok az egyetlen...)
- Csak megbízható forrásból származó szoftvereket és patch-eket szabad használni, és javasolt antivírus/antimalware szoftvereket használni;
- Biztonságtudatossági képzési programokat kell tartani a felhasználóknak, ahol meg kell ismertetni velük azokat a jeleket, amikre figyelve felismerhetik az adathalász/social engrineering támadásokat;
- Minimalizálni kell, vagy ha lehetséges, meg kell szüntetni az ICS rendszerek kitettségét a támadásoknak és biztosítani kell, hogy nem lehet őket elérni az Internet irányából;
- Tűzfalakkal és egyéb hálózatszegmentációban használt eszközökkel szeparálni kell az ICS rendszereket az egyéb informatikai rendszerektől;
- Javasolt csak a bevizsgált és engedélyezett alkalmazások futását engedélyezni (application whitelisting).

A hibáról további információkat az ICS-CERT bejelentése tartalmaz: ICSA-16-056-01

Eaton Lighting Systems EG2 Web Control Authentication Bypass Vulnerabilities

Az Eaton Lighting Systems EG2 Web Control v4.04P és korábbi verziójú termékeiben Maxim Rupp fedezett fel két olyan hibát, amelyek kihasználásával meg lehet kerülni a rendszer authentikációs folyamatát. A hibák közül az egyiket a nem megfelelően ellenőrzött cookie-k használata jelenti, a másik pedig lehetővé teszi a szöveges formában tárolt érzékeny adatok illetéktelenek általi megismerését.

A gyártó a hibákat a legújabb verziójú firmware-ben javította a hibákat, egyúttal jelezte, hogy az idei év későbbi részében az érintett termékek elérik életciklusuk végét és hogy a hibás funkciót el fogja távolítani az eszközeiből.

A hibáról további információkat az ICS-CERT bejelentése tartalmaz: ICSA-16-061-03

Pro-face GP-Pro EX HMI sérülékenységek

A Pro-face’s GP-Pro EX HMI szoftverében a Zero Day Initiative (ZDI) munkatársai találtak számos hibát, melyek távolról is kihasználhatóak, egy részük kihasználásához pedig felhasználói interakció sem szükséges. A sérülékenységek az EX-ED, PFXEXEDV, PFXEXEDLS, PFXEXGRPLS modelleket, illetve az 1.00-tól 4.0.4-ig terjedő szoftververziókat érintik. A hibák között egyaránt van heap- és stack-alapú puffer-túlcsordulás, beégetett felhasználói azonosítók és authentikáció-megkerülésre lehetőséget adó hiba is.

A gyártó a hibákat a GP-Pro EX (4.05.000 és későbbi) verziójú modulban javította.

A hibáról további információkat az ICS-CERT bejelentése tartalmaz: ICSA-16-096-01

Mindhárom sérülékenységgel kapcsolatban élnek az ICS-CERT általános érvényű, kockázatokat csökkentő javaslatai:

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

A Verizon Enterprise 2016 márciusi adatbiztonsági incidenseket összefoglaló kiadványában  egy 5 oldalas összefoglaló (gyakorlatilag egy esettanulmány) jelent meg a Kemuri Water Company (KWC) rendszerében felfedezett ICS kiberbiztonság incidensről. Az esetet a szaksajtó is felkapta, számos online biztonsági híroldalon jelentek meg cikkek az esetről.

A KWC egy proaktív ellenőrzést kért a Verizon RISK Team-jétől, vagyis állításuk szerint semmilyen jel nem utalt arra, hogy bármilyen IT vagy ICS biztonsági incidens érintette volna a rendszereiket. A vizsgálat során a Verizon a vizsgálat során számos aggasztó részletet tárt fel. Ilyenek voltak az összefoglalóban antiknak nevezett, 10 évnél öregebb informatikai rendszerek, amelyek továbbra is éles üzemben voltak használva. A KWC központi rendszere egy AS400 alapú rendszer, ami egyszerre szolgált a víziközmű folyamatirányító rendszereként, százas nagyságrendű PLC-t vezérelve és biztosított backend-szolgáltatásokat a számlázórendszer és az Internet irányából elérhető webes alkalmazások számára az ügyfél azonosító adatok tárolásával (ezeket többek között az Internetes fizetési lehetősége biztosító alkalmazás is használta). Gyakorlatilag az AS400-as rendszer, a különböző hálózati zónákba kiépített kapcsolatain keresztül router-ként funkcionált a KWC hálózatában. Mindezen túl további üzemeltetési és logikai biztonsági kockázatokat jelentett, hogy ezt a rendszert mindössze egyetlen ember üzemeltette.

Az Internet irányából elérhető szolgáltatások használatához a KWC csak a felhasználónév-jelszó páros követelte meg, többfaktoros azonosítást nem alkalmaztak, ráadásul az alkalmazásszerver és az AS400-as szerver között direkt fizikai összeköttetés volt kialakítva, de hogy a helyzet még rosszabb legyen, a Verizon szakemberei felfedezték, hogy az AS400 elérhető volt az Internet irányából, az alkalmazás szerver egyik .ini fájljában elérhető volt az AS400-as szerver belső hálózati IP címe is.

A további vizsgálatok során kiderült, hogy a KWC rendszereit korábban már kompromittálták (erről a vizsgálatnak eddig a pontjáig a KWC-nek nem volt tudomása - ez mondjuk nem túl meglepő, ha az átlagos IT biztonsági incidens-felderítési időablakot nézzük, ami jóval több, mint 200 nap!) és mintegy 2,5 millió ügyfél adatait lopták el. Még ennél is nagyobb gondot jelentett az, hogy a támadók nem elégedtek meg az ügyféladatok ellopásával, hanem beavatkoztak a szelepeket és a vízvezetéket vezérlő alkalmazás működésébe is és ezt kb. 60 napig voltak képesek megtenni a vizsgálatot megelőzően. Legalább két esetben megváltoztatták azoknak a vegyszereknek a mennyiségét, amiket a KWC az ivóvíz megfelelő minőségének biztosítása érdekében használ a vízvezeték-rendszerben és ezzel növelték a vízellátás helyreállításához szükséges időt. A vizsgálat során a támadók indítékait nem sikerült kideríteni.

Az incidens feltárása után a KWC és a Verizon szakemberei megszüntették a kapcsolódási lehetőséget az ügyfélmenedzsment rendszer és az AS400 között, majd miután a támadók további hozzáférési lehetőségeit blokkolták, újraépítették a kompromittált rendszereket. A Verizon javaslatot tett az elavult rendszerek cseréjére és a frissített rendszerek naprakész patch-elésére (az én tapasztalataim szerint a core ICS rendszerek esetén ez az egyik legnehezebb feladat, elérni azt, hogy újabb verziójú szoftvereket és biztonsági frissítéseket lehessen alkalmazni). Ugyancsak javasolták, hogy az egyetlen AS400 adminisztrátor kérdését is rendezze a KWC, hiszen ez a helyzet nem csak logikai biztonsági, hanem jelentős üzembiztonsági kockázatokat is képvisel.

A Verizon esetleírása számos tanulságos pontot mutat be. Ahogy arról már többször írtam, az ICS biztonság területén általános probléma, hogy a különböző ICS rendszerek nagy része közvetlen Internet-kapcsolattal rendelkezik, ahol pedig nem, ott olyan szervereknek vagy munkaállomásoknak van ICS/SCADA-hozzáférésük, amelyek Internet-eléréssel is rendelkeznek. Ez önmagában is jelentős kockázatokat hordoz, de azzal a ténnyel együtt, hogy az ICS rendszereket (és gyakran bizony az ICS rendszerekhez kapcsolódó kiegészítő rendszereket sem) nem patch-elik rendszeresen, ezek a kockázatok nagyságrendekkel nagyobbak lesznek. Ahogy a KWC-t érintő incidens is megmutatja, ezek a kockázatok valósak és az ICS rendszereket üzemeltetőknek esetenként fogalmuk sincs arról, hogy a támadók már hetek vagy hónapok óta hozzáféréssel rendelkeznek a legfontosabb rendszereikhez.

Az ICS rendszerek biztonsága esetén számos egyéb hiányosság is általánosnak tekinthető, így a KWC incidensben is jelentős szerepe volt annak, hogy a kritikus eszközöket nem szeparálták el megfelelően a hálózat más részeitől és nem alkalmaztak erős illetve több faktoros authentikációs megoldásokat.

Mit lehet tenni annak érdekében, hogy az ICS rendszereket ne tudják úgy kompromittálni, mint a KWC rendszereit? Számos olyan módszert lehet alkalmazni, amelyek megfelelő kombinálásával jelentősen lehet javítani az ICS rendszerek biztonságát, azonban egyenként nem fognak megoldást jelenteni.

1. Az ICS rendszereket és eszközöket a lehető legnagyobb mértékben el kell szeparálni a hálózat többi szegmensétől.

2. Meg kell szüntetni az ICS rendszerek közvetlen vagy közvetett Internet-kapcsolatát. Alapszabályként kell kezelni, hogy olyan számítógépnek, aminek Internet-elérése van, nem lehet hozzáférése az ICS-rendszerekhez.

3. Erős, lehetőleg több faktoros azonosítást kell bevezetni az ICS rendszerek felhasználói számára.

4. Mélységi védelmet (defense-in-depth) kell kialakítani a vállalati és az ICS rendszerek körül és olyan riasztási mechanizmusokat kell beépíteni a rendszerbe, amelyekkel a lehető leghamarabb fel lehet fedezni a támadók tevékenységeit.

5. Kiemelkedően fontos az ICS rendszerekkel bármilyen kapcsolatba kerülő emberek (fejlesztők, projekt- és felsővezetők, felhasználók, üzemeltetők) biztonságtudatossági képzése, hogy mindannyian ismerjék és értsék azokat a kockázatokat, amelyek a leginkább fenyegetik az ipari rendszereket. Ugyanilyen fontos, hogy az IT biztonsági szakembereket képezni kell, hogy megismerjék az ICS rendszerek sajátosságait, enélkül gyakran előfordulhat, hogy az IT biztonsági szakterület olyan javaslatokat tesz, amik az ICS rendszerek funkcionalitását fogja gátolni, ami abból adódik, hogy számos ipari rendszert az átlagos informatikai rendszerektől eltérő módon működnek.

A sors furcsa fintora, hogy a Verizon összefoglalója után néhány nappal Brian Krebs blogbejegyzése nyomán számos helyen arról cikkeztek a szaksajtóban, hogy támadók 1,5 millió ügyfél adatati lopták el a Verizon Enterprise rendszereinek feltörésével és ezeket árulják a DarkNet-en.

Az ICS-CERT tegnap nyilvánosságra került bejelentése szerint Maxim Rupp directory traversal hibát talált az ICONICS nevű amerikai ICS fejlesztő cég WebHMI nevű termékének 9-es és korábbi verzióiban.

A hiba a CVSS v3 besorolás alapán 9.8 pontot kapott, vagyis kiemelkedően súlyos hibának tekintik, amit távolról is ki lehet használni. A hibát kihasználva a támadó olyan konfigurációs fájlokhoz is hozzáférhet, amikben a rendszer paramétereit is megváltoztathatja, illetve elérheti a felhasználói jelszavak hash-eit is.

A gyártó a 10-es verzióban javította a hibát, az ügyfelek az új verziót az ICONICS weboldalán érhetik el: http://www.iconics.com/Home/Products.aspx

Azon felhasználók számára, akik nem tudnak frissíteni a sérülékeny verziókról, az ICONICS és az ICS-CERT több intézkedést javasolnak, amelyek alkalmazásával csökkenteni tudják a sérülékenységek negatív hatásait:

- 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 még március 29-én tette közzé a CareFusion Pyxis SupplyStation System nevű ICS rendszerében Billy Rios és Mike Ahmadi független biztonsági szakértők által felfedezett sérülékenységeket.

A sérülékenység az alábbi verziókat érinti:

- Pyxis SupplyStation system, Version 8.0 Server;
- Pyxis SupplyStation system, Version 8.1.3 Server;
- Pyxis SupplyStation system, Version 9.0 Server;
- Pyxis SupplyStation system, Version 9.1 Server;
- Pyxis SupplyStation system, Version 9.2 Server;
- Pyxis SupplyStation system, Version 9.3 Server.

A felsorolt, sérülékenység által érintett verziók mindegyik Windows Server 2003 és Windows XP operációs rendszereken fut. A CareFusion szerint a Windows Server 2008/2012 és Windows 7 operációs rendszerekre telepített 9.3-as, 9.4-es és 10.0-ás Pyxis SupplyStation system verziókat nem érinti a felfedezett hiba.

A hiba által érintett szoftver-verziók mind elérték már életciklusuk végét, így nem fognak hibajavítást kapni, a gyártó olyan intézkedéseket javasol a sérülékeny verziót használó ügyfeleinek, amikkel a kockázatokat csökkenteni lehet.

További részleteket az ICS-CERT bejelentése tartalmaz.

Az ICS rendszerek biztonsága nagyjából a Stuxnet óta téma az IT biztonsági szakmában. Bár sokan (különösen az ICS rendszerek üzemeltetői) még ma sem szívesen ismerik el nyilvánosan, hogy a különböző ipari IT rendszerek biztonsága bizony a gyengétől a katasztrofálisig terjed. A mai posztban a PLC-k gyenge biztonságának okait fogom (legalább részben) áttekinteni.

Történetileg a az első PLC-k kifejlesztése és üzembe helyezése az 1960-as évek elejére tehető. Ekkoriban kezdett elterjedni az a megoldás, hogy a különböző reléket PLC-kre cserélték. Ennek több oka is volt, a relék paneljeit nehéz volt módosítani, nem lehetett hatékonyan karbantartani és komoly kihívás volt a különböző problémákat diagnosztizálni, a már beazonosított hibák javítása pedig még ennél is nehezebb volt.

Bár a PLC-k ma már számos iparágban nélkülözhetetlen eszközök, a '60-as években először a különböző gyártósorok automatizálása során kerültek a relék helyére, majd innen terjedtek el a legkülönbözőbb iparágakban. Eleinte a PLC-k egy teljesen izolált környezetben működtek és csak a 70-es évek közepén, a kommunikációs eszközök rohamos fejlődésével kezdődött meg az összekapcsolásuk más eszközökkel. A különböző PLC-felhasználó vállalatok gyorsan ráébredtek, hogy a PLC-kből kapott adatok mennyire hasznosak tudnak lenni a folyamatok hatékonyságának és pontosságának monitorozásában és az összekapcsolt PLC-k jelentősen segítették a munkafolyamatok biztonságának (safety) és a rendszer megbízható működésének fejlesztését is.

Ahogy a PLC-ket használó vállalatok nőttek és az informatika fejlődött, úgy jelentek meg az újabb és újabb ipari és vállalati rendszerek, amiknek az összekapcsolása fontos üzleti/műszaki igényként jelentkezett (pl. a termelő vállalatok költség-optimalizálása miatt elengedhetetlen volt, hogy egy helyen lássák a termelési adatokat, a megrendeléseket és a beszállítóktól érkező alkatrészek beérkezésének ütemezését, stb.), hogy a PLC-ket olyan rendszerekkel is összekapcsolják, amelyekhez korábban nem készültek interfészek sem.

Ahogy arról korábban már írtam, a PLC-knek, mint minden ICS rendszernek, a normál IT rendszereknél sokkal (nem ritkán 5-6-szor) hosszabb az élettartama, egyáltalán nem ritka a 15-20 éve működő ICS rendszer, amin időközben csak kisebb fejlesztéseket hajtottak végre, esetleg egyszer volt operációs rendszer és/vagy adatbázis verzió-váltás (termelő vállalatoknál még ma sem ritkaság, hogy Windows NT 4.0 alapú rendszer vezérli a gyártósorokat). A PLC-k esetében még ennél is hosszabb lehet az élettartam, hiszen erősen célrendszerként lettek megalkotva, az alapvető követelmények pedig nem vagy nem nagyon változtak az évtizedek során. Azonban a több évtizedes eszközök azt is magukban hordozzák, hogy az erőforrások 10-20 évvel ezelőtt a mainak a töredékét sem érték el (ha belegondolunk, hogy 1999-ben még 300-800 MHz-es CPU-kat és 64-256 MB memóriát használó számítógépekkel dolgoztunk, el lehet képzelni, hogy a 20-25 éves PLC-kben milyen microprocesszor és mennyi memória lehet). Emiatt (különösen a régi PLC-k esetén) az utólagos funkcióbővítések nem vagy csak nagyon korlátozottan lehetséges.

20-25 évvel ezelőtt a kiberbiztonság az ICS rendszerek esetében ismeretlen témának számított. Ha valaki mégis szóba hozta, annak minden esetben kész válasszal szolgáltak, mely szerint az ICS rendszerek hálózata az egyéb hálózati zónák felől nem elérhető, így nincs ok az aggodalomra - ma már persze világos, hogy ez az állítás már a 90-es években sem állta meg a helyét, de akkor legalább az ICS rendszereknek még nem volt közvetlen vagy közvetett módon Internet-kapcsolata. Ezekből a (tév)hitekből merítve erőt, a legtöbb PLC- (és ICS-) felhasználó cég és szakember bátran támogatta az ipari rendszerek összekapcsolását más rendszerekkel. Ahol valaki (jellemzően a régi vágású ICS-üzemeltetők) ellenezte volna az ilyen összekapcsolásokat, ott az ő ellenállásukat az üzleti igények vagy jogszabályi előírások emlegetésével söpörték félre a döntéshozók (akik jellemzően üzleti vagy jogalkotói területről érkeztek és természetesen közük nem volt az ICS üzemeltetés vagy biztonság témájához).

Hogyan lehetne biztonságosabb PLC-ket létrehozni?

Már többször írtam róla, hogy az ICS rendszerek biztonságát véleményem szerint az emberi gondolkodáson és hozzáálláson keresztül lehetne a leginkább hatékony módon fejleszteni, a PLC-k esetén ezt elsősorban két csoport speciális biztonságtudatossági képzésén keresztül lehet elérni.

Elsőként a tervezésben és fejlesztésben résztvevő szakembereknek kéne a funkcionális követelmények mellett a biztonsági szempontokat is beépíteni a PLC-tervezés és fejlesztés folyamatába. A tervezést egy kockázatelemzéssel lenne célszerű kezdeni. Ennek során többek között fel kéne mérni a PLC-knél alkalmazott különböző hozzáférési módszerek és eszközök alkalmazása jelentette kockázatokat és a túl nagy kockázatokat jelentő tényezők (pl. Telnet, RSH, rexec, stb.) használatát el kell vetni vagy olyan kontrollokat kell a használatukkal kapcsolatban beépíteni a PLC-kbe, amelyekkel az ilyen hozzáférések kockázatai elfogadható szintre csökkenthetőek.

A fejlesztőknek és az üzemeltetőknek is el kell sajátítaniuk az "ellenség fejével gondolkodás" képességét, azt is végig kell gondolniuk, hogy ők maguk hogyan szereznének jogosultságot a saját rendszerükben, ha a szabályos módszereket és útvonalakat nem használhatnák. Ezzel nyilván nem sikerülne nullára csökkenteni egy támadó lehetőségeit a PLC kompromittálására, de a leginkább kézenfekvő és egyszerű támadási vektorok nagy valószínűsséggel ilyen módon megszüntethetőek lesznek.

Természetesen egyetlen megoldási lehetőség sem fogja varázsütésre megoldani az ICS biztonsági problémákat, ahogy az IT biztonságban sincs olyan csodafegyver, aminek megvásárlása/kifejlesztése egy csapás megszüntetné az adatlopásokat. Az ICS rendszerek biztonságát csak a megfelelő biztonsági eszközök (technikai eszközök, szabályzatok, biztonságtudatossági képzések és modern, a biztonsági szempontokat is megfelelő szinten kezelő fejlesztési és üzemeltetési eljárások, ICS biztonsági szabványok) egyidejű alkalmazásával lehet az elvárt szintre emelni, majd ezt a szintet fenntartani.

Az ICS-CERT által tegnap megjelentetett figyelmeztetésben Steven Seeley, a Source Incite munkatársa által felfedezett hibáról számol be. A sérülékenység a Cogent DataHub 7.3.9-es és ennél korábbi verzióit érinti. A hibát kihasználva korlátozott (user vagy guest) jogosultsággal rendelkező felhasználók egy számukra is módosítható fájlt megfelelően szerkesztve system jogosultságot tudnak szerezni. A hibát távolról és legitim felhasználói interakció nélkül nem lehet kihasználni, azonban egy támadó akár már alacsonyabb tudással is képes lehet olyan exploitot írni, amellyel ki lehet használni a sérülékenységet, ha rá tudja venni a felhasználót, hogy töltse be a megfelelően formázott fájlt.

A Cogent a hibát a 7.3.10-es verzióban javította, ami minden, 7-es főverziót használó ügyfele számára ingyenesen elérhető a http://www.cogentdatahub.com/Download_Software.html weboldalon.

Az ICS-CERT ebben a bejelentésében is hangsúlyozza azoknak a kockázatcsökkentő intézkedéseknek a fontosságát, amiket én is minden ilyen bejelentés kapcsán idézek:

- csak megbízható szoftvereket, patch-eket használjanak;
- alkalmazzanak antivirus/antimalware szoftvereket;
- csak megbízható weboldalakat és csatolmányokat nyissanak meg;
- tartsanak biztonságtudatossági képzéseket a munkatársaknak, hogy minél hatékonyabban ismerjék fel az adathalász és social engineering támadásokat;
- minimalizálják az ICS rendszerek és eszközök kockázatait, rendszeresen ellenőrizzék, hogy az ilyen eszközök és rendszerek nem érhetőek el az Internet irányából;
- ICS rendszerekhez csak VPN használatával biztosítsanak távoli hozzáférést, figyelembe véve, hogy az VPN-megoldásokban is lehetnek hibák és hogy minden VPN-kapcsolat csak annyira biztonságos, mint az ezen keresztül csatlakoztatott végponti eszköz.

Az ICS-CERT március 22-én publikálta a Siemens által március 18-án nyilvánosságra hozott, APOGEE Insight épületüzemeltetési rendszerben felfedezett sérülékenységet. A hibát a Network & Information Security Ltd. Company and HuNan Quality Inspection Institute fedezte fel és jelentette a Siemens-nek. A sérülékenység az APOGEE Insight minden verzióját érinti. Az APOGEE Insight-ot futtató operációs rendszerbe sikeresen bejelentkezett felhasználó a rendszer könyvtárain hibásan implementált engedélyeket kihasználva képes lehet a rendszerben tárolt adatok jogosulatlan módosítására.

A sérülékenységet az ICS-CERT nem értékeli súlyosnak, részben mert távolról vagy sikeres operációs rendszer szintű authentikáció nélkül nem lehet kihasználni.

A gyártó jelenleg is dolgozik a hibát javító verzión, ám az egyelőre nem érhető el az ügyfeleknek. A Siemens a sérülékenység hatásainak csökkentésére részletes útmutatót ad azoknak az ügyfeleinek, akik ezt kérik tőlük.

Az ICS-CERT ezúttal is szolgál néhány tanáccsal az ICS rendszereket használó szervezeteknek, amelyekkel azok csökkenteni tudják az ilyen sérülékenységek kihasználásának kockázatait:

- Limitálni kell a felhasználók hozzáférését a számukra valóban szükséges számítógépekre;
- Szegmentált hálózatokat kell használni az ipari rendszerek esetében is;
- Szigorúan kontrollálni kell, hogy a felhasználók milyen programokat futtathatnak;
- A felügyelet nélküli számítógépeket zárolni kell.

További részleteket az ICS-CERT oldalán lehet olvasni a sérülékenységről.

Az ICS-CERT március 17-i bejelentése szerint az ABB Panel Builder 800 termékének 5.1-es verziójában Ivan Sanchez, a Nullcode Team munkatársa DLL hijacking sérülékenységet fedezett fel.

A hibát kihasználva egy támadó tetszőleges kódot illeszhet be és futtathat a sérülékeny rendszereken. A hiba alapja a nem megfelelő DLL-hívás alkalmazása, abban az esetben, amikor egy alkalmzás teljes elérési út nélkül hivatkozik egy DLL-re, a Windows számos helyen kezdi keresni a DLL-t.

A gyártó a Panel Builder 6.0-ás verziójára történő frissítést javasolja javításként. Amennyiben erre nincs lehetőség, az 5.1-es verzióban workaround-ként el kell távolítani a szoftver .pba kiterjesztű fájlokhoz történt társítását, ami a hibát ugyan nem szünteti meg, de képes blokkolni az ismert támadási vektorokat.

További részleteket és a szokásos, általános ICS biztonsági tanácsokat az ICS-CERT bejelentése tartalmaz.

A Siemens ma publikált bejelentése alapján Maik Brüggemann és Ralf Spenneberg sérülékenységet találtak a már nem támogatott SIMATIC S7-1200v3 és ezt megelőző firmware verziókban.

Frissítés: Az ICS-CERT által a sérülékenységről készített összefoglalóban a Siemens bejelentésénél több részlet található a hibáról, ennek alapján a hibát kihasználva egy támadó megkerülheti az érintett verziójú firmware-ekbe épített user program block protection mechanizmust és ezt akár távolról is meg lehet tenni.
 
A gyártó a termékcsalád V4.0 és ennél újabb firmware verzióira történő frissítést javasolja minden ügyfelének. Azok számára, akik ezt bármilyen oknál fogva nem tehetik meg, javaslom az ICS-CERT ipari rendszerek biztonságosabbá tételére vonatkozó ajánlásait:

- 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!