Sérülékenység Rockwell Automation rendszerekben

A Rockwell Automation a Tenable-vel együttműködve egy kritikus besorolású puffer-túlcsordulás sérülékenységet találtak az RSLinx Classic PLC-k 4.10.00 és korábbi verzióiban.

A gyártó a hibát javító patch-et a v3.60, v3.70, v3.80, v3.81, v3.90, v4.00.01 és v4.10-es verziókhoz készítette el. 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-064-01

Sérülékenység Siemens SCALANCE X ipari switch-ekben

A Siemens ProductCERT bejelentése szerint egy sérülékenységet találtak a SCALANCE X ipari switch-ekben, ami a termékcsalád alábbi tagjait érinti:

- SCALANCE X-200 minden verziója;
- SCALANCE X-300 minden verziója;
- SCALANCE XP/XC/XF-200 minden, V4.1-nél korábbi verziója.

A gyártó az XP/XC/XF-200-as eszközök esetén a V4.1-es verzióba javította a hibát, az X-200-as és X-300-as eszközöknél kockázatcsökkentő intézkedésekre tett javaslatot. A sérülékenységről további információkat a Siemens ProductCERT weboldalán lehet találni.

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.

Március 8-a óta Venezuela területének nagyjából 70%-án komoly áramszünetek vannak, emitt fennakadások vannak a tömegközlekedésben és egyes források szerint különböző kórházakban már legalább négyen haltak meg, szintén az áramszünetek következtében.

Venezuelai politikusok viszonylag gyorsan megvádolták az USA-t, hogy kibertámadást hajtottak végre a Venezuela Bolivár államában található Guri vízerőmű ellen, ami kb. az ország villamosenergia-ellátásának 70%-át adja. A hírt a LinkedIn-en több ICS biztonsági szakember is megosztotta (különböző forrásokból) és szinte rögtön megindult a vélemények áradata, részben tényként kezelve a venezuelai politikusok állítását, mások pedig nagyon határozottan foglaltak állást amellett, hogy az USA-nak semmilyen köze nincs, nem lehet az eseményekhez.

Egy biztos, egyelőre semmilyen bizonyíték nem támasztja alá sem a kibertámadás verzióját, sem azt a verziót (bár tény, hogy jóval valószínűbbnek látszik - számomra legalábbis), hogy az egyre nagyobb gazdasági nehézségekkel küzdő Venezuelában nem jut elég pénz, alkatrész és szakember az időszerű karbantartások elvégzésére, így akár egy "hétköznapi" üzemzavar is okozhat ekkor kiesést a villamosenergia-ellátásában.

Részletek az alábbi (és számos más) hírforrásokban:

- CNN

- BBC

- The Guardian

Fairuz Rafique, a Galactic Security munkatársa nemrég egy LinkedIn bejegyzésben írt arról, a grúziai Gudauri Ski Resort sífelvonóján még 2018 márciusban történt incidensről, amiben tizenketten sérültek meg. Bár a grúz illetékesek szerint a balesetet a sílift meghibásodása okozta, Fairuz szerint biztonsági kutatók ugyanazon a napon fedezték fel, hogy a sílift vezérlő rendszere elérhető volt az Internetről.

Az eset nyomán Joe Weiss ismét azt a (már 2015-ben is boncolt) témát járja körül, hogy az ICS rendszerek esetén van-e értelme különbséget tenni a szándékos (kibertámadás) és a nem szándékos (rendszerhiba, üzemeltetői hiba) ICS kiberbiztonsági incidensek között? Joe fontosabb észrevételei a téma kapcsán:

- Az NIST kiberbiztonsági szótára szerint "a kiberbiztonsági incidens olyan potenciális vagy ténylegesen bekövetkezett esemény, amely veszélyezteti az információs rendszer vagy az információs rendszer által feldolgozott, tárolt vagy továbbított információ bizalmas kezelését, integritását vagy elérhetőségét, vagy amely a biztonsági szabályok, eljárások megsértésének vagy közvetlen fenyegetésének minősül". Ebben a definícióban sehol nem szerepel a szándékos kitétel és ezen definíció alapján a fenti eset egyértelműen kiberbiztonsági incidensnek számít, hiszen a sílift rendelkezésre állása sérült (és akkor még nem is beszélünk a biztonsági - safety - tényező sérüléséről, hiszen emberek kerültek veszélybe és sérültek meg).

- Számos olyan esetről tudunk (az egyik még nevet is kapott, Stuxnet néven szoktuk emlegetni), amikor a szándékos és a véletlen ICS kiberbiztonsági incidenst csak az adott mérnök hozzáállása különböztette meg egymástól (az "A fenébe ezzel az egésszel!" és a "Hoppá..." pillanatok közötti különbség). Ráadásul egy jól felkészült támadó képes lehet a kibertámadása nyomán előálló üzemzavart egy ideig rendszerhibának álcázni - erre végképp tökéletes példa a Stuxnet.

- Az ICS rendszerekben, szemben az IT világával, a kiterjedt és alapos forensics vizsgálatoknak nincs meg a hagyománya és hiányzik a (kiberbiztonsági, főként forensics szempontból) megfelelően képzett OT mérnökök hada, akik képesek lennének az ICS rendszerek hosszabb ideig tartó leállása nélkül vizsgálni egy-egy incidens kiváltó okait. Az IT biztonsági incidensek esetén évek óta tudjuk, hogy az első támadás és a támadók felfedezése között akár 200-400 nap is eltelhet, ezért aztán, figyelembe véve az ICS kiberbiztonság igen korai érettségi állapotát, nem csoda, hogy az orosz hátterűnek tulajdonított, amerikai villamosenergia-rendszer elleni támadásokat 7 hónap utána fedezték fel, a 2015-ös ukrán áramszolgáltatók elleni támadás előtt a (szintén orosznak gyanított) támadók 9 hónapig rendelkeztek hozzáféréssel a kompromittált rendszerekhez - és akkor sem az adott cégek szakemberei fedezték fel a támadókat, hanem ők maguk mutatták meg magukat.

Joe záró gondolata, hogy alapvető fontosságú minden ICS biztonsági incidens alapos és minden részletre kiterjedő vizsgálatát elvégezni, még akkor is, ha "szinte biztos", hogy az adott üzemzavart nem kibertámadás okozta.

Már maga ez a cikk is érdekes gondolatokat vetett fel, de a SANS ICS Community-ben ennek nyomán elindult beszélgetés (csak regisztráció után olvasható!) még érdekesebb:

- Van, aki szerint igenis számít a különbség, mégpedig azért, ha meg akarjuk előzni egy incidens megismétlődését, akkor ismerni kell a kiváltó okát (root cause).

- Egy másik érv a biztosítási szektorból érkezik, akiket szintén nagyon érdekel egy adott incidens kiváltó oka.

Egy biztos, ezt a témát itthon eddig nem nagyon érintette senki. Szerintem itt lenne az ideje.

Sérülékenységek Moxa ipari switchekben

Ivan B, Sergey Fedonin és Vyacheslav Moskvin, a Positive Technologies munkatársai nem kevesebb, mint 10 sérülékenységet azonosítottak a Moxa alábbi, ipari környezetekbe szánt hálózati eszközeiben:

- IKS-G6824A sorozat 4.5 és korábbi verziói;
- EDS-405A sorozat 3.8 és korábbi verziói;
- EDS-408A sorozat 3.8 és korábbi verziói;
- EDS-510A sorozat 3.8 és korábbi verziói.

A gyártó a hibákat javító patch-eket már elérhetővé tette a weboldalán. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-057-01

PSI GridConnect rendszerek sérülékenysége

M. Can Kurnaz egy Cross-site Scripting sérülékenységet talált a PSI GridConnect alábbi megoldásaiban:

- Telecontrol Gateway 3G 4.2.21, 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- Telecontrol Gateway XS-MU 4.2.21, 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- Telecontrol Gateway VM 4.2.21, 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- Smart Telecontrol Unit TCG 5.0.27, 5.1.19, 6.0.16 és korábbi verziói;
- IEC104 Security Proxy 2.2.10 és korábbi verziói.

A gyártó a hibát az érintett szoftverek legújabb verzióiban javította. A sérülékenységgel kapcsolatban részleteket az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-059-01

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.

A Censys egy több, mint három éve létező kereső, ami a Shodan-hoz hasonlóan nem a webes tartalmakra keres kulcsszavak alapján, hanem az Internetre csatlakoztatott rendszerek és eszközök (így köztük különböző ICS eszközök) adataiban keres és képes akár ezeknek a rendszereknek és eszközöknek egyes konfigurációs adatait is hozzáférhetővé tenni.

A Censys a ZMap scannert használja, ami megjelenésekor azzal keltett nagy feltűnést, hogy a teljes publikus IPv4 címtartományt képes volt meglepően rövid idő alatt (egy napon belül) végigvizsgálni, így pedig lehetőséget ad arra, hogy a Censys-szel egy napi frissítettségű adatbázist lehessen létrehozni az Interneten elérhető rendszerekről és eszközökről.

A Censys ráadásul egyéni felhasználásra teljesen ingyenes (még a Shodan-nál szokásos évenkénti, black friday-hez kötött akciós, 5 dolláros egyszeri előfizetést sem kell kifizetni) és nagyon gyorsan nagyon részletes adatokat lehet gyűjteni egy adott ICS gyártó eszközeiről vagy egy adott szervezet Internetes jelenlétéről.

Mindezeket figyelembe véve megint csak azt tudom tanácsolni minden, ICS rendszerekkel/berendezésekkel foglalkozó kollégának: alaposan és kétszer vagy akár háromszor is fontolják meg, mielőtt bármilyen ICS eszközt publikus hálózatra csatlakoztatnak, ha pedig nincs más lehetőségük, rendszeresen vizsgálják meg, hogy az eszközeikről/rendszereikről a Shodan, a Censys és esetleges más, hasonló megoldások milyen információkat szolgáltatnak egy ügyesen kérdező embernek.

Pangea Communications rendszerek sérülékenysége

Ankit Anubhav, a NewSky Security munkatársa egy authentikáció megkerülést lehetővé tevő hibát fedezett fel a Pangea Communications Internet FAX ATA (Analóg-Telefon Adapter) berendezésének 3.1.8 és korábbi verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette az ügyfelei számára.

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-045-01

Sérülékenység a gpsd nyílt forráskódú projektben

A GE Digital Cyber Security Services a GE-PSIRT együttműködve jelentett egy sérülékenységet az NCCIC-nek, ami a nyílt forráskódú GPS megoldás alábbi szoftverkomponenseit érinti:

- gpsd 2.9.0-től 3.17-ig terjedő verziói,
- microjson 1.0-tól 1.3-ig terjedő verziói.

A hibát a fejlesztők a gpsd 3.18-as és újabb, illetve a microjson 1.4 és újabb verzióiban javították. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-310-01

OSIsoft PI Vision sérülékenység

Az OSIsoft az alábbi, folyamatvirtualizációhoz használható megoldásaiban talált egy Cross-site Scripting sérülékenységet:

- PI Vision 2017,
- PI Vision 2017 R2.

A gyártó a hibát a PI Vision 2017 R2 SP1 verzióban javította. A sérülékenységgel kapcsolatoban részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-043-01

Sérülékenységek Intel szoftverekben

Az Intel Product Security Incident Response Team-je 11 különböző sérülékenységet azonosított és jelentett az NCCIC-nek, amik a gyártó Data Center Manager SDK 5.0.2-nél korábbi verzióit érintik.

Az Intel a sérülékenységeket a Data Center Manager SDK 5.0.2-es verziójában javította. A sérülékenységekkel kapcsolatban részletesebb információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-01

Delta CNCSoft sérülékenység

Natnael Samson a ZDI-vel együttműködve egy sérülékenységet azonosított a Delta Industrial Automation CNCSoft ScreenEditor 1.00.84 és korábbi verzióiban.

A gyártó a hibát az 1.01.15-ös verzióban javította. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-02

Sérülékenység Horner Automation rendszerekben

Egy névtelenségbe burkolózó biztonsági kutató a ZDI-vel együttműködve azonosított egy hibát a Horner Automation Cscape szoftverének 9.80 SP4-es és korábbi verzióiban.

A gyártó a hibát a Cscape legutolsó, 9.90-es verziójában javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-03

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

Luca Chiou, az ACSI munkatársa két sérülékenységet talált a Rockwell Automation Allen-Bradley Power Monitor 1000 összes verziójában.

A gyártó jelenleg is dolgozik a sérülékenységek javításán és megerősítette, hogy a CheckPoint IPS eszközei már képesek felismerni a sérülékenységeket kihasználni próbáló hálózati forgalmakat. A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-04

Sérülékenységek Siemens SIMATIC IPC-k Intel AMT komponenseiben

A Siemens ProductCERT bejelentése szerint az Intel AMT komponensek három sérülékenysége érinti az alábbi SIMATIC IPC berendezéseket:

- SIMATIC FieldPG M5 minden, v22.01.06-nál korábbi verziója;
- SIMATIC IPC427E minden, v21.01.09-nél korábbi verziója;
- SIMATIC IPC477E minden, v21.01.09-nél korábbi verziója;
- SIMATIC IPC547E minden, R1.30.0-nél korábbi verziója;
- SIMATIC IPC547G minden, R1.23.0-nál korábbi verziója;
- SIMATIC IPC627D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC647D minden, v19.01.14-nél korábbi verziója;
- SIMATIC IPC677D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC827D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC847D minden, v19.01.14-nél korábbi verziója;
- SIMATIC ITP1000 minden, v23.01.04-nél korábbi verziója.

A gyártó a hibákat az érintett szoftverek legújabb verzióiban javította. A sérülékenységekről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenység Siemens berendezésekben

Lars Lengersdorf, az Amprion munkatársa egy sérülékenységet azonosított a Siemens alábbi berendezéseiben:

- EN100 Ethernet modul IEC-61850 protokollhoz minden, v4.35-nél korábbi firmware-verzió esetén;
- EN100 Ethernet modul MODBUS/TCP protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul DNP3/TCP protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul IEC-104 protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul Profinet IO protokollhoz minden firmware-verzió esetén;
- SIPROTEC 5 relék CP300 és CP100 processzorral szerelt példányainak minden, v7.82-nél korábbi verziója;
- SIPROTEC 5 relék CP200 processzorral szerelt példányainak minden, v7.58-nál korábbi verziója.

A hibát a gyártó az érintett eszközök legújabb firmware-verzióiban javította. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SICAM rendszerek licenckezelő szoftverének sérülékenységei

A Siemens három sérülékenységet jelentett az NCCIC-nek, amik a SICAM 230-as sorozatú berendezéseinek 7.20-as és korábbi verzióinál használt licenckezelő szoftverét érintik.

a gyártó a hibát a licenckezelő szoftver legújabb verziójában javította. A sérülékenységekkel kapcsolatban részletesebb információkat a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

SPECTRE sérülékenység Siemes SIMATIC ipari vékonykliensekben

A Siemes ProductCERT bejelentése szerint az alábbi SIMATIC ipari vékonyklienseiket érintik a SPECTRE néven ismertté vált sérülékenység V1 és V4 variánsai:

- SIMATIC ITC1500 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1500 V3 PRO összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1900 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1900 V3 PRO összes, V3.1-nél korábbi verziója;
- SIMATIC ITC2200 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC2200 V3 PRO összes, V3.1-nél korábbi verziója.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedésekre tett javaslatokat. A sérülékenységekről bővebb információkat a Siemens ProductCERT oldalán tettek közzé: https://cert-portal.siemens.com/productcert/pdf/ssa-505225.pdf

Sérülékenységek Schneider Electric SoMachine és Modicon rendszerekben

A Schneider Electric publikációja szerint több sérülékenységet azonosítottak az alábbi termékeikben:

- SoMachine Basic összes verziója;
- Modicon M221 minden verziója a V1.10.0.0-nál korábbi firmware-ek esetén.

A gyártó a hibákat a Modicon M221 V1.10.0.0 firmware-verziójában és az EcoStruxure Machine Expert – Basic v 1.0-ban javította. A sérülékenységekről részleteket a Schneider Electric publikációjában lehet találni.

Schneider Electric Vijeo Designer Lite sérülékenység

A Schneider Electric Vijeo Designer Lite nevű szoftverében, amit az alábbi berendezéseik konfigurációjához lehet használni, egy sérülékenységet azonosítottak:

- XBTN200;
- XBTN400;
- XBTN401;
- XBTN410;
- XBTNU400;
- XBTR400;
- XBTR410;
- XBTR411;
- XBTRT500;
- XBTRT511.

A Vijeo Designer Lite gyártói támogatása 2017 júniusában megszűnt, így a hiba kapcsán a gyártó csak kockázatcsökkentő intézkedéset javasol:

- A Vijeo Designer Lite-ot használó ügyfelei a szoftvert csak erre dedikált rendszeren használják a minimálisan szükséges jogosultságokkal rendelkező jogosultságokkal;
- Csak megbízható forrásból származó DOP projektfájlokat nyissanak meg.

A sérülékenységről több információt a Schneider Electric bejelentéséből lehet szerezni.

Sérülékenységek Schneider Electric ipari kamerákban

A Schneider Electric által közzétett információk szerint az alábbi ipari kameráikban több sérülékenység is található:

Pelco Sarix Enhanced első generációs kamerák:
- Beltéri kamerák:
- IMES19-1I, IMES19-1S, IMES19-1P;
- IME119-1I, IME119-1S, IME119-1P;
- IME219-1I, IME219-1S, IME219-1P;
- IME319-1I, IME319-1S, IME319-1P;
- IME319-B1I, IME319-B1S, IME319-B1P;
- IME3122-1I, IME3122-B1I, IME3122-1S, IME3122-B1S, IME3122-1P, IME3122-B1P;
- Környezeti kamerák, mini dómok:
- IMES19-1EI, IMES19-1ES, IMES19-1EP;
- IME119-1EI, IME119-1ES, IME119-1EP;
- IME219-1EI, IME219-1ES, IME219-1EP;
- IME319-1EI, IME319-1ES, IME319-1EP;
- IME3122-1EI, IME3122-1ES, IME3122-1EP;
- Vandálbiztos mini dómok:
- IMES19-1VI, IMES19-1VS, IMES19-1VP;
- IME119-1VI, IME119-1VS, IME119-1VP;
- IME219-1VI, IME219-1VS, IME219-1VP;
- IME319-1VI, IME319-1VS, IME319-1VP;
- IME3122-1VI, IME3122-1VS, IME3122-1VP;
- Box kamerák:
- IXES1;
- IXE11;
- IXE21;
- IXE31;
Spectra Enchanced kamerák:
- D6220, D6220L;
- D6230, D6230L.

A gyártó a hibákat a Sarix Enchanced kamerák 2.2.3.0 és a Spectra Enchanced 2.11-es és újabb verziójú firmware-jeiben javította. A sérülékenységekkel kapcsolatban további információkat a Schneider Electric weboldalán lehet olvasni.

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.

Az IT biztonság területén már viszonylag megszokott az új típusú kártevők és fenyegetések felbukkanása, így volt ez a zsarolóvírusokkal is, amelyek néhány évvel ezelőtti felbukkanása után elég gyorsan meg kellett szokni a létezésüket és meg kellett tanulniuk az érintett szakembereknek együttélni ezekkel az új fenyegetésekkel. 2017-ben a WannaCry, majd a NotPetya támadások idején az ICS rendszerek egy része szintén érintett volt, de nem volt információnk olyan titkosító-zsaroló malware-ről, amit kifejezetten ICS rendszerek ellen terveztek és vetettek volna be. Eddig.

Az ESET blogján most szerdán jelent meg az a cikk, amiben a bűnözők egyik új taktikáját mutatják be, neveztesen az épület-automatizálási rendszerek (Business Automation Systems) elleni zsarolóvírus támadásokat. A jelenségnek már saját neve is van, a kutató siegeware-nek nevezték, magyarul szó szerinti fordításban ostromvírusnak lehet fordítani, de én ezt kicsit esetlennek érzem, ezért inkább az eredeti megnevezéssel fogok hivatkozni ezekre az új kártevőkre.

Nagyon röviden, hogy mik is az épületautomatizálási rendszerek. A BAS rendszerek jellemzően a nagyobb épületek üzemeltetéséhez szükséges folyamatok automatizlását lehetővé tevő rendszerek (füstérzékelő és tűzjelző rendszerek, központi hűtő-, fűtő- és légkondícionáló rendszerek, automata tűzoltó rendszerek, világításvezérlő rendszerek, az épületekbe integrált biztonsági és fizikai hozzáférés-vezérlő, beléptető rendszerek, épületen belüli villamosenergia-menedzsment rendszerek, különösen az adatközpontok szünetmentes tápellátását biztosító rendszerek, stb.).

Most képzeljük el azt az esetet, amikor egy nagy irodaházat üzemeltető cég dolgozói egy e-mail vagy SMS üzenetet kapnak az alábbi szöveggel: “Az xxxxxxxx címen található épület összes vezérlő rendszere felett átvettük az irányítást és leállítjuk őket, amennyiben nem fizetnek 24 órán belül 10.000.000 Forintot Bitcoinban az alábbi számlára.” Hogy ilyen csak a filmekben történhet? Már többször megtörtént, legalábbis a hivatkozott ESET cikk szerint, ami azt állítja, hogy egy, a fentihez hasonló esetben a rendőrséghez forduló áldozatnak a hatóság emberei állították, hogy nem az első ilyen panasz érkezik hozzájuk.

Hogyan lehetséges egyáltalán egy ilyen támadást végrehajtani? Anélkül, hogy tippeket akarnék adni a támadóknak, azt tudom mondani, hogy pont ugyanúgy, mint bármilyen más ICS rendszer elleni támadás esetén:

1. A BAS rendszerek egy jelentős hányada minden ellenkező ajánlás ellenére elérhető az Interneten, egy gyors Shodan vagy Censys keresés akár több 10.000 találatot is adhat.

2. A BAS rendszerek általános kiberbiztonsági állapota semmivel sem jobb (vagy ami azt illeti, rosszabb), mint az átlagos ICS rendszereké, ami ugye azt jelenti, hogy elég gyenge.

A helyzet tehát az, hogy (ahogy azt 2017 illetve 2018 végén a szakértők már jósolták) egyre terjednek az ICS rendszereket célzó malware-ek és támadások. Lehetséges, hogy kicsit lassabban, mint ahogyan vártuk, de ezek a (időnként még csak elméleti) fenyegetések egyre inkább valósággá válnak, az ICS rendszereket üzemeltetőknek pedig időben el kell kezdeniük felkészülni arra, hogy az ő rendszereik is célponttá válhatnak.

Kifejezetten érdekes a BAS rendszerek és üzemeltetőik helyzete, hiszen a nagyobb irodaházak mellett minden nagyobb adatközpontban is megtalálhatóak ezek a rendszerek, tehát még arra sincsen szükség, hogy az adott szervezet ipari tevékenységet (közmű-szolgáltatás, gyártás, stb.) végezzen, elég, ha a támadók egy nagyobb bank adatközponti BAS rendszereit támadják siegeware-rel - vajon melyik bank vállalja azt, hogy akár napokra leállnak a legfontosabb rendszerei vagy inkább fizetnek a támadóknak?

Nemrég egy kollégától kaptam ennek az előadásnak a hivatkozását, amiben Andreas Klien, az OMIRCRON osztrák munkatársa nagyon jól foglalja össze a főként az alállomási automatizálásban használt IEC 61850-es ipari protokoll kiberbiztonsági problémáit és a lehetséges támadási formákat. Az előadásban megjelennek magukat régóta makacsul tartó mítoszok ("Miért kéne foglalkozni az alállomási berendezések kiberbiztonságával, ha egy teherautóval is be lehet törni az alállomásra?" vagy "A soros porti kommunikáció és a régi, nem dokumentált protokollok biztonságosabban, mint az Ethernet portok és a modern, nyílt protokollok.")

Az előadás egyik legfontosabb gondolata a kockázatkezelés és nagyon helyesen kiemeli azt is, hogy a legfőbb kockázatok egyike a folyamatok irányításába bevont ember és így a leghatékonyabb és legfenyegetőbb támadási formák egyike a social engineering.

Úgy gondolom, hogy az ilyen szakmai előadásoknak nagyon nagy szerep hárulhatna a hazai szakma ICS biztonságtudatosságának javításában (sajnos még mindig azt tapasztalom, hogy néhány elszánt úttörőtől eltekintve a szakma legtöbb képviselője nem kér az OT és az IT biztonsági szakterületek együttműködéséből, hiszen mennyivel könnyebb ülni a saját elefántcsont-tornyunkban és onnan hibáztatni mindenki mást a jelenlegi rossz - és folyamatosan romló - ICS kiberbiztonsági helyzetért). A feladat kiindulva az ipari szervezeteket még 2019-ben is jellemző merev, hierarchikus struktúrákból, elsősorban a menedzsmenté, a szakemberek legfontosabb dolga ebben a témában - azon túl, hogy nyitottak legyenek a többi szakterületen dolgozó kolléga javaslataira - az, hogy meggyőzzék a menedzsmentet az ilyen jellegű együttműködések nélkülözhetetlenségéről.

Stryker orvosi eszközök sérülékenysége

Mathy Vanhoef, a Leuven-i Katolikus Egyetemen működő imec-DistriNet munkatársa a KRACK (a több, mint egy éve felfedezett, WPA és WPA2 titkosításokat érintő) sérülékenység újabb érintett rendszereit azonosította, ezúttal a Stryker alábbi, gyógyászatban használt rendszereit, amennyiben azokban engedélyezve van az iBed Wireless funkció):

- Secure II MedSurg Bed, Model: 3002;
- S3 MedSurg Bed, Models 3002 S3 és 3005 S3;
- InTouch ICU Bed, Model 2131 és 2141.

A gyártó az érintett termékek közül a Gateway 1.0-hoz nem, a Gateway 2.0 és a Gateway 3.0 verziókhoz elérhetővé tette a javítást. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-029-01

Sérülékenység BD FACSLyric rendszerekben

A Becton, Dickinson and Company (BD) egy sérülékenységet azonosított az alábbi termékeiben:

- BD FACSLyric, Windows 10 kutatói változat, amerikai és malájziai kiadások;
- BD FACSLyric IVD Windows 10 amerikai kiadás.

A gyártó a rendelkezésre álló információk szerint fel fogja venni a kapcsolatot az érintett ügyfélkörrel a javítással illetve a kockázatcsökkentő intézkedések részletei miatt. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-029-02

Yokogawa rendszerek sérülékenysége

A Kaspersky Lab egy, a feltöltött fájlok nem megfelelő ellenőrzéséből adódó sérülékenységet azonosított a Yokogawa License Manager szolgáltatást használó alábbi termékeiben:

- CENTUM VP (R5.01.00 - R6.06.00);
- CENTUM VP Entry Class (R5.01.00 - R6.06.00);
- ProSafe-RS (R3.01.00 - R4.04.00);
- PRM (R4.01.00 – R4.02.00);
- B/M9000 VP (R7.01.01 - R8.02.03).

A gyártó a hiba javítása érdekében az érintett termékek legújabb, elérhető verzióra történő frissítését javasolja. A sérülékenységgel kapcsolatos részletes információk az ICS-CERT weboldalán érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-19-029-01

Sérülékenység Mitsubishi Electric PLC-kben

Tri Quach, az Amazon Customer Fulfillment Technology Security csoportjának munkatársa egy sérülékenységet fedezett fel a Mitsubishi Electric alábbi, MELSEC-Q sorozató PLC-iben:

- Q03/04/06/13/26UDVCPU: 20081 és korábbi sorozatszámú termékek;
- Q04/06/13/26UDPVCPU: 20081 és korábbi sorozatszámú termékek;
- Q03UDECPU, Q04/06/10/13/20/26/50/100UDEHCPU: 20101 és korábbi sorozatszámú termékek.

A gyártó a hibát a legújabb firmware-verzióban javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-029-02

AVEVA Wonderware sérülékenység

Vladimir Dashchenko, a Kaspersky Lab munkatársa egy, a felhasználói adatok nem megfelelő védelmére visszavezethető sérülékenységet azonosított az AVEVA Wonderware System Platform 2017 Update 2 és korábbi verzióiban.

A gyártó a hibát a Wonderware System Platform 2017 Update 3-ban javította. A sérülékenységgel kapcsolatban további információk az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-19-029-03

IDenticard PremiSys sérülékenységek

Jimi Sebree a Tenable-vel együttműködve három sérülékenységet talált az IDenticard PremiSys minden, 4.1-nél korábbi verziójában.

A gyártó a beégetett felhasználói azonosítók hibát a 4.1-es verzióban javította, a másik két hibára februárban ígér javítást. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-031-02

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

Vladimir Kononovich és Vyacheslav Moskvin, a Positive Technologies munkatársai három sérülékenységet találtak a Schneider Electric EVLink Parking 3.2.0-12_v1 és korábbi verzióiban.

A gyártó a javítást tartalmazó verziót már elérhetővé tette és azt javasolja, hogy a töltőállomások távoli hozzáférését tűzfallal védjék. A sérülékenységekről további információkat a Schneider Electric és az ICS-CERT weboldalain lehet találni.

Sérülékenységek Aveva InduSoft és InTouch rendszerekben

Az AVEVA a Tenable-vel együttműködve két sérülékenységről hozott nyilvánosságra részleteket, amik az alábbi termékeiket érintik:

- InduSoft Web Studio 8.1 SP3-nál korábbi verziói;
- InTouch Edge HMI (korábbi nevén InTouch Machine Edition) 2017 Update-nél korábbi verziók.

A gyártó a hibákat az érintett szoftverek legújabb verzióiban javította. 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-19-036-01

Rockwell Automation rendszerek sérülékenységei

A Rockwell Automation a Tenable-vel közösen egy sérülékenységet jelentett az NCCIC-nek, ami a következő rendszereiket érinti:

- 1756-EWEB (és a 1756-EWEBK) 5.001 és korábbi verziói;
- CompactLogix 1768-EWEB 2.005 és korábbi verziói.

A gyártó a sérülékenységgel kapcsolatban kockázatcsökkentő intézkedésként azt javasolja az ügyfeleinek, hogy amennyiben nem használják, kapcsolják ki az érintett rendszerekben az SNMP-szolgáltatást. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-036-02

WECON LeviStudio sérülékenységek

Mat Powell, Ziad Badawi és Natnael Samson, a ZDI-vel együttműködve három sérülékenységet azonosítottak a WECON LeviStudio 1.8.56-os és korábbi verzióiban.

A gyártó a sérülékenységeket az érintett termék legújabb verziójában javította. A sérülékenységekről további részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-036-03

Sérülékenységek Kunbus termékekben

Nicolas Merle, az Applied Risk munkatársa öt sérülékenységet fedezett fel a Kunbus PR100088 Modbus gateway termékének 1.1.13166-osnál korábbi verzióiban.

A gyártó a hibákat az 1.1.13166 (Version R02) verzióban javította. 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-19-036-05

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.

Tavaly év végén, az ENISA jelentős mértékű megerősítéséről és bővítéséről hozott döntést az EU, ezzel párhuzamosan adta ki az IoT és az Ipar 4.0 biztonságával foglalkozó tanulmányát az ENISA.

A negyedik ipari forradalom a tanulmány szerint immár elválaszthatatlan a kiberbiztonság témájától, ezt mutatják az egyre szaporodó, ipari IT rendszereket érintő incidensek, különösen azoknál az ipari szereplőknél, ahol az IoT megoldásokat a fizikai folyamatok irányításához is felhasználják.

A tanulmányban az ENISA szakemberei összegyűjtötték azokat az útmutatókat és biztonsági intézkedéseket, amelyek segítséget nyújhatnak az Ipar 4.0 irányába fejlesztő ipari szervezeteknek.

Az ENISA tanulmánya itt érhető el.