Sérülékenységek Johnson Controls rendszerekben

Az ICS-CERT publikációja szerint a Tridium Niagara két sérülékenységről adott információt a Johnson Controls-nak, amik a gyártó alábbi termékeit érintik:

- Facility Explorer 14.4u1-nél korábbi 14-es verziói;
- Facility Explorer 6.6-nál korábbi 6-os verziói.

A gyártó a hibát a 14.6-os, 14.4u1-es és 6.6-os Facility Explorer verziókban javította. A sérülékenységekről további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-022-01

Dräger rendszerek sérülékenységei

Marc Ruef és Rocco Gagliardi a scip AG munkatársai 3 sérülékenységet azonosítottak a Dräger betegmonitorozásra használt alábbi rendszereiben:

- Infinity Delta, minden verzió;
- Delta XL, minden verzió;
- Kappa, minden verzió;
- Infinity Explorer C700, minden verzió.

A gyártó a hibák javítását tartalmazó verziókat 2018 decemberében elérhetővé tette. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-022-01

Sérülékenységek Advantech WebAccess/SCADA rendszerekben

Devesh Logendran of Attila Cybertech Pte. Ltd. munkatársa 3 sérülékenységet fedezett fel az Advantech WebAccess/SCADA 8.3-as verziójában.

A gyártó a hibákat a 8.3.5-ös verzióban javította. A sérülékenységekről részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-024-01

Sérülékenységek Phoenix Contact rendszerekben

A Phoenix Contact a Positive Technologies munkatársaival, Evgeniy Druzhinin-nal, Ilya Karpov-val és Georgy Zaytsev-vel együttműködve 6 sérülékenységet azonosíottak, amik a gyártó FL SWITCH 3xxx, 4xxx és 48xx sorozatú eszközeinek 1.35-ösnél korábbi verzióit érintik.

A gyártó a hibát az 1.35-ös és újabb verzióban javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-024-02

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.

Elég sokszor esik szó az ICS biztonság világában arról, hogy az USA villamosenergia-rendszerét különböző támadók, idegen hatalmak próbálják kompromittálni, legtöbbször az oroszokat, kínaiakat és az irániakat említik, amikor megnevezik, hogy elsősorban kik állhatnak a támadások mögött. Ezek a hírek láthatóan az USA hivatalos szerveit is aggasztják, ennek jele volt tavaly nyáron a két héten át tartó DHS webinar-sorozat is.

2018 novemberében a DARPA, az amerikai védelmi kutatásokkal foglalkozó ügynökség a Long Island (New York állam) melletti kis szigeten, Plum Island-en az USA villamosenergia-rendszerét ért kibertámadást szimuláló gyakorlatot tartott. A gyakorlat célja az volt, hogy minél életszerűbb körülmények között tudják tesztelni egy, a teljes villamosenergia-rendszert érintő leállás utáni újrainduláshoz használatos eljárásokat. Ehhez Plum Island kifejezetten alkalmas, mert a New York-i Central Park-nál alig nagyobb szigeten 18 alállomás, két vezénylőközpont és két erőmű is van.

A gyakorlatról bővebben a Sophos Naked Security blogjában lehet olvasni, a DARPA pedig már az idén májusra tervezett, a korábbinál is összetettebb gyakorlat előkészítésén dolgozik, hiszen ahogy láthattuk az elmúlt években, a villamosenergia-rendszer elleni támadások egyre gyakoribbak. Már csak az a kérdés, hogy Európában illetve Magyarországon mikor lesz ilyen gyakorlat (hozzátéve, hogy 2014-ben már volt egy kezdeményezés és egy gyakorlat, aminek azóta sajnos érdemi folytatása a villamosenergia-szektorban nem volt)?

A CVSS (Common Vulnerability Scoring System) rendszer széles körben ismert és használt az informatikai rendszerek sérülékenységeinek osztályozásához. Jelenleg a CVSSv3 az általánosan használt módszer, ami lehetőséget ad egy alap pontszám kalkulálására a támadási vektor, a támadás komplexitása, a szükséges jogosultságok és felhasználói interakció, a sérülékenység hatókörének és a bizalmasság-sértetlenség-rendelkezésre állás hármas faktorok figyelembe vételével.

Október végén, az atlantai ICS Cyber Security konferencián a Radiflow alapító-vezérigazgatója, Ilan Barda előadásában arra hívta fel a figyelmet, hogy a CVSS pontozásos módszerét eredetileg IT rendszerekre dolgozták ki és ismerve az IT és ICS rendszerek közötti különbségeket, ez problémákat jelenthet az érintett (jellemzően ipari) szervezetek számára.

Számos további ICS biztonsági szakértő (többek között a Nozomi Networks-től, a Positive Technologies-tól, a Kaspersky Lab ICS-CERT-jétől, stb.) is megszólalt a témában és a véleményeik nagyjából egyezik abban, hogy a CVSS alapján történő sérülékenység-kategorizálás hasznos útmutató lehet, de nem szabad csak erre építeni és vakon bízni benne, sokkal inkább csak kiindulási pontként célszerű használni az egyes sérülékenységek adott szervezetre vonatkozó.

A hivatkozott előadás videója itt érhető el, a témában írt SecurityWeek cikk pedig itt, amiben több példán is bemutatják, hogyan vezethet félre ICS sérülékenységek esetén, ha kizárólag a CVSS-besorolás alapján ítéljük meg egy-egy ICS sérülékenység kockázatait.

Sérülékenységek LCDS LAquis SCADA rendszerekben

Esteban Ruiz (mr me) a ZDI-vel együttműködve nem kevesebb, mint 11 különböző sérülékenységet azonosított az LCDS (Leão Consultoria e Desenvolvimento de Sistemas Ltda ME) LAquis SCADA nevű SCADA rendszerének 4.1.0.3870-es verziójában.

A gyártó a hibákat a 4.1.0.4150-es verzióban javította. A sérülékenységekről részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-015-01

ControlByWeb berendezések sérülékenységei

John Elder és Tom Westenberg, az Applied Risk munkatársai a ControlByWeb X-320M típusú időjárás-előrejelzéshez használt berendezéseinek v1.05 és korábbi firmware-verzióiban találtak két sérülékenységet.

A gyártó a hibákat a v1.06-os firmware-ben javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-017-03

Sérülékenység ABB szoftverekben

Ivan Sanchez, a NullCode munkatársa egy sérülékenységet azonosított az ABB Control Panel Software Suite csomagjához tartozó CP400PB, a CP405-ös és CP408-as berendezésekhez használható Panel Builder szoftverének 2.0.7.05-ös és korábbi verzióiban.

A gyártó a hibát a 2.1.7.21-es 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-19-017-02

Sérülékenységek Omron CX-Supervisor rendszerekben

Esteban Ruiz (mr me) a ZDI-vel együttműködve 5 sérülékenységet azonosított az Omron CX-Supervisor 3.42 és korábbi verzióiban.

A gyártó a hibákat a 3.5.0.11-es verzióban javította. A sérülékenységek részleteit az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-19-017-01

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.

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