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)?

Siemens SIMATIC HMI-ok sérülékenysége

A ZDI és DHS CISA egy sérülékenységről közölt információkat a Siemens-szel, ami a gyártó alábbi termékeit érinti:

- SIMATIC HMI Comfort panelek (ide értve a SIPLUS variánsokat is) minden, V16 Update 3a-nál korábbi változata;
- SIMATIC HMI KTP Mobile panelek (ide értve a SIPLUS variánsokat is) minden, V16 Update 3a-nál korábbi változata.

A gyártó a hibát az érintett termékek V16 Update 3a és újabb verzióiban javította. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT publikációja tartalmaz.

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

Kimiya, Tran Van Khang, a VinCSS munkatársa és egy névtelenségbe burkolózó biztonsági kutató 5 sérülékenységet fedeztek fel a Fuji Electric alábbi rendszereiben:

- Tellus Lite V-Simulator v4.0.10.0-nál korábbi verziói;
- V-Server Lite v4.0.10.0-nál korábbi verziói.

A gyártó a hibákat a v4.0.10.0 verzióban javította. 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-026-01

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

A Tenable kutató 3 sérülékenységet találtak a Rockwell Automation alábbi megoldásaiban:

- FactoryTalk Linx szoftver 6.20 és korábbi verziói;
- FactoryTalkServices Platform 6.20 és korábbi verziói.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységek részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-21-028-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.

Már több, mint egy hónapja, hogy a SolarWinds incidens valódi súlyával tisztában vagyunk. Sajnos ennyi idő a jelek szerint nem volt elég ahhoz, hogy a hazai kritikus infrastruktúra cégei és az illetékes állami szervek koordinált intézkedésekről kezdjenek egyeztetni, amik lehetőséget adnának a jövőbeli, hasonló jellegű és méretű fenyegetést jelentő, részben a beszállítói lánc, részben pedig a hálózatmenedzsment és monitoring megoldások elleni támadások esetére a védekezéshez.

Első lépésként minden szervezetnek, de szerintem különösképpen a kritikus infrastruktúrákhoz tartozó szervezeteknek és (természetesen) az államigazgatásban érintett szervezetek esetén el kéne végezni a beszállítók jelentette kockázatok elemzését. Ehhez meglehetősen jó iránymutatást ad az NIST Cyber Supply Chain Risk Management című publikációja. Emellett egyes vélemények szerint három területen lehet viszonylag gyorsan érezhető hatású intézkedésekkel csökkenteni a hasonló támadások kockázatait:

1. A szoftver-beszállítói lánc irányítása - A legtöbb szervezetnek nincs megfelelő rálátása arra, hogy a neki egyedi szoftvereket fejlesztő vagy dobozos szoftver-termékeket értékesítő/üzembe helyező vállalatok pontosan mit is adnak át nekik, de még ha a képességnek birtokában is vannak (1000 ügyfélből talán egy ilyen, ha lehet), a fejlesztők és integrátorok általában nem érdekeltek abban, hogy az ügyfeleknek minél transzparensebbé tegyék a saját folyamataikat. Pedig szükség lenne ahhoz, hogy a beszállítói lánc elleni támadásokat meg lehessen előzni vagy legalább csökkenteni lehessen a hatásaikat. Erre két esély kínálkozhat, egyrészt az ügyfélnek célszerű minden olyan befolyásolási eszközt megragadni a tárgyalások során, amivel rá tudja venni a szállítót az általa fontosnak tartott átláthatósági követelmények betartására, másrészt pedig az iparági jó gyakorlatok és (szerintem különösképpen a kritikus infrastruktúrák közé sorolt hazai szervezetek esetén) a 41/2015. BM rendeletben is előírt követelmény (a fejlesztési folyamat teljes körű és átlátható dokumentálása) alapján lehet megteremteni ezt a fajta transzparenciát.

2. Viselkedés-elemzésen alapuló fenyegetés-detektálás

Ha jól belegondolunk abban, hogy a támadók általában nem mozognak otthonosan a megtámadott rendszerekben, megérthetjük, miért lehet jó eszköz a viselkedés-elemzés a különböző támadások észlelésében. Egyes hírek szerint a SolarWinds-incidens első felfedezéséhez (a FireEye nyomozását kiváltó eseményhez) egy szokatlan távoli felhasználói bejelentkezés vezetett, ami egy ismeretlen eszközről és gyanús IP címről történt.

3. Adatletöltés megelőzése és észlelése

Ha minden más biztonsági intézkedésünk elbukott, képesnek kell lennünk gyorsan azonosítani, amikor a szervezet értékes adatait éppen jogosulatlanul akarják a cég rendszerein kívülre juttatni. Ebben a témában (szigorúan műszaki szempontból) sok szervezet jól teljesít (a SolarWinds incidens kapcsán számos cégnél találtak olyan logokat, amik az adatok lopására utaló jeleket tartalmaztak), éppen csak a riasztások kezelése volt csapnivaló (gyakorlatilag nem foglalkoztak ezekkel). Ebből is látszik annak a régi, IT biztonsági műveleti körökben ismert megállapításnak az igazsága, ami szerint a különböző gyártók különböző csoda-megoldásai önmagukban nem fogják megvédeni a szervezeteket a biztonsági eseményektől és incidensektől, a jó megoldások mellé nagyon jó és tapasztalt biztonsági elemzőkre és jól megtervezett, jól begyakorolt és rendszeresen tesztelt (valamint szükség esetén finomhangolt) eljárásokra is legalább ugyanekkora (vagy inkább még nagyobb) szükség van.

Azt egyelőre még nem lehet tudni, hogy a SolarWinds incidens lesz-e ugyanolyan mérföldkő a supply-chain támadások terén, mint amilyen a Stuxnet az ICS kiberbiztonság témájában, de én személy szerint arra számítok, hogy a közeli jövőben látni fogunk még nagyszabású, a beszállító láncot is érintő kiberbiztonsági incidenseket.

Dnsmasq sérülékenységek

Moshe Kol és Shlomi Oberman, a JSOF munkatársai 7 sérülékenységet találtak a Simon Kelley által fejlesztett Dnsmasq DNS és DHCP szervereinek 2.8.2-es és korábbi verzióiban.

A Dnsmasq fejlesztői a 2.83-as vagy újabb verzióra történő frissítést és kockázatcsökkentő intézkedések alkalmazását javasolják. A sérülékenységekről bővebb információkat az ICS-CERT publikációjában lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-019-01

Dnsmasq sérülékenységek Siemens SCALANCE és RUGGEDCOM eszközökben

A Siemens bejelentése szerint a JSOF munkatársai által felfedezett Dnsmasq sérülékenységek közül három érinti az alábbi Siemens termékeket is:

- RUGGEDCOM RM1224 minden verziója;
- SCALANCE M-800 minden verziója;
- SCALANCE S615 minden verziója;
- SCALANCE SC-600 minden verziója;
- SCALANCE W1750D minden verziója;

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységek részleteit a Siemens ProductCERT bejelentésében lehet megtalálni.

Reolink eszközök sérülékenységei

A Nozomi Networks két sérülékenységet talált a Reolink alábbi, P2P kommunikációt használó kameráiban:

- RLC-4XX sorozatú eszközök;
- RLC-5XX sorozatú eszközök;
- RLN-X10 sorozatú eszközök.

A gyártó jelenleg is egyeztet a DHS CISA-val a sérülékenységekkel kapcsolatos intézkedésekről. A sérülékenységekkel kapcsolatos bővebb információkat az ICS-CERT weboldalán lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-019-02

Sérülékenység Philips orvostechnikai rendszerekben

A Philips egy sérülékenységről közölt információkat a DHS CISA-val, ami az alábbi termékeiket érinti:

- Interventional Workspot (1.3.2, 1.4.0, 1.4.1, 1.4.3 és 1.4.5-ös kiadások);
- Coronary Tools/Dynamic Coronary Roadmap/Stentboost Live (1.0 kiadás);
- ViewForum (6.3V1L10 kiadás).

A hibát javító patch-et a Philips már elérhetővé tette. A sérülékenység részleteivel kapcsolatban az ICS-CERT publikációját érdemes megnézni: https://us-cert.cisa.gov/ics/advisories/icsma-21-019-01

Sérülékenység M&M Software termékekben

Az Emerson munkatársai egy sérülékenységet találtak a WAGO Kontakttechnik leányvállalataként működő M&M Software GmbH alábbi termékeiben:

- fdtCONTAINER komponensek
   - 3.5.0-tól 3.5.20304.x-ig terjedő verziói;
   - 3.6.0-tól 3.6.20304.x-ig terjedő verziói;
   - 3.5-nél régebbi verziók;
- fdtCONTAINER alkalmazások
   - 4.5.0-tól 4.5.20304.x-ig terjedő verziói;
   - 4.6.0-tól 4.6.20304.x-ig terjedő verziói;
   - 4.5-nél régebbi verziók;
- dtmINSPECTOR 3 (az FDT 1.2.x-en alapuló verzió).

A gyártó a hibával kapcsolatban a legújabb verziókra történő frissítést javasolja. 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-021-05

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

A kínai Qi An Xin Group Inc. Industrial Control Security laborja egy sérülékenységet talált a Mitsubishi Electric alábbik, robotvezérlő berendezéseiben:

- MELFA FR sorozat;
- MELFA CR sorozat;
- MELFA ASSISTA.

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

Sérülékenységek Matrikon rendszerekben

Uri Katz, a Claroty munkatársa négy sérülékenységet talált a Honeywell leányvállalat Matrikon OPC UA Tunneller termékének 6.3.0.8233-asnál korábbi verzióiban.

A gyártó a hibákat a 6.3.0.8233-as verziójában 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-021-03

Sérülékenységek Delta Electronics TPEditor rendszerekben

kimiya, a ZDI-vel együttműködve két sérülékenységről közölt információkat a DHS CISA-val, amik a Delta Electronics TPEditor v1.98-as és korábbi verzióit érintik.

A gyártó a hibákat a v1.98.03-as és későbbi verziókban 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-021-02

Delta Electronics ISPSoft sérülékenység

Francis Provencher, a ZDI-vel közösen egy sérülékenységet jelentett a DHS CISA-nak a Delta Electronics ISPSoft v 3.12-es és korábbi verzióiban.

A hibát a gyártó a v.3.12.01-es verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjából lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-021-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.

A különböző, termelésirányítási rendszereket használó cégek elleni ransomware-támadások 2020-ban soha nem látott mértékben szaporodtak el. Csak itt a blogon XX ilyen támadásról írtam én is, a TrendMicro 2020 végén megjelent cikke szerint pedig a szektor elleni zsarolóvírus-támadások száma majdnem másfélszer akkora volt, mint a második helyen álló kormányzati szervek elleni ugyanilyen támadásoké.

A cikk szerzője, Ryan Flores írásában röviden összefoglalja a folyamatvezérlő rendszereket korábban ért ransomware-támadások hatásait és arra a következtetésre jut, hogy egy ransomware-nek nem szükségszerűen kell a folyamatirányító rendszer elemeit céloznia ahhoz, hogy a felügyeleti (Loss of View), vezérlési (Loss of Control) vagy termelési (Loss of Productivity) képessége sérüljön az adott szervezetnek.

A különböző termékek gyártását a szervezet fő céljának tekintő cégek esetén ráadásul más megvilágításba kerül a Maze ransomware által megkezdett dupla-zsarolási módszer is, amikor nem csak titkosítják a szervezet számára fontos állományokat, de egy részüket el is lopják és az ellopott adatok publikálásával is fenyegetnek a támadók. Míg sok folyamatirányító rendszert használó szervezet (pl. közüzemi szolgáltatók) esetén egy ilyen fenyegetés ugyan jelenthet problémákat, de a cég működését alapjaiban nem képesek ezzel veszélyeztetni, a különböző termékek (pl. szabadalmaztatott gyógyszerek) pontos összetevőinek arányai olyan értéket képviselhetnek, ami, ha nyilvánosságra kerül, adott esetben már a szervezet létezését is veszélyeztetheti.

A TrendMicro cikkében szó esik még a leggyakoribb, gyártásautomatizálási rendszereket alkalmazó cégeket támadó ransomware-ek sajátosságairól és néhány javaslatot is összegyűjtött a szerző a zsarolóvírusok elleni védelemben használható hálózatbiztonsági intézkedésekről.