Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

Sérülékeny ipari robotok

Tanulmány az ipari robotizálás biztonságáról

2017. május 13. - icscybersec

A TrendMicro-n belül működő TrendLabs és a Politecnico Milano közös kutatásáról készült tanulmány alig több, mint egy hete látott napvilágot. Manapság már egyáltalán nem számít rendkívülinek, ha újabb cikkek, tanulmányok és blogposztok jelennek meg a különböző ipari folyamatvezérlő rendszerek és eszközök kiberbiztonságáról, a most megjelent tanulmány abban mindenképp az elsők közé tartozik, hogy az iparban, különösen a gyártástechnológiában használt robotok kiberbiztonsági helyzetéről nyújt egy alaposabb áttekintést.

A kutatók munkájuk során olyan, mindenki számára szabadon elérhető eszközöket használtak, mint pl. a Shodan, a ZoomEye vagy a Censys keresőmotorok.

Ezekkel az eszközökkel tucatnyi, kifejezetten ipari környezetbe szánt router-eket gyártó cég több, mint 80.000 router-ét térképezték fel az Interneten. Nem lehet eléggé hangsúlyozni, hogy mennyire fontos, hogy legalább az ipari rendszerek közvetlen Internet-kapcsolatait szüntessük meg - azzal kapcsolatban már régen senkinek nincsenek illúziói, hogy az ipari rendszereket és a vállalati/irodai/ügyviteli hálózatok összekötését meg lehet-e előzni vagy ha már összekapcsolták őket, meg lehet-e szüntetni ezeket a kapcsolatokat, de az ipari rendszerek/berendezések közvetlen Internetre történő csatlakoztatása több nagyságrenddel növeli az érintett szervezetek kockázatait.

Tovább árnyalja a gyártástechnológiai rendszerek kiberbiztonsági helyzetének sötét képét az a szám, hogy a kutatók által feltérképezett több, mint 80.000 ipari router közül több, mint 5.000-nél még a legalapvetőbb bejelentkezésre sincs szükség ahhoz, hogy bárki hozzáférést szerezhessen ezeken az eszközökön. Tudva, hogy az ipari rendszerek esetén még ma is mennyire kevéssé elterjedt a hibajavítások rendszeres telepítése, még egy nem privilegizált hozzáférés is nagyon komoly biztonsági kockázatokat jelent.

A kutatás során nem csak ipari router-eket, hanem 5 különböző gyártó 28 ipari robotját is elérték az Interneten keresztül. A legtöbb robothoz az azok vezérlő szoftverébe épített FTP-szerveren keresztül sikerült hozzáférést szerezni.

A kutatóknak az általuk vizsgált ipari robotokban feltárt, ismert vagy 0. napi sérülékenységek labor-körülmények között történő kihasználásával számos támadási forgatókönyvet sikerült vázolni, többek között a gyártott termékek szabotálásától (gondoljuk csak el az autó vagy repülőgép-gyártósorokon működő robotok kompromittálásával okozható károk méretét - vegyünk csak egy, az autógyártástól annyira függő országot, mint Magyarország és képzeljük el, mi történne a magyar GDP-vel, ha a legnagyobb hazai autógyárak robotizált gyártósorait egyszerre kéne napokra vagy akár hetekre leállítani egy kiterjedt és összehangolt kibertámadás nyomán...) a robotokban történő károkozáson és az ipari kémkedésen át egészen az emberi sérüléssel vagy halállal járó incidensig.

Ahogy az ipari dolgok Internete (IIoT) és a negyedik ipari forradalom (Industry 4.0) egyre inkább a mindennapok részévé válnak az ICS világban, mindenkinek, a döntéshozóktól az OT-ban dolgozó mérnökökön át az ICS biztonsági szakemberekig tudomásul kell venniük, hogy csak közösen, az egyes szakterületek tudását és tapasztalatait ötvözve leszünk képesek megfelelni az ipari rendszerek egyre nagyobb kiberbiztonsági kihívásainak. A gyártástechnológiai ICS rendszerek esetén sem kell ismét feltalálni a kereket, a SCADA rendszereknél már több, mint fél évtizede fejlesztett biztonsági eljárások és eszközök a megfelelő tervezéssel, teszteléssel és körültekintéssel alkalmazva a gyártósorokon alkalmazott automatizálási rendszerek esetén is hatékonyan használhatóak - feltéve, hogy az OT és az ICS biztonsági területek képesek a megfelelő szintű együttműködésre.

ICS sérülékenységek CXI

Sérülékenységek Siemens, Rockwell Automation és Cisco rendszerekben

Az elmúlt napokban furcsa kettősség volt a friss ICS sérülékenységekről szóló bejelentésekben, a Siemens számos termékében javított a bevitt adatok nem megfelelő ellenőrzéssel kapcsolatos hibákat, a Rockwell Automation pedig egy termékcsaládjában javított nem kevesebb, mint 41 különböző sérülékenységet és gyenge pontot.

Siemens SIMATIC WinCC és STEP 7 (TIA Portal) sérülékenység

Duan JinTong, Ma ShaoShuai és Cheng Lei, az NSFOCUS Security Team tagjai jelezték a Siemensnek, hogy az alábbi SIMATIC WinCC és STEP 7 (TIA Portal) termékeiben egy, a PROFINET Discovery and Configuration Protocol-lal (DCP-vel) kapcsolatos hibát fedeztek fel:

- SIMATIC WinCC (TIA Portal)
  - V13: minden, V13 SP2-nél korábbi verzió;
  - V14: minden, V14 SP1-nél korábbi verzió;
- SIMATIC STEP 7 (TIA Portal)
  - V13: minden, V13 SP2-nél korábbi verzió;
  - V14: minden, V14 SP1-nél korábbi verzió;
- SIMATIC STEP 7 V5.X: minden verzió;
- STEP 7 - Micro/WIN SMART: minden verzió;
- SMART PC Access V2.0,
- SIMATIC Automation Tool: minden verzió;
- SIMATIC WinCC: minden verzió;
- SIMATIC PCS 7: minden verzió;
- SIMATIC NET PC-Software: minden verzió;
- Primary Setup Tool (PST): minden verzió;
- Security Configuration Tool (SCT): minden verzió;
- SINEMA Server: minden verzió;
- SINAUT ST7CC: minden verzió;
- SIMATIC WinAC RTX 2010 SP2: minden verzió;
- SIMATIC WinAC RTX F 2010 SP2: minden verzió;
- SINUMERIK 808D Programming Tool: minden verzió;
- SIMATIC WinCC flexible 2008: minden verzió.

Egy támadó a PROFINET DCP hibát kihasználva szolgáltatás-megtagadásos (DoS) támadást indíthat a sérülékeny rendszerek ellen, amit csak az érintett eszközök manuális újraindításával lehet elhárítani. A Siemens a hibát az alábbi verziókban javította:

- SIMATIC WinCC (TIA Portal) V13 SP2;
- SIMATIC WinCC (TIA Portal) V14 SP1;
- SIMATIC STEP 7 (TIA Portal) V13 SP2;
- SIMATIC STEP 7 (TIA Portal) V14 SP1.

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

A DCP hiba hasonló módon érint számos Siemens terméket:

- SIMATIC CP 343-1 Std, CP 343-1 Lean: minden verzió;
- SIMATIC CP 343-1 Adv: minden verzió;
- SIMATIC CP 443-1 Std, CP 443-1 Adv: V3.2.17-nél korábbi verziók;
- SIMATIC CP 443-1 OPC-UA: minden verzió;
- SIMATIC CP 1243-1: minden verzió;
- SIMATIC CM 1542-1: V2.0-nál korábbi verziók
- SIMATIC CP 1543SP-1, CP 1542SP-1 és CP 1542SP-1 IRC: minden verzió;
- SIMATIC CP 1543-1: V2.1-nél korábbi verziók;
- SIMATIC RF650R, RF680R, RF685R: V3.0-nál korábbi verziók;
- SIMATIC CP 1616, CP 1604, DK-16xx PN IO: V2.7-nél korábbi verziók;
- SCALANCE X200: minden verzió;
- SCALANCE X200 IRT: minden verzió;
- SCALANCE X300, X408, X414: minden verzió;
- SCALANCE XM400, XR500: minden verzió;
- SCALANCE W700: V6.1-nél korábbi verziók;
- SCALANCE M-800,S615:minden verzió;
- Softnet PROFINET IO for PC-based Windows systems: minden verzió;
- IE/PB-Link: V3.0-nál korábbi verziók;
- IE/AS-i Link PN IO: minden verzió;
- SIMATIC Teleservice Adapter Standard Modem, IE Basic, IE Advanced: minden verzió;
- SITOP PSU8600 / UPS1600 PROFINET: minden verzió;
- SIMATIC ET 200 PROFINET IO-hoz való interfész modulok:
  - SIMATIC ET 200AL: minden verzió;
  - SIMATIC ET 200ecoPN: minden verzió;
  - SIMATIC ET 200M: minden verzió;
  - SIMATIC ET 200MP: V4.0.1-nél korábbi verziók;
  - SIMATIC ET 200pro: minden verzió;
  - SIMATIC ET 200S: minden verzió;
  - SIMATIC ET 200SP: minden verzió;
  - PN/PN Coupler: minden verzió;
- PROFINET IO fejlesztői és teszt készletek:
  - DK Standard Ethernet Controller: V4.1.1 Patch04-nél korábbi verziók;
  - EK-ERTEC 200P PN IO: V4.4.0 Patch01-nél korábbi verziók;
  - EK-ERTEC 200 PN IO: V4.2.1 Patch03-nál korábbi verziók;
- SIMATIC S7-200 SMART: minden verzió;
- SIMATIC S7-300, F és T sorozat is: V3.X.14-nél korábbi verziók;
- SIMATIC S7-400, F és H sorozat: minden verzió;
- SIMATIC S7-1200, F sorozat: V4.2.1-nél korábbi verziók;
- SIMATIC S7-1500m F, T és TF sorozat: V2.1-nél korábbi verziók;
- SIMATIC S7-1500 szoftveres kontroller, F sorozat: V2.1-nél korábbi verziók;
- SIMATIC WinAC RTX 2010, F sorozat: minden verzió;
- SIRIUS ACT 3SU1 PROFINET interfész modul: minden verzió;
- SIRIUS Soft starter 3RW44 PN: minden verzió;
- SIRIUS Motor starter M200D PROFINET: minden verzió;
- SIMOCODE pro V PROFINET: minden verzió;
- SINAMICS:
  - SINAMICS DCM: minden verzió;
  - SINAMICS DCP: minden verzió;
  - SINAMICS G110M / G120(C/P/D) w. PN: V4.7 SP6 HF3-nél korábbi verziók;
  - SINAMICS G130 és G150: V4.8 HF4-nél korábbi verziók;
  - SINAMICS S110 w. PN: minden verzió;
  - SINAMICS S120: V4.8 HF4-nél korábbi verziók;
  - SINAMICS S150: V4.8 HF4-nél korábbi verziók;
  - SINAMICS V90 w. PN: minden verzió;
- SIMOTION: V4.5 HF1-nél korábbi verziók;
- SINUMERIK 828D:
  - V4.5-nél korábbi verziók;
  - V4.7: V4.7 SP4 HF1-nél korábbi verziók;
- SINUMERIK 840D sl:
  - Minden, V4.5 SP6 HF8-nál korábbi verzió;
  - V4.7: V4.7 SP4 HF1-nél korábbi verziók;
- SIMATIC HMI Comfort Panels, HMI Multi Panels, HMI Mobile Panels: minden verzió.

A hibát a gyártó ezekben a termékekben is javította, az alábbi verziókban:

- SIMATIC CP 443-1 Std: V3.2.17;
- SIMATIC CP 443-1 Adv: V3.2.17;
- SIMATIC CM1542-1: V2.0;
- SIMATIC CP 1543-1: V2.1;
- SIMATIC RF650R, RF680R, RF685R: V3.0;
- SIMATIC CP 1616, CP 1604, DK-16xx PN IO: V2.7;
- SCALANCE W700: V6.1.0;
- IE/PB-Link: V3.0;
- PROFINET IO fejlesztői és teszt készletek:
  - DK Standard Ethernet Controller: V4.1.1 Patch04-nél korábbi verziók;
  - EK-ERTEC 200P PN IO:V4.4.0 Patch01-nél korábbi verziók;
  - EK-ERTEC 200 PN IO: V4.2.1 Patch03-nál korábbi verziók;
- SIMATIC S7-300, F és  T sorozat: V3.X.14;
- SIMATIC S7-1200, F sorozat:V4.2;
- SIMATIC S7-1500, F, T és TF sorozat: V2.1;
- SIMATIC S7-1500 szoftveres kontroller, F sorozat: V2.1;
- SINAMICS:
  - SINAMICS G110M/G120(C/P/D) w. PN: V4.7 SP6 HF3;
- SINAMICS G130 és G150: V4.8: V4.8 HF4;
- SINAMICS S120: V4.8: V4.8 HF4;
- SINAMICS S150: V4.8: V4.8 HF4;
- SIMOTION: V4.5 HF1;
- SINUMERIK 828D: V4.7: V4.7 SP4 HF1;
- SINUMERIK 840D sl:
  - V4.5-nél korábbi verzióknál: V4.5 SP6 HF8;
  - V4.7: V4.7 SP4 HF1.

A sérülékenységről ezeknél az eszközöknél is a Siemens ProductCERT és az ICS-CERT bejelentéseiből lehet többet megtudni.

Sérülékenység Siemens SIMATIC WinCC és WinCC Runtime Professional termékekben

Sergey Temnikov és Vladimir Dashchenko, a Kaspersky Lab kritikus infrastruktúra védelmi csapatának tagjai szintén egy, a bevitt adatok nem megfelelő ellenőrzésével kapcsolatos hibát találtak a SIMATIC WinCC és a WinCC Runtime Professional szoftverek alábbi verzióiban:

- SIMATIC WinCC:
  - V7.3: V7.3 Update 11-nél korábbi verziók;
  - V7.4: V7.4 SP1-nél korábbi verziók;
- SIMATIC WinCC Runtime Professional:
  - V13: V13 SP2-nél korábbi verziók;
  - V14: V14 SP1-nél korábbi verziók;
- SIMATIC WinCC (TIA Portal) Professional:
  - V13: V13 SP2-nél korábbi verziók;
  - V14: V14 SP1-nél korábbi verziók.
 
A hibát a sérülékeny rendszerek DCOM interfészére küldött, speciálisan kialkaított üzenetekkel lehet kihasználni. A hiba kihasználáshoz a támadó által használt felhasználói fióknak adminisztrátori jogosultságokkal kell rendelkeznie. Egy sikeres támadás eredményeképp a sérülékeny rendszer összeomolhat, ezzel gyakorlatilag szolgáltatás-megtagadás idézhető elő.

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

- SIMATIC WinCC:
  - V7.3: Update to WinCC V7.3 Update 13;
  - V7.4: Update to WinCC V7.4 SP1;
- SIMATIC WinCC Runtime Professional:
  - V13: Update to V13 SP2;
  - V14: Update to V14 SP1;
- SIMATIC WinCC (TIA Portal) Professional:
  - V13: Update to V13 SP2;
  - V14: Update to V14 SP1.

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

Rockwell Automation Stratix 5900 sérülékenységek

A Rockwell Automation-nek a Cisco jelezte, hogy a Cisco kódbázisra épülő Stratix 5900-as routerek 15.6.3-nál korábbi firmware-jei számos (számszerűen 41 különböző) hibát tartalmaznak. A sérülékenységek között több, a bevitt adatok nem megfelelő ellenőrzéssel kapcsolatos hiba, erőforrás-kezelési hibák, nem megfelelő authentikációból adódó hibák és könyvtár-bejárást lehetővé tevő hibák vannak.

A gyártó a hibákat a Stratix 5900-asok 15.6.3-as firmware-jében javította.

A sérülékenységekről számos részletet tartalmaz az ICS-CERT publikációja: https://ics-cert.us-cert.gov/advisories/ICSA-17-094-04

Sérülékenység Cisco ipari környezetekbe szánt hálózati eszközökben

A Cisco bejelentése szerint az alábbi, ipari környezetekbe szánt hálózati eszközeiben találtak olyan, Cluster Management Protocol (CMP) hibát, ami távoli kódfuttatást tesz lehetővé:

- Cisco IE 2000-16PTC-G Industrial Ethernet Switch;
- Cisco IE 2000-16T67 Industrial Ethernet Switch;
- Cisco IE 2000-16T67P Industrial Ethernet Switch;
- Cisco IE 2000-16TC Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-E Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-N Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-X Industrial Ethernet Switch;
- Cisco IE 2000-24T67 Industrial Ethernet Switch;
- Cisco IE 2000-4S-TS-G Industrial Ethernet Switch;
- Cisco IE 2000-4T Industrial Ethernet Switch;
- Cisco IE 2000-4T-G Industrial Ethernet Switch;
- Cisco IE 2000-4TS Industrial Ethernet Switch;
- Cisco IE 2000-4TS-G Industrial Ethernet Switch;
- Cisco IE 2000-8T67 Industrial Ethernet Switch;
- Cisco IE 2000-8T67P Industrial Ethernet Switch;
- Cisco IE 2000-8TC Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G-E Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G-N Industrial Ethernet Switch;
- Cisco IE 3000-4TC Industrial Ethernet Switch;
- Cisco IE 3000-8TC Industrial Ethernet Switch;
- Cisco IE-3010-16S-8PC Industrial Ethernet Switch;
- Cisco IE-3010-24TC Industrial Ethernet Switch;
- Cisco IE-4000-16GT4G-E Industrial Ethernet Switch;
- Cisco IE-4000-16T4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4GC4GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4GS8GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4S8P4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4T4P4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4TC4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GS4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GT4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GT8GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8S4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8T4G-E Industrial Ethernet Switch;
- Cisco IE-4010-16S12P Industrial Ethernet Switch;
- Cisco IE-4010-4S24P Industrial Ethernet Switch;
- Cisco IE-5000-12S12P-10G Industrial Ethernet Switch;
- Cisco IE-5000-16S12P Industrial Ethernet Switch.

A Cisco új firmware verziót adott ki az érintett eszközökhöz, amiben javította a hibát.

A sérülékenységről további részleteket a Cisco bejelentéséből lehet megtudni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp

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áltasáok 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ű (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.

ICS sérülékenységek CX

Hikvision, Dahua Technology Co., Ltd, Advantech és Rockwell Automation rendszerek sérülékenységei

Hikvision kamerák sérülékenységei

A "Montecrypto" nevű IPcamtalk felhasználó két hibát talált a Hikvision alábbi kameráiban és szoftver verzióiban:

- DS-2CD2xx2F-I sorozat, V5.2.0 build 140721-től V5.4.0 build 160530-ig;
- DS-2CD2xx0F-I sorozat, V5.2.0 build 140721-től V5.4.0 Build 160401-ig;
- DS-2CD2xx2FWD sorozat, V5.3.1 build 150410-től V5.4.4 Build 161125-ig;
- DS- 2CD4x2xFWD sorozat, V5.2.0 build 140721-től V5.4.0 Build 160414-ig;
- DS-2CD4xx5 sorozat, V5.2.0 build 140721-től V5.4.0 Build 160421-ig;
- DS-2DFx sorozat, V5.2.0 build 140805-től V5.4.5 Build 160928-ig;
- DS-2CD63xx sorozat, V5.0.9 build 140305-től V5.3.5 Build 160106-ig.

A két hiba közül az első az authentikációs eljárásban található, a második pedig abból adódik, hogy egyes konfigurációs fájlokban jelszavak lehetnek.

Az authentikáció hibáját a gyártó egy új firmware-verzióban javította, a konfigurációs állományokban található jelszavak problémájára azonban egyelőre nincs javítás.

A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-124-01

Sérülékenység Dahua Technology Co., Ltd digitális videórögzítő rendszerekben és IP kamerákban

Egy Bashis néven ismert kutató talált hibákat a Dahua Technology Co., Ltd egyes DVR és IP kamera rendszerekben. Az alábbi kamerák érintettek:

- DH-IPC-HDBW23A0RN-ZS;
- DH-IPC-HDBW13A0SN;
- DH-IPC-HDW1XXX;
- DH-IPC-HDW2XXX;
- DH-IPC-HDW4XXX;
- DH-IPC-HFW1XXX;
- DH-IPC-HFW2XXX;
- DH-IPC-HFW4XXX;
- DH-SD6CXX;
- DH-NVR1XXX;
- DH-HCVR4XXX és
- DH-HCVR5XXX.

Érintettek továbbá az alábbi digitális videórögzítő rendszerek:

- DHI-HCVR51A04HE-S3;
- DHI-HCVR51A08HE-S3 és
- DHI-HCVR58A32S-S2.

Az első hiba lehetővé teszi egy támadó számára, hogy pass-the-hash támadást hajtson végre a sérülékeny rendszerek ellen, a második pedig (ma már nem először) a jelszavak konfigurációs fájlokban történő megjelenéséből adódik.

A gyártó elkészítette és elérhetővé tette a hibák javítását tartalmazó firmware-verziót és további információkat publikált a sérülékenységekről:

http://us.dahuasecurity.com/en/us/Security-Bulletin_030617.php
http://www.dahuasecurity.com/en/us/single.php?nid=354
http://www.dahuasecurity.com/en/us/single.php?nid=364
http://us.dahuasecurity.com/en/us/Security-Bulletin_04032017.php

A sérülékenységekkel kapcsolatos ICS-CERT publikáció itt érhető el: https://ics-cert.us-cert.gov/advisories/ICSA-17-124-02

Advantech WebAccess sérülékenység

Zhou Yu, a ZDI-vel együttműködő kutató egy könyvtárbejárást lehetővé tevő hibát talált az Advantech WebAccess 8.1-es és korábbi verzióiban.

A gyártó a hibát a 8.2_20170330 verzióban javította, amit a hibát jelentő kutató is tesztelt és megerősítette, hogy a javítás nyomán a sérülékenység megszűnt.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-124-03

Rockwell Automation ControlLogix és CompactLogix sérülékenység

Az ICS-CERT bejelentése szerint a Rockwell Automation alábbi rendszereiben egy DoS-támadást lehetővé tevő hibát azonosítottak:

- ControlLogix 5580 vezérlők V28.011, V28.012 és V28.013 verziói;
- ControlLogix 5580 vezérlők V29.011 verziója;
- CompactLogix 5380 vezérlők V28.011 verziója és
- CompactLogix 5380 vezérlők V29.011 verziója.

A hibát a gyártó a későbbi verziókban már javította, így minden, érintett verziójú vezérlőt használó ügyfelének azt javasolja, hogy frissítsenek, a ControlLogix 5580-as a CompactLogix 5380-as vezérlők esetén is a V30.011-es verzióra.

A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-094-05

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áltasáok 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ű (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 ICS kiberbiztonság hiányzó láncszeme

Miért fontos kérdés a terepi/gyártósori ICS eszközök kiberbiztonsága?

A különböző ipari rendszereket a múltban és a jelenben is a megbízhatóságot, a biztonságot (safety) és a különböző szabályozói előírásoknak való megfelelést szem előtt tartva fejlesztik. Ahogy az ipari rendszerek mind több ponton kerültek összekapcsolásra a vállalati IT-val és ezzel párhuzamosan egyre több IT komponens került beépítésre az ipari rendszerekbe, megjelent az ICS kiberbiztonság fogalma, majd rögtön ezután az igény a megvalósítására is - különösen a Stuxnet nyilvánosságra kerülése után vált ez mind népszerűbb témává (e sorok írójára is igen mély benyomást tett a Stuxnet, majd az azt követő években nyilvánosságra kerülő többi ICS rendszerekkel kapcsolatos incidens, ennek egyenes következménye volt a blog elindítása is). Az ICS kiberbiztonság igen sokáig az OT által használt szerverek, HMI-ok, mérnöki munkaállomások biztonsági kérdéseire fókuszált, ezek mellett jóval kisebb figyelmet kaptak a Purdue modell első szintjére sorolt komponensek (szenzorok, szabályozó, elemző és vezérlő eszközök). Ezek gyakran még ma is soros porton kommunikálnak és egy soros-Ethernet átalakítón keresztül csatlakoznak a TCP/IP hálózatokra. A felsorolt eszközöknek még az OT által használt számítógépekénél is rosszabb a biztonsága, pedig a különböző ICS szerverek, HMI-ok, MMI-ok biztonsága is komoly hiányosságokkal küzd.

A Purdue referencia modell kialakításakor markáns elkülönítést fogalmaztak meg az alkotók az egyes szinteken működő eszközök között. Ahogy azonban a modern IT technológiái egyre inkább teret nyernek az ipari eszközökben, így a Purdue modell első szintjén üzemelő eszközökben is mind több IT komponens jelent meg, ami folyamatosan nehezebbé teszi, hogy az első szintet elválasszuk a második, de időnként még a harmadik szinttől is.

Felmerülhet a kérdés, hogy ez miért jelent problémát? A Purdue modell első szintjén működő eszközöket gyakran nevezik mező vagy gyártósori eszközöknek (field/plant floor device). Ezeket az eszközöket szinte minden esetben speciális fizikai igénybevételre (a normál IT eszközökhöz képest extrém meleg vagy hideg, por, vibráció, stb. elviselésére) tervezik, viszont a kiberbiztonsági kihívások megválaszolására kevés vagy éppen semennyi erőforrást sem fordítanak. Éppen emiatt a legtöbb mező/gyártósori eszköz számos alapvető kiberbiztonsági hiányosságot hordoz:

- Nincs vagy csak nagyon alapszintű biztonsági kontrollokkal rendelkeznek (pl. egyetlen, közös felhasználónév-jelszó, gyakori a beégetett jelszavak használata);
- Az általuk használt kommunikációs protokollokról (vezetékes és Wireless HART, Profibus, Fieldbus, stb.) számos alkalommal bizonyították már be, hogy komoly sérülékenységek találhatóak bennük, de az ipari rendszer hosszú életciklusa miatt a protokollok biztonságosabbra cserélése kifejezetten nehéz és lassú;
- Egyre több az IP-alapon kommunikáló eszköz és mind több eszköz képes vezeték nélküli kapcsolatot kiépíteni;
- Nő a száma azoknak az eszközöknek, amik már a Purdue modell több szintjén kommunikálnak., egyre gyakoribbak az olyan mező/gyártósori eszköz, ami közvetlenül küld adatokat a második/harmadik szinten üzemelő rendszerekbe.

A probléma tehát adott, a kérdés, hogy mit is kéne tennünk azért, hogy az ICS rendszereket üzemeletető szervezetek meg tudjanak felelni a kihívásnak és képesek legyenek megelőzni a komolyabb ICS kiberbiztonsági incidenseket. Amennyire én ma látom, erre a legjobb esély az lehet, ha a ma még élesen elkülönülő IT biztonsági és OT szakterületek elkezdenek végre együttműködni és megérteni a másik szakterület munkáját, prioritásait. Mindaddig, amíg az OT szakemberek többsége új keletű úri hóbortként tekint az IT biztonságra, aminek sem keresnivalója, sem hatása nem lehet az ipari rendszerekre, az IT biztonsági szakemberek nagy része pedig csak a 90-es évekből (vagy még korábbról) itt felejtett, múzeális számítógépeket látnak az ipari rendszerekben, nem lesz esélyünk eredményesen védekezni a mind nagyobb fenyegetések ellen.

ICS sérülékenységek CIX

Advantech, CyberVision és Schneider Electric rendszerek sérülékenységei

Az ICS-CERT weboldalán ismét több sérülékenységi bejelentés látott napvilágot.

Advantech B+B SmartWorx MESR901 Modbus gateway sérülékenység

A blogon már sokszor emlegetett Maxim Rupp ezúttal az Advantech B+B SmartWorx MESR901 Modbus gateway eszközeinek 1.5.2 és ennél korábbi verzióiban talált egy hibát, ami a kliens oldalon megvalósított authentikációra vezethető vissza.

Az ICS-CERT bejelentése szerint a gyártó nem képes(!) javítani a hibát és azon dolgozik, hogy a sérülékeny berendezéseket egy új modellel lehessen lecserélni!

A hibáról további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-122-03

CyberVision Kaa IoT Platform sérülékenység

Jacob Baines, a Tenable Network Security (többek között a Nessus automatizált sérülékenység vizsgáló szoftvert gyártó cég) munkatársa egy kódbefecskendezéses támadást lehetővé tevő hibát talált a CyberVision Kaa IoT Platform-jának 0.7.4 és feltételezhetően korábbi verzióiban.

A gyártó többszöri megkeresésre sem reagált, így a hibával kapcsolatban sem javítás, sem a sérülékenység okozta kockázatok csökkentésére vonatkozó gyártói javaslatok nem érhetőek el!

A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-122-02

Schneider Electric Wonderware Historian Client sérülékenység

Andrey Zhukov, a USSC munkatársa talált egy, a nem megfelelő XML-feldolgozásból adódó hibát a Schneider Electric Wonderware Historian Client 2014 R2 SP1 és korábbi verzióiban.

A gyártó a hiba javítását a HC_SecurityHF_10.6.13100 nevű frissítésben végezte el. Azoknak az ügyfeleknek, akik a Wonderware Historian Client 2014 R2 SP1-nél korábbi verzióját használják, előbb frissíteniük kell a 2014 R2 SP1-re, majd utána tudják telepíteni a HC_SecurityHF_10.6.13100-at.

A sérülékenységről további információkat a gyártó közleményéből vagy az ICS-CERT publikációjából lehet megtudni.

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áltasáok 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ű (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.

ICS sérülékenységek CVIII

Sérülékenységek Moxa, Hyundai Motor America, Sierra Wireless, BLF-Tech LLC és GE rendszerekbe

Moxa AWK-3131A sérülékenységek

A Cisco Talos munkatársa, Patrick DeSantis egy beégetett adminisztrátori hozzáférést talált a Moxa AWK-3131A sorozatú ipari IEEE 802.11a/b/g/n vezeték nélküli eszközeinek 1.1-es verziójában. A 94jo3dkru4 felhasználónévhez tartozó moxaiwroot jelszóval bárki teljes hozzáférést szerezhet a sérülékeny eszközökön. Az érintett eszközökön a legitim adminisztrátorok számára jelenleg nincs lehetőség a fenti felhasználói adatok megváltoztatására, a Talos és a Moxa csak azt tudja javasolni, hogy a sérülékeny eszközökön tiltsák le a távoli bejelentkezést lehetővé tevő szolgáltatásokat (SSH, Telnet).

A fenti, a CVSSv3-ban 10,0 pontra értékelt hiba mellett a Talos szakemberei számos egyéb  (XSS, CSRF, CLI, DoS, POODLE, DROWN, HTTP header injection, jelszavak olvasható formában történő továbbítását, információ-szivárgást lehetővé tevő) hibát is találtak.

A hibákról bővebben az alábbiakban lehet olvasni:

http://www.talosintelligence.com/reports/TALOS-2016-0225/
http://www.talosintelligence.com/reports/TALOS-2016-0230/
http://www.talosintelligence.com/reports/TALOS-2016-0232/
http://www.talosintelligence.com/reports/TALOS-2016-0233/
http://www.talosintelligence.com/reports/TALOS-2016-0234/
http://www.talosintelligence.com/reports/TALOS-2016-0236/
http://www.talosintelligence.com/reports/TALOS-2016-0237/
http://www.talosintelligence.com/reports/TALOS-2016-0238/
http://www.talosintelligence.com/reports/TALOS-2016-0239/
http://www.talosintelligence.com/reports/TALOS-2016-0240/
http://www.talosintelligence.com/reports/TALOS-2016-0241/
http://www.talosintelligence.com/reports/TALOS-2016-0235/
http://www.talosintelligence.com/reports/TALOS-2016-0231/

Hyundai Motor America Blue Link sérülékenységek

A Hyundai Motor America jármű-kezeléshez használt alkalmásának alábbi verzióiban Will Hatzer és Arjun Kumar, a Rapid7 munkatársai találtak hibákat:

- Blue Link 3.9.5 és
- Blue Link 3.9.4.

A kutatók a fenti verziókban beégetett titkosítási kulcsokat és egy közbeékelődéses (Man-in-the-Middle) támadásra lehetőséget adó hibát azonosítottak.

A gyártó a hibát javító verziót (Blue Link 3.9.6) Androidra 2017. március 6-án, iOS-re március 8-án adta ki.

A hibáról további részleteket a Rapid7 és az ICS-CERT publikációiban lehet találni.

Új információk a Sierra Wireless AirLink Raven XE és XT sérülékenységekkel kapcsolatban

Az ICS-CERT új információkat jelentetett meg a 2016. június 30-án publikált Sierra Wireless AirLink Raven XE és XT eszközöket érintő sérülékenységekkel (nem megfelelő jogosultságkezelés, CSRF, nem kellőképpen védett felhasználói adatok) kapcsolatban. A gyártó tavaly nyári nyilatkozatával ellentétben (hogy az AirLink Raven XE és XT sorozatú eszközök életciklusa lejárt és az akkor publikált hibák javítására nem fordítanak erőforrásokat) most mégis arról érkeztek hírek, hogy a Sierra Wireless mind a Raven XE, mind az XT sorozatú eszközökhöz elkészítette a fenti hibákat javító firmware-verziókat (a Raven XE-nél ez a 4.0.14, az XT-nél a 4.0.11).

További információkat (a firmware-ek letöltési hivatkozásait és a Sierra Wireless által kiadott Technical Bulletint) az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-17-115-02

BLF-Tech LLC VisualView HMI sérülékenység

Karn Ganeshen a BLF-Tech LLC által fejlesztett VisualView HMI 9.9.14.0 és korábbi verzióiban talált egy kártékony DLL felhasználásával tetszőleges kódfuttatásra lehetőséget adó hibát.

A gyártó a hibát a 10.2.15.0 verzióban javította.

A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-115-01

Sérülékenység a GE Multilin SR digitális védelmi reléiben

Anastasis Keliris, Charalambos Konstantinou, Marios Sazos, és Dr. Michail (Mihalis) Maniatakos, a New York-i egyetem kutatói a GE több digitális védelmi reléjében találtak olyan sérülékenységet, ami a jelszavak gyenge titkosításában ölt testet. Az érintett rendszerek:

- 750 Feeder védelmi relé, 7.47-nél korábbi firmware-verziókban;
- 760 Feeder védelmi relé, 7.47-nél korábbi firmware-verziókban;
- 469 Motor védelmi relé, 5.23-nál korábbi firmware-verziókban;
- 489 Generátor védelmi relé, 4.06-nál korábbi firmware-verziókban;
- 745 Transzformátor védelmi relé, 5.23-nál korábbi firmware-verziókban;
- 369 Motor védelmi relé, minden firmware-verzió esetén.

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

- 750 Feeder védelmi relé, 7.47;
- 760 Feeder védelmi relé, 7.47;
- 469 Motor védelmi relé, 5.23;
- 489 Generátor védelmi relé, 4.06;
- 745 Transzformátor védelmi relé, 5.23;
- 369 Motor védelmi relé - a GE a javítást ennél a rendszernél 2017. júniusra igéri.

A hibával kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-117-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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

ICS biztonság a termelésirányításban

A dolgok Internete után nem kellett sokat várni, hogy megjelenjen az ipari dolgok Internete (Industrial IoT) fogalom, valamint az okosautó, okoshűtő és az okosotthon után az okosgyár koncepciója. Az utóbbi hónapokban, egy évben pedig egyre gyakrabban lehet olvasni és hallani az Industry 4.0-ról, amit magyarul egy új ipari forradalomként, az ipar digitalizálásaként szoktak emlegetni.

Azok, akik szerint ez egy kifejezetten pozitív, innovatív és hasznos folyamat lesz, teljesen digitalizált, intelligens gyárakat látnak lelki szemeikkel, ahol mobil ultrahangos mérőberendezések vizsgálják a gyártósorok gépeit, hogy szükséges-e karbantartásra küldeni őket, vezető nélküli targoncák és villásemelők mozgatják az alkatrészeket és a kész termékeket és egymással együttműködő robotok teszik mind hatékonyabbá a gyártási folyamatokat.

Az IT és információbiztonsági szakértők igyekeznek óvatosságra inteni ezekkel a folyamatokkal kapcsolatban és ennek több oka is van.

Korábban már több posztban írtam róla, ahogy az ipari rendszerek (az automatizált gyártósorok és kapcsolódó rendszerek is ide tartoznak) egyre nagyobb mértékben integrálódnak a vállalati IT rendszerekkel, nagyságrendekkel nő annak a kockázata, hogy a vállalati rendszerek kompromittálásával támadók hozzáférhetnek a termelésirányításban nélkülözhetetlen ipari rendszerekhez is.

Ez a vélemény nem csak az enyém, az ipari rendszerek biztonságával foglalkozó szakemberek körében általános ez az aggodalom, ami abból a tényből ered (amint arról is számos esetben írtam), hogy a különböző ipari rendszerek, így a gyárak termelésirányító rendszerei sem úgy lettek tervezve és kialakítva, hogy az Internetre legyenek csatlakoztatva vagy hogy az IT biztonsági szempontok kiemelten lettek volna kezelve. Ráadásul amíg a gyárak és a termelésirányító rendszerek gyakran fejlett megfigyelő és riasztó rendszerekkel vannak felszerelve, a szoftverek és az alkalmazások monitoringja másodlagos vagy teljesen figyelmen kívül hagyott terület. Ez a gyakorlat a termelésirányítási rendszereknél ugyanúgy katasztrófális következményekkel járhat, mint a kritikus infrastuktúrákban használt folyamatirányító rendszereknél. Ha egy támadó képes hozzáférni a termelésirányító rendszerhez, akkor a termelő gépek és folyamatok irányítása mellett hozzáférhet a vállalat bizalmas, gyakran akár szabadalommal védett adataihoz is.

Ezeket a kockázatok a Stuxnet és a 2014-es, német acélkohó elleni támadás mutatták be a legjobban, mindkét esetben a termelésirányító rendszer kompromittálásával okoztak jelentős károkat a támadók. Egy tavalyi német kutatás szerint az ipari kémkedésre illetve az adott termékek visszafejtése a leggyakoribb okok között vannak, ami miatt a német vállalatok 70 %-át érintette a szoftverek és gépek illegális lemásolásából eredő 7,3 milliárd eurós veszteség.

Ha a termelő vállalatok valóban hosszú távú előnyöket várnak a negyedik ipari forradalomtól, akkor a technológiai fejlesztések mellett az IT biztonsági szabványokat is újra kell gondolniuk és frissíteniük kell. Az ICS kiberbiztonság egyik legnagyobb kihívása, hogy tradícionális biztonsági módszerekkel és eszközökkel próbálunk megvédeni olyan ipari rendszereket, amiknek gyakran a működését nem értjük pontosan, most pedig minden korábbinál nagyobb változások történnek az ICS rendszerek területén, ami miatt immár az OT sem képes az eddig fenntartott, nagyon mély tudásszintjét megőrizni. Ahhoz, hogy eséllyel vegyük fel a küzdelmet az ipari rendszereinket fenyegető támadókkal, a tradícionális módszereket és eszközöket ötvöznünk kell az új és innovatív biztonsági technológiákkal és eljárásokkal.

ICS sérülékenységek CVII

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

A gyártó bejelentése szerint a Cisco Industrial Ethernet 2000 Series Switch-ekben egy olyan hibát azonosítottak, amely lehetőséget ad egy támadónak, hogy hibásan formázott CIP cosmagokkal szolgáltatás-megtagadásos (DoS) támadást indíthat a sérülékeny hálózati eszközök ellen.

Bővebb információkat az érintett szoftver verziókról és a hiba javítását tartalmazó frissítésekről a Cisco bejelentésében és a megfelelő Bug ID-k alatt találhatnak a cég ügyfelei.

Folyamatosan nőtt az ICS rendszerek fenyegetettsége 2016 második felében

A Kaspersky az elmúlt héten hozta nyilvánosságra a 2016 második félévéről készült ICS biztonsági összefoglalóját. A felmérés adatai szerint 2016 második félévében (egy minimális decemberi csökkenés mellett) folyamatosan nőtt az ICS rendszerek esetén észlelt kiberbiztonsági incidensek száma,  átlagosan az összes, a Kaspersky által vizsgált ICS rendszerek 20-25 %-át érte támadás ebben az időszakban.

A fenyegetések döntő többsége (22 %-a) az Internet irányából érte a vizsgált ICS rendszereket, a második legnagyobb kockázatot továbbra is a különböző, ICS rendszerekben használt adathordozók jelentik (10,9 %-kal), a harmadik pedig az ICS rendszerekkel valamilyen formában (pl. mérnöki hordozható eszközökön működő) e-mail kliensek jelentik (8,1 %-kal). További támadási vektorokként jelennek meg a rendszerekről készített mentések (0,9 %), a hálózati megosztások (0,7 %), a Windows mentések másolata (0,5 %) és a felhős tárhelyek alkalmazása (0,1 %). A fentiekből jól látszik, hogy az ICS rendszerek fizikai szeparálása a vállalati IT hálózattól és az Internettől megbukott, mint önállóan hatékony, preventív biztonsági intézkedés az ICS rendszerek kiberbiztonságának megteremtése során. Ahelyett, hogy egy-egy támadási vektor elleni intézkedésekkel a szervezetek szétforgácsolnák az erőforrásaikat, egy átfogó és integrált, rendszeres és alapos kockázatelemzésen alapuló biztonsági intézkedéscsomagot kell kifejleszteni és alkalmazni.

A Kaspersky adatai alapján jól kirajzolódik, hogy a különböző kiberbiztonsági incidensek zöméért az átlagos IT rendszerek elleni támadásokért felelős malware-ek tehetőek felelőssé. Ezek a malware-ek jellemzően a fent vázolt módok valamelyikén találnak utat az ICS rendszerekig és jóval kevésbé jellemző, hogy kifejezetten az ICS rendszerek ellen fejlesztenék őket a támadók. Ennek ellenére az adatokból azt is le lehet szűrni, hogy az ICS rendszereket üzemeltető szervezetek elleni célzott támadások is egyre gyakoribbak. A Kaspersky egy széles körű, adathalász módszereket használó támadást figyelt meg, ami megfigyeléseik szerint 2016 júniusában kezdődött és 2017 március végén még tartott. Ez a támadássorozat 50 ország több, mint 500 vállalatát érintette, többek között a kohászati, villamosenergia-ipari és más szektorokban működő cégeket. A támadók jellemzően már ismert és a különböző motivációjú csoportok által már jóideje használt malware-családokat használják ezekhez a támadásokhoz is: euS, Pony/FareIT, Luminosity RAT, NetWire RAT, HawkEye, stb. Ezek a malware-ek a kiberbűnözők köreiben is igen népszerűek, de az ipari szereplők elleni támadásokhoz egyedi módosításokat is tartalmaznak.

A Kaspersky felmérésében szereplő incidensek között kiemelkedően sok a szolgáltatás-megtagadásos (DoS) támadás. Második helyen a távoli kódfuttatást lehetővé tevő hibák kihasználása áll, a harmadik pedig a fájl-manipulálásra építő támadások csoportja. A különböző (SQL és parancssori) kódbefecskendezéses támadások és a felhasználói fiókok manipulálására épülő támadások csak a lista végére fértek fel.

A Kaspersky CERT-jében dolgozó kutatók 2016 második felében összesen 75 különböző ICS rendszereket érintő sérülékenységet fedeztek fel, ezeknek 77 %-a (58 a 75-ből) a CVSSv3 alapján magas vagy kritikus besorolású volt (ez még az általam publikus forrásokból gyűjtött számoknál is rosszabb képet mutatnak, én tavaly július elejétől december végéig összesen 131 különböző ICS sérülékenységről szóló információt gyűjtöttem össze, ezek 66 %-a tartozott a magas vagy kritikus kockázatú csoportban).

A fenti fenyegetések az általános IT biztonsági kihívásokon túl további, elsősorban az ipari rendszerekre jellemző kihívásokat jelentenek az ICS rendszerek üzemeltetéséért és kiberbiztonságáért felelős szakemberek számára (ezek egy részét korábban már érintettük itt, a blogon is):

1. Az ipari rendszerek esetében az összetettségük és az integráltságuk a különböző IT rendszerekkel, együtt azzal, hogy a különböző gyártók hagyományosan minimális erőfeszítéseket tesznek a biztonságosabb rendszer/komponens kialakítása érdekében, jelentősen növeli az ismert és a nulladik napi sérülékenységek kihasználásának kockázatát. További problémákat okoz, hogy a gyártók még mindig nem priorizálják a feltárt hibák javítását a rendszereikben és az elkészült javításokat is inkább az új verziókban jelentetik meg, ahelyett, hogy patch-ek és hotfix-ek formájában minél több sérülékeny rendszer javítására törekednének. Emellett még mindig vannak olyan gyártók is, akik inkább megpróbálják titokban tartani és javítani a rendszereikben felfedezett hibákat.

2. A klasszikus IT biztonsági hármas (bizalmasság, sértetlenség, rendelkezésre állás) és az eszközök kompatibilitásának biztosítása közben a gyártók gyakran félreteszik a biztonságosabb rendszerek fejlesztésének szempontját, ezért sok esetben az ICS rendszerek gyenge biztonsági szinttel vagy kifejezetten sérülékeny megoldásokkal kerülnek üzembe helyezésre.

3. Az ICS/SCADA rendszerek jellemző biztonsági (safety) beállításai a legritkább esetben vannak felkészítve arra az esetre, amikor egy támadó szándékosan manipulálja a folyamatvezérlést vagy valaki ártó szándékkal használja a legitim jogosultságokat a rendszerben. Ez utóbbira a legjobb példa a két ukrán incidens 2015 és 2016 decemberében, de szerencsére ezekben az esetekben, amennyire tudhatjuk, személyi sérülés nem történt és arról sincs információ, hogy a SCADA rendszerek biztonsági (safety) funkcióit is manipulálták volna.

Botnetek ipari hálózatokban

A Kaspersky kutatói a vizsgált hálózatok 5 %-ában találtak aktívan működő botnetekhez tartozó eszközöket illetve olyan nyomokat, amik alapján korábban az adott hálózatban működtek botnetekhez tartozó eszközök. Ez ahhoz képest nagy szám, hogy a botnetek általános működési köre (pénzügyi és más Internetes szolgáltatásokhoz használt felhasználói adatok ellopása, levélszemét küldése, DoS-támadások indítása) nem jellemző az ipari rendszerekre. Bár ezek a botnet-műveletek alapvetően nem arra szolgálnak, hogy zavart okozzanak az ipari folyamatvezérlésben, az ICS rendszerek sok esetben olyan kicsi teljesítmény-tartalékkal működnek, hogy egy efféle extra funkció futása már hatással lehet a stabil működésre vagy kompatibilitási problémákat okozhat. További problémát okozhat, ha egy botnetbe bevont ipari eszköz publikus hálózaton kommunikál, előfordulhat, hogy a botnet forgalom miatt az ICS eszközhöz rendelt IP cím fekete vagy szürkelistára kerül egyes reputációs adatbázisokból dolgozó biztonsági megoldásoknál, ami az üzembiztonsági probémákon túl az adott szervezet jó hírét is csorbíthatja. A fertőzött ICS eszközök más jellegű fenyegetéseket is hordoznak. A botnet ügynökök jellemzően sok olyan adatot is összegyűjtenek a megfertőzött eszközökről, amelyek alapján egészen jól be lehet azonosítani az adott szervezetet, ráadásul a botneteket a DarkWeb-en/DeepWeb-en rendszeresen el- vagy bérbe adják, így akár egy célzott támadás megalapozásához is vezethet egy nem célzott malware-fertőzés.

A felmérés során gyűjtött adatok alapján az ICS rendszerekben a leggyakoribb botnet-építő malware az Andromeda volt, a második leggyakoribb a Zeus, harmadik pedig a Cryptowall.

A Kaspersky ICS-CERT által készített tanulmány teljes terjedelmében itt érhető el.

ICS sérülékenységek CVI

Sérülékenységek Wecon Technologies és Schneider Electric termékekben

A húsvét előtti pár napban megint több ICS rendszerrel kapcsolatos sérülékenység látott napvilágot.

Wecon Technologies LEVI Studio HMI Editor sérülékenységek

Andrea Micalizzi (rgod) a Wecon Technologies LEVI Studio HMI Editor összes verzióját érintő puffer-túlcsordulási hibákat talált. A gyártó a hibákat az 1.8.1-es verzióban javította, amit a weboldaláról lehet letölteni.

A sérülékenységekről további részleteket az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-103-01

Sérülékenységek Schneider Electric Modicon M221 PLC-kben és SoMachine Basic berendezésekben

Simon Heming, Maik Brüggemann, Hendrik Schwartke és Ralf Spenneberg, az Open Source Security munkatársai két sérülékenységet fedeztek fel a Schneider Electric alábbi termékeiben:

- Modicon M221 PLC, v1.5.0.1-nél korábbi firmware-verziói és
- SoMachine Basic, v1.5-nél korábbi verziók.

A most felfedezett sérülékenységek a fenti rendszerekben tárolt adatok védelmével kapcsolatos hibákon alapulnak. A rendszerekben beégetett titkosító kulcsok találhatóak illetve a Modbus-TCP protokollon keresztül küldött speciális parancs segítségével egy támadó hozzáférést szerezhet az alkalmazás védelméhez tartozó jelszóhoz.

A gyártó által közzétett ajánlások szerint a sérülékeny rendszereket használó ügyfelek számára javasolt biztonságos, szigorú hozzáférési szabályokkal védett és lehetőleg harmadik féltől származó titkosítással titkosított helyen tárolni a projekt fájlokat. A SoMachine Basic titkosító mechanizmusának javítása várhatóan 2017. június 15-én fog megjelenni.

A Schneider Electric további javaslatai a kockázatok csökkentése érdekében:

- Aktiválják az Application Protection funkciót az érintett eszközökön egy üres jelszóval, ahogyan a SoMachine Basic Súgójában a "Password Protecting an Application" fejezetben áll, ezzel kikapcsolva az M221-es PLC-kben az alkalmazás-feltöltés funkciót.
- Tűzfalak használatával blokkolni kell a távoli/külső hálózatokból történő 502/tcp (Modbus-TCP) port elérését az M221-es PLC-k esetén.

A hibákról részleteket a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

süti beállítások módosítása
Mobil