Sérülékenységek Selix és GE Healthcare rendszerekben

Az ICS-CERT publikációja szerint Eric Evenchick, az Atredis Partners munkatársa két sérülékenységet talált a Selix alábbi rendszereiben:

- GEH-500 1.54 és korábbi verziói;
- SX-500 minden verziója (a termék gyártói támogatása 2011-ben megszűnt);
- GEH-SD-320AN, GEH-1.1-es és korábbi verziók;
- SD-320AN, 2.01-s és korábbi verziók (a termék gyártói támogatása 2017-ben megszűnt).

A GEH-500-as és GEH-SD-320AN eszközöket az alábbi GE Healthcare rendszerekben is felhasználták, így a sérülékenységek ezeket is érintik:

- MAC 3500;
- MAC 5000 (a termék gyártói támogatása 2012-ben megszűnt);
- MAC 5500;
- MAC 5500 HD.

A gyártók a hibák javításán jelenleg is dolgoznak. A sérülékenységek részleteiről az ICS-CERT weboldalán lehet bővebb információkat találni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-128-01

Rockwell Automation FactoryTalk Activation Manager sérülékenységek

Az ICS-CERT bejelentése szerint a Rockwell Automation két sérülékenységet azonosított a FactoryTalk Activation Manager nevű megoldásában. A hibák az alábbi verziókat és a velük érkező termékeiket érintik:

- FactoryTalk Activation Manager v4.00 és v4.01, amiket a Wibu-Systems CodeMeter v6.50b és korábbi verzióihoz használnak;
- FactoryTalk Activation Manager v4.00, amit a FlexNet Publisher v11.11.1.1 és korábbi verzióinál alkalmaznak.

A gyártó a hibákat javító újabb verziókat már elérhetővé tette.

A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-102-02

Sérülékenység Rockwell Automation Arena rendszerekben

Az ICS-CERT publikációja szerint Ariele Caltabiano, a ZDI-vel együttműködve egy memóriakezelési hibát jelentett az NCCIC-nek, ami a Rockwell Automation Arena rendszereinek 15.10.00 és korábbi verzióit érinti.

A gyártó a hibát az Arena 15.10.01-es verzióban javította.

A sérülékenységről bővebben az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-130-02

Sérülékenység MatrikonOPC rendszerekben

Ilya Karpov, a Positive Technologies munkatársa egy sérülékenységet jelentett a MatrikonOPC-nek, ami a MatrikonOPC Explorer 5.0 és korábbi verzióit érinti és amit kihasználva egy támadó a rendszer fájljaihoz és könyvtáraihoz szerezhet hozzáférést.

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

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

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

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

Manapság az ICS világában egyre többször lehet hallani az IIoT kifejezést és bár az IoT (Internet of Things) mára a mindennapjaink részévé vált, a többség nem igazán érti, hogy mit is jelent az ipari dolgok Internete, ezért úgy döntöttem, hogy a mai posztban ezt fogom egy kicsit körüljárni (egyébként is úgy látszik a blog statisztikáiból, hogy az alapfogalmak posztjai stabilan a leginkább látogatott oldalak, nem ide számítva néhány nagy érdeklődésre számot tartó esetet, mint például az ICS rendszerben talált cryptobányász malware-ről szóló poszt).

Szóval az IoT-t már minden kisgyerek is ismeri (láttam már alig másfél éves gyereket olyan biztonsággal tabletet kezelni, hogy az döbbenet) és lassan minden második nagymamánál is okostelefon van, de mi is az az IIoT?

Az ipari dolgok Internete kifejezés röviden azoknak az alkalmazásoknak, eszközöknek és szenzoroknak az összessége, amiket ipari környezetekben (például a szállítmányozásban, az energia és közműszektorban, különböző termelőüzemekben és hasonló ipari területeken) használnak, hogy az automatizálás egy új szintjét tudják megvalósítani (ez az, amiről Industry 4.0-ként vagy negyedik ipari forradalomként is szoktak beszélni, aminek a minél nagyobb fokú automatizálás a lényege, bulvárosan szólva a gépek elveszik a munkánkat...).

A gyakorlatban az IIoT lefed mindent a legegyszerűbb ipari automatizálástól a legbonyolultabb önműködő gyártósorokig, ahol akár még a karbantartási ciklusokat is a szenzoroktól gyűjtött adatok alapján tervezi és hajtja végre a rendszer, minimális emberi beavatkozást igényelve.

Miben más és miben hasonlít egymásra az IIoT és az IoT?

Kezdjük talán azzal, miben hasonlít az IIoT és az IoT: nagyon röviden fogalmazva ez a működési elv és mód. Jellemzően nagyon hasonló kommunikációs módokat használnak (bár az ipari eszközöknek van néhány csak rájuk jellemző vezeték nélküli kommunikációs protokollja, ilyen pl. a BGAN, a VSAT, a ZigBee vagy a WirelessHART) és - sajnos - a biztonsági hibák és hiányosságok területén is nagyon sok hasonlóságot lehet felfedezni.

Különbségből viszont már jóval több van. Az IIoT elsősorban a különböző gépek és berendezések összekapcsolására koncentrál, szemben az IoT eszközökkel, amik jellemzően az átlag fogyasztók igényeinek kiszolgálására fókuszálnak (ide értve az okostelefonoktól a fitnesz-karkötőkön át az okoshűtőig nagyjából minden, hálózaton kommunikálni képes eszközt). A legfontosabb különbség, hogy az IoT eszközök hibás működése vagy működésképtelensége nem okoz vészhelyzetet - szemben egyes ipari rendszerekkel, ahol egy rendszerhiba vagy leállás magas kockázatú vagy akár életveszélyes helyzeteket is teremthet, de jobb esetben is nagyon súlyos anyagi veszteségek okozója lehet.

Ugyancsak nagy különbség van az IoT és IIoT eszközök élettartamában. Az IoT esetében egy két éves eszköz már elavultnak számít, gondolom mindenki ismer legalább egy olyan embert, aki pl. évente cserél telefont, mert az újabb mindig jobb(?), az ipari eszközöknél viszont mind a mai napig bevett szokás 10-15-20 évre tervezni egy-egy nagyobb értékű berendezéssel és ez alól az IIoT eszközök sem kivételek.

A jóval hosszabb élettartam mellett figyelemmel kell lenni arra is, hogy az IIoT eszközöknek gyakran sokkal mostohább környezetben (szélsőséges hidegben vagy melegben, porban, vizes vagy más folyadékokkal szennyezet környezetben, stb.) kell működniük megbízhatóan. Egyes eszköz-kategóriákban (pl. hálózati eszközök) már régóta létezik az ún. ruggedized kategória, ami kifejezetten az ipari környezetbe tervezett eszközök kategóriáját jelenti.

Jellemzően milyen területeken használják az IIoT-t?

Az Industrial IoT Consortium összeállított egy 15 tételes listát az IIoT lehetséges felhasználási területeiről, ezek a következők:

- Okosgyárak raktározási alkalmazásai;
- Prediktív és távoli karbantartás;
- Áruszállítás nyomonkövetése;
- Hálózatintegrált logisztika;
- Okosmérés és okos villamosenergia-hálózat;
- Okosvárosok alkalmazásai;
- Okosfarmok és állatállomány felügyelete;
- Ipari biztonsági (security) berendezések;
- Energia-felhasználás optimalizálása;
- Ipari fűtés, szellőztetés és légkondícionálás;
- Gyártásellenőrzés;
- Eszközkövetés és okoslogisztika;
- Ipari környezetekben gáz- és hőmérsékletellenőrzés;
- Biztonsági (safety) és egészségügyi ellenőzés;
- Eszközök teljesítmény menedzsmentje.

Az IIoT kihívásai

Lévén ICS kiberbiztonsági blog, talán megbocsátható, ha ezzel a témával kezdem az IIoT eszközök kihívásainak felsorolását. Az IIoT berendezések, hasonlóan az IoT termékekhez, sajnos meglehetősen komoly hiányosságokkal rendelkeznek kiberbiztonsági szempontból, elég csak a 2016 októberi Mirai botnet által végrehajtott DDoS-támadásokra gondolni, ahol egyes információk szerint számos gyengén védett és kompromittált ipari biztonsági kamerát is felhasználtak a támadók. Ugyanígy kompromittált IIoT eszközökön keresztül értékes adatokat lehet ellopni vagy akár jelentős károkat (akár emberéletet is követelő incidenseket) is lehet előidézni - itt szeretnék mindenkit emlékeztetni, hogy még mindig nem tudjuk, vajon mi is volt a pontos célja a Triton/TriSIS ICS malware-t fejlesztő és felhasználó csoportnak...

Meglepő módon pont az IoT irányából érkezik egy olyan módszer, ami egyes szakértők szerint segíthet javítani az IIoT eszközök biztonsági problémáin, ez pedig az automatizált, háttérben történő frissítés. Én azonban ezzel kapcsolatban szkeptikus vagyok, hiszen az ICS világ egy legnagyobb kihívása mind a mai napig a lassú hibajavítás vagy éppen a javítások telepítésének teljes hiánya. Nem érzem életszerűnek, hogy egy változatlan gondolkodású és hozzáállású OT-s mérnökcsapat, akik a DCS/SCADA rendszerek esetén minden rendelkezésükre álló érvvel és eszközzel a patch-ek telepítése ellen van, hajlandó lesz az IIoT eszközöknél engedélyezni az automatikus frissítések telepítését.

A biztonsági problémákon túl két további komoly kihívás is nehezíti az IIoT elterjedését:

- A szabványok és a szabványosítás hiánya;
- A régi technológiákkal történő integráció nehézkessége.

Sérülékenységek Lantech IDS 2102 berendezésekben

Florian Adamsky két sérülékenységet jelentett az NCCIC-nek, amik a Lantech IDS 2102 berendezéseinek 2.0 és korábbi verzióit érinti.

A gyártó nem reagált az NCCIC sérülékenységekkel kapcsolatos megkeresésére, így egyelőre nincs javítás a hibákra.

A sérülékenységek részleteiről az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-123-01

Sérülékenységek Philips Brilliance komputer tomográfokban

A gyártó 3 sérülékenységről tett jelentést az NCCIC-nek, amik a Brilliance komputer tomográf berendezéseik alábbi modelljeit és verzióit érintik:

- Brilliance 64, 2.6.2 és korábbi verziók;
- Brilliance iCT, 4.1.6 és korábbi verziók;
- Brillance iCT SP 3.2.4 és korábbi verziók;
- Brilliance CT Big Bore 2.3.5 és korábbi verziók.

A Philips kockázatcsökkentő intézkedések bevezetését javasolja és az egyik hibához (beégetett felhasználónevek és jelszavak) javítást is kiadott.

A sérülékenységekkel kapcsolatos bővebb információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-18-123-01

Siemens Siveillance VMS sérülékenységek

A Siemens ProductCERT egy friss sérülékenységről publikált részleteket, amik a Siveillance VMS (IP alapú videó menedzsment rendszer) alábbi verzióit érinti:

- Siveillance VMS 2016 R1 és korábbi kiadások V10.0a-nál korábbi firmware verzió használata esetén;
- Siveillance VMS 2016 R2, V10.1a-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2016 R3, V10.2b-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2017 R1, V11.1a-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2017 R2, V11.2a-nél korábbi firmware verzió használata esetén;
- Siveillance VMS 2018 R1, V12.1a-nél korábbi firmware verzió használata esetén.

A hiba javítását a gyártó már elérhetővé tette. A sérülékenységről további információkat a Siemens ProductCERT weboldalán lehet találni: https://cert-portal.siemens.com/productcert/pdf/ssa-457058.pdf

Sérülékenység a Siemens Siveillance VMS mobil alkalmazásokban

A Siemens ProductCERT bejelentése szerint Karsten Sohr, a TZI Bremen munkatársa egy nem megfelelő tanúsítvány-ellenőrzésből adódó hibát azonosított a Siveillance VMS Video mobil alkalmazások alábbi verzióiban:

Siveillance VMS Video for Android, V12.1a-nál korábbi összes verzió;
Siveillance VMS Video for iOS, V12.1a-nál korábbi összes verzió.

A gyártó a hibát a V12.1a verzióban javította. A sérülékenységgel kapcsolatban további részleteket a Siemens ProductCERT publikációja tartalmaz: https://cert-portal.siemens.com/productcert/pdf/ssa-468514.pdf

Sérülékenységek Siemens SINAMICS termékekben

A Siemens ProductCERT publikációja szerint két sérülékenységet azonosítottak a SINAMICS középfeszültségű berendezések következő verzióiban:

SINAMICS GH150 V4.7 (PROFINET-es változat), V4.7 SP5 HF7-nél korábbi verziói;
SINAMICS GL150 V4.7 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS GM150 V4.7 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SL150 V4.7.0 (PROFINET-es változat), V4.7 HF30-nál korábbi verziói;
SINAMICS SL150 V4.7.4 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SL150 V4.7.5 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SM120 V4.7 (PROFINET-es változat), V4.8 SP2-nél korábbi verziói;
SINAMICS SM150 V4.7 (PROFINET-es és SIMOTION-ös változatok) minden verziója.

A gyártó a sérülékenységek javításait már elérhetővé tette. A sérülékenységekről részletesebben a Siemes ProductCERT weboldalán lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-546832.pdf

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.

Alig két hete egy nagyon érdekes cikk jelent meg a golem.de oldalon. A tiroli Patscherkofel hegy síliftjének vezérlőrendszerét két biztonsági kutató, Sebastian Neef és Tim Philipp Schäfers még márciusban fedezték fel, amikor Internetre csatlakoztatott, sérülékeny rendszereket kerestek.

Az egyébként is elavult vezérlőrendszerrel kapcsolatban számos egyéb (ICS rendszerek esetében sajnos általánosnak nevezhető) hibát is azonosítottak. Amellett, hogy sílift vezérlőrendszerét az Internetről is el lehetett érni, semmilyen titkosítást (pl. TLS) nem használtak a vezérlési utasítások kiadása során, nem volt szükség authentikációra a rendszerbe történő bejelentkezéshez, Cross-site scripting támadást lehetett végrehajtani a rendszer ellen és további, az OWASP Top10-ben is megtalálható sérülékenységet is ki lehetett használni a rendszer elleni támadások során.

Az osztrák CERT tájékoztatása szerint a sílift vezérlőrendszerét mindaddig nem fogja használni az IKB, az Innsbruck-i városi közműszolgáltató, amíg megfelelő biztonsági intézkedéseket nem vezetnek be a rendszerrel kapcsolatban. Így végül is a történetet tekinthetjük pozitív végkifejletűnek, azonban nem lehet elégszer hangsúlyozni: nem szabad folyamatvezérlő rendszereket publikus hálózatokra csatlakoztatni! Ahogy ebből az esetből is látszik, gyakorlatilag a szerencsén múlt, hogy két olyan ember találta meg a sílift vezérlőrendszerét az Interneten, akik kellően megfontoltak és felelősségteljesek voltak és eszükbe sem jutott kipróbálni, hogy "mi lesz, ha megnyomom ezt a gombot?"

A teljes történetet (németül) a golem.de oldalán lehet olvasni: https://www.golem.de/news/patscherkofel-gondelbahn-mit-sicherheitsluecken-1804-133930.html

Az esettel kapcsolatban a CERT.at is kiadott egy közleményt: http://www.cert.at/services/blog/20180420131015-2180.html

Sérülékenység Siemens WinCC iOS alkalmazásban

Alexander Bolshev, az IOActive és Ivan Yushkevich, az Embedi munkatársai egy információszivárgáshoz vezető hibát azonosítottak a SIMATIC WinCC OA Operator iOS alkalmazás összes verziójában.

A hibával kapcsolatban nincs hír javítást hozó verzióról, a Siemens kompenzáló kontrollok alkalmazását javasolja az érintett szoftvert használó ügyfeleinek és azt, hogy kiemelt biztonságú környezetekben ne használják az alkalmazást.

A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Delta Electronics PMSoft sérülékenység

Ghirmay Desta a TrendMicro ZDI-vel együttműködve talált egy puffer-túlcsordulást a Delta Electronics PMSoft nevű, mozgásvezérlő rendszerek fejlesztő környezeteként használt rendszer 2.10-es és korábbi verzióiban.

A gyártó a hibát a 2.11-es és későbbi verziókban javította.

A sérülékenységről bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-116-01

Sérülékenységek WECON rendszerekben

Sergey Zelenyuk, az RVRT és Michael DePlante, a Champlain Főiskola munkatársai, a TrendMicro ZDI-vel együttműködve azonosítottak egy puffer-túlcsordulásos hibát a WECON alábbi rendszereiben:

- WECON LeviStudioU 1.10-es verzió, a WECON LeviStudioU 1.8.29 és korábbi verzióiban megtalálható szoftver;
- PI Studio HMI Project Programmer 2017. november 11-i és korábbi build-ek.

A gyártó a hibát az itt elérhető verzióban javította.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-116-02

Advantech WebAccess sérülékenységek

Steven Seeley, a Source Incite munkatársa a ZDI-vel közösen publikált több, az Advantech WebAccess HMI Designer 2.1.7.32-es és korábbi verzióit érintő sérülékenységet.

Jelenleg nincs információ olyan újabb verzióról, ami javítaná a hibákat, a gyártó az NCCIC-vel közösen dolgozik kockázatcsökkentő intézkedéseken.

A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-114-03

Vecna VGo Robot sérülékenységek

Dan Regalado, a Zingbox munkatársa két hibát azonosított a Vecna VGo Robot 3.0.3.52164-esnél korábbi verzióiban.

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

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

Becton, Dickinson and Company termékek sérülékenysége

Mathy Vanhoef, az imec-DistriNet és a Leuven-i Katolikus Egyetem munkatársa több, a KRACK sérülékenységhez kapcsolódó hibát talált a Becton, Dickinson and Company alábbi termékeiben:

- BD Pyxis Anesthesia ES;
- BD Pyxis Anesthesia System 4000;
- BD Pyxis Anesthesia System 3500;
- BD Pyxis MedStation 4000 T2;
- BD Pyxis MedStation ES;
- BD Pyxis SupplyStation;
- BD Pyxis Supply Roller;
- BD Pyxis ParAssist System;
- BD Pyxis PARx;
- BD Pyxis CIISafe – Workstation;
- BD Pyxis StockStation System;
- BD Pyxis Parx handheld

A gyártó a hibákat harmadik féltől származó javítás alkalmazásával javítja a termékeiben.

A sérülékenységről további részleteket az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-114-01

Intel 2G Modem sérülékenység

Dr. Ralph Phillip Weinmann és Dr. Nico Golde a Comsecuris munkatársai egy puffer-túlcsordulásos hibát találtak az Intel alábbi, 2G képes és engedélyezett ETWS funkcióval működő modemjeiben:

- Intel XMM71xx;
- Intel XMM72xx;
- Intel XMM73xx;
- Intel XMM74xx;
- Sofia 3G;
- Sofia 3G-R;
- Sofia 3G-R W.

Az Intel a hibát javító patch-et azoknak a gyártó partnereinek fogja elérhetővé tenni, akik ezeket a modemeket beépítik a saját eszközeikbe, a végfelhasználók az egyes gyártóknál tudnak érdeklődni a javításokról.

A sérülékenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-114-02

Moxa EDR-810 ipari routerek sérülékenységei

Carlos Pacho, a Cisco Talos laborjának munkatársa több sérülékenységet fedezett fel a Moxa EDR-810 ipari routereinek V4.1 build 17030317 verziójában. A Talos publikációja szerint feltételezhető, de nem megerősített, hogy a sérülékenységek a korábbi verziókat is érintik.

A gyártó a hibát a v4.2-es firmware-verzióban javította.

A sérülékenységek részleteiről a Talos és a Moxa weboldalain lehet olvasni.

Sérülékenységek Schneider Electric Pelco Sarix Pro 1 kamerákban

A Schneider Electric publikációja szerint a Pelco Sarix Pro első generációs kamerák firmware-jének 3.29.69-nél korábbi verzióiban. A második generációs Pelco Sarix Pro kamerákat a hibák nem érintik.

A sérülékenységeket a gyártó a 3.29.69-es firmware-verzióban javította.

A hibákról részletesebben a Schneider Electric publikációjában lehet olvasni.

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

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

Ezen a héten hétfőn publikálta a Symantec azt jelentését, amely szerint egy eddig ismeretlen támadó csoportot azonosítottak (és neveztek el Orangeworm-nek), akiket elsősorban az különböztet meg más csoportoktól, hogy előszeretettel vesznek célba egészségügyi szolgáltatókat és egészségügyi rendszereket.

Bár az egészségügyi rendszerek szigorúan véve nem ICS rendszerek, de (követve az ICS-CERT megközelítését) én is írok az ilyen rendszerek biztonságáról időnként a blogon, így ezt a hírt is figyelemre méltónak tartom.

Az Orangeworm tagjai a Symantec cikke szerint egy Kwampirs nevű trójai programot használnak arra, hogy hátsó ajtót nyissanak a megtámadott rendszereken, amelyek között röntgengépeket és MRI-ket vezérlő rendszerek is találhatóak. Ezeken túl a támadók a Symantec elemzése szerint kifejezetten nagy érdeklődést mutatnak az olyan rendszerek iránt, amelyekkel a betegek hozzájárulásukat tudják adni az egyes vizsgálatokhoz és beavatkozásokhoz.

Az egészségügyben használt rendszerek biztonsága (ahogy arról még bő egy évvel ezelőtt egy két részes bejegyzésben írtam) számos gyenge ponttal rendelkezik, a jelek szerint a Symantec most egy olyan csoport nyomaira bukkant, akik nem csak kihasználják az ilyen rendszerek hibáit, de nem is igazán tesznek erőfeszítéseket annak érdekében, hogy a tevékenységük titok maradjon.

A Symantec cikke a témáról itt érhető el, de már az Index is írt a témáról.

Február közepén jelentette be az amerikai energiaügyi minisztérium (Department of Energy, DoE), hogy egy új hivatalt állít fel CESER nevén, aminek a feladata az amerikai energiaszektor kiberbiztonsági helyzetének javítása lesz. A tervek szerint az új hivatalt egy helyettes államtitkári rangú tisztviselő fogja vezetni, első költségvetése pedig közel 100 millió amerikai dollár lesz.

Szintén még februári döntés volt, hogy az ukrán villamosenergia-ipari rendszerirányító, az Ukrenergo 20 millió amerikai dolláros fejlesztéseket hajt végre az új biztonsági koncepciójuk megvalósításával kapcsolatban.

2016 decemberében az Ukrenergo volt a célpontja a második nagyobb ukrán villamosenergia rendszer elleni kiberbtámadásnak, ami jelentős üzemzavart okozott a Kijev környéki áramellátásban.

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

Az ICS-CERT bejelentése szerint az rgod néven ismert biztonsági kutató a ZDI-vel együttműködve talált 3 sérülékenységet az Omron CX-One alábbi verzióiban:

- CX-One 4.42 és korábbi verziók, ide értve az alábbi alkalmazásokat is:
- CX-FLnet 1.00 és korábbi verziók;
- CX-Protocol 1.992 és korábbi verziók;
- CX-Programmer 9.65 és korábbi verziók;
- CX-Server 5.0.22 és korábbi verziók;
- Network Configurator 3.63 és korábbi verziók;
- Switch Box Utility 1.68 és korábbi verziók.

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

- CX-FLnet 1.10;
- CX-Protocol 1.993;
- CX-Programmer 9.66;
- CX-Server 5.0.23;
- Network Configurator 3.64;
- Switch Box Utility 1.69.

A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-100-02

ATI Systems vészhelyzeti tömegtájékoztató rendszerek sérülékenységei

Balint Seeber, a Bastille munkatársa 2 sérülékenységet jelentett az ICS-CERT-nek, amit az ATI Systems vészhelyzeti tömegtájékoztató rendszerének alábbi eszközeit érintik:

- HPSS16;
- HPSS32;
- MHPSS;
- ALERT4000.

A gyártó jelenleg is teszteli a hibákat javító patch-et és igény szerint elérhetővé teszi az ügyfelei számára.

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

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

A Yokogawa a japán nemzeti CERT-tel (JPCERT) együttműködve publikált egy sérülékenységet, ami az alábbi termékeit érinti:

- CENTUM CS 1000 minden verziója;
- CENTUM CS 3000 R3.09.50 és korábbi verziók;
- CENTUM CS 3000 Small R3.09.50 és korábbi verziók;
- CENTUM VP R6.03.10 és korábbi verziók;
- CENTUM VP Small R6.03.10 és korábbi verziók;
- CENTUM VP Basic R6.03.10 és korábbi verziók;
- Exaopc R3.75.00 és korábbi verziók;
- B/M9000 CS minden verziója;
- B/M9000 VP R8.01.01 és korábbi verziók.

A gyártó a CENTUM CS 1000, CENTUM CS 3000 és CENTUM CS 3000 Small berendezésekhez nem fog javítást kiadni, ezek a típusok már elérték életciklusuk végét. A CENTUM VP, CENTUM VP Small, CENTUM VP BASIC típusokat használó ügyfelek az R5.04.B2 vagy az R6.04.00 verziókra történő frissítéssel javíthatják a hibát. Az Exaopc-k esetén az R3.76.00 verzió javítja a hibát.

A sérülékenységgel kapcsolatos további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-102-01

Rockwell Automation Stratix ipari switch-ek sérülékenységei

A Rockwell Automation 8 sérülékenységet jelentett az ICS-CERT-nek, amik a Cisco IOS és IOS XE firmware-jeire épülő alábbi termékeit érintik:

- Allen-Bradley Stratix 8300 menedzselt ipari Ethernet switch-ek, 15.2(4a)EA5 és korábbi verziói;
- Allen-Bradley Stratix 5400 ipari Ethernet switch-ek, 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 5410 ipari Ethernet switch-ek, 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 5700 ipari Ethernet switch-ek, 15.2(6)E0a és korábbi verziói;
- Allen-Bradley Stratix 8000 moduláris menedzselt Ethernet switch-ek, 15.2(6)E0a és korábbi verziói;
- Allen-Bradley ArmorStratix 5700 menedzselt ipari Ethernet switch-ek, 15.2(6)E0a és korábbi verziói.

A hibákkal kapcsolatban nincs információ javításról.

A sérülékenységekről bővebben az ICS-CERT publikációiban lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-107-05
https://ics-cert.us-cert.gov/advisories/ICSA-18-107-04

Sérülékenységek Rockwell Automation Stratix routerekben

A gyártó 4 sérülékenységet jelentett az ICS-CERT-nek, amik az Allen-Bradley Stratix 5900 routerek 15.6.3M1 és korábbi verzióit érintik.

A hibákkal kapcsolatban nincs információ javításról.

A sérülékenység részleteiről az ICS-CERT bejelentése tartalmaz további információkat: https://ics-cert.us-cert.gov/advisories/ICSA-18-107-03

Schneider Electric Triconex sérülékenységek

A HatMan ICS malware-rel kapcsolatos vizsgálatok során a gyártó és a NCCIC közös vizsgálata során két memóriakezelési hibát fedeztek fel, amik az MP model 3008 10.0-10.4 közötti firmware-verzióit érintik.

A hibákat a gyártó a 11.x verziókban javította.

A sérülékenységekről további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-107-02

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

A Tenable Research munkatársai egy sérülékenységet fedeztek fel az alábbi Schneider Electric rendszerekben:

- InduSoft Web Studio v8.1 és korábbi verziók;
- InTouch Machine Edition 2017 v8.1 és korábbi verziók.

A hibát a gyártó az InduSoft Web Studio v8.1 SP1 és InTouch Machine Edition 2017 v8.1 SP1 verzióiban javította.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-107-01

Abbott Laboratories rendszerek sérülékenységei

A MedSec Holdings két sérülékenységet fedezett fel az Abbott Laboratories defibrillátorainak alábbi verzióiban:

- Fortify;
- Fortify Assura,;
- Quadra Assura;
- Quadra Assura MP;
- Unify;
- Unify Assura;
- Unify Quadra;
- Promote Quadra;
- Ellipse;
- Current;
- Promote.

A gyártó a legújabb firmware-ben javította a hibákat.

A sérülékenységekről részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-107-01

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

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

Az NCC Group nevű, IT biztonsággal foglalkozó Nagy-britanniai cég nemrégiben egy rövid, ám annál érdekesebb cikket publikált. Egy ügyfelük kérésére átalakították a tavaly júniusban komoly károkat okozó, EternalBlue SMB sérülékenységet kihasználó NotPetya malware-t és a romboló funkciójától megfosztott férget szabadon engedték egy ipari vezérlőrendszer laborkörülmények között reprodukált másolatában.

A módosított malware-t egy mérnöki hálózatban engedték szabadon és semmilyen jogosultságot nem kapott a hálózaton található eszközökön. Első körben a módosított malware három, az EternalBlue sérülékenység ellen nem patch-elt számítógépet talált. A malware-be kódolt exploit-ot használva a NotPetya mindhárom sérülékeny számítógépen kernel szintű jogosultságot szerzett, majd ezzel a jogosultsággal megfertőzte ezeket a számítógépeket.

Tíz percen belül az első három számítógépről szerzett felhasználónevekkel és jelszavakkal a teljes mérnöki hálózatot átfésülte további megfertőzhető eszközöket keresve. Két további perccel később a malware átvette az uralmat a teljes tartomány felett. A módosított NotPety nagyjából 45 perc alatt 107 számítógép felett szerzett irányítást, mielőtt az NCC Group ügyfele aktiválta volna a beépített leállító és eltávolító funkciót.

A teszthez használt NotPetya-variáns terjedésát ezen az ábrán lehet megnézni.

Az NCC Group kutatásáról kiadott publikáció itt érhető el: https://www.nccgroup.trust/uk/about-us/newsroom-and-events/blogs/2018/february/eternalglue-part-two-a-rebuilt-notpetya-gets-its-first-execution-outside-of-the-lab/

Rockwell Automation MicroLogix sérülékenységek

Az ICS-CERT bejelentése szerint Jared Rittle és Patrick DeSantis, a Cisco munkatársai 6 különböző, a nem megfelelő authentikációból adódó sérülékenységet azonosítottak a Rockwell Automation alábbi MicroLogix berendezéseiben:

- MicroLogix 1400 FRN 21.003 és korábbi verziók;
- MicroLogix 1100 FRN 16.00 és korábbi verziók.

A gyártó a weboldalán részletes kockázatcsökkentési tanácsokat publikált: https://rockwellautomation.custhelp.com/app/answers/detail/a_id/1072942 (a megtekintéséhez regisztráció szükséges!)

A sérülékenységek részleteit az ICS-CERT publikációja tartalmazza: https://ics-cert.us-cert.gov/advisories/ICSA-18-095-01

Sérülékenység Moxa MXView rendszerekben

Michael DePlante a Champlain College munkatársa egy információ szivárgás sérülékenységet azonosított a Moxa MXView 2.8-as és korábbi verzióiban.

A gyártó a hibát a 2.9-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-18-095-02

LCDS LAquis SCADA sérülékenység

Karn Ganeshen egy újonan felfedezett sérülékenységet jelentett az ICS-CERT-nek, ami a Leão Consultoria e Desenvolvimento de Sistemas Ltda nevű brazil gyártó LAquis SCADA szoftverének 4.1.0.3391-es és korábbi verzióit érinti.

A gyártó a hibát a 4.1.0.3774-es verzióban javította, amit innen lehet letölteni: http://laquisscada.com/instale1.php

A sérülékenységgel kapcsolatos további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-095-03

Sérülékenységek Schneider Electric U.motion Builder szoftverekben

A gyártó által kiadott publikáció szerint 16 különböző sérülékenységet azonosítottak az U.motion Builder v1.3.4-esnél korábbi verzióiban.

A Schneider Electric weboldalán már elérhető a hibákat javító verzió: https://www.schneider-electric.com/en/download/document/SE_UMOTION_BUILDER/

A sérülékenységekről további részleteket a Schneider Electric webodalán lehet találni.

Sérülékenységek Natus NeuroWorks orvosi rendszerekben

A Talos (a Cisco kiberbiztonsági laborja) 5 különböző sérülékenységet azonosított a Natus NeuroWorks orvosi rendszereiben. A Talos publikációja szerint a Natus Xltek NeuroWorks 8-as verziója bizonyítottan érintett.

Jelenleg nincs információ arról, hogy a gyártó tervezi-e a sérülékenységek javítását.

A sérülékenységek részleteivel kapcsolatban a Talos weboldalán lehet bővebb információkat találni: http://blog.talosintelligence.com/2018/04/vulnerability-spotlight-natus.html

Sérülékenység Moxa vezeték nélküli AP/bridge eszközökben

Szintén a Talos munkatársai (Patrick DeSantis és Dave McDaniel) azonosítottak egy sérülékenységet, amit kihasználva a felhasználónév megadása során kódvégrehajtást lehet előidézni.

A sérülékenység a Moxa AWK-3131A 1.4-1.9-ig terjedő firmware verzióit érinti.

A gyártó már kiadott egy olyan, újabb firmware verziót, amiben javította a hibát.

A sérülékenységgel kapcsolatos mélyebb, technikai részleteket is tartalmazó információkat a Talos sérülékenységi jelentése tartalmaz: https://talosintelligence.com/vulnerability_reports/TALOS-2017-0507

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.