Omron Network Configurator sérülékenység

Egy n0b0dy néven ismert biztonsági szakember egy sérülékenységről osztott meg információkat a DHS CISA-val, ami az Omron Network Configurator for DeviceNet Safety megoldásának 3.41-es és korábbi verzióit érinti.

A gyártó a hibát az érintett termék 3.42-es verziójában javította és további 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 publikációjában lehet találni: https://www.us-cert.gov/ics/advisories/ICSA-19-134-01

Sérülékenység Omron CX-Supervisor rendszerekben

Michael DePlante a ZDI-vel együttműködésben egy sérülékenység részleteit osztotta meg a DHS CISA-val. A sérülékenység az Omron CX-Supervisor 3.5(12)-es és korábbi verzióit érinti.

A gyártó a hibát a 3.51(9)-es verzióban javította. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-309-01

Fuji Electric V-Server sérülékenység

kimiya, a 9SG biztonsági csoport tagja egy sérülékenységet azonosított a Fuji Electric V-Server 4.0.6-os és korábbi verzióiban.

A gyártó a hibát a 4.0.7-es verzióban javította. A sérülékenység részleteit az ICS-CERT weboldalán lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-311-02

Sérülékenység Mitsubishi Electric berendezésekben

Tri Quach, az Amazon Customer Fulfillment Technology Security (CFTS) csoportjának munkatársa egy sérülékenységet fedezett fel a Mitsubishi Electric alábbi termékeiben:

- MELSEC-Q sorozatú eszközök:
- Q03/04/06/13/26UDVCPU eszközök 21081 és korábbi sorozatszámú darabjai;
- Q04/06/13/26UDPVCPU eszközök 21081 és korábbi sorozatszámú darabjai;
- Q03UDECPU, Q04/06/10/13/20/26/50/100UDEHCPU eszközök 21081 és korábbi sorozatszámú darabjai.
- MELSEC-L sorozatú eszközök:
- L02/06/26CPU, L26CPU-BT eszközök 21101 és korábbi sorozatszámú darabjai;
- L02/06/26CPU-P, L26CPU-PBT eszközök 21101 és korábbi sorozatszámú darabjai;
- L02/06/26CPU-CM, L26CPU-BT-CM eszközök 21101 és korábbi sorozatszámú darabjai.

A gyártó a hibát az érintett eszközökhöz kiadott legfrissebb firmware-verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-311-01

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

Az ICS-CERT két publikációjában is Medtronic Valleylab rendszerekkel kapcsolatos sérülékenységekről hozott nyilvánosságra részleteket.

Az első esetben beégetett felhasználói azonosítói adatokról, törhető hash-elési algoritmus használatáról és a bevitt adatok nem megfelelő ellenőrzéséről van szó, az érintett rendszerek az alábbiak:

- Valleylab Exchange Client 3.4-es és korábbi verziói;
- Valleylab FT10 Energy Platform (VLFT10GEN) 4.0.0 és korábbi verziói;
- Valleylab FX8 Energy Platform (VLFX8GEN)1.1.0 és korábbi verziói.

A második publikációban nem megfelelő authentikációs folyamatról és a beépített védelmi mechanizmusok hibájáról ír az ICS-CERT, ezek a hibák az alábbi rendszereket érintik:

- Valleylab FT10 Energy Platform (VLFT10GEN) 2.1.0 és korábbi verziói;
- Valleylab LS10 Energy Platform (VLLS10GEN) 1.20.2 és korábbi verziói.

A gyártó a hibákat az FT10-es és LS10-es rendszerekhez már kiadott frissítésben javította, az FX8-as típushoz a javítás várhatóan 2020-ban fog megjelennni. A sérülékenységekről részletesen az ICS-CERT vonatkozó publikációiban lehet olvasni:

https://www.us-cert.gov/ics/advisories/icsma-19-311-01
https://www.us-cert.gov/ics/advisories/icsma-19-311-02

Sérülékenység Cisco ipari környezetbe szánt hálózati eszközök menedzsment megoldásában

A Cisco bejelentése szerint egy cross-site scripting sérülékenységet azonosítottak a Cisco Industrial Network Director nevű termékük 1.7.1-45-nél korábbi verzióiban.

A gyártó a hibát az 1.7.1-45-ös verzióban javította. A sérülékenység részleteit a Cisco weboldalán lehet megtalálni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20191106-idn-xss

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 hetekben két, ICS biztonsággal kapocslatos felmérésről is publikáltak részleteket. Az elsőt a Control Systems Cyber Security Association International (CS2AI) az idei ICS Cyber Security Conference nevű, évente megrendezésre kerülő Atlanta-i szakmai konferencián mutatta be.

A felmérésükben közel 300-an válaszoltak a feltett kérdésekre, az anonimizált válaszok alapján készülő publikáció várhatóan november folyamán fog napvilágot látni.

A felmérés egyik leginkább figyelemfelkeltő része az elmúlt 12 hónapban történt ICS biztonsági incidensekre vonatkozóan adott válaszok között található, ugyanis a válaszolók 1 %-a jelzett személyi sérüléssel és szintén 1 % ismerte be, hogy a biztonsági incidens halálos balesetet okozott. Jelenleg semmilyen további részlet nem ismert ezekkel az incidensekkel kapcsolatban, mert a CS2AI minden választ névtelenként kezel, így a válaszadók megbízhatósági szintjéről sem állnak rendelkezésre információk, minden esetre aggasztó, hogy (ha most még csak névtelenül is), de az ipari szektorban működő szervezetek már hajlandóak elismerni, hogy az ICS biztonsági események safety incidensekhez vezethetnek és egyes esetekben vezetnek is.

A válaszadók további negyede jelezte, hogy a biztonsági incidens üzemzavarhoz vezetett és sokan nem tudtak válaszolni az általuk képviselt szervezetek belső szabályai miatt.

A fenyegetések közül még mindig az ICS környezetekben használt adathordozókon terjedő malware-ek vezetnek, valamivel kisebb százalékban nevezték meg az e-mailt, mint jelentős támadási vektort.

Annak ellenére, hogy sok éve az egyik első számú ICS biztonsági javaslat úgy a gyártók, mint a független biztonsági szakértők részéről, hogy ne csatlakoztassanak az ipari szektorban működő cégek ICS rendszereket és berendezéseket az Internetre vagy más, nem védett hálózatra, mégis, még mindig több olyan választ adtak a megkérdezettek, hogy PLC-k, HMI-ok, szerverek, munkaállomások és történeti adatbázisok érhetőek el a hálózataikban az Internetről.

Amint lesz információm a CS2AI teljes, publikusan elérhető jelentéséről, frissíteni fogom ezt a posztot.

Két további felmérés is megjelent, egy az amerikai számvevőszéktől (U.S. Government Accountability Office - GAO), egy pedig a Siemens-től. Ezekből a felmérésekből ismét az derül ki, hogy a villamosenergia-rendszer elleni kibertámadások hatására súlyos károkat okozhatnak. A Siemens és a Ponemon intézet közös felmérése alapján a villamosenergia-rendszer kockázatai nőttek az utóbbi időben. A válaszadók 54%-a számít kibertámadásra a kritikus infrastruktúrák ellen a következő egy évben és 64%-uk szerint a kiberbiztonság egyike a legnagyobb kihívásaiknak.

A GAO felmérése szerint az amerikai villamosenergia-hálózat kiberbiztonsági kitettsége egyre nagyobb. A GAO publikációjában a villamosenergia-ipari cégek mellett az amerikai energiaügyi minisztérium (Department of Energy, DoE) szerepét is kiemeli, akik kidolgoztak ugyan terveket és értékelési módszereket az érintett szektor szereplőinek kiberbiztonsági szintjének javítására, de a GAO szerint ezek a dokumentumok nem tartalmazzák mindazokat a kulcsfontosságú részleteket, amik egy hatékony nemzeti stratégiához szükségesek.

A GAO szerint a villamosenergia-ipari cégek öt fontos területen küzdenek jelentős kihívásokkal:

1. Nehézséget jelent a megfelelő számú kiberbiztonsági szakember alkalmazása.
2. Korlátozott a minősített információk megosztásának lehetősége az állami szervek és magánkézben lévő cégek között.
3. Korlátozott erőforrások a kiberbiztonsági védelmi eszközök beszerzésére.
4. Kitettség más kritikus infrastruktúrák felé, amik szintén sérülékenyek lehetnek a kibertámadásokra.
5. Bizonytalanság, hogyan kellene megvalósítani a kiberbiztonsági szabványokban és útmutatókban foglaltakat.

Sérülékenységek Horner Automation rendszerekben

Francis Provencher, a Protek Research Lab munkatársa a ZDI-vel együttműködve két sérülékenységről publikált részleteket a Horner Automation Cscape 9.90 és korábbi verzióival kapcsolatban.

A gyártó a hibákat a Cscape 9.90 SP1 verzióban javította. A sérülékenységek részleteiről az ICS-CERT bejelentésében lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-290-02

AVEVA rendszerek sérülékenysége

Az indiai Kanpur Műszaki Egyetem sérülékenység vizsgálatra és behatolás-tesztelésekre specializálódott csapat egy sérülékenységet jelentett az AVEVA-nak, ami az alábbi rendszereiket érinti:

- Vijeo Citect és Citect SCADA IEC870IP driver-ének v4.14.02 és korábbi verziói.

A hibát a gyártó az IEC870IP driver v4.15.00 verziójában javította. A sérülékenységgel kapcsolatban további részletek az ICS-CERT bejelentésében lehet találhatóak: https://www.us-cert.gov/ics/advisories/icsa-19-290-01

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

Haojun Hou, Kushal Arvind Shah, a Fortinet, Yongjun Liu, a NSFOCUS munkatársa és a Telus összesen 3 sérülékenységről közöltek részleteket a Schneider Electric-kel, amik a ProClima 8.0.0-nál korábbi verzióit érintik.

A gyártó a hibákat a ProClima 8.0.0 verziójában javította. A sérülékenységekről több információt az ICS-CERT publikációjában lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-295-01

Honeywell IP-AK2 berendezések sérülékenysége

Maxim Rupp egy sérülékenységet talált a Honeywell IP-AK2 Access Control Panel-jeinek 1.04.07-es és korábbi verzióiban.

A gyártó a hibát az 1.04.15-ös verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-297-02

Sérülékenységek Rittal rendszerekben

Az Applied Risk két sérülékenységet fedezett fel a Rittal Chiller SK 3232-es sorozatú, Carel pCOWeb firmware A1.5.3 – B1.2.4 verzióira épülő webes interfészeiben.

A sérülékenységek okozta kockázatok csökkentésével kapcsolatban javasolt felvenni a kapcsolatot a gyártó támogatási központjával. A sérülékenységek részleteit az ICS-CERT bejelentésében lehet megtalálni: https://www.us-cert.gov/ics/advisories/icsa-19-297-01

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

Brian Landrum, a Coalfire LABS munkatársa egy sérülékenységet azonosított a Philips IntelliSpace Perinatal K és korábbi verzióiban.

A gyártó a hibával kapcsolatban terjedelmes útmutatót adott ki a kockázatok csökkentése érdekében és jelenleg is vizsgálja, hogy milyen javítást készíthet a hibára. A patch várhatóan a következő, tervek szerint 2020 végén megjelenő kisebb frissítésben lesz elérhető. A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsma-19-297-01

Sérülékenység PHOENIX CONTACT rendszerekben

A 9sg biztonsági csoport a ZDI-vel együttműködve egy sérülékenységről publikált részleteket, ami a PHOENIX CONTACT Automation Worx szoftvercsomagjának alábbi tagjait érinti:

- PC Worx 1.86 és korábbi verziói;
- PC Worx Express 1.86 és korábbi verziói;
- Config+ 1.86 és korábbi verziói.

A gyártó a hiba javításán jelenleg is dolgozik. 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-19-302-01

Honeywell IP kamerák és videórögzítők sérülékenysége

A Honeywell egy sérülékenységről közölt részleteket, ami az alábbi termékeit érinti.

equIP sorozatú kamera modellek:
- H2W2GR1;
- H3W2GR1;
- H3W2GR1V;
- H3W2GR2;
- H3W4GR1;
- H3W4GR1V;
- H4D8GR1;
- H4L2GR1;
- H4L2GR1V;
- H4L6GR2;
- H4W2GR1;
- H4W2GR1V;
- H4W2GR2;
- H4W4GR1;
- H4W4GR1V;
- HBD8GR1;
- HBL2GR1;
- HBL2GR1V;
- HBL6GR2;
- HBW2GR1;
- HBW2GR1V;
- HBW2GR3;
- HBW2GR3V;
- HBW4GR1;
- HBW4GR1V;
- HCD8G;
- HCL2G;
- HCL2GV;
- HCPB302;
- HCW2G;
- HCW2GV;
- HCW4G;
- HDZ302D;
- HDZ302DE;
- HDZ302DIN;
- HDZ302DIN-C1;
- HDZ302DIN-S1;
- HDZ302LIK;
- HDZ302LIW;
- HEPB302W01A04;
- HEPB302W01A10;
- HEPZ302W0;
- HFD6GR1;
- HFD8GR1;
- HM4L8GR1;
- HMBL8GR1;
- HSW2G1;
- HSW2G1;
- HSWB2G1;
- HSWB2G1.

Performance sorozatú kamera modellek:
- H2W2PC1M;
- H2W2PER3;
- H2W2PRV3;
- H2W4PER3;
- H2W4PRV3;
- H4D3PRV2;
- H4D3PRV3;
- H4D8PR1;
- H4W2PER2;
- H4W2PER3;
- H4W2PRV2;
- H4W4PER2;
- H4W4PER3;
- H4W4PRV2;
- H4W4PRV3;
- H4W8PR2;
- HBD2PER1;
- HBD3PR1;
- HBD3PR2;
- HBD8PR1;
- HBW2PER1;
- HBW2PER2;
- HBW2PR1;
- HBW2PR2;
- HBW4PER1;
- HBW4PER2;
- HBW4PR1;
- HBW4PR2;
- HBW8PR2;
- HDZP252DI;
- HDZP304DI;
- HED2PER3;
- HED3PR3;
- HED8PR1;
- HEW2PER2;
- HEW2PER3;
- HEW2PR1;
- HEW2PR2;
- HEW2PRW1;
- HEW4PER2;
- HEW4PER2B;
- HEW4PER3;
- HEW4PER3B;
- HEW4PR2;
- HEW4PR3;
- HEW4PRW3;
- HFD5PR1;
- HPW2P1.

Videórögzítő modellek:
- HEN04102;
- HEN04112;
- HEN04122;
- HEN08102;
- HEN08112;
- HEN08122;
- HEN08142;
- HEN08162;
- HEN16102;
- HEN16122;
- HEN16142;
- HEN16162;
- HEN04103;
- HEN04113;
- HEN04123;
- HEN08103;
- HEN08113;
- HEN08123;
- HEN08143;
- HEN16103;
- HEN16123;
- HEN16143;
- HEN16163;
- HEN04103L;
- HEN08103L;
- HEN16103L;
- HEN32103L;
- HEN08104;
- HEN08144;
- HEN081124;
- HEN16104;
- HEN16144;
- HEN16184;
- HEN32104;
- HEN321124;
- HEN16204;
- HEN16284;
- HEN162244;
- HEN32204;
- HEN32284;
- HEN322164;
- HEN64204;
- HEN642164;
- HEN16304;
- HEN16384;
- HEN32304;
- HEN32384;
- HEN323164;
- HEN64304;
- HEN643164;
- HEN643324;
- HEN643484;
- HRHT4040;
- HRHT4041;
- HRHT4042;
- HRHT4080;
- HRHT4082;
- HRHT4084;
- HRHT4160;
- HRHT4162;
- HRHT4164;
- HRHT4166;
- HRHT41612;
- HRHQ1040;
- HRHQ1040L;
- HRHQ1041;
- HRHQ1080;
- HRHQ1080L;
- HRHQ1081;
- HRHQ1082;
- HRHQ1160;
- HRHQ1161;
- HRHQ1162;
- HRHQ1164.

A gyártó a hibát az érintett berendezések legfrissebb firmware-verzióiban javította. A sérülékenységgel kapcsolatos további információkat az ICS-CERT bejelentésében lehet találni.

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

A Honeywell publikációja szerint egy sérülékenységet találtak az alábbi termékeikben.

equIP sorozatú kamera modellek:
- H2W2GR1,
- H3W2GR1,
- H3W2GR1V,
- H3W2GR2,
- H3W4GR1,
- H3W4GR1V,
- H4D8GR1,
- H4L2GR1,
- H4L2GR1V,
- H4L6GR2,
- H4LGGR2,
- H4W2GR1,
- H4W2GR1V,
- H4W2GR2,
- H4W4GR1,
- H4W4GR1V,
- HBD8GR1,
- HBL2GR1,
- HBL2GR1V,
- HBL6GR2,
- HBL6GR2,
- HBW2GR1,
- HBW2GR1V,
- HBW2GR3,
- HBW2GR3V,
- HBW4GR1,
- HBW4GR1V,
- HCD8G,
- HCL2G,
- HCL2GV,
- HCW2G,
- HCW2GV,
- HCW4G,
- HDZ302,D
- HDZ302DE,
- HDZ302DIN,
- HDZ302DIN-C1,
- HDZ302DIN-S1,
- HDZ302LIK,
- HDZ302LIW,
- HFD6GR1,
- HFD8GR1,
- HM4L8GR1,
- HMBL8GR1.

Performance sorozatú kamera modellek:
- H4D8PR1,
- HFD5PR1,
- HPW2P1,
- HDZP304DI,
- HDZP252DI.

A gyártó elérhetővé tette a hibát javító firmware-verziókat. A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni.

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

A Honeywell információi szerint egy sérülékenységet azonosítottak az alábbi, equIP sorozatú IP kameráikban:

- H4L2GR1;
- HBL2GR1;
- HCL2G;
- H4W2GR1;
- H4W2GR2;
- H4W4GR1;
- H3W2GR1;
- H3W2GR2;
- H3W4GR1;
- HBW2GR1;
- HBW4GR1;
- HBW2GR3;
- HCW2G;
- HCW4G.

A gyártó a hibát a legfrissebb elérhető firmware-verziókban javította. A sérülékenység részleteiről az ICS-CERT weboldalán lehet tájékozódni.

Sérülékenységek Advantech rendszerekben

rgod, a 9SG biztonsági csoport tagja és trendytofu, a ZDI-vel együttműködve 4 sérülékenységről hoztak nyilvánosságra részleteket, amik az Advantech alábbi rendszereit érintik:

- WISE-PaaS/RMM 3.3.29 és korábbi verziói.

A gyártó az érintett termékek támogatását 2019. júliussal befejezte, az ezeket még használó ügyfeleinek az EdgeSense és DeviceOn termékekre történő cserélését és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekkel kapcsolatban további információkat az ICS-CERT publikációja tartalmaz: https://www.us-cert.gov/ics/advisories/icsa-19-304-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.

Ez év márciusában kerültek napvilágra az első részletek (amikről én itt írtam) arról a támadásról, amik egy amerikai villamosenergia-ipari szereplő vezérlőközpontja és távoli alállomásai közötti kommunikáció ellen indított szolgáltatás-megtagadásos támadás (DoS) néhány részletéről szóltak.

Akkor még sok részletet visszatartottak, most azonban további információkat publikáltak az esetről. Ezek alapján az incidens a Utah államban működő, szél- és naperőmű-farmokat üzemeltető sPower nevű cég rendszerét érték. Az érintett cég megnevezésén túl az incidenssel kapcsolatban most megjelent cikkek megnevezik a helytelenül beállított és nem patch-elt tűzfal gyártóját is - nem mintha ez igazán számítana, hiszen bármelyik gyártó bármelyik eszközét lehet rosszul beállítva használni, a nem telepített patch-ek pedig egy Internetre csatlakoztatott eszköz esetén mindig jelentős kockázatokat hordoznak.

A márciusi sPower incidens részleteiről most az E&E News, a CyberScoop, és a ZDNet ír, az eredeti, 13 oldalas jelentés az amerikai Energiaügyi Minisztériumtól (Department of Energy, DoE) pedig itt érhető el.

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.