Az ICS-CERT weboldalán ismét több sérülékenységi bejelentés látott napvilágot.

Advantech B+B SmartWorx MESR901 Modbus gateway sérülékenység

A blogon már sokszor emlegetett Maxim Rupp ezúttal az Advantech B+B SmartWorx MESR901 Modbus gateway eszközeinek 1.5.2 és ennél korábbi verzióiban talált egy hibát, ami a kliens oldalon megvalósított authentikációra vezethető vissza.

Az ICS-CERT bejelentése szerint a gyártó nem képes(!) javítani a hibát és azon dolgozik, hogy a sérülékeny berendezéseket egy új modellel lehessen lecserélni!

A hibáról további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-122-03

CyberVision Kaa IoT Platform sérülékenység

Jacob Baines, a Tenable Network Security (többek között a Nessus automatizált sérülékenység vizsgáló szoftvert gyártó cég) munkatársa egy kódbefecskendezéses támadást lehetővé tevő hibát talált a CyberVision Kaa IoT Platform-jának 0.7.4 és feltételezhetően korábbi verzióiban.

A gyártó többszöri megkeresésre sem reagált, így a hibával kapcsolatban sem javítás, sem a sérülékenység okozta kockázatok csökkentésére vonatkozó gyártói javaslatok nem érhetőek el!

A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-122-02

Schneider Electric Wonderware Historian Client sérülékenység

Andrey Zhukov, a USSC munkatársa talált egy, a nem megfelelő XML-feldolgozásból adódó hibát a Schneider Electric Wonderware Historian Client 2014 R2 SP1 és korábbi verzióiban.

A gyártó a hiba javítását a HC_SecurityHF_10.6.13100 nevű frissítésben végezte el. Azoknak az ügyfeleknek, akik a Wonderware Historian Client 2014 R2 SP1-nél korábbi verzióját használják, előbb frissíteniük kell a 2014 R2 SP1-re, majd utána tudják telepíteni a HC_SecurityHF_10.6.13100-at.

A sérülékenységről további információkat a gyártó közleményéből vagy az ICS-CERT publikációjából lehet megtudni.

A sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- 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;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltasáok hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Moxa AWK-3131A sérülékenységek

A Cisco Talos munkatársa, Patrick DeSantis egy beégetett adminisztrátori hozzáférést talált a Moxa AWK-3131A sorozatú ipari IEEE 802.11a/b/g/n vezeték nélküli eszközeinek 1.1-es verziójában. A 94jo3dkru4 felhasználónévhez tartozó moxaiwroot jelszóval bárki teljes hozzáférést szerezhet a sérülékeny eszközökön. Az érintett eszközökön a legitim adminisztrátorok számára jelenleg nincs lehetőség a fenti felhasználói adatok megváltoztatására, a Talos és a Moxa csak azt tudja javasolni, hogy a sérülékeny eszközökön tiltsák le a távoli bejelentkezést lehetővé tevő szolgáltatásokat (SSH, Telnet).

A fenti, a CVSSv3-ban 10,0 pontra értékelt hiba mellett a Talos szakemberei számos egyéb  (XSS, CSRF, CLI, DoS, POODLE, DROWN, HTTP header injection, jelszavak olvasható formában történő továbbítását, információ-szivárgást lehetővé tevő) hibát is találtak.

A hibákról bővebben az alábbiakban lehet olvasni:

http://www.talosintelligence.com/reports/TALOS-2016-0225/
http://www.talosintelligence.com/reports/TALOS-2016-0230/
http://www.talosintelligence.com/reports/TALOS-2016-0232/
http://www.talosintelligence.com/reports/TALOS-2016-0233/
http://www.talosintelligence.com/reports/TALOS-2016-0234/
http://www.talosintelligence.com/reports/TALOS-2016-0236/
http://www.talosintelligence.com/reports/TALOS-2016-0237/
http://www.talosintelligence.com/reports/TALOS-2016-0238/
http://www.talosintelligence.com/reports/TALOS-2016-0239/
http://www.talosintelligence.com/reports/TALOS-2016-0240/
http://www.talosintelligence.com/reports/TALOS-2016-0241/
http://www.talosintelligence.com/reports/TALOS-2016-0235/
http://www.talosintelligence.com/reports/TALOS-2016-0231/

Hyundai Motor America Blue Link sérülékenységek

A Hyundai Motor America jármű-kezeléshez használt alkalmásának alábbi verzióiban Will Hatzer és Arjun Kumar, a Rapid7 munkatársai találtak hibákat:

- Blue Link 3.9.5 és
- Blue Link 3.9.4.

A kutatók a fenti verziókban beégetett titkosítási kulcsokat és egy közbeékelődéses (Man-in-the-Middle) támadásra lehetőséget adó hibát azonosítottak.

A gyártó a hibát javító verziót (Blue Link 3.9.6) Androidra 2017. március 6-án, iOS-re március 8-án adta ki.

A hibáról további részleteket a Rapid7 és az ICS-CERT publikációiban lehet találni.

Új információk a Sierra Wireless AirLink Raven XE és XT sérülékenységekkel kapcsolatban

Az ICS-CERT új információkat jelentetett meg a 2016. június 30-án publikált Sierra Wireless AirLink Raven XE és XT eszközöket érintő sérülékenységekkel (nem megfelelő jogosultságkezelés, CSRF, nem kellőképpen védett felhasználói adatok) kapcsolatban. A gyártó tavaly nyári nyilatkozatával ellentétben (hogy az AirLink Raven XE és XT sorozatú eszközök életciklusa lejárt és az akkor publikált hibák javítására nem fordítanak erőforrásokat) most mégis arról érkeztek hírek, hogy a Sierra Wireless mind a Raven XE, mind az XT sorozatú eszközökhöz elkészítette a fenti hibákat javító firmware-verziókat (a Raven XE-nél ez a 4.0.14, az XT-nél a 4.0.11).

További információkat (a firmware-ek letöltési hivatkozásait és a Sierra Wireless által kiadott Technical Bulletint) az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-17-115-02

BLF-Tech LLC VisualView HMI sérülékenység

Karn Ganeshen a BLF-Tech LLC által fejlesztett VisualView HMI 9.9.14.0 és korábbi verzióiban talált egy kártékony DLL felhasználásával tetszőleges kódfuttatásra lehetőséget adó hibát.

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

A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-115-01

Sérülékenység a GE Multilin SR digitális védelmi reléiben

Anastasis Keliris, Charalambos Konstantinou, Marios Sazos, és Dr. Michail (Mihalis) Maniatakos, a New York-i egyetem kutatói a GE több digitális védelmi reléjében találtak olyan sérülékenységet, ami a jelszavak gyenge titkosításában ölt testet. Az érintett rendszerek:

- 750 Feeder védelmi relé, 7.47-nél korábbi firmware-verziókban;
- 760 Feeder védelmi relé, 7.47-nél korábbi firmware-verziókban;
- 469 Motor védelmi relé, 5.23-nál korábbi firmware-verziókban;
- 489 Generátor védelmi relé, 4.06-nál korábbi firmware-verziókban;
- 745 Transzformátor védelmi relé, 5.23-nál korábbi firmware-verziókban;
- 369 Motor védelmi relé, minden firmware-verzió esetén.

A gyártó a hibát az alábbi firmware-verziókban javította:

- 750 Feeder védelmi relé, 7.47;
- 760 Feeder védelmi relé, 7.47;
- 469 Motor védelmi relé, 5.23;
- 489 Generátor védelmi relé, 4.06;
- 745 Transzformátor védelmi relé, 5.23;
- 369 Motor védelmi relé - a GE a javítást ennél a rendszernél 2017. júniusra igéri.

A hibával kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-117-01

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- 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;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltasáok hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A dolgok Internete után nem kellett sokat várni, hogy megjelenjen az ipari dolgok Internete (Industrial IoT) fogalom, valamint az okosautó, okoshűtő és az okosotthon után az okosgyár koncepciója. Az utóbbi hónapokban, egy évben pedig egyre gyakrabban lehet olvasni és hallani az Industry 4.0-ról, amit magyarul egy új ipari forradalomként, az ipar digitalizálásaként szoktak emlegetni.

Azok, akik szerint ez egy kifejezetten pozitív, innovatív és hasznos folyamat lesz, teljesen digitalizált, intelligens gyárakat látnak lelki szemeikkel, ahol mobil ultrahangos mérőberendezések vizsgálják a gyártósorok gépeit, hogy szükséges-e karbantartásra küldeni őket, vezető nélküli targoncák és villásemelők mozgatják az alkatrészeket és a kész termékeket és egymással együttműködő robotok teszik mind hatékonyabbá a gyártási folyamatokat.

Az IT és információbiztonsági szakértők igyekeznek óvatosságra inteni ezekkel a folyamatokkal kapcsolatban és ennek több oka is van.

Korábban már több posztban írtam róla, ahogy az ipari rendszerek (az automatizált gyártósorok és kapcsolódó rendszerek is ide tartoznak) egyre nagyobb mértékben integrálódnak a vállalati IT rendszerekkel, nagyságrendekkel nő annak a kockázata, hogy a vállalati rendszerek kompromittálásával támadók hozzáférhetnek a termelésirányításban nélkülözhetetlen ipari rendszerekhez is.

Ez a vélemény nem csak az enyém, az ipari rendszerek biztonságával foglalkozó szakemberek körében általános ez az aggodalom, ami abból a tényből ered (amint arról is számos esetben írtam), hogy a különböző ipari rendszerek, így a gyárak termelésirányító rendszerei sem úgy lettek tervezve és kialakítva, hogy az Internetre legyenek csatlakoztatva vagy hogy az IT biztonsági szempontok kiemelten lettek volna kezelve. Ráadásul amíg a gyárak és a termelésirányító rendszerek gyakran fejlett megfigyelő és riasztó rendszerekkel vannak felszerelve, a szoftverek és az alkalmazások monitoringja másodlagos vagy teljesen figyelmen kívül hagyott terület. Ez a gyakorlat a termelésirányítási rendszereknél ugyanúgy katasztrófális következményekkel járhat, mint a kritikus infrastuktúrákban használt folyamatirányító rendszereknél. Ha egy támadó képes hozzáférni a termelésirányító rendszerhez, akkor a termelő gépek és folyamatok irányítása mellett hozzáférhet a vállalat bizalmas, gyakran akár szabadalommal védett adataihoz is.

Ezeket a kockázatok a Stuxnet és a 2014-es, német acélkohó elleni támadás mutatták be a legjobban, mindkét esetben a termelésirányító rendszer kompromittálásával okoztak jelentős károkat a támadók. Egy tavalyi német kutatás szerint az ipari kémkedésre illetve az adott termékek visszafejtése a leggyakoribb okok között vannak, ami miatt a német vállalatok 70 %-át érintette a szoftverek és gépek illegális lemásolásából eredő 7,3 milliárd eurós veszteség.

Ha a termelő vállalatok valóban hosszú távú előnyöket várnak a negyedik ipari forradalomtól, akkor a technológiai fejlesztések mellett az IT biztonsági szabványokat is újra kell gondolniuk és frissíteniük kell. Az ICS kiberbiztonság egyik legnagyobb kihívása, hogy tradícionális biztonsági módszerekkel és eszközökkel próbálunk megvédeni olyan ipari rendszereket, amiknek gyakran a működését nem értjük pontosan, most pedig minden korábbinál nagyobb változások történnek az ICS rendszerek területén, ami miatt immár az OT sem képes az eddig fenntartott, nagyon mély tudásszintjét megőrizni. Ahhoz, hogy eséllyel vegyük fel a küzdelmet az ipari rendszereinket fenyegető támadókkal, a tradícionális módszereket és eszközöket ötvöznünk kell az új és innovatív biztonsági technológiákkal és eljárásokkal.

A gyártó bejelentése szerint a Cisco Industrial Ethernet 2000 Series Switch-ekben egy olyan hibát azonosítottak, amely lehetőséget ad egy támadónak, hogy hibásan formázott CIP cosmagokkal szolgáltatás-megtagadásos (DoS) támadást indíthat a sérülékeny hálózati eszközök ellen.

Bővebb információkat az érintett szoftver verziókról és a hiba javítását tartalmazó frissítésekről a Cisco bejelentésében és a megfelelő Bug ID-k alatt találhatnak a cég ügyfelei.

A Kaspersky az elmúlt héten hozta nyilvánosságra a 2016 második félévéről készült ICS biztonsági összefoglalóját. A felmérés adatai szerint 2016 második félévében (egy minimális decemberi csökkenés mellett) folyamatosan nőtt az ICS rendszerek esetén észlelt kiberbiztonsági incidensek száma,  átlagosan az összes, a Kaspersky által vizsgált ICS rendszerek 20-25 %-át érte támadás ebben az időszakban.

A fenyegetések döntő többsége (22 %-a) az Internet irányából érte a vizsgált ICS rendszereket, a második legnagyobb kockázatot továbbra is a különböző, ICS rendszerekben használt adathordozók jelentik (10,9 %-kal), a harmadik pedig az ICS rendszerekkel valamilyen formában (pl. mérnöki hordozható eszközökön működő) e-mail kliensek jelentik (8,1 %-kal). További támadási vektorokként jelennek meg a rendszerekről készített mentések (0,9 %), a hálózati megosztások (0,7 %), a Windows mentések másolata (0,5 %) és a felhős tárhelyek alkalmazása (0,1 %). A fentiekből jól látszik, hogy az ICS rendszerek fizikai szeparálása a vállalati IT hálózattól és az Internettől megbukott, mint önállóan hatékony, preventív biztonsági intézkedés az ICS rendszerek kiberbiztonságának megteremtése során. Ahelyett, hogy egy-egy támadási vektor elleni intézkedésekkel a szervezetek szétforgácsolnák az erőforrásaikat, egy átfogó és integrált, rendszeres és alapos kockázatelemzésen alapuló biztonsági intézkedéscsomagot kell kifejleszteni és alkalmazni.

A Kaspersky adatai alapján jól kirajzolódik, hogy a különböző kiberbiztonsági incidensek zöméért az átlagos IT rendszerek elleni támadásokért felelős malware-ek tehetőek felelőssé. Ezek a malware-ek jellemzően a fent vázolt módok valamelyikén találnak utat az ICS rendszerekig és jóval kevésbé jellemző, hogy kifejezetten az ICS rendszerek ellen fejlesztenék őket a támadók. Ennek ellenére az adatokból azt is le lehet szűrni, hogy az ICS rendszereket üzemeltető szervezetek elleni célzott támadások is egyre gyakoribbak. A Kaspersky egy széles körű, adathalász módszereket használó támadást figyelt meg, ami megfigyeléseik szerint 2016 júniusában kezdődött és 2017 március végén még tartott. Ez a támadássorozat 50 ország több, mint 500 vállalatát érintette, többek között a kohászati, villamosenergia-ipari és más szektorokban működő cégeket. A támadók jellemzően már ismert és a különböző motivációjú csoportok által már jóideje használt malware-családokat használják ezekhez a támadásokhoz is: euS, Pony/FareIT, Luminosity RAT, NetWire RAT, HawkEye, stb. Ezek a malware-ek a kiberbűnözők köreiben is igen népszerűek, de az ipari szereplők elleni támadásokhoz egyedi módosításokat is tartalmaznak.

A Kaspersky felmérésében szereplő incidensek között kiemelkedően sok a szolgáltatás-megtagadásos (DoS) támadás. Második helyen a távoli kódfuttatást lehetővé tevő hibák kihasználása áll, a harmadik pedig a fájl-manipulálásra építő támadások csoportja. A különböző (SQL és parancssori) kódbefecskendezéses támadások és a felhasználói fiókok manipulálására épülő támadások csak a lista végére fértek fel.

A Kaspersky CERT-jében dolgozó kutatók 2016 második felében összesen 75 különböző ICS rendszereket érintő sérülékenységet fedeztek fel, ezeknek 77 %-a (58 a 75-ből) a CVSSv3 alapján magas vagy kritikus besorolású volt (ez még az általam publikus forrásokból gyűjtött számoknál is rosszabb képet mutatnak, én tavaly július elejétől december végéig összesen 131 különböző ICS sérülékenységről szóló információt gyűjtöttem össze, ezek 66 %-a tartozott a magas vagy kritikus kockázatú csoportban).

A fenti fenyegetések az általános IT biztonsági kihívásokon túl további, elsősorban az ipari rendszerekre jellemző kihívásokat jelentenek az ICS rendszerek üzemeltetéséért és kiberbiztonságáért felelős szakemberek számára (ezek egy részét korábban már érintettük itt, a blogon is):

1. Az ipari rendszerek esetében az összetettségük és az integráltságuk a különböző IT rendszerekkel, együtt azzal, hogy a különböző gyártók hagyományosan minimális erőfeszítéseket tesznek a biztonságosabb rendszer/komponens kialakítása érdekében, jelentősen növeli az ismert és a nulladik napi sérülékenységek kihasználásának kockázatát. További problémákat okoz, hogy a gyártók még mindig nem priorizálják a feltárt hibák javítását a rendszereikben és az elkészült javításokat is inkább az új verziókban jelentetik meg, ahelyett, hogy patch-ek és hotfix-ek formájában minél több sérülékeny rendszer javítására törekednének. Emellett még mindig vannak olyan gyártók is, akik inkább megpróbálják titokban tartani és javítani a rendszereikben felfedezett hibákat.

2. A klasszikus IT biztonsági hármas (bizalmasság, sértetlenség, rendelkezésre állás) és az eszközök kompatibilitásának biztosítása közben a gyártók gyakran félreteszik a biztonságosabb rendszerek fejlesztésének szempontját, ezért sok esetben az ICS rendszerek gyenge biztonsági szinttel vagy kifejezetten sérülékeny megoldásokkal kerülnek üzembe helyezésre.

3. Az ICS/SCADA rendszerek jellemző biztonsági (safety) beállításai a legritkább esetben vannak felkészítve arra az esetre, amikor egy támadó szándékosan manipulálja a folyamatvezérlést vagy valaki ártó szándékkal használja a legitim jogosultságokat a rendszerben. Ez utóbbira a legjobb példa a két ukrán incidens 2015 és 2016 decemberében, de szerencsére ezekben az esetekben, amennyire tudhatjuk, személyi sérülés nem történt és arról sincs információ, hogy a SCADA rendszerek biztonsági (safety) funkcióit is manipulálták volna.

Botnetek ipari hálózatokban

A Kaspersky kutatói a vizsgált hálózatok 5 %-ában találtak aktívan működő botnetekhez tartozó eszközöket illetve olyan nyomokat, amik alapján korábban az adott hálózatban működtek botnetekhez tartozó eszközök. Ez ahhoz képest nagy szám, hogy a botnetek általános működési köre (pénzügyi és más Internetes szolgáltatásokhoz használt felhasználói adatok ellopása, levélszemét küldése, DoS-támadások indítása) nem jellemző az ipari rendszerekre. Bár ezek a botnet-műveletek alapvetően nem arra szolgálnak, hogy zavart okozzanak az ipari folyamatvezérlésben, az ICS rendszerek sok esetben olyan kicsi teljesítmény-tartalékkal működnek, hogy egy efféle extra funkció futása már hatással lehet a stabil működésre vagy kompatibilitási problémákat okozhat. További problémát okozhat, ha egy botnetbe bevont ipari eszköz publikus hálózaton kommunikál, előfordulhat, hogy a botnet forgalom miatt az ICS eszközhöz rendelt IP cím fekete vagy szürkelistára kerül egyes reputációs adatbázisokból dolgozó biztonsági megoldásoknál, ami az üzembiztonsági probémákon túl az adott szervezet jó hírét is csorbíthatja. A fertőzött ICS eszközök más jellegű fenyegetéseket is hordoznak. A botnet ügynökök jellemzően sok olyan adatot is összegyűjtenek a megfertőzött eszközökről, amelyek alapján egészen jól be lehet azonosítani az adott szervezetet, ráadásul a botneteket a DarkWeb-en/DeepWeb-en rendszeresen el- vagy bérbe adják, így akár egy célzott támadás megalapozásához is vezethet egy nem célzott malware-fertőzés.

A felmérés során gyűjtött adatok alapján az ICS rendszerekben a leggyakoribb botnet-építő malware az Andromeda volt, a második leggyakoribb a Zeus, harmadik pedig a Cryptowall.

A Kaspersky ICS-CERT által készített tanulmány teljes terjedelmében itt érhető el.

A húsvét előtti pár napban megint több ICS rendszerrel kapcsolatos sérülékenység látott napvilágot.

Wecon Technologies LEVI Studio HMI Editor sérülékenységek

Andrea Micalizzi (rgod) a Wecon Technologies LEVI Studio HMI Editor összes verzióját érintő puffer-túlcsordulási hibákat talált. A gyártó a hibákat az 1.8.1-es verzióban javította, amit a weboldaláról lehet letölteni.

A sérülékenységekről további részleteket az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-103-01

Sérülékenységek Schneider Electric Modicon M221 PLC-kben és SoMachine Basic berendezésekben

Simon Heming, Maik Brüggemann, Hendrik Schwartke és Ralf Spenneberg, az Open Source Security munkatársai két sérülékenységet fedeztek fel a Schneider Electric alábbi termékeiben:

- Modicon M221 PLC, v1.5.0.1-nél korábbi firmware-verziói és
- SoMachine Basic, v1.5-nél korábbi verziók.

A most felfedezett sérülékenységek a fenti rendszerekben tárolt adatok védelmével kapcsolatos hibákon alapulnak. A rendszerekben beégetett titkosító kulcsok találhatóak illetve a Modbus-TCP protokollon keresztül küldött speciális parancs segítségével egy támadó hozzáférést szerezhet az alkalmazás védelméhez tartozó jelszóhoz.

A gyártó által közzétett ajánlások szerint a sérülékeny rendszereket használó ügyfelek számára javasolt biztonságos, szigorú hozzáférési szabályokkal védett és lehetőleg harmadik féltől származó titkosítással titkosított helyen tárolni a projekt fájlokat. A SoMachine Basic titkosító mechanizmusának javítása várhatóan 2017. június 15-én fog megjelenni.

A Schneider Electric további javaslatai a kockázatok csökkentése érdekében:

- Aktiválják az Application Protection funkciót az érintett eszközökön egy üres jelszóval, ahogyan a SoMachine Basic Súgójában a "Password Protecting an Application" fejezetben áll, ezzel kikapcsolva az M221-es PLC-kben az alkalmazás-feltöltés funkciót.
- Tűzfalak használatával blokkolni kell a távoli/külső hálózatokból történő 502/tcp (Modbus-TCP) port elérését az M221-es PLC-k esetén.

A hibákról részleteket a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- 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;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltasáok hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Schneider Electric Modbus protokoll sérülékenységek

Az ICS-CERT publikációja szerint a Schneider Electric Modicon PLC-iben hazsnált Modbus protokollban két sérülékenységet azonosított Eran Goldstein, a CRITIFENCE munkatársa. A hibák a Modicon Modbus protokoll minden verziójában jelen vannak. Az első hiba az authentikációs adatokat tartalmazó hálózati csomagok újraküldésével az authentikációs folyamat megkerülését teszi lehetővé, a második pedig a biztonságos rendszertervezés alapelveinek megsértéséből adódik.

A gyártó a fenti hibákkal kapcsolatban kockázatcsökkentő intézkedésekre vonatkozó javaslat-csomagot tett közzé:

- A Momentum M1E vezérlők közül a 171CBU98090-es és 171CBU98091-es modellek összes verzióját használó ügyfeleknek azt javasolják, hogy tűzfalak alkalmazásával kontrollálják az eszközök 502/tcp portjára irányuló vagy onnan kiinduló kapcsolatokat, mert ezeknél az eszközöknél egyéb kompenzáló kontrollok nem állnak rendelkezésre.
- A Modicon M340, M580, Premium és Quantum felhasználók számára a Schneider Electric az alábbi intézkedések bevezetését javasolja:
 - Engedélyezzék a PLC-hez történő csatlakozáshoz szükséges authentikációt;
 - Engedélyezzék az M340-es, Premium és Quantum eszközökön azt a védelmi funkciót, amivel tiltani lehet a távoli kapcsolatokat illetve a futtatás/leállítás parancsokat;
 - Engedélyezzék a PLC-ken az ACL-ek működését (én már csak azt az egyet szeretném tudni, hogy ha ezek a funkciók mind léteznek a Schneider Electric PLC-in, miért is nem az az alapértelemezett beállítás, hogy működnek is és ha a felhasználási körülmények indokolják, ki lehet kapcsolni őket?)
 
A fenti hibákkal kapcsolatban további információkat a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- 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;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltasáok hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A Ponemon Institute a Siemens megbízásából készített egy felmérést az USA olaj és gázipari szereplői körében azt kutatva, hogy az ebben a szektorban működő cégek hogyan látják a szervezeteik kiberbiztonsági kockáaztait. A felmérésről készült publikáció néhány hete jelent meg, ebben 8 pontban foglalták össze a fontosabb megállapításokat:

1. A válaszadók 59 %-a szerint az OT (Operations Technology) kockázatai nagyobbak, mint az IT kockázatok és 67 % szerint az ipari rendszerek kockázatai az elmúlt években jelentősen nőttek, elsősorban a kiberbiztonsági helyzet romlása miatt.

2. Az olaj- és gáztársaságok egyöntetűen profitálnak a digitalizációból, de a válaszadók 66 %-a szerint ugyanakkor a digitalizáció jelentős kockázatnövekedést is hozott.

3. A felmérésben résztvevők 68 %-a tapasztalt már kibertámadást, mégis nagyon sok szervezetnél nem veszik elég komolyan az OT kiberbiztonsági kockázatait vagy az ezzel kapcsolatos stratégia kialakítását.

4. A válaszolók 61 %-a szerint az ipari rendszereik esetében alkalmazott biztonsági megoldások és eljárások nem biztosítanak megfelelő szintű védelmet.

5. A megkérdezettek 65 %-a gondolta úgy, hogy a legnagyobb fenyegetést a saját munkatársak hanyagsága jelenti és 15 % válaszolta azt, hogy ártó szándékú külső támadó - ezzel is megerősítve az igényt a fejlett monitoring megoldásokra, amikkel a munkatársak által végrehajtott műveleteket  lehet viselkedéselemzésnek alávetni.

6. A válaszadóknak csak 41 %-a mondta azt, hogy folyamatosan monitorozzák az ICS infrastruktúrát, hogy értékelni tudják a fenyegetéseket és támadásokat. A felmérések szerint az OT-t érő támadások 46 %-át az érintett szervezetek észre sem veszik. Ezek a számok azt mutatják, hogy komoly fejlesztésekre lenne szükség az olaj- és gázszektor szervezeteinél annak érdekében, hogy jobban átlássák és megértsék, mi történik a rendszereikkel egy adott pillanatban.

7. A felmérésben résztvevők 68 %-a szerint a biztonsági elemzés alapvető vagy nagyon fontos a hatékony biztonság kialakításához.

8. A válaszolóknak kevesebb, mint kétharmada mondta azt, hogy a felhasználói viselkedést elemző rendszerek és a biztonsági hardeningen átesett végponti eszközök hatékony eszközök a biztonság megteremtésében. 62 % szerint az adatok rendszerek és rendszerelemek közötti küldése során alkalmazott titkosítás nagyon hatékony, ennek ellenére sok szervezet nem tervezi ezeknek a technológiáknak az alkalmazását.

A PI tanulmánya (benne számos további érdekes részlettel) szabadon elérhető a BusinessWire oldalán.

Talán nem vagyok egyedül azzal a véleményemmel, hogy egyszer érdekes lenne hasonló kutatást magyar ipari szereplőkkel elvégezni.

Az ICS-CERT bejelentése szerint Sebastian Neef, az Internetwache.org munkatársa több sérülékenységet fedezett fel a német Certec EDV GmbH Atvise scada nevű termékének 3.0 és ennél korábbi verzióiban. A hibák Cross-site scripting és fejléc-befecskendezéses támadásra adnak lehetőséget, amiken keresztül egy támadónak tetszőleges kódfuttatásra nyílik lehetősége, ezzel akár az eszköz sértetlenségét is befolyásolhatja.

A gyártó a hibákat a 3.1-es verzióban javította, amit az érintett ügyfelek a Certec EDV Gmbh weboldaláról tölthetnek le.

A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-096-01

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- 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;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltasáok hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Tegnap este egy érdekes cikket olvastam a hwsw.hu-n arról, hogy miért esett ki tavaly decemberben a Delta Airlines adatközpontja és mi okozta a kiesést. A részletek a cikkben olvashatóak, dióhéjban az történt, hogy az áramkimaradás idejére üzembe helyezett tartalék generátorok védelmi reléiben használt PLC-k feszültségingadozást észleltek az áramszolgáltató vonalán bekövetkezett betáp-kiesés után, amit a PLC belső logikája úgy értelmezett, hogy az adatközpont villamosenergia-rendszerében valahol rövidzárlat van, ezért a generátorokat védve nem engedte csatlakoztatni őket az adatközponti hálózatra. Emiatt a generátorok fogyasztók nélkül, "üresben" működtek, a szerverek pedig a szünetmentes áramforrások lemerülése után leálltak.

A cikk szerint hasonló történt már az Amazon egyik adatközpontjában is, abban az esetben a PLC gyártója még az Amazon kifejezett kérésére sem volt hajlandó olyan, módosított firmware-t szállítani a védelmi relék PLC-ihez, amiben felülbírálható lett volna a generátort védő logika. Emiatt - írja a hwsw.hu - az Amazon adatközpontjaiban ma már azok a villamosmérnökök írják a PLC-k firmware-jeit, akik az adatközponti villamosenergia-ellátásért felelősek. Itt meg is érkeztünk a ma poszt elején feltett kérdéshez: ICS biztonsági szempontból jó-e, ha az OT munkatársai írják a saját maguk üzemeltette eszközökön futó szoftvereket?

Az ICS kiberbiztonság területén dolgozók hosszú ideje próbálják terjeszteni azt a nézetet, hogy a biztonságos programozásnak az ipari rendszerek világába is utat kell találni. Ennek megértése és alkalmazása az ICS gyártók részéről még a IT szoftverfejlesztők meggyőzésénél is fontosabb feladat kéne, hogy legyen, hiszen egy IT-ban használt szoftver életciklusa jellemzően 1-2-3 év lehet és ez az idő egyre csökken, ráadásul a feltárt hibákat rövid idő alatt lehet javítani. Ezzel szemben az ICS rendszereknél egy már élesbe állított rendszert 10-15-20 évig fognak használni és jóval ritkábbak a hibajavítások telepítésének lehetőségei is.

Természetesen ezzel nem azt mondom, hogy ez egy elhibázott út, hiszen ha egy szervezet a beszállítóitól nem kapja meg azt a funkcionalitást egy rendszerben, amire szüksége van és van lehetősége egyedileg fejleszteni, akkor nem igen van más lehetősége. Azonban ha ezt választják, mindenképp nagyon alapos kockázatelemzéseket kell folytatniuk a saját fejlesztésű szoftverek teljes életciklusa során és ha ilyen alapvető fontosságú szoftverelemeket fejlesztenek házon belül, hangsúlyt kell fektetniük a szoftverfejlesztés biztonsági szempontú minőségbiztosítására is, különben elképzelhető, hogy egy funkcionalitásában már-már tökéletes, de a támadók számára könnyen kompromittálható rendszert építenek, ami immár a szoftveres sérülékenységei miatt nem lesz képes az elvárásoknak megfelelően működni.