Pangea Communications rendszerek sérülékenysége

Ankit Anubhav, a NewSky Security munkatársa egy authentikáció megkerülést lehetővé tevő hibát fedezett fel a Pangea Communications Internet FAX ATA (Analóg-Telefon Adapter) berendezésének 3.1.8 és korábbi verzióiban.

A gyártó a hibát javító patch-et már elérhetővé tette az ügyfelei számára.

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-045-01

Sérülékenység a gpsd nyílt forráskódú projektben

A GE Digital Cyber Security Services a GE-PSIRT együttműködve jelentett egy sérülékenységet az NCCIC-nek, ami a nyílt forráskódú GPS megoldás alábbi szoftverkomponenseit érinti:

- gpsd 2.9.0-től 3.17-ig terjedő verziói,
- microjson 1.0-tól 1.3-ig terjedő verziói.

A hibát a fejlesztők a gpsd 3.18-as és újabb, illetve a microjson 1.4 és újabb verzióiban javították. 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-18-310-01

OSIsoft PI Vision sérülékenység

Az OSIsoft az alábbi, folyamatvirtualizációhoz használható megoldásaiban talált egy Cross-site Scripting sérülékenységet:

- PI Vision 2017,
- PI Vision 2017 R2.

A gyártó a hibát a PI Vision 2017 R2 SP1 verzióban javította. A sérülékenységgel kapcsolatoban részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-043-01

Sérülékenységek Intel szoftverekben

Az Intel Product Security Incident Response Team-je 11 különböző sérülékenységet azonosított és jelentett az NCCIC-nek, amik a gyártó Data Center Manager SDK 5.0.2-nél korábbi verzióit érintik.

Az Intel a sérülékenységeket a Data Center Manager SDK 5.0.2-es verziójában javította. A sérülékenységekkel kapcsolatban részletesebb információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-01

Delta CNCSoft sérülékenység

Natnael Samson a ZDI-vel együttműködve egy sérülékenységet azonosított a Delta Industrial Automation CNCSoft ScreenEditor 1.00.84 és korábbi verzióiban.

A gyártó a hibát az 1.01.15-ös verzióban javította. A sérülékenységről részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-02

Sérülékenység Horner Automation rendszerekben

Egy névtelenségbe burkolózó biztonsági kutató a ZDI-vel együttműködve azonosított egy hibát a Horner Automation Cscape szoftverének 9.80 SP4-es és korábbi verzióiban.

A gyártó a hibát a Cscape legutolsó, 9.90-es verziójá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-050-03

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

Luca Chiou, az ACSI munkatársa két sérülékenységet talált a Rockwell Automation Allen-Bradley Power Monitor 1000 összes verziójában.

A gyártó jelenleg is dolgozik a sérülékenységek javításán és megerősítette, hogy a CheckPoint IPS eszközei már képesek felismerni a sérülékenységeket kihasználni próbáló hálózati forgalmakat. A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-19-050-04

Sérülékenységek Siemens SIMATIC IPC-k Intel AMT komponenseiben

A Siemens ProductCERT bejelentése szerint az Intel AMT komponensek három sérülékenysége érinti az alábbi SIMATIC IPC berendezéseket:

- SIMATIC FieldPG M5 minden, v22.01.06-nál korábbi verziója;
- SIMATIC IPC427E minden, v21.01.09-nél korábbi verziója;
- SIMATIC IPC477E minden, v21.01.09-nél korábbi verziója;
- SIMATIC IPC547E minden, R1.30.0-nél korábbi verziója;
- SIMATIC IPC547G minden, R1.23.0-nál korábbi verziója;
- SIMATIC IPC627D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC647D minden, v19.01.14-nél korábbi verziója;
- SIMATIC IPC677D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC827D minden, v19.02.11-nél korábbi verziója;
- SIMATIC IPC847D minden, v19.01.14-nél korábbi verziója;
- SIMATIC ITP1000 minden, v23.01.04-nél korábbi verziója.

A gyártó a hibákat az érintett szoftverek legújabb verzióiban javította. A sérülékenységekről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Sérülékenység Siemens berendezésekben

Lars Lengersdorf, az Amprion munkatársa egy sérülékenységet azonosított a Siemens alábbi berendezéseiben:

- EN100 Ethernet modul IEC-61850 protokollhoz minden, v4.35-nél korábbi firmware-verzió esetén;
- EN100 Ethernet modul MODBUS/TCP protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul DNP3/TCP protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul IEC-104 protokollhoz minden firmware-verzió esetén;
- EN100 Ethernet modul Profinet IO protokollhoz minden firmware-verzió esetén;
- SIPROTEC 5 relék CP300 és CP100 processzorral szerelt példányainak minden, v7.82-nél korábbi verziója;
- SIPROTEC 5 relék CP200 processzorral szerelt példányainak minden, v7.58-nál korábbi verziója.

A hibát a gyártó az érintett eszközök legújabb firmware-verzióiban javította. A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT weboldalain lehet találni.

Siemens SICAM rendszerek licenckezelő szoftverének sérülékenységei

A Siemens három sérülékenységet jelentett az NCCIC-nek, amik a SICAM 230-as sorozatú berendezéseinek 7.20-as és korábbi verzióinál használt licenckezelő szoftverét érintik.

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

SPECTRE sérülékenység Siemes SIMATIC ipari vékonykliensekben

A Siemes ProductCERT bejelentése szerint az alábbi SIMATIC ipari vékonyklienseiket érintik a SPECTRE néven ismertté vált sérülékenység V1 és V4 variánsai:

- SIMATIC ITC1500 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1500 V3 PRO összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1900 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC1900 V3 PRO összes, V3.1-nél korábbi verziója;
- SIMATIC ITC2200 V3 összes, V3.1-nél korábbi verziója;
- SIMATIC ITC2200 V3 PRO összes, V3.1-nél korábbi verziója.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedésekre tett javaslatokat. A sérülékenységekről bővebb információkat a Siemens ProductCERT oldalán tettek közzé: https://cert-portal.siemens.com/productcert/pdf/ssa-505225.pdf

Sérülékenységek Schneider Electric SoMachine és Modicon rendszerekben

A Schneider Electric publikációja szerint több sérülékenységet azonosítottak az alábbi termékeikben:

- SoMachine Basic összes verziója;
- Modicon M221 minden verziója a V1.10.0.0-nál korábbi firmware-ek esetén.

A gyártó a hibákat a Modicon M221 V1.10.0.0 firmware-verziójában és az EcoStruxure Machine Expert – Basic v 1.0-ban javította. A sérülékenységekről részleteket a Schneider Electric publikációjában lehet találni.

Schneider Electric Vijeo Designer Lite sérülékenység

A Schneider Electric Vijeo Designer Lite nevű szoftverében, amit az alábbi berendezéseik konfigurációjához lehet használni, egy sérülékenységet azonosítottak:

- XBTN200;
- XBTN400;
- XBTN401;
- XBTN410;
- XBTNU400;
- XBTR400;
- XBTR410;
- XBTR411;
- XBTRT500;
- XBTRT511.

A Vijeo Designer Lite gyártói támogatása 2017 júniusában megszűnt, így a hiba kapcsán a gyártó csak kockázatcsökkentő intézkedéset javasol:

- A Vijeo Designer Lite-ot használó ügyfelei a szoftvert csak erre dedikált rendszeren használják a minimálisan szükséges jogosultságokkal rendelkező jogosultságokkal;
- Csak megbízható forrásból származó DOP projektfájlokat nyissanak meg.

A sérülékenységről több információt a Schneider Electric bejelentéséből lehet szerezni.

Sérülékenységek Schneider Electric ipari kamerákban

A Schneider Electric által közzétett információk szerint az alábbi ipari kameráikban több sérülékenység is található:

Pelco Sarix Enhanced első generációs kamerák:
- Beltéri kamerák:
- IMES19-1I, IMES19-1S, IMES19-1P;
- IME119-1I, IME119-1S, IME119-1P;
- IME219-1I, IME219-1S, IME219-1P;
- IME319-1I, IME319-1S, IME319-1P;
- IME319-B1I, IME319-B1S, IME319-B1P;
- IME3122-1I, IME3122-B1I, IME3122-1S, IME3122-B1S, IME3122-1P, IME3122-B1P;
- Környezeti kamerák, mini dómok:
- IMES19-1EI, IMES19-1ES, IMES19-1EP;
- IME119-1EI, IME119-1ES, IME119-1EP;
- IME219-1EI, IME219-1ES, IME219-1EP;
- IME319-1EI, IME319-1ES, IME319-1EP;
- IME3122-1EI, IME3122-1ES, IME3122-1EP;
- Vandálbiztos mini dómok:
- IMES19-1VI, IMES19-1VS, IMES19-1VP;
- IME119-1VI, IME119-1VS, IME119-1VP;
- IME219-1VI, IME219-1VS, IME219-1VP;
- IME319-1VI, IME319-1VS, IME319-1VP;
- IME3122-1VI, IME3122-1VS, IME3122-1VP;
- Box kamerák:
- IXES1;
- IXE11;
- IXE21;
- IXE31;
Spectra Enchanced kamerák:
- D6220, D6220L;
- D6230, D6230L.

A gyártó a hibákat a Sarix Enchanced kamerák 2.2.3.0 és a Spectra Enchanced 2.11-es és újabb verziójú firmware-jeiben javította. A sérülékenységekkel kapcsolatban további információkat a Schneider Electric weboldalán 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.

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.