Zsarolóvírus-támadás érte az Advantech ICS gyártó rendszereit

November utolsó napjaiban került nyilvánosságra, hogy ransomware-támadás érte az Advantech, tajvani ICS gyártó infomatikai rendszereit. Az újabb generációs ransomware-támadásokhoz hasonlóan ebben az esetben is egy kombinált, titkosító-adatlopó támadásról van szó. A BleepingComputer beszámolója szerint az Advantech-től ellopott (és a támadók által részben már publikált) bizalmas dokumentumok a kisebb értékű, vállalati adminisztratív folyamatok dokumentumai közül kerültek ki.

Az incidensről megjelent információk arról szólnak, hogy a támadás a Conti ransomware-hez köthető. Egyelőre nincs hír arról, hogy az incidens érintette volna az Advantech gyártósorait illetve termékeit.

Az Advantech elleni ransomware-támadásról bővebben a BleepingComputer cikkében lehet olvasni.

Ransomware-támadás a Vancouver-i tömegközlekedési vállalat rendszerei ellen

December 1-jén zsarolóvírus-támadás érte a kanadai Vancouver városának tömegközlekedési vállalatát, a TransLinket. A támadás nem érintette a vállalat folyamatirányításért felelős rendszereit, de az utasok nem tudtak készpénzmentes fizetési módokat használni a jegyvásárláshoz. Az incidens során a támadók (a mostanában szokásos elkövetési mód szerint) el is loptak egyes, bizalmas adatokat tartalmazó fájlokat és azok nyilvánosságra hozásával is fenyegetik az áldozatot.

Az esetről bővebben a BitDefender blogján és a SecurityWeek cikkében lehet olvasni.

Kibertámadás érte egy izraeli víziközmű cég ICS rendszereit

Az OTORIO nevű ipari IT biztonsági cég által publikált részletek szerint (feltételezések szerint iráni) támadók hozzáfértek egy izraeli víztározó ICS rendszerének védtelenül hagyott HMI-ához. A támadók december 1-jén publikáltak egy videót a támadásról.

Mivel a vízellátás egyre inkább kulcskérdésnek számít a Közel-Keleten és az izraeli-iráni viszony talán minden korábbinál feszültebb az utóbbi idők eseményei után, kifejezetten nagy hiba fontos ICS rendszerek komponenseit védtelenül, az Internetre csatlakoztatva működtetni.

Mitsubishi Electric berendezések sérülékenysége

Xiaofei Zhang egy sérülékenységet talált a Mitsubishi Electric MELSEC iQ-R sorozatú berendezéseinek alábbi modelljeiben:

- R00/01/02CPU 19-es és korábbi firmware-verziói;
- R04/08/16/32/120(EN)CPU 51-es és korábbi firmware-verziói;
- R08/16/32/120SFCPU 22-es és korábbi firmware-verziói;
- R08/16/32/120PCPU minden verziója;
- R08/16/32/120PSFCPU minden verziója;
- RJ71EN71 47-es és korábbi firmware-verziói;
- RJ71GF11-T2 47-es és korábbi firmware-verziói;
- RJ72GF15-T2 07-es és korábbi firmware-verziói;
- RJ71GP21-SX 47-es és korábbi firmware-verziói;
- RJ71GP21S-SX 47-es és korábbi firmware-verziói;
- RJ71C24(-R2/R4) minden verziója;
- RJ71GN11-T2 minden verziója.

A gyártó a hibát az érintett eszközökhöz kiadott ú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://us-cert.cisa.gov/ics/advisories/icsa-20-324-05

Sérülékenység Fuji Electric rendszerekben

Tran Van Khang, a VinCSS munkatársa egy sérülékenységet jelentett a ZDI-nek, ami a Fuji Electric V-Server Lite termékének 3.3.24.0-nál korábbi verzióit érinti.

A gyártó a hibát a 3.3.25.0 verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-329-02

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

Sharon Brizinov, a Claroty munkatársa 3 sérülékenységet azonosított a Rockwell Automation FactoryTalk Linx 6.11-es és korábbi verzióiban.

A gyártó a hibával kapcsolatban a legújabb elérhető verzióra történő frissítést javasolja. A sérülékenységek részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-329-01

National Instruments vezérlők sérülékenysége

A Titanium Industrial Security munkatársai egy sérülékenységet jelentettek a spanyol Nemzeti Kiberbiztonsági Intézetnek (INCIBE), ami a National Instruments CompactRIO nevű, valósidejú beágyazott vezérlőinek drivereit érinti, a 20.5-ös verziónál korábbi verziók használata esetén.

A gyártó a hibát a driver 20.5-ös verziójában javította, aminek alkalmazásához a vezérlők firmware-jét is frissíteni kell a 8.5-ös vagy újabb verzióra. A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-338-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.

Ahogy szinte minden iparágban, úgy a tengerhajózásban is folyamatosan nő a kibertámadások száma. A 2017-es NotPetya-támadások a Maersk számára okozott 300 millió dolláros kárt, azóta pedig támadások érték a barcelonai és San Diego-i kikötőket, az Austal nevű ausztrál hajógyártót és a COSCO amerikai hajózási vállalatot is. 2020-ban az MSC hajózási vállalat rendszereit (és emiatt többek között a Genova-i központját) kellett leállítani Ryuk ransomware fertőzés miatt, legutóbb pedig az iráni Shahid Rajaee kikötőt érték sorozatos kibertámadások.

Ahogy általában a különböző iparágakban, a kiberbiztonság a legutóbbi időkig a tengerhajózási vállalatoknál is az IT feladata volt. Azonban (hasonlóan a többi iparághoz), az OT biztonsági kihívásokra nem lehet kizárólag a hagyományos IT biztonsági megoldásokkal és módszerekkel választ adni. Ezt felismerve a Nemzetközi Tengerhajózási Szervezet (Internation Maritime Organization, IMO) 2021. januártól konkrét elvárásokat fogalmaz meg a szektorban működő vállalkozások safety rendszereinek kiberbiztonságával kapcsolatban. Ezzel párhuzamosan az USA kormánya is változtat a témával kapcsolatos hozzáállásán és a Trump-kabinet is prioritásként kezd tekinteni a tengerhajózásban használt rendszerek kiberbiztonságára - nem utolsósorban az USA világpolitikai pozíciójához kapcsolódó tengeri haderő miatt is.

Ez utóbbinak egyébként már 2019-ben is láthattuk jeleit, amikor a US Cyber Command egy tengeri kikötő elleni kibertámadást szimulált. A gyakorlatról a CyberScoop cikkében lehet bővebben olvasni: https://www.cyberscoop.com/us-cyber-command-simulated-seaport-cyberattack-test-digital-readiness/

Néhány hete hozták nyilvánosságra, hogy zsarolóvírus-támadás érte a világ egyik legnagyobb játékgyártó cégének, a Mattel-nek a rendszereit. A rendelkezésre álló információk szerint az incidens nem érintette a vállalat gyártássutomatizálásért felelős rendszereit és (eltérően az utóbbi idők kombinált, titkosító-zsaroló és adatlopásra felkészített malware-jeitől) nem történt adatlopás az incidens során.

Bár az incidens hatásai a jelek szerint nem voltak súlyosak, maga a tény, hogy 2020-ban ennyire megszaporodtak az ipari szervezetek, gyakran kritikus infrastruktúrák elleni ransowmare-támadások, nagyon erős figyelemfelkeltő hatással kéne, hogy legyen a döntéshozókra. Ennek sajnos egyelőre a nyomait sem igen látjuk, ez pedig oda vezethet, hogy itthon is várható(ak) lesznek komolyabb, akár egyes szektorok ellátásbiztonságát is veszélyeztető incidensek. A kérdés valójában nem az, hogy lesz-e ilyen incidens, hanem az, hogy mikor?

Schneider Electric Modicon berendezések sérülékenységei

Kai Wang, a Fortinet FortiGuard laboratóriumának munkatára 3 sérülékenységet fedezett fel a Schneider Electric alábbi termékeiben:

- M340 CPU -k BMX P34x modelljeinek minden verziója;
- M340 Ethernet kommunikációs modulok:
- BMX NOE 0100 (H) modelljeinek minden verziója;
- BMX NOE 0110 (H) modelljeinek minden verziója;
- BMX NOC 0401 modelljeinek minden verziója;
- BMX NOR 0200H modelljeinek minden verziója;
- Premium processzorok integrált Ethernet kommunikációs processzorokkal:
- TSXP574634, TSXP575634, TSXP576634 modellek minden verziója;
- Premium kommunikációs modulok:
- TSXETY4103 modellek minden verziója;
- TSXETY5103 modellek minden verziója;
- Quantum processzorok integrált Ethernet kommunikációs processzorokkal:
- 140CPU65xxxxx modellek minden verziója;
- Quantum kommunikációs modulok:
- 140NOE771x1 modellek minden verziója;
- 140NOC78x00 modellek minden verziója;
- 140NOC77101 modellek minden verziója.

A gyártó jelenleg is dolgozik a sérülékenységek javításán és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatos további információkat a Schneider Electric publikációjában lehet megtalálni.

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

Lasse Trolle Borup, a Danish Cyber Defence munkatársa egy sérülékenységet talált a Schneider Electric alábbi rendszereiben:

EcoStruxure™ Operator Terminal Expert Runtime 3.1 Service Pack 1A és korábbi verziói, amiket régebbi BIOS verzióval működő Windows PC-kre vagy Harmony iPC-kre (HMIG5U és HMIG5U2 verziókra) telepítettek.

A gyrátó a hibát a 3.1 Service Pack 1B verzióban javította. A sérülékenység részleteiről a Schneider Electric bejelentéséből lehet tájékozódni.

Schneider Electric IGSS rendszerek sérülékenységei

kimiya, a ZDI-vel együttműködve 9 sérülékenységről közölt információkat a Schneider Electric-kel, amik a gyártó Interactive Graphical SCADA System (IGSS) nevű rendszerében 14.0.0.20247-es és korábbi verzióit érintik.

A gyártó a hibákat a 14.0.0.20248-as verzióban javította. A sérülékenységek részleteiről a Schneider Electric és az ICS-CERT weboldalain lehet olvasni.

Sérülékenységek Schneider Electric EcoStruxure Building Operation rendszerekben

Luis Vázquez, Francisco Palma és Diego León, a Zerolynx munkatársai, együttműködésben az INCIBE CERT-tel, valamint Alessandro Bosco, Luca Di Giuseppe, Alessandro Sabetta és Massimiliano Brolli, a TIM Security Red Team Research (TIM S.p.A.) munkatársai 7 sérülékenységet találtak a Schneider Electric EcoStruxure Building Operation alábbi komponenseiben:

- WebReports V1.9-től V3.1-ig terjedő verziói;
- WebStation V2.0-tól V3.1-ig terjedő verziói;
- Enterprise Server telepítő V1.9-től V3.1-ig terjedő verziói;
- Enterprise Central telepítő V2.0-tól V3.1-ig terjedő verziói.

A hibákkal kapcsolatban a gyártó az EcoStruxure Building Operation 3.2-es verziójára történő frissítést javasolja. A sérülékenységekkel kapcsolatos bővebb információkat a Schneider Electric publikációja tartalmazza.

Schneider Electric Modicon PLC-k sérülékenységei

Yehuda Anikster és Rei Henigman, a Claroty valamint Seok Min Lim és Bryon Kaan, a Trustwave munkatársai összesen 4 sérülékenységet találtak a Schneider Electric Modicon M221-es típusú PLC-iben.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről részletesebben a Schneider Electric bejelentésében lehet olvasni.

Sérülékenység Schneider Electric Easergy T300 rendszerekben

Evgeniy Druzhinin és Ilya Karpov, a Rostelecom-Solar munkatársai egy sérülékenységet fedeztek fel a Schneider Electric Easergy T300 típusú RTU-inak 2.7-es és régebbi firmware-verzióiban.

A gyártó a hibát a 2.7.1-es firmware-verzióban javította. A sérülékenységgel kapcsolatos részleteket a Schneider Electric weboldalán lehet elérni.

Sérülékenységek Schneider Electric EcoStruxure Control Expert PLC szimulátorokban

Alexander Perez-Palma és Jared Rittle, a Cisco Talos munkatársai, a Parity Dynamics kutatócsoportja és Flavian Dola az Airbus Cybersecurity munkatársa 5 sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- EcoStruxure™ Control Expert PLC szimulátor minden verziója;
- Unity Pro PLC szimulátor minden verziója.

A hibával kapcsolatos javításokat a gyártó az EcoStruxure™ Control Expert 15.0 verziójában tette elérhetővé. A sérülékenységekkel kapcsolatos további részleteket a Schneider Electric és az ICS-CERT publikációi tartalmazzák.

Siemens SCALANCE rendszerek sérülékenysége

A Siemens egy sérülékenységről közölt információkat a DHS CISA-val, ami a SCALANCE W 1750D megoldásuk minden verzióját érinti.

A gyártó a hibát az érintett termékek legújabb firmware-verziójában javította. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT bejelentéseiből lehet tájékozódni.

Sérülékenység Siemens SIMATIC és SINUMERIK rendszerekben

Wang Fang Li, a Beijing Winicssec Technology CO munkatársa egy sérülékenységet jelentett a Siemens-nek, ami a gyártó alábbi termékeit érinti:

- SIMATIC S7-300 CPU-család (beleértve a kapcsolódó ET200-as CPU-kat és SIPLUS változatokat) minden verziója;
- SINUMERIK 840D sl minden verzió.

A hibával kapcsolatos javításon a gyártó jelenleg is dolgozik és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatosan további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Sérülékenységek OSIsoft PI Vision rendszerekben

Az OSIsoft 2 sérülékenységet jelentett a DHS CISA-nak, amik a PI Vision nevű termékük 2020-as verzióját érintik.

A gyártó hibák a PI Vision 2020 3.5.0 verziójában javította. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-315-02

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

Az OSIsoft 1 sérülékenységről közölt információkat a DHS CISA-val, amit a PI Interface for OPC XML-DA nevű termékük 1.7.3.x-nél korábbi verzióiban találtak.

A gyártó a hibát az 1.7.3.x verzióban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-315-01

Sérülékenység Mitsubishi MELSEC iQ-R berendezésekben

Xiaofei Zhang egy sérülékenységet azonosított a Mitsubishi MELSEC iQ-Rsorozatú CPU modelljeinek alábbi vezrióiban:

- R00/01/02 CPU-k 05-től 19-ig terjedő firmware-verziói;
- R04/08/16/32/120(EN) CPU-k 35-től 51-ig terjedő firmware-verziói.

A gyártó kiadta a hibát javító újabb firmware-verziókat. A sérülékenységről további információkat az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-317-01

BD rendszerek sérülékenysége

A Medigate egy sérülékenységet talált a BD alábbi, orvostechnikai eszközeiben:

- BD Alaris PC Unit, Model 8015 9.33.1 és korábbi verziói;
- BD Alaris Systems Manager 4.33 és korábbi verziói.

A gyártó a hibát az érintett termékekhez kiadott újabb verziókban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet tajékozódni: https://us-cert.cisa.gov/ics/advisories/icsma-20-317-01

Sérülékenység Real Time Automation rendszerekben

Sharon Brizinov, a Claroty munkatársa egy sérülékenységet talált a Real Time Automation 499ES típusú EtherNet/IP-adapterének forráskódjában.

A hiba javításáról jelenleg nem érhető el publikus információ. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-03

Paradox rendszerek sérülékenységei

Omri Ben-Bassat, az Azure Defender for IoT-hez tartozó Section 52 munkatársa két sérülékenységet talált a Paradox IP150 típusú berendezéseinek 5.02.09-es verziójú firmware-jében.

A gyártó a hibával kapcsolatban érdeklődő ügyfeleit a terméktámogatói csoportjukhoz irányítja. A sérülékenységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-02

Sérülékenység Sensormatic Electronics rendszerekben

Joachim Kerschbaumer egy sérülékenységet jelentett a Sensormatic anyavállalatának, a Johnson Controls-nak, ami a Sensormatic alábbi termékeit érinti:

- victor Web Client v5.6 és korábbi verziói;
- C•CURE Web Client v2.90 és korábbi verziói.

A gyártó a hibát javító újabb verziókat már elérhetővé tette. A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT bejelentésében lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-324-01

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

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgá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 OT és ICS rendszerek elleni kiberbiztonsági kockázatok folyamatosan nőnek. Ez nem újdonság, de az amikor egyes állami ügynökségek ez nyíltan beismerik és a kockázatok csökkentését célzó javasolatokat adnak ki, az már az. Ez történt még július végén, amikor az USA-ban a Department of Homeland Security-hez tartozó Cybersecurity & Infrastructure Security Agency (CISA) és az NSA közös publikációban adott tanácsokat a kritikus infrastruktúrák OT üzemeltetői számára.

A tanácsok között szerepel az OT/ICS rendszerekre és berendezésekre vonatkozó incidenskezelési és működésfolytonossági tervek készítése, ide értve az adatok (nem utolsósorban a helyes konfigurációs beállítások) rendszeres mentését és a mentések tesztelését, az incidenskezelési tervek kidolgozását, tesztelését és rendszeres felülvizsgálatát, valamint az OT hálózatban végzett monitoring tevékenységet a potenciális fenyegetések mielőbbi felismerése érdekében.

Sérülékenység WAGO termékekben

William Knowles, az Applied Risk munkatársa egy sérülékenységet talált a WAGO alábbi termékeiben:

- 750-352 sorozat FW11-nél korábbi firmware-verziói;
- 750-831/xxx-xxx sorozat FW11-nél korábbi firmware-verziói;
- 750-852 sorozat FW11-nél korábbi firmware-verziói;
- 750-880/xxx-xxx sorozat FW11-nél korábbi firmware-verziói;
- 750-881 sorozat FW11-nél korábbi firmware-verziói;
- 750-889 sorozat FW11-nél korábbi firmware-verziói.

A hibával kapcsolatban a gyártó a legújabb, már elérhető firmware-verzió használatát és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-308-01

Sérülékenységek ARC Informatique PcVue rendszerekben

Sergey Temnikov és Andrey Muravitsky, a Kaspersky Lab munkatársai három sérülékenységet fedeztek fel az ARC Informatique PcVue 8.10-től 12.0.17-ig terjedő verzióiban.

A gyártó a hibával kapcsolatban a 12.0.17-es verzióra történő frissítést javasolja. A sérülékenységek részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-308-03

NEXCOM rendszerek sérülékenységei

A ZDI két sérülékenységről közölt információkat a DHS CISA-val, amik a NEXCOM NIO 50-es rendszereinek összes verzióját érintik.

A gyártó már nem forgalmazza a NIO 50-es rendszereket és támogatást sem biztosít hozzájuk, így a hibák javítása nem várható. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-308-02

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

A Mitsubishi Electric összesen hat sérülékenységről osztott meg információkat a DHS CISA-val, amik az alábbi termékeiket érintik:

A CoreOS 05.65.00.BD és korábbi verzióival működő GOT1000 rendszerek alábbi modelljei:

- GT1455-QTBDE;
- GT1450-QMBDE;
- GT1450-QLBDE;
- GT1455HS-QTBDE;
- GT1450HS-QMBDE.

A gyártó a hibákat a CoreOS legújabb verziójában javította. A sérülékenységek részleteiről további információkat az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-310-02

WECON PLC Editor sérülékenységek

Natnael Samson és Francis Provencher, a ZDI-vel együttműködve két sérülékenységet jelentettek a DHS CISA-nak, amik a WECON PLC Editor 1.3.8-as és korábbi verzióit érintik.

A hibák javításán a gyártó jelenleg is dolgozik. A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-310-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.

Nemrég egy kifejezetten színvonalas cikket (terjedelmi és minőségi okok miatt nem használnám rá a blogposzt kifejezést, szerintem ez az írásmű sokkal több egyszerű blogbejegyzésnél) találtam az otcybersecurity.blog-on.

Szerzője, Sinclair Koelemij 16 különböző DCS és SCADA hálózati architektúrán mutatja be, milyen eltérő hálózatbiztonsági követelményeknek kell megfelelniük a különböző SCADA és DCS rendszereknek különböző környezetekben, ide értve akár az Interneten keresztül távkezelt alállomásokat is.

Nem is szaporítanám tovább a szót, inkább mindenki olvassa el ezt a cikket, akit érdekel az ICS rendszerek határvédelme, különösen, ha éppen ilyen témába vágó feladatot kapott.

Sérülékenység Moxa NPort berendezésekben

A Moxa publikációja szerint egy sérülékenységet találtak az NPort 5100A sorozatú eszközeik 1.5-ös és korábbi firmware-verzióiban.

A gyártó a hibát javító új firmware-verziót már elérhetővé tette. A sérülékenységről további részleteket a Moxa publikációjában lehet találni.

Moxa EDR secure router-ek sérülékenysége

A Moxa bejelentése szerint egy sérülékenységet fedeztek fel az alábbi, EDR sorozatú routereikben:

- EDR-G903 sorozatú eszközök 5.5-ös és korábbi firmware-verziói;
- EDR-G902 sorozatú eszközök 5.5-ös és korábbi firmware-verziói;
- EDR-810 sorozatú eszközök 5.5-ös és korábbi firmware-verziói.

A gyártó a hibát az érintett termékekhez kiadott legújabb firmware-verziójában javította. A sérülékenységgel kapcsolatosan bővebb információkat a Moxa bejelentése tartalmaz.

Sérülékenység Hitachi ABB Power Grids berendezésekben

A Hitachi ABB Power Grids egy sérülékenységet azonosított az alábbi termékeiben:

- XMC20 R4 típusú Multiservice-Multiplexer-ek, amelyek a co5ne_r1h07_12.esw-nél régebbi COGE5 verziót használnak;
- XMC20 R6 típusú Multiservice-Multiplexer-ek, amelyek a co5ne_r2d14_03.esw-nél régebbi COGE5 verziót használnak.

A gyártó a hibát javító újabb firmware-verziókat már elérhetővé tette és 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 olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-294-02

Rockwell Automation berendezések sérülékenységei

Jared Rittle, a Cisco Talos munkatársa három sérülékenységet talált az alábbi Rockwell Automation termékekben:

- 1794-AENT Flex I/O berendezések B sorozatának 4.003 és korábbi verziói.

A hibával kapcsolatosban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-294-01

Sérülékenységek B.Braun rendszerekben

Julian Suleder, Nils Emmerich és Birk Kauer, az ERNW Research GmbH, valamint Dr. Oliver Matula, az ERNW Enno Rey Netzwerke GmbH munkatársai 11 sérülékenységet találtak a B.Braun alábbi termékeiben:

- SpaceCom U61 és korábbi verziói (az USA-ban), L81 és korábbi verziói (az USA-n kívüli piacokon);
- Battery pack with Wi-Fi U61 és korábbi verziói (az USA-ban), L81 és korábbi verziói (az USA-n kívüli piacokon);
- Data module compactplus A10 és A11-es verziói.

A gyártó a hibákat javító újabb verziókat már elérhetővé tette. A sérülékenységekkel kapcsolatos bővebb informácók az ICS-CERT bejelentésében találhatóak: https://us-cert.cisa.gov/ics/advisories/icsma-20-296-02

B.Braun OnlineSuite sérülékenységek

Julian Suleder, Nils Emmerich és Birk Kauer, az ERNW Research GmbH, valamint Dr. Oliver Matula, az ERNW Enno Rey Netzwerke GmbH munkatársai három sérülékenységet fedeztek fel a B.Braun OnlineSuite AP 3.0 és korábbi verzióiban.

A gyártó a hiba javítását már publikálta. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsma-20-296-01

Sérülékenységek SHUN HU rendszerekben

Marco Balduzzi, Philippe Z Lin, Federico Maggi, Jonathan Andersson, Akira Urano, Stephen Hilt és Rainer Vosseler, a ZDI-vel együttműködve 2 sérülékenységről közöltek információkat a DHS CISA-val. A sérülékenységek a SHUN HU alábbi rendszereit érintik:

- JUUKO K-800 és K-808 típusú ipari rádiótávírányító berendezések firmware-verziói, amik a következőknél korábbi számokra végződnek: ...9A, 9B, ...9C, stb.

A gyártó kiadta a hibákat javító firmware-verziókat. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-301-01

Mitsubishi Electric MELSEC berendezések sérülékenysége

A Mitsubishi Electric egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi eszközeiket érinti:

MELSEC iQ-R sorozat:
- R 00/01/02 CPU-k 20-as és korábbi firmware-verziói;
- R 04/08/16/32/120 (EN) CPU-k 52-es és korábbi firmware-verziói;
- R 08/16/32/120 SFCPU-k 22-es és korábbi firmware-verziói;
- R 08/16/32/120 PCPU-k minden firmware-verziója;
- R 08/16/32/120 PSFCPU-k minden firmware-verziója;
- R 16/32/64 MTCPU-k minden firmware-verziója;

MELSEC Q sorozat:
- Q03 UDECPU, Q 04/06/10/13/20/26/50/100 UDEHCPU-k 22081-es és korábbi sorozatszámok;
- Q 03/04/06/13/26 UDVCPU-k 22031-es és korábbi sorozatszámok;
- Q 04/06/13/26 UDPVCPU-k 22031-es és korábbi sorozatszámok;
- Q 172/173 DCPU, Q 172/173 DCPU-S1 minden verziója;
- Q 172/173 DSCPU minden verziója;
- Q 170 MCPU minden verziója;
- Q 170 MSCPU, Q 170 MSCPU（-S1） minden verziója;
- MR-MQ100 minden verziója;

MELSEC L sorozat:
- L 02/06/26 CPU (-P), L 26 CPU - (P) BT minden verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését ajánlja, az elérhető patch-ekről a weboldalán lehet tájékozódni. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-303-01

Sérülékenységek Mitsubishi MELSEC iQ-R eszközökben

Az ICS-CERT által publikált informáicók szerint 6 sérülékenységet azonosítottak a Mitsubishi Electric MELSEC iQ-R sorozatú eszközeinek alábbi moduljaiban:

- EtherNet/IP Network Interface Module, RJ71EIP91, ha a sorozatszám első két számjegye 02 vagy korábbi;
- PROFINET IO Controller Module, RJ71PN92, ha a sorozatszám első két számjegye 01 vagy korábbi;
- High Speed Data Logger Module, RD81DL96, ha a sorozatszám első két számjegye 08 vagy korábbi;
- MES Interface Module, RD81MES96N, ha a sorozatszám első két számjegye 04 vagy korábbi;
- OPC UA Server Module, RD81OPC96, ha a sorozatszám első két számjegye 04 vagy korábbi.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről bővebb információkat a Mitsubishi Electric és az ICS-CERT weboldalain 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.

Még a nyáron futottam bele Sarah Fluchs cikkébe a medium.com-on, amiben a szerző arról ír, hogy a PLC programozás során is meg kell honosítani a biztonságos fejlesztési gyakorlatot.

Ahogy Sarah is ír erről, a PLC programozással foglalkozók az első, tapogatózó biztonsági kérdésekre még nagyon magabiztosan szokták azt válaszolni, hogy ők aztán nem programoznak, de ahogy tovább folyik a beszélgetés, viszonylag gyorsan eljut társalgás oda, hogy PLC-ket azért programoznak és időnként el is bizonytalanodnak, hogy vajon a PLC programozás számít-e?

A válasz egyértelmú igen, de tudomásul kell venni, hogy az IT programozás egészen más környezetben fejlődött azzá, amit ma ismerünk. Lévén az IT hálózatok már hosszú évtizedek óta egyre meghatározóbbak az IT fejlesztők gondolkodását és fejlesztési gyakorlatait illetően, ez pedig azt is magával hozta (kb. a 2000-es évektől egyre gyorsuló ütemben), hogy az IT fejlesztők (akár tetszett nekik, akár nem) szépen lassan hozzászoktak a biztonságos(abb) fejlesztési módszertanok alkalmazásához.

Ezzel szemben a PLC programozás nagyon eltérő prioritások mentén fejlődött azzá, ami ma. A PLC működése során a legfontosabb prioritás (a safety biztosítása mellett) a valós idejű műveletek elvégzésének megbízható garantálása (ez ugye az OT/ICS biztonsági célok közül a másik a safety mellett, amire korábban már hivatkoztunk a CIA-hármason túl, vagyis a reliability). Ráadásul nagyon sokáig (igazából az elmúlt 8-10 évet nem számolva) a PLC-k jellemzően nem vagy nem igazán kommunikáltak IP hálózatokon, az I/O moduljaikon, néhány környező PLC-n és a folyamatirányító rendszereiken kívül mással jellemzően nem volt kapcsolatuk (ez az a történelmi alap, amire az OT/ICS mérnökök mind a mai napig gyakran hivatkoznak, amikor amellett érvelnek, hogy a kiberbiztonsági kérdések miért is nem vonatkoznak az általuk üzemeltetett rendszerekre - épp csak azt felejtik el vagy arról nem tudnak, hogy a rendszereik és berendezéseik egyre inkább részei egy IP hálózatnak, jobb esetben megfelelő logikai szeparáltság mellett, rosszabb esetben a vállalat ügyviteli hálózatából, legrosszabb esetben pedig külső hálózatokból és az Internetről is elérhető módon működnek).

A cikk két hibás feltételezést is megcáfol:

1. A PLC-k esetén nincs szükség biztonságos fejlesztési eljárásokra
2. A PLC programozásra nem lehet alkalmazni a biztonságos fejlesztés eljárásokat

A PLC-k működési sajátosságai adnak néhány olyan pluszt a biztonságos PLC programozáshoz, amire elsőre nem is gondolna az ember. Ezeket és néhány példát is a cikkben lehet megtalálni: https://medium.com/swlh/the-top-20-secure-plc-coding-practices-project-32729f6d4814