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

William Knowles, az Applied Risk munkatársa egy sérülékenységet talált a WAGO alábbi termékeiben:

- 750-352 sorozat FW11-nél korábbi firmware-verziói;
- 750-831/xxx-xxx sorozat FW11-nél korábbi firmware-verziói;
- 750-852 sorozat FW11-nél korábbi firmware-verziói;
- 750-880/xxx-xxx sorozat FW11-nél korábbi firmware-verziói;
- 750-881 sorozat FW11-nél korábbi firmware-verziói;
- 750-889 sorozat FW11-nél korábbi firmware-verziói.

A hibával kapcsolatban a gyártó a legújabb, már elérhető firmware-verzió használatát és 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://us-cert.cisa.gov/ics/advisories/icsa-20-308-01

Sérülékenységek ARC Informatique PcVue rendszerekben

Sergey Temnikov és Andrey Muravitsky, a Kaspersky Lab munkatársai három sérülékenységet fedeztek fel az ARC Informatique PcVue 8.10-től 12.0.17-ig terjedő verzióiban.

A gyártó a hibával kapcsolatban a 12.0.17-es verzióra történő frissítést javasolja. A sérülékenységek részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-308-03

NEXCOM rendszerek sérülékenységei

A ZDI két sérülékenységről közölt információkat a DHS CISA-val, amik a NEXCOM NIO 50-es rendszereinek összes verzióját érintik.

A gyártó már nem forgalmazza a NIO 50-es rendszereket és támogatást sem biztosít hozzájuk, így a hibák javítása nem várható. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-308-02

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

A Mitsubishi Electric összesen hat sérülékenységről osztott meg információkat a DHS CISA-val, amik az alábbi termékeiket érintik:

A CoreOS 05.65.00.BD és korábbi verzióival működő GOT1000 rendszerek alábbi modelljei:

- GT1455-QTBDE;
- GT1450-QMBDE;
- GT1450-QLBDE;
- GT1455HS-QTBDE;
- GT1450HS-QMBDE.

A gyártó a hibákat a CoreOS legújabb verziójában javította. A sérülékenységek részleteiről további információkat az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-310-02

WECON PLC Editor sérülékenységek

Natnael Samson és Francis Provencher, a ZDI-vel együttműködve két sérülékenységet jelentettek a DHS CISA-nak, amik a WECON PLC Editor 1.3.8-as és korábbi verzióit érintik.

A hibák javításán a gyártó jelenleg is dolgozik. A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-310-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.

Nemrég egy kifejezetten színvonalas cikket (terjedelmi és minőségi okok miatt nem használnám rá a blogposzt kifejezést, szerintem ez az írásmű sokkal több egyszerű blogbejegyzésnél) találtam az otcybersecurity.blog-on.

Szerzője, Sinclair Koelemij 16 különböző DCS és SCADA hálózati architektúrán mutatja be, milyen eltérő hálózatbiztonsági követelményeknek kell megfelelniük a különböző SCADA és DCS rendszereknek különböző környezetekben, ide értve akár az Interneten keresztül távkezelt alállomásokat is.

Nem is szaporítanám tovább a szót, inkább mindenki olvassa el ezt a cikket, akit érdekel az ICS rendszerek határvédelme, különösen, ha éppen ilyen témába vágó feladatot kapott.

Sérülékenység Moxa NPort berendezésekben

A Moxa publikációja szerint egy sérülékenységet találtak az NPort 5100A sorozatú eszközeik 1.5-ös és korábbi firmware-verzióiban.

A gyártó a hibát javító új firmware-verziót már elérhetővé tette. A sérülékenységről további részleteket a Moxa publikációjában lehet találni.

Moxa EDR secure router-ek sérülékenysége

A Moxa bejelentése szerint egy sérülékenységet fedeztek fel az alábbi, EDR sorozatú routereikben:

- EDR-G903 sorozatú eszközök 5.5-ös és korábbi firmware-verziói;
- EDR-G902 sorozatú eszközök 5.5-ös és korábbi firmware-verziói;
- EDR-810 sorozatú eszközök 5.5-ös és korábbi firmware-verziói.

A gyártó a hibát az érintett termékekhez kiadott legújabb firmware-verziójában javította. A sérülékenységgel kapcsolatosan bővebb információkat a Moxa bejelentése tartalmaz.

Sérülékenység Hitachi ABB Power Grids berendezésekben

A Hitachi ABB Power Grids egy sérülékenységet azonosított az alábbi termékeiben:

- XMC20 R4 típusú Multiservice-Multiplexer-ek, amelyek a co5ne_r1h07_12.esw-nél régebbi COGE5 verziót használnak;
- XMC20 R6 típusú Multiservice-Multiplexer-ek, amelyek a co5ne_r2d14_03.esw-nél régebbi COGE5 verziót használnak.

A gyártó a hibát javító újabb firmware-verziókat már elérhetővé tette és kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-294-02

Rockwell Automation berendezések sérülékenységei

Jared Rittle, a Cisco Talos munkatársa három sérülékenységet talált az alábbi Rockwell Automation termékekben:

- 1794-AENT Flex I/O berendezések B sorozatának 4.003 és korábbi verziói.

A hibával kapcsolatosban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-294-01

Sérülékenységek B.Braun rendszerekben

Julian Suleder, Nils Emmerich és Birk Kauer, az ERNW Research GmbH, valamint Dr. Oliver Matula, az ERNW Enno Rey Netzwerke GmbH munkatársai 11 sérülékenységet találtak a B.Braun alábbi termékeiben:

- SpaceCom U61 és korábbi verziói (az USA-ban), L81 és korábbi verziói (az USA-n kívüli piacokon);
- Battery pack with Wi-Fi U61 és korábbi verziói (az USA-ban), L81 és korábbi verziói (az USA-n kívüli piacokon);
- Data module compactplus A10 és A11-es verziói.

A gyártó a hibákat javító újabb verziókat már elérhetővé tette. A sérülékenységekkel kapcsolatos bővebb informácók az ICS-CERT bejelentésében találhatóak: https://us-cert.cisa.gov/ics/advisories/icsma-20-296-02

B.Braun OnlineSuite sérülékenységek

Julian Suleder, Nils Emmerich és Birk Kauer, az ERNW Research GmbH, valamint Dr. Oliver Matula, az ERNW Enno Rey Netzwerke GmbH munkatársai három sérülékenységet fedeztek fel a B.Braun OnlineSuite AP 3.0 és korábbi verzióiban.

A gyártó a hiba javítását már publikálta. A sérülékenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsma-20-296-01

Sérülékenységek SHUN HU rendszerekben

Marco Balduzzi, Philippe Z Lin, Federico Maggi, Jonathan Andersson, Akira Urano, Stephen Hilt és Rainer Vosseler, a ZDI-vel együttműködve 2 sérülékenységről közöltek információkat a DHS CISA-val. A sérülékenységek a SHUN HU alábbi rendszereit érintik:

- JUUKO K-800 és K-808 típusú ipari rádiótávírányító berendezések firmware-verziói, amik a következőknél korábbi számokra végződnek: ...9A, 9B, ...9C, stb.

A gyártó kiadta a hibákat javító firmware-verziókat. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-301-01

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

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

MELSEC iQ-R sorozat:
- R 00/01/02 CPU-k 20-as és korábbi firmware-verziói;
- R 04/08/16/32/120 (EN) CPU-k 52-es és korábbi firmware-verziói;
- R 08/16/32/120 SFCPU-k 22-es és korábbi firmware-verziói;
- R 08/16/32/120 PCPU-k minden firmware-verziója;
- R 08/16/32/120 PSFCPU-k minden firmware-verziója;
- R 16/32/64 MTCPU-k minden firmware-verziója;

MELSEC Q sorozat:
- Q03 UDECPU, Q 04/06/10/13/20/26/50/100 UDEHCPU-k 22081-es és korábbi sorozatszámok;
- Q 03/04/06/13/26 UDVCPU-k 22031-es és korábbi sorozatszámok;
- Q 04/06/13/26 UDPVCPU-k 22031-es és korábbi sorozatszámok;
- Q 172/173 DCPU, Q 172/173 DCPU-S1 minden verziója;
- Q 172/173 DSCPU minden verziója;
- Q 170 MCPU minden verziója;
- Q 170 MSCPU, Q 170 MSCPU（-S1） minden verziója;
- MR-MQ100 minden verziója;

MELSEC L sorozat:
- L 02/06/26 CPU (-P), L 26 CPU - (P) BT minden verziója.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését ajánlja, az elérhető patch-ekről a weboldalán lehet tájékozódni. A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-303-01

Sérülékenységek Mitsubishi MELSEC iQ-R eszközökben

Az ICS-CERT által publikált informáicók szerint 6 sérülékenységet azonosítottak a Mitsubishi Electric MELSEC iQ-R sorozatú eszközeinek alábbi moduljaiban:

- EtherNet/IP Network Interface Module, RJ71EIP91, ha a sorozatszám első két számjegye 02 vagy korábbi;
- PROFINET IO Controller Module, RJ71PN92, ha a sorozatszám első két számjegye 01 vagy korábbi;
- High Speed Data Logger Module, RD81DL96, ha a sorozatszám első két számjegye 08 vagy korábbi;
- MES Interface Module, RD81MES96N, ha a sorozatszám első két számjegye 04 vagy korábbi;
- OPC UA Server Module, RD81OPC96, ha a sorozatszám első két számjegye 04 vagy korábbi.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységekről bővebb információkat a Mitsubishi Electric és az ICS-CERT weboldalain lehet olvasni.

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

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

Még a nyáron futottam bele Sarah Fluchs cikkébe a medium.com-on, amiben a szerző arról ír, hogy a PLC programozás során is meg kell honosítani a biztonságos fejlesztési gyakorlatot.

Ahogy Sarah is ír erről, a PLC programozással foglalkozók az első, tapogatózó biztonsági kérdésekre még nagyon magabiztosan szokták azt válaszolni, hogy ők aztán nem programoznak, de ahogy tovább folyik a beszélgetés, viszonylag gyorsan eljut társalgás oda, hogy PLC-ket azért programoznak és időnként el is bizonytalanodnak, hogy vajon a PLC programozás számít-e?

A válasz egyértelmú igen, de tudomásul kell venni, hogy az IT programozás egészen más környezetben fejlődött azzá, amit ma ismerünk. Lévén az IT hálózatok már hosszú évtizedek óta egyre meghatározóbbak az IT fejlesztők gondolkodását és fejlesztési gyakorlatait illetően, ez pedig azt is magával hozta (kb. a 2000-es évektől egyre gyorsuló ütemben), hogy az IT fejlesztők (akár tetszett nekik, akár nem) szépen lassan hozzászoktak a biztonságos(abb) fejlesztési módszertanok alkalmazásához.

Ezzel szemben a PLC programozás nagyon eltérő prioritások mentén fejlődött azzá, ami ma. A PLC működése során a legfontosabb prioritás (a safety biztosítása mellett) a valós idejű műveletek elvégzésének megbízható garantálása (ez ugye az OT/ICS biztonsági célok közül a másik a safety mellett, amire korábban már hivatkoztunk a CIA-hármason túl, vagyis a reliability). Ráadásul nagyon sokáig (igazából az elmúlt 8-10 évet nem számolva) a PLC-k jellemzően nem vagy nem igazán kommunikáltak IP hálózatokon, az I/O moduljaikon, néhány környező PLC-n és a folyamatirányító rendszereiken kívül mással jellemzően nem volt kapcsolatuk (ez az a történelmi alap, amire az OT/ICS mérnökök mind a mai napig gyakran hivatkoznak, amikor amellett érvelnek, hogy a kiberbiztonsági kérdések miért is nem vonatkoznak az általuk üzemeltetett rendszerekre - épp csak azt felejtik el vagy arról nem tudnak, hogy a rendszereik és berendezéseik egyre inkább részei egy IP hálózatnak, jobb esetben megfelelő logikai szeparáltság mellett, rosszabb esetben a vállalat ügyviteli hálózatából, legrosszabb esetben pedig külső hálózatokból és az Internetről is elérhető módon működnek).

A cikk két hibás feltételezést is megcáfol:

1. A PLC-k esetén nincs szükség biztonságos fejlesztési eljárásokra
2. A PLC programozásra nem lehet alkalmazni a biztonságos fejlesztés eljárásokat

A PLC-k működési sajátosságai adnak néhány olyan pluszt a biztonságos PLC programozáshoz, amire elsőre nem is gondolna az ember. Ezeket és néhány példát is a cikkben lehet megtalálni: https://medium.com/swlh/the-top-20-secure-plc-coding-practices-project-32729f6d4814

Az utóbbi években egyre népszerűbbekké váltak a különböző, kiberbiztonsági podcast-ek és ebből az ICS kiberbiztonság sem tudott kimaradni, így elérkezettnek látom az időt ennek a blogposzt-sorozatnak a beindítására.

Az ICS biztonsági podcast-ek sorozet első részében a FireEye munkatársának, Luke McNamara-nak a felvételét hoztam, aki Nathan Brubaker-rel, a FireEye által felvásárolt Mandiant fenyegetéselemzéssel foglalkozó csoportjának vezetőjével beszélget. A felvétel itt érhető el.

Tegnapi a hír hogy ismét ransomware-támadás érte a világ egyik legnagyobb energetikai cégcsoportját az ENEL-t. Első alkalommal, idén júniusban a Snake/ENAKS zsarolóvírus jutott be az ENEL inormatikai rendszereibe (erről akkor én is írtam), most pedig a hírek szerint a Netwalker ransomware mögött álló csoport követel váltságdíjat a titkosított fájlok visszaállításáért és azért, hogy ne tegyék közzé az ellopott, összesen mintegy 5 TB-nyi, bizalmas információkat tartalmazó fájlokat.

Az egyértelműen látszik, hogy az idei év egyik legjelentősebb kiberbiztonsági kockázatát a zsarolóvírusok jelentik az ipari szervezetek számára is, még ha a legtöbb esetben közvetlenül a folyamatirányító rendszerekre esetenként nincsenek is hatással (a mostani esetben sincs információ arról, hogy ICS rendszereket érintene az incidens, bár kizárni sem lehet ezt a forgatókönyvet). A kérdés már csak az, vajon a hazai ipari szereplők mennyire felkészültek a hasonló incidensekre?

A jelenlegi járványhelyzet az ICS biztonsági konferenciákra is nagyon komolyan rányomja a bélyegét. A héten az éves ICS Cyber Security Conference nevű rendezvényt tartották teljesen virtuális formában, szemben az eddig, tizensok éves hagyományokkal. Eddig szinte minden évben Atlanta volt a konferencia helyszíne.

Figyelembe véve, hogy a virtuális forma alternatívája a konferencia elmaradása volt, így végső soron jó volt ez a virtuális forma (a konferencia keretét adó rendszer szerintem egészen jól sikerült), de azért a hagyományos konferencia szerintem minden szempontból jobb megoldás - amikor ez utóbbira lehetőség nyílik.

A virtuális forma miatt érezhetően kevesebb volt az előadás és a kiállító is, de összességében ez sem volt igazán meglepő. Ami meglepő volt, az (a szintén a hagyományokkal szemben nem az első, hanem az utolsó napon) megrendezett workshop-nap volt. Én ezen a napon az ICS Red Team Blue Team workshop-on vettem részt, ami egy meglepően jó (és hosszú, közel 9 órás) program volt a ThreatGen munkatársainak vezetésével.

Összességében nem volt rossz az idei 4 nap, de azért erősen remélem, hogy jövőre már visszatérhetünk a normális konferenciák világába.

Különösen azért, mert az ICS biztonsági világ egy másik, nyugodtan ikonikusnak nevezhető rendezvénye, az S4X21 konferenciával kapcsolatban épp a napokban jelentette be a szervező Dale Peterson, hogy a járvány miatt 2021. januárban nem fogják megrendezni a floridai South Beach-en.

Allen-Bradley rendszerek sérülékenységei

A Cisco Talos kutatólaborjának munkatársa, Jared Rittle 5 sérülékenységet talált az Allen-Bradley Flex IO 1794-AENT/B 4.003 berendezéseiben.

A gyártó mostanáig nem adott ki javítást a hibákra. A sérülékenységek részleteit három Talos publikációban lehet megtalálni:

https://talosintelligence.com/vulnerability_reports/TALOS-2020-1005
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1006
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1007

Sérülékenység Fieldcomm rendszerekben

Reid Wightman, a Dragos munkatársa egy sérülékenységet fedezett fel a Fieldcomm alábbi rendszereiben:

- HART-IP Developer kit, Release 1.0.0.0;
- hipserver, Release 3.6.1.

A gyártó a hibával kapcsolatban a kockázatcsökkentő intézkedések fontosságát hangsúlyozta. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-04

Flexera rendszerek sérülékenységei

Egy névtelenségbe burkolózó biztonsági kutató egy sérülékenységet azonosított a Flexera InstallShield 2015 SP1-es és korábbi verzióiban, amit számos más gyártó termékeibe építettek be.

A hibával kapcsolatban az érintett termékeket használó ügyfeleknek ajánlott felvenni a kapcsolatot a rendszereik gyártóival, akiktől további információkat kaphatnak a sérülékenységhez kapcsolódó teendőkről. A sérülékenység részleteiről az ICS-CERT weboldalán lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-03

Sérülékenység LCDS rendszerekben

Egy névtelen biztonsági kutató, a ZDI-vel együttműködve egy sérülékenységről közölt információkat a DHS CISA-val, ami az LCDS (Leão Consultoria e Desenvolvimento de Sistemas Ltda ME) SCADA rendszerének 4.3.1.870-esnél korábbi verzióit érinti.

A gyártó a hibát a 4.3.1.870 és újabb verziókban javította. A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT publikációjában lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-02

Moxa NPort berendezések sérülékenységei

Evgeniy Druzhinin és Ilya Karpov, a Rostelecom-Solar munkatársai 6 sérülékenységet találtak a Moxa NPort IAW5000A-I/O típusú berendezéseinek 2.1-es és korábbi firmware-verzióiban.

A gyártó a hibákat a legújabb firmware-verzióban javította. A sérülékenységekről bővebb információkat az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-01

Sérülékenység Advantech WebAccess/SCADA rendszerekben

Sivathmican Sivakumaran, a Trend Micro ZDI munkatársa egy sérülékenységet fedezett fel az Advantech WebAccess/SCADA 9.0 és korábbi verzióiban.

A gyártó a hibát a 9.0.1-es és későbbi verziókban javította. A sérülékenység részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-289-01

Advantech R-SeeNet rendszerek sérülékenysége

rgod, a ZDI-vel együttműködve egy sérülékenységről közölt részleteket a DHS CISA-val, ami az Advantech R-SeeNet nevű megoldásának 1.5.1-től 2.4.10-ig terjedő verzióit érinti.

A gyártó a hibát az R-SeeNet 2.4.11-es és későbbi verzióiban javította. A sérülékenységgel kapcsolatos további információkat az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-289-02

Sérülékenységek Siemens SIPORT MP rendszerekben

A Siemens ProductCERT egy sérülékenységet jelentett a DHS CISA-nak a SIPORT MP nevű termékük 3.2.1-nél korábbi verzióival kapcsolatban.

A gyártó a hibát a 3.2.1-es verzióban javította. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens Desigo Insight sérülékenységek

Davide De Rubeis, Damiano Proietti, Matteo Brutti, Stefano Scipioni és Massimiliano Brolli, a TIM Security Red Team Research munkatársai 3 sérülékenységet találtak a Siemens Desigo Insight nevű termékében. A sérülékenységek a Desigo Insight minden verzióját érintik.

A gyártó a hibákat a 6.0 SP5 Hotfix 2 és későbbi verziókban javította. A sérülékenységekről részletesebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

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

Michiel Evers és Niels Pirotte három sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- EcoStruxure™ Power Monitoring Expert 9.0, 8.x és 7.x verziói;
- EcoStruxure™ Energy Expert 2.0;
- Power Manager 1.1, 1.2 és 1.3 verziói;
- StruxureWare™ PowerSCADA Expert with Advanced Reporting and Dashboards Module 8.x;
- EcoStruxure™ Power SCADA Operation with Advanced Reporting and Dashboards Module 9.0.

A sérülékenységek javításával kapcsolatos és egyéb további információkat a Schneider Electric weboldalán lehet megtalálni.

Schneider Electric termékek sérülékenysége

A Schneider Electric publikációja alapján egy sérülékenységet azonosítottak az alábbi termékeikben:

- Acti9 Smartlink SI D minden, 002.004.002-nél korábbi verziója;
- Acti9 Smartlink SI B minden, 002.004.002-nél korábbi verziója;
- Acti9 PowerTag Link / Link HD minden, 001.008.007-nél korábbi verziója;
- Acti9 Smartlink EL B minden, 1.2.1-nél korábbi verziója;
- Wiser Link minden, 1.5.0-nál korábbi verziója;
- Wiser Energy minden, 1.5.0-nál korábbi verziója.

A gyártó a hibát az érintett termékek legújabb verzióiban javította. A sérülékenységről bővebben a Schneider Electric publikációjában lehet olvasni.

Schneider Electric rendszereket is érint a Wibu-Systems CodeMeter sérülékenység

Néhány hete én is beszámoltam a Wibu-Systems CodeMeter licenc menedzser termékében talált sérülékenységekről. Ehhez kapcsolódik a Schneider Electric egyik új bejelentése, amely szerint az alábbi termékeiket is érintik az akkor talált sérülékenységek:

- EcoStruxure Machine Expert minden verziója;
- E+PLC400 minden verziója;
- E+PLC100 minden verziója;
- E+PLC_Setup minden verziója;
- EcoStruxure Machine SCADA Expert minden verziója.

A hiba javításáig a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebb információkat a Schneider Electric bejelentése tartalmaz.

Schneider Electric Modicon berendezések sérülékenysége

Yang Dong, a DingXiang Dongjian Security Lab munkatársa egy sérülékenységet talált a Schneider Electric Modicon termékcsaládjának alábbi tagjaiban:

- az M340 CPU-k BMX P34x modelljeinek 3.20-as firmware-verziója;
- az M340 Ethernet kommunikációs modulok alábbi modelljei:
   - BMX NOE 0100 (H) 3.3-asnál korábbi verziói;
   - BMX NOE 0110 (H) 6.5-ösnél korábbi verziói;
   - BMX NOC 0401 2.10-esnél korábbi verziói;
- Premium processorok integrált Ethernet COPRO-val:
   - TSXP574634, TSXP575634 és TSXP576634 modelljeinek 6.1-es verziója;
- a Premium kommunikációs modulok:
   - TSXETY4103 modell 6.2-esnél korábbi verziói;
   - TSXETY5103 modell 6.4-esnél korábbi verziói;
- Quantum processorok integrált Ethernet COPRO-val:
   - 140CPU65xxxxx modell 6.1-esnél korábbi verziói;
- Quantum kommunikációs modulok:
   - 140NOE771x1 modell 7.1-esnél korábbi verziói;
   - 140NOC78x00 modell 1.74-esnél korábbi verziói;
   - 140NOC77101 modell 1.08-asnál korábbi verziói.

A gyártó a sérülékenységet az érintett termékekhez kiadott újabb verziókban javította. A sérülékenységgel kapcsolatosan részleteket a Schneider Electric weboldalán lehet találni.

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.

Március végén, amikor a COViD-19 első hulláma már teljes komolyságával (bár korántsem olyan statisztikákat produkálva, mint most, szinte napra pontosan 6 hónappal később) sokkolta a világot, írtam arról, hogy a járvány milyen hatással lehet az ICS rendszerek kiberbiztonságára.

Az elmúlt fél évben történt incidensek nagyjából beigazolták a várakozásokat, erről jelent meg nyár végén egy felmérés a Claroty-tól (regisztráció után itt érhető el).

A felmérésben a Claroty munkatársai vizsgálták a 2020. első félévében publikált ICS sérülékenységek számát (az NVD adatbázisa alapján), ezek a statisztikák azt mutatják, hogy az egy évvel korábbi azonos időszakhoz képest 2020 első felében több, mint 10%-kal magasabb volt a publikált sérülékenységek száma és ezek több, mint 75%-a súlyos vagy kritikus besorolást kapott. A felmérésben elérhető további statisztikák is az ICS sérülékenységek számának folyamatos emelkedését mutatják.

Ami azonban talán még fontosabb kérdés, hogy vajon a tavaszi első hullám esetén rohamtempóban bevezetett tömeges távoli/otthoni munkavégzés megteremtése során "ideiglenesen" áthágott/félresöpört biztonsági szabályokat azóta a cégek hány százalékat állította helyre - vagy legalább kezdett hozzá a normális időszakban elvárt biztonsági szint visszaállításához?

Tartok tőle, hogy a jövőben számos olyan incidensről fogunk hallani, aminek egyik kiváltó oka a járvány miatt félretett biztonsági megfontolásokból eredt.

Sérülékenységek Pepperl+Fuchs rendszerekben

T. Weber, a SEC Consult Vulnerability Lab munkatársa a CERT@VDE-vel együttműködve három sérülékenységet jelentett a Pepperl+Fuchs-nak, amik a gyártó alábbi rendszereit érintik:

P+F Comtrol RocketLinx termékcsalád
- ICRL-M-8RJ45/4SFP-G-DIN berendezéseinek 1.2.3 és korábbi firmware-verziói;
- ICRL-M-16RJ45/4CP-G-DIN berendezéseinek 1.2.3 és korábbi firmware-verziói.

A gyártó a hibákkal kapcsolatban firmware-frissítést és kockázatcsökkentő intézkedésekre vonatkozó ajánlásokat tett közzé. A sérülékenységekről további információkat a Pepperl+Fuchs publikációja tartalmaz.

Mitsubishi Electric MELSEC rendszerek sérülékenysége

Yossi Reuven, a SCADAfence munkatársa egy sérülékenységet fedezett fel a Mitsubishi Electric MELSEC iQ-R sorozatú eszközeinek alábbi moduljaiban:

- R00/01/02CPU minden verziója;
- R04/08/16/32/120(EN)CPU minden verziója;
- R08/16/32/120SFCPU minden verziója;
- R08/16/32/120PCPU minden verziója;
- R16/32/64MTCPU minden verziója.

A gyártó tervei szerint az elkövetkező hónapokban megjelenő új verzióban fogja javítani a hibát, addig is kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatos részleteket az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-282-02

Sérülékenység Sensormatic Electronics rendszerekben

Joachim Kerschbaumer egy sérülékenységet jelentett a Johnson Controls-nak, a Sensormatic Electronics anyavállalatának, ami a Sensormatic Electronics American Dynamics victor Web Client nevű termékének v5.4.1 és korábbi verzióit érinti.

A gyártó a hibát az 5.6-os verzióban javította. A sérülékenység részleteit az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-282-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.