Az IT biztonság területén már viszonylag megszokott az új típusú kártevők és fenyegetések felbukkanása, így volt ez a zsarolóvírusokkal is, amelyek néhány évvel ezelőtti felbukkanása után elég gyorsan meg kellett szokni a létezésüket és meg kellett tanulniuk az érintett szakembereknek együttélni ezekkel az új fenyegetésekkel. 2017-ben a WannaCry, majd a NotPetya támadások idején az ICS rendszerek egy része szintén érintett volt, de nem volt információnk olyan titkosító-zsaroló malware-ről, amit kifejezetten ICS rendszerek ellen terveztek és vetettek volna be. Eddig.

Az ESET blogján most szerdán jelent meg az a cikk, amiben a bűnözők egyik új taktikáját mutatják be, neveztesen az épület-automatizálási rendszerek (Business Automation Systems) elleni zsarolóvírus támadásokat. A jelenségnek már saját neve is van, a kutató siegeware-nek nevezték, magyarul szó szerinti fordításban ostromvírusnak lehet fordítani, de én ezt kicsit esetlennek érzem, ezért inkább az eredeti megnevezéssel fogok hivatkozni ezekre az új kártevőkre.

Nagyon röviden, hogy mik is az épületautomatizálási rendszerek. A BAS rendszerek jellemzően a nagyobb épületek üzemeltetéséhez szükséges folyamatok automatizlását lehetővé tevő rendszerek (füstérzékelő és tűzjelző rendszerek, központi hűtő-, fűtő- és légkondícionáló rendszerek, automata tűzoltó rendszerek, világításvezérlő rendszerek, az épületekbe integrált biztonsági és fizikai hozzáférés-vezérlő, beléptető rendszerek, épületen belüli villamosenergia-menedzsment rendszerek, különösen az adatközpontok szünetmentes tápellátását biztosító rendszerek, stb.).

Most képzeljük el azt az esetet, amikor egy nagy irodaházat üzemeltető cég dolgozói egy e-mail vagy SMS üzenetet kapnak az alábbi szöveggel: “Az xxxxxxxx címen található épület összes vezérlő rendszere felett átvettük az irányítást és leállítjuk őket, amennyiben nem fizetnek 24 órán belül 10.000.000 Forintot Bitcoinban az alábbi számlára.” Hogy ilyen csak a filmekben történhet? Már többször megtörtént, legalábbis a hivatkozott ESET cikk szerint, ami azt állítja, hogy egy, a fentihez hasonló esetben a rendőrséghez forduló áldozatnak a hatóság emberei állították, hogy nem az első ilyen panasz érkezik hozzájuk.

Hogyan lehetséges egyáltalán egy ilyen támadást végrehajtani? Anélkül, hogy tippeket akarnék adni a támadóknak, azt tudom mondani, hogy pont ugyanúgy, mint bármilyen más ICS rendszer elleni támadás esetén:

1. A BAS rendszerek egy jelentős hányada minden ellenkező ajánlás ellenére elérhető az Interneten, egy gyors Shodan vagy Censys keresés akár több 10.000 találatot is adhat.

2. A BAS rendszerek általános kiberbiztonsági állapota semmivel sem jobb (vagy ami azt illeti, rosszabb), mint az átlagos ICS rendszereké, ami ugye azt jelenti, hogy elég gyenge.

A helyzet tehát az, hogy (ahogy azt 2017 illetve 2018 végén a szakértők már jósolták) egyre terjednek az ICS rendszereket célzó malware-ek és támadások. Lehetséges, hogy kicsit lassabban, mint ahogyan vártuk, de ezek a (időnként még csak elméleti) fenyegetések egyre inkább valósággá válnak, az ICS rendszereket üzemeltetőknek pedig időben el kell kezdeniük felkészülni arra, hogy az ő rendszereik is célponttá válhatnak.

Kifejezetten érdekes a BAS rendszerek és üzemeltetőik helyzete, hiszen a nagyobb irodaházak mellett minden nagyobb adatközpontban is megtalálhatóak ezek a rendszerek, tehát még arra sincsen szükség, hogy az adott szervezet ipari tevékenységet (közmű-szolgáltatás, gyártás, stb.) végezzen, elég, ha a támadók egy nagyobb bank adatközponti BAS rendszereit támadják siegeware-rel - vajon melyik bank vállalja azt, hogy akár napokra leállnak a legfontosabb rendszerei vagy inkább fizetnek a támadóknak?

Nemrég egy kollégától kaptam ennek az előadásnak a hivatkozását, amiben Andreas Klien, az OMIRCRON osztrák munkatársa nagyon jól foglalja össze a főként az alállomási automatizálásban használt IEC 61850-es ipari protokoll kiberbiztonsági problémáit és a lehetséges támadási formákat. Az előadásban megjelennek magukat régóta makacsul tartó mítoszok ("Miért kéne foglalkozni az alállomási berendezések kiberbiztonságával, ha egy teherautóval is be lehet törni az alállomásra?" vagy "A soros porti kommunikáció és a régi, nem dokumentált protokollok biztonságosabban, mint az Ethernet portok és a modern, nyílt protokollok.")

Az előadás egyik legfontosabb gondolata a kockázatkezelés és nagyon helyesen kiemeli azt is, hogy a legfőbb kockázatok egyike a folyamatok irányításába bevont ember és így a leghatékonyabb és legfenyegetőbb támadási formák egyike a social engineering.

Úgy gondolom, hogy az ilyen szakmai előadásoknak nagyon nagy szerep hárulhatna a hazai szakma ICS biztonságtudatosságának javításában (sajnos még mindig azt tapasztalom, hogy néhány elszánt úttörőtől eltekintve a szakma legtöbb képviselője nem kér az OT és az IT biztonsági szakterületek együttműködéséből, hiszen mennyivel könnyebb ülni a saját elefántcsont-tornyunkban és onnan hibáztatni mindenki mást a jelenlegi rossz - és folyamatosan romló - ICS kiberbiztonsági helyzetért). A feladat kiindulva az ipari szervezeteket még 2019-ben is jellemző merev, hierarchikus struktúrákból, elsősorban a menedzsmenté, a szakemberek legfontosabb dolga ebben a témában - azon túl, hogy nyitottak legyenek a többi szakterületen dolgozó kolléga javaslataira - az, hogy meggyőzzék a menedzsmentet az ilyen jellegű együttműködések nélkülözhetetlenségéről.

Stryker orvosi eszközök sérülékenysége

Mathy Vanhoef, a Leuven-i Katolikus Egyetemen működő imec-DistriNet munkatársa a KRACK (a több, mint egy éve felfedezett, WPA és WPA2 titkosításokat érintő) sérülékenység újabb érintett rendszereit azonosította, ezúttal a Stryker alábbi, gyógyászatban használt rendszereit, amennyiben azokban engedélyezve van az iBed Wireless funkció):

- Secure II MedSurg Bed, Model: 3002;
- S3 MedSurg Bed, Models 3002 S3 és 3005 S3;
- InTouch ICU Bed, Model 2131 és 2141.

A gyártó az érintett termékek közül a Gateway 1.0-hoz nem, a Gateway 2.0 és a Gateway 3.0 verziókhoz elérhetővé tette a javítást. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-029-01

Sérülékenység BD FACSLyric rendszerekben

A Becton, Dickinson and Company (BD) egy sérülékenységet azonosított az alábbi termékeiben:

- BD FACSLyric, Windows 10 kutatói változat, amerikai és malájziai kiadások;
- BD FACSLyric IVD Windows 10 amerikai kiadás.

A gyártó a rendelkezésre álló információk szerint fel fogja venni a kapcsolatot az érintett ügyfélkörrel a javítással illetve a kockázatcsökkentő intézkedések részletei miatt. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-029-02

Yokogawa rendszerek sérülékenysége

A Kaspersky Lab egy, a feltöltött fájlok nem megfelelő ellenőrzéséből adódó sérülékenységet azonosított a Yokogawa License Manager szolgáltatást használó alábbi termékeiben:

- CENTUM VP (R5.01.00 - R6.06.00);
- CENTUM VP Entry Class (R5.01.00 - R6.06.00);
- ProSafe-RS (R3.01.00 - R4.04.00);
- PRM (R4.01.00 – R4.02.00);
- B/M9000 VP (R7.01.01 - R8.02.03).

A gyártó a hiba javítása érdekében az érintett termékek legújabb, elérhető verzióra történő frissítését javasolja. A sérülékenységgel kapcsolatos részletes információk az ICS-CERT weboldalán érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-19-029-01

Sérülékenység Mitsubishi Electric PLC-kben

Tri Quach, az Amazon Customer Fulfillment Technology Security csoportjának munkatársa egy sérülékenységet fedezett fel a Mitsubishi Electric alábbi, MELSEC-Q sorozató PLC-iben:

- Q03/04/06/13/26UDVCPU: 20081 és korábbi sorozatszámú termékek;
- Q04/06/13/26UDPVCPU: 20081 és korábbi sorozatszámú termékek;
- Q03UDECPU, Q04/06/10/13/20/26/50/100UDEHCPU: 20101 és korábbi sorozatszámú termékek.

A gyártó a hibát a legújabb firmware-verzióban javította. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-029-02

AVEVA Wonderware sérülékenység

Vladimir Dashchenko, a Kaspersky Lab munkatársa egy, a felhasználói adatok nem megfelelő védelmére visszavezethető sérülékenységet azonosított az AVEVA Wonderware System Platform 2017 Update 2 és korábbi verzióiban.

A gyártó a hibát a Wonderware System Platform 2017 Update 3-ban javította. A sérülékenységgel kapcsolatban további információk az ICS-CERT bejelentésében érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-19-029-03

IDenticard PremiSys sérülékenységek

Jimi Sebree a Tenable-vel együttműködve három sérülékenységet talált az IDenticard PremiSys minden, 4.1-nél korábbi verziójában.

A gyártó a beégetett felhasználói azonosítók hibát a 4.1-es verzióban javította, a másik két hibára februárban ígér javítást. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-031-02

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

Vladimir Kononovich és Vyacheslav Moskvin, a Positive Technologies munkatársai három sérülékenységet találtak a Schneider Electric EVLink Parking 3.2.0-12_v1 és korábbi verzióiban.

A gyártó a javítást tartalmazó verziót már elérhetővé tette és azt javasolja, hogy a töltőállomások távoli hozzáférését tűzfallal védjék. A sérülékenységekről további információkat a Schneider Electric és az ICS-CERT weboldalain lehet találni.

Sérülékenységek Aveva InduSoft és InTouch rendszerekben

Az AVEVA a Tenable-vel együttműködve két sérülékenységről hozott nyilvánosságra részleteket, amik az alábbi termékeiket érintik:

- InduSoft Web Studio 8.1 SP3-nál korábbi verziói;
- InTouch Edge HMI (korábbi nevén InTouch Machine Edition) 2017 Update-nél korábbi verziók.

A gyártó a hibákat az érintett szoftverek legújabb verzióiban javította. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-036-01

Rockwell Automation rendszerek sérülékenységei

A Rockwell Automation a Tenable-vel közösen egy sérülékenységet jelentett az NCCIC-nek, ami a következő rendszereiket érinti:

- 1756-EWEB (és a 1756-EWEBK) 5.001 és korábbi verziói;
- CompactLogix 1768-EWEB 2.005 és korábbi verziói.

A gyártó a sérülékenységgel kapcsolatban kockázatcsökkentő intézkedésként azt javasolja az ügyfeleinek, hogy amennyiben nem használják, kapcsolják ki az érintett rendszerekben az SNMP-szolgáltatást. A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-036-02

WECON LeviStudio sérülékenységek

Mat Powell, Ziad Badawi és Natnael Samson, a ZDI-vel együttműködve három sérülékenységet azonosítottak a WECON LeviStudio 1.8.56-os és korábbi verzióiban.

A gyártó a sérülékenységeket az érintett termék legújabb verziójában javította. A sérülékenységekről további részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-036-03

Sérülékenységek Kunbus termékekben

Nicolas Merle, az Applied Risk munkatársa öt sérülékenységet fedezett fel a Kunbus PR100088 Modbus gateway termékének 1.1.13166-osnál korábbi verzióiban.

A gyártó a hibákat az 1.1.13166 (Version R02) verzióban javította. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-036-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á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.

Tavaly év végén, az ENISA jelentős mértékű megerősítéséről és bővítéséről hozott döntést az EU, ezzel párhuzamosan adta ki az IoT és az Ipar 4.0 biztonságával foglalkozó tanulmányát az ENISA.

A negyedik ipari forradalom a tanulmány szerint immár elválaszthatatlan a kiberbiztonság témájától, ezt mutatják az egyre szaporodó, ipari IT rendszereket érintő incidensek, különösen azoknál az ipari szereplőknél, ahol az IoT megoldásokat a fizikai folyamatok irányításához is felhasználják.

A tanulmányban az ENISA szakemberei összegyűjtötték azokat az útmutatókat és biztonsági intézkedéseket, amelyek segítséget nyújhatnak az Ipar 4.0 irányába fejlesztő ipari szervezeteknek.

Az ENISA tanulmánya itt érhető el.

Sérülékenységek Johnson Controls rendszerekben

Az ICS-CERT publikációja szerint a Tridium Niagara két sérülékenységről adott információt a Johnson Controls-nak, amik a gyártó alábbi termékeit érintik:

- Facility Explorer 14.4u1-nél korábbi 14-es verziói;
- Facility Explorer 6.6-nál korábbi 6-os verziói.

A gyártó a hibát a 14.6-os, 14.4u1-es és 6.6-os Facility Explorer verziókban javította. A sérülékenységekről további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-022-01

Dräger rendszerek sérülékenységei

Marc Ruef és Rocco Gagliardi a scip AG munkatársai 3 sérülékenységet azonosítottak a Dräger betegmonitorozásra használt alábbi rendszereiben:

- Infinity Delta, minden verzió;
- Delta XL, minden verzió;
- Kappa, minden verzió;
- Infinity Explorer C700, minden verzió.

A gyártó a hibák javítását tartalmazó verziókat 2018 decemberében elérhetővé tette. A sérülékenységekről bővebben az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-19-022-01

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

Devesh Logendran of Attila Cybertech Pte. Ltd. munkatársa 3 sérülékenységet fedezett fel az Advantech WebAccess/SCADA 8.3-as verziójában.

A gyártó a hibákat a 8.3.5-ös verzióban javította. A sérülékenységekről részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-024-01

Sérülékenységek Phoenix Contact rendszerekben

A Phoenix Contact a Positive Technologies munkatársaival, Evgeniy Druzhinin-nal, Ilya Karpov-val és Georgy Zaytsev-vel együttműködve 6 sérülékenységet azonosíottak, amik a gyártó FL SWITCH 3xxx, 4xxx és 48xx sorozatú eszközeinek 1.35-ösnél korábbi verzióit érintik.

A gyártó a hibát az 1.35-ös és újabb verzióban javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-024-02

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.

Elég sokszor esik szó az ICS biztonság világában arról, hogy az USA villamosenergia-rendszerét különböző támadók, idegen hatalmak próbálják kompromittálni, legtöbbször az oroszokat, kínaiakat és az irániakat említik, amikor megnevezik, hogy elsősorban kik állhatnak a támadások mögött. Ezek a hírek láthatóan az USA hivatalos szerveit is aggasztják, ennek jele volt tavaly nyáron a két héten át tartó DHS webinar-sorozat is.

2018 novemberében a DARPA, az amerikai védelmi kutatásokkal foglalkozó ügynökség a Long Island (New York állam) melletti kis szigeten, Plum Island-en az USA villamosenergia-rendszerét ért kibertámadást szimuláló gyakorlatot tartott. A gyakorlat célja az volt, hogy minél életszerűbb körülmények között tudják tesztelni egy, a teljes villamosenergia-rendszert érintő leállás utáni újrainduláshoz használatos eljárásokat. Ehhez Plum Island kifejezetten alkalmas, mert a New York-i Central Park-nál alig nagyobb szigeten 18 alállomás, két vezénylőközpont és két erőmű is van.

A gyakorlatról bővebben a Sophos Naked Security blogjában lehet olvasni, a DARPA pedig már az idén májusra tervezett, a korábbinál is összetettebb gyakorlat előkészítésén dolgozik, hiszen ahogy láthattuk az elmúlt években, a villamosenergia-rendszer elleni támadások egyre gyakoribbak. Már csak az a kérdés, hogy Európában illetve Magyarországon mikor lesz ilyen gyakorlat (hozzátéve, hogy 2014-ben már volt egy kezdeményezés és egy gyakorlat, aminek azóta sajnos érdemi folytatása a villamosenergia-szektorban nem volt)?

A CVSS (Common Vulnerability Scoring System) rendszer széles körben ismert és használt az informatikai rendszerek sérülékenységeinek osztályozásához. Jelenleg a CVSSv3 az általánosan használt módszer, ami lehetőséget ad egy alap pontszám kalkulálására a támadási vektor, a támadás komplexitása, a szükséges jogosultságok és felhasználói interakció, a sérülékenység hatókörének és a bizalmasság-sértetlenség-rendelkezésre állás hármas faktorok figyelembe vételével.

Október végén, az atlantai ICS Cyber Security konferencián a Radiflow alapító-vezérigazgatója, Ilan Barda előadásában arra hívta fel a figyelmet, hogy a CVSS pontozásos módszerét eredetileg IT rendszerekre dolgozták ki és ismerve az IT és ICS rendszerek közötti különbségeket, ez problémákat jelenthet az érintett (jellemzően ipari) szervezetek számára.

Számos további ICS biztonsági szakértő (többek között a Nozomi Networks-től, a Positive Technologies-tól, a Kaspersky Lab ICS-CERT-jétől, stb.) is megszólalt a témában és a véleményeik nagyjából egyezik abban, hogy a CVSS alapján történő sérülékenység-kategorizálás hasznos útmutató lehet, de nem szabad csak erre építeni és vakon bízni benne, sokkal inkább csak kiindulási pontként célszerű használni az egyes sérülékenységek adott szervezetre vonatkozó.

A hivatkozott előadás videója itt érhető el, a témában írt SecurityWeek cikk pedig itt, amiben több példán is bemutatják, hogyan vezethet félre ICS sérülékenységek esetén, ha kizárólag a CVSS-besorolás alapján ítéljük meg egy-egy ICS sérülékenység kockázatait.

Sérülékenységek LCDS LAquis SCADA rendszerekben

Esteban Ruiz (mr me) a ZDI-vel együttműködve nem kevesebb, mint 11 különböző sérülékenységet azonosított az LCDS (Leão Consultoria e Desenvolvimento de Sistemas Ltda ME) LAquis SCADA nevű SCADA rendszerének 4.1.0.3870-es verziójában.

A gyártó a hibákat a 4.1.0.4150-es verzióban javította. A sérülékenységekről részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-19-015-01

ControlByWeb berendezések sérülékenységei

John Elder és Tom Westenberg, az Applied Risk munkatársai a ControlByWeb X-320M típusú időjárás-előrejelzéshez használt berendezéseinek v1.05 és korábbi firmware-verzióiban találtak két sérülékenységet.

A gyártó a hibákat a v1.06-os firmware-ben javította. A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-017-03

Sérülékenység ABB szoftverekben

Ivan Sanchez, a NullCode munkatársa egy sérülékenységet azonosított az ABB Control Panel Software Suite csomagjához tartozó CP400PB, a CP405-ös és CP408-as berendezésekhez használható Panel Builder szoftverének 2.0.7.05-ös és korábbi verzióiban.

A gyártó a hibát a 2.1.7.21-es 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-19-017-02

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

Esteban Ruiz (mr me) a ZDI-vel együttműködve 5 sérülékenységet azonosított az Omron CX-Supervisor 3.42 és korábbi verzióiban.

A gyártó a hibákat a 3.5.0.11-es verzióban javította. A sérülékenységek részleteit az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-19-017-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.

A hét elején rendezték Miami-ban az év hagyományosan első ICS biztonsági rendezvényét, az S4x-et. Az idei konferencia egyik legnagyobb visszhangot kapott előadása a Triton/Trisis néven ismertté vált, Schneider Electric Triconex safety rendszereket célzó malware és a szaúdi incidens részletesebb elemzésével foglalkozó előadás volt.

Az előadás szerint a korábban publikált információkkal szemben nem kettő, hanem 6 rendszert érintett az incidens és a vizsgálatban résztvevő kutatók szerint az incidens előtt két hónappal lett volna lehetőség a malware felfedezésére és a támadás megállítására. Állításuk szerint az első esetet a gyártó nem kezelte kibertámadásként és így nem is tették meg azokat az intézkedéseket, amik lehetővé tették volna a malware teljes eltávolítását a megtámadott rendszerekből, ez csak két hónappal később, 2017 augusztusában történt meg.

Az incidens több szempontból is úttörőnek számít, ez az első dokumentált eset, amikor a támadók kifejezetten a safety rendszereket célozták és legalábbis szokatlannak számít az is, ahogy a gyártó Schneider Electric publikussá tette a támadás nyomán indított vizsgálata során feltárt részleteket - ilyet eddig ICS/SCADA gyártótól még nem láttunk, de nagyon hasznos információforrás lehet nem csak az érintett safety rendszereket használó többi Schneider Electric ügyfélnek, hanem általában az ICS biztonsággal foglalkozó szakembereknek. Ritka az is, hogy az előadásban elhangzottakra (ti. hogy a gyártó az első, júniusi safety kontroller leállásnál nem ismerte fel, hogy kibertámadás okozta az eszköz leállását) a Schneider Electric viszonylag gyorsan reagált és rámutatott, miért nem volt lehetőségük ennél az esetnél felismerni, hogy malware-támadás áll az eset hátterében.

Az előadásról további részleteket a DarkReading illetve a CyberScoop cikkeiben lehet olvasni.

Tridium Niagara termékcsalád sérülékenység

Daniel Santos és Elisa Costante, a SecurityMatters munkatársai egy Cross-Site Scripting sérülékenységet találtak a Tridium Niagara termékcsaládjának alábbi tagjaiban:

- Niagara Enterprise Security 2.3u1 minden, 2.3.118.6-nál régebbi verziója;
- Niagara AX 3.8u4 minden, 3.8.401.1-nél korábbi verziója;
- Niagara 4.4u2 minden, 4.4.93.40.2-nél régebbi verziója;
- Niagara 4.6 minden, 4.6.96.28.4-nél korábbi verziója.

A hibát a gyártó az egyes termékek legújabb verziójában javította. A sérülékenység részletei az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-333-02

Sérülékenység Emerson DeltaV rendszerekben

Alexander Nochvay, a Kaspersky Lab munkatársa egy authentikáció megkerülést lehetővé tevő hibát azonosított az Emerson DeltaV DCS rendszereinek 11.3.1, 11.3.2, 12.3.1, 13.3.1, 14.3, R5.1, R6 és korábbi verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-010-01

Omron rendszerek sérülékenysége

Esteban Ruiz (mr_me), a Source Incite munkatársa a ZDI-vel együttműködve egy sérülékenységről hozott nyilvánosságra információkat, ami az Omron alábbi rendszereit érinti:

- CX-One 4.50 és korábbi verziói;
- CX-Protocol 2.0 és korábbi verziói.

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

Sérülékenység Pilz rendszerekben

Gjoko Krstikj, az Applied Risk munkatársa egy eddig ismeretlen sérülékenységet talált a Pilz PNOZmulti Configurator 10.9 és korábbi verzióiban, ami egy safety rendszerek konfigurálásához használható szoftver.

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

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.