A harmadik (és ebben a sorozatban egyelőre utolsó) esettanulmányban egy gyár termelésirányítási rendszerében a monitoring funkciókhoz használt mobiltelefon modemekkel kapcsolatos incidensről lesz szó.

Felmerülhet a kérdés, hogy miért is használna valaki mobiltelefonokat modemnek egy ICS rendszer monitoringjához? A válasz viszonylag egyszerű: a mobiltelefonok modemek használatához nagyjából egyetlen feltételnek kell teljesülnie - legyen az adott létesítményben megfelelő lefedettsége a szolgáltató hálózatának és máris egy olcsó és (meghibásodások, avulás, stb. esetén) könnyen cserélhető, publikus hálózatokra épülő kommunikációs csatornára tett szert az adott szervezet. A rendelkezésre állásnál nyilván tervezni kell az adott szolgáltató karbantartásaival és célszerű egy tartalék megoldással is rendelkezni, ha a mobil szolgáltatónál van üzemzavar, de ezeket a hátrányokat a mobiltelefon modemek rugalmassága és költséghatékonysága általában túlszárnyalja a döntéshozók szemében.

A logikai biztonsági megfontolások (mint általában), a konkrét esetben sem voltak alaposan felmérve, emiatt például a modemek konfigurációja nem volt biztonságos (a gyári jelszavak cseréje is elmaradt), ami miatt a támadók nem csak, hogy a modemeken keresztül hozzáfértek a gyár hálózatához, de ugyanezeket a modemeket felhasználva DoS-támadásokat is indítottak más célpontok ellen, ami mobil adatforgalom-költségként a gyár számláján jelentkezett. A gyár hálózatához hozzáférve a támadóknak lehetőségük nyílhatott módosítani a modemeken keresztül felügyelt berendezéseket, az Internet felé pedig spam-eket küldhettek.

Tanulságok

Ismét csak azzal a tanulsággal kell kezdeni, hogy minden, Internetre csatlakoztatott eszközt a lehetőségekhez képest a leginkább biztonságos konfigurációval szabad csak használni. Mivel az ICS rendszerek esetén a biztonsági hardening során nagyon gyakran az üzembiztonságot fontosabbnak kell tekinteni a biztonságos konfigurációnál, gondoskodni kell arról is, hogy egy esetleges támadásról illetve annak sikeréről minél előbb értesüljenek az illetékesek és biztosítani kell azt is, hogy egy támadás elhárítása után fel lehessen építeni, hogy a támadók pontosan milyen sérülékeny pontokat használtak a támadás során - ehhez célszerű minden bejövő és kimenő hálózati forgalmat rögzíteni és a kockázatelemzésekből származó megállapítások alapján meghatározott ideig megőrizni.

A mobiltelefonos modemek esetén a fentieken túlmenően rendszeresen ellenőrizni kell a szolgáltatótól érkezett számlákat és amennyiben bármilyen jelentős változás tapasztalható a normális forgalomtól, azt haladéktalanul ki kell vizsgálni.

Az esettanulmány eredeti, német nyelvű verziója itt érhető el.

A Kaspersky Lab, az egyik legjelentősebb IT biztonsági cég, akik kiemelten foglalkoznak az ICS rendszerek biztonságával, nemrég megjelentette legújabb jelentését, amiben a 2018 első félévben történt, ICS rendszereket célzó támadásokat elemezte. Az összefoglaló mögött, amennyire tudom, a termékeiket használó ügyfelektől kapott adatokra épülnek, így az, hogy az USA-ban és egyes EU-tagállamokban (így Magyarországon is) már a nem ajánlott vagy egyenesen tiltott szoftverek listáján találhatóak a Kaspersky termékek, torzíthatnak a statisztikákon.

A Kaspersky adatai alapján legnagyobb mértékben ázsiai, Latin-amerikai és Észak-afrikai ICS rendszereket ért támadás 2018 első félévében. Ezek a támadások az esetek legnagyobb részében nem célzott támadásnak, hanem véletlenszerűnek tekinthetőek, amiket 2800 különböző malware-családba tartozó malware-ek okoztak. A támadások száma a legmagasabb Vietnamban, Algériában és Marokkóban volt, a legalacsonyabb pedig Dániában, Írországban és Svájcban.

A támadások leggyakoribb csatornája még mindig az Internet (az összes támadás 27%-a köthető az Internethez illetve webes szolgáltatásokhoz), 8,4%-uknál volt szerepük különböző adathordozóknak és 3,8%-ban játszott szerepet az e-mail.

A Kaspersky teljes elemzése itt érhető el.

Fuji Electric V-Server sérülékenységek

Steven Seeley (akit mr_me néven is ismernek), a Source Incite munkatársa és Ghirmay Desta hét különböző sérülékenységet találtak a Fuji Electric V-Server VPR termékének 4.0.3.0 és korábbi verzióiban.

A gyártó a hibákat a 4.0.4.0 verzióban javította. A sérülékenységekről részletesebb információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-254-01

A sérülékenységekről a SecurityAffairs és a SecurityWeeks is írt.

Sérülékenység Fuji Electric V-Server Lite rendszerekben

Ariele Caltabiano (kimiya) a ZDI-vel együttműködve egy klasszikus puffer túlcsordulásos hibát azonosított a Fuji Electric V-Server Lite 4.0.3.0 és korábbi verzióiban.

A gyártó ezt a hibát is a 4.0.4.0-es firmware verzióban javított. A sérülékenységről további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-254-02

Siemens SCALANCE switch-ek sérülékenysége

A gyártó Siemens egy, a bevitt adatok nem megfelelő ellenőrzéséből fakadó sérülékenységet azonosított az alábbi SCALANCE switch-ekben:

- SCALANCE X300 4.0.0-nál korábbi összes verziója;
- SCALANCE X408 4.0.0-nál korábbi összes verziója;
- SCALANCE X414 minden verziója.

A gyártó az X300-as és X408-as készülékekhez elérhetővé tette a hiba javítását tartalmazó verziót, az X414-es készülékekhez kockázatcsökkentő intézkedéseket javasol. A sérülékenységről bővebben az ICS-CERT és a Siemens ProductCERT weboldalain lehet olvasni.

Sérülékenység Siemens SIMATIC WinCC OA rendszerekben

A Siemens egy nem megfelelő hozzáférés-kezelésből adódó sérülékenységet azonosított a SIMATIC WinCC OA 3.14-es és korábbi verzióiban.

A hibát a gyártó a SIMATIC WinCC OA v3.14-P021 verziójában javította. A sérülékenységről az ICS-CERT és a Siemens ProductCERT is publikált részleteket.

Siemens TD Keypad Designer sérülékenység

A Siemens egy DLL sérülékenységet azonosított a TD Keypad Designer nevű termékének minden elérhető verziójában.

A hibával kapcsolatban a Siemens kockázatcsökkentő intézkedések alkalmazását javasolja az érintett terméket használó ügyfeleinek. A sérülékenységről további információkat az ICS-CERT és a Siemens ProductCERT bejelentéseiben lehet találni.

Sérülékenység Honeywell eszközökben

A gyártó és a Google Android csapatának együttműködése egy nem megfelelő jogosultságkezelési hiba felfedezéséhez vezetett a Honeywell alábbi, Android operációs rendszert futtató mobil számítógépeiben:

- CT60 running Android OS 7.1-et futtató CT60;
- CN80 running Android OS 7.1-et futtató CN80;
- CT40 running Android OS 7.1-et futtató CT40;
- CK75 running Android OS 6.0-át futtató CK75;
- CN75 running Android OS 6.0-át futtató CN75;
- CN75e running Android OS 6.0-át futtató CN75e;
- CT50 running Android OS 6.0-át futtató CT50;
- D75e running Android OS 6.0-át futtató D75e;
- CT50 running Android OS 4.4-et futtató CT50;
- D75e running Android OS 4.4-et futtató D75e;
- CN51 running Android OS 6.0-át futtató CN51;
- EDA50k running Android 4.4-et futtató EDA50k;
- EDA50 running Android OS 7.1-et futtató EDA50;
- EDA50k running Android OS 7.1-et futtató EDA50k;
- EDA70 running Android OS 7.1-et futtató EDA70;
- EDA60k running Android OS 7.1-et futtató EDA60k;
- EDA51 running Android OS 8.1-et futtató EDA51.

A hibát javító Android verziókat a Honeywell elérhetővé tette a weboldalán. A sérülékenység részleteit az ICS-CERT weboldalán lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-256-01

Spectre-NG sérülékenységek Siemens ipari termékekben

A Siemens által közzétett információk szerint számos terméküket érinti a Spectre-NG (3a és 4-es változatai) sérülékenység, egészen pontosan az alábbi rendszereket:

- RUGGEDCOM APE minden verziója;
- RUGGEDCOM RX1400 VPE minden verziója;
- SIMATIC ET 200 SP Open Controller minden verziója;
- SIMATIC ET 200 SP Open Controller (F) minden verziója;
- SIMATIC Field PG M4, minden V18.01.09-nél korábbi BIOS verzió használata esetén;
- SIMATIC Field PG M5, minden V22.01.06-nél korábbi BIOS verzió használata esetén;
- SIMATIC HMI Basic Panels 2nd Generation összes, SIMATIC WinCC V14-el használt verziója;
- SIMATIC HMI Basic Panels 2nd Generation
- SIMATIC HMI Comfort 15-22 Panelek közül a következőek (6AV2124-0QC02-0AX1, 6AV2124-1QC02-0AX1, 6AV2124-0UC02-0AX1, 6AV2124-0XC02-0AX1), SIMATIC WinCC V14-el használva;
- SIMATIC HMI Comfort 15-22 Panelek közül a következőek (6AV2124-0QC02-0AX1, 6AV2124-1QC02-0AX1, 6AV2124-0UC02-0AX1, 6AV2124-0XC02-0AX1), SIMATIC WinCC V15 Update 2-nél korábbi verziókkal használva;
- SIMATIC HMI Comfort 4-12" Panelek SIMATIC WinCC V14-el használva;
- SIMATIC HMI Comfort 4-12" Panelek SIMATIC WinCC V15 Update 2-nél korábbi verziókkal használva;
- SIMATIC HMI Comfort PRO Panelek SIMATIC WinCC V14-el használva;
- SIMATIC HMI Comfort PRO Panelek SIMATIC WinCC V15 Update 2-nél korábbi verziókkal használva;
- SIMATIC HMI KTP Mobile Panelek SIMATIC WinCC V14-el használva;
- SIMATIC HMI KTP Mobile Panelek SIMATIC WinCC V15 Update 2-nél korábbi verziókkal használva;
- SIMATIC IPC227E minden verziója;
- SIMATIC IPC3000 SMART V2 minden verziója;
- SIMATIC IPC347E minden verziója;
- SIMATIC IPC377E minden verziója;
- SIMATIC IPC427C minden verziója;
- SIMATIC IPC427D minden, V17.0X.14-nél korábbi BIOS verziói;
- SIMATIC IPC427E minden, V21.01.09-nél korábbi BIOS verziói;
- SIMATIC IPC477C minden verziója;
- SIMATIC IPC477D minden, V17.0X.14-nél korábbi BIOS verziói;
- SIMATIC IPC477E minden, V21.01.09-nél korábbi BIOS verziói;
- SIMATIC IPC477E Pro minden, V21.01.09-nél korábbi BIOS verziói;
- SIMATIC IPC547E minden verziója;
- SIMATIC IPC547G minden verziója;
- SIMATIC IPC627C minden verziója;
- SIMATIC IPC627D minden verziója;
- SIMATIC IPC647C minden verziója;
- SIMATIC IPC647D minden verziója;
- SIMATIC IPC677C minden verziója;
- SIMATIC IPC677D minden verziója;
- SIMATIC IPC827C minden verziója;
- SIMATIC IPC827D minden verziója;
- SIMATIC IPC847C minden verziója;
- SIMATIC IPC847D minden verziója;
- SIMATIC ITP1000 minden verziója;
- SIMATIC S7-1500 CPU S7-1518-4 PN/DP MFP (6ES7518-4AX00-1AC0) minden verziója;
- SIMATIC S7-1500 CPU S7-1518-4 PN/DP ODK (6ES7518-4AP00-3AB0) minden verziója;
- SIMATIC S7-1500 CPU S7-1518F-4 PN/DP MFP (6ES7518-4FX00-1AC0) minden verziója;
- SIMATIC S7-1500 CPU S7-1518F-4 PN/DP ODK (6ES7518-4FP00-3AB0) minden verziója;
- SIMATIC S7-1500 Software Controller
- SIMOTION P320-4E minden verziója;
- SIMOTION P320-4S minden verziója;
- SINEMA Remote Connect minden verziója;
- SINUMERIK 840 D sl (NCU720.3B, NCU730.3B, NCU720.3, NCU730.3)
- SINUMERIK PCU 50.5 minden verziója;
- A TCU-val integrált SINUMERIK Panelek minden 2016-ban vagy korábban kiadott verziói;
- SINUMERIK TCU 30.3 minden verziója.

A gyártó a fent felsorolt, sérülékenység által érintett termékei közül többhöz is újabb BIOS verziókat adott ki a sérülékenység javításával, a többihez kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenység részleteiről a Siemens ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-268644.pdf

Sérülékenység WECON rendszerekben

Natnael Samson a ZDI-vel együttműködve egy puffer túlcsordulásos sérülékenységet azonosított a WECON PLC Editor szoftverének 1.3.3U verziójában.

A gyártó megerősítette a sérülékenység létezését, de mindezidáig nem adott ki javítást. A sérülékenységről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-261-01

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.

A SecurityAffairs.co cikke szerint az amerikai energiaügyi minisztérium (DoE) az első olyan gyakorlat szervezéséhez kezdett hozzá, aminek a forgatókönyve szerint az USA villamosenergia-rendszerét ért kibertámadás utáni, teljes leállást okozó üzemzavart kell elhárítaniuk a résztvevőknek. A hírek szerint a Liberty Eclipse névre keresztelt gyakorlat egy hetes lesz és a New York közelében található Plum szigetén kerül megrendezésre. A gyakorlat célja egyértelmű, a DoE igyekszik felkészíteni az amerikai villamosenergia-szektor szereplőit a súlyos incidensek minél hatékonyabb elhárítására. A kérdés igazán az, hogy Európában és (ami számunkra még fontosabb, Magyarországon) a döntéshozók mikor fogják elég nagynak ítélni a kockázatokat, hogy hasonló, teljes szektorokat felölelő gyakorlatokat szervezzenek?

A Liberty Eclipse-ről bővebben a securityaffairs.co és az E&E News weboldalain lehet olvasni.

Opto22 rendszerek sérülékenysége

Robert Hawes egy sérülékenységet fedezett fel az Opto22 alábbi rendszereiben:

- PAC Control Basic Versions R10.0a és korábbi verziók;
- PAC Control Professional Versions R10.0a és korábbi verziók.

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

Sérülékenységek Ice Qube rendszerekben

Maxim Rupp két sérülékenységet talált az Ice Qube Thermal Management Center rendszerének 4.13-nál korábbi verzióiban.

A gyártó a hibákat a Thermal Management Center 4.13-as és ennél újabb verzióiban javította. 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-18-249-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 Pen Test Partners nevű IT biztonsági cég kutatói 20 különböző, tengerjáró hajók vezérléséhez használt OT rendszert vizsgáltak és számos olyan hibát találtak, amiket kihasználva támadók hozzáférhetnek többek között a motorok, ballaszt szivattyúk vezérlő rendszereihez és a hajók esetén általánosan használt ECDIS (Electronic Chart Display and Information System) rendszerekhez is.

A feltárt sérülékenységek között számos olyan, súlyos hiba is van, ami az ICS kiberbiztonsággal foglalkozó szakemberek számára nem számítanak újdonságnak (pl. a rendszerek adminisztrátori felületeinek Telnet-en vagy HTTP-n keresztüli elérése), a hajók vezérlőrendszerei esetén azonban mostanáig senki nem mérte fel a kockázatokat.

A Pen Test Partners kutatásairól részletesebben itt lehet olvasni: https://www.pentestpartners.com/security-blog/hacking-tracking-stealing-and-sinking-ships/

Qualcomm Life Capsule DTS sérülékenység

Elad Luz, a CyberMDX munkatársa egy távoli kódfuttatást lehetővé tevő hibát jelentett az NCCIC-nek, ami a Qualcomm Life Capsule Datacaptor Terminal Server (DTS) termékének egyik komponensét, az Allegro RomPager beágyazott webszerver 4.01-4.34-es verzióit érinti.

A gyártó kiadott egy új firmware verziót, ami csökkenti a sérülékenység okozta kockázatokat. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet bővebben olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-240-01

Sérülékenységek Schneider Electric PLC-kben

Az ICS-CERT két bejelentést is megjelentetett, amikben a Schneider Electric által gyártott ModiCon M221 PLC-k sérülékenységeiről adnak tájékoztatást.

Az első bejelentésben ismertetett sérülékenységeket a New Orleans-i egyetem munkatársai, Irfan Ahmed, Hyunguk Yoo, Sushma Kalle és Nehal Ameen fedezték fel és a ModiCon M221 minden, 1.6.2.0-nál korábbi firmware verzióit érintik.

A gyártó a hibákat az 1.6.2.0 firmware verzióban javította. További részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-01

A másik, sérülékenységről szóló bejelentésben szereplő hiba szintén a a ModiCon M221 minden, 1.6.2.0-nál korábbi firmware verzióit érinti. A hibát a gyártó ebben az esetben is az 1.6.2.0 verzióban javította. Ennek a sérülékenységnek a részleteit ebben a publikációban lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-02

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

A Schneider Electric, Ezequiel Fernandez-zel és Bertin Jose-val együttműködve egy Cross-Site Scripting sérülékenységet azonosított a PowerLogic PM5560 2.5.4-nél korábbi firmware verzióiban.

A gyártó a hibát a 2.5.4-es verzióban javította. A sérülékenységről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-03

ABB eSOMS sérülékenység

Az ABB egy nem megfelelő authentikációból adódó sérülékenységet jelentett az NCCIC-nek. A hiba az eSOMS 6.0.2-es verzióját érinti.

A gyártó a hibát tervei szerint a szeptember végén publikálásra kerülő új eSOMS verzióban fogja javítani, addig is kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további részleteket illetve az ABB kockázatcsökkentő javaslatait az ICS-CERT weboldalán lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-04

Sérülékenységek Philips rendszerekben

A gyártó 9 különböző sérülékenységet jelentett az NCCIC-nek, amik a Philips e-Alert rendszerének R2.1 és korábbi verzióit érintik.

A hibák közül négyet a júniusban megjelent R2.1 már javította, a maradék öt sérülékenység javítását a gyártó 2018 végére igéri. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-242-01

Lehetséges malware-fertőzött USB adathordozók Schneider Electric rendszerekhez kapcsolódóan

A gyártó bejelentése szerint lehetséges, hogy az alábbi rendszereihez kapcsolódó USB adathordozók közül néhány malware-fertőzött lehet:

- Conext Combox (sku 865-1058) és
- Conext Battery Monitor (sku 865-1080-01) termékekkel érkező USB adathordozók.

Az USB adathordozókon rendszerdokumentációk és a rendszerek működéséhez nem nélkülözhetetlen szoftverkomponensek találhatók. A gyártó ajánlása az esettel kapcsolatban az érintett USB adathordozók törlése. A szükséges rendszerdokumentációkat és szoftvereket az ügyfelek a Schneider Electric weboldaláról is le tudják tölteni.

Az esettel kapcsolatosan bővebb infomációkat a Schneider Electric weboldalán lehet találni.

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.

Még nyáron a helpnetsecurity.com-on megjelent egy 5 részes cikksorozat, aminek célja, hogy azok az IT biztonsági szakemberek, akik érdeklődnek az ICS kiberbiztonság témája iránt, megértsék azokat az alapvető különbségeket, amik nélkül egy tapasztalt IT biztonsági szakember is komoly hibákat véthet, ha ICS rendszerekkel kell dolgoznia (én már a saját bőrömön tapasztaltam ilyet...).

A cikksorozat első részében az ICS/OT világ rövid áttekintése mellett szó esik a biztonság különböző aspektusairól (security és safety) és az IT illetve OT biztonsági szempontok hierarchiájáról. Röviden áttekintésre kerül a Purdue-modell (erről korábban már én is írtam itt a blogon) és végül nagyon röviden említésre kerül néhány modern ICS biztonsági eszköz és intézkedés. A cikksorozat első része itt érhető el: https://www.helpnetsecurity.com/2018/07/13/ot-ics-landscape/

A második részben a szerző megpróbálja összegyűjteni, hogy mi motiválhatja az ICS rendszerek ellen támadást indító személyeket/cosportokat, majd a Stuxnet és az ukrán villamosenergia-rendszer elleni támadások példáján részletesebben is bemutatja, hogyan sikerült korábban többször is nagyon súlyos következményekkel járó támadásokat vezetni fontos ICS rendszerek ellen. A második részt itt lehet elolvasni: https://www.helpnetsecurity.com/2018/07/19/hackers-exploit-critical-infrastructure/

A harmadik rész nagyrészt a SCADA rendszerekkel és sérülékenységeikkel foglalkozik, egy rövid kitekintéssel az autókban használt folyamat szabályózó eszközök világába: https://www.helpnetsecurity.com/2018/07/26/scada-vulnerabilities-in-ics-architectures/

A negyedik rész tovább boncolgatja a SCADA és autókba épített vezérlő rendszerek sérülékenységeit és igyekszik néhány biztonsági alapelvet is megfogalmazni: https://www.helpnetsecurity.com/2018/07/26/scada-vulnerabilities-in-ics-architectures/

Az utolsó, ötödik részben a szerző részletesen foglalkozik az IT hálózatok felől az OT rendszerek és hálózatok felé irányuló fenyegetésekről (amik, ezt nem lehet elégszer hangsúlyozni, nem feltétlenül kell, hogy ártó szándékúak legyenek - elég arra gondolni, hogy milyen alapvető és jelentős különbségek vannak az IT és az OT közötti gondolkodásmódban és gyakorlatokban és rögtön be lehet látni, hogy az IT-ban legjobb gyakorlatként kezelt eljárások önmagukban is jelentős kockázatokat hordozhatnak az OT rendszerekre nézve, az OT-ben megszokott eljárások pedig lassúnak tűnhetnek az IT számára): https://www.helpnetsecurity.com/2018/08/02/protecting-industrial-cybersecurity/

 A blog lassan 3 éves fennállása alatt a legolvasottabb posztom az ICS rendszerekkel kapcsolatos alapfogalmakat összegyűjtő poszt volt, remélem, hogy ez a link- és cikk-gyűjtemény is sokak számára hasznos lesz.

Yokogawa rendszerek sérülékenysége

Az ICS-CERT publikációja szerint a gyártó a japán CERT-tel együttműködve hozott nyilvánosságra részleteket egy puffer túlcsordulásos hibáról, ami az alábbi termékeiket érinti:

- ASTPLANNER: R15.01 és korábbi verziók;
- iDefine for ProSafe-RS: R1.16.3 és korábbi verziók;
- STARDOM: VDS R7.50 és korábbi verziók;
- FCN/FCJ Simulator R4.20 és korábbi verziók;
- TriFellows: 5.04 és korábbi verziók.

A gyártó a hibákat az érintett rendszerek firmware-jeinek legújabb verzióiban javította. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-233-01

Sérülékenység Philips IntelliVue rendszerekben

Az ICS-CERT bejelentése alapján egy felhasználó jelentett egy sérülékenységet a Philips-nek, ami az IntelliVue Information Center iX B2 verzióját érinti.

A gyártó kockázatcsökkentő intézkedéseket dolgozott ki arra az időre, amíg 2018. szeptemberben ki tudja adni a hibát javító új verziót. A sérülékenységről bővebb információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-18-233-01

BD Alaris rendszerek sérülékenységei

Az ICS-CERT publikációja alapján Elad Luz, a CyberMDX munkatársa egy, a nem megfelelő authentikációból adódó sérülékenységet fedezett fel a BD alábbi egészségügyi rendszereiben:

- Alaris GS 2.3.6 és korábbi verziói;
- Alaris GH 2.3.6 és korábbi verziói;
- Alaris CC 2.3.6 és korábbi verziói;
- Alaris TIVA 2.3.6 és korábbi verziói.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedésekre vonatkozó javaslatokat tett közzé, a hiba javításáról jelenleg nincs információ. A sérülékenység részleteiről további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-235-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.

A Dragos által Allanite néven emlegetett csoport az ICS rendszerek mellett üzleti/vállalati hálózatokat is célba vesz, tevékenységük során elsősorban amerikai és Nagy-britanniai szervezetek, főként villamosenergia-ipari szereplők rendszerei és hálózatai ellen folytatnak felderítő és információszerző támadásokat.

A Dragos fenyegetés-elemző szakembereinek véleménye szerint az Allanite tevékenysége az ICS rendszerek esetében két fő célt szolgál, minél jobban megérteni az ICS rendszer és a rendszer által irányított folyamatok felépítését és működését illetve birtokolni azokat a hozzáféréseket, amiket felhasználva üzemzavarokat idézhetnek elő a villamosenergia rendszerekben.

A jelenleg ismerhető adatok alapján feltételezhető, hogy az Allanite legalább 2017 májusa óta aktív és a tevékenységük erős hasonlóságot mutat a DHS által Paletto Fusion nevű, amerikai vilalmosenergia-ipari cégeket célzó támadásokkal és kapcsolatot véltek felfedezni a Symantec által Dragonfly, a Dragos által Dymalloy néven emlegetett támadókkal. A Dragos elemzése szerint bár az Allanite a célpontok kiválasztása és a használt módszerek tekintetében mutat hasonlóságokat a Dragonfly/Dymalloy csoporttal, de a technikai képességeiket jelentősen különbözőnek tartják.

Az Allanite adathalász e-mail-támadásokkal és ún. watering hole-támadásokkal próbál weboldalakat kompromittálni és bejelentkezési adatokat szerezni, amikkel utána képesek hozzáférést szerezni a célba vett hálózatokhoz, ide értve az adott szervezetek ICS rendszereiből gyűjtött képernyőképeket is. Az Allanite ilyen jellegű tevékenysége a megfigyelések alapján mostanáig csak az információszerzésre terjedt ki, nincs bizonyíték arra, hogy a csoportot bármilyen, üzemzavart okozó tevékenységhez lehetne kapcsolni.

Az Allanite jellemzően nem használ malware-eket, ezek helyett az adott rendszerekben legitimnek számító eszközöket és a Windows operációs rendszerekben megtalálható eszközöket használják fel.

A Dragos publikációját az Allanite-ról itt lehet elérni: https://www.dragos.com/blog/20180510Allanite.html