Az IBM X-Force szakértői egy új, a célbavett számítógépeken tárolt adatok törlésére specializált malware támadásainak nyomait fedezték fel a Közel-Keleten. A ZeroCleare névre keresztelt malware az X-Force szerint elsősorban a régió energia szektorában működő illetve más ipari szervezeteket támadja, arról azonban egyelőre nincs hír, hogy az incidensek érintettek volna ICS rendszereket.

Az X-Force kutatói a malware elemzése alapján arra a következtetésre jutottak, hogy a mostani kártevő sok szempontból hasonlít a korábbi években megismert Shamoon malware-re, emiatt pedig azt feltételezik, hogy a ZeroCleare támadások mögött is Irán állhat. Ezt az elméletet erősíti a ZeroCleare által a fájlok törlésére használt EldoS RawDisk is, amit már a Shamoon-támadásoknál is használtak a malware fejlesztői.

Egyelőre sokkal több információ nem érhető el, az X-Force cikke a ZeroCleare malware-ről eddig publikált részletekkel az IBM SecurityIntelligence weboldalán, a teljes elemzés pedig itt található.

ABB Relion 670 sorozatú eszközök sérülékenysége

Kirill Nesterov, a Kaspersky Lab munkatársa egy sérülékenységet talált az ABB Relion 670 sorozatú eszközök alábbi verzióiban:

- Relion 670 sorozat 1p1r26 és korábbi verziói;
- Relion 670 sorozat 1.2.3.17 és korábbi verziói;
- Relion 670 sorozat 2.0.0.10 és korábbi (RES670 2.0.0.4 és korábbi) verziói;
- Relion 670 sorozat 2.1.0.1 és korábbi verziói.

A gyártó a hibát az érintett eszközök legújabb verzióiban javította. A sérülékenységről további részleteket az ICS-CERT bejelentésében lehet találni: https://www.us-cert.gov/ics/advisories/icsa-19-330-01

Sérülékenység ABB Relion berendezésekben

lya Karpov, Evgeniy Druzhinin és Victor Nikitin, a ScadaX munkatársai egy sérülékenységet azonosítottak az ABB alábbi termékeiben:

- Relion 650 sorozat 1.3.0.5 és korábbi verziói;
- Relion 670 sorozat 1.2.3.18 és korábbi verziói;
- Relion 670 sorozat 2.0.0.11 és korábbi verziói;
- Relion 670 sorozat 2.1.0.1 és korábbi verziói.

A gyártó a hibát a legújabb verziókban javította. A sérülékenységgel kapcsolatban részletesebb információkat az ICS-CERT publikációjában lehet olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-330-02

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

A gyártó által nyilvánosságra hozott információk szerint 10 sérülékenységet találtak az AWK-3121 sorozatú, ipari környezetekbe szánt hálózati eszközök 1.14-es és korábbi firmware-verzióiban.

A gyártó az érintett eszközök támogatását már megszüntete, így a sérülékenységekkel kapcsolatban csak kockázatcsökkentő intézkedések alkalmazására nyílik mód. A sérülékenységekről további részleteket a Moxa 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.

Az APT33 névre keresztelt támadói csoport (őket nevezi a Dragos Magnallium-nak) a 2012-es Shamoon (más néven Disttrack) malware támadásai óta ismert. A támadók elsősorban olajipari és repülőgép-gyártásban érdekelt vállalatokat vett célba, többnyire a Perzsa- (Arab-) Öbölben, Dél-Koreában és az USA-ban. Korábban voltak olyan elemzők, akik úgy gondolták, a Magnallium/APT33 csoport jelentős fenyegetést képvisel a kritikus infrastruktúrák ellen, de az elmúlt néhány évben tapasztalt tevékenységeik elemzése alapján a Dragos munkatársai szerint a csoport inkább információszerzésre koncentrál és feltételezhetően nincsenek kifejezetten ICS rendszerek ellen fejlesztett képességeik.

A Magnallium/APT33 csoport jellemzően célzott adathalász támadásokkal probál kezdeti hozzáférést szerezni a célba vett szervezetek informatikai rendszereihez, ezen felül előszeretettel használják a különböző biztonsági cégek által Stonedrill, Tunedup, Shapeshift, Dropshot, Nanocore és Netwire névre keresztelt malware-eket is.

Bár a csoport az utóbbi időben a támadások kezdeti szakaszában folytatott információszerzést végezte és a célba vett vállalatok rendszereihez próbálnak tartósan hozzáféréseket szerezni, az elemzők szerint ezek lehetnek előkészítő lépések egy, az ICS rendszerek elleni későbbi támadáshoz is.

A Magnallium/APT33 csoportról a Dragos és a FireEye elemzéseiben lehet további részleteket találni.

Néhány héttel ezelőtt én is írtam arról, hogy iráni illetékesek szerint kibertámadás érte az iráni olajipar egyik legfontosabb létesítményét. Már abban a posztban is írtam arról, hogy indokolt egyre óvatosabban kezelni azokat a kijelentéseket, amik egy-egy ipari baleset vagy safety incidens után nagyon gyorsan kibertámadás neveznek meg vagy sejtetnek, mint kiváltó okot anélkül, hogy erre vonakozóan konkrét bizonyítékokat ismertetnének. Ezt erősítette meg Robert M. Lee október 20-án publikált posztja is (elérhető a Dragos weboldalán és Robert saját blogján is), amiben nem először ír arról, hogy bár az ipari szereplőket és ICS rendszereket támadó csoportok egyre agresszívebbek és egyre gyakrabban céljuk bizonyíthatóan a fizikai károkozás (elég csak a Trition/TriSIS malware-támadásra vagy a Industroyer/CrashOverride malware-ről nemrég publikált újabb elemzés következtetéseire gondolni), helytelennek tartja, hogy egy incidens után az első reakció az, hogy az illetékesek kibertámadásra hivatkoznak kiváltó okként. A konkrét esetről ma még csak annyit lehet tudni, hogy az olajfinomító egyik csatornájában, ahol a finomítás során keletkező hulladékanyagokat vezették el, tűz ütött ki.

Robert fontosnak tartja kiemelni, hogy a legtöbb ICS rendszereket üzemeltető szervezetnek (ide értve feltehetően az abadani olajfinomítót is) jelenleg nem állnak rendelkezésére azok a képességek és az a képzett és tapasztalt ICS biztonsági csapat, akikkel egy hasonló kategóriájú incidens esetén a fizikai következmények felszámolása során már egy alapos <<root-cause analysis>>-t tudjanak végrehajtani, amelynek során képesek alaposan átvizsgálni az érintett ICS rendszereket bármilyen, illegális vagy helytelen (hiszen nem szabad elfelejteni, a legtöbb ICS biztonsági incidens mind a mai napig nem ellenséges szándékú támadók, hanem jó szándékú és valamilyen legitim hozzáféréssel rendelkező ember tevékenységének a következménye) módosítás nyomait.

Ahhoz, hogy az ICS rendszerek és eszközök biztonsági szintjén javítani lehessen, korántsem elegendő a döntéshozók és a társadalom figyelmét ráirányítani a valóban létező problémára (arról nem is beszélve, hogy mennyire kontraproduktívnak tartom, hogy minden ICS rendszerrel kapcsolatos incidenst azonnal és gondolkodás nélkül kibertámadásra visszavezetni nagyjából annyira szolgálja az ipari szektorban működő szervezetek és a kritikus infrastruktúrák érdekeit, mint amennyire a mesebeli fiúnak érdemes volt rendszeresen farkast kiálltani), de mindenképp olyan intézkedéseket kell javasolni, amikkel jelentősen lehet javítani az ICS rendszerek biztonsági helyzetét. Néhány ilyen intézkedés lehet:

- Az ipari szektorban működő szervezetek kockázatainak felmérése és értékelése, a magasnak ítélt kockázatokra vonatkozóan kockázatcsökkentő intézkedések alkalmazása. Itt fontosnak tartom megemlíteni, hogy ma még az ipari szektorban sem sok helyen sikerült elmozdulni a fizikai eszközök és az adatok számszerűsített értékén alapuló kockázatelemzési megközelítéstől, pedig figyelembe véve, hogy az ICS rendszereket és berendezéseket használó szervezetek számára szinte kivétel nélkül az egyik legfontosabb érték az ICS rendszerekkel vezérelt folyamatok biztonságának (safety), megbízhatóságának és rendelkezésre állásának biztosítása, ezért úgy gondolom, hogy legalább is megfontolásra érdemes lehet egy másfajta, a fizikai folyamatokkal kapcsolatos elvárások irányából közelítő kockázatelemzési módszertan alkalmazása. Ezzel nyilván nem azt állítom, hogy az adatok nem fontosak, de mérlegelni kell, hogy egyes adatkörök fontossága hogyan viszonyul a felügyelt folyamatok különböző szempontok alapján értékelt fontosságához.

- ICS eszközleltár: A vállalati IT biztonság terén már igen régóta számos szabvány írja elő a napra kész eszközleltár vezetését. ICS környezetekben egy ilyen nyilvántartás kialakítása talán nehezebb lehet (hiszen fontos eszközök lehetnek távoli, akár személyzettel nem is rendelkező telephelyeken), azonban az ICS rendszerek már többször is említett statikussága ebben az esetben kifejezetten előnyt jelent.

- ICS rendszerek szeparálása publikus/külső hálózatoktól: Lassan már unalomig ismételt alapszabály, hogy ICS rendszerekhez ne engedjünk hozzáférést publikus hálózatokról (pl. Internet) vagy olyan külső hálózati zónákból, ami nem áll teljes mértékben az ellenőrzésünk alatt. Amennyiben nem lehet teljes mértékben elkülöníteni a külső hálózatokat az ICS rendszerektől (pl. mert külső szakértőknek is hozzáférést kell biztosítani a rendszer bizonyos részeihez, akkor használjuk a Purdue-modellt vagy annak valamelyik modernizált változatát.

- A rendszerek és kommunikációjuk átláthatóságának megteremtése: biztosítani kell azt, hogy az (ICS) kiberbiztonsággal foglalkozó szakemberek minél teljesebb képpel rendelkezzenek arról, mi is történik a hálózatokban és rendszerekben. Ennek leginkább hatékony módszere (a korábban már említett pontos és naprakész eszközleltáron túl) a folyamatos, 7/24-es hálózatbiztonsági monitoring tevékenység magas szintre fejlesztése.

Miközben ezt a posztot írtam, jöttek a hírek arról, hogy ransomware-támadás érte a Pemex nevű mexikói állami olajtársaságot. Bár a Pemex nem szolgált részletekkel (mindössze annyit közöltek, hogy az incidens nem érintette a termelésirányításért felelős rendszereiket), de egyes biztonsági kutatók nem megerősített hírei szerint az incidensért a DoppelPaymer ransomware a felelős. Egyes elemzések szerint a DoppelPaymer mögött ugyanaz a támadói csoport állhat, akik a Dridex és Locky ransomware-támadásokért is felelősek lehetnek.

Ahogy közeledünk az év végéhez, lassan megállapíthatjuk, hogy 2019 az ipari szervezetek (és az állami és önkormányzati szervek) elleni ransomware-támadások éve és nem sok jele van annak, hogy a helyzet 2020-ban javulna - valószínűleg inkább csak romlani fog. Azt hiszem éppen ideje mindenkinek feltenni magának a kérdést: fel vagyunk készülve hasonló incidensekre, mint amivel a Norsk Hydro-nak vagy a Johannesburg-i áramszolgáltatónak kellett megküzdenie?

Sérülékenység ABB rendszerekben

Rikard Bodforss, a Bodforss Consulting munkatársa (és a név alapján tulajdonosa) egy sérülékenységet fedezett fel az ABB alábbi rendszereiben:

- Power Generation Information Manager (PGIM) minden verziója;
- Plant Connect minden verziója.

A SecurityWeek cikke szerint a sérülékenységről a gyártó már 5 éve tudott, de nem javította azt és a jelek szerint már nem is fogja, mivel a Plant Connect gyártói támogatása már megszűnt és a PGIM életciklusa is a végéhez fog érni. A sérülékenység részleteiről az ICS-CERT publikációjában lehet bővebben olvasni: https://www.us-cert.gov/ics/advisories/icsa-19-318-05

Omron CX-Supervisor sérülékenység

Michael DePlante a ZDI-vel együttműködve egy sérülékenységet talált az Omron CX-Supervisor 3.5 (12) és korábbi verzióiban.

A gyártó a hibát a 3.51 (9)-es verzióban javította. A sérülékenység részletei az ICS-CERT bejelentésében találhatóak: https://www.us-cert.gov/ics/advisories/icsa-19-318-04

Sérülékenység Siemens Desigo PX vezérlőkben

Gjoko “LiquidWorm” Krstic, a Zero Science Lab munkatársa egy sérülékenységet azonosított, ami az alábbi Siemens termékeket érinti:

- PXC00-E.D, PXC50-E.D, PXC100-E.D és PXC200-E.D Desigo PX vezérlők PXA40-W0, PXA40-W1 és PXA40-W2 web modullal működő példányai, amennyiben V6.00.320-nál korábbi firmware-verziót használnak;
- PXC00-U, PXC64-U és PXC128-U Desigo PX vezérlők, ha a PXA30-W0, PXA30-W1, PXA30-W2 web modult használják és a V6.00.320-nál korábbi firmware-verziót futtatják;
- PXC22.1-E.D, PXC36-E.D és PXC36.1-E.D modellek aktivált web szerver esetén, ha a a V6.00.320-nál korábbi firmware-verziót használják.

A gyártó a hibát a V6.00.320-as és újabb firmware-verziókban javította. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens S7-1200 CPU-k sérülékenysége

Ali Abbasi, a bochum-i Ruhr Egyetem munkatársa egy sérülékenységet talált a Siemens S7-1200-as eszközeiben, ami minden firmware-verziót érint.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenység Siemens Nucleus rendszerekben

Az Armis Security munkatársai egy sérülékenységet jelentettek a Siemens-nek, ami az alábbi rendszereiket érinti:

- Nucleus NET minden verziója;
- Nucleus RTOS minden verziója;
- Nucleus ReadyStart ARM, MIPS és PPC processzorokhoz kiadott változatainak minden, v2017.02.2 “Nucleus 2017.02.02 Nucleus NET Patch” hibajavításnál korábbi verziója;
- Nucleus SafetyCert minden verziója;
- Nucleus Source Code minden verziója;
- VSTAR minden verziója.

A gyártó a Nucleus ReadyStart ARM, MIPS és PPC processzorokhoz adott ki javítást, a többi érintett termék esetében kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Philips Intellitech orvostechnikai eszközök sérülékenysége

A New York-i Presbiteriánus Kórház Medical Technology Solutions csoportja egy sérülékenységet fedezett fel a Philips alábbi rendszereiben:

- IntelliBridge EC40 Hub minden verziója;
- IntelliBridge EC80 Hub minden verziója.

A gyártó a hiba javítását 2020 harmadik negyedév végére ígéri. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://www.us-cert.gov/ics/advisories/icsma-19-318-01

Sérülékenységek Flexera rendszerekben

Sergey Temnikov, a Kaspersky munkatársa 4 sérülékenységet talált a Flexera alábbi rendszereiben:

- FlexNet Publisher 2018 R3 és korábbi verziói.

A gyártó a hibákat a FlexNet Publisher 2018 R4 és újabb verzióiban javította. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet elérni: https://www.us-cert.gov/ics/advisories/icsa-19-323-01

Sérülékenység Schneider Electric Andover Continuum vezérlőkben

Ken Pyle a DFDR Consulting munkatársa egy sérülékenységről közölt információkat a Schneider Electric-kel, ami az Andover Continuum termékcsalád alábbi vezérlőit érinti:

- 9680;
- 5740;
- 5720;
- bCX4040;
- bCX9640;
- 9900;
- 9940;
- 9924;
- 9702.

Az érintett termékek támogatását a gyártó már megszűntette, ezért a hibával kapcsolatban csak kockázatcsökkentő intézkedésekre vonatkozó javasolatokat adott ki. A sérülékenységről bővebb információkat a Schneider Electric weboldalán lehet találni.

Schneider Electric Modicon vezérlők sérülékenysége

A Schneider Electric bejelentése szerint egy sérülékenységet azonosítottak az alábbi termékeik minden verziójában:

- M340 BMX P34x CPU-k
- M340 kommunikációs modulok:
- BMX NOE 0100
- BMX NOE 0110
- BMX NOC 0401
- TSX P57x Premium CPU-k
- TSX ETY x103 Premium kommunikációs modulok:
- 140 CPU6x Quantum CPU-k
- Quantum kommunikációs modulok:
- 140 NOE 771x1
- 140 NOC 78x00
- 140 NOC 77101

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenység részleteit a Schneider Electric bejelentésében lehet megtalá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.

A 2017-es WannaCry- és NotPetya-támadások, majd az idén tavaszi Norsk Hydro elleni LockerGoga-támadás után október elején a Pilz nevű német, automatizálási eszközöket gyártó vállalatot érte ransomware támadás. A hírek szerint az incidensért a BitPaymer ransomware a felelős, ami a vállalat minden szerverét és munkaállomását, ide értve a cég kommunikációját is, érintette. A Pilz-nek világszerte 76 országban vannak telephelyei, amik a hírek szerint mind érintettek az incidensben, aminek következtében nem csak a vállalati levelezőrendszer esett ki (legalább három napra), hanem megrendelésekért és kiszállításokért felelős rendszerek is több, mint egy héten át nem voltak elérhetőek. A gyártásirányításért felelős rendszereket a hírek szerint az incidens nem érintette, de így is jelentős késések keletkeztek a gyártási folyamatokban.

Egyes források szerint (tőlük származik az információ, amely szerint a támadók a BitPaymer ransomware-t használták) a ransomware által hagyott üzenet alapján kijelenthető, hogy a támadás célzottan a Pilz ellen lett előkészítve.

Az incidenssel kapcsolatban a legfrissebb híreket a Pilz weboldalán lehet megtalálni (német nyelven).

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.