Ezen a héten kedden, október 29-én érkeztek az első hírek arról, hogy a legnagyobb indiai atomerőművet, a Tamil Nadu tartományban található Kudankulam Atomerőművet (Kudankulam Nuclear Power Plant, KKNPP) kibertámadás érte. Az illetékesek először kategórikusan tagadták az incidens megtörténtét. Október 30-án azonban a Nuclear Power Corporation of India Ltd. (NPCIL) nevű indiai állami atomenergia vállalat megerősítette, hogy szeptember elején valóban történt egy incidens, amikor a Kaspersky Lab által szeptember közepén publikált elemzésben leírt, DTrack néven hivatkozott, elsősorban ATM-ek ellen használt malware fertőzött meg legalább egy számítógépet az KKNPP hálózatában.

A Kaspersky elemzése szerint a DTrack malware billentyűzet-leütés naplózásra, böngésző-előzmények mentésére, IP címek és egyéb, hálózati információk gyűjtésére, a futó folyamatok listázására és a megfertőzött számítógépen található fájlok listázására is képes volt.

Fentiekből elég jól látható, hogy a DTrack inkább egy felderítésre (is) használható malware-nek látszik. Az indiai illetékesek szerint (akik persze többé-kevésbé ugyanazok, akik egy napig vehemensen tagadták, hogy bármilyen incidens történt volna), a malware-támadás nem érintette az atomerőmű irányítástechnikai rendszereit, én azonban egyáltalán nem tartom elképzelhetetlennek, hogy a támadók pontosan az atomerőmű rendszereinek és hálózatainak felépítéséről gyűjtöttek információkat. Ha emlékszünk még a Havex/Dragonfly néven ismertté vált ICS malware-re (amiről szándékaim szerint fogok még hosszabb írni, ha jut majd időm megírni ezt a régen tervezett posztot és több másikat is, amiket az ICS-malware-ek témájában tervezek), az is elsősorban felderítésre használt malware volt és felfedezése után nem is kellett túl sokat várnunk a következő, immár nem csak információk gyűjtését végző ICS malware megjelenésére.

Ami miatt a KKNPP elleni támadás komoly aggodalmakat keltett sok, témával foglalkozó szakértőben, az a következő: a KKNPP hálózatában talált DTrack malware-ben beégetett felhasználóneveket és jelszavakat találtak, amik érvényesek voltak a KKNPP hálózatában a támadás idején, emiatt egyértelmű, hogy célzott támadásról volt szó. A DTrack malware-t a Kaspersky elemzése szerint a Lazarus néven ismert, általában Észak-koreai állami háttérrel rendelkező csoportként szoktak jellemezni, azonban szinte minden, a témával foglalkozó publikációban megemlítik, hogy napjainkban a célzott és kifinomult, ún. APT támadások mögött álló valódi elkövetőket azonosítani meglehetősen nehéz feladat, mert nem jelent komoly nehézséget a támadók számára álcázni valódi kilétüket.

Mindent figyelembe véve egyáltalán nem jelent sok jót, hogy a feltehetően állami/titkosszolgálati támadói csoportok már atomerőművek rendszerei elleni támadások környékén is feltűnnek. Valószínűnek tartom, hogy még akár 2019-ben sem ez az utolsó, ICS rendszerek vagy kritikus infrastruktúrák elleni kibertámadás, amiről beszélnünk kell.

A Covellite néven hivatkozott (a név a Dragos-tól származik) csoport az elemzések szerint kifejezetten a villamosenergia-rendszer elleni támadásokra specializálódott, azonban a rendelkezésre álló információk alapján nincsenek olyan képességeik, amik az érintett szervezetek ICS rendszereinek támadásához szükségesek, ehelyett a célba vett hálózatokról gyűjtenek információkat és szellemi tulajdont képező információkhoz igyekeznek hozzáférni.

A Covellite 2017 óta egyaránt célba vett európai, Észak-amerikai, Kelet-ázsiai szervezeteket, jellemzően kis volumenű, célzott adathalász támadásokkal operálva, amelyek során önéletrajznak vagy meghívónak álcázott fájlokkal próbálják bejuttatni a malware-jeiket a megcélzott szervezetek rendszereibe. Ezek a malware-ek jellemzően távoli hozzáférést biztosító trójaiak (RAT).

A Covellite által használt infrastruktúra (Command-and-Control szerverek) és malware-ek meglehetősen nagy hasonlóságot mutatnak a Lazarus és Hidden Cobra néven ismert, egyes források szerint Észak-koreai hátterű csoportokkal, de arra vonatkozóan jelenleg nem áll rendelkezésre bizonyíték, hogy milyen és mennyire szoros kapcsolat állhat fenn ezek között a csoportok között.

Az utóbbi időben a Covellite csoport aktivitása a jelek szerint fókuszt váltott és az Észak-amerikai célpontok helyett most már inkább európai és Kelet-ázsiai célpontokra koncentrálnak. A Dragos a Covellite csoport kritikus infrastruktúrák iránti fokozott érdeklődése, gyorsan fejlődő eszköztára és korábbi agresszív támadásai miatt kiemelt veszélyforrásnak tekinti ezt a csoportot.

Egy üdvözlendő e-mailt kaptam valamelyik nap, a Com-Forth ipari informatikával foglalkozó cég ipari IoT biztonsági szakmai napot fog tartani november 21-én. A tervezett program szerint lesz előadás az IIoT legnagyobb veszélyeiről, az ICS hálózatok védelméről (angol nyelven), élő hálózatmenedzsment demó, esettanulmányok és végül kerekasztal/panel-beszélgetés az ICS kiberbiztonság kérdéseiről.

Mindenképp örömtelinek tartom, hogy végre mozgolódás látszik az ICS biztonság területén és (amennyire én tudom) első alkalommal végre valaki tematikus ICS biztonsági konferenciát, szakmai napot szervez.

Kíváncsian várom, hogy milyen lesz a rendezvény és milyen visszhangja lesz.

Részletek és regisztrációs lehetőség az esemény weboldalán: https://info.comforth.hu/ipari-iot-szakmai-nap-2019

Siemens SIMATIC WinAC sérülékenység

Tal Keren, a Claroty munkatársa egy sérülékenységet talált a Siemens SIMATIC WinAC RTX (F) 2010 összes verziójában. A gyártó a sérülékenységgel kapcsolatban kockázatcsökkentő intézkedések alkalmazására tett javaslatot.

A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenységek GE Mark VIe vezérlőkben

Sharon Brizinov, a Claroty munkatársa két sérülékenységet azonosított a GE Mark VIe sorozatú vezérlőinek összes verziójában. A hibához a gyártó kockázatcsökkentő intézkedéseket jelentetett meg, javításról jelenleg nincs információ. A sérülékenységgel kapcsolatban részleteket az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-281-02

SMA Solar Technology rendszerek sérülékenysége

Borja Merino és Eduardo Villaverde, a León-i egyetem munkatársai az INCIBE-CERT-tel együttműködésben egy sérülékenységről publikáltak részleteket amik az SMA Solar Technology Sunny WebBox 1.6-os és korábbi firmware-verzióit érinti.

Az érintett termékek elérték életciklusuk végét, ezért javítás sem készül a hibára. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-281-01

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

A WATERSURE és a KIANDRA IT egy sérülékenységről közölt információkat a Siemens-szel, ami az alábbi, ipari rendszereiket érinti:

- Primary Setup Tool (PST) minden, v4.2 HF1-nél korábbi verziója;
- SIMATIC IT Production Suite minden, v7.0 SP1 HFX 2-nél korábbi verziója;
- SIMATIC NET PC-Software minden, v14-nél korábbi verziója;
- SIMATIC PCS 7 v7.1 és korábbi verziói;
- SIMATIC PCS 7 v8.0 minden verziója;
- SIMATIC PCS 7 v8.1 minden verziója;
- SIMATIC PCS 7 v8.2 minden, v8.2 SP1-nél korábbi verziója;
- SIMATIC STEP 7 (TIA Portal) v13 minden, v13 SP2-nél korábbi verziója;
- SIMATIC STEP 7 v5.X minden, v5.5 SP4 HF11-nél korábbi verziója;
- SIMATIC WinAC RTX (F) 2010 SP2 minden, SIMATIC WinAC RTX 2010 SP3-nál korábbi verziója;
- SIMATIC WinCC (TIA Portal) Basic, Comfort, Advanced minden, v14-nél korábbi verziója;
- SIMATIC WinCC (TIA Portal) Professional v13 minden, v13 SP2-nél korábbi verziója;
- SIMATIC WinCC (TIA Portal) Professional v14 minden, v14 SP1-nél korábbi verziója;
- SIMATIC WinCC Runtime Professional v13 minden, v13 SP2-nél korábbi verziója;
- SIMATIC WinCC Runtime Professional v14 minden, v14 SP1-nél korábbi verziója;
- SIMATIC WinCC v7.0 SP2 minden, v7.0 SP2 Update 12-nél korábbi verziója;
- SIMATIC WinCC v7.0 SP3 minden, v7.0 SP3 Update 8-nál korábbi verziója;
- SIMATIC WinCC v7.2 minden, v7.2 Update 14-nél korábbi verziója;
- SIMATIC WinCC v7.3 minden, v7.3 Update 11-nél korábbi verziója;
- SIMATIC WinCC v7.4 minden, v7.4 SP1-nél korábbi verziója;
- SIMIT minden, v9.0 SP1-nél korábbi verziója;
- SINEMA Remote Connect Client minden, v1.0 SP3-nál korábbi verziója;
- SINEMA Server minden, v13 SP2-nél korábbi verziója;
- SOFTNET Security Client v5.0 minden verziója;
- Security Configuration Tool (SCT) minden, v4.3 HF1-nél korábbi verziója;
- TeleControl Server Basic minden, v3.0 SP2-nél korábbi verziója.

A gyártó a hibával kapcsolatban javított verziókat adott ki az érintett termékekhez és a hivatalos telepítési útmutatóban leírtak szerzinti telepítést javasolja, mert az azt követve telepített rendszereket nem érinti a most publikált sérülékenység. A sérülékenységről a Siemens ProductCERT és az ICS-CERT publikációiban lehet további részleteket találni.

Philips orvostechnikai rendszerek sérülékenységei

A Philips három sérülékenységgel kapcsolatban közölt részleteket az ICS-CERT-tel, amik az alábbi orvostechnikai rendszereiket érintik:

- Brilliance 64 2.6.2 és korábbi verziói;
- Brilliance iCT 4.1.6 és korábbi verziói;
- Brilliance iCT SP 3.2.4 és korábbi verziói;
- Brilliance CT Big Bore 2.3.5 és korábbi verziói;
- MX8000 Dual EXP Systems.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://www.us-cert.gov/ics/advisories/ICSMA-18-123-01

Sérülékenység Siemens PROFINET eszközökben

A Siemens egy sérülékenységről publikált részleteket, ami az alábbi PROFINET termékcsaládba tartozó rendszereket érinti:

- Fejlesztő/tesztelő készletek PROFINET IO rendszerekhez:
- DK Standard Ethernet Controller minden verziója;
- EK-ERTEC 200 minden verziója;
- EK-ERTEC 200P minden verziója;
- SIMATIC CFU PA minden, 1.2.0-nál korábbi verzió;
- SIMATIC ET 200AL minden verziója;
- SIMATIC ET 200M minden verziója;
- SIMATIC ET 200MP IM 155-5 PN BA minden, 4.2.3-nál korábbi verzió;
- SIMATIC ET 200MP IM 155-5 PN HF minden verziója;
- SIMATIC ET 200MP IM 155-5 PN ST minden verziója;
- SIMATIC ET 200S minden verziója;
- SIMATIC ET 200SP IM 155-6 PN BA minden verziója;
- SIMATIC ET 200SP IM 155-6 PN HA minden verziója;
- SIMATIC ET 200SP IM 155-6 PN HF minden, 4.2.2-nél korábbi verzió;
- SIMATIC ET 200SP IM 155-6 PN HS minden verziója;
- SIMATIC ET 200SP IM 155-6 PN ST minden verziója;
- SIMATIC ET 200SP IM 155-6 PN/2 HF minden, 4.2.2-nél korábbi verzió;
- SIMATIC ET 200SP IM 155-6 PN/3 HF minden, 4.2.1-nél korábbi verzió;
- SIMATIC ET 200ecoPN minden verziója (kivéve a 6ES7148-6JD00-0AB0 és 6ES7146-6FF00-0AB0 sorozatszámú eszközöket);
- SIMATIC ET 200pro minden verziója;
- SIMATIC HMI Comfort Outdoor Panels 7" & 15" minden verziója;
- SIMATIC HMI Comfort Panels 4" - 22" minden verziója;
- SIMATIC HMI KTP Mobile Panels minden verziója;
- SIMATIC PN/PN Coupler minden verziója;
- SIMATIC PROFINET Driver minden, 2.1-nél korábbi verzió;
- SIMATIC S7-1200 CPU family minden verziója;
- SIMATIC S7-1500 CPU family minden, 2.0-nál korábbi verzió;
- SIMATIC S7-300 CPU family minden verziója;
- SIMATIC S7-400 PN/DP V7 minden verziója;
- SIMATIC S7-400 V6 és korábbi modellek minden verziója;
- SIMATIC S7-400H V6 minden, 6.0.9-nél korábbi verzió;
- SIMATIC S7-410 V8 minden verziója;
- SIMATIC WinAC RTX (F) 2010 minden, SP3-nál korábbi verzió;
- SINAMICS DCM minden, 1.5 HF1-nél korábbi verzió;
- SINAMICS DCP minden verziója;
- SINAMICS G110M v4.7 (PN Control Unit) minden, 4.7 SP10 HF5-nél korábbi verzió;
- SINAMICS G120 v4.7 (PN Control Unit) minden, 4.7 SP10 HF5-nél korábbi verzió;
- SINAMICS G130 v4.7 (Control Unit and CBE20) minden verziója;
- SINAMICS G150 (Control Unit and CBE20) minden verziója;
- SINAMICS GH150 v4.7 (Control Unit) minden verziója;
- SINAMICS GL150 v4.7 (Control Unit) minden verziója;
- SINAMICS GM150 v4.7 (Control Unit) minden verziója;
- SINAMICS S110 (Control Unit) minden verziója;
- SINAMICS S120 v4.7 (Control Unit and CBE20) minden verziója;
- SINAMICS S150 (Control Unit and CBE20) minden verziója;
- SINAMICS SL150 v4.7 (Control Unit) minden verziója;
- SINAMICS SM120 v4.7 (Control Unit) minden verziója;
- SINUMERIK 828D minden, 4.8 SP5-nél korábbi verzió;
- SINUMERIK 840D sl minden verziója;

A gyártó számos érintett eszközhöz kiadta a hiba javítását tartalmazó új verziókat. A sérülékenység részleteit a Siemens ProductCERT és az ICS-CERT publikációiban lehet elérni.

Sérülékenység Siemens valós idejű operációs rendszert futtató eszközeiben

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi, valós idejű operációs rendszert futtató eszközeit érinti:

- CP1604/CP1616 minden, 2.8-nál korábbi verziója;
- Fejlesztői/tesztelői készleteket PROFINET IO rendszerekhez:
- DK Standard Ethernet Controller minden, 4.1.1 Patch 05-nél korábbi verziója;
- EK-ERTEC 200 minden, 4.5.0 Patch 01-nél korábbi verziója;
- EK-ERTEC 200P minden, 4.5.0-nál korábbi verziója;
- SCALANCE X-200IRT minden, 5.2.1-nél korábbi verziója;
- SIMATIC ET 200M minden verziója;
- SIMATIC ET 200S minden verziója;
- SIMATIC ET 200ecoPN minden verziója (kivéve a 6ES7148-6JD00-0AB0 és a 6ES7146-6FF00-0AB0 sorozatszámú eszközöket);
- SIMATIC ET 200pro minden verziója;
- SIMATIC PN/PN Coupler 6ES7158-3AD01-0XA0 sorozatú eszközök minden verziója;
- SIMATIC S7-300 CPU family (incl. F) minden verziója;
- SIMATIC S7-400 (incl. F) v6 and below minden verziója;
- SIMATIC S7-400 PN/DP v7 (incl. F) minden verziója;
- SIMATIC WinAC RTX (F) 2010 minden, SP3-nál korábbi verziója;
- SIMOTION minden verziója;
- SINAMICS DCM minden, 1.5 HF1-nél korábbi verziója;
- SINAMICS DCP minden verziója;
- SINAMICS G110M v4.7 (Control Unit) minden, 4.7 SP10 HF5-nél korábbi verziója;
- SINAMICS G120 v4.7 (Control Unit) minden, 4.7 SP10 HF5-nél korábbi verziója;
- SINAMICS G130 v4.7 (Control Unit) minden, 4.7 HF29-nél korábbi verziója;
- SINAMICS G150 (Control Unit) minden, 4.8-nál korábbi verziója;
- SINAMICS GH150 v4.7 (Control Unit) minden verziója;
- SINAMICS GL150 v4.7 (Control Unit) minden verziója;
- SINAMICS GM150 v4.7 (Control Unit) minden verziója;
- SINAMICS S110 (Control Unit) minden verziója;
- SINAMICS S120 v4.7 (Control Unit and CBE20) minden, 4.7 HF34-nél korábbi verziója;
- SINAMICS S150 (Control Unit) minden, 4.8-nál korábbi verziója;
- SINAMICS SL150 v4.7 (Control Unit) minden verziója;
- SINAMICS SM120 v4.7 (Control Unit) minden verziója;
- SINUMERIK 828D minden, 4.8 SP5-nél korábbi verziója;
- SINUMERIK 840D sl minden verziója.

A gyártó a hibát az érintett termékek legújabb verzióiban javította. A sérülékenységgel kapcsolatban további részletek a Siemens ProductCERT és az ICS-CERT weboldalain találhatóak.

Siemens SIMATIC IT UADM rendszerek sérülékenysége

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami a SIMATIC IT UADM 1.3-nál korábbi verzióit érinti.

A gyártó a hibát az 1.3-as verzióban javította. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

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

Jared Rittle és Patrick DeSantis, a Cisco Talos munkatársai számos sérülékenységet találtak különböző Schneider Electric Modicon termékcsaládhoz tartozó berendezésben. Az érintett eszközök az alábbiak:

- Modicon M580 minden firmware-verziója;
- Modicon M340 minden firmware-verziója;
- Modicon Premium minden firmware-verziója;
- Modicon Quantum minden firmware-verziója;
- Modicon BMxCRA and 140CRA modulok minden firmware-verziója;
- Modicon BMENOC 0311;
- Modicon BMENOC 0321.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről további információkat az alábbi bejelentésekben lehet olvasni:

- SEVD-2019-281-01;
- SEVD-2019-281-02;
- SEVD-2019-281-03;
- SEVD-2019-281-04;

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.

Korábban a blogon én is többször írtam a Triton/TriSIS malware-támadásról, ami a (nem megerősített) feltételezések szerint egy szaúdi olajfinomító safety rendszereit fertőzte meg. 2019. szeptemberében a világ részben attól volt hangos, hogy légitámadás ért több szaúdi olajipari létesítményt, most pedig egymás után jönnek a hírek iráni és amerikai olajipari cégek elleni kibertámadásokról.

Az esetekről rendelkezésre álló információk megbízhatósági szintje nagyon változatos (elég annyit említeni, hogy az egyik, iráni illetékesektől származó nyilatkozat szerint az USA kiberháborút indított az iráni olajipar ellen a Stuxnet egy újabb verzióját használva, amit az iráni biztonsági szakemberek még időben észrevettek és megállítottak), de annyit biztosan lehet látni, hogy amint a nemzetközi politikai és diplomáciai feszültségek fokozódnak, úgy nő az egyes nemzeti kritikus infrastruktúrákat érő kibertámadások száma is.

Nem lehet eléggé hangsúlyozni, hogy a civil kritikus infrastruktúrák elleni támadások (legyenek azok fegyveres vagy számítógépes támadások) milyen hatalmas fenyegetést jelentenek az egész modern civilizációnkra, arra a világra, amit ma ismerünk és arra, ahogy az életünket éljük.

Mivel sejtem, hogy azokat a politikai döntéshozókat, akiknek hatalmában áll (minden oldalon), nem tudjuk meggyőzni arról, hogy nem a támadó célú kiberbiztonsági képességeket növeljék, ezért a hazai szakmai szervezetekhez fordulok, hogy befolyásukkal legalább azt érjék el, hogy a magyar döntéshozók érezzék a jelenleginél sokkal fontosabbnak a nemzeti kritikus infrastruktúrák kibervédelmének javítását.

Sérülékenységek Moxa berendezésekben

Guillaume Lopes, a Randorisec munkatársa két sérülékenységet jelentett a DHS CISA-nak, amik a Moxa EDR-810 berendezéseinek 5.1-es és korábbi verzióit érintik.

A gyártó a hibákat az 5.2-es verzióban javította. A sérülékenységekről bővebb információkat az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-274-03

Yokogawa termékek sérülékenysége

A Yokogawa egy sérülékenységet talált az alábbi termékeiben:

- Exaopc R1.01.00 - R3.77.00 verziók;
- Exaplog R1.10.00 - R3.40.00 verziók;
- Exaquantum R1.10.00 - R3.02.00 verziók;
- Exaquantum/Batch R1.01.00 - R2.50.40 verziók;
- Exasmoc minden verziója;
- Exarqe minden verziója;
- GA10 R1.01.01 - R3.05.01 verziók;
- InsightSuiteAE R1.01.00 - R1.06.00 verziók.

A gyártó minden érintett termékéhez kiadta a hiba javítását tartalmazó új verziót. A sérülékenységgel kapcsolatban további információk az ICS-CERT bejelentésében érhetőek el: https://www.us-cert.gov/ics/advisories/icsa-19-274-02

Sérülékenység Cisco ipari átjárókban

A Cisco publikációja szerint sérülékenységet találtak az IC3000 ipari átjárók firmware-jének 1.1.1-nél korábbi verzióiban.

A gyártó a hibát az 1.1.1-es firmware-verzióban javította. A sérülékenység részleteit a Cisco publikációjában lehet megtalálni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20191002-ic3000-icg-dos

Sérülékenységek Interpeak IPnet TCP/IP stack-et használó termékekben

Az ICS-CERT bejelentése szerint Gregory Vishnepolsky, Dor Zusman és Ben Seri, az Armis kutatói 11 különböző sérülékenységet találtak az Interpeak IPnet TCP/IP stack-ben, amit az alábbi gyártók valós idejű operációs rendszereiben (Real-Time Operating System, RTOS) használnak:

- ENEA OSE4 és OSE5, 2004. és 2006. között kiadott verziók (az ENEA 2007-ben lecserélte az Interpeak IPnet-et az OSENet-re);
- Régebbi, már nem támogatott VxWorks verziók 6.5-től kezdődően;
- Az életciklusuk végét már elért Advanced Network Technology (ANT) termékek mindegyike;
- A VxWorks bootrom network stack-je szintén érintett lehet;
- A VxWorks 653 MCE 3.x érintett lehet.

Az alábbi gyártók termékei szintén érintettek lehetnek:

- Abbott Laboratories;
- BD (Beckton Dickinson);
- Drager;
- GE Healthcare;
- Medtronic;
- Philips;
- Spacelabs.

A sérülékenységekről és az egyes gyártók hibákkal kapcsolatos tanácsairől további részleteket az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsma-19-274-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.

2019-re az ICS rendszerek eljutottak oda, hogy - a nyár elején publikált 2019-es SANS ICS kiberbiztonsági kérdőív (regisztráció után elérhető) szerint az ICS rendszerek harmada érhető el az Internetről és közel kétharmaduk csatlakozik valamilyen privát (általában az adott szervezet ügyviteli) hálózathoz. Ez egyértelmű bizonyítéka az IT-OT konvergencia és az IT komponensek ICS rendszerekben történő térnyerésének.

Ez azonban nem hozta magával az IT és az OT területeken dolgozók közötti együttműködés és párbeszéd kialakulását. Még mindig sokkal gyakrabban tapasztalom az IT és az OT területeken dolgozók közötti összeütközéseket, félreértéseket, értetlenséget és bizalmatlanságot. Nem egyszer tapasztaltam már ICS biztonsági konferenciákon, hogy egyes, néha kifejezetten idős OT mérnökök félig-meddig tréfásan vagy teljesen komolyan azzal vádolják az IT és IT biztonsági területekről érkező szakembereket, hogy nem értik az ICS rendszerek világát és felelőtlenségükkal üzemzavarokat fognak előidézni. Ugyanakkor persze az IT irányból érkezőket sem kell félteni, akik maradi és túlzottan óvatoskodó embereknek tartják az OT mérnököket, akik mindenféle megfontolás vagy a kiberbiztonsági kockázatok bármiféle elemzése nélkül söpörnek le az asztalról változtatási (patch-elési, illetve a biztonsági szint emelésére vonatkozó egyéb) javasolatokat.

Ez a helyzet nem tolerálható tovább. Azzal, hogy az IT komponensek egyre több ICS rendszerben és berendezésben jelennek meg és az IT egyre nagyobb szerepet kap a folyamatvezérlő rendszerekben, elkerülhetetlenné válik, hogy ez a bizalmatlan és néha bizony ellenséges hangulat az IT és OT területek szakemberei között megváltozzon. Az ICS rendszereknek több olyan sajátosságuk van, amiket egy, a jelenleginél jobb IT-OT együttműködéssel megalapozva ki lehetne használni egy olyan kiberbiztonsági rendszer felállítására, amivel az ICS rendszereket akár a normál vállalati IT rendszereknél sokkal hatékonyabban lehetne védeni. Az ICS rendszerek statikussága és az a tudás, amivel az OT mérnökök ezekről a rendszerekről és berendezésekről rendelkeznek, megtámogatva a megfelelően kiválasztott IT biztonsági eszközökkel (és időnként az elérhető, kifejezetten ICS biztonsági megoldásokkal) kiemelkedő eredményeket mutathat fel mind a kiberbiztonsági incidensek megelőzésében és észlelésében.

Ehhez mindkét szakterületnek lépéseket kell tennie. Az IT irányából érkező szakembereknek tiszteletben kell tartaniuk, hogy az ICS rendszerek és berendezések mások, mint amikhez a vállalati hálózatokban hozzászoktak, más megkötések és prioritások mentén történik az üzemeltetésük és meg kell hallgatniuk az OT mérnököket ezekről a szempontokról és követelményekről, az OT mérnököknek pedig el kell fogadniuk, hogy a kiberbiztonsági kockázatok egyre inkább realitássá válnak az ICS rendszerek és berendezések mindennapjaiban is és ezeknek a kockázatoknak a csökkentése nem lesz lehetséges az IT biztonsági eszközök és az azokat ismerő szakemberek nélkül. Tudomásul kell venniük továbbá, hogy bár a legtöbb IT és IT biztonsági mérnök valóban keveset (vagy éppen semmit sem) tud az ICS rendszerek működéséről, az ismeretek átadása terén az OT mérnökök feladat és felelőssége a nagyobb, hiszen nekik kell megtanítaniuk az IT és IT biztonsági szakembereknek legalább azt a minimumot, amivel már el lehet kezdeni az érdemi közös munkát az ICS rendszerek biztonsági szintjének növelése érdekében.

Cisco ipari hálózati eszközök sérülékenysége

A Cisco múlt heti bejelentése szerint egy sérülékenységet találtak az alábbi ipari környezetekbe szánt termékeikben:

- Cisco 800-as sorozatú Industrial Integrated Services routerek;
- Cisco 1000-es sorozatú Connected Grid Routers (CGR 1000).

A gyártó a hibával kapcsolatban javított firmware-verziót és kockázatcsökkentő intézkedésekre vonatkozó javaslatokat is kiadott. A sérülékenységről további információkat a Cisco weboldalán lehet találni.

Sérülékenységek Moxa hálózati eszközökben

A Moxa publikációja szerint 7 különböző sérülékenységet találtak az alábbi hálózati eszközeikben:

- EDS-G516E sorozatú Ethernet switch-ek 5.2-es vagy korábbi firmware-verziói;
- EDS-510E sorozatú Ethernet switch-ek 5.2-es vagy korábbi firmware-verziói.

A hibákra vonatkozóan a gyártó kockázatcsökkentő intézkedések bevezetését javasolja illetve kiadott egy új firmware-verziót is. A sérülékenységek részletei a Moxa publikációjában érhetőek el: https://www.moxa.com/en/support/support/security-advisory/eds-g516e-510e-ethernet-switches-vulnerabilities

Moxa ioLogik vezérlők sérülékenységei

A Moxa bejelentése szerint több sérülékenységet azonosítottak az alábbi rendszereikben:

- ioLogik 2500-as sorozatú vezérlők 3.0 és korábbi firmware-verziói;
- IOxpress Configuration Utility 2.3.0 és korábbi verziói.

A gyártó a hibával kapcsolatban minden érintett ügyfelének azt javasolja, hogy vegyék fel a kapcsolatot a Moxa Technical Support-tal, akiktől megkaphatják a szükséges hibajavítást. A sérülékenységekről bővebben a Moxa bejelentésében lehet olvasni: https://www.moxa.com/en/support/support/security-advisory/iologik-2542-hspa-series-ioxpress-vulnerabilities

Sérülékenységek Moxa Protocol Gateway-ekben

A Moxa weboldalán megjelent információk szerint 9 sérülékenységet azonosítottak az alábbi termékeikben:

- MB3170 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- MB3270 sorozatú eszközök 4.0 és korábbi firmware-verziói;
- MB3180 sorozatú eszközök 2.0 és korábbi firmware-verziói;
- MB3280 sorozatú eszközök 3.0 és korábbi firmware-verziói;
- MB3480 sorozatú eszközök 3.0 és korábbi firmware-verziói;
- MB3660 sorozatú eszközök 2.2 és korábbi firmware-verziói.

A hibák orvoslására a gyártó firmware-frissítést és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységek részleteit a Moxa weboldalán lehet elérni: https://www.moxa.com/en/support/support/security-advisory/mb3710-3180-3270-3280-3480-3660-vulnerabilities

Sérülékenységek Moxa Ethernet switch-ekben

A Moxa publikációja szerint 7 sérülékenységet azonosítottak az alábbi Ethernet switch-ikkel kapcsolatban:

- PT-7528 sorozatú eszközök 4.0 és korábbi verziói;
- PT-7828 sorozatú eszközök 4.0 és korábbi verziói.

A hibákkal kapcsolatban a gyártó elérhetővé tett egy új, javított firmware-verziót és kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről további információkat a Moxa publikációjában lehet olvasni: https://www.moxa.com/en/support/support/security-advisory/pt-7528-7828-ethernet-switches-vulnerabilities

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

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

A Dragos által Chrysene névre keresztelt csoportra (a Symantec Greenbug, a Palo Alto Networks OilRig néven említi őket az elemzéseikben) először 2012-ben, a Saudi Aramco elleni Shamoon támadások vizsgálatakor figyeltek fel a biztonsági kutatók. A Saudi Aramco a 2012-es támadások következtében több tízezer munkaállomását vesztette el átmenetileg, amikor a támadók törölték az érintett számítógépek merevlemezeit.

A Chrysene csoport az elemzők szerint több más csoporttal együttműködve hajtják végre a támadásaikat, ők azok, akik egy adott rendszer kezdeti kompromittálásáért felelősek és amikor kiépítették a későbbi műveletekhez szükséges hátsó ajtókat, akkor a rendszerekben történő további műveleteket átadják más csoportoknak.

A csoport tevékenységének nyomait felfedezték már Irakban, Pakisztánban, Izraelben, Nagy-Britanniában és az Arab öbölben is.

Eszköztárukra jellemzőek a 64-bites malware-ek (amik csak 64-bites operációs rendszereken tudnak futni), valamint az ún. watering hole-támadások. Elsődleges célpontjaik az ICS rendszereket használó szervezetek, de 2017 óta a Dragos megfigyelései szerint újra aktívak és immár nem csak ICS rendszerek kompromittálását próbálják watering hole-támadásokkal elérni.

A csoportról több elemzés is elérhető az alábbi linkeken:
Dragos: https://dragos.com/resource/chrysene/
Symantec: https://www.symantec.com/connect/blogs/greenbug-cyberespionage-group-targeting-middle-east-possible-links-shamoon
Palo Alto Networks Unit 42: https://unit42.paloaltonetworks.com/behind-the-scenes-with-oilrig/
Marco Ramili elemzései: https://marcoramilli.com/2019/06/27/similarities-and-differences-between-muddywater-and-apt34/

https://marcoramilli.com/2019/05/02/apt34-glimpse-project/
https://marcoramilli.com/2019/04/23/apt34-webmask-project/

Sérülékenység Honeywell IP kamerákban

Ismail Bulbil egy sérülékenységet jelentett a DHS CISA-nak, ami a Honeywell alábbi, Performance sorozatú IP kameráit és NVR berendezéseit érinti:

Performance IP kamerák:

- HBD3PR2;
- H4D3PRV3;
- HED3PR3;
- H4D3PRV2;
- HBD3PR1;
- H4W8PR2;
- HBW8PR2;
- H2W2PC1M;
- H2W4PER3;
- H2W2PER3;
- HEW2PER3;
- HEW4PER3B;
- HBW2PER1;
- HEW4PER2;
- HEW4PER2B;
- HEW2PER2;
- H4W2PER2;
- HBW2PER2;
- H4W2PER3;
- HPW2P1.

Performance NVR-ek:

- HEN08104;
- HEN08144;
- HEN081124;
- HEN16104;
- HEN16144;
- HEN16184;
- HEN16204;
- HEN162244;
- HEN16284;
- HEN16304;
- HEN16384;
- HEN32104;
- HEN321124;
- HEN32204;
- HEN32284;
- HEN322164;
- HEN32304;
- HEN32384;
- HEN323164;
- HEN64204;
- HEN64304;
- HEN643164;
- HEN643324;
- HEN643484;
- HEN04103;
- HEN04113;
- HEN04123;
- HEN08103;
- HEN08113;
- HEN08123;
- HEN08143;
- HEN16103;
- HEN16123;
- HEN16143;
- HEN16163;
- HEN04103L;
- HEN08103L;
- HEN16103L;
- HEN32103L.

A gyártó a hibával kapcsolatban minden érintett típusú berendezéshez elérhetővé tette a javított firmware-verziót. A sérülékenységről további információkat az ICS-CERT publikációjában lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-260-03

Advantech WebAccess sérülékenységek

Peter Cheng, az Elex CyberSecurity Inc., a VenusTech-hez tartozó ADLab és Mat Powell, a Zero Day Initiative munkatársa négy sérülékenységet találtak az Advantech WebAccess 8.4.1 és korábbi verzióiban.

A gyártó a hibákat a WebAccessNode 8.4.2-es verziójában javította. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-260-01

Sérülékenységek Tridium Niagara rendszerekben

Johannes Eger és Fabian Ullrich, a Secure Mobile Networking Lab munkatársai két sérülékenységet azonosítottak az alábbi Tridium termékekben:

- Niagara AX 3.8u4 (JACE 3e, JACE 6e, JACE 7, JACE-8000);
- Niagara 4.4u3 (JACE 3e, JACE 6e, JACE 7, JACE-8000);
- Niagara 4.7u1 (JACE-8000, Edge 10).

A sérülékenységek nem érintik a Windows és Linux Supervisor telepítéseket.

A hibákat a gyártó az érintett termékek újabb verzióiban javította. A sérülékenységekkel kapcsolatban részletek az ICS-CERT bejelentésében érhetőek el: https://www.us-cert.gov/ics/advisories/icsa-19-262-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.