Hitachi ABB Power Grids rendszerek sérülékenységei

A Hitachi ABB Power Grids két sérülékenységről közölt információkat a DHS CISA-val, ami az Ellipse Enterprise Asset Management nevű megoldásuk 9.0.25-ös és korábbi verzióit érinti.

A hibák egyikét a 9.0.23-as verzió, mindkettőt pedig a 9.0.26-os verzió javítja. A sérülékenységekről további információk az ICS-CERT publikációjában érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-21-061-01

Sérülékenység Rockwell Automation CompactLogix vezérlőkben

Yeop Chang egy sérülékenységet jelentett a DHS CISA-nak a Rockwell Automation alábbi vezérlőivel kapcsolatban:

- Armor Compact GuardLogix 5370 vezérlők 33-as és korábbi firmware-verziói;
- Armor GuardLogix, Safety vezérlők 33-as és korábbi firmware-verziói;
- CompactLogix 5370 L1 vezérlők 33-as és korábbi firmware-verziói;
- CompactLogix 5370 L2 vezérlők 33-as és korábbi firmware-verziói;
- CompactLogix 5370 L3 vezérlők 33-as és korábbi firmware-verziói;
- Compact GuardLogix 5370 vezérlők 33-as és korábbi firmware-verziói;
- ControlLogix 5570 vezérlők 33-as és korábbi firmware-verziói.

A gyártó a hibát a 33.011-es és későbbi firmware-verziókban 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-21-061-02

MB connect line rendszerek sérülékenységei

Az OTORIO munkatársai összesen 18 sérülékenységet azonosítottak az MB connect line alábbi termékeiben:

- mymbCONNECT24 v2.6.1 és korábbi verziói;
- mbCONNECT24 v2.6.1 és korábbi verziói.

A gyártó a hibák egy részét az érintett termékek 2.71-es és későbbi verzióiban javította, a többi esetében a javításon jelenleg is dolgozik. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-061-03

Sérülékenységek Rockwell Automation kommunikációs modulokban

Adam Eliot, a Loon Security Team tagja két sérülékenységet jelentett a Rockwell Automation-nek, amik az 1734-AENTR típusú kommunikációs moduljaik alábbi példányait érintik:

- B-sorozatú eszközök 4.001-től 4.005-igy és 5.011-től 5.017-ig terjedő firmware-verziói;
- C-sorozatú eszközök 6.011-es és 6.012-es firmware-verziói.

A gyártó a hibákat a B-sorozatú eszközöknél az 5.018-as, a C-sorozatú eszközök esetén a 6.013-as firmware-verzióban javították. A sérülékenység részleteit az ICS-CERT publikációjában lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-063-01

Schneider Electric EcoStruxure Building Operation termékek sérülékenységei

Luis Vázquez, Francisco Palma és Diego León, a Zerolynx munkatársai, az INCIBE-bal együttműködve, valamint Alessandro Bosco, Luca Di Giuseppe, Alessandro Sabetta és Massimiliano Brolli, a TIM Security Red Team Research munkatársai 7 sérülékenységet fedezetek fel a Schneider Electric EcoStruxure Building Operation nevű termékcsaládjának alábbi tagjaiban:

- 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 gyártó a hibákat az EcoStruxure Building Operation 3.2-es verziójában javította. A sérülékenységekkel kapcsolatban további információkat az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-063-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.

A SANS minden év tavaszán egy nagyszabású, általában 6-8 napos, ICS témájú rendezvényt szervez, hagyományosan Floridába. Idén, a COViD-19 miatt ez is rendhagyó módon került megrendezésre és 2021 többi SANS biztonsági Summit-jához hasonlóan, a március 4-5-i ICS Security Summit is ingyenes volt.

Maga az esemény március 3-án, egy SANS-Dragos ICS CTF-fel kezdődött, amin idén sajnos nem volt lehetőségem részt venni (bár nem vagyok egy nagy hacker/forensics guru, de ezek a CTF-ek szórakozásnak és tanulási lehetőségnek sem utolsók).

Viszont a Summit két igazi napja egyetlen hatalmas, bő 30 órán át majdnem folyamatosan (valahol 5-én, magyar idő szerint 04:30 és 09:00 között volt némi szünet) mentek az előadások, panel-beszélgetések, díjátadók.

Számos érdekes előadást lehetne kiemelni, én most csak arról a keynote-ról írnék, ahol Anne Neuberger, a Biden-adminisztráció által frissen kinevezett, kiberbiztonsági ügyekért felelős helyettes tanácsadója és a nemzetbiztonsági biztottság tagja beszélt az ICS kiberbiztonság helyzetéről és fontosságáról. Nem csak azt volt érdekes felfedezni, hogy érti a téma súlyát, hanem az előadása után kérdezni is lehetett és a kérdésekre adott válaszok is azt mutatták, hogy átlátja és érti ezt a kérdéskört.

Kíváncsi lennék, itthon mikor jutunk el arra a szintre, amikor a hazai kritikus infrastruktúrák biztonságáért felelős vezetők (és általában a nemzeti kiberbiztonsági kérdésekben illetékesek) ilyen hozzáállással fordulnának a szakmai közösséghez.

A 2021-es ICS Securty Summit teljes programja itt érhető el, én úgy gondolom, hogy ez megint egy kifejezetten jól szervezett, nagyon érdekes rendezvény volt. Ha már a járvány ennyire korlátozza az életünket, jó, hogy legalább a szakmai vonalon van lehetőség ebben a helyzetben is fejlődni, tájékozódni.

Frissítés: Anne Neuberger keynote-ja és utána a kérdésekre adott válaszai itt nézhetőek meg.

Korábban már írtam az indiai Kudankulam-i atomerőmű (Kudankulam Nuclear Power Plant - KKNPP) elleni kibertámadásról, március 1-jén, kora hajnalban azonban a Recorded Future nevű threat intelligenc szolgáltató kiadta ezt a jelentést, amiben az elemzésük szerint kínai APT-csoport(ok?) által az indiai kritikus infrastruktúrák, elsősorban az indiai villamosenergia-szektor cégei elleni kibertámadásokról írnak részletesebben.

Az elemzés alapján a támadók a Kaspersky által ShadowPad-nek nevezett malware-t juttaták be a célba vett szervezetek beszállítóin keresztül (vagyis a SolarWinds- és Centreon-támadások után rövid időn belül itt a harmadik nagyon komoly támadás, ami a beszállítói lánc elleni támadásként kategorizálható).

A Recorded Future elemzői szerint a támadások már 2017-ben folyamatban lehettek (ekkor találták az első ShadowPad malware-mintát a Netsarang-incidens során), de a támadások a 2020. májusi, Ladakh-tó környékén elfajult kínai-indiai határincidensek után szaporodtak el. A támadások 10 különböző indiai villamosenergia-ipari céget, köztük az ötből négy reginális teherelosztót (Európában ma ezeket már rendszerirányítóknak nevezik) is érintett, rajtuk kívül pedig több erőmű (köztük egy széntűzelésű hőerőmű) is a megtámadott létesítmények között van, a villamosenergia-szektoron túl pedig többek között kikötői rendszereket is értek támadások.

Az egyre inkább látszik, hogy az országok közötti nézeteltérések nem hagyják érintetlenül az adott országok polgári kritikus infrastruktúráit sem, az ukrán villamosenergia-rendszer utáni 2015-ben és 2016-ban történt támadások után lehetett arról olvasni/hallani, hogy az oroszok az USA villamosenergia-rendszerében, az amerikai szolgálatok pedig az orosz rendszerekhez rendelkeznek rejtett hozzáférésekkel (amolyan modern, kibertérben megvalósított kölcsönösen biztosított megsemmítés-elv szerűen), de ez az eset (és a hasonlók) arra utalnak, hogy a nukleáris fegyverek terjedésével ellentétben a kibertér-képességeit sokkal több ország fejleszti nagyon gyors ütemben. A kérdés már csak az, hogy a magyar illetékesek vajon mit tesznek ebben a témában, különösen a védekezés oldalán?

PerFact OpenVPN kliens sérülékenység

Sharon Brizinov, a Claroty munkatársa egy sérülékenységet jelentett a DHS CISA-nak, amit a PerFact OpenVPN kliensének 1.4.1.0 és korábbi verziókban fedezett fel.

A gyártó a hibát az 1.6.0 verzióban javította. A sérülékenységről további információkat az ICS-CERT publikációjában lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-056-01

Sérülékenységek Fatek rendszerekben

Francis Provencher és rgod, a ZDI-vel együtt dolgozva 5 sérülékenységről közöltek részleteket a DHS CISA-val. A sérülékenységek a Fatek FvDesigner nevű, HMI-ok tervezésére és fejlesztésére használható megoldásának 1.5.76-os és korábbi verzióit érintik.

A gyártó jelenleg is dolgozik a feltárt hibák javításán. 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-21-056-02

Rockwell Automation Logix vezérlők sérülékenysége

Eunseon Jeong, Youngho An, Junyoung Park, Insu Oh és Kangbin Yim a Soonchunhyang Egyetem Information Systems Security Assurance laboratóriumának munkatársai, a Kaspersky, valamint Sharon Brizinov és Tal Keren, a Claroty munkatársai egymástól függetlenül találtak egy kritikus besorolású sérülékenységet a Rockwell Automation alábbi termékeiben:

- RSLogix 5000 szoftverek 16-ostól 20-asig terjedő verziói;
- Studio 5000 Logix Designer szoftverek 21-es és későbbi verziói;
- CompactLogix 1768 vezerlők;
- CompactLogix 1769 vezerlők;
- CompactLogix 5370 vezerlők;
- CompactLogix 5380 vezerlők;
- CompactLogix 5480 vezerlők;
- ControlLogix 5550 vezerlők;
- ControlLogix 5560 vezerlők;
- ControlLogix 5570 vezerlők;
- ControlLogix 5580 vezerlők;
- DriveLogix 5560 vezerlők;
- DriveLogix 5730 vezerlők;
- DriveLogix 1794-L34 vezerlők;
- Compact GuardLogix 5370 vezerlők;
- Compact GuardLogix 5380 vezerlők;
- GuardLogix 5570 vezerlők;
- GuardLogix 5580 vezerlők;
- SoftLogix 5800 vezerlők.

A hibával kapcsolatban a gyártó kockázatcsökkentő és a biztonságot növelő intézkedések és jó gyakorlatok kombinálására bíztatja. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-056-03

ProSoft Technology berendezések sérülékenysége

Maxim Rupp egy sérülékenységet jelentett a DHS CISA-nak a ProSoft Technology alábbi termékeivel kapcsolatban:

- ICX35-HWC-A típusú ipari mobil-átjárók 1.9.62-es és korábbi verziói;
- ICX35-HWC-E típusú ipari mobil-átjárók 1.9.62-es és korábbi verziói.

A gyártó a hibát az érintett termékek firmware-jeinke 1.10.30-as verziójában javította. A sérülékenységről bővebb információkat az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-056-04

Sérülékenység Rockwell Automation FactoryTalk Services Platform termékekben

A Rockwell Automation egy kritikus hibáról közölt információkat a DHS CISA-val, ami a FactoryTalk Services Platform nevű termékük 6.10.00 és 6.11.00 verzióit érinti.

A gyártó a hibát javító új verziót már elérhetővé tette. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-054-01

Advantech Spectre RT ipari routerek sérülékenységei

Ilya Karpov és Evgeniy Druzhinin, a Rostelecom-Solar, valamint Vlad Komarov, a ScadaX munkatársai öt sérülékenységet találtak az Advantech alábbi berendezéseiben:

- Spectre RT ERT351-es típusú ipari routerek 5.1.3 és korábbi firmware-verziói.

A gyártó a hibákat a 6.2.7-es firmware-verzióban javította. A sérülékenységekről további információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-054-03

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

Egy névtelenségét őrző biztonsági kutató a ZDI-vel együttműködve egy kritikus sérülékenységről közölt a DHS CISA-val, amit az Advantech BB-ESWGP506-2SFP-T típusú ipari switch-einek 1.01.09-es és korábbi firmware-verzióiban talált.

A gyártó már felhagyott a BB-ESWGP506-2SFP-T típusú eszközök támogatásával, így a hiba javításával sem foglalkozik. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-054-02

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 104-es protokoll (hivatalosabb nevén az IEC 60870-5-104 protokoll) elsősorban az európai villamosenergia-rendszerek területén elterjedt kommunikációs protokoll, a Snort pedig a legtöbb hagyományos hálózati vagy host-IDS/IPS megoldás alapja. A SANS Reading Room-ban nemrég egy nagyon jó publikációt találtam. A dolgozat szerzője, Adrian Aron nem csak egy teljes, 104-es protokollra vonatkozó protokoll-elemzést nyújt a publikációban, de öt példa Snort-szabályon meg is mutatja, hogy hogyan tudnak a villamosenergia-rendszerek biztonságáért felelős szakemberek a saját környezetük és rendszereik egyedi igényeihez igazított IDS szabályokat készíteni, ezzel is javítva a hálózati forgalom feletti ellenőrzés hatékonyságát.

A publikációt a SANS Reading Room-ban lehet megtalálni.

Sérülékenységek Advantech iView rendszerekben

rgod és egy névtelenségét őrző biztonsági kutató négy sérülékenységet találtak az Advantech iView nevű, eszközmenedzsmentre használt megoldásának v5.7.03.6112-t megelőző verzióiban.

A gyártó a hibákat az 5.7.03.6112-es verzióban javította. A sérülékenységekkel kapcsolatosan bővebb információkat az ICS-CERT publikációjában lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-040-02

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

A Claroty és a Cognite munkatársai egy sérülékenységről közöltek információkat a Rockwell Automation-nel, ami a gyártó alábbi rendszereit érinti:

- DriveTools SP v5.13 és korábbi verziói;
- DriveExecutive v5.13 és korábbi verziói;
- Drives AOP v4.12 és korábbi verziói (amik a Logix Versions v16-tól v30-ig terjedő verzióit támogatják).

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ég részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-042-02

Sérülékenységek ICS rendszerekben használt beágyazott TCP/IP stack-ekben

Daniel dos Santos, Stanislav Dashevskyi, Jos Wetzels és Amine Amri, a Forescout Research Labs munkatársai összesen 9 sérülékenységet azonosítottak az alábbi gyártók termékeiben használt TCP/IP stack-ekben:

- Nut/Net 5.1 és korábbi verziói;
- CycloneTCP 1.9.6 és korábbi verziói;
- NDKTCPIP 2.25 és korábbi verziói;
- FNET 4.6.3 és korábbi verziói;
- uIP-Contiki-OS (end-of-life [EOL]) 3.0 és korábbi verziói;
- uC/TCP-IP (EOL) 3.6.0 és korábbi verziói;
- uIP-Contiki-NG 4. és korábbi verziói;
- uIP (EOL) 1.0 és korábbi verziói;
- picoTCP-NG 1.7.0 és korábbi verziói;
- picoTCP (EOL) 1.7.0 és korábbi verziói;
- MPLAB Net 3.6.1 és korábbi verziói;
- Nucleus NET minden, 5.2-nél korábbi verziója;
- Nucleus ReadyStart ARM, MIPS és PPC architektúrákra fejlesztett változataink minden 2012.12-nél korábbi verziója.

A hibákkal kapcsolatos frissítésekről szóló információkat és kockázatcsökkentő intézkedéseket az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-042-01

Rockwell Automation Allen-Bradley vezérlők sérülékenysége

A Cisco Talos csapata egy sérülékenységet jelentett a Rockwell Automation-nek, ami Allen-Bradley MicroLogix 1100-as PLC-inek 1.0 revízióját érinti.

A gyártó a hibát az éintett PLC-khez kiadott v21.006-os és későbbi 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-21-047-02

Sérülékenységek Open Design Alliance fejlesztő eszközökben

Michael DePlante és rgod, a ZDI-vel együttműködve hat sérülékenységről közölt információkat a DHS CISA-val, amik az Open Design Alliance Drawings SDK nevű fejlesztő eszközének 2021.12-nél korábbi verzióit érintik.

A gyártó a hibát a v2021.12-es és későbbi verziókban javította. A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-047-01

Hamilton Medical rendszerek sérülékenységei

Julian Suleder, Raphael Pavlidis és Nils Emmerich, 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 Hamilton Medical T1 Ventilator nevű megoldásának 2.2.3-as és korábbi verzióiban.

A gyártó a hibákat a 2.2.3-asnál újabb verziókban javította. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsma-21-047-01

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

dliangfun két sérülékenységet jelentett a Mitsubishi Electric-nek, amik a gyártó FA mérnöki szoftverecsomagjának alábbi tagjait érintik:

- C Controller modul beállító és monitoring eszköz minden verziója;
- CPU Module Logging Configuration Tool minden verziója;
- CW Configurator minden verziója;
- Data Transfer minden verziója;
- EZSocket minden verziója;
- FR Configurator minden verziója;
- FR Configurator SW3 minden verziója;
- FR Configurator2 minden verziója;
- GT Designer3 Version1(GOT1000) minden verziója;
- GT Designer3 Version1(GOT2000) minden verziója;
- GT SoftGOT1000 Version3 minden verziója;
- GT SoftGOT2000 Version1 minden verziója;
- GX Configurator-DP 7.14Q és korábbi verziói;
- GX Configurator-QP minden verziója;
- GX Developer minden verziója;
- GX Explorer minden verziója;
- GX IEC Developer minden verziója;
- GX LogViewer minden verziója;
- GX RemoteService-I minden verziója;
- GX Works2, Versions 1.597X and prior
- GX Works3, Versions 1.070Y and prior
- M_CommDTM-HART minden verziója;
- M_CommDTM-IO-Link minden verziója;
- MELFA-Works minden verziója;
- MELSEC WinCPU Setting Utility minden verziója;
- MELSOFT EM Software Development Kit (EM Configurator) minden verziója;
- MELSOFT Navigator minden verziója;
- MH11 SettingTool Version2 minden verziója;
- MI Configurator minden verziója;
- MT Works2 minden verziója;
- MX Component minden verziója;
- Network Interface Board CC IE Control utility minden verziója;
- Network Interface Board CC IE Field Utility minden verziója;
- Network Interface Board CC-Link Ver.2 Utility minden verziója;
- Network Interface Board MNETH utility minden verziója;
- PX Developer minden verziója;
- RT ToolBox2 minden verziója;
- RT ToolBox3 minden verziója;
- C Controller modulhoz tartozó beállító és monitoring eszközök minden verziója;
- SLMP Data Collector minden verziója.

A gyártó a hibákat az egyes szoftverek újabb verzióiban javította. A sérülékenységekről további részleteket az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-049-02

Johnson Controls rendszerek sérülékenysége

A TIM Security Red Team Research csapata egy sérülékenységről közölt információkat a Johnson Controls-szal, ami a Metasys Reporting Engine (MRE) Web Services 2.0 és 2.1-es verzióit érinti.

A gyártó a hibát az MRE v2.2-es és újabb verzióiban 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-21-049-01

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

A Schneider Electric weboldalán publikált információk szerint három sérülékenységet azonosítottak az alábbi PowerLogic termékekben:

- ION7400 minden, V3.0.0-nál korábbi verziója;
- ION7650 minden verziója;
- ION7700/73xx minden verziója;
- ION83xx/84xx/85xx/8600 minden verziója;
- ION8650V 4.31.2-es és korábbi verziói;
- ION8800 minden verziója;
- ION9000 minden, V3.0.0-nál korábbi verziója;
- PM8000 minden, V3.0.0-nál korábbi verziója.

A gyártó a hibákat egyes érintett termékeiben javította, a többi esetén kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről bővebben a Schneider Electric weboldalán lehet olvasni.

Sudo sérülékenység Moxa termékekben

A Moxa publikációja alapján a nemrég a Unix/Linux operációs rendszerekben felfedezett sudo-sérülékenység érinti az alábbi termékeiket:

- ARM-alapú számítógépek:
  - UC-2100 sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-2100-W sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-3100 sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-5100 sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-8100 sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-8100A-ME-T sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-8100-ME-T sorozatú számítógépek Debian 8.x verziójú operációs rendszerei;
  - UC-8100-ME-T sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-8200 sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-8410A sorozatú számítógépek Debian 8.x verziójú operációs rendszerei;
  - UC-8410A sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
  - UC-8540 sorozatú számítógépek Debian 8.x verziójú operációs rendszerei;
  - UC-8580 sorozatú számítógépek Moxa Industrial Linux v1.0 operációs rendszerei;
- x86-alapú számítógépek:
  - MC-1100 sorozatú számítógépek Debian 8.x verziójú operációs rendszerei;
  - MC-1100 sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - MC-1200 sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - V2201 sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - V2403 sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - V2406A sorozatú számítógépek Debian 8.x verziójú operációs rendszerei;
  - V2406C sorozatú számítógépek Debian 7.x verziójú operációs rendszerei;
  - V2416A sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - V2426A sorozatú számítógépek Debian 7.x verziójú operációs rendszerei;
  - V2616A sorozatú számítógépek Debian 7.x verziójú operációs rendszerei;
  - DA-681C sorozatú számítógépek Debian 7.x verziójú operációs rendszerei;
  - DA-681A sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - DA-682C sorozatú számítógépek Debian 8.x verziójú operációs rendszerei;
  - DA-720 sorozatú számítógépek Debian 9.x verziójú operációs rendszerei;
  - DA-820C sorozatú számítógépek Debian 8.x verziójú operációs rendszerei.
- Panel számítógépek és kijelzők:
  - MPC-2070 sorozatú eszközök Debian 9.x verziójú operációs rendszerei;
  - MPC-2101 sorozatú eszközök Debian 9.x verziójú operációs rendszerei;
  - MPC-2120 sorozatú eszközök Debian 9.x verziójú operációs rendszerei;
  - MPC-2121 sorozatú eszközök Debian 9.x verziójú operációs rendszerei.
- Vezérlő és I/O eszközök:
  - ioThinx 4530 sorozatú berendezések 1.3 és korábbi firmware-verziói.

A hibával kapcsolatos javításokról illetve a sérülékenység további részleteiről a Moxa publikációjában lehet olvasni.

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 elmúlt időszak egyik legkomolyabb üzembiztonsági eseménye, a január 8-i európai villamosenergia-rendszer két részre szakadása ismét posztírásra késztette GéPé kollégát:

Az előző posztomban két össze nem függő esetre vezettem le, hogy valójában összefüggenek.

Ennek mintájára ma egy olyan esetet mutatok be, aminek nincs kiberbiztonsági relevanciája. Vagy talán mégis?

Január 8-án ritka esemény történt. Az egységes európai villamosenergia rendszer közép-európai idő szerint 14:05-kor két részre szakadt, az ábrán kékkel jelölt észak-nyugati és a sárgával jelölt dél-keleti részre. Forrás

A szétválás után az észak-nyugati hálózatrészben a villamosenergia-termelésnél mintegy 6.3 GW-tal nagyobb fogyasztás miatt csökkeni kezdett a frekvencia. Ugyanakkor a dél-keleti hálózatrészben a fogyasztásnál nagyobb termelés miatt nőni kezdett a frekvencia. Az észak-nyugati hálózatrész frekvencia csökkenésének megállítására Francia- és Olaszországban mintegy 1.7 GW értékben nagyfogyasztók kerültek lekapcsolásra. Ugyanakkor a dél-keleti hálózatrész termelési többletére tekintettel ott termelő kapacitások kerültek lekapcsolásra. Az európai villamosenergia-rendszer bő 1 órán keresztül két részre szakadva, az alábbi ábra szerinti frekvencia eltérésekkel és mozgásokkal üzemelt mindaddig, amíg a két hálózatrészt összekapcsolva sikerült helyreállítani az egységes rendszert.

Az eddigi – még nem minden részletre kiterjedő, de fő vonalaiban helytálló – elemzés szerint a horvátországi Ernestinovo alállomásban a két 400 kV-os ún. gyűjtősínt összekapcsoló ún. sínáthidaló megszakítót az ún. túláramvédelem kikapcsolta. Jelenleg még nem ismert, hogy valóban volt-e olyan áramnövekedés, amely indokolta a túláramvédelem működését, avagy a védelem valójában indok nélkül kapcsolta ki a sínáthidaló megszakítót.

Nyilván felmerül a kérdés, hogy mindennek mi a kiberbiztonsági relevenciája?!

Nézzük a történtek lényegét! Valahol Európában egyetlen (!) megszakító kikapcsolódása úgy hasította szét – és tette átmenetileg instabillá – az egységes európai villamosenergiarendszert, hogy az egységes, stabil üzemet csak 1 óra múltán sikerült helyreállítani.

Ennek tudatában gondoljunk bele a következőbe! Mi van akkor, ha egy magasan képzett, erőforrásokban gazdag (mondjuk APT) támadó is azonosítani tudja ezt az egy – vagy további néhány – kulcsfontosságú megszakítót és SCADA és/vagy RTU és/vagy védelmi sérülékenységet kihasználva kikapcsolja az(oka)t.

Ne gondoljuk azt, hogy ez képtelenség! Nem túl sok kutakodással (akár passzív OSINT révén is) megismerhető az európai villamosenergia-rendszer topológiája. Némi szakértelemmel felépíthető a hálózat számítógépes modellje, amelyen aztán szimulálható a különféle kapcsolások hatása. Egy állami hátterű támadónak, egy APT-nek ez nem lehet gond. Emlékezzünk a pl. Pivnichna-i (Ukrajna) átviteli hálózati alállomás elleni 2016. évi támadásra, amely a gyakorlatban mutatta meg a támadó magas szintű villamostechnológiai ismereteit!

Európában leginkább a 2006. november 4-ei kontinentális üzemzavar mutatta meg azt, hogy sajnos lehetnek olyan rendszerelemek, melyek kikapcsolása lavinaszerű kikapcsolódásokat – ezzel nagy kárral járó, kiterjedt ellátatlanságot – okozhat. Észak-Németországban, egy túlméretes hajó biztonságos áthaladására tekintettel, elővigyázatossági okból, egy a folyón átívelő 400 kV-os távvezetéket kikapcsoltak. A műveletet gondosan megtervezték, a várható terheléseloszlást modellezték. Viszont valamely okból a tervezettnél előbbre hozták a kikapcsolást. Ekkor viszont a modellezettől eltérőek voltak a terhelés viszonyok. A távvezeték kikapcsolása nyomán meginduló sorozatos túlterhelődések miatti vezeték kiesések után az egységes európai villamosenergia-rendszer 18 mp alatt három részre szakadt. Az egyik „szigetben” a blackout csak tömeges fogyasztói korlátozással, hatalmas kárt okozva volt megelőzhető. Ebben az esetben is volt tehát egy olyan kritikus hálózati elem, melynek kikapcsolása rendszerüzemzavart volt képes kiváltani.

Vegyük észre, hogy mind az idén januári, mind a 2006. novemberi kontinentális rendszerüzemzavarokat is egyetlen (!) hálózati elem kiválása okozta. Ne legyen kétségünk, hogy az a támadó, aki egyetlen rendszerelemet ki tud ejteni, az ne lenne képes további, előzetesen jól kiválasztott rendszerelemek kiejtésével súlyosbítani a hatásokat, akár a blackout-ig!

Az USA már évekkel korábban felismerte a néhány kritikus hálózati elem kiejtésével előidézhető, akár kontinentális kiterjedésű üzemzavar veszélyét. A 2014-ben elvégzett vizsgálat szerint az USA 55.000 alállomása között található 9 olyan alállomás (négy keleten, három nyugaton, kettő pedig Texasban), melyeknek egy kánikulai napon történő kiejtése kontinentális blackout-ot képes kiváltani.

Az idén januári eset rámutatott arra, hogy az európai villamosenergia-rendszernek lehetnek olyan kritikus állapotai, amelyekben egy vagy néhány rendszerelem kiesése – rosszabb esetben támadó általi kiejtése – kiterjedt üzemzavart, szélső esetben blackout-ot okozhat.

Növeli ennek esélyét, ha óvatlanul, nem törődve a támadó által végezhető OSINT révén megszerezhető adatok kockázatával, mi magunk tesszük elérhetővé számára hálózatunk érzékeny adatait.

De legfőképp ne becsüljük le a támadó képességét! Ahogy Szun-Ce írta: „Ne becsülj alá egyetlen ellenséget sem, mert könnyen lehet, az pontosan erre számít.”

Sérülékenység Belden ICX35 típusú ipari vezeték nélküli eszközökben

A Belden publikációja szerint a ProSoft Technology nevű leányvállalatuk alábbi termékeiben egy sérülékenységet azonosítottak:

- ICX35-HWC-A típusú berendezések 1.9.62-es és korábbi verziói;
- ICX35-HWC-E típusú berendezések 1.9.62-es és korábbi verziói.

A gyártó a hibát az 1.10.30-as és újabb verziókban javította. A sérülékenység részleteit a Belden publikációjában lehet megtalálni.

Rockwell Automation MicroLogix berendezések sérülékenysége

A Veermata Jijabai Technological Institute egy sérülékenységet talált a Rockwell Automation MicroLogix 1400 típusú vezérlőinek 21.6-os és korábbi firmware-verzióiban.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. 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-21-033-01

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

Francis Provencher, a ZDI-vel együttműködve egy sérülékenységről közölt információkat a DHS CISA-val, ami a Horner Automation Cscape nevű, vezérlőrendszerek fejlesztésére használható rendszerének minden, 9.90 SP3.5-nél korábbi verzióját érinti.

A gyártó a hibát a Cscape 9.90 SP3.5-ös verziójában javította. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-035-02

Luxion rendszerek sérülékenységei

rgod, a ZDI-vel közösen 5 sérülékenységet jelentett a DHS CISA-val, amiket a Luxion alábbi rendszereiben talált:

- KeyShot 10.1-nél korábbi verziói;
- KeyShot Viewer 10.1-nél korábbi verziói;
- KeyShot Network Rendering 10.1-nél korábbi verziói;
- KeyVR 10.1-nél korábbi verziói.

A gyártó a hibákat az érintett termékek 10.1-es verzióiban javította. 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-21-035-01

Sérülékenység Siemens DIGSI 4 rendszerekben

Rich Davy, az ECSC Group munkatársa egy sérülékenységet talált a Siemens DIGSI 4 rendszerek v4.94 SP1 HF1-nél korábbi verzióiban.

A gyártó a hibát a v4.94 SP1 HF1-es és újabb verziókban javította. A sérülékenységgel kapcsolatban részleteket az ICS-CERT bejelentésében lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-040-10

Sérülékenység Siemens SIMATIC WinCC és PCS 7 rendszerekben

Enrique Murias Fernandez, a Tecdesoft Automation munkatársa egy sérülékenységet azonosított a Siemens alábbi rendszereiben:

- SIMATIC PCS 7 minden verziója;
- SIMATIC WinCC minden, 7.5 SP2-nél korábbi verziója.

A gyártó a hibát a WinCC esetében a 7.5 SP2 és későbbi verziókban javította, a PCS 7 támogatása viszont már megszűnt, ezért ehhez javítás nem várható. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

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

Daniel dos Santos, a Forescout Technologies munkatársa egy sérülékenységet talált a Siemens alábbi rendszereiben:

- Nucleus NET minden V5.2-nél korábbi verziója;
- Nucleus ReadyStart ARM-re MIPS-re és PPC-re készült változatainak minden, V2012.12-nél korábbi verziója.

A hibával kapcsolatban a gyártó az érintett rendszerek legújabb verzióra történő frissítését javasolja. A sérülékenység részleteit a Siemens ProductCERT publikációja tartalmaz.

Sérülékenység Siemens rendszerekben

rgod a ZDI-vel együttműködve egy sérülékenységről közölt információkat a DHS CISA-val, ami a Siemens alábbi rendszereit érinti:

- SINEC NMS összes, v1.0 SP1 Update 1-nél korábbi verziója;
- SINEMA Server minden, v14.0 SP2 Update 2-nél korábbi verziója.

A gyártó a hibát az érintett termékek legújabb verziójában javította. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenységek Siemens RUGGEDCOM eszközökben

A Siemens ProductCERT által nyilvánosságra hozott információk szerint fél tucat sérülékenységet azonosítottak a RUGGEDCOM termékcsalád alábbi tagjaiban:

- RUGGEDCOM ROX MX5000 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX1400 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX1500 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX1501 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX1510 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX1511 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX1512 minden, v2.14.0-nál régebbi verziója;
- RUGGEDCOM ROX RX500 minden, v2.14.0-nál régebbi verziója.

A hibákat a gyártó a v2.14.0 és újabb verziókban javította. A sérülékenységek részleteiről bővebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Siemens TIA Administrator sérülékenység

Will Dormann, a CERT/CC munkatársa egy sérülékenységet talált az alábbi Siemens rendszerekben:

- PCS neo (Administration Console) v3.0;
- TIA Portal v15, v15.1 és v16.

A gyártó a hibával kapcsolatban javítást és kockázatcsökkentő intézkedésekre vonatkozó ajánlásokat adott ki. A sérülékenység részleteit a Siemens ProductCERT és az ICS-CERT publikációi tartalmazzák.

Sérülékenységek Siemens T2Go és Teamcenter Visualization rendszerekben

Michael DePlante, Francis Provencher és rgod összesen 21 sérülékenységet azonosítottak a Siemens alábbi termékeiben:

- JT2Go minden v13.1.0.1-nél korábbi verziója;
- Teamcenter Visualization minden v13.1.0.1-nél korábbi verziója.

A gyártó a hibákat az érintett termékek v13.1.0.1-es és újabb verzióiban javította. A sérülékenységekkel kapcsolatban bővebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Siemens SCALANCE sérülékenység

A Siemens ProductCERT egy sérülékenységről közölt információkat a DHS CISA-val, ami a SCALANCE termékcsalád W780-as és W740-es sorozatú eszközeinek v6.3-asnál korábbi verzióit érinti.

A gyártó a hibát a v6.3-as és újabb verziókban javította. A sérülékenységről bővebb információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet elérni.

Sérülékenység Siemens SIMARIS configuration szoftverekben

Richard Davy, az ECSC Group munkatársa egy sérülékenységet talált a SIMARIS configuration nevű tervezőszoftverben. A hiba az érintett termék minden verzióját érinti.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT publikációiból lehet tájékozódni.

GE Digital rendszerek sérülékenységei

William Knowles, az Applied Risk a DHS CISAmal, Sharon Brizinov pedig a GE-nek jelentette ugyanazt a két sérülékenységet, amik a GE HMI/SCADA iFIX rendszerek 6.1-es és korábbi verzióit érintik.

A hibákkal kapcsolatban a gyártó az érintett termékek 6.5-ös verziójára történő frissítést javasolja. 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-21-040-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.

Az elmúlt néhány napban sajnos nem volt elég időm a blogra, de a floridai Oldsmar nevű kisváros vízművében történt ICS biztonsági incidens mellett nem lehet elmenni szó nélkül (főleg, hogy erről viszonylag gyorsan egyes magyar híroldalakon is jelentek meg hírek). Ezek a cikkek egészen jól feldolgozták az eseményeket, így én inkább azt nézném meg, hogy mit is jelentenek ennek a támadásnak a jelenleg ismert részletei.

1. Bár maga az incidens súlyos (a támadó több, mint százszorosára emelte a vízmű ICS rendszereiben szerzett jogosultsággal a vízhez adagolt nátrium-hidroxid mennyiségét), de az eddig megismert részletek alapján a kibertámadás nem volt sem kifinomult, sem összetett. A támadó (vagy támadók), a rendelkezésre álló információk szerint egy, a vízműben dolgozó felügyelők (mérnökök) által üzemszerűen a távoli hozzáférésre használt TeamViewer alkalmazáson keresztül fértek hozzá a vízmű ICS rendszereihez, a TeamViewer-hez pedig egyetlen jelszót használt több felhasználó is.

2. Ráadásul a TeamViewer egy Windows 7 operációs rendszert futtató számítógépre volt telepítve (ahogy azt még a magyar cikkek is kihangsúlyozzák, a Windows 7 már több, mint egy éve nem rendelkezik gyártói támogatással, de ez a legtöbb ipari szervezetet nem nagyon zavarja, főleg, mert még mindig több Windows XP-t futtató számítógépet használt a folyamatírányátáshoz, mint Windows 7-et).

3. Ha a korábbiak nem lettek volna elég elrettentőek, akkor további adalék, hogy a TeamViewer-t futtató Windows 7 tűzfallal sem volt leválasztva az Internetről.

4. Az már csak az OSINT iránt érdeklődők számára csemege, hogy az érintett vízműben használt HMI-ról és annak konfigurációjáról könnyedén lehet szabadon elérhető információkat találni. (Szerk.: Időközben a képet a mckimcreed.com-ról eltávolították, de a lényeg, hogy kint volt. A konkrét kép egyébként a Google Cache-ben még elérhető... Ezért kell óvatosnak lenni a megosztott információk terén.)

Ez az incidens tehát (megint hangsúlyozom, az ebben a pillanatban rendelkezésre álló információk alapján) egy alkalom szülte eset, amit akár egy kezdő script-kiddie is összehozhatott.

Gyorsan fussunk is át azon, mik azok az alapvető intézkedések, amiket ajánlott minden ICS rendszereket használó szervezetnek alapvető biztonsági ökölszabályként kezelni:

1. Az ICS rendszereket le kell választani a külső és különösen a publikus hálózatokról - ha máshogy nem megy, hát megfelelően konfigurált tűzfalakkal!

2. A vállalati/irodai/ügyviteli és ICS hálózatokat szintén le kell választani egymástól és kizárólag a szükséges hálózati forgalmakat szabad engedélyezni a minimálisan szükséges mértékben!

3. Távoli hozzáférésre biztonságos módszereket (VPN, több faktoros authentikáció, stb.) használva szabad engedélyt adni.

4. Ragaszkodni kell (az elszámoltathatóság információbiztonsági alapelvéhez ragaszkodva) a személyhez köthető egyedi hozzáférések használatához és a minimális jogosultság elvéhez!

5. Kontrollálni kell és minimálisra kell szorítani a folyamatírányátáshoz használt rendszereinkről nyilvánosan megjelent információkat!

Nyilván ez az 5 pont korántsem fog minden támadástól megvédeni, de egy hasonló incidenst már jó eséllyel meg lehet előzni ezeknek a szabályoknak, elveknek a betartásával.

Ransomware-támadások amerikai ipari szereplők ellen

A hírek szerint még január 23-án ransomware-támadás érte a WestRock nevű amerikai vállalatot, ami csomagolóanyagok, főként hullámpapír gyártásával foglalkozik. Az incidens az ügyviteli/irodai rendszereik mellett a gyártásautomatizálásban használt rendszereket is érintette. A vállalat meglehetősen szűkszavú az esettel kapcsolatban, de az alapján, hogy az incidens elérte az OT rendszereiket is, mindenképp súlyos incidensről lehet szó.

Egy másik híradás szerint még tavaly decemberben történt zsarolóvírus-támadás a Tennesse állambeli Forward Air Corporation nevű szállítmányozó cég rendszereiben. Az incidens az USA tőzsdei felügyeleti szerveként működő SEC közlése szerint legalább 7,5 millió amerikai dollárnyi kárt okozott a FAC-nek. Bár az incidensről kevés részletet lehet tudni (még az sem nyilvános, melyik ransomware a felelős), annyit lehet tudni, hogy a FAC már képes volt a működéséhez szükséges rendszereket helyreállítani.

Tavaly már írtam arról, hogy az amerikai fegyveres erők vezetésével évek óta rendeznek olyan gyakorlatokat, amelyek célja különböző forgatókönyvek mentén az amerikai villamosenergia-rendszer elleni kibertámadások hatásait és a védekezés lehetséges módjait tesztelik.

2020-ban ez a teszt, ami (szokás szerint) a Long Island mellett található Plum Island-en kapott helyet, a COViD miatt ugyanúgy kicsit máshogy lett végrehajtva, mint annyi minden más. A gyakorlat résztvevői döntő többségükben távolról csatlakoztak a teszthez felépített villamosenergia-hálózat egyes létesítményeihez, fizikailag csak azok a szakemberek voltak a szigeten, akiknél a feladataik ezt nélkülözhetetlenné tették.

A gyakorlat részleteiről és a Plum Island-i gyakorlat utóéletéről a CyberScoop cikkében lehet olvasni. Én már csak arra lennék kíváncsi, hogy az illetékesek mikor szeretnék megrendezni az első magyar, kifejezetten szektor-specifikus kiberbiztonsági gyakorlatokat (villamosenergia-szektor, viziközmű vállalatok, gáz- és olajipar, stb. számára)?