A máricus 7-én, a Wikileaks által nyilvánosságra hozott CIA-s exploit-gyűjtemény (amiről nagyon sokan írtak az azóta eltelt közel két hétben, a szerintem egyik legérdekesebb nézőpontot képviselő írás itt található: http://freszbook.blogspot.hu/2017/03/a-cia-vs-wikleaks-margojara.html) nyomán a Cisco kritikus besorolással tette közzé az IOS és az IOS XE szoftvereik Cluster Management Protocol-jában felfedezett, távoli kódfuttatást (Remote Code Execution, RCE) lehetővé tevő hibát. A sérülékenység 319 különböző Cisco terméket érint, amennyiben a 15.2(5.5.15i)E2-nél korábbi verziójú firmware-t használnak. Minket ezek közül most csak a kifejezetten ipari környezetekbe szánt eszközök érdekelnek igazán (bár a nem ipari felhasználásra tervezett eszközök is jelen lehetnek vezérlőközpontok, alállomások és más létesítményekben, pl. informatikai géptermekben üzemeltetve):

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

A sérülékenységet javító patch kiadását a gyártó későbbre ígéri. Mivel a sérülékenység kihasználásához szükség van az érintett eszközökön futó telnet szolgáltatásra, workaroundként a telnet letiltása lehet a megoldás - feltéve, hogy az adott eszközöket a szervezet képes a telnet-nél biztonságosabb módon is üzemeltetni.

További részleteket a sérülékenységgel kapcsolatban a Cisco publikációja tartalmaz: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp

Az ICS-CERT bejelentése szerint amerikai egyetemi kutatók egy csoportja (Timothy Trippel, Ofir Weisse, Peter Honeyman és Kevin Fu a University of Michigan-ről és Wenyuan Xu a  University of South Carolina-ról) egy hardver-tervezési hiba okozta sérülékenységet találtak számos, MEMS gyorsulásmérő szenzort használó eszközben:

Bosch BMA222E,
STMicroelectronics MIS2DH,
STMicroelectronics IIS2DH,
STMicroelectronics LIS3DSH,
STMicroelectronics LIS344ALH,
STMicroelectronics H3LIS331DL,
InvenSense MPU6050,
InvenSense MPU6500,
InvenSense ICM20601,
Analog Devices ADXL312,
Analog Devices ADXL337,
Analog Devices ADXL345,
Analog Devices ADXL346,
Analog Devices ADXL350,
Analog Devices ADXL362,
Murata SCA610,
Murata SCA820,
Murata SCA1000,
Murata SCA2100,
Murata SCA3100.

A sérülékenységgel kapcsolatban javításról egyelőre nincs információ, a Robert Bosch GmbH két dokumentumot publikált az esettel összefüggésben, az elsőben további információkat közöl a sérülékenységről, a másodikban pedig az érintett eszközök kezelésével és szerelésével kapcsolatos információkat adtak közre. Egy másik gyártó, az InvenSense Inc. bejelentésében szintén elismerte, hogy az érintett szenzort használó termékeik egyes esetekben a tervezettől eltérően működhetnek.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-073-01

Hosszú ideje szerepel a listámon egy blogposzt a Shodan kereső motorról, de ma végre eljött a napja, hogy erről is beszéljünk.

A Shodan-t 2009-ben John Matherly hobbiként kezdte fejleszteni. A projekt elsődleges célja a különböző, Internetre csatlakoztatott eszközök egy, a megszokottól eltérő katalogizálása volt. Míg a Google, a Bing, a Yahoo és a többi nagy keresőoldal az Interneten elérhető tartalom alapján  katalogizálja a különböző weboldalakat és egyéb szolgáltatásokat, a Shodan az eszközök által visszaadott meta-adatok alapján indexeli és teszi kereshetővé a szolgáltatásokat.

A Shodan projekt kezdetben HTTP, HTTPS, FTP, SSH, Telnet, SNMP, SIP és RTSP protokollokra koncentráltak, mára a Shodan által felismert és katalogizált protokollok száma meghaladja a 170-et. Igazán ismertek akkor lettek, amikor 2013-ban a CNNMoney.com-on megjelent egy cikk, amiben a Shodan-ról, már mint olyan keresőről írtak, amivel Internetre csatlakoztatott folyamatirányító rendszereket (a cikkben a közlekedési lámpákat vezérlő PLC-ről volt szó) lehet találni.

A Project SHINE-ban Bob Radvankovsky, egy az USA-ban igen elismert ICS biztonsági kutató a Shodan-t használta arra, hogy felmérje az Internetre csatlakoztatott ICS rendszerek számát. A kutatást 2012 áprilisában kezdte és 2013 végére több, mint 64 gyártó több, 1 milliónál is több ICS eszközét találta meg az Interneten a Shodan segítségével és ez a szám naponta 2000-8000 darabbal nőtt!

A Shodan számos lehetőséget ad arra, hogy gyártók, portok, városok vagy országok alapján keressünk, ami kiváló eszközzé teszi, ha sérülékeny, Internetre csatlakoztatott ICS eszközöket keresünk.

A Shodant anonim módon lehet használni, lehetőség van ingyenes regisztrációra (ekkor már lehetőség van a kereséséi eredmények mentésére, ehhez több féle fájlformátumot, JSON-t, XML-t, CSV-t támogatnak és lehet riportokat készíteni a keresések eredményeiből, a riportokhoz vezetők linkeket e-mailben küldik el a regisztrációkor megadott e-mail címre). A következő szint a (jelenleg) 49 amerikai dollárért történő regisztráció, ez a most rendelkezésre álló információk szerint egyszeri összeg és véglegesen hozzáférést biztosít a Shodan összes funkciójához, többek között a Shodan API fejlesztői dokumentációhoz, lehetőséget ad térképre helyezni a keresési találatokat, számos ismert és elterjedt szoftverrel teszi integrálhatóvá a Shodan-t (többek között a Metasploit-tal, a Maltego-val, a Google Chrome-mal, stb.) és az ingyenes változatoktól eltérően itt már nincs meg az 50-es limit a találatok megjelenítésénél.

Sajnos nem csak biztonsági kutatók, hanem a támadók is előszeretettel használják a Shodan-t, ezért az ICS rendszerek biztonságáért felelős szakembereknek is csak azt tudom ajánlani, hogy (ammennyiben a saját szervezetük nem tiltja az ilyen eszközök használatát) rendszeresen ellenőrizzék az általuk használt publikus IP címeket és szolgáltatásokat, hogy minél inkább tisztában legyenek azokkal az információkkal, amiket egy potenciális támadó ki tud nyerni a Shodan-ból.

Karn Ganeshen, az egyik legtermékenyebb ICS sérülékenységekre vadászó biztonsági kutató a brazil LCDA (Leao Consultoria e Desenvolvimento de Sistemas LTDA ME) SCADA rendszerében talált egy nem megfelelő hozzáférés-vezérlésből eredő hibát. A sérülékenység a LAquis SCADA 4.1 és minden, 2017. január 20-a előtt megjelent verzióját érinti.

A gyártó a hiba javítását elérhetővé tette a weboldalán: http://laquisscada.com/instale1.php

A sérülékenységről további részleteket ezúttal is az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-075-01

Az ICS-CERT szokásos módon ezúttal is a 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áltasáok hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az ICS-CERT tegnapi publikációja szerint az alábbi Fatek Automation PLC-kben használt Ether_cfg szoftverkonfigurációs eszközben puffer túlcsordulási hibát fedezett fel egy meg nem nevezett biztonsági kutató:

- CBEH V3.6 Build 170215-nél korábbi verziók;
- CBE V3.6 Build 170215-nél korábbi verziók;
- CM55E V3.6 Build 170215-nél korábbi verziók;
- CM25E V3.6 Build 170215-nél korábbi verziók.

A gyártó a hibát az Ether_cfg szoftverkonfigurációs eszköz új verziójában javította, amit a weboldaláról lehet letölteni: http://www.fatek.com/en/technical.php?act=software&catId=12

A sérülékenységgel kapcsolat további információkat a Fatek Automation és az ICS-CERT publikációi tartalmaznak.

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

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

Az elmúlt néhány napban több Schneider Electric termékkel kapcsolatban jelentek meg friss sérülékenységi információk.

Schneider Electric Wonderware Intelligence sérülékenység

A Schneider Electric házon belül talált egy, a felhasználói adatok kezelésével kapcsolatos hibát a Wonderware Intelligence 2014R3 és korábbi verzióiba beágyazottan használt Tableau Server/Desktop szoftver 7.0-tól 10.1.3-ig terjedő verzióiban. A hibát kihasználva egy támadó adminisztrátori szintű jogosultságot szerezhet a sérülékeny rendszereken.

A gyártó a hibát az alább felsorolt verziókban javította:

Tableau Analytics Dashboard Server v10.1.4
Tableau Analytics Client v10.1.4
Wonderware Intelligence 2014 R3

A sérülékenységről további információkat a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

Schneider Electric ClearSCADA sérülékenység

Sergey Temnikov és Vladimir Dashchenko, a Kapersky Lab Critical Infrastructure Defense Team-jének munkatársai fedeztek fel egy sérülékenységet a Schneider Electric ClearSCADA termékének alábbi verzióiban:

- ClearSCADA 2014 R1 (build 75.5210) és minden korábbi verziója;
- ClearSCADA 2014 R1.1 (build 75.5387) és minden korábbi verziója;
- ClearSCADA 2015 R1 (build 76.5648) és minden korábbi verziója;
- ClearSCADA 2015 R2 (build 77.5882) és minden korábbi verziója.

A hiba lehetővé teszi, hogy a sérülékeny rendszerek a bevitt adatokat bármilyen ellenőrzés nélkül dolgozzák fel, ezzel lehetővé válik egy támadó számára, hogy megzavarja vagy akár meg is szakítsa a sérülékeny rendszer üzemszerű működését.

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

- ClearSCADA 2014 R1.1 hotfix build 75.6239
- ClearSCADA 2015 R1.1 Service Pack (build 76.6191)
- ClearSCADA 2015 R2 hotfix build 77.6181

A ClearSCADA 2013R2 és ennél korábbi verzióit futtató felhasználók számára a Schneider Electric azt javasolja, hogy frissítsenek a ClearSCADA 2015R2 verzióra a hiba javítása érdekében.

A hibajavítás alkalmazása mellett a gyártó az alábbi kockázatcsökkentő intézkedések alkalmazását is javasolja a ClearSCADA termékcsaládot használó ügyfeleinek:

- Gondoskodjanak a ClearSCADA rendszerek és hálózati interfészeik fizikai biztonságáról;
- Megfelelően konfigurált tűzfalak alkalmazásával korlátozzák az egyes hálózati szegmensek közötti forgalmat a feltétlenül szükséges portokra és protokollokra;
- Minden külső hozzáférés esetén használjanak VPN-megoldást;
- A felhazsnálói biztonsági beállítások használatával és rendszeres auditálásával csökkentsék a DoS-támadások kockázatait;
- A ClearSCADA rendszerek kulcsfelhasználói fiókjainál a megfelelő biztonsági szabályok konfigurálásával tegyék minél nehezebbé a jogosulatlan bejelentkezéseket.

A sérülékenységről bővebb információkat a Schneider Electric és az ICS-CERT bejelentéseiben lehet olvasni.

A fenti sérülékenységekkel kapcsolatban az ICS-CERT ezúttal is az általános kockázatcsökkentési intézkedések alkalmazására hívja fel a figyelmet:

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

Az elmúlt bő egy évben már többször írtam már a SCADA Strangelove csoport munkáiról. A SCADA Strangelove egy orosz kutatókból álló csoport, ami elsősorban a különböző ICS/SCADA rendszerek biztonságát vizsgálja. Összesen 29-en vannak, név szerint:

- Alexander Timorin
- Alexander Tlyapov
- Alexander Zaitsev
- Alexey Osipov
- Andrey Medov
- Artem Chaykin
- Denis Baranov
- Dmitry Efanov
- Dmitry Nagibin
- Dmitry Serebryannikov
- Dmitry Sklyarov
- Evgeny Ermakov
- Gleb Gritsai
- Ilya Karpov
- Ivan Poliyanchuk
- Kirill Nesterov
- Roman Ilin
- Roman Polushin
- Sergey Bobrov
- Sergey Drozdov
- Sergey Gordeychik
- Sergey Scherbel
- Sergey Sidorov
- Timur Yunusov
- Valentin Shilnenkov
- Vladimir Kochetkov
- Vyacheslav Egoshin
- Yuri Goltsev
- Yuriy Dyachenko

Céljuk, saját bevallásuk szerint az, hogy megmentsék az emberiséget az ipari katasztrófáktól és (az ő szóhasználatukkal "megőrizzék a lényeg tisztaságát"). Elmondásuk szerint a Stuxnet nyilvánosságra kerülése után kezdtek foglalkozni az ICS rendszerek biztonságával és elég gyorsan felmérték, hogy az ICS rendszerek már az élet minden területén jelen vannak. További megállapításaik:

- Jellemzően régi technológiát képviselnek, a klasszikus vagy modern biztonsági alapelvek bármilyen alkalmazása nélkül;
- Az ICS rendszerek (elvileg) izolált hálózatokban működnek, de idővel mindig kiderül, hogy ezek a hálózatok más hálózatokhoz vannak csatlakoztatva, ezek a "más hálózatok" pedig már gyakran rendelkeznek Internet-kapcsolattal is;
- Ma már több, nyilvánosan elérhető eszköz (Shodan és Censys keresők, zmap, masscan) érhető el az Internetre csatlakoztatott ICS rendszerek felderítésére
- Az ICS rendszereket üzemeltető mérnökök a mai napig azzal érvelnek, hogy "Ez már nagyon régen így működik - ne nyúlj hozzá!";
- A valóság azonban az, hogy a támadók igenis képesek és készek hozzányúlni az ICS rendszerekhez;
- A SCADA Strangelove alapítóit ezek a tények aggodalommal töltötték el;
- Nem voltak hajlandóak elfogadni a korábbi megközelítéseket, így  hát elhatározták, hogy változtatnak a helyzeten - és 2012-ben, 4 taggal megszületett a SCADA Strangelove.

2013 és 2016 között jelentős fejlődésen ment át a csapat, a taglétszám 30 fő fölé nőtt, több, mint 100 0. napi sérülékenységet azonosítottak a legkülönbözőbb iparágakban (közlekedéstől a megújuló energia-rendszerekig) használt ICS rendszerekben. A feltárt hibák között voltak memóriakezeléssel kapcsolatos, webes, ipari protokollokat érintő hibák, backdoor-ok, hibás kriptográfiai modulok és beégetett gyári jelszavak is. A felfedezett sérülékenységek egyetlen nagyobb ICS gyártók termékeit sem kímélték - SCADA szerverek és kliensek, PLC-k, HMI-ok és MMI-ok, RTU, védelmi relék, konverterek, okosmérők, ipari switch-ek és GSM/GPRS-modemek egyaránt voltak a SCADA Strangelove által vizsgált és sérülékenynek talált ipari eszközök között.

A SCADA Strangelove tagjai különböző cégeknél dolgoznak és megvannak a saját projektjeik, de a csapatnak vannak hosszú távú projektjei is, ilyenek a SCADAPASS és a SCADASOS.

SCADAPASS

A SCADAPASS a különböző ICS eszközök gyári, beégetett jelszavainak gyűjtésére fókuszáló projekt. Legutóbb 2015. december 27-én tették közzé a gyűjtemény utolsó verzióját (erről egyébként anno én is hírt adtam, mindmáig ez a poszt a legolvasottabb a blogon)

SCADASOS

A SCADASOS ((in)Secure Open SmartGrids) projekt célja, hogy minél nagyobb mértékben csökkentse az olyan SmartGrid eszközök számát, amik Internet-kapcsolattal rendelkeznek. Az elmúlt években több, mint 80.000-rel csökkent azoknak az eszközöknek a száma, amiket az Internetről el lehet érni. Ez azonban még mindig csak csepp a tengerben, hiszen újabb és újabb gyártók és ICS rendszerek kerülnek elő, ahol nem csak a rendszert telepítő és üzemeltető szakemberek tudatlansága vagy nemtörődömsége, de adott esetben a gyártó ajánlása is ahhoz vezet, hogy az ICS rendszert vagy egyes komponenseit az Internetre csatlakoztassák (igen jó példa erre a december elején az ICS-CERT által publikált Locus Energy berendezések sérülékenységéről szóló bejegyzés is).

A SCADASOS projekt célja a SmartGrid, valamint a fotovoltalikus (napenergia) és szélerőmű-farmok kiberbiztonsági helyzetének javítása.

A SCADA Strangelove-ról további információkat a weboldalukon lehet megtudni.

Sérülékenység az Eaton xComfort Ethernet Communication Interface-ben

Maxim Rupp, az egyik legismertebb ICS biztonsági kutató az ICS-CERT bejelentése szerint egy hozzáférés-kezelési hibát fedezett fel az Eaton xComfort ECI 1.07-es és korábbi verzióiban. A hibát kihasználva egy támadó a megfelelő URL-en authentikáció nélkül férhető hozzá a sérülékeny rendszerek fájljaihoz.

A gyártó a sérülékeny verziót használói ügyfelei számára azt javasolja, hogy frissítsenek a legújabb verzióra, amiben a hibát már javították.

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-17-061-01

Schneider Electric Conext ComBox sérülékenység

Arik Kublanov és Mark Liapustin, a Nation-E Ltd. munkatársai a Schneider Electric Conext ComBox, model 865-1058-as eszközein használt V3.03 BN 830-nál korábbi firmware-verzióiban találtak hibát, amit kihasználva a sérülékeny eszközök túlterhelhetőek, aminek hatására újraindulhatnak.

A gyártó a hiba javítását a V3.03 BN 830-as firmware-ben már elérhetővé tette.

A sérülékenységről további információkat az ICS-CERT bejelentésében és a Schneider Electric publikációjában lehet olvasni.

A fenti hibákkal kapcsolatban az ICS-CERT ezúttal is az általános kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

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

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

Ez a poszt a 2016.12.31-én megjelent, Egészségügyi folyamatvezérlő rendszerek kiberbiztonsága című írásom második része.

2013-14 során az FDA útmutatókat jelentetett meg az egészségügyi rendszerek biztonságával kapcsolatban, a végleges útmutató végül 2014 októberben vált elérhetővé. Az FDA útmutatója elsősorban az egészségügyi folyamatvezérlő eszközök biztonsági funkcióonak tervezési és fejlesztési fázisban történő alkalmazását hangsúlyozza. Részletesen az alábbi intézkedéseket nevesítik (nem meglepő módon ezek sokszor egybevágnak az ICS rendszerek biztonsága kapcsán már megismert intézkedésekkel):

- Eszközök, fenyegetések és sérülékenységek azonosítása;
- Az egészségügyi eszközök funkcionalitását és/vagy a pácienseket/végfelhasználókat érintő fenyegetések és sérülékenységek értékelése;
- A fenyegetések és a sérülékenységek kihasználásának valószínűségeinek értékelése;
- A kockázati szintek és a megfelelő kockázatcsökkentési stratégiák meghatározása;
- A maradványkockázatok és a kockázat elfogadási feltételek értékelése.

Az egészségügyi rendszerek biztonsági helyzete a jelenben

Napjainkra már megkezdődött az a folyamat, aminek során biztonsági szakértők bevonásával és egy átfogó megközelítés alkalmazásával probálják javítani az egészségügyi eszközök biztonsági szintjét. A problémák sokrétűek, hardver és szoftverhibák, a rádiós kommunikációs csatornák elleni támadások, malware-ek és a különböző sérülékenységek kihasználása egyaránt ide tartoznak. Egy, a témában 2014-ben készített felmérés az mutatta ki, hogy az egészségügyi eszközök biztonságával kapcsolatos fejlesztések elsősorban a telemetriai interfészek elleni támadásokra koncentráltak. Ezek a telemetriai interfészek döntő részben a rádiós kommunikációhoz kapcsolódnak. A felmérésből tisztán látszik, hogy a vezeték nélküli telemetriai adatforgalmazásnak öt fontos területe van: a biometrikus authentikáció, a rádióhullámokon keresztül távolról végrehajtott authentikáció, a többfaktoros authentikáció, a külső eszközök és az anomáliák észlelése.

Az egészségügyi rendszerek jövője

A ma hozott intézkedések nagy mértékben meghatározzák az egészségügyi rendszerek biztonságának jövőjét is. A biztonság mindig a kompromisszumokról szól és a tét az egészségügyi rendszerek esetén az egyik legnagyobb. Azonban így sem szabad hagyni, hogy az egészségügyi eszközök biztonságával kapcsolatos esetekből szenzációt kreáljanak, ehelyett józan, racionális és szisztematikus megközelítéssel meg kell érteni és csökkenteni kell a biztonsági kockázatokat. Az FDA javaslatai az NIST kiberbiztonsági keretrendszere alapján a következők:

- Azonosítani kell a védelemre szoruló folyamatokat és eszközöket;
- Definiálni kell az elérhető védelmi intézkedéseket;
- Incidens-felismerési technikákat kell kidolgozni;
- Intézkedési terveket kell kialakítani az incidensek kezelésére;
- Formalizált helyreállítási tervet kell készíteni.

Az egészségügyi rendszerekre leselkedő fenyegetések kiemelkedőek és az elkerülhetetlennek látszó nulladik napi támadásokkal is az egészségügyi eszközök teljes életciklusa alatt foglalkozni kell. Ez egy olyan feladat, amin az egészségügyi szolgáltatóknak, az eszközök gyártóinak, a szoftverek fejlesztőinek és a biztonsági szakembereknek együttműködve kell dolgozniuk - gyakran a páciensek bevonásával.

A Siemens ProductCERT tegnapi bejelentése szerint a SINUMERIK termékcsalád alábbi tagjaiban Man-in-The-Middle támadást lehetővé tevő hibát fedeztek fel:

- A SINUMERIK Integrate Access MyMachine/Ethernet AMM  Service  Engineer  Client  (ActiveX)-szel használt összes verziója;
- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Integrate  Operate Client-tel használt verziói 2.0.3.00.016-tól a 2.0.6 előtti verzióig;
- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Integrate  Operate Client-tel használt verziói 3.0.4.00.032-tól a 3.0.6 előtti verzióig;

A hiba által érintett SINUMERIK Integrate Operate kliensek:
- V4.5 SP6-tól a V4.5  SP6  Hotfix  8 előtti verzióig;
- V4.7 SP2 Hotfix 1-től a V4.7  SP4 előtti verzióig.

A hibát a Siemens az érintett szoftverek alábbi verzióiban javította:

- A SINUMERIK Integrate Access MyMachine/Ethernet és az Analyze  MyCondition SINUMERIK Operate V4.7 SP4 vagy SINUMERIK Integrate Operate Client V3.0.6;
- SINUMERIK Operate V4.5 SP6 Hotfix 8 vagy SINUMERIK Integrate Operate Client V2.0.6;
- A SINUMERIK Integrate Access MyMachine/Ethernet AMM  Service  Engineer  Client  (ActiveX)-szel használt szoftvereket az AMM  Service Client V4.1.0.5-tel javasolják kiváltani.

A sérülékenységgel kapcsolatban további információkat a Siemens ProductCERT publikációjában lehet olvasni: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-934525.pdf