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

A Schneider Electric bejelentése szerint Seok Min Lim és Johnny Pan, a Trustwave munkatársai egy sérülékenységet találtak az alábbi termékeikben:

- SoMachine Basic minden verziója;
- EcoStruxure Machine Expert – Basic minden verziója;
- Modicon M100 Logic Controller minden verziója;
- Modicon M200 Logic Controller minden verziója;
- Modicon M221 Logic Controller minden verziója.

A gyártó a hibát javító újabb szoftver és firmware-verziókat elérhetővé tette és további kockázatcsökkentő eljárásokra vonatkozó ajánlásokat is publikált. A sérülékenységgel kapcsolatban további információkat a Schneider Electric bejelentésében lehet találni.

Schneider Electric Modicon vezérlők, SoMachine és EcoStruxure rendszerek sérülékenységei

Rongkuan Ma, Shunkai Zhu és Peng Cheng, a Zhejiang-i Egyetemen működő 307Lab kutatói két sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- EcoStruxure Machine Expert minden verziója;
- SoMachine, SoMachine Motion minden verziója;
- Modicon M218 Logic Controller minden verziója;
- Modicon M241 Logic Controller minden verziója;
- Modicon M251 Logic Controller minden verziója;
- Modicon M258 Logic Controller minden verziója.

A sérülékenységekkel kapcsolatos gyártói ajánlások és a sérülékenységek további részletei a Schneider Electric publikációjában olvashatóak.

Sérülékenység Schneider Electric Viejo termékekben

Yongjun Liu, az nsfocus munkatársa egy sérülékenységet talált a Schneider Electric Viejo termékcsaládjának alábbi tagjaiban:

- Vijeo Designer Basic V1.1 HotFix 15 és korábbi verziói;
- Vijeo Designer V6.9 SP9 és korábbi verziói.

A gyártó a hibát a Vijeo Designer Basic version V1.1 HotFix 16-ban már javította a Vijeo Designer esetén pedig a következő service pack-ben ígéri. A sérülékenységről bővebb információk a Schneider Electric weboldalán érhetőek el.

Schneider Electric Triconex sérülékenységek

Egy meg nem nevezett biztonsági kutató 4 sérülékenységről közölt információkat a Schneider Electric-kel, amik az alábbi, régebbi kiadású Triconex rendszereket érintik:

Windows NT, Windows XP és Windows 7 operációs rendszereken futó TriStation 1131 v4.0.0-tól v4.9.0-ig tartó és v4.10.0 verziói;
Tricon v10.0, v10.1, v10.2.x és v10.3.x verziói;
Tricon Communications Module 4351, 4352, 4351A/B és 4352A/B modelljei.

A hibákat javító verziókat a gyártó publikációja szerint elérhetővé tették. A sérülékenységekről bővebb információkat a Schneider Electric bejelentésében lehet találni.

Rockwell Automation RSLinx Classic PLC-k sérülékenysége

Az Applied Risk munkatársai egy sérülékenységet találtak a Rockwell Automation RSLinx Classic PLC-k 4.11.00 és korábbi firmware-verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette ügyfelei számára. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-100-01

Triangle MicroWorks SCADA Data Gateway sérülékenységek

Steven Seeley és Chris Anastasio, az Incite Team tagjai, valamint Tobias Scharnowski, Niklas Breitfeld és Ali Abbasi három sérülékenységet találtak a Triangle MicroWorks SCADA Data Gateway nevű termékén 2.41.0213-tól 4.0.122-ig terjedő verzióiban.

A gyártó a hibát a 4.0.123-as verzióban javította. A sérülékenység részleteit az ICS-CERT publikációjában lehet elolvasni: https://www.us-cert.gov/ics/advisories/icsa-20-105-03

Sérülékenység Triangle MicroWorks DNP3 Outstation forráskódjában

Steven Seeley és Chris Anastasio, az Incite Team tagjai egy sérülékenységet találtak a Triangle MicroWorks DNP3 Outstation .NET protokoll komponenseiben és ANSI C könyvtáraiban, ami az említett termékek 3.16.00-tól 3.25.01-ig terjedő verzióit érinti.

A gyártó a hibával kapcsolatban a 3.26-os verzióra történő frissítést javasolja. A sérülékenységgel kapcsolatban bővebb információk az ICS-CERT weboldalán találhatóak: https://www.us-cert.gov/ics/advisories/icsa-20-105-02

Eaton HMISoft sérülékenységek

Natnael Samson a ZDI-vel együttműködve két sérülékenységről hozott nyilvánosságra információkat, amik az Eaton HMISoft VU3 nevű termékének 3.00.23-as és korábbi verzióit érintik (a HMiVU verziók nem érintettek).

A hibákkal kapcsolatban csak kockázatcsökkentő intézkedésekre vonatkozó ajánlások érhetőek el. A sérülékenységekről részleteket az ICS-CERT publikációjában lehet találni: https://www.us-cert.gov/ics/advisories/icsa-20-105-01

Sérülékenység Siemens TIM3V-IE és 4R-IE termékcsaládokba tartozó eszközökben

A Siemens egy sérülékenységről publikált részleteket, amik a SIMATIC S7-300-as és S7-400-as eszközeik TIM kommunikációs moduljai közül az alábbiakban található meg:

- TIM 3V-IE (a SIPLUS NET változatok is) minden, v2.8-nál régebbi verziója;
- TIM 3V-IE Advanced (a SIPLUS NET változatok is) minden, v2.8-nál régebbi verziója;
- TIM 3V-IE DNP3 (a SIPLUS NET változatok is) minden, v3.3-nál régebbi verziója;
- TIM 4R-IE (a SIPLUS NET változatok is) minden, v2.8-nál régebbi verziója;
- TIM 4R-IE DNP3 (a SIPLUS NET változatok is) minden, v3.3-nál régebbi verziója.

A gyártó a hibát az érintett termékekhez kiadott legújabb frissítésekben javította. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Siemens rendszerek sérülékenysége

A Siemens ProductCERT egy sérülékenységről közölt információkat, ami az alábbi termékeiket érinti:

- KTK ATE530S minden verziója;
- SIDOOR ATD430W minden verziója;
- SIDOOR ATE530S COATED minden verziója;
- SIDOOR ATE531S minden verziója;
- SIMATIC ET200SP IM155-6 MF HF minden verziója;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC (a SIPLUS változatok is) minden, 2.0-nál korábbi verziója;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (a SIPLUS változatok is) minden, 2.0-nál korábbi verziója;
- SIMATIC ET200MP IM155-5 PN HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC ET200SP IM155-6 PN HA (a SIPLUS változatok is) minden verziója;
- SIMATIC ET200SP IM155-6 PN HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC ET200SP IM155-6 PN/2 HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC ET200SP IM155-6 PN/3 HF (a SIPLUS változatok is) 4.2 és későbbi verziói;
- SIMATIC MICRO-DRIVE PDC minden verziója;
- SIMATIC PN/PN Coupler (a SIPLUS NET változatok is) 4.2 és későbbi verziói;
- SIMATIC S7-1500 CPU család (beleértve az ET200 CPU-kat és a SIPLUS változatokat is) minden, 2.0-nál korábbi verziója;
- SIMATIC S7-1500 Software Controller minden, 2.0-nál korábbi verziója;
- SIMATIC S7-300 CPU család (beleértve az ET200 CPU-kat és a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 PN/DP V7 és ez alatti CPU család (a SIPLUS változatok is) minden verziója;
- SIMATIC S7-410 CPU család (a SIPLUS változatok is) minden verziója;
- SIMATIC TDC CP51M1 minden verziója;
- SIMATIC TDC CPU555 minden verziója;
- SIMATIC WinAC RTX (F) 2010 minden verziója;
- SINAMICS S/G Control Unit w. PROFINET minden verziója.

A gyártó egyes érintett termékekhez már kiadta a hibát javító újabb verziókat. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT oldalain lehet olvasni.

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

A Siemens ProductCERT publikációja szerint egy eddig ismeretlen sérülékenységet azonosítottak a Siemens VxWorks-alapú SCALANCE és SIMATIC termékcsaládjainak alábbi tagjaiban:

- SCALANCE X-200 switch család (a SIPLUS NET változatok is) minden verziója;
- SCALANCE X-200IRT switch family (a SIPLUS NET változatok is) minden verziója;
- SCALANCE X-300 switch family (beleértve az X408 és a SIPLUS NET változatokat) minden verziója.
- SIMATIC CP 443-1 (a SIPLUS NET változatok is) minden verziója;
- SIMATIC CP 443-1 Advanced (a SIPLUS NET változatok is) minden verziója;
- SIMATIC RF180C minden verziója;
- SIMATIC RF182C minden verziója.

A gyártó mostanáig sem javítást, sem kockázatcsökkentő intézkedésekre vonatkozó javaslatokat nem adott ki a hibával kapcsolatosan. A sérülékenység részleteit a Siemens ProductCERT és az ICS-CERT publikációiban lehet megtalálni

Siemens ipari rendszerek sérülékenységei

A Siemens két sérülékenységről osztott meg információkat, amelyek számos, ipari környezetekben szánt megoldását érintik:

- IE/PB-Link v3 minden verziója;
- RUGGEDCOM RM1224 minden, 6.1-nél korábbi verziója;
- RUGGEDCOM ROX II minden, 2.13.3-nál korábbi verziója;
- SCALANCE M-800 család minden, 6.1-nél korábbi verziója;
- SCALANCE S615 minden, 6.1-nél korábbi verziója;
- SCALANCE SC-600 minden, 2.0-nál korábbi verziója;
- SCALANCE W1700 IEEE 802.11ac minden, 2.0-nál korábbi verziója;
- SCALANCE W700 IEEE 802.11a/b/g/n minden, 6.4-nél korábbi verziója;
- SIMATIC CP 1242-7 minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1243-1 (beleértve a SIPLUS NET változatokat is) minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1243-7 LTE EU minden, 3.2-nél korábbi verziója;
- SIMATIC CP 2243-7 LTE US minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1243-8 IRC minden, 3.2-nél korábbi verziója;
- SIMATIC CP 1542SP-1 minden, 2.1-nél korábbi verziója;
- SIMATIC CP 1542SP-1 IRC (beleértve a SIPLUS NET változatokat is) minden, 2.1-nél korábbi változata;
- SIMATIC CP 1543-1 (beleértve a SIPLUS NET változatokat is) minden, 2.2-nél korábbi változata;
- SIMATIC CP 1543SP-1 (beleértve a SIPLUS NET változatokat is) minden, 2.1-nél korábbi változata;
- SIMATIC RF185C minden verziója;
- SIMATIC RF186C minden verziója;
- SIMATIC RF186CI minden verziója;
- SIMATIC RF188C minden verziója;
- SIMATIC RF188CI minden verziója;
- SINEMA Remote Connect Server minden, 1.1 és 2.0.1 közötti verziója.

A gyártó a hibákat az érintett termékekhez kiadott legújabb verziókban javította. A sérülékenységekkel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenységek Siemens Climatix rendszerekben

Ezequiel Fernandez, a Dreamlab Technologies munkatársa két sérülékenységet jelentett a Siemens ProductCERT-nek, amik az alábbi Siemens rendszereket érintik:

- Climatix POL908 (BACnet/IP module) minden verziója;
- Climatix POL909 (AWM module) minden verziója.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről részleteket a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Siemens SIMATIC S7 V5 PN CPU-k sérülékenysége

A Siemens ProductCERT bejelentése szerint egy sérülékenységet taáltak a SIMATIC S7-400-as CPU-k alábbi változataiban:

- SIMATIC S7-400 CPU 414-3 PN/DP (6ES7414-3EM05-0AB0) minden verziója;
- SIMATIC S7-400 CPU 416-3 PN/DP (6ES7416-3ER05-0AB0, beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-400 CPU 416F-3 PN/DP (6ES7416-3FR05-0AB0) minden verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben a Siemens ProductCERT weboldalán lehet olvasni.

Sérülékenység SIMATIC S7-400 V6 PN CPU-kban

A Siemens ProductCERT az ICS-CERT-tel és a Kasperky Labs-nál dolgozó Artem Zinenko-val együttműködve egy sérülékenységről publikált információkat, ami az alábbi termékeit érinti:

- SIMATIC S7-400 CPU 412-2 PN (6ES7412-2EK06-0AB0, beleértve a SIPLUS változatokat is) minden, V6.0.3-nál korábbi változat;
- SIMATIC S7-400 CPU 414-3 PN/DP and CPU414F-3 PN/DP (6ES7414-3EM06-0AB0 és 6ES7414-3FM06-0AB0, beleértve a SIPLUS változatokat is) minden, V6.0.3-nál korábbi változat;
- SIMATIC S7-400 CPU 416-3 PN/DP és CPU 416F-3 PN (6ES7416-3ES06-0AB0 és 6ES7416-3FS06-0AB0, beleértve a SIPLUS változatokat is) minden, V6.0.3-nál korábbi változat.

A gyártó a hibát a legújabb verzióban javította. A sérülékenység részleteiről a Siemens ProductCERT bejelentéséből lehet tájékozódni.

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 ICS kiberbiztonság egyik legrégebbi akadályát a különböző ICS rendszerek és berendezések végtelenül behatárolt performancia-tartalékai jelentik. Itt nem csak arra kell gondolni, hogy nem lehet mindazokat a klienseket telepíteni egy ICS rendszer elemeire, amiket a nagyvállalati IT rendszerek esetén már régen megszoktunk (végpontvédelmi megoldás, DLP, eszközgazdálkodási rendszerek és sok egyéb kliens) és amiknek a száma ma már akár tucatnyi is lehet egy-egy irodai, jellemzően Windows-alapú operációs rendszert futtató operációs rendszeren, de időnként olyan extrém esetek is megtörténnek, amikor egy adott ICS berendezésben felfedezett sérülékenységet nem azért nem javított a gyártó, mert nem akarta, hanem mert egyszerűen nem volt kapacitása az eszköznek (nem volt elég code space) a patch telepítéséhez! Hasonló helyzetet én személyesen is megéltem már, amikor egy gyártó az elavult és a fejlesztő által már nem támogatott webszerver problémájára azt a választ adta, hogy érti, mire gondolunk, de az eszközben használt processzor nem képes újabb generációs, akár valamilyen lightweight webszervert futtatni, a CPU cseréje pedig egy erősebb modellre csak CPU architektúra-váltással oldható meg, ami a berendezés teljes újratervezését és újraépítését is jelentené.

A másik oldalon viszont lassan már megszokottá válnak az ICS rendszerek és az ipari szervezetek elleni kibertámadásokról szóló hírek és mind gyakrabban merülnek fel azok a javaslatok, hogy az ICS rendszerek elmeire és az ICS célberendezésekre is kerüljenek telepítésre a nagyvállalati IT-ban már megszokottakhoz hasonló biztonsági megoldások.

Az Ipar 4.0 és az IIoT térnyerésével a fenti kihívások mind jobban fogják követelni a különböző ipari szervezetek döntéshozóinak figyelmét. Az én véleményem szerint a gyártóknak (közösen az ICS rendszerek és berendezések felhasználóival) minél gyorsabban fel kell ismerniük, hogy az új rendszerek és berendezések tervezésénél már a különböző biztonsági funkciókat (patch-elés, végpontvédelmi megoldások, stb.) és azok performancia-igényét is bele kell tervezniük az eszközök teljesítmény-igényeibe. Előbb vagy utóbb (én nagyon remélem, hogy minél előbb), az ICS rendszereket és eszközöket üzletkritikus folyamataikban használó vállalatok fel fogják ismerni, hogy a nagyvállalati IT rendszerek biztonságával kapcsolatban már másfél-két évtizede csiszolgatott szabályzataiknak és eljárásaiknak ki kell alakítani az OT-re vonatkozó párjait (figyelembe véve az OT rendszerek sajátosságait) és akkor nagyon gyorsan meg fog jelenni az igény olyan ICS rendszerekre és berendezésekre, amik képesek a jelenlegi üzembiztonsági követelményeknek megfelelni úgy, hogy közben már egyes biztonsági megoldások és funkciók is zavartalanul működnek rajtuk (nem tartom lehetetlennek, hogy akkor már kizárólag ilyen működés lesz elfogadható az új idők új követelményeit felismerő és elfogadó szervezetek számára).

Tavaly év végén írtam egy posztot arról a Tripwire cikkről, amiben 12 biztonsági szakértő vázolta, hogy milyennek látják az ICS biztonság jövőjét 5-10 éves időtávon. Ezekben a válaszokban az egyik várakozás az volt, hogy az ICS rendszerek egyre több ponton fognak kapcsolódni felhős alkalmazásokhoz, például az ipari folyamatirányítással kapcsolatos adatok felhős alkalmazásokkal történő feldolgozása során.

A poszthoz több hozzászólás is érkezett, egyrészt nem tagadva ezt a tendenciát, másrészt viszont erősen helytelenítve az ICS rendszereké és a felhős megoldások egyre szorosabb kapcsolatát.

Először is röviden érdemes átnézni, hogy mire is gondolunk, amikor felhőről beszélünk (ezt csak nagyon röviden, mert ez a téma nem igazán vág a blog profiljába).

Egyrészt vannak publikus, privát és hibrid felhők. Publikus felhőszolgáltató többek között a Microsoft, a Google vagy az Amazon, akik erőforrásokat bocsátanak az ügyfeleik rendelkezésére, privát felhőt pedig gyakorlatilag bármilyen megfelelő infrastruktúrával rendelkező vállalat építhet magának a saját belső hálózatát vagy akár az Internetet felhasználva ehhez - jellemzően ezt azért világszinten is jelentős multinacionális vállalatok szokták megtenni. A hibrid felhő a két előző megoldásnak valamilyen keveréke.

Másrészt ma már szinte bármivel kapcsolatban találhatunk "as-a-Service"-ként hivatkozott, felhős megoldást. A leginkább elterjedtebbek mindmáig az infrastruktúra, mint szolgáltatás (IaaS, Infrastructure-as-a-Service), a platform (Paas, Platform-as-a-Service) és a szoftver (SaaS, Software-as-a-Service), de gyakorlatilag tényleg bármi lehet felhős szolgáltatás, nemrég láttam már Recovery-as-a-Service vagy Identity-as-a-Service szolgáltatásokat is (a Wikipedián a poszt írásának pillanatában 56 különböző szolgáltatást sorolnak fel az Analytics-as-a-Service-től a Unified Communications-as-a-Service).

Én kb. 10 éve gondolom úgy, hogy az ipari szervezetek esetében sem ördögtől való gondolat a felhős alkalmazások használata, de előbb minden esetben alapos kockázatelemzést tartok fontosnak. Azokban az esetekben, amikor a felhőben tárolni szándékozott adatok esetében a bizalmasság nem szempont (vagy egyenesen nem értelmezhető, például jogszabályi kötelezettség miatt publikált adatok esetén), a felhő komolyabb kockázatok nélkül biztosíthat olyan rendelkezésre állást, amit az adott szervezet csak magasabb ráfordítások mellett tudna elérni.

Nyilván vannak olyan adatok, amiket nem vagy csak jelentősen komolyabb biztonsági kontrollok mellett lehet, szabad vagy érdemes a felhőben tárolni vagy feldolgozni, de már talán az előző példa is megmutatja, mennyire bonyolult lehet a kérdés.

Külön kell kezelni azokat az eseteket, amikor egy adott gyártó már nem igazán ad lehetőséget nem-felhős megoldás használatára. A legjobb példának a Microsoft Key Management Service (KMS) rendszerét ma már nem lehet felhő nélkül használni. Ha pedig belegondolunk, hogy a Microsoft Windows operációs rendszer-családja mennyire elterjedt bizonyos ICS gyártók termékeinél, rögtön láthatjuk, hogy vannak és lesznek olyan ICS rendszerek, ahol nem igazán lesz kérdés a jövőben, hogy az adott rendszernek lesz-e (akár csak közvetetten is) köze felhős megoldásokhoz.

Azoknak, akik egy ideje már olvassák a blogot, nem lehet túl meglepő, hogy én személy szerint nem vagyok híve annak, hogy az ICS rendszereket Internet-kapcsolattal lássuk el és ebből egyenesen következik, hogy az ICS rendszerek felhős kapcsolatait sem tartom kifejezetten jó ötletnek. Tekintettel azonban arra, hogy láthatóan nem lehet majd teljesen távol tartani a felhős megoldásokat az ICS rendszerek világától, mindenképp hasznosnak tartom beszélni a témáról, azon túl is, hogy miért nem tartjuk jó ötletnek a felhő és az ICS rendszerek kapcsolatát.

A hírek szerint ransomware-támadás érte a portugál központú, multinacionális energia-szolgáltató EDP csoport informatikai rendszereit. Az EDP csoport az egyik legnagyobb európai energia-szolgáltató cégcsoport, amely mind a gáz-, mind villamosenergia-szektorban jelen van és a világ negyedik legnagyobb szélenergia-termelő vállalata. Az EDP-nek 4 kontinensen, 19 országban vannak vállalatai, amik összesen több, mint 11.500 alkalmazottal 11 milliónál is több ügyfelet szolgálnak ki.

A támadók mintegy 10 millió Eurónak (vagy 11 millió amerikai dollárnak) megfelelő BitCoin-t követelnek és a legújabb ransomware-es trendeknek megfelelően azzal is fenyegetőznek, hogy az általuk letöltött, állításuk szerint 10 TB-nyi(!) adatot publikálják, ha az EDP nem fizet. A hírek egyelőre nem szólnak arról, hogy az EDP csoport adatain kívül a folyamatirányításban használt rendszereket vagy berendezéseket is érintette volna a támadás, azonban a RagnarLocker-t az EDP-re szabadító támadók által közzétett fájlok között található többek között egy edpradmin2.kdb nevű fájl is, ami a közkedvelt KeePass jelszókezelő alkalmazás által használt fájl lehet, ez pedig arra is utalhat, hogy a támadók akár az EDP rendszeradminisztrátorai által használt jelszavak egy részéhez is hozzáférhettek, aminek további súlyos következményei is lehetnek.

KUKA Sim Pro sérülékenység

Federico Maggi, a Trend Micro munkatársa egy sérülékenységet talált a KUKA Sim Pro 3.1-es verziójában.

A gyártó a hibát a 3.1.2-es verzióban javította. A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-098-05

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

A kimiya néven ismert biztonsági kutató a ZDI-vel együttműködve egy sérülékenységet fedezett fel a Fuji electric V-Server Lite minden, 4.0.9.0-nál korábbi verziójában.

A gyártó a hibát a 4.0.9.0 verzióban javította. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-20-098-04

HMS Networks rendszerek sérülékenysége

Ander Martínez, a Titanium Industrial Security munkatársa egy sérülékenységről osztott meg részleteket a spanyol INCIBE CERT-tel, ami az HMS Networks eWON termékcsaládjának alábbi tagjait érinti:

- eWON Flexy minden, 14.1s0-nál korábbi firmware-verziója;
- eWON Cosy 14.1s0-nál korábbi firmware-verziója.

A hibával kapcsolatban a gyártó a legújabb, 14.1s0 firmware-verzióra történő frissítését javasolja. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-098-03

Sérülékenység GE Digital rendszerekben

Sharon Brizinov, a Claroty munkatársa egy sérülékenységet jelentett a GE Digital-nak, ami a gyártó CIMPLICITY v10.0 és korábbi verzióit érinti.

A gyártó a hibát javító v11.0 verziót 2020. januárban adta ki. A sérülékenység részleteiről az ICS-CERT publikációjából lehet tájékozódni: https://www.us-cert.gov/ics/advisories/icsa-20-098-02

Advantech rendszerek sérülékenységei

rgod, a 9sg biztonsági csoport tagja 8 sérülékenységet azonosított az Advantech WebAccess/NMS 3.0.2-nél korábbi verzióiban.

A gyártó a hibákat a 3.0.2-es verzióban javította. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-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.

Kevesen gondolnák, hogy a folyamatirányítás biztonsági kérdései olyan, az ICS rendszerekétől látszólag távoli világban is fel tudnak bukkanni, mint a tengerhajózásé. Pedig ha jól belegondolunk, nem kéne nagyon meglepőnek lennie, hogy a hatalmas teherszállító hajókat és turisták százait és ezreit a fedélzetükön szállító tengerjáró hajók csak úgy irányíthatóak egy maroknyi tengerésszel, hogy az irányításuk nagy mértékben automatizált. Ez viszont azt is jelenti, hogy a hajók automatizálási rendszerei minden valószínűség szerint kiberbiztonsági szempontból semmivel sincsenek jobb (vagy éppenséggel ami azt illeti, rosszabb) helyzetben, mint az átlagos ICS rendszerek. Persze nem jelenti azt, hogy a helyzet jó vagy megnyugtató lenne, éppen ellenkezőleg, erre nagyon jól rámutat, hogy az amerikai CISA (Cybersecurity and Infrastructure Security Agency) nemrég az amerikai parti őrség (US Coast Guard) ajánlásokat adott ki a hajózásban használt informatikai eszközök biztonságosabb használatával kapcsolatban.

Még 2019 tavaszán, a szingapúri Maritime Technology Conference nevű rendezvényen Itai Sela, a Szingapúri Kikötői Felügyelet vezetője előadásában azt részletezte, hogy a tengerhajózási cégek jelenleg is kibertámadások célpontjai és a szektor szereplőinek tisztában kell lenniük azzal, milyen fenyegetésekkel kell szembenézniük.

A konferencia kerekasztal beszélgetései és további előadásai során elhangzott, hogy bár a tengerhajózási cégek, leginkább pedig a tengeri árufuvarozással foglalkozó cégek tisztában vannak a kockázatokkal (ez szerintem már önmagában egy hatalmas eredmény - 7 éve foglalkozom az ICS kiberbiztonság kérdéseivel és én személy szerint még mindig azt tapasztalom, hogy nagyon sok szektorban nagyon sokan még mindig teljes értetlenséggel fogadják, hogy ezzel a témával foglalkozni kéne), azonban nagyon komoly kihívást jelent nekik, hogy pontosan mely pontokon és hogyan kéne hozzákezdeniük a kockázatok értékelésének és csökkentésének.

Szokás azt mondani, hogy a villamosenergia-rendszerek nélkül a civilizációnk rövid időn belül összeomlana, de legalábbis nagyon máshogy nézne ki, mint amit ma megszoktunk. Ezzel igen kevesen vitatkoznak. Azt már jóval kevesebben gondolják végig, hogy a tengeri áruszállítás felel az energiahordozók és legkülönbözőbb árucikkek célba juttatásáért, ezért egy, a tengerjáró hajók elleni nagyobb szabású kibertámadás-sorozat nem csak safety incidenseket okozna (természetesen azokra is számítani kellene és lehetne), hanem a világgazdaságra nézve is komoly veszélyeket jelenthetnek.

Sérülékenység a Becton, Dickinson and Company orvostechnikai rendszereiben

A Becton, Dickinson and Company (BD) egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi rendszereiket érinti:

- Pyxis MedStation ES System v1.6.1 verziója;
- Pyxis Anesthesia (PAS) ES System v1.6.1 verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsma-20-091-01

Hirschmann Automation and Control rendszerek sérülékenysége

Sebastian Krause és Toralf Gimpel, a GAI NetConsult GmbH munkatársai egy sérülékenységet fedeztek fel a Hirschmann alábbi rendszereiben:

- Az alábbi, HiOS 07.0.02 és korábbi verziókat használó berendezések:
- SP, RSPE, RSPS, RSPL, MSP, EES, EES, EESX, GRS, OS, RED
- A HiSecOS 03.2.00 és korábbi verziókat használó EAGLE20/30 berendezések.

A gyártó a hibát a HiOS 07.0.03 és a HiSecOS 03.3.00 verziókban javította. A sérülékenységgel kapcsolatban részleteket az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-20-091-01

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

Rongkuan Ma, Jie Meng és Peng Cheng egy sérülékenységet azonosítottak a Mitsubishi Electric MELSEC iQ-R, iQ-F, Q, L és F sorozatú programozható vezérlőinek minden verziójában.

A gyártó kockázatcsökkentő intézkedések bevezetését javasolja az érintett eszközeit használó ügyfeleinek. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-091-02

B&R Automation Studio sérülékenység

Yehuda Anikster és Amir Preminger, a Claroty munkatrásai három sérülékenységet találtak a B&R Automation Studio alábbi verzióiban:

- Automation Studio 4.0.x;
- Automation Studio 4.1.x;
- Automation Studio 4.2.x;
- Automation Studio 4.3.11SP-nél korábbi verziók;
- Automation Studio 4.4.9SP-nél korábbi verziók;
- Automation Studio 4.5.4SP-nél korábbi verziók;
- Automation Studio 4.6.3SP-nél korábbi verziók;
- Automation Studio 4.7.2-nél korábbi verziók;
- Automation Studio 4.8.1-nél korábbi verziók.

A gyártó a hibákkal kapcsolatban minél előbb a legfrissebb elérhető verzióra történő frissítést javasolja. A sérülékenységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-093-01

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználó kezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A Kaspersky által nemrég publikált elemzés szerint egy, a Kaspersky által Milum-nak nevezett trójait használ egy ismeretlen APT-csoport Közel-keleti szervezetek, köztük ipari cégek elleni támadásokhoz.

A támadásokat és a trójait elemző szakértők szerint a malware-t nagyjából egy éve, 2019. márciusban készítették. Az elemzések szerint egyelőre nincs nyoma annak, hogy a Wildpressure-nek nevezett támadásoknak az információgyűjtésen kívül más célja is lenne.

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

Flavian Dola, az Airbus Security munkatársa egy sérülékenységet talált a Schneider Electric alábbi termékeiben:

- EcoStruxure Control Expert minden, 14.1 Hot Fix-nél korábbi verziója;
- Unity Pro minden verziója;
- Modicon M340 minden, V3.20-nál korábbi verziója;
- Modicon M580 minden, V3.10-nél korábbi verziója.

A gyártó a hibát javító hotfix-et elérhetővé tette a weboldalán. A sérülékenységről további információkat a Schneider Electric bejelentésében lehet találni.

Sérülékenységek VISAM rendszerekben

Gjoko Krstic, az Applied Risk munkatársa 5 sérülékenységet azonosított a VISAM Automation Base (VBASE) termékcsaládjának alábbi tagjaiban:

- VBASE Editor, Version 11.5.0.2
- VBASE Web-Remote Module

A gyártó egyelőre nem reagált a most felfedezett hibákra. A sérülékenységekkel kapcsolatban bővebben az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-20-084-01

Advantech WebAccess sérülékenység

Peter Cheng, az Elex CyberSecurity, Inc. munkatársa egy sérülékenységet jelentett a DHS CISA-nak, ami az Advantech WebAccess 8.4.2 és korábbi verzióit érinti.

A gyártó a hibát a 8.4.4-es verzióban javította. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-20-086-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.

Felmerülhet a kérdés, hogy hogyan kapcsolódhat össze az ICS rendszerek kiberbiztonsága a koronavírus járvánnyal a válasz pedig több részből áll össze.

Az első a tömegesen elrendelt otthoni-távoli munkavégzés/home office jelensége. Ahogy Magyarországon, úgy szerte Európában elég hirtelen döntöttek úgy állami és vállalati vezetők, hogy aki csak tudja, végezze otthonról, távolról a napi munkáját, ezzel is elősegítve, hogy minél kevesebb embernek kelljen az otthonából a munkahelyére majd vissza utaznia tömegközlekedéssel vagy más módokon, így csökkentve a lehetséges fertőzések számát. Ez a járvány terjedése szempontjából nyilván jó, de a legtöbb cég nem volt felkészülve arra, hogy a munkatársaik ilyen tömegben kezdjenek távolról dolgozni, ez számos szervezetnél (az államigazgatástól az üzleti szférán át a közüzemi szolgáltatókig) okozott igen komoly műszaki kihívásokat. A VPN kapcsolatokat termináló eszközök és a hálózatbiztonsági eszközök kapacitásproblémái valamint az elégtelen számú notebook is igen komoly átmeneti problémákat tudtak okozni, de a biztonságos VPN kapcsolatok sarokkövét jelentő többfaktoros authentikációt biztosító megoldások bővítése is kihívást jelentett nem egy szervezetnél, ahogyan a távoli munkavégzés feltételeit még ki nem alakító kollégák azonnali hozzáférési igényei is rohammunkára kényszerítették (és talán kényszerítik még mindig) az IT terület szakembereit. Mondhatnánk azt, hogy ez nem igazán baj, mert most legalább felzárkóznak a korszerű munkakörülmények témájában azok a szervezetek, akik ezt az elmúlt 10-15 évben bármilyen indokkal halogatták. Azonban a rohamtempóban végzett munka, a kollégák hozzáféréseinek mindenáron történő biztosítása gyanítom nem egy esetben okozta a normál IT biztonsági szabályok lazítását ("Csak működjön minél előbb, nem számít, hogyan oldjátok meg!"-jeligével), ami viszont rövidesen IT biztonsági incidensek formájában fizettethetik meg kapkodás árát. Az elmúlt napokban már elkezdtek érkezni az első hírek, amik támadási kísérletekről szólnak többek között a WHO (World Health Organization) munkatársai és rendszerei ellen. Ahogy azt már többször láttuk, az első ilyen, egy adott eseményhez vagy témához vagy módszerhez kapcsolódó támadások általában nem az ICS rendszereket üzemeltető és használó szervezetek ellen történnek, de a Stuxnet óta eltelt 10 évben az első támadások és az első, ICS rendszerek elleni támadások közötti idő nagymértékben csökkent, nem lenne meglepő tehát, ha a világméretű járvány vége előtt megjelenne egy valamilyen módon a koronavírushoz kapcsolódó kibertámadás, ami ipari szervezeteket vagy ICS rendszereket céloz.

A válasz második részét a blogon néhányszor már érintettem és a ICS sérülékenységek sorozatban is számos alkalommal hivatkoztam orvostechnikai folyamatvezérlő rendszerek sérülékenységeiről szóló bejelentéseket. Ma már a kórházakban használt egészségügyi berendezések egy jelentős része ugyanúgy számítógépek által vezérelt orvostechnikai eszköz, mint a termelésirányításban vagy a közműszektorban használt PLC-k és ezeknek az orvostechnikai eszközöknek a biztonsági helyzete semmivel sem jobb, mint az ipari környezetekben használt rendszereké, amikről már számtalanszor írtam. Bízzunk benne, hogy sem véletlenül, sem célzott módon nem történnek majd támadások azok ellen a TCP/IP-n kommunikáló orvostechnikai berendezések ellen, amelyek segítségével az orvosok éppen egy súlyos beteg életéért küzdenek.

A másik kérdés pedig az, hogy mit tehetnek az ICS rendszerek üzemeltetéséért és biztonságáért felelős szakemberek? A két héttel ezelőtt, magyarra fordítva már idézett mondás Robert M. Lee Dragos alapító/vezérigazgatótól nagyon tömörören foglalja össze a mostani teendőket: Fear less, do more! Maradjunk otthon amennyire csak tudunk, tegyük a dolgunkat tudásunk legjavát adva és védjük meg a ránk bizott rendszereket és hálózatokat, végső soron pedig azt a civilizációt, amit ismerünk és amiben élünk!