Sérülékenységek Delta rendszerekben

Natnael Samson és egy névtelenségbe burkolózó biztonsági kutató a ZDI-vel együttműködve 3 sérülékenységről publikáltak részleteket, amik a Delta Industrial Automation CNCSoft ScreenEditor termékének 1.00.88-as és korábbi verzióit érinti.

A gyártó a hibákat az 1.00.89-es verzióban javította. A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-106-01

Sérülékenység WAGO PLC-kben

Jörn Schneeweisz, a Recurity Labs munkatársa egy, a PLC-kbe beégetett authentikációs adatokból adodó sérülékenységet azonosított a WAGO alábbi PLC-iben:

- 750-88x sorozatú eszközök:
  - 750-330 FW14-nél korábbi firmware-verziói;
  - 750-352 FW14-nél korábbi firmware-verziói;
  - 750-829 FW14-nél korábbi firmware-verziói;
  - 750-831 FW14-nél korábbi firmware-verziói;
  - 750-852 FW14-nél korábbi firmware-verziói;
  - 750-880 FW14-nél korábbi firmware-verziói;
  - 750-881 FW14-nél korábbi firmware-verziói;
  - 750-882 FW14-nél korábbi firmware-verziói;
  - 750-884 FW14-nél korábbi firmware-verziói;
  - 750-885 FW14-nél korábbi firmware-verziói;
  - 750-889 FW14-nél korábbi firmware-verziói;
- 750-87x sorozatú eszközök:
  - 750-830 FW06-nál korábbi firmware-verziói;
  - 750-849 FW08-nál korábbi firmware-verziói;
  - 750-871 FW11-nél korábbi firmware-verziói;
  - 750-872 FW07-nél korábbi firmware-verziói;
  - 750-873 FW07-nél korábbi firmware-verziói.

A gyártó a hibát az érintett eszközökhöz kiadott legújabb firmware-verzióban javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-106-02

Sérülékenység különböző gyártók PLC-iben

Matthias Niedermaier és Florian Fischer, az Augsburg-i Főiskola valamint Jan-Ole Malchow, a Berlini Szabadegyetem munkatársai egy olyan sérülékenységet azonosítottak, ami több gyártó PLC-it és érinti:

ABB:
- ABB 1SAP120600R0071 PM554-TP-ETH;

Phoenix Contact:
- Phoenix Contact 2700974 ILC 151 ETH;

Schneider Electric:
- Schneider Modicon M221;

Siemens:
- Siemens 6ES7211-1AE40-0XB0 Simatic S7-1211;
- Siemens 6ES7314-6EH04-0AB0 Simatic S7-314;
- Siemens 6ED1052-1CC01-0BA8 Logo! 8;

WAGO:
- WAGO 750-889 Controller KNX IP;
- WAGO 750-8100 Controller PFC100;
- WAGO 750-880 Controller ETH;
- WAGO 750-831 Controller BACnet/IP.

A sérülékenységgel kapcsolatban az egyes gyártók javítást illetve helyes konfigurációs beállításokra/kockázatcsökkentő intézkedésekre vonatkozó tanácsokat adtak ki. A sérülékenységről az ICS-CERT weboldalán lehet bővebben olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-106-03

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.

Tegnap este egy nagyon érdekes, alig 3 és fél perces videót találtam arról, hogy a Norsk Hydro Toulouse-i üzemében hogyan oldották meg a helyi munkatársak a manuális működést, miután a LockerGoga-támadás nyomán elvesztették a teljesen automatizált gyár integrált rendszereit. A videót itt lehet megnézni: https://www.youtube.com/watch?v=o6eEN0mUakM

A film nyomán két gondolat fogalmazódott meg bennem (nem először):

1. Elismerésre méltó (és egyáltalán nem szokványos), amilyen nyíltan és transzparens módon áll a Norsk Hydro az esethez, ezzel lehetőséget adva nagyjából bárkinek az ipari szektorban működő szervezetek közül, hogy tanuljanak, tanuljunk ebből az incidensből.

2. Ez az eset megint nagyon jól rávilágít arra, hogy az ICS rendszerek világában az BCP/DRP terveket nem elég megírni és a megfelelőségi követelményeket szem előtt tartva rendszeresen frissíteni, még csak az sem elég, ha rendszeresen és alaposan begyakoroltatjuk az érintett kollégákkal a feladataikat, de legalább ilyen fontos a helyettesítő (sok esetben bizony manuális) eljárások kidolgozása.

Bízom benne, hogy ezt a videót sok hazai szakember fogja látni és elgondolkodnak a fenti felvetéseimen.

Nemrég egy igen érdekes blog poszt jelent meg a Tripwire oldalán, amiben a szerző az elmúlt közel 9 év ICS biztonsági incidensei alapján próbálja meg bemutatni azokat a támadási vektorokat, amik alapján jellemzően az ipari létesítményeket támadják és próbál néhány általános biztonsági intézkedést felsorolni, amivel javítani lehet a támadások megelőzésének vagy észlelésének esélyeit.

A posztban két hasznos tanács is található. Az egyik, hogy mire kell az ICS üzemeltetőknek és ICS biztonsági szakembereknek figyelni, ha minél előbb észlelni akarnak egy támadási kísérletet:

- Abnormális hálózati események (pl. a szokásosnál több VPN-kapcsolat kezdeményezése nem megszokott földrajzi helyekről, nem a megszokott napszakokban)
- Fenyegetések (Command&Control szerverek felé tartó hálózati forgalom, malware-fertőzött mérnöki munkaállomások, stb.)

A blog poszt felsorolja a 2015-ös ukrán incidens után született Energy ISAC elemzést (Defense Use Case 5) ajánlásait:

1. Hálózat szegmentálás az ipari és vállalati hálózatok, a vezérlőközponti és alállomási hálózatok illetve az alállomáson belül és az alállomások között
2. Naplózás megvalósítása nem csak az IT komponenseken, hanem lehetőség szerint a különböző alállomási automatizálási berendezésekben is (ezek többsége ma már valamilyen beágyazott Linux vagy Windows rendszer, amik gyakran képesek legalább alapszintű syslog/Event log használatra)
3. A menedzselhető switch-ek port-tükrözésének és naplózási képességeinek a védelmi intézkedések szolgálatába állítása
4. A sérülékenységek priorizálása és patch-elése (illetve ha a belső kockázatelemzés szerint a rendelkezésre álló patch valamilyen ok miatt nem telepíthető, akkor egyéb kockázatcsökkentő intézkedések alkalmazása)
5. A folyamatvezérlés szempontjából értékes rendszerek és rendszerelemek (pl. SCADA szerverek, mérnöki munkállomások, HMI-ok, stb.) mélyebb monitoringja (pl. rendszeres fájl-integritás ellenőrzések futtatása és a változások vizsgálata)

Ezek az ajánlások, bár nem fogják a támadások 100%-át megakadályozni és időnként biztos, hogy kényelmetlenebbé és lassabbá tehetik a védendő rendszerek üzemeltetését, abban jelentős segítséget nyújthatnak, hogy a jövőbeni támadásokat minél előbb észre lehessen venni és ezek egy részét talán még az előtt meg lehet akadályozni, hogy olyan üzemzavarokat okoznának, mint a WannaCry vagy a NotPetya tették (úgy, hogy azokat a malware-eket nem is célzottan ipari létesítmények elleni támadásokhoz hozták létre).

Siemens SIMOCODE rendszerek sérülékenysége

A Siemens ProductCERT egy szolgáltatás-megtagadás támadást lehetővé tevő sérülékenységet jelentett az NCCIC-nek, ami az alábbi termékeit érinti:

- SIMOCODE pro V EIP minden, v1.0.2-nél korábbi verziója.

A gyártó a hibát a szoftver v1.0.2-es verziójában javította. A sérülékenységről további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenység Siemens Spectrum Power rendszerekben

Az Appliend Risk kutatói egy távoli kódfuttatást lehetővé tevő sérülékenységet jelentettek a Siemens-nek, ami a Spectrum Power 4 Web Office Portal funkcióval ellátott telepítéseit érinti.

A gyártó a hibára kiadta a javítást. A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

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

A Siemens ProductCERT egy számos termékét érintő hibáról tájékoztatta az NCCIC-t. Az érintett termékek:

- SIMATIC CP443-1 OPC UA minden verziója;
- SIMATIC ET200 Open Controller CPU 1515SP PC2 minden verziója;
- SIMATIC IPC DiagMonitor minden verziója;
- SIMATIC NET PC Software minden verziója;
- SIMATIC RF188C minden verziója;
- SIMATIC RF600R minden verziója;
- SIMATIC S7-1500 CPU termékcsalád v2.5 és korábbi verziói;
- SIMATIC S7-1500 szoftvere vezérlők v2.5 és korábbi verziói;
- SIMATIC WinCC OA minden, v3.15-P018-nál korábbi verzió;
- SIMATIC WinCC Runtime Advanced minden verziója;
- SIMATIC WinCC Runtime Comfort minden verziója;
- SIMATIC WinCC Runtime HSP Comfort minden verziója;
- SIMATIC WinCC Runtime Mobile minden verziója;
- SINEC-NMS minden verziója;
- SINEMA Server minden verziója;
- SINUMERIK OPC UA Server minden, v2.1-nél korábbi verziója;
- TeleControl Server Basic minden verziója.

A gyártó mostanáig az alábbi termékekhez adott ki javítást a hibával kapcsolatban:

- SIMATIC WinCC OA;
- SINUMERIK OPC UA Server.

A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

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

A Siemens ProductCERT négy sérülékenységet jelentett az NCCIC-nek az alábbi SINEMA rendszerekkel kapcsolatban:

- SINEMA Remote Connect Client minden, v2.0 HF1-nél korábbi verzió;
- SINEMA Remote Connect Server minden, v2.0-nál korábbi verzió.

A gyártó az érintett termékek legújabb verziójában javította a hibákat. A sérülékenységekkel kapcsolatban bővebb információt a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

RuggedCom eszközök sérülékenysége

A Siemens három, eddig ismeretlen sérülékenységről számolt be az NCCIC-nek az alábbi RuggedCom firmware-ekkel kapcsolatban:

- RUGGEDCOM ROX II minden, v2.13.0-nál korábbi verzió.

A gyártó a hibát javító firmware-verziót már elérhetővé tette. A sérülékenységről további részleteket a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens termékek széles körét érintő sérülékenység

A Siemens egy memóriakezelési hibát jelentett az NCCIC-nek, ami az alábbi termékeit érinti:

- CP1604 minden verziója;
- CP1616 minden verziója;
- SIAMTIC RF185C minden verziója;
- SIMATIC CP343-1 Advanced minden verziója;
- SIMATIC CP443-1 minden verziója;
- SIMATIC CP443-1 Advanced minden verziója;
- SIMATIC CP443-1 OPC UA minden verziója;
- SIMATIC ET 200 SP Open Controller CPU 1515SP PC minden v2.1.6-nál korábbi verziója;
- SIMATIC ET 200 SP Open Controller CPU 1515SP PC2 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 KTP400F, KTP700, KTP700F, KTP900 und KTP900F minden verziója;
- SIMATIC IPC DiagMonitor minden verziója;
- SIMATIC RF181-EIP minden verziója;
- SIMATIC RF182C minden verziója;
- SIMATIC RF186C minden verziója;
- SIMATIC RF188C minden verziója;
- SIMATIC RF600R minden verziója;
- SIMATIC S7-1500 CPU family minden verziója;
- SIMATIC S7-1500 Software Controller minden verziója;
- SIMATIC S7-300 CPU family minden, v3.X.16-nál korábbi verziója;
- SIMATIC S7-400 PN (incl. F) v6 minden korábbi verziója;
- SIMATIC S7-400 PN/DP v7 (incl. F) minden verziója;
- SIMATIC S7-PLCSIM Advanced minden verziója;
- SIMATIC Teleservice Adapter IE Advanced minden verziója;
- SIMATIC Teleservice Adapter IE Basic minden verziója;
- SIMATIC Teleservice Adapter IE Standard minden verziója;
- SIMATIC WinAC RTX 2010 minden verziója;
- SIMATIC WinCC Runtime Advanced minden verziója;
- SIMOCODE pro V EIP minden verziója;
- SIMOCODE pro V PN minden verziója;
- SINAMICS G130 v4.6 minden verziója;
- SINAMICS G130 v4.7 minden verziója;
- SINAMICS G130 v4.7 SP1 minden verziója;
- SINAMICS G130 v4.8 minden v4.8 HF6-nál korábbi verziója;
- SINAMICS G130 v5.1 minden verziója;
- SINAMICS G130 v5.1 SP1 minden v5.1 SP1 HF4-nél korábbi verziója;
- SINAMICS G150 v4.6 minden verziója;
- SINAMICS G150 v4.7 minden verziója;
- SINAMICS G150 v4.7 SP1 minden verziója;
- SINAMICS G150 v4.8 minden, v4.8 HF6-nál korábbi verziója;
- SINAMICS G150 v5.1 minden verziója;
- SINAMICS G150 v5.1 SP1 minden, v5.1 SP1 HF4-nél korábbi verziója;
- SINAMICS S120 v4.6 minden verziója;
- SINAMICS S120 v4.7 minden verziója;
- SINAMICS S120 v4.7 SP1 minden verziója;
- SINAMICS S120 v4.8: minden, v4.8 HF6-nál korábbi verziója;
- SINAMICS S120 v5.1 minden verziója;
- SINAMICS S120 v5.1 SP1 minden, v5.1 SP1 HF4-nél korábbi;
- SINAMICS S150 v4.6 minden verziója;
- SINAMICS S150 v4.7 minden verziója;
- SINAMICS S150 v4.7 SP1 minden verziója;
- SINAMICS S150 v4.8 minden, v4.8 HF6-nál korábbi verziója;
- SINAMICS S150 v5.1 minden verziója;
- SINAMICS S150 v5.1 SP1 minden, v5.1 SP1 HF4-nél korábbi verziója;
- SINAMICS S210 v5.1 minden verziója;
- SINAMICS S210 v5.1 SP1 minden verziója;
- SITOP Manager minden verziója;
- SITOP PSU8600 minden verziója;
- SITOP UPS1600 minden verziója;
- TIM 1531 IRC minden verziója.

A hibát a gyártó az egyes termékek újabb verzióiban javította, a pontos lista és további részletek a Siemens ProductCERT és az ICS-CERT weboldalain találhatóak.

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

A Schneider Electric egy, az alábbi termékeiben megtalálható Modbus Serial Driver sérülékenységről adott ki publikációt:

A Driver Suite V14.12 és korábbi verzióinak részeként:
- a 64-bites Windows operációs rendszerekhez kiadott V3.17 IE 37 és korábbi verziójú driverek;
- a 32-bites Windows operációs rendszerekhez kiadott V2.17 IE 27 és korábbi verziójú driverek.

Az érintett drivereket az alábbi Schneider Electric termékekben használják:

- TwidoSuite;
- PowerSuite;
- SoMove;
- SoMachine;
- Unity Pro;
- Control Expert;
- Unity Loader;
- Concept;
- Modbus SL Comm DTM;
- PL7;
- SFT2841;
- OFS.

A gyártó a hibát javító verziókat már elérhetővé tette a weboldalán. A sérülékenységről bővebben a Schneider Electric publikációjában 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.

2017 decemberben és 2018 januárban én is többször írtam a Triton/TriSIS (később Hatman) néven elhíresült malware-ről, ami egy Szaúd-arábiai olajipari vállalat safety (SIS) rendszere elleni támadáshoz használt kártékony kód. A héten a FireEye kutatói (ők adták a malware-nek a Triton nevet) újabb információkat hoztak nyilvánosságra, amelyek szerint a Triton/TriSIS malware mögött álló támadók (akikről a Dragos Xenotime név alatt már számos jellemző eszközt és technikát publikált) egy újabb kritikus infrastruktúra elleni támadásnál használták fel a Szaúd-Arábiában már látott malware-t.

A FireEye elemzése szerint a támadók a széles körben használt eszközök (pl. Mimikatz) mellett számos egyedi, saját fejlesztésű eszközt is használnak a támadások végrehajtása során, ezek funkcionalitásban nem nagyon különböznek a már ismert, hasonló eszközöktől, de az egyedi fejlesztés lehetővé teszi, hogy nagyobb eséllyel kerüljék el a kártékony kódok észlelését a hagyományos, mintaillesztéssel dolgozó biztonsági rendszerek esetén.

A támadók tevékenységét elemző kutatók úgy vélik, hogy a Triton/TriSIS mögött álló csoport 2014 óta lehet aktív, de a módszereik és eszközeik miatt képesek volt sokáig elkerülni, hogy felfedezzék a tevékenységüket, egészen addig, amíg Szaúd-Arábiában egy hiba következtében le nem állították az olajipari létesítmény egyes folyamatait.

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

Maxim Rupp egy Command Injection sérülékenységet jelentett a PHOENIX CONTACT-nak, ami a gyártó alábbi rendszereit érinti:

- RAD-80211-XD (2885728);
- RAD-80211-XD/HP-BUS (2900047).

A gyártó a sérülékenységgel kapcsolatban az érintett termékek támogatásának korábbi megszünése miatt kockázatcsökkentő intézkedéseket javasol. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-085-02

ENTTEC rendszerek sérülékenysége

Ankit Anubhav, a NewSky Security munkatársa egy kritikus funkciókhoz tartozó authentikáció hiányát fedezte fel az ENTTEC alábbi rendszereiben:

- a Datagate MK2 minden, 70044_update_05032019-482-nél korábbi firmware-verziója;
- a Storm 24 minden, 70050_update_05032019-482-nél korábbi firmware-verziója;
- a Pixelator minden, 70060_update_05032019-482-nél korábbi firmware-verziója.

A gyártó a hibát a legújabb firmware-verziókban javította. A sérülékenységről további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-085-03-0

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

Mat Powell és Natnael Samson a ZDI-vel együttműködve három sérülékenységet találtak az Advantech WebAccess/SCADA rendszerének 8.3.5-ös és korábbi verzióiban.

A gyártó a sérülékenységeket a 8.4.0 verzióban javította. A sérülékenységekkel kapcsolatban részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-092-01

Sérülékenységek különböző Rockwell Automation rendszerekben

Az elmúlt 2 hétben 4 bejelentésben is különböző Rockwell Automation rendszerek sérülékenységi információi jelentek meg. Az elsőt Nicolas Merle, az Applied Risk munkatársa találta a Rockwell Automation beágyazott EtherNet/IP és Safety protokollal ellátott PowerFlex 525 AC drive berendezéseinek 5.001 és korábbi verzióiban.

A gyártó a hibát a legújabb firmware-verzióban javította. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-087-01

A következő hibát a gyártó jelezte az NCCIC-nek, ez a sérülékenység a bevitt adatok nem megfelelő ellenőrzéséből adódik és az Allen-Bradly Stratix 5950-es biztonsági appliance-ek alábbi verzióit érinti:

- 1783-SAD4T0SBK9;
- 1783-SAD4T0SPK9;
- 1783-SAD2T2SBK9;
- 1783-SAD2T2SPK9.

A hibával kapcsolatban a gyártó a berendezésekbe épített Cisco IPSec VPN használatának mellőzését és további kockázatcsökkentő intézkedéseket javasol. A sérülékenységről bővebben az ICS-CERT-nek ebben a bejelentésében lehet információkat találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-04

Szintén a gyártó jelezte az NCCIC-nek, hogy az alábbi termékeiben két sérülékenységet is azonosítottak:

- Allen-Bradley Stratix 5400, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 5410, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 5700, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley ArmorStratix 5700, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 8000, a 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 8300, a 15.2(4)EA7 és korábbi verziói.

A gyártó a hibát az alábbi verziókban javította:

- FRN 15.2(6)E2a:
- Allen-Bradley Stratix 5400 esetén;
- Allen-Bradley Stratix 5410 esetén;
- Allen-Bradley Stratix 5700 esetén;
- Allen-Bradley ArmorStratix 5700 esetén;
- Allen-Bradley Stratix 8000 esetén.
- FRN 15.2(4)EA7:
- Allen-Bradley Stratix 8300 esetén.

A sérülékenységről további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-03

A Rockwell Automation egy ugyancsak Cisco komponensekből eredeztethető hibát jelentett az NCCIC-nek az alábbi termékeivel kapcsolatban:

- Allen-Bradley Stratix 5400 minden 15.2(6)E2a-nál korábbi verzió;
- Allen-Bradley Stratix 5410 minden 15.2(6)E2a-nál korábbi verzió;
- Allen-Bradley Stratix 5700 minden 15.2(6)E2a-nál korábbi verzió;
- Allen-Bradley ArmorStratix 5700 minden 15.2(6)E2a-nál korábbi verzió.

A gyártó a hibát a 15.2(6)E2a és később verziókban javította. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-02

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

Esteban Ruiz, a Source Incite munkatársa a ZDI-vel együttműködve egy sérülékenységet talált az Omron alábbi termékeiben:

- CX-Programmer v9.70 és korábbi verziói;
- Common Components January 2019 és korábbi verziók.

A gyártó a hibát az érintett rendszerek legújabb verzióiban javította. A sérülékenységről részleteket az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-19-094-01

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

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

Ahogy a tisztán elektromos és plug-in hibrid meghajtású autók terjednek, egyre nyilvánvalóbbá válik, hogy a elektromos árammal történő feltöltésük a tömeges elterjedésük egyik legnagyobb akadálya. Jelenleg a legtöbb országban még a nem kellően sűrű töltőhálózat okoz problémát, amit a gyártók részben az otthoni, távolról is kezelhető házi töltőállomások elterjesztésével is próbálnak orvosolni.

A mai posztban két olyan, még 2018 végén publikált cikkre szeretném felhívni a figyelmet, amik azt mutatják be, mennyire hétköznapi, triviális sérülékenységek találhatóak ezekben a rendszerekben, amik, ha a háztartási elektromos autó töltők nagy tömegben terjednek el, adott esetben komoly hatással lehetnek a villamosenergia-rendszer nagyobb szegmenseire is (emlékezzünk csak a méltán elhíresült Black out - holnap már túl késő című könyvben az európai villamosenergia-rendszer ellen elkövetett - szerencsére csak fiktív - támadásra).

Az első cikkben a Kaspersky Lab munkatársai foglalták össze, hogy milyen sérülékenységeket találtak a ChargePoint által gyártott ChargePoint Home rendszerben, a 30 oldalas jelentés a rendszerben talált (és a gyártó által még tavaly év végén javított) sérülékenységekről itt érhető el.

Néhány nappal a Kaspersky fenti publikációja után a SecurityAffairs.co weboldalon kerültek nyilvánosságra a Schneider Electric EVLink Parking rendszerben a Positive Technologies munkatársai által talált sérülékenységek. Mindkét eset azt példázza (és nem először), hogy amint a gyártók között felerősödik a verseny egy új termékkel kapcsolatban történő piacszerzés során, úgy az új termékek (elsősorban IT biztonsági) minőségellenőrzése háttérbe szorul. Így volt ez néhány éve az IoT eszközök robbanásszerű terjedésének elején is, ezúttal azonban előfordulhat, hogy a következmények sokkal súlyosabbak lesznek, mint amikor a fitnesz-karkötőket lehetett nem túl bonyolult módon kompromittálni.

A héten újabb hírek láttak napvilágot, amik egy része a Norsk Hydro-t ért, másfél héttel ezelőtti támadás mértékét világítják meg (a hírek szerint a részleges leállást okoztó incidens első hete mintegy 35-40 millió amerikai dollárnyi veszteséget generált a cégnek). Más források szerint két amerikai vegyipari vállalatot (amelyek ugyanannak a befektetési alapnak a tulajdonásban vannak) szintén LockerGoga-támadás ért, még március 12-én. Ennek a hírnek a leginkább érdekes momentuma az a feltevés, hogy a LockerGoga ransomware-t irányító támadók nem igazán hatékonyak a váltságdíjak megszerzésében, ezért már felmerült az az elmélet is, hogy a LockerGoga nem is igazán ransomware, inkább egy wiper malware (inkább a NotPetya-ra és nem a WannaCry-ra hasonlít) és elsődleges célja a rombolás és nem a pénzszerzés.

Még év elején írtam egy posztot, amiben a TrendMicro által végzett, IIoT biztonsági kutatás eredményeiről írtam. Most a TrendMicro egy újabb kutatása eredményeiről lesz szó, ezúttal azonban azt vizsgálták, hogy a különböző Deep/DarkWeb-en megforduló egyének és csoportok milyen információkat és milyen céllal próbálnak összegyűjteni az Internet mélyebb rétegeiben.

A Deep/DarkWeb fórumain folytatott beszélgetések vizsgálata alapján a TrendMicro munkatársai az általános, ICS/SCADA rendszerekkel ismerkedő embereket (akik lehet, hogy csak a saját munkakörükhöz szükséges tudást próbálták a hivatalos tanfolyamoknál sokkal olcsóbban - ingyen - megszerezni,) éppúgy találtak, mint olyanokat, akik a Shodan és Censys keresők használatáról érdeklődtek és persze olyanokat is, akik a különböző (I)IoT eszközökön keresztül megszerezhető profit vezérelt. Túl ezeken a motivációkon, találtak olyan személyeket is, akik nem voltak hajlandóak elárulni, milyen cél elérése érdekében akarnak többet megtudni különböző ICS/SCADA rendszerekről, míg mások kifejezett Proof-of-concept kódokat, sérülékenységeket és a sérülékenységeket kihasználó éles exploit-okat kerestek.

A kutatók számára nagy nehézséget okozott megállapítani, hogy ezek az információgyűjtő tevékenységek előre jelezhetnek-e készülő vagy már folyamatban lévő támadásokat, viszont ezek a jelzések mind határozottabban mutatják, hogy a közműszektorban működő cégeknek alaposabb és pontosabb kockázatelemzésekkel kell készülniük az IIoT eszközök egyre nagyobb számban történő bevezetésére és ezzel egyidőben minél hatékonyabb eljárásokat kell kidolgozniuk a már üzemelő rendszereik biztonsági kockázatainak csökkentésére. Ebben továbbra is a már unalomig ismételt, de még mindig számos helyen és esetben megszegett, alapvető kockázatcsökkentési intézkedéseké lehet a főszerep:

- Minimálisra kell csökkenteni az ICS/SCADA 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 ICS/SCADA rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ICS/SCADA 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 TrendMicro teljes, 70 oldalas elemzése itt érhető el.

Sérülékenységek Columbia Weather Systems rendszerekben

John Elder és Tom Westenberg, az Applied Risk munkatársai hat sérülékenységet azonosítottak a Columbia Weather Systems Weather MicroServer nevű termékének MS_2.6.9900-as és korábbi firmware-verzióiban.

A gyártó a hibákat az MS_2.7.9973-as firmware-verzióban javította. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-078-02

AVEVA rendszerek sérülékenysége

A Venustech-hez tartozó ADLab munkatársai a Gemalto Sentinel UltraPro korábban már általam is jelzett sérülékenységét találták meg az AVEVA alábbi rendszereiben:

- InduSoft Web Studio v8.1 SP3-nál korábbi verziók;
- InTouch Edge HMI 2017 Update 3-nál korábbi verziók.

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észleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-078-01

Sérülékenységek Medtronic eszközök által használt protokollban

Egy számos kutatóból álló csapat (Peter Morgan, a Clever Security munkatársa, Dave Singelée és Bart Preneel, a Leuven-i Katolikus Egyetem munkatársai, Eduard Marin a Leuven-i Katolikus Egyetem korábbi, jelenleg a Birmingham-i egyetem munkatársa, Flavio D. Garcia, Tom Chothia a Birmingham-i egyetem munkatársa, és Rik Willems a Leuven-i Gasthuisberg Egyetemi kórház munkatársa) két sérülékenységet fedeztek fel az alábbi Medtronic eszközök által használt rádiófrekvenciás telemetriai protokollban:

- MyCareLink Monitor 24950-es és 24952-es verziói;
- CareLink Monitor 2490C verzió;
- CareLink 2090 Programmer,
- Amplia CRT-D minden modell;
- Claria CRT-D minden modell;
- Compia CRT-D minden modell;
- Concerto CRT-D minden modell;
- Concerto II CRT-D minden modell;
- Consulta CRT-D minden modell;
- Evera ICD minden modell;
- Maximo II CRT-D and ICD minden modell;
- Mirro ICD minden modell;
- Nayamed ND ICD minden modell;
- Primo ICD minden modell;
- Protecta ICD and CRT-D minden modell;
- Secura ICD minden modell;
- Virtuoso ICD minden modell;
- Virtuoso II ICD minden modell;
- Visia AF ICD minden modell; and
- Viva CRT-D minden modell.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedések bevezetését javasolja és jelenleg is dolgozik a sérülékenységek javításán. A sérülékenységekről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-080-01

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

Az Applied Risk munkatársai egy DoS-támadást lehetővé tevő sérülékenységet találtak a Schneider Electric Triconex TriStation Emulator 1.2.0 verziójában, ami a Triconex TriStation 1131 4.9.0 verziójának egyik komponense. A 2017 végén nyilvánosságra került TriSIS/Triton/Hatman malware-támadás is ezt a terméket érintette.

A gyártó a hibát javító verziót tervei szerint 2019 júliusában fogja kiadni. A sérülékenységről bővebben az Applied Risk és a Schneider Electric kiadványaiban lehet olvasni.

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.