Számos hírforrás hozta le a mai nap folyamán a hírt, miszerint kibertámadás érte a Colonial Pipeline nevű amerikai cég (amely naponta közel félmillió liter üzemanyagot szállít csővezetékein) rendszereit pénteken. A támadás (egyelőre ransomware-támadásról lehet hallani) "egyes IT rendszereiket" érte, és "elővigyázatosságból ideiglenesen leállították bizonyos rendszereiket, köztük egyes, a csővezetékek üzemeltetésében érintett rendszereket is."

További részletek egyelőre nem ismertek, de az már a tavalyi évben is tisztán látszott, hogy már nincs olyan iparág, amit ne vennének célba a különböző ransomware-ek - vajon a magyar vállalatok mennyire felkészültek az ilyen fenyegetésekre?

Szerk (2021.05.10.): Még mindig keveset tudunk, de egy ismerősömtől (aki igencsak otthonosan mozog az USA kritikus infrastruktúrájának kiberbiztonsági kérdéseiben) azt a véleményt hallottam, hogy az ügyviteli IT rendszerek érintettsége (ha például a üzemanyag-kereskedéshez használt rendszerek is érintettek) miatt is dönthettek úgy, hogy inkább leállítják a csővezeték rendszer irányításáért felelős rendszereket és ezzel magát a vezetékeket is. Egy ilyen döntéshez az én meglátásom szerint nagyon komoly pénzügyi kockázatelemzési képességekkel kell rendelkezni, hiszen az egyik kockázatot (a teljes csővezeték leállítása okozta pénzügyi veszteséget) kell szembeállítani a másik kockázattal (a nem működő kereskedéshez használt rendszer nélkül történő üzemanyag-szállításból eredeztethető anyagi veszteséggel). A forrásom szerint egyébként nem ez az első ilyen, csővezeték-hálózat IT/OT rendszereit érintő kiberbiztonsági incidens.

Ezzel párhuzamosan a blogon már jó néhányszor hivatkozott Robert M. Lee is megszólalt az incidens kapcsán, a Twitteren az alábbiakat írta (nem szoktam angol forrásokat hosszan idézni a blogon, de ebben a gondolatmenetben több olyan dolog is megjelenik, amikről a következő hetekben lehetne és kéne kicsit részletesebben írni - remélem lesz időm, de ha bárkinek van ehhez vagy bármelyik másik részhez kapcsolódóan véleménye, csak bátran, akár a kommentek között is elindulhat egy érdekes beszélgetés):

"In my opinion there's some bad takes out there but overall it's completely reasonable that folk are paying attention. This is the most disruptive incident we've seen on US energy infrastructure from cyber instrusions. Colonial Pipeline is the victim and has done a lot right. They contacted a top tier incident response firm (FireEye/Mandiant) for the enterprise compromise (only IT impacted it seems) to lead the response. They informed the USG [US Government - szerk.] who had great folks form CISA/FBI/DOE supporting. They focused on safety and took operations down proactively.

Congress and others will reasonably ask: "If a criminal can do this, what more could a state adversary do?" While we should avoid hype this is a very reasonable question. The reality is our infrastructure is undergoing a rapid digital transformation. While the ransomware was confined to IT this could have been much worse if it had hit OT and at Dragos we have handled such cases and they candidly suck. AS our industries change the historical mindset of "segment and disconnect OT" just isn't practical in most cases. 75+% of many of the standards/regulations/frameworks/etc. push for preventive controls (segmentation, authentication, anti malware, patching, etc.) all good controls but that leaves an under investment in detection and response. As our infrastructure changes, so will our threats.

What we see most commonly is without visibility and monitoring in OT networks the preventive controls are not applied everywhere and atrophy over time unkowningly to the defenders. Many realize this though. The current White House administration has rightfully pushed for a 100 day action plan to encourage visibility, detection, and response enchancements in OT in the electricity sector and likely following suit in water and natural gas to raise awareness.

To the practitioners out there thinking about their OT networks I would encourage engaging firms with OT/ICS incident response experience. Conduct a TTX to reherse. Use burn down to do an Architecture Review of what you have today and it's state. Then move into monitoring in OT. For the executives out there realize your IT and Security staff are usually already under invested in. Picking up a whole new mission set with focus (OT) requires additional resources. Elevate the conversation in your org and invest in your people to enable your business."

Szerk2: A hírek továbbra is csordogálnak, most a Waterfall és a Dragos incidenssel kapcsolatos posztjaiba futottam bele, mint érdekesebb forrásokba illetve egy hazai, légiközlekedéssel foglalkozó oldal, az AirPortal.hu cikke érdekes még, ami szerint a Colonial Pipeline ideiglenes csővezeték-leállítása már 2-3 nap után komolyan érezteti a hatását az USA egyes déli és keleti szövetségi államaiban található repülőterek kerozin-ellátásában.

Még egy érdekesség: Miközben a Dragos blogposzt linkjét kerestem, találtam egy másik, 2020. elején született írásukat, ahol egy földgáz szállításra használt másik csővezetéket üzemeltető vállalat elleni ransomware-támadásról írnak (ez annak idején az én figyelmemet is elkerülte). Szóval a forrásomnak teljes mértékben igaza volt, amikor azt mondta, nem ez volt az első eset, amikor az USA energiaszektorában használt csővezetékeket üzemeltető céget ért zsarolóvírus-támadás.

Az IBM (és X-Force néven ismert biztonsági kutatócsapata) nem túl gyakran kerülnek szóba az ICS kiberbiztonsággal kapcsolatban, pedig egy alapvetően jó és tapasztalt csoportról van szó. A még március végén megjelent Threat Intelligence Index nevű éves kiadványukban számunkra most az az igazán érdekes, hogy az általuk feltárt kutatási adatok alapján a három dobogós szektor közül (akiket a legtöbb célzott kibertámadás ért 2020-ban), kettő (a második és harmadik helyezett, az első még mindig a pénzügyi szektor) ipari szektor. A második helyre a gyártóvállalatok kerültek, a harmadik helyen pedig már az energiaszektor, vagyis a nemzeti kritikus infrastruktúrák alfája és omegája került.

A gyártóvállalatok elleni támadások egy jelentős része zsarolóvírus-támadás volt, amik számos esetben jelentős veszteséggel járó, hosszabb-rövidebb leállásokat okoztak a termelésirányítási és készletezési-raktározási rendszerekben.

Az energiaszektorban tapasztalt támadások valamivel több, mint harmada (35%-a) adatlopási kísérlet volt, itt a ransomware-ek "csak" 6%-ot tettek ki.

Hasonló tendenciákat lehet látni a Kaspersky 2020 második félévet felölelő ICS biztonsági összefoglalójában, ami az egyes országok ICS rendszerei és berendezései elleni zsarolóvírus-támadások növekedéséről számol be.

A hivatkozott összefoglalók kiválóan illeszkednek a többi, hasonló kiadvány sorába és mutatja, hogy az ipari szervezetek és ezek ICS rendszerei egyre nagyobb kiberbiztonsági kockázatokkal működnek, amikre ezeknek a szervezeteknek hatékony és gyors válaszokat kell adniuk. Ez nem fog működni máshogy, mint az IT és OT szakterületek soha korábban nem látott hatékonyságú együttműködésével - ez azonban nem vagy csak fájdalmasan lassan fog megvalósulni, ha alulról építkezve, az IT-s és OT-s mérnökök által kezdeményezve akarják a szervezetek felépíteni az együttműködést és a vállalati menedzsment nem vállal ebben (is) vezető szerepet.

Sérülékenységek Moxa NPort készülékekben

Alexander Nochvay, a Kaspersky Lab ICS CERT részlegének munkatársa négy sérülékenységet fedezett fel a Moxa alábbi termékeiben:

- NPort IA5150A/IA5250A sorozatú berendezések 1.4-es és korábbi firmware-verziói;
- NPort IA5450A sorozetú eszközök 1.7-es és korábbi firmware-verziói.

A hibákkal kapcsolatban a gyártó javításokat és kockázatcsökkentő intézkedésekre vonatkozó javaslatokat adott ki. A sérülékenységek részleteiről a Moxa bejelentéséből lehet tájékozódni.

Johnson Controls exacqVision sérülékenység

A Johnson Controls egy sérülékenységről közölt információkat a DHS CISA-val, ami az Exacq Technologies nevű leányvállalatuk alábbi, Ubuntu-alapú rendszereit érinti:

- a Linux-alapú Z- és A-sorozatú termékeik;
- Q-sorozat;
- G-sorozat;
- Legacy LC-sorozat;
- Legacy ELP-sorozat;
- exacqVision Network Video Recorders (NVR);
- a Linux-alapú C-sorozatú munkaállomások;
- S-sorozatú storage szerverek.

A gyártó a hibával kapcsolatban a megfelelő Ubuntu biztonsági javítások telepítését javasolja. A sérülékenységről további információkat az ICS-CERT publikációja: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-03

Sérülékenység Cassia Networks rendszerekben

Amir Preminger és Sharon Brizinov, a Claroty munkatársai egy sérülékenységet találtak a Cassia Networks Access Controllereinek 2.0.1-nél korábbi verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette. A sérülékenységgel kapcsolatos részleteket az ICS-CERT weboldalán lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-02

Texas Instruments rendszerek sérülékenységei

David Atch és Omri Ben Bassat, a Microsoft munkatársai öt sérülékenységet azonosítottak a Texas Instruments alábbi termékeiben:

- SimpleLink MSP432E4 SDK v4.20.00.12 és korábbi verziói;
- SimpleLink CC32XX SDK v4.30.00.06 és korábbi verziói;
- SimpleLink CC13X0 SDK v4.10.03-nál korábbi verziói;
- SimpleLink CC13X2 SDK v4.40.00-nál korábbi verziói;
- SimpleLink CC26XX SDK v4.40.00-nál korábbi verziói;
- CC3200 SDK v1.5.0 és korábbi verziói;
- CC3100 SDK v1.3.0 és korábbi verziói.

A hibákat a gyártó az érintett termékek legújabb verzióiban javította. A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-01

Delta Electronics CNCSoft ScreenEditor sérülékenység

Kimiya, 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 Delta Electronics CNCSoft ScreenEditor nevű megoldásának v1.01.28-nál korábbi verzióit érinti.

A gyártó a hibát a v.1.01.30-as verzióban javította. A sérülékenységgel kapcsolatos további részleteket az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-124-02

Sérülékenység Advantech rendszerekben

Chizuru Toyama, a TXOne IoT/ICS Security Research Labs munkatársa a ZDI-vel közösen egy sérülékenységet jelentett a DHS CISA-nak, ami az Advantech WISE-PaaS/RMM 9.0.1-nél korábbi verzióit érinti.

A gyártó az érintett termék forgalmazását és támogatását megszüntette, így a hibához javítás sem várható. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-124-01

Sérülékenységek valós idejű operációs rendszerekben (RTOS)

David Atch, Omri Ben Bassat és Tamir Ariel, a Microsoft Section 52 munkatársai, valamint az Azure Defender for IoT research group munkatársai összesen 23 sérülékenységről osztottak meg információkat a DHS CISA-val, amik az alábbi valós idejű operációs rendszereket (Real-Time Operating System, RTOS) érintik:

- Amazon FreeRTOS 10.4.1-es verziója;
- Apache Nuttx OS 9.1.0 verziója;
- ARM CMSIS-RTOS2 2.1.3-nál korábbi verziója;
- ARM Mbed OS 6.3.0 verziója;
- ARM mbed-uallaoc 1.3.0 verziója;
- Cesanta Software Mongoose OS v2.17.0 verziója;
- eCosCentric eCosPro RTOS 2.0.1-től 4.5.3-ig terjedő verziói;
- Google Cloud IoT Device SDK 1.0.2 verziója;
- Linux Zephyr RTOS 2.4.0-nál korábbi verziói;
- Media Tek LinkIt SDK 4.6.1-nél korábbi verziói;
- Micrium OS 5.10.1-es és korábbi verziói;
- Micrium uCOS II/uCOS III 1.39.0 és korábbi verziói;
- NXP MCUXpresso SDK 2.8.2-nél korábbi verziói;
- NXP MQX 5.1 és korábbi verziói;
- Redhat newlib 4.0.0-nál korábbi verziói;
- RIOT OS 2020.01.1 verziója;
- Samsung Tizen RT RTOS 3.0.GBB-nél korábbi verziói;
- TencentOS-tiny 3.1.0 verziója;
- Texas Instruments CC32XX 4.40.00.07-nél korábbi verziói;
- Texas Instruments SimpleLink MSP432E4XX
- Texas Instruments SimpleLink-CC13XX 4.40.00-nál korábbi verziói;
- Texas Instruments SimpleLink-CC26XX 4.40.00-nál korábbi verziói;
- Texas Instruments SimpleLink-CC32XX 4.10.03-nál korábbi verziói;
- Uclibc-NG 1.0.36-nál korábbi verziói;
- Windriver VxWorks 7.0-nál korábbi verziói.

A hibákra az egyes gyártók által kiadott javításokért és további részletekért az ICS-CERT publikációját érdemes átnézni: https://us-cert.cisa.gov/ics/advisories/icsa-21-119-04

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 okosmérők az ICS biztonság egyik méltatlanul háttérbe szorult komponens-csoportját alkotják, éppen ezért örültem, hogy nemrég a FireEye (illetve a FireEye-hoz tartozó Mandiant) kutatói egy okosmérők biztonsági teszteléséről szóló cikket publikáltak.

Az okosmérők egyre gyorsabban terjednek, ha valaki pl. "villanyóra" cserét kér az áramszolgáltatójától (akár csak bővítés, akár háztáji naperőmű kiépítése miatt), szinte biztos, hogy ilyen berendezést fognak felszerelni nála, vagyis a hazai mérőórák (nem csak az áramszolgáltatók mérői, de azok talán a legnagyobb mértékben) egyre nagyobb hányada képes már kommunikálni valamilyen (többnyire publikus) hálózaton. Azt pedig tudjuk, hogy ami képes publikus hálózaton, szabványos protokollon kommunikálni, azt előbb vagy utóbb meg fogják találni azok az emberek is, akik vagy szakmai kíváncsiságtól hajtva és kizárólag a legjobb szándékkal vagy kevésbé jó szándékkal és saját céljaiktól (bármik is legyenek azok) vezérelve elkezdenek hibákat keresni ezekben a berendezésekben. Hibák viszont minden, szoftver-vezérelt eszközben lesznek, ezt ma már szinte senki sem vitatja, ami azt jelenti, hogy ezeket az eszközöket lehet informatikai eszközökkel és módszerekkel támadni, el lehet lehetetleníteni a működésüket illetve át lehet venni felettük az irányítást.

Itt most térjünk ki egy kicst Marc Elsberg Blackout című könyvére, amit én még 2016-ban olvastam és aminek a története azzal indul, hogy valakik kompromittálnak nagyszámú okos villamosenergia-mérőt Európai országokban, majd azokat egyszerre lekapcsolva a kontinens nagy részére kiterjedő üzemzavart idéznek elő. Amikor ezt a könyvet olvastam, beszélgettem néhány emberrel a villamosenergia-szektorból, akik határozottan állították, hogy ilyen módon nem lehet üzemzavart előidézni, én azonban már akkor és most is úgy gondolom, hogy néhány tényező együttállása esetén bizony nem is olyan lehetetlen egy hasonló forgatókönyv.

Egyrészt az nem igazán lehet kérdés, hogy az okosmérők szoftveresen ugyanolyan sérülékenyek lehetnek, mint bármilyen más "okos" eszköz, a fitnesz-karkötőtől az okoshűtőn keresztül az ipari IoT (IIoT) eszközökig.

Másrészt, amennyire én tudom (vajon jól tudom?) nincs olyan nagyon sok különböző gyártótól származó, eltérő firmware-családdal működő okosmérő egy-egy közüzemi szektorban, így a villamosenergia-szektorban is okkal feltételezhetjük, hogy nem túl sok különböző modell működik ezekből az okosmérőkből.

Ezek után már csak néhány olyan (0-day, vagyis javítást még nem kapott) sérülékenységre van szükség, valamint némi háttérre és szervezőkészségre, hogy egy támadói csoport nagy mennyiségű okosmérő kompromittálása után egy összehangolt akcióval már rendszer szinten érezhető fogyasztást tűntessen el egyik pillanatról a másikra a villamosenergia-rendszerből. Ekkor pedig már az áramszolgáltató, rosszabb esetben a villamos teherelosztó felkészültségén múlik, hogy egy ilyen incidenshez társul-e üzemzavar is?

Így talán már látható, miért érzem fontosnak az ilyen teszteket, publikációkat és kíváncsian várom, hogy hazai kutatók, IT és/vagy OT biztonsággal foglalkozó cégek mikor jelentkeznek olyan publikációkkal, amikben a hazai okosmérők biztonsági teszteléséről szóló tapasztalataikat osztják meg. Diplomamunka szintén született már színvonalas dolgozat a témában, de (amint a FireEye kutatóinak publikációjából is látszik) bőven van még hova fejlődni ebben a témában is.

Sérülékenységek Eaton rendszerekben

Amir Preminger, a Claroty munkatársa hat sérülékenységet fedezett fel az Eaton alábbi rendszereiben:

- Eaton Intelligent Power Manager (IPM) minden, 1.69-nél korábbi verziója;
- Eaton Intelligent Power Manager Virtual Appliance (IPM VA) minden, 1.69-nél korábbi verziója;
- Eaton Intelligent Power Protector (IPP) minden, 1.68-nál korábbi verziója.

A gyártó a hibákat az érintett termékek újabb verzióiban javította. A sérülékenységek részletiről az ICS-CERT publikációjából lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-06

Delta Electronics CNCSoft-B szoftverek sérülékenységei

Natnael Samson, a ZDI-vel együttműködve két sérülékenységet jelentett a DHS CISA-nak a Delta Electronics CNCSoft-B nevű szoftver-menedzsment platformjának 1.0.0.3-as és korábbi verzióiban.

A gyártó a hibákat az 1.0.0.4-es verzióban javította. A sérülékenységekkel kapcsolatos további információkat az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-05

Sérülékenység Delta Electronics CNCSoft ScreenEditor szoftverekben

Ugyancsak Natnael Samson találta azt a sérülékenységet, ami a CNCSoft 1.01.28-as és korábbi verziói közül a ScreenEditor 1.01.2-vel működő telepítéseit érinti.

A gyártó a hibát a CNCSoft 1.01.30-as verzióban javította. A sérülékenységről bővebb információkat az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-04

Delta Industrial Automation COMMGR sérülékenység

Peter Cheng, az Elex CyberSecurity CyberSpace Non-Attack Research Institute nevű kutatóközpontjának munkatársa egy sérülékenységet azonosított a Delta Industrial Automation COMMGR nevű kommunikáció-menedzsment szoftverének és az ahoz tartozó PLC-szimulátorának 1.12-es és korábbi verzióiban.

A gyártó a hibát az 1.13-as verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-03

Sérülékenységek Rockwell Automation Stratix hálózati eszközökben

A Cisco összesen 7 sérülékenységről közölt információkat a Rockwell Automation-nel, amik a gyártó Stratix nevű, ipari környezetekbe szánt hálózati eszközei közül az alábbiakat érintik:

- Stratix 5800 16.12.01 és korábbi verziói;
- Stratix 8000 15.2(7)E3 és korábbi verziói;
- Stratix 5700 15.2(7)E3 és korábbi verziói;
- Stratix 5410 15.2(7)E3 és korábbi verziói;
- Stratix 5400 15.2(7)E3 és korábbi verziói.

A gyártó a hibákat a Stratix 5800-asok esetén a 17.04.01-es és újabb verziókban javította, a többi érintett termék esetén kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatos további részleteket az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-02

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

A Hitachi ABB Power Grids egy sérülékenységről közölt információkat a DHS CISA-val, ami az Ellipse APM nevű termékeik alábbi verzióit érinti:

- Ellipse APM 5.3.0.1 és korábbi verziói;
- Ellipse APM 5.2.0.3 és korábbi verziói;
- Ellipse APM 5.1.0.6 és korábbi verziói.

A gyártó a hibát az 5.3.0.2-es, 5.2.0.4-es és 5.1.0.7-es verziókban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-110-01

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

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

- GOT2000 sorozat
  - GT27 modell minden verziója;
  - GT25 modell minden verziója;
  - GT21 modell minden verziója;
   - GT2107-WTBD modell minden verziója;
   - GT2107-WTSD modell minden verziója;
- GOT SIMPLE sorozat
  - GS21 model.
   - GS2110-WTBD-N modell minden verziója;
   - GS2107-WTBD-N modell minden verziója.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-112-02

Sérülékenységek Horner Automation Cscape szoftverekben

Sharon Brizinov, a Claroty munkatársa két sérülékenységet talált a Horner Automation Cscape nevű, vezérlő rendszerek fejlesztésére használt szoftverének minden, 9.90 SP4-nél korábbi verziójában.

A gyártó a hibákat a Cscape legújabb 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-21-112-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.

GéPé kolléga feszült figyelemmel kíséri az USA-ban az előző (Trump-) adminisztráció által hozott, energetikai vészhelyzetről szóló elnöki rendelet sorsát, a héten történt fejleményeket az alábbiakban foglalja össze:

Előző posztjaimban (itt és itt) érintettem a 2021. május 1-én az USA átviteli hálózatának biztonságáról kiadott elnöki rendeletet (E.O. 13920, Executive Order on Securing the United States Bulk-Power System, a továbbiakban: EO), amely energetikai vészhelyzetet hirdetett ki. Az EO-ban foglaltak szerint 90 nappal később ki kellett volna adni a végrehajtás részleteit is. Erre nem került sor. Végül nagy késéssel a DOE (Department of Energy) csak egy a kritikus védelmi létesítményekbe történő, egyes kínai eredetű villamos berendezések beépítésére vonatkozó tilalmi rendelkezést adott ki. Idén január 20-án Biden elnök első rendelkezései egyikeként az EO 90 napos felfüggesztés mellett döntött. Annak leteltével, április 20-án a DOE ismét hatályba helyezte az EO-t, egyben meghatározta a következő 100 nap teendőit. Ennek részletei még nem ismertek, mindössze csak annyi, hogy a tavaly nyári RFI (RFI: Request for Information) után újabb RFI került kiadásra (45 napos válaszadási határidővel).

Felmerülhet a kérdés, hogy ennek a kacskaringós történetnek mi köze van az ICS-ek – azon belül a villamosenergetikai ICS-ek – kiberbiztonságához?!

Nos, egyrészt „csak” annyi, hogy az EO (és a tilalmi rendelkezés) az új beszerzésű (sőt, már jelenleg is üzemelő) külföldi eredetű, vagy érdekeltségű kritikus villamos berendezések (pl. transzformátorok, mérőváltók, védelmi és irányítástechnikai berendezések) üzemeltetése és létesítése kapcsán fogalmaz meg kemény teendőket és korlátozásokat. Mindezt az USA villamosenergia rendszerét e berendezések ellátási lánca révén fenyegető kiberveszélyek miatt!

Főleg Kína nyomulása kapcsán az USA mostanában különösen kényes az ellátási láncát érő fenyegetésekre. Idén február 24-én került kiadásra az USA ellátási láncaira vonatkozó elnöki rendelet (E.O. 14017, America's Supply Chains), amely 100 napos határidővel előírta az ellátási lánc kockázatok felülvizsgálatát, sok egyéb mellett pl. a nagyteljesítményű akkumulátorok vonatkozásában (amelyek különös fontosságúak a kritikus infrastruktúrák ICS/SCADA-i megbízható tápellátása szempontjából). Ezt a felülvizsgálatot 1 éves határidővel az energetikai szektor egésze szempontjából is el kell végezni.

Másrészt időközben robbant ki az ICS/OT rendszerekre is sokkoló tanulságokkal szolgáló SolarWinds/Orion botrány, melynek kapcsán kiderült az USA kibervédelmének – és ennek részeként az ICS-ek kibervédelmének – vaksága, mondhatni csődje.

Harmadrészt az USA továbbra is jelentős kockázatnak tekinti a kritikus infrastruktúráiba egyre nagyobb számban beépített és beépítésre kerülő kínai eredetű berendezéseket. Mint az RFI fogalmaz: „A kínai eredetű kulcsfontosságú villamos berendezések alapvető fenyegetést jelentenek, mivel a kínai törvények lehetőséget biztosítanak Kína számára, hogy kihasználja az USA kritikus infrastruktúráiban használt – Kínában gyártott vagy szállított berendezések – sebezhetőségeit.”

Az ismételt hatályba helyező rendelkezés tartalma és gyakorlati következményei több kérdést is felvetnek. Pl.

• Mitől lehetne most éppen 100 nap alatt kezelni egy olyan – sőt azóta „még olyanabb” (lásd SolarWinds/Orion) – helyzetet, amelyet egyszer már 90 nap alatt nem sikerült?!

• A „stabil politikai környezet megteremtése” elégséges indok-e az elmúlt időszak egyetlen érdemi (és indokolt) fejleménye – a kritikus védelmi létesítményekre vonatkozó decemberi tilalmi rendelkezés – visszavonására?!

• Az érintett villamosenergetikai cégek miként tudnak megfelelni annak az elvárásnak, hogy a most kezdődött 100 napban az EO előírásai szellemében tevékenykedjenek, ha a végrehajtás részletei jó esetben csak a 100 nap leteltével lesznek megismerhetők?!

• Hogyan kerülnek finanszírozásra az EO-ban foglaltak végrehajtásának várhatóan horribilis költségei?!

Tehát továbbra is izgalmas hónapoknak nézünk elébe.

És egy pillanatig ne gondoljuk, hogy mindez tőlünk messze, a távolban történik, melyhez nekünk itt Magyarországon semmi közünk. A mai globalizált ellátási láncokat érő fenyegetések minket is érnek! Azaz a kritikus infrastruktúrák – azon belül hangsúllyal a villamosenergia-rendszer – kiberbiztonsága hazai illetékeseinek nagyon is érdemes elgondolkodniuk azon, hogy vajon az USA miért is nyomja ennyire a csengőt!?

Siemens LOGO! Soft Comfort sérülékenységek

A Siemens publikációja szerint Mashav Sapir, a Claroty munkatársa két sérülékenységet talált, amik a LOGO! Soft Comfort nevű termékük minden verzióját érintik.

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

Sérülékenységek Siemens SINEMA Remote Connect Server-ekben

A Siemens két sérülékenységről közölt információkat a DHS CISA-val, amiket a SINEMA Remote Connect Server v3.0-nál korábbi verzióiban találtak.

A gyártó a hibákkal kapcsolatban a SINEMA Remote Connect Server v3.0 verziójára történő frissítést javasolja. A sérülékenységekről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Siemens SCALANCE X200 webszerver sérülékenységek

A Siemens két, puffer-túlcsordulás sérülékenységet jelentett a DHS CISA-nak, amik a SCALANCE X200-as termékcsalád alábbi tagjait érintik:

- SCALANCE X200-4P IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE X201-3P IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE X201-3P IRT PRO minden, 5.5.1-nél korábbi verziója;
- SCALANCE X202-2 IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE X202-2P IRT minden, 5.5.1-nél korábbi verziója (beleértve a SIPLUS NET változatokat is);
- SCALANCE X202-2P IRT PRO minden, 5.5.1-nél korábbi verziója;
- SCALANCE X204 IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE X204 IRT PRO minden, 5.5.1-nél korábbi verziója;
- SCALANCE X204-2 minden verziója (beleértve a SIPLUS NET változatokat is);
- SCALANCE X204-2FM minden verziója;
- SCALANCE X204-2LD minden verziója (beleértve a SIPLUS NET változatokat is);
- SCALANCE X204-2LD TS minden verziója;
- SCALANCE X204-2TS minden verziója;
- SCALANCE X206-1 minden verziója;
- SCALANCE X206-1LD minden verziója;
- SCALANCE X208 minden verziója (beleértve a SIPLUS NET változatokat is);
- SCALANCE X208PRO minden verziója;
- SCALANCE X212-2 minden verziója (beleértve a SIPLUS NET változatokat is);
- SCALANCE X212-2LD minden verziója;
- SCALANCE X216 minden verziója;
- SCALANCE X224 minden verziója;
- SCALANCE XF201-3P IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE XF202-2P IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE XF204 minden verziója;
- SCALANCE XF204 IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE XF204-2 minden verziója (beleértve a SIPLUS NET változatokat is);
- SCALANCE XF204-2BA IRT minden, 5.5.1-nél korábbi verziója;
- SCALANCE XF206-1 minden verziója;
- SCALANCE XF208 minden verziója.

A gyártó az alábbi termékek esetén az 5.5.1-es verzióban javította a hibákat:

- SCALANCE X200-4P IRT;
- SCALANCE X201-3P IRT;
- SCALANCE X201-3P IRT PRO;
- SCALANCE X202-2 IRT;
- SCALANCE X202-2P IRT (beleértve a SIPLUS NET változatokat is);
- SCALANCE X202-2P IRT PRO;
- SCALANCE X204 IRT;
- SCALANCE X204 IRT PRO;
- SCALANCE XF201-3P IRT;
- SCALANCE XF202-2P IRT;
- SCALANCE XF204 IRT;
- SCALANCE XF204-2BA IRT.

A sérülékenységekkel kapcsolatos további információk a Siemens ProductCERT és az ICS-CERT weboldalain érhetőek el.

Sérülékenységek Siemens Solid Edge szoftvereszközökben

Francis Provencher és rgod, a ZDI-vel együttműködve 5 sérülékenységet találtak a Siemens Solid Edge szoftvereinek alábbi verzióiban:

- Solid Edge SE2020 MP13-as és minden korábbi verziója;
- Solid Edge SE2021 minden, SE2021MP4-nél korábbi verziója.

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

Siemens/PKE Control Center Server sérülékenységek

Raphaël Rigo, az Airbus Security Lab munkatársa egy tucatnyi sérülékenységet talált a Siemens és a PKE által fejlesztett, Control Center Server nevű videó menedzsment megoldás alábbi verzióiban:

- A v1.5.0-nál korábbi verziókat minden sérülékenység érinti;
- A v1.5.0 és újabb verziókat csak a CVE-2019-18340 azonosítóval ellátott sérülékenység érinti.

A gyártók a hibák nagy részét a v1.5.0 és újabb verziókban javították. A sérülékenységek részleteit a Siemens ProductCERT és az ICS-CERT bejelentései tartalmazzák.

Siemens Nucleus IPv6 sérülékenységek

A Siemens két sérülékenységet azonosított, amik a Nucleus termékcsalád alábbi tagjaiban használt IPv6 stack-jeit érintik:

- Nucleus 4 minden, v4.1.0-nál korábbi verziója;
- Nucleus NET minden verziója;
- Nucleus ReadyStart minden verziója;
- Nucleus Source Code minden verziója, ami az érintett IPv6 stack-et használja;
- VSTAR minden verziója, ami az érintett IPv6 stack-et használja.

A gyártó az érintett termékekhez készült javításokat már elérhetővé tette. A sérülékenységekkel kapcsolatos bővebb információk a Siemens ProductCERT és az ICS-CERT weboldalain találhatóak meg.

Sérülékenységek Siemens Nucleus DNS modulokban

Daniel dos Santos, a Forescout Technologies munkatársa összesen három sérülékenységet talált a Siemens Nucleus termékcsalád alábbi tagjaiban használt DNS modulokban:

- Nucleus NET minden verziója (a háromból két sérülékenység, a CVE-2020-15795 és a CVE-2020-27009, a v5.2-nél korábbi verziókat érintik);
- Nucleus RTOS érintett DNS modulokat használó verziói;
- Nucleus Source Code érintett DNS modulokat használó verziói;
- VSTAR érintett DNS modulokat használó verziói;
- Nucleus ReadyStart minden, V2013.08-nál korábbi verziója (csak a CVE-2021-27393 érinti).

A gyártó a hibákat javító újabb verziókat már elérhetővé tette. A sérülékenységekről további információk a Siemens ProductCERT és az ICS-CERT publikációiban érhetőek el.

Sérülékenység Siemens Siveillance Video Open Network Bridge rendszerekben

A Siemens egy kritikus sérülékenységről hozott nyilvánosságra információkat, ami a Siveillance Video Open Network Bridge rendszereik alábbi verzióit érinti:

Siveillance Video Open Network Bridge 2020 R3;
Siveillance Video Open Network Bridge 2020 R2;
Siveillance Video Open Network Bridge 2020 R1;
Siveillance Video Open Network Bridge 2019 R3;
Siveillance Video Open Network Bridge 2019 R2;
Siveillance Video Open Network Bridge 2019 R1;
Siveillance Video Open Network Bridge 2018 R3;
Siveillance Video Open Network Bridge 2018 R2.

A gyártó a hibát javító patch-eket már elérhetővé tette. A sérülékenység részleteit a Siemens ProductCERT bejelentésében lehet elolvasni.

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

A Siemens ProductCERT által közzé tett információk alapján az alábbi termékeknél használt SmartClient Installation technológia (ClickOnce) által használt lejárt tanúsítvány jelentős kockázatokat hordoz az érzékeny ügyféladatokra nézve. Az érintett rendszerek:

Opcenter Quality minden, V12.2-nél korábbi verziója;
QMS Automotive, minden, V12.30-nál korábbi verziója.

A gyártó az érintett tanúsítványt visszavonási listára tette és általános kockázatcsökkentő intézkedések bevezetésére vonatkozó javasolatokat is tett. A sérülékenységgel kapcsolatos részleteket a Siemens ProductCERT weboldalán lehet megtalálni.

Sérülékenységek Siemens TIM 4R-IE eszközökben

A Siemens ProductCERT publikációja szerint 14 régebbi NTP-sérülékenység érinti a gyártó alábbi eszközeit (különböző egyéb termékeiben használt kommunikációs moduljait) is:

- TIM 4R-IE minden verziója (beleértve a SIPLUS NET változatokat is);
- TIM 4R-IE DNP3 minden verziója (beleértve a SIPLUS NET változatokat is).

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések alkalmazását és újabb termékekre történő migrációt javasol. A sérülékenységekről további részleteket a Siemens ProductCERT publikációjában lehet találni.

Siemens Tecnomatix RobotExpert sérülékenység

A ZDI-vel és a DHS CISA-val együttműködve a Siemens ProductCERT egy sérülékenységről hozott nyilvánosságra információkat, ami a Tecnomatix RobotExpert V16.1-nél korábbi verzióit érinti.

A gyártó a hibát a V16.1-es és újabb verziókban javította. A sérülékenységről részleteket a Siemens ProductCERT bejelentése tartalmaz.

Sérülékenység Siemens Mendix alkalmazásokban

A Siemens egy sérülékenységet azonosított a FlowFabric BV segítségével, ami az alábbi termékeiket érinti:

- Mendix 7 minden, V7.23.19-nél korábbi verziója;
- Mendix 8 minden, V8.17.0-nál korábbi verziója;
- Mendix 8 (V8.12) minden, V8.12.5-nél korábbi verziója;
- Mendix 8 (V8.6) minden, V8.6.9-nél korábbi verziója;
- Mendix 9 minden, V9.0.5-nél korábbi verziója.

A hibát javító újabb verziókat a gyártó már elérhetővé tette ügyfelei számára. A sérülékenységgel kapcsolatos további információk a Siemens ProductCERT weboldalán érhetőek el.

Siemens SIMOTIC CONNECT 400 sérülékenységek

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

- SIMOTICS CONNECT 400 minden, V0.5.0.0 és korábbi verziója;
- SIMOTICS CONNECT 400 V0.5.0.0 és újabb verzióit csak a CVE-2021-25677 sérülékenység érinti.

A gyártó a hibák nagy részét a V0.5.0.0 verzióban javította, továbbá kockázatcsökkentő intézkedések bevezetésére vonatkozó javasolatokat tett. A sérülékenységekkel kapcsolatosan bővebb információk a Siemens ProductCERT publikációjában érhetőek el.

Sérülékenység JTEKT rendszerekben

Younes Dragoni, a Nozomi Networks munkatársa egy sérülékenységet talált a JTEKT alábbi berendezéseiben:

TOYOPUC-PC10 sorozat:
- PC10G-CPU TCC-6353 minden verziója;
- PC10GE TCC-6464 minden verziója;
- PC10P TCC-6372 minden verziója;
- PC10P-DP TCC-6726 minden verziója;
- PC10P-DP-IO TCC-6752 minden verziója;
- PC10B-P TCC-6373 minden verziója;
- PC10B TCC-1021 minden verziója;
- PC10B-E/C TCU-6521 minden verziója;
- PC10E TCC-4737 minden verziója;

TOYOPUC-Plus sorozat:
- Plus CPU TCC-6740 minden verziója;
- Plus EX TCU-6741 minden verziója;
- Plus EX2 TCU-6858 minden verziója;
- Plus EFR TCU-6743 minden verziója;
- Plus EFR2 TCU-6859 minden verziója;
- Plus 2P-EFR TCU-6929 minden verziója;
- Plus BUS-EX TCU-6900 minden verziója;

TOYOPUC-PC3J/PC2J sorozat:
- FL/ET-T-V2H THU-6289 minden verziója;
- 2PORT-EFR THU-6404 minden verziója.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenység részleteit az ICS-CERT bejelentése tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-103-03

Advantech WebAccess/SCADA rendszerek sérülékenysége

Chizuru Toyama, a TrendMicro TXOne IoT/ICS Security Research Labs munkatársa egy sérülékenységet azonosított az Advantech WebAccess/SCADA 9.0.1-es és korábbi verzióiban.

A gyártó a hibát a 9.0.3-as és újabb verzióiban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-103-02

Sérülékenység az EIPStackGroup OpENer Ethernet/IP protokoll-implementációjában

Tal Keren és Sharon Brizinov, a Claroty munkatársai négy sérülékenységet jelentettek a DHS CISA-nak, amiket a OpENer EtherNet/IP 2021. február 10-e előtti, https://github.com/EIPStackGroup/OpENer/ hivatkozáson elérhető commit-jaiban és verzióiban találtak.

Az OpENer projekt fejlesztői a hibákkal kapcsolatban a legújabb elérhető verzió használatát javasolják. A sérülékenységek részleteiről az ICS-CERT publikációjában lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-105-02

Schneider Electric C-Bus Toolkit sérülékenységek

rgod, a ZDI-vel együttműködve öt sérülékenységről közölt információkat a DHS CISA-val, amiket a Schneider Electric C-Bus Toolkit v1.15.7-es és korábbi verzióiban talált.

A gyártó a hibákat a C-Bus Toolkit legújabb verziójában javította. A sérülékenységekkel kapcsolatos bővebb információk a Schneider Electric és az ICS-CERT weboldalain érhetőek el.

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 USA Igazságügyi Minisztériuma (Department of Justice, DoJ) által publikált információk szerint egy 22 éves, Kansas állambeli férfit fognak szövetségi bíróság előtt perbe fogni a szintén Kansas állambeli Ellsworth megyei vízmű ICS rendszereihez történő jogosulatlan hozzáférés miatt. A Környezetvédelmi Ügynökség (Environmental Protection Agency, EPA) bűnügyi nyomozó részlegét vezető ügynök szerint az illegális hozzáféréssel és a vízmű rendszereiben végrehajtott módosításokkal a vádlott az ivóvíz-hálózatot és azon keresztül a közösség biztonságát veszélyeztette. A nyilvánosságra hozott információk nem tartalmaznak azzal kapcsolatban részleteket, hogy az illegális módosítások sikeresek voltak-e illetve hogy hogyan észlelték ezeket a változtatásokat, viszont a vádlott jelenleg 25 évig terjedő (szövetségi börtönben letöltendő) szabadságvesztés és 500.000 dollárig terjedő bírsággal néz szembe.

Nem ez volt az első és nem is az utolsó kiberbiztonsági incidens az amerikai viziközmű cégek életében, elég csak az floridai Oldsmar vízművének rendszerében történt incidensre gondolni, de az izraeli vízmű cégek elleni támadás-sorozat sem volt olyan régen. Ráadásul a DoE 2016-ban kiadott információi szerint már 2015-ben is legalább 25 kiberbiztonsági incidenst regisztráltak különböző (kisméretű) amerikai viziközmű szolgáltatók rendszereiben, tehát az utóbbi idők eseményei korántsem előzmény nélküliek.

Az egyre nyilvánvalóbb, hogy az USA-ban immár a legmagasabb (szövetségi) szinten és több hatalmi ágban (végrehajtói - a blogon többször hivatkozott elnöki rendeletekben is leírtak szerint - és bírói - vagy legalább is ügyészi szinten - hatalmi ágakban) is egyre fontosabbnak értékelik a nemzeti kritikus infrastruktúrák kiberbiztonságának kérdését. Vajon itthon mikor indulunk el hasonló úton? Mert az nem lehet kérdés, hogy (ebben a témában mindenképp) követnünk kéne az USA-t, a kérdés inkább csak az, mi kell ahhoz, hogy ezt a magyar döntéshozók is kellően fontosnak érezzék?

Bár Magyarországon a viziközmű cégek egészen más méretűek, ezáltal pedig (feltételezéseim szerint) más problémákkal, kihívásokkal szembesülnek, a kisméretű közmű cégek problémái szerintem itthon is jelen vannak, csak éppen másik szektort kell vizsgálni. Az elmúlt években gombamód szaporodó és az állam által is támogatott kis- és háztáji naperőművek hasonló kiberbiztonsági kockázatokat hordozhatnak. Egyenként ezek a naperőművek nem jelentenek érezhető beépített teljesítmény az országos villamosenergia-rendszer szempontjából, de figyelembe véve, hogy milyen sokat ezek közül alig néhány gyártó azonos technológiára épülő illetve sok esetben egy sorozatba tartozó eszközeiből építenek fel és ezek publikus hálózatokon kommunikálnak az adott terület áramszolgáltatójának rendszereivel, már látható, hogy adott esetben már komolyabb kockázatok is megjelenhetnek.

Vasárnap számos híroldal (NY Times, BBC, CNN, Al Jazira, The Guardian, itthon többek között a Telex és a 444.hu is) és több IT biztonsági forrás (pl. SecurityWeek) hozta a hírt, hogy komoly áramkimaradás volt a Natanz-i urándúsító létesítményben és egyes források szerint számos, az urándúsítási folyamatban fontos eszköz meg is hibásodott az áramkimaradás következtében. Némely források az áramkimaradás hátterében kibertámadást, mások robbanásokat emlegetnek.

Irán szinte azonnal erős kijelentéseket tett (nukleáris terrorizmust emlegettek és a Nemzetközi Atomenergia Ügynökség, az IAEA közbelépését sürgette). Bár még szinte semmilyen konkrétumot nem lehet tudni és éppen ezért én is tartózkodnék a konkrétabb megállapításoktól, az mindenképp látszik, hogy egy adott ország kritikus infrastruktúrája egyre nagyon mértékben ki van téve a kibertérből érkező támadásoknak, különösen, ha az adott országnak van egy vagy több elszánt ellenlábasa.

Egyes források szerint az incidens ismét jelentősen (egy helyen 9 hónapot olvastam) visszaveti az iráni nukleáris programot a fejlődésben.

Ha az iráni illetékesek nukleáris terrorizmusra vonatkozó kijelentéseit vizsgáljuk, akár még arra a megállapításra is juthatunk, hogy akár igazuk is lehet, hiszen a civil kritikus infrastruktúrák elleni támadásokat simán lehet terrorcselekményként kezelni, azonban az iráni atomprogrammal kapcsolatban annak elejétől kezdve komoly kétségek vannak szerte a világban a békés, civil voltát illetően.

Ezt a posztot igyekszem majd frissíteni, amikor a konkrét esetről további, megerősített információk látnak napvilágot.

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

Sharon Brizinov és Amir Preminger, a Claroty munkatársai 9 sérülékenységet fedeztek fel a Rockwell Automation FactoryTalk AssetCentre nevű megoldásának v10.00 és korábbi verzióiban.

A gyártó a hibákat az AssetCentre v11-es és újabb verzióiban javította. A sérülékenységek részleteirő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-091-01

Sérülékenység Hitachi ABB Power Grids termékekben

Markus Mahrla a GAI NetConsult GmbH és Lars Lengersdorf, az Amprion GmbH munkatársa egy sérülékenységet azonosítottak a Hitachi ABB Power Grids alábbi termékeiben:

- Relion 670 sorozat 1.1-es verzió minden revíziója;
- Relion 670 sorozat 1.2.3-as verzió minden revíziója;
- Relion 670 sorozat 2.0-es verzió minden revíziója;
- Relion 670/650 sorozatok 2.1-es verzió minden revíziója;
- Relion 670/650 sorozatok 2.2.0-es verzió minden revíziója;
- Relion 670/650/SAM600-IO sorozatok 2.2.1-es verzió minden revíziója;
- Relion 670 sorozatok 2.2.2-es verzió minden revíziója;
- Relion 670 sorozatok 2.2.3-as verzió minden revíziója;
- Relion 650 sorozatok 1.1-es verzió minden revíziója;
- Relion 650 sorozatok 1.2-es verzió minden revíziója;
- Relion 650 sorozatok 1.3-as verzió minden revíziója;
- RTU500 CMU 7.x firmware-verziók;
- RTU500 CMU 8.x firmware-verziók;
- RTU500 CMU 9.x firmware-verziók;
- RTU500 CMU 10.x firmware-verziók;
- RTU500 CMU 11.x firmware-verziók;
- RTU500 CMU 12.x firmware-verziók;
- REB500 7.3;
- REB500 7.4;
- REB500 7.5;
- REB500 7.6;
- REB500 8.2;
- REB500 8.3;
- TEGO1 FOX615 service unit-jai R1D02-es és korábbi ESW-vel futó példányai;
- MSM minden, 2.1.0-nál régebbi verziója;
- GMS600 1.3.0 és korábbi verziói;
- PWC600 Version 1.0;
- PWC600 Version 1.1.

A hibát a gyártó az érintett termékek újabb verzióiban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-096-01

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

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 FATEK Automation WinProladder PLC-inek 3.30-as és korábbi verzióit érinti.

A gyártó jelenleg is dolgozik a hibát javító újabb verzión. A sérülékenységgel kapcsolatosan bővebb információkat az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-098-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.