Az ICS-CERT  tegnap publikált a Rockwell Automation FactoryTalk EnergyMetrix nevű termékével kapcsolatos legújabb sérülékenységeket. A hiba az alábbi verziókat érinti:

- FactoryTalk EnergyMetrix, Version 2.10.00 és korábbi verziók.

A FactoryTalk EnergyMetrix egy webes felületű menedzsemnt szoftver, amit energiaadatok gyűjtésére, elemzésére, tárolására és megosztására használnak számos iparágban, többek között vegyipari, kereskedelmi, energetikai és viziközmű vállalatok is.

A hibák között egy SQLi és egy nem megfelelő munkamenet lejárat-kezelés is található.

A gyártó a hibákat a Version 2.30.00 verzióban javította, ami a rockwellautomation.com weboldalon, authetnikáció után érhető el az ügyfelek számára: http://compatibility.rockwellautomation.com/Pages/MultiProductDownload.aspx?famID=1&crumb=112

A verziófrissítés mellett a Rockwell Automation további kockázatcsökkentő intézkedések bevezetését javasolja ügyfeleinek:

- Bizonyosodjanak meg arról, hogy az érintett rendszerekben alkalmazzák a minimális jogosultságok elvét humán és szervíz felhasználói fiókoknál egyaránt;
- A FactoryTalk EnergyMetrix sezrverek konfigurálják be a https használatát, amivel biztosítható a böngésző és a szerver között forgalmazott adatok bizalmassága és sértetlensége;
- Csak megbízható szoftvereket és javítócsomagokat használjanak, valamint alkalmazzanak antivirus/antimalware megoldást! Csak megbízható weboldalakat és csatolmányokat nyissanak meg;
- Biztonsági és biztonságtudatossági képzésekkel fokozzák a felhasználók biztonsággal kapcsolatos tudását, így segítve, hogy felismerjék az adathalász és social engineering támadásokat;

A gyártó tanácsain túl az ICS-CERT a szokásos kockázatcsökkentő intézkedések alkalmazását javasolja:

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

További információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-173-03

Az ICS kiberbiztonság egyesek szerint két jelentős ok miatt más, mint az általános IT biztonság, az első az ipari rendszerek által használt egyedi protokollok, a második pedig a gyakran 15 évnél is régebbi végponti célrendszerek (PLC-k, RTU-k és egyéb ipari végponti berendezések) nagy számban történő alkalmazása.

Az ICS rendszerek kiberbiztonságának helyzetét részben az általuk használt kommunikációs protokollok biztonságának javításával lehet előre mozdítani, erről tartott nemrég egy webes előadást Erik Schweigert (Belden) és Joel Langill (SCADAhacker.com), ahol a DNP3 ICS protokoll biztonsági kérdéseivel foglalkoztak. Az előadás teljes terjedelmében itt érhető el (regisztrációt igényel): http://www.globalspec.com/events/eventdetails?eventid=1121&evtsrc=519Blog Bár a DNP3 protokoll használata Európában és Magyarországon nem jellemző, az előadás szerintem mégis érdekes és hasznos gondolatokat tartalmaz.

Az előadás fontosabb gondolatai az alábbiak:

A DNP3 (és a DNP3 helyett Európában meghatározó 104-es protokoll, IEC 60870-5-104) nagyon jó alacsony sávszélességgel rendelkező WAN hálózatokon történő kommunikáció stabil működésének biztosítására, emiatt széles körben használják a villamosenergia, kőolaj és földgáz szektorokban.

A DNP3 (hasonlóan a Modbus-hoz) tervezési okokból nem vizsgálja az egyes hálózati üzenetek legitimitását, vagyis egy alállomási eszközből érkező (a központi rendszer által nem kért) üzenettel könnyedén lehet üzemzavart előidézni. Ilyen volt a Marochy-Shire csatornarendszerben történt incidens, amikor egy hamis alállomási eszközről a felügyeleti rendszerbe érkezett üzenet hatására 1.000.000 liter szennyvíz került leeresztésre a rendszerből.

A beágyazott szoftvereket futtató eszközöket nem lehet host-alapú biztonsági eszközökkel megvédeni, általánosan kevés olyan  kontroll van, amit úgy lehet az ipari végponti berendezések biztonságának növelése érdekében alkalmazni, hogy az ne legyen hatással az eszköz alapvető funkcionalitására, teljesítményére és válaszidejére (elég csak a nemrég publikált Moxa sérülékenységre gondolni, amit a gyártó nem tud javítani egy egyébként még három évig támogatott eszközön, mert a patch forráskódja már nem fér el a rendszerben). Emiatt az ipari berendezések preventív műszaki kontrollját biztosító megoldásokat jellemzően az ipari hálózatok határvédelmében szokták alkalmazni.

Az ICS biztonság nem kizárólag a támadókról és a tevékenységük által jelentett fenyegetésekről szól, legalább ennyire fontos a megbízhatóság is (ahogy erről korábban már én is írtam). Az előadásban három olyan ICS incidenst mutatnak be, amiket nem malware-ek váltottak ki, de komoly üzemzavarokat okoztak az energiaszektorban és autógyártásban érdekelt cégeknél. Az előadásban külön kiemelik, hogy azokat a 15-25 éves ipari berendezéseket, amiket még jóval az Internet széleskörű elterjedése előtt terveztek és gyártottak, hogyan kell megvédeni a ma már mindennapos támadásoktól és az olyan hálózati forgalomtól, amit ezek az eszközök nem tudnak tolerálni.

Az előadásban egy nagyon jó animált hálózati diagramon bemutatják, hogy egy malware hogyan képes megkerülni egy erőművi ipari hálózatot védő tűzfalat és hogy egy hálózati eszköz meghibásodása hogyan idézheti elő PLC-k egy csoportjának kiesését. Ezek a példák igen jól bemutatják az ICS eszközök biztonságának kihívásait.

Az IEC 62443 (Zones and Conduits model) alapján bemutatják, hogyan kell hatékony mélységi védelmet kialakítani ICS rendszerek esetén. Ipari tűzfalak használatával a végponti berendezések kommunikációs csatornáira alapuló védelmét lehet megvalósítani, így biztosítva az automatizálási rendszerek védelmét malware és véletlen hálózati meghibásodások okozta incidensek ellen. Az előadásban azt is kiemelik, hogy az IEC 62443 általában egy meglehetősen nehezen értelmezhető koncepció az IT szakemberek számára, mert a vállalati IT-ban nincs megfelelője. Arról is beszél, hogyan lehet az IEC 62443-at Windows XP-t futtató PC-k és beágyazott operációs rendszerű eszközök biztonságának fokozására.

Az előadás utolsó nagyobb szekciója a hálózati csomagelemzésről szól és bemutatja azt is, hogy miben különbözik a protokoll-alapú DPI a mintaillesztéses DPI-től.

Az előadásban ezután még szó esik arról, hogy miért kell egyszerűnek lennie az ICS biztonsági megoldások ICS üzemeltetők (Operations Technology, OT) általi implementációjának (én inkább azon a véleményen vagyok, hogy az ICS biztonság megfelelő szintjének elérése érdekében a legjobb eredményt az hozza, ha az IT biztonsági és OT szakterületek folyamatos együttműködésére és információcseréjére építünk).

A Siemens ProductCERT-en ma három termékkel kapcsolatban is hibajavításokkal kapcsolatos információk jelentek meg.

SIMATIC NET PC-Software

Vladimir Dashchenko, a Kaspersky Lab kritikus infrastruktúra védelmi csoportjának munkatársa talált egy DoS-támadást lehetővég tevő hibát a SIMATIC NET PC-Software V13 SP2-nél korábbi verzióiban. A hibát a sérülékeny szoftvert futtató eszközökön különböző ((55101/tcp – 55105/tcp, 4845/tcp, 4847/tcp – 4850/tcp) portjaira küldött, megfelelően kialakított csomagokkal lehet szolgáltatás-megtagadást előidézni az OPC UA szolgáltatásnál. A rendszer helyreállításához az érintett szolgáltatást újra kell indítani.

A gyártó a hibát a V13 SP2 verzióban javította.

További részleteket a vonatkozó bejelentés tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-453276.pdf

SIMATIC WinCC, PCS 7 és WinCC Runtime Professional

A SIMATIC WinCC termékcsalád több tagjában szintén a Kaspersky Lab kritikus infrastruktúra védelmi csoportjának munkatársai, Sergey Temnikov és Vladimir Dashchenko találtak sérülékenységeket. A hibák az alábbi termékeket és szoftververziókat érintik:

SIMATIC WinCC:
- V7.0 SP2 és korábbi verziók;
- V7.0 SP3 minden verziója;
- V7.2 minden verziója;
- V7.3 Update 10-nél korábbi verziók;
- V7.4 Update  1-nél korábbi verziók;

SIMATIC PCS7 (WinCC,  Batch,  Route  Control,  OPEN  PCS  7):
- V7.1 SP4 és korábbi verziók;
- V8.0 minden verziója;
- V8.1 minden verziója;
- V8.2 minden verziója;

SIMATIC  WinCC  Runtime  Professional:
- V13 SP1 Update 9-nél korábbi verziók.

A fenti termékekben egy authentikáció nélküli távoli kódfuttatást lehetővé tevő és egy authentikáció nélküli, tetszőleges fájl hozzáférést lehetővé tevő hibát azonosítottak.

A hiba javítását a Siemens az alábbi verziókban tette elérhetővé az ügyfeleinek:

- WinCC V7.3 esetén a WinCC V7.3 Update 10-ben;
- WinCC V7.4 esetén a WinCC V7.4 Update 1-ben;
- SIMATIC PCS7 V8.1 SP1 esetén:
   - WinCC V7.3 Update 10;
   - SIMATIC BATCH V8.1 SP1 Upd. 9;
   - OpenPCS 7 V8.1 Upd. 3;
- SIMATIC PCS 7 V8.2 esetén:
    - WinCC V7.4 Update 1;
    - OpenPCS7 V8.2 Update 1;
- WinCC  Runtime  Professional  V13 esetén a WinCC  Runtime  Professional V13 SP1 Update 9-ben.

A hibákkal kapcsolatban további információkat a Siemens bejelentése tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-378531.pdf

SINEMA Remote Connect Server

A SINEMA Remote Connect Server a Siemens által kínált VPN-megoldás ipari rendszerek biztonságos távoli elérés kialakításához, ebben a termékben találtak hibát Antonio Morales Maldonado, az Innotec Systems, valamint  Alexander Van Maele és Tijl Deneut, a Howest munkatársai.

A hibát kihasználva XSS-támadást lehet intézni a SINEMA Remote Connect Server V1.2-nél korábbi verziói ellen.

A hibát a Siemens a V1.2-es verzióban javította.

További információkat a Siemens ProductCERT oldalán elérhető bejelentés tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-119132.pdf

Szerk: tegnap megjelentek a fenti sérülékenységekkel kapcsolatos ICS-CERT publikációk is, amik itt érhetőek el:

SIMATIC NET PC-Software: https://ics-cert.us-cert.gov/advisories/ICSA-16-208-02
SIMATIC WinCC, PCS 7 és WinCC Runtime Professional: https://ics-cert.us-cert.gov/advisories/ICSA-16-208-01
SINEMA Remote Connect Server: http://icscybersec.blog.hu/admin/post/edit/8908482

A különböző forgalomszűrő eszközök (Layer-2 és Layer-3 ACL-ek, tűzfalak, IDS/IPS eszközök) használata mára az ICS rendszerek hálózataiban is elterjedtnek számít, az ICS-CERT rendszeresen ad olyan kockázatcsökkentést célzó tanácsokat, amelyek között az első az ipari rendszerek hálózatának publikus hálózatoktól történő szeparálását sürgeti.

A mai poszt a Belden Industrial blog-ján megjelent cikk alapján az ipari rendszereknél használt különböző forgalomszűrési módszereket fogja áttekinteni.

Csomagszűrés ACL-ek használatával

Az ACL-ek használata az IT hálózatokban több évtizedes múltra tekint vissza, mind a mai napig használják költséghatékony forgalomszűrésre olyan esetekben, amikor nincs lehetőség tűzfalak használatára.

Előnyük továbbá a nagyon gyors csomagszintű ellenőrzés, ami egyes valósidejű működésre épülő ipari rendszerek esetén az egyetlen elfogadható csomagszűrő eszközzé teszik az ACL-eket. Hátrányuk a nem állapottartó működés (vagyis nem képesek felismerni, hogy egy bejövő csomag egy kimenőre érkező válasz vagy fordítva), emiatt minden kapcsolat működéséhez két szabályt kell felvenni. Ez meglehetősen nagy ACL-eket eredményezhet, ami extrém esetekben azt eredményezheti, hogy a L2-L3 eszközök már CPU-ból próbálják végezni az alapvető routing feladatokat, ez pedig komolyabb teljesítményromlást eredményezhet.

Állapottartó csomagszűrés

Eredeti angol kifejezéssel stateful packet filtering (SPI), az egyik legalapvetőbb hálózati forgalomszűrő módszer, amire számos ipari környezetbe szánt eszköz épül, ilyen többek között a Hirschmann EAGLE tűzfalak vagy a Tofino Xenon Security Appliance-ek illetve ugyanerre a technológiára épül számos ipari hálózati eszköz, mint például a GarrettCom 5RX és 10RX sorozatú routerei vagy a Hirschmann OpenBAT vezeték nélküli hálózatokhoz használható AP.

Az SPI-alapú eszközök egyik legnagyobb előnye az ACL-ekkel szemben, hogy képesek felismerni a csomagok közül azokat, amelyek egy kimenő csomagra válaszul érkeznek, ezen az alapon tudják elhárítani azoknak a támadásoknak egy részét, amik a védendő hálózatot célozzák. Az SPI működéséből adódóan lassabb, mint az ACL, az ilyen módon működő eszközök már mérhető késleltetést okoznak a hálózati kommunikációban. Ipari környezetben történő használatuknál ezt a tényt minden esetben figyelembe kell venni még a tervezési fázisban.

Magas szintű csomagelemzés (Deep Packet Inspection - DPI)

Úgy az ACL-ek, mint az SPI-alapú eszközök biztosítanak bizonyos szintű védelmet az ipari rendszerek számára, azonban ezek sok esetben nem képesek megelőzni, hogy a támadók rossz szándékkal készített csomagokat juttassanak be az ipari rendszerek hálózatába. Az ACL vagy az SPI csak abban segít, hogy eldöntsük, egy adott kapcsolatot engedélyezünk vagy tiltunk, ennél alaposabb vizsgálatra egyik eszköz sem képes. Például ha ACL-ekkel vagy egy SPI-szabállyal engedélyezzük a forgalmat az HMI és egy PLC között azért, hogy az HMI-ról ki lehessen olvasni a PLC állapotát, egyúttal arra is lehetőséget biztosítunk, hogy programozási parancsokat adjanak ki ugyanarról az HMI-ról, ami komoly biztonsági problémákat okozhat. Egy bizonyos pontig ez a szintű védelem megfelelő lehet, de minél mélyebbre megyünk az ipari rendszerek hálózataiban (és elérjük a PLC-k és RTU-k és egyéb ipari eszközök szintjét), már ennél finomabban hangolható szabályrendszerre lesz szükség.

Erre találták ki a DPI-t, ami nem csak a csomagok fejléceit vizsgálják, hanem magát a csomag adattartalmát is ellenőrzik, így teszik lehetővé finomra hangolt szabályrendszer kialakítását. Az előző példával élve, ha egy DPI-eszközt megfelelően felparaméterezünk, az eszköz képes lehet arra, hogy a HMI-től a PLC-hez érkező olvasási utasításokat tartalmazó csomatokat átengedje, de a programozási utasításokat hordozó csomatokat blokkolja. A minta-illesztéses DPI-elemzéseknek természetesen megvan az ára, a nagyobb biztonságért cserébe nagyobb feldolgozási teljesítménnyel és nagyobb hálózati késleltetéssel kell fizetni. Ipari környezetbe szánt DPI-képes eszközből is többféle van, ilyen például a Tofino Xenon Security Appliance vagy az EAGLE 20/30 típusú tűzfalak.
A DPI-eszközök (különösen pedig a minta-illesztést alkalmazó DPI-megoldások) legnagyobb hátránya, hogy csak a már ismert fenyegetések ellen tudnak megfelelő védelmet nyújtani - hasonlóan a szignatúra-alapú víruskereső megoldásokhoz, amelyek hatásfokáról sokunknak vannak tapasztalatai.

A fent ismertetett megoldások egyike sem jelent újdonságot a vállalati hálózatok biztonságáért felelős szakembereknek, azonban ipari rendszerek esetén még ma sem magától értetődő, elég csak azt megnézni, hány ipari eszköz érhető el az Internetről. A különböző csomagszűrő megoldásokkal és egyéb biztonsági eszközökkel (valamint egyéb biztonsági megoldásokkal és a megfelelő eljárásokkal) ki lehet alakítani egy olyan mélységi védelmet, amely ha megakadályozni nem is tudja, hogy egy elszánt és megfelelő tudással és háttérrel rendelkező támadó bejusson az ipari rendszerek hálózatába, de hozzásegíthetnek ahhoz, hogy minél gyorsabban felismerhető legyen egy biztonsági incidens.

Ismét egy ICS sérülékenységekben gazdag napra ébredtünk, az ICS-CERT három ICS gyártó termékeivel kapcsolatban jelentetett meg különböző sérülékenységi információkat.

Schneider Electric Pelco Digital Sentry Video Management System

A Schneider Electric házon belül fedezett fel egy olyan beégetett jelszót, aminek megszerzésével egy támadó bizalmas információkhoz férhet hozzá és kódfuttatási jogokat szerezhet az érintett rendszereken. A hiba a Pelco Digital Sentry Video Management System Version 7.13 és korábbi verzióit érinti. A gyártó a hibát a 7.14-es verzióban javította, ami elérhető a www.pelco.com weboldalon.

További részleteket a hibáról az ICS-CERT bejelentése és a Schneider Electric hibával kapcsolatban kiadott közleménye tartalmaz.

Moxa MGate sérülékenység

A már sokszor emlegetett Maxim Rupp ezúttal a Moxa MGate termékeiben fedezett fel authentikáció megkerülését lehetővé tevő sérülékenységet. A hiba az alábbi termékeket és firmware-verziókat érinti:

- MGate MB3180, v1.8-nál régebbi firmware használata esetén;
- MGate MB3280, v2.7-nél régebbi firmware használata esetén;
- MGate MB3480, v2.6-nál régebbi firmware használata esetén;
- MGate MB3170, v2.5-nél régebbi firmware használata esetén;
- MGate MB3270, v2.7-nél régebbi firmware használata esetén.

A gyártó minden érintett típushoz új verziójú firmware-t tett elérhetővé, amikben javították a hibát. További információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-196-02

Schneider Electric SoMachine HVAC sérülékenység

Andrea Micalizzi a Schneider Electric SoMachine HVAC rendszerében talált egy ActiveX vezérlővel kapcsolatos hibát, amit a ZDI-n keresztül jelentett a gyártónak. A hiba a SoMachine HVAC-Application 2.0.2 és ennél korábbi verzióit érinti. A Schneider Electric elérhetővé tette a hibát javító patch-et, ami a termék weboldalán érhető el.

A hibával kapcsolatban részletes információk az ICS-CERT bejelentésében és a gyártó weboldalán érhetőek el.

Philips Xper-IM Connect sérülékenységek

Az igazán szép találat a végére maradt. Mike Ahmadi, a Synopsys és Billy Rios, a Whitescope LLC munkatársai a Philips-szel együttműködve 460 különböző sérülékenységet fedeztek fel az Xper-IM Connect Windows XP operációs rendszeren futó, 1.5.12 és korábbi verzióiban. A hibák közül 100 a CVSS alapján közepes (4.0-6.9), 360 pedig magas vagy kritikus (7.0-10.0) besorolást kapott. A hibák mindegyike a következő öt kategória egyikébe sorolható:

- kód befecskendezés;
- erőforrás-kezelési hiba;
- információ-szivárgás;
- numerikus hiba;
- pufferen belüli nem műveletkorlátozás.

A gyártó a hibákkal kapcsolatban azt javasolja a felhasználóknak, hogy frissítsenek az 1.5 Service Pack 13 verzióra, ami a már évek óta nem támogatott Windows XP helyett Windows Server 2008R2-re épül.

A hibával kapcsolatban további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-16-196-01

A most közzétett hibákhoz kapcsolódóan is a már ismert biztonsági intézkedések fontosságát hangsúlyozza az ICS-CERT:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi 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!

Még július 12-én az ICS-CERT két, ICS rendszerek sérülékenységeiről szóló bejelentést publikált.

GE Proficy HMI SCADA CIMPLICITY

Zhou Yu, az Acorn Network Security munkatársa egy jogosultságkezelési hibát talált a GE Proficy HMI SCADA CIMPLICITY nevű termékében. A hiba a CIMPLICITY Version 8.2, SIM 26 és korábbi verzióit érinti.

A hiba sikeres kihasználásával egy authentikált felhasználó képes lehet módosítani a rendszer konfigurációját és tetszőleges végrehajtható állományt futtathat. A hibával kapcsolatban a gyártó egy bejelentést tett közzé, valamint javasolja a sérülékeny verziókat futtató ügyfeleinek a Proficy HMI/SCADA–CIMPLICITY, Version 8.2, Sim 27 verziójú vagy újabb (a legutolsó elérhető verzió a CIMPLICITY Version 8.2 SIM 43) firmware-re történő frissítést.

A hibával kapcsolatos ICS-CERT bejelentés itt olvasható: https://ics-cert.us-cert.gov/advisories/ICSA-16-194-02

Tollgrade Smart Grid EMS LightHouse

Ashish Kamble, a Qualys munkatársa a Tollgrade Communications Smart Grid LightHouse Sensor Management System nevű termékében fedezett fel több sérülékenységet. A hibák a LightHouse SMS, Version 5.1, Patch 3-nál korábbi verziókat érintik.

A hibák között található kritikus funkcióhoz történő, authentikáció nélküli hozzáférés, információszivárgás a hibaüzenetben és nem megfelelő jogosultságkezelés.

A gyártó a hibákat a LightHouse SMS, Version 5.1, Patch 3 verzióban javította. A sérülékeny verziót használó ügyfeleknek azt javasolják, lépjenek kapcsolatba a Tollgrade support csapatával.

A Tollgrade support elérhetőségei és a hibákkal kapcsolatos részletes információk az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-16-194-01

Az ICS-CERT ezen túlmenően a szokásos kockázatcsökkentő intézkedéseket javasolja:
- 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 SentinelOne, egy izraeli kiberbiztonsági cég munkatársai egy olyan malware-t találtak a DarkWeb egyik fórumán, ami a vizsgálatok alapján feltételezhetően egy európai villamosenergia-szektorban működő szervezet elleni támadáshoz lett fejlesztve. A kutatók feltételezései szerint a Furtim idén május óta lehet aktív és két ismert exploit-ot (CVE-2014-4113 és CVE-2015-1701), valamint UAC-megkerülési technikát is alkalmaz. A malware fejlesztői jelentős erőfeszítéseket tettek annak érdekében, hogy ne csak a hagyományos antivirus és modern (next-gen) tűzfal-termékekkel ne lehessen észlelni az általuk fejlesztett malware-t, de a különböző sandbox-okat (pl. GFI, Joe Sandbox) is nagyon hatékonyan képes észlelni és ilyen környezetekben inaktív marad. Még érdekesebb a kutatóknak az a feltételezése, hogy a malware-t olyan létesítmény vagy létesítmények ellen tervezték, ahol nem csak a szoftveres, de a fizikai védelem szintje is magas. Ha a malware a ZKTeco nevű globális fizikai biztonsági rendszereket (arcfelismerő, ujjlenyomat olvasó és RFID rendszereket) gyártó cég szoftverét észleli a célba vett számítógépen, azonnal leállítja a működését, mivel ezeket a rendszereket az üzemeltetőik jellemzően szigorú felügyelet alatt tartják, így egy malware-fertőzés valószínűleg nem maradna észrevétlen.

A malware alacsony szintű API-kat (Nt* és Rtl*) és közvetlen rendszerhívásokat (INT 2Eh és CALL ntdll!KiFastSystemCall) használ, így kerülve el, hogy  antivirus szoftverekkel vagy sandbox-okkal felfedezzék. A SentinelOne munkatársai szerint ezeknek az eszközöknek a használata egyértelműen bizonyítja, hogy a Furtim fejlesztői igen alapos ismeretekkel rendelkeznek a Windows Driver Developement Kit használatával kapcsolatban. Az indirekt szubrutin hívások használatával a statikus manuális elemzéseket tették gyakorlatilag lehetetlenné, a dinamikus elemzések pedig fájdalmasak és lassúak. A kutatók által vizsgált malware-minta végső célja (a célba vett rendszeren talált antivirus szoftver csendes eltávolítása után) a lényegi kódjának futtatása.

A malware-t vizsgáló kutatók egyebek mellett ezek alapján azt feltételezik, hogy a fejlesztők mögött egy nemzetállam állhat, feltételezéseik szerint Kelet-Európából. Arról egyelőre nincsenek pontosabb információk, hogy milyen villamosenergia-ipari szervezettel kapcsolatban fedezték fel a Furtim-ot, azonban az európai villamosenergia-hálózattal kapcsolatban egyre gyakrabban látnak napvilágot különböző súlyú kiberbiztonsági incidensek és fenyegetések, amik nem ígérnek sok jót a jövőre nézve.

Az SFG/Furtim részletes elemzését a SentinelOne weboldalán lehet elolvasni: https://sentinelone.com/blogs/sfg-furtims-parent/

A SentinelOne elemzése nyomán számos biztonsági híroldal hozta le a saját összefoglalóját:

http://www.theregister.co.uk/2016/07/12/scada_malware/
http://securityaffairs.co/wordpress/49332/cyber-warfare-2/government-malware-dark-web.html
https://www.helpnetsecurity.com/2016/07/13/malware-backdoor-critical-infrastructure-targets/
http://thehackernews.com/2016/07/scada-malware-energy.html

Szerk: Robert M. Lee gondolatai a SentinelOne elemzéséről és a szakmai reakcióiról.

Július 11-én a Kaspesky Lab Security Intelligence csapata két PDF-et publikált. Az elsőben az ICS rendszerek rendelkezésre állási statisztikáit, a másodikban az ICS sérülékenységek statisztikáit összegezték. A mai posztban ezeket fogom röviden áttekinteni, illetve az ICS sérülékenységi adatoknál a saját, 2016-ra vonatkozó gyűjtéseimmel kiegészíteni.

A Kaspersky kutatása alapvetően a nyílt forrású adatokra (Open Source Intelligence, OSINT) és publikusan elérhető információkra (pl. ICS-CERT publikációk, különböző ICS gyártók publikációi, stb.) épített és a 2015-ös évre fókuszált.

Annak ellenére, hogy az ICS biztonság területén a mai napig alapvetésnek számít, hogy ipari eszközöket és rendszereket ne csatlakoztassunk az Internetre, a kutatók több, mint 188 ezer ICS eszközt (és ezekben több, mint 220 ezer ICS komponenst) találtak az Interneten keresve (ez egyáltalán nem tűnik nehéz feladatnak, pl. a Shodan keresőjét használva). Az Interneten elérhetó ICS eszközök a világ 170 országában üzemelnek, vagyis globálisan létező rossz gyakorlatról beszélhetünk, azonban első helyen az USA áll (a kutatás során vizsgált ~13 ezer rendszer 30,5%-a itt üzemel). Európában az első helyen Németország (13,9%-kal), a második helyen Spanyolország (5,9%-kal), a harmadik helyen pedig Franciaország (5,6%-kal) áll (Magyarország a Top20-as listán nem szerepel).

A legtöbb, Interneten elérhető ICS rendszer az alábbi 10 gyártó termékei közül kerül ki:

1. Tridium (24446)
2. Sierra Wireless (17908)
3. Beck IPC (14837)
4. Digi International (12367)
5. SMA (11904)
6. Siemens (11232)
7. Moxa (11208)
8. HMS Industrial Networks AB (7680)
9. Lantronix (7533)
10. Westermo (5908)

Az ICS rendszerek komponensei közül a legtöbb sérülékenységet az alábbi 5 kategóriában találták:

1. ICS hálózati eszközök (61355)
2. PLC-k (33080)
3. SCADA rendszerek (22624)
4. Inverterek (19530)
5. HMI-k (15549)

Szintén régóta ismert probléma, hogy a legtöbb ipari rendszerek elavult és/vagy titkosítás nélküli protokollokat használ, ami tovább növeli az egyébként sem alacsony kockázatokat. A Kaspersky kutatási eredményei is mutatják, hogy a legnagyobb számban használt, problémás protokollok között még mindig túlsúlyban vannak a nem ICS-specifikus (vagyis elvileg könnyebben biztonságosabbra cserélhető) protokollok:

1. HTTP (116900)
2. Telnet (29586)
3. Niagara Fox (20622)
4. SNMP (16752)
5. Modbus (16233)

A Kaspersky kutatásából az is nagyon jól látszik, hogy a Stuxnet 2010-es nyilvánosságra kerülése után alig másfél év kellett ahhoz, hogy az ICS rendszerekben felfedezett sérülékenységek megtízszereződjenek. Ez a szám az azóta eltelt években sem csökkent számottevően, jellemzően 150 és 190 közötti sérülékenységet találnak a gyártók és kutatók minden évben a különböző ICS rendszerekben (ebből a szempontból várhatóan a 2016-os év sem fog javulást hozni, már amennyire ezt a saját gyűjtésem alapján látom, az év első 6 hónapjában 66 különböző bejelentésben 135 ICS sérülékenység jelent meg és ennél minden bizonnyal többet fedeztek fel, csak én nem tudok mindegyikről). Tovább árnyalja a képet, hogy a 2015-ben felfedezett sérülékenységek 49%-a magas, további 42%-a közepes kockázati besorolást kapott (CVSSv2 és CVSSv3 pontozások alapján) és közel 92%-uk távolról is kihasználható - ugyanez a megoszlás a 2016. első féléves adataim alapján az idei sérülékenységek 51%-a magas, 42%-a pedig közepes kockázatú és 88%-uk volt távolról is kihasználható.

Komponensek szerint bontásban a legtöbb sérülékenységet az alábbi ICS komponensekben találták:

1. HMI-k
2. Elektromos eszközök (ebbe a kategóriába többek között gázdetektorok, szivattyúk, relévezérlők, stb. tartoznak)
3. SCADA rendszerek
4. ICS hálózati eszközök

Már hosszú évek óta nyilvánvaló tény, hogy a különböző ipari rendszerek esetén az izoláció nem elégséges biztonsági intézkedés, különösképpen nem úgy, hogy ez a fajta izoláció gyakran csak az üzemeltetők/fejlesztők/biztonsági szakemberek fejében létezik és különböző (üzleti, technológiai, stb.) indokok miatt az ICS rendszerek már régen össze lettek kapcsolva a vállalati hálózattal, sok esetben pedig az Internettel is. Ez azt eredményezte, hogy az ICS rendszerek kockázatai nagyságrendekkel megnőttek, a különböző kritikus infrastruktúrák elleni támadások pedig azt is bizonyítják, hogy ezek a rendszerek egyre inkább a támadók érdeklődésének homlokterébe kerülnek (ezt láttuk a 2015 decemberi ukrajnai incidens során is). Ezeket a kockázatokat csak az ICS rendszerek üzemeltetői és fejlesztői közötti szorosabb és sokkal aktívabb együttműködéssel lehet elfogadható mértékűre csökkenteni.

Az ICS-CERT július 7-i publikációja szerint Maxim Rupp a Moxa Device Web Console nevű, soros-Ethernet átalakító eszközében talált hibát, ami a Device Server Web Console 5232-N típusú eszközök minden verzióját érinti.

A hibát kihasználva egy támadó képes lehet megkerülni a rendszer jogosultságkezelő eljárását.

A hibával kapcsolatban a gyártó minden érintett ügyfelének azt javasolja, hogy ne használják az eszközök 80/TCP és 23/TCP portjait, valamint a 161/UDP, 4800/UDP, és 4900/TCP portokat csak megbízható eszközökről lehessen elérni.

Az ICS-CERT ezen túlmenően a szokásos kockázatcsökkentő intézkedéseket javasolja:
- 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!

További részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-189-02

Minden információ/IT-biztonsági intézkedés első lépése egy megalapozott kockázatelemzés elkészítése, ezzel lehet meghatározni, hogy melyek azok a kockázatok, amelyek túl magasak a rendszerre/szervezetre nézve és amelyek csökkentésére különböző intézkedéseket kell hozni. A különböző ipari rendszerek kiberbiztonsági kockázatelemzései, hasonlóan az ICS biztonság más területeihez, egy meglehetősen egyedi téma, amiről most Rebekah Mohrtól jelent meg egy rövidebb írás a SANS ICS Security Blog-ján.

Az ipari folyamatokkal kapcsolatban az általános kockázatelemzésnek nagyon komoly múltja és hagyományai vannak és az ezzel foglalkozó szakemberek nagyon jó munkát is végeznek. Problémát a kockázatelemzés szempontjából is az ICS rendszerek információ/IT-biztonsági kockázatelemzése jelent, nem utolsósorban azért, mert a klasszikus ipari kockázatelemzéssel foglalkozó szakemberek jellemzően nem ismerik és nem érint az IT és IT biztonsági kockázatok sajátosságait, az információ/IT-biztonsági kockázatelemzéssel foglalkozó kollégák pedig többnyire nincsenek tisztában az ICS rendszerek sehol máshol nem jelentkező egyedi tulajdonságaival.

Az ipari kockázatelemzések során több kockázatelemzési eszközt is használnak annak érdekében, hogy minél pontosabban tudják meghatározni a működési és emberéletet érintő biztonsági kockázatokat, ilyen többek között a Bow-Tie modell és kockázatelemzési mátrix (Risk Assessment Matrix, RAM), így határozva meg, hogy a maradványkockázatok elfogadhatóan alacsonyak-e (As Low As Reasonably Practicable, ALARP). Ezeket az eszközöket néhány kisebb változtatással az ipari rendszerek kiberbiztonsági kockázatelemzéséhez is hatékonyan lehet használni. Ennek a megoldásnak van egy további előnye, ilyen módon nem az egyes fenyegetések múltbeli előfordulása alapján próbáljuk megbecsülni a bekövetkezés valószínűségét (ahogy ez jellemzően az IT kockázatértékelések során szokott történni), hanem a támadáshoz szükséges erőforrások értékelése alapján. Erről a módszerről szól a SANS Reading Room-ban "Evaluating Cyber Risk in Engineering Environments: A Proposed Framework & Methodology" címmel elérhető útmutató.