A hét elején rendezték Miami-ban az év hagyományosan első ICS biztonsági rendezvényét, az S4x-et. Az idei konferencia egyik legnagyobb visszhangot kapott előadása a Triton/Trisis néven ismertté vált, Schneider Electric Triconex safety rendszereket célzó malware és a szaúdi incidens részletesebb elemzésével foglalkozó előadás volt.

Az előadás szerint a korábban publikált információkkal szemben nem kettő, hanem 6 rendszert érintett az incidens és a vizsgálatban résztvevő kutatók szerint az incidens előtt két hónappal lett volna lehetőség a malware felfedezésére és a támadás megállítására. Állításuk szerint az első esetet a gyártó nem kezelte kibertámadásként és így nem is tették meg azokat az intézkedéseket, amik lehetővé tették volna a malware teljes eltávolítását a megtámadott rendszerekből, ez csak két hónappal később, 2017 augusztusában történt meg.

Az incidens több szempontból is úttörőnek számít, ez az első dokumentált eset, amikor a támadók kifejezetten a safety rendszereket célozták és legalábbis szokatlannak számít az is, ahogy a gyártó Schneider Electric publikussá tette a támadás nyomán indított vizsgálata során feltárt részleteket - ilyet eddig ICS/SCADA gyártótól még nem láttunk, de nagyon hasznos információforrás lehet nem csak az érintett safety rendszereket használó többi Schneider Electric ügyfélnek, hanem általában az ICS biztonsággal foglalkozó szakembereknek. Ritka az is, hogy az előadásban elhangzottakra (ti. hogy a gyártó az első, júniusi safety kontroller leállásnál nem ismerte fel, hogy kibertámadás okozta az eszköz leállását) a Schneider Electric viszonylag gyorsan reagált és rámutatott, miért nem volt lehetőségük ennél az esetnél felismerni, hogy malware-támadás áll az eset hátterében.

Az előadásról további részleteket a DarkReading illetve a CyberScoop cikkeiben lehet olvasni.

Tridium Niagara termékcsalád sérülékenység

Daniel Santos és Elisa Costante, a SecurityMatters munkatársai egy Cross-Site Scripting sérülékenységet találtak a Tridium Niagara termékcsaládjának alábbi tagjaiban:

- Niagara Enterprise Security 2.3u1 minden, 2.3.118.6-nál régebbi verziója;
- Niagara AX 3.8u4 minden, 3.8.401.1-nél korábbi verziója;
- Niagara 4.4u2 minden, 4.4.93.40.2-nél régebbi verziója;
- Niagara 4.6 minden, 4.6.96.28.4-nél korábbi verziója.

A hibát a gyártó az egyes termékek legújabb verziójában javította. A sérülékenység részletei az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-333-02

Sérülékenység Emerson DeltaV rendszerekben

Alexander Nochvay, a Kaspersky Lab munkatársa egy authentikáció megkerülést lehetővé tevő hibát azonosított az Emerson DeltaV DCS rendszereinek 11.3.1, 11.3.2, 12.3.1, 13.3.1, 14.3, R5.1, R6 és korábbi verzióiban.

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

Omron rendszerek sérülékenysége

Esteban Ruiz (mr_me), a Source Incite munkatársa a ZDI-vel együttműködve egy sérülékenységről hozott nyilvánosságra információkat, ami az Omron alábbi rendszereit érinti:

- CX-One 4.50 és korábbi verziói;
- CX-Protocol 2.0 és korábbi verziói.

A gyártó a hibát a legújabb verzióban javította. A sérülékenységről bővebben az ICS-CERT weboldalán lehet információkat találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-010-02

Sérülékenység Pilz rendszerekben

Gjoko Krstikj, az Applied Risk munkatársa egy eddig ismeretlen sérülékenységet talált a Pilz PNOZmulti Configurator 10.9 és korábbi verzióiban, ami egy safety rendszerek konfigurálásához használható szoftver.

A sérülékenységgel kapcsolatosan további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-010-03

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.

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