Federico Maggi és Rainer Vosseler, a TrendMicro és Davide Quarta, az EURECOM és a Milánói Műszaki Egyetem munkatársai még decemberben publikálták az MQTT (Message Queuing Telemetry Transport) és CoAP (Constrained Application Protocol) IIoT kommunikációs protokollok biztonságával kapcsolatban végzett kutatásaik eredményeit.

A kutatók mindkét protokollal kapcsolatban számos problémát azonosítottak, vizsgálataik szerint az ipari eszközöket üzemeltetők még mindig nem veszik komolyan az ICS (vagy IIoT) biztonság egyik első számú szabályát, név szerint azt, hogy ilyen berendezéseket ne csatlakoztassanak publikus hálózatokra. A vizsgálatot végző szakemberek több százezer MQTT és CoAP hosztot találtak az Interneten. Ezen túlmenően pedig mindkét vizsgált protokollban találtak olyan sérülékenységeket, amik az ICS biztonsággal foglalkozók számára ugyan nem ismeretlenek (ilyenek pl. a kliensek által küldött adatok érvényesség-ellenőrzésének a hiánya, az adatok bizalmasságának nem megfelelő vagy éppen semmilyen védelme.)

A Kasszandraként komoly ICS biztonsági incidenseket jósoló szakemberek mellé immár a TrendMicro is felzárkózott, a most publikált kutatási dokumentációban azt írják, hogy csak idő kérdése, mikor fogják támadók kihasználni a fent említett protokollok biztonsági hiányosságait célzott támadásokhoz.

A teljes, 65 oldalas kutatási anyag elérhető a TrendMicro weboldalán.

Sérülékenység Schneider Electric ZelioSoft rendszerekben

A Schneider Electric 2018 utolsó napjaiban hozta nyilvánosságra, hogy mdm és rgod, a 9SG Security Team tagjai egy Use-after-free sérülékenységet találtak a ZelioSoft 2 v5.1 és korábbi verzióiban.

A gyártó a hibát a ZelioSoft 2 v5.2-es verziójában javította. A sérülékenységgel kapcsolatban további részleteket a Schneider Electric publikációjában lehet találni.

Sérülékenység Yokogawa rendszerekben

A Yokogawa a japán CERT-tel együttműködve gy erőforrás-kezelési hibát azonosított az alábbi termékeiben:

- CENTUM CS 3000 (R3.05.00 - R3.09.50);
- CENTUM CS 3000 Entry Class (R3.05.00 - R3.09.50);
- CENTUM VP (R4.01.00 - R6.03.10);
- CENTUM VP Entry Class (R4.01.00 - R6.03.10);
- Exaopc (R3.10.00 - R3.75.00);
- PRM (R2.06.00 - R3.31.00);
- ProSafe-RS (R1.02.00 - R4.02.00);
- FAST/TOOLS (R9.02.00 - R10.02.00);
- B/M9000 VP (R6.03.01 - R8.01.90).

A gyártó a hibát a legfrissebb verzióban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-19-003-02

Hetronic berendezések sérülékenysége

Jonathan Andersson, Philippe Z Lin, Akira Urano, Marco Balduzzi, Federico Maggi, Stephen Hilt és Rainer Vosseler a ZDI-vel együttműködve egy authentikáció megkerülésre lehetőséget adó hibát találtak a Hetronic alábbi távírányító adó-vevő berendezéseiben:

- Nova-M: minden, r161-nél korábbi verzió;
- ES-CAN-HL: minden, Main r1864-nél és Estop_v24-nél korábbi verzió;
- BMS-HL: minden, Main r1175 és Estop_v24-nél korábbi verzió;
- MLC: minden, Main r1600 és Estop_v24-nél korábbi verzió;
- DC Mobile: minden, Main r515 és Estop_v24-nél korábbi verzió.

A gyártó a hibát a legújabb firmware-verziókban javította. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-003-03

Sérülékenységek Siemens SWT3000 berendezések EN100 Ethernet moduljaiban

A Siemens ProductCERT bejelentése szerin Victor Nikitin, Vladislav Suchkov és Ilya Karpov, a ScadaX munkatársai két sérülékenységet fedeztek fel a Siemens SWT3000-es, IEC 61850-es protokollt használó berendezéseinek EN100 Ethernet moduljainak V4.33-nál korábbi firmware-verzióiban.

A gyártó a hibákat a V4.33-as firmware-verzióban javította. A sérülékenységekről további részleteket a Siemens ProductCERT bejelentése tartalmaz.

Sérülékenység Siemens SICAM A8000 sorozatú RTU-kban

A Siemens ProductCERT publikációja szerint Emanuel Duss és Nicolas Heiniger, a Compass Security munkatársai egy sérülékenységet találtak az alábbi, SICAM A8000-es sorozatú RTU-kban:

- SICAM A8000 CP-8000 minden, V14-nél korábbi verziója;
- SICAM A8000 CP-802X minden, V14-nél korábbi verziója;
- SICAM A8000 CP-8050 minden, V2.00-nál korábbi verziója.

A gyártó a hibát a legújabb verzióban javította. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT weboldalán lehet találni.

Sérülékenységek Siemens rendszerekben

A Siemens ProductCERT által közzétett információk szerint három sérülékenységet találtak az alábbi, PROFINET kommunikációs kártyákban:

- CP 1604: minden, V2.8-nál korábbi verzió;
- CP 1616: minden, V2.8-nál korábbi verzió.

A gyártó a hibákat a V2.8-as verzióban javította. A sérülékenységekről további részleteket a Siemens ProductCERT bejelentésében érdemes keresni.

Sérülékenység Siemens S7-300 vezérlőkben

A Siemens ProductCERT bejelentése szerint sérülékenységet találtak a SIMATIC S7-300 CPU-k V3.X.16-nál korábbi összes verziójában.

A gyártó a hibát a V3.X.16-os verzióban javította. A sérülékenységről bővebben a Siemens ProductCERT publikációjában lehet olvasni.

Siemens S7-1500 vezérlők sérülékenységei

A Siemens ProductCERT által publikált információk szerint Georgy Zaytsev, Dmitry Sklyarov, Druzhinin Evgeny, Ilya Karpov és Maxim Goryachy, a Positive Technologies munkatársai két sérülékenységet találtak az alábbi Siemens vezérlőkben:

- SIMATIC S7-1500 CPU-k minden, V2.0 és V2.5 közötti verziója;
- SIMATIC S7-1500 CPU-k minden, V1.8.5-nél korábbi verziója.

A gyártó a hibákat a V2.5 és frissebb firmware-verziókban javította. A sérülékenységek részleteit a Siemens ProductCERT bejelentésében lehet megtalálni.

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- 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áltatások 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ű (valamilyen szinten tűzálló 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.

Kicsit több, mint egy éve láttak napvilágot az eddigi egyik leginkább aggasztó, ICS rendszer elleni kibertámadás részletei (én itt írtam a Triton/TriSIS névre keresztelt malware-ről), októberben (talán nem tévedek nagyot, ha azt feltételezem, hogy legalábbis részben az ICS Cybersecurity Conference-re időzítve) számolt be a FireEye a támadás további elemzése során feltárt részletekről, amelyek alapján a támadást az orosz állami Központi Kémiai és Mechanikai Tudományos Intézettel (Central Scientific Research Institute of Chemistry and Mechanics, CNIIHM vagy oroszul ЦНИИХМ) hozták kapcsolatba.

A FireEye részletes elemzését és (az általuk valószínűtlennek nevezett alternatív magyarázatot) a FireEye blogján lehet megtalálni.

Ahogy közeledik az év vége, az IT biztonság világában is megkezdődik a 2018-as év értékelése és a 2019-re vonatkozó előrejelzések, várakozások publikálása. Immár nincs ez másként az ICS kiberbiztonság terén sem.

Az ICS rendszerek elleni támadások és a teljes fenyegetettségi kép az általános IT biztonsági helyzetnél lassabban változik, aminek egyik oka az, hogy ezeknek a rendszereknek a támadásából a különböző támadói csoportok nehezebben tudnak maguknak bevételt generálni.

A Kaspersky Lab napokban megjelent, 2019-re vonatkozó ICS biztonsági fenyegetettségi előrejelzése azonban pont erre a témára koncentrál és 4 pontban foglalják össze a legfontosabbnak tartott kihívásokat, ezek a következők:

1. Az ICS rendszerek folyamatosan növekvő támadási felületei - Azzal, hogy egyre nő a különböző automatizálási és folyamatvezérlési rendszerek száma és egyre több ilyen rendszer válik elérhetővé publikus hálózatokról, folyamatosan javul a támadók helyzete, hogy sikeres támadásokat tudjanak indítani különböző ICS rendszerek ellen.

2. Egyre nagyobb kiberbűnözői és titkosszolgálati érdeklődés az ICS rendszerek iránt - a kiberbűnözők egyes hagyományos bevételi forrásaik átmeneti vagy végleges beszűkülése esetén elkezdhetnek jobban érdeklődni az ICS rendszerek iránt, különösen, hogy ezek a rendszerek az átlagos IT rendszereknél gyakran sokkal kevésbé védettek, fontosságuk miatt viszont például egy zsarolóvírus-támadás esetén nagyobb eséllyel érhetik el, hogy az áldozat fizessen. A különböző, nemzetállami háttérrel rendelkező csoportok egészen más motivációval vehetik célba az ICS rendszereket, 8 évvel a Stuxnet után már egyáltalán nem számít rendkívülinek, hogy egy nagyhatalmi vagy akár csak egy regionális konfliktus egyik színtere valamelyik ország egy vagy több kritikus infrastruktúráját kiszolgáló ICS rendszer legyen.

3. Az általános fenyegetettségi szint alábecsülése - Az ICS biztonsági információk viszonylagosan alacsony mennyisége, az ICS rendszerek elleni, relatív ritka támadások és a valós ICS biztonsági problémák tagadása, tudomásul nem vétele nagyon komoly negatív hatással van a fenyegetettségi helyzet objektív értékelésére a döntéshozók szintjén. Ahogy korábban már említettem, jelenleg talán ezt tartom a legnagyobb problémának és kihívásnak: hogyan lehet megváltoztatni azoknak az embereknek a gondolkodását, akik nélkül nem lehet érdemi eredményeket elérni az ICS kiberbiztonság területén?

4. A fenyegetettségek jellemzőinek félreértelmezése és nem a megfelelő biztonsági intézkedések választása - Az ICS rendszerek világában, bár folyamatosan nő a biztonsági incidensek száma, még mindig nagyon kevés komoly esemény került nyilvánosságra és ezekről az incidensekről is olyan információk lettek publikálva, amit túl kevesen értenek. Ez oda vezet, hogy az ICS biztonsági megoldások fejlesztői sokkal inkább mesterségesen kialakított körülményekre tervezik és azokon is tesztelik a megoldásaikat, nem pedig valós támadók valós módszerei és eszközei ellen.

A Kaspersky teljes, angol nyelvű elemzése itt érhető el: https://media.kasperskycontenthub.com/wp-content/uploads/sites/43/2018/11/26142000/Threat-Predictions-for-Industrial-Security-in-2019.pdf

Sérülékenység ABB M2M ETHERNET firmware-ekben

Maxim Rupp egy nem megfelelő authentikációból adódó hibát fedezett fel a gyártóval közösen az ABB alábbi firmware-jeiben:

- M2M ETHERNET 2.22 és korábbi verziók;
- ETH-FW 1.01 és korábbi verziók.

A hibával kapcsolatban mostanáig nem érkezett hír javításról, a gyártó az eszközeihez kiadott műszaki kézikönyvekben leírt telepítési beállításokat javasolja kockázatcsökkentő intézkedésként. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-352-07

ABB CMS szoftverek sérülékenysége

Szintén Maxim Rupp és szintén egy nem megfelelő authentikációból adódó hibát jelentett a gyártóval együttműködve az NCCIC-nek, ami a CMS-770 1.7.1 és korábbi verzióiban található meg.

Az ABB ezzel a hibával kapcsolatban is a kiadott műszaki kézikönyvekben leírt telepítési beállításokat javasolja kockázatcsökkentő intézkedésként. A sérülékenységgel kapcsolatos további információk az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-352-06

Sérülékenységek Moxa NPort eszközökben

A gyártó publikációja szerint két sérülékenységet azonosítottak a Moxa alábbi berendezéseiben:

- NPort W2150A, 2.1 és korábbi firmware-verziók használata esetén;
- NPort W2250A, 2.1 és korábbi firmware-verziók használata esetén.

A gyártó a hibát a legújabb firmware-ben javította. A sérülékenységről további részleteket a Moxa webodalán lehet találni: https://www.moxa.com/support/faq/faq_detail.aspx?id=2726

CODESYS rendszerek sérülékenységei

Alexander Nochvay, a Kaspersky Lab munkatársa két sérülékenységet azonosított a 3S-Smart Software Solutions alábbi rendszereiben:

- CODESYS Control for BeagleBone;
- CODESYS Control for emPC-A/iMX6;
- CODESYS Control for IOT2000;
- CODESYS Control for Linux;
- CODESYS Control for PFC100;
- CODESYS Control for PFC200;
- CODESYS Control for Raspberry Pi;
- CODESYS Control RTE V3;
- CODESYS Control RTE V3 (Beckhoff CX-hez kiadott változat);
- CODESYS Control Win V3 (a CODESYS Development System setup-nak is része);
- CODESYS Control V3 Runtime System Toolkit;
- CODESYS V3 Embedded Target Visu Toolkit;
- CODESYS V3 Remote Target Visu Toolkit;
- CODESYS V3 Safety SIL2;
- CODESYS Gateway V3;
- CODESYS HMI V3;
- CODESYS OPC Server V3;
- CODESYS PLCHandler SDK;
- CODESYS V3 Development System
- CODESYS V3 Simulation Runtime (a CODESYS Development System része).

A gyártó a weboldalán kiadta a hibákat javító verziót. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-352-04

Sérülékenység CODESYS rendszerekben

Yury Serdyuk, a Kaspersky Lab munkatársa egy nem megfelelő hozzáférés-vezérlési funkcióban fedezett fel hibát, ami az alábbi, CODESYS termékcsaládba tartozó rendszereket érinti:

- Control for BeagleBone;
- CODESYS Control for BeagleBone;
- CODESYS Control for emPC-A/iMX6;
- CODESYS Control for IOT2000;
- CODESYS Control for Linux;
- CODESYS Control for PFC100;
- CODESYS Control for PFC200;
- CODESYS Control for Raspberry Pi;
- CODESYS Control RTE V3;
- CODESYS Control RTE V3 (Beckhoff CX-hez kiadott változat);
- CODESYS Control Win V3 (a CODESYS setup-nak is része);
- CODESYS V3 Simulation Runtime (a CODESYS Development System-nek is része);
- CODESYS Control V3 Runtime System Toolkit;
- CODESYS HMI V3.

A gyártó a hibát a 3.5.14.0 és újabb verziókban javította. A sérülékenység további részletei az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-352-03

Advantech WebAccess sérülékenység

Jacob Baines, a Tenable munkatársa egy, a bevitt adatok nem megfelelő ellenőrzéséből adódó sérülékenységet talált az Advantech WebAccess/SCADA 8.3.2-es, Windows Server 2008R2 SP1 operációs rendszerre telepített változatában.

A gyártó a hibát a 8.3.4-es verzióban javította. A sérülékenységgel kapcsolatosan további információkat az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-352-02

Sérülékenységek ABB GATE-E berendezésekben

Nelson Berg, az Applied Risk munkatársa két sérülékenységet azonosított az ABB alábbi, Pluto Safety PLC-khez használt Ethernet átjáróiban:

- GATE-E1 (EOL 2013);
- GATE-E2 (EOL OCT 2018).

Mindkét típus már elérte életciklusa végét, így a gyártó várhatóan már nem fog javítást készíteni a hibákhoz. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-352-01

Rockwell Automation FactoryTalk sérülékenység

Andrey Zhukov egy puffer-túlcsordulásos hibát fedezett fel a Rockwell Automation FactoryTalk Services Platform 2.90 és korábbi verzióiban.

A gyártó a hibát a szoftver legújabb verziójában javította. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://ics-cert.us-cert.gov/advisories/ICSA-18-331-02

Sérülékenység Schneider Electric EcoStruxure rendszerekben

Donato Onofri, a Business Integration Partners S.p.A munkatársa egy sérülékenységet talált a Schneider Electric alábbi rendszereiben:

- EcoStruxure Power Monitoring Expert (PME) Version 8.2 (minden kiadás);
- EcoStruxure Energy Expert 1.3 (korábbi nevén Power Manager);
- EcoStruxure Power SCADA Operation (PSO) 8.2 Advanced Reports and Dashboards Module;
- EcoStruxure Power Monitoring Expert (PME) Version 9.0;
- EcoStruxure Energy Expert Version 2.0;
- EcoStruxure Power SCADA Operation (PSO) 9.0 Advanced Reports and Dashboards Module.

A gyártó egyes érintett termékekhez kiadta a javítást a felfedezett hibára, a javított termékekkel és a sérülékenységgel kapcsolatos további információkat az ICS-CERT weboldalán lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-354-02

Horner Automation rendszerek sérülékenysége

rgod és mdm, a 9SG Security Team tagjai a ZDI-vel együttműködve jelentettek egy, a Horner Automation alábbi rendszereit érintő sérülékenységet az NCCIC-nek:

- Cscape Version 9.80.75.3 SP3 és korábbi verziók.

A gyártó a hibát a Cscape 9.80 SP4-ben javította. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-354-01

Sérülékenységek Schneider Electric EVLink rendszerekben

A gyártó bejelentése szerint Vladimir Kononovich és Vyacheslav Moskvin a Positive
Technologies munkatársai három sérülékenységet találtak az EVLink Parking v3.2.0
-12_v1 és korábbi verzióiban.

A gyártó a hibákat javító új verziót már elérhetővé tette. A sérülékenységekről további részleteket a Schneider Electric webodalán lehet találni.

Sérülékenység Schneider Electric Pro-Face GP-Pro EX termékekben

Yu Quiang, a Venustech-hez tartozó ADLab munkatársa egy sérülékenységet talált a Schneider Electric Pro-Face GP-Pro EX v4.08 és korábbi verzióiban.

A gyártó a sérülékenységet a V4.08.200 verzióban javította. A sérülékenységgel kapcsolatban bővebben a Schneider Electric weboldalán lehet olvasni.

Sérülékenységek Schneider Electric IIoT Monitor rendszerekben

A gyártó bejelentése szerint rgod a ZDI-vel együttműködve három sérülékenységet azonosított a Schneider Electric IIoT Monitor 3.1.38-as verziójában.

A gyártó a hibákat az IIoT Monitor legújabb verziójában javította. A sérülékenységek részleteit a Schneider Electric publikációjában lehet megtalálni.

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áltatások 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ű (valamilyen szinten tűzálló 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.

Napjainkban egyre többször lehet hallani a termelő vállalatok robotizálásáról (a hazai sajtó is mind gyakrabban foglalkozik a témával abban az összefüggésben, hogy a robotizálás drasztikus változásokat hozhat a termelésben dolgozók alkalmazásával kapcsolatban), ami kiválóan mutatja, hogy a negyedik ipari forradalom vagy másik nevén az Ipar 4.0 (Industry 4.0) legfontosabb eleme a gyártás-automatizálás. Ahogy azt az IT és az ICS világában már megszokhattuk, a gyártás-automatizáláshoz használt robotok esetén is a közgazdasági (elsősorban költség-megtakarítási) szempontok az elsődlegesek, az üzembe helyezett eszközök logikai biztonsága pedig háttérbe szorul. Ugyanakkor az ICS kiberbiztonság feltörekvő helyzetét mutatja, hogy ezzel a témával is egyre többen foglalkoznak, köztük már nagy IT biztonsági vállalatok is.

Még tavasszal a TrendMicro publikált egy tanulmányt az ipari robotok biztonsági helyzetéről. A vizsgálat során az ABB, a Kawasaki, a Fanuc és a Yaskawa termékeit vizsgálták A kutatók olyan hibákat találtak ezeknek a gyártóknak a termékeiben, amit kihasználva olyan változtatásokat tudtak végrehajtani a robotok beállításaiban, amiknek hatására megváltozott az előre beléjük programozott viselkedés.

Más sérülékenységek kihasználásával a kutatóknak lehetőségük nyílt váratlan és pontatlan mozgásra késztetni a robotokat, amik (ha arra gondolunk, hogy az eredetileg beléjük programozott mozgáshoz igazodó, a robotok között mozgó emberek testi épsége vagy akár élete is veszélybe kerülhet) akár a legkomolyabb biztonsági (safety) incidenseket is kiválthatnak. Ehhez képest sokkal kisebb jelentőségű, de a termelő vállalatok számára katasztrófális eredménnyel járhat az is, ha a kompromittált robotok nem látható, de komoly minőségi hibákkal rendelkező termékeket engednek le a futószalagról és emellett még számos más hatása is lehet a robotok sérülékenységeinek.

A TrendMicro kutatói szerint a most feltárt sérülékenységek közül néhányat nagyon könnyen javítani lehet, mások azonban sokkal nehezebben javíthatóak és még ha van is elérhető javítás a hibákhoz, nagyon fontos kérdés, hogy azok mikor lesznek (lesznek-e egyáltalán) telepítve?

Sérülékenység Medtronic orvostechnikai rendszerekben

Billy Rios és Jonathan Butts, a Whitescope LLC munkatársai egy sérülékenységet azonosítottak a Medtronic alábbi orvostechnikai berendezéseiben:

- CareLink 9790 Programmer minden verziója;
- CareLink 2090 Programmer minden verziója;
- 29901 Encore Programmer minden verziója.

A CareLink 9790 Programmer már elérte életciklusa végét, a CareLink 2090 Programmer és a 29901 Encore Programmer esetén a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja.

A sérülékenységről bővebben az ICS-CERT bejelentésében lehet tájékozódni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-347-01

Schneider Electric rendszer sérülékenységei

mdm és rgod, a 9SG Security Team tagjai a ZDI-vel együttműködve három sérülékenységet fedeztek fel az Eurotherm by Schneider Electric GUIcon 2.0 (Gold Build 683.0) verziójában.

A gyártó a hibákat a GUIcon Version 2.0 Software Package (Gold Build 683.003) verzióban javította. A sérülékenységgel kapcsolatban további információkat a gyártó és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenységek Siemens rendszerekben

Victor Nikitin, Vladislav Suchkov és Ilya Karpov, a ScadaX munkatársai két, a bevitt adatok nem megfelelő ellenőrzéséből adódó sérülékenységet találtak az alábbi Siemens termékekben:

- IEC 61850 protokollhoz tartozó EN100 Ethernet modulok minden, v4.33-nál korábbi firmware-verzió esetén;
- PROFINET IO protokollhoz tartozó EN100 Ethernet modulok minden firmware-verzió esetén;
- Modbus/TCP protokollhoz tartozó EN100 Ethernet modulok minden firmware-verzió esetén;
- DNP3 protokollhoz tartozó EN100 Ethernet modulok minden firmware-verzió esetén;
- IEC-104 protokollhoz tartozó EN100 Ethernet modulok minden firmware-verzió esetén;
- SIPROTEC 5 relék CP300-as és CP100-as CPU-val illetve az ezekhez tartozó Ethernet kommunikációs modulok v7.80-nál korábbi verziói;
- SIPROTEC 5 relék CP200-as CPU-val és az ezekhez tartozó Ethernet kommunikációs modulok v7.80-nál korábbi verziói.

A gyártó a SIPROTEC 5 relékhez és a 61850-es protokollt kiszolgáló EN100 Ethernet modulokhoz kiadta a javításokat tartalmazó új firmware-verziókat, a többi érintett termék esetén pedig még dolgozik a javításokon. A sérülékenységekről részletesebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-347-02

Geutebrück IP kamerák sérülékenysége

Davy Douhine, a RandoriSec munkatársa egy sérülékenységet azonosított a Geutebrück E2-es sorozatú IP kameráinak 1.12.0.25-nél korábbi firmware-verzióiban.

A gyártó a hibát az 1.12.0.25 verzióban javította. A sérülékenységről bővebb információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-347-03

Sérülékenység GE rendszerekben

Can Demirel, a Biznet Bilisim munkatársa egy sérülékenységet talált a GE alábbi rendszereiben:

- Mark VIe 03.03.28C verziótól 05.02.04C verzióig;
- EX2100e minden, v04.09.00C-nél korábbi verziója;
- EX2100e_Reg minden, v04.09.00C-nél korábbi verziója;
- LS2100e minden, v04.09.00C-nél korábbi verziója.

A gyártó kiadta a javítást a hibára. A sérülékenység részleteit az ICS-CERT weboldalán érdemes keresni: https://ics-cert.us-cert.gov/advisories/ICSA-18-347-04

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áltatások 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ű (valamilyen szinten tűzálló 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.

Kedden látott napvilágot a hír, hogy a Saipem nevű olasz, olaj- és gázipari szolgáltató vállalat rendszereit támadás érte. A részletek egyelőre ködösek, nem lehet tudni, hogy zsarolóvírus- vagy más jellegű támadás történt-e. A támadás leginkább a cég Közel-keleti országokban üzemelő szervereit érte, ide értve Szaúd-Arábiát, az Egyesült Arab Emirátusokat és Kuvaitot.

A Saipem a világ egyik vezető vállalati olaj- és gázkitermelésekhez használt fúróberendezések és kapcsolódó szolgáltatások terén.

A CyberX egyik ICS biztonsági alelnöke szerint, bár bizonyítékok ezúttal sem állnak rendelkezésre, sejteni lehet, hogy a támadás mögött ugyanazok állhatnak, akik 2012-ben és 2016-ban a Saudi Aramco elleni támadást végrehajtották, mert a Saipem egyik legnagyobb ügyfele a szaúdi olajcég.

Néhány forrás a hírrel kapcsolatban:

SecurityWeek
SecurityAffairs
CyberX

Sérülékenységek INVT Electric rendszerekben

Ariele Caltabiano, a ZDI-vel együttműködve két sérülékenységet fedezett fel az INVT Electric VT-Designer nevű szoftverének 2.1.7.31-es verziójában. A gyártótól mostanáig nem érkezett javítás a most publikált hibákkal kapcsolatban. A sérülékenységekről részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-333-01

SpiderControl SCADA WebServer sérülékenység

Ismail Bulbul egy, a SpiderControl SCADA WebServer 2.03.0001-nél korábbi verzióit érintő sérülékenységről tájékoztatta az NCCIC-t. A gyártó a hibát a 2.03.0001-es verzióban javította. A sérülékenységről bővebb információkat az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-338-02

Omron CX-One sérülékenységek

Esteban Ruiz, a Source Incite munkatársa a ZDI-vel együttműködve két sérülékenységről hozott nyilvánosságra részleteket, amelyek az Omron alábbi szoftvereit érintik:

- CX-Programmer 9.66 és korábbi verziói;
- CX-Server 5.0.23 és korábbi verziói.

A gyártó a hibákat a CX-Programmer 9.70-es és a CX-Server 5.0.24-es verzióiban javította. A sérülékenységekről további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-338-01

Sérülékenység Rockwell Automation PLC-kben

David Noren egy, a Rockwell Automation alább felsorolt PLC-iben található kritikus funkció esetén hiányzó authentikációból eredő hibát fedezett fel:

- MicroLogix 1400 vezérlők:
- A sorozat minden verziója;
- B sorozat, v21.003 és korábbi verziói;
- C sorozat, v21.003 és korábbi verziói.
- 1756 ControlLogix EtherNet/IP kommunikációs modulok:
- 1756-ENBT minden verziója;
- 1756-EWEB A sorozat minden verziója;
- 1756-EWEB B sorozat minden verziója.
- 1756-EN2F A sorozat minden verziója;
- 1756-EN2F B sorozat minden verziója;
- 1756-EN2F C sorozat, v10.10 és korábbi verziói.
- 1756-EN2T A sorozat minden verziója;
- 1756-EN2T B sorozat minden verziója;
- 1756-EN2T C sorozat minden verziója;
- 1756-EN2T D sorozat, v10.10 és korábbi verziói.
- 1756-EN2TR A sorozat minden verziója;
- 1756-EN2TR B sorozat minden verziója;
- 1756-EN2TR C sorozat, v10.10 és korábbi verziói.
- 1756-EN3TR A sorozat minden verziója;
- 1756-EN3TR B sorozat, v10.10 és korábbi verziói.

A sérülékenységgel kapcsolatban elérhető javítások listáját és a sérülékenység további részleteit az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-310-02

Sérülékenység GE rendszerekben

Vladimir Dashchenko, a Kaspersky Lab munkatársa egy sérülékenységet azonosított, amelyek a GE Cimplicity alábbi verzióit érintik:

- Cimplicity 9.0 R2;
- Cimplicity 9.5;
- Cimplicity 10.0

A gyártó a hibát javító verziót már elérhetővé tette. A sérülékenységgel kapcsolatban részletesebb információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-340-01

Philips egészségügyi rendszerek sérülékenysége

Egy névtelenségbe burkolózó biztonsági kutató egy nem megfelelő erősségű titkosításból eredő sérülékenységet jelentett a Philips-nek, ami minden Philips HealthSuite Health Android alkalmazást érint. A gyártó a hibát várhatóan 2019 első negyedévében fogja javítani, addig is kockázatcsökkentő intézkedéseket javasol az érintett termékét használó ügyfeleinek. A sérülékenységről bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-18-340-01

Sérülékenységek Siemens SINUMERIK vezérlőkben

Anton Kalinin, Danila Parnishchev, Dmitry Sklyar, Gleb Gritsai, Kirill Nesterov, Radu Motspan, és Sergey Sidorov, a Kaspersky Lab munkatársai a Siemens-szel együttműködve 10 különböző sérülékenységet azonosítottak a SINUMERIK CNC-vezérlők alábbi verzióiban:

- SINUMERIK 808D v4.7 minden verziója;
- SINUMERIK 808D v4.8 minden verziója;
- SINUMERIK 828D v4.7 minden, v4.7 SP6 HF1-nél korábbi verzió;
- SINUMERIK 840D sl v4.7 minden, v4.7 SP6 HF5-nél korábbi verzió;
- SINUMERIK 840D sl v4.8 minden, v4.8 SP3-nál korábbi verzió.

A gyártó már számos, érintett termékéhez kiadta a hibákat javító új verziókat, a többi érintett termék esetén pedig jelenleg is dolgozik a javításokon. A sérülékenységekről részletesebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenység Siemens SINAMICS PERFECT HARMONY GH180-as HMI-okban

A Siemens és a McAfee közös publikációja alapján a SINAMICS PERFECT HARMONY GH180-as HMI-okon futó MACC komponens hibája miatt az alábbi verziókban találtak sérülékenységet:

- SINAMICS PERFECT HARMONY GH180: MLFB 6SR32 sorozat;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR42 sorozat;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR52 sorozat;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR325 sorozat;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR32 sorozat, ha az HMI Microsoft Windows XP-n fut;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR42 sorozat, ha az HMI Microsoft Windows XP-n fut;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR52 sorozat, ha az HMI Microsoft Windows XP-n fut;
- SINAMICS PERFECT HARMONY GH180: MLFB 6SR325 sorozat, ha az HMI Microsoft Windows XP-n fut.

A Siemens és a McAfee ajánlása szerint az MLFB 6SR32, 6SR42 és 6SR52 sorozatú HMI-okat használó ügyfelek a McAfee ajánlásainak megfelelően frissítsenek a MACC v8.2.0 verziójára. A többi érintett verziót használó ügyfél számára kockázatcsökkentő intézkedések bevezetését javasolják.

A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Sérülékenység Siemens TIM 1531 IRC modulokban

A Siemens ProductCERT publikációja szerint a SIMATIC S7-1500, S7-400 és az S7-300 SINAUT ST7-tel szerelt berendezéseiben használt TIM 1531 IRC kommunikációs modulok V2.0-nál korábbi verzióiban hiányzik egy authentikáció a 102/tcp porton folytatott kommunikáció során.

A gyártó a hibát a TIM 1531 IRC modul V2.0 verziójában javította. A sérülékenységgel kapcsolatban bővebb információkat a Siemens ProductCERT publikációjában lehet olvasni.

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- 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áltatások 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ű (valamilyen szinten tűzálló 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.

Egy hónapja látott napvilágot a SANS Institute legújabb felmérése, amiben az intézet a különböző ipari szektorok szereplőinek ipari IoT biztonsággal kapcsolatos véleményére volt kíváncsi.

A felmérés alapján készült jelentés szerzői szerint "minél közelebbről ismeri valaki az IIoT biztonság témáját, annál jobban ismeri fel, milyen komoly kihívásról van szó". A jelek szerint az OT-ben dolgozó mérnökök a legkevésbé biztosak abban, hogy a szervezet, aminek dolgoznak, képes biztonságosan használni az IIoT berendezéseket, míg a vezetők (minél magasabb beosztásúak, annál inkább) biztosak abban, hogy nem lesz gond.

A felmérés szerint a legnagyobb problémának a válaszadók az IIoT eszközök közvetlen Internet-kapcsolatát tartják - ezek a berendezések igen gyakran kerülnek üzembe helyezésre anélkül, hogy az ICS biztonsággal kapcsolatos alapvető hálózati elkülönítés ajánlásait betartanák. Emiatt aztán egyre kevésbé fikció egy Internetről indított, ICS rendszert célzó támadás - ahogyan arra a DHS nyári webinar-sorozata is rámutatott, az Egyesült Államok villamosenergia-szektorában már történtek incidensek.

A felmérés másik érdekes megállapítása, hogy a válaszadók által ismert rendszerek kevesebb, mint 30%-a rendelkezik OT-specifikus monitoring megoldással. Anélkül, hogy az adott szervezetnek rálátása lenne a rendszerben végrehajtott változásokra, gyakorlatilag lehetetlen észlelni egy, az ICS rendszer elleni támadást addig, amíg már nem túl késő.

Szintén nagyon komoly problémának látszik a felmérés alapján, hogy még mindig csak a szervezetek 40%-a végzi megfelelően az ICS rendszerek patch-elését - már ahol egyáltalán van elérhető hibajavítás egy sérülékenységre (erről korábban már többször is volt szó itt a blogon, de ez is egy olyan aspektusa az ICS biztonságnak, amit nem lehet eleget hangsúlyozni).

A teljes, SANS Industiral IIoT Security Survey itt érhető el.