ABB netCADOPS sérülékenységek

İsmail Erkek, a Barikat Internet Security munkatársa egy kritikus adatbázis információkat közzétételét eredményező hibát fedezett fel az ABB netCADOPS alábbi verzióiban:

- netCADOPS Web Application Version 3.4 és korábbi verziók;
- netCADOPS Web Application Version 7.1 és korábbi verziók;
- netCADOPS Web Application Version 7.2x és korábbi verziók;
- netCADOPS Web Application Version 8.0 és korábbi verziók;
- netCADOPS Web Application Version 8.1 és korábbi verziók.

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

- ADMS 3.4.34.6 Release 16;
- ADMS 7.1.16.1 Release 16;
- ADMS 7.2.10 Release 16;
- ADMS 8.0.20 Release 16;
- ADMS 8.1.7.1 Release 16.

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

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

- RUGGEDCOM APE: minden verzió;
- RUGGEDCOM RX1400 VPE: minden verzió;
- SIMATIC ET 200 SP Open Controller: minden verzió;
- SIMATIC Field PG M4: minden verzió;
- SIMATIC Field PG M5: minden V22.01.05-nél korábbi verzió;
- SIMATIC HMI Basic Panels 2nd Generation: minden verzió;
- SIMATIC HMI Comfort 15-22 Panels (6AV2124-0QC02-0AX1, 6AV2124-1QC02-0AX1, 6AV2124-0UC02-0AX1, 6AV2124-0XC02-0AX1): minden verzió;
- SIMATIC HMI Comfort 4-12" Panels: minden verzió;
- SIMATIC HMI Comfort PRO Panels: minden verzió;
- SIMATIC HMI KTP Mobile Panels: minden verzió;
- SIMATIC IPC227E: minden verzió;
- SIMATIC IPC277E: minden verzió;
- SIMATIC IPC347E: minden verzió;
- SIMATIC IPC377E: minden verzió;
- SIMATIC IPC427C: minden verzió;
- SIMATIC IPC427D: minden verzió;
- SIMATIC IPC427E: minden verzió;
- SIMATIC IPC477C: minden verzió;
- SIMATIC IPC477D: minden verzió;
- SIMATIC IPC477E: minden verzió;
- SIMATIC IPC547E: minden verzió;
- SIMATIC IPC547G: minden verzió;
- SIMATIC IPC627C: minden verzió;
- SIMATIC IPC627D: minden verzió;
- SIMATIC IPC677C: minden verzió;
- SIMATIC IPC677D: minden verzió;
- SIMATIC IPC827C: minden verzió;
- SIMATIC IPC827D: minden verzió;
- SIMATIC IPC847C: minden verzió;
- SIMATIC IPC847D: minden verzió;
- SIMATIC ITP1000: minden V23.01.03-nál korábbi verzió;
- SIMATIC ITP3000 v2: minden verzió;
- SIMATIC S7-1500 Software Controller: minden verzió;
- SIMATIC S7-1518-4 PN/DP ODK (MLFB: 6ES7518-4AP00-3AB0): minden verzió;
- SIMATIC S7-1518F-4 PN/DP ODK (MLFB: 6ES7518-4FP00-3AB0): minden verzió;
- SIMOTION P320-4E: minden verzió;
- SIMOTION P320-4S: minden verzió;
- SINEMA Remote Connect: minden verzió;
- SINUMERIK 840 D sl (NCU720.3B, NCU730.3B, NCU720.3, NCU730.3): minden verzió;
- SINUMERIK PCU 50.5: minden verzió;
- SINUMERIK Panels wtih integrated TCU: minden 2016-ban vagy korábban kiadott verzió;
- SINUMERIK TCU 30.3: minden verzió.

A SIMATIC IPC, SIMATIC Field PG, SIMATIC ITP, SIMOTION P és SINUMERIK PCU eszközökhöz a Siemens BIOS frissítéseket adott ki, amik az érintett CPU-k mikrokód-frissítését is tartalmazza. A gyártó emelett kiemeli, hogy a mikrokód-frissítés mellett az operációs rendszer frissítéseket is telepíteni kell.

A sérülékenységek Siemens-eszközökre vonatkozó részletes információit a Siemens ProductCERT publikációjában lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-168644.pdf

TPM sérülékenység Siemens SIMATIC IPC-kben

A Siemens ProductCERT egy, az Infineon által gyártott TPM modulban található titkosítással kapcsolatos sérülékenységről adott ki tájékoztatót, ami az alábbi SIMATIC termékeket érinti:

- SIMATIC Field-PG M5: BIOS < V22.01.04;
- SIMATIC IPC227E: BIOS < V20.01.10;
- SIMATIC IPC277E: BIOS < V20.01.10;
- SIMATIC IPC427E: BIOS < V21.01.07;
- SIMATIC IPC477E: BIOS < V21.01.07;
- SIMATIC IPC547G: minden verzió;
- SIMATIC ITP1000: BIOS < V23.01.03.

A Siemens kockázatcsökkentő intézkedésként azt javasolja az érintett modelleket és BIOS verziókat használó ügyfeleinek, hogy a TPM saját RSA kulcspárjai helyett biztonságos algoritmussal (pl. ECC-vel) generált kulcspárokat alkalmazzanak.

A sérülékenységről további részleteket a Siemens ProductCERT bejelentése tartalmaz: https://cert-portal.siemens.com/productcert/pdf/ssa-470231.pdf

Intel-sérülékenységek Siemens ipari PC-kben

A Siemens tájékoztatójában az Intel Management Engine, Intel Server Platform Services és az Intel Trusted Execution Engine sérülékenységeinek alábbi termékeire gyakorolt hatásairól ír:

- SIMATIC Field-PG M3: ME < V6.2.61.3535;
- SIMATIC Field-PG M4: BIOS < V18.01.06;
- SIMATIC Field-PG M5: BIOS < V22.01.04;
- SIMATIC HMI IPC677C: ME < V6.2.61.3535;
- SIMATIC IPC427D: BIOS < V17.0?.10;
- SIMATIC IPC427E: BIOS < V21.01.07;
- SIMATIC IPC477D: BIOS < V17.0?.10;
- SIMATIC IPC477D PRO: BIOS < V17.0?.10ç
- SIMATIC IPC477E: BIOS < V21.01.07;
- SIMATIC IPC547D: ME < V7.1.91.3272;
- SIMATIC IPC547E: ME < V9.1.41.3024;
- SIMATIC IPC547G: ME < V11.8.50.3425 és BIOS < R1.21.0;
- SIMATIC IPC547G: ME < V11.8.50.3425 és BIOS < R1.21.0;
- SIMATIC IPC627C: ME < V6.2.61.3535;
- SIMATIC IPC627D: ME < V9.1.41.3024;
- SIMATIC IPC647C: ME < V6.2.61.3535;
- SIMATIC IPC647D: ME < V9.1.41.3024;
- SIMATIC IPC677D: ME < V9.1.41.3024;
- SIMATIC IPC827C: ME < V6.2.61.3535;
- SIMATIC IPC827D: ME < V9.1.41.3024;
- SIMATIC IPC847C: ME < V6.2.61.3535;
- SIMATIC IPC847D: ME < V9.1.41.3024;
- SIMATIC ITP1000: BIOS < V23.01.03;
- SIMOTION P320-4S: BIOS < S17.02.06.83.1;
- SINUMERIK PCU50.5-C, WIN7: ME < V6.2.61.3535;
- SINUMERIK PCU50.5-C, WINXP: ME < V6.2.61.3535;
- SINUMERIK PCU50.5-P, WIN7: ME < V6.2.61.3535;
- SINUMERIK PCU50.5-P, WINXP: ME < V6.2.61.3535.

A gyártó a sérülékenységről kiadott publikációban megadta a sérülékenységet javító verziószámokat: https://cert-portal.siemens.com/productcert/pdf/ssa-892715.pdf

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

A Schneider Electric publikációja szerint egy jogosultsági szint emelést lehetővé tevő hibát azonosítottak a SAITEL DP rendszerek 11.06.04-nél korábbi verzióiban.

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

A sérülékenységgel kapcsolatos bővebb információkat a Schneider Electric tájékoztatójában lehet megtalá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.

Évek óta lehet hallani ICS biztonsági szakértőktől (és én is többször írtam már a blogon), hogy az ICS rendszerek kiberbiztonságának első és leginkább hatékony eleme, ha nem tesszük elérhetővé az ipari rendszereket az Internetről, ennek ellenére évről-évre nő az Interneten található ICS rendszerek száma.

Néhány hete a Positive Technologies munkatársai publikálták annak a 2017-ben végzett kutatásuknak az eredményét, aminek keretében több, mint 175.000 Internetre csatlakoztatott ICS rendszert találtak Shodan, Censys és Google keresésekkel.

Protokollok szerinti bontásban a legtöbb Internetről elérhető ICS rendszer HTTP protokollon volt elérhető, ezt követték a Fox épületautomatizálási protokollt és a Honeywell Niagara keretrendszerét használó rendszerek, az Ethernet/IP (ebben az esetben az IP Industrial Protocol-t jelöl), a BACnet és a Lantronix Discovery Protocol-t használó rendszerek.

Gyártók szerint nézve a legtöbb Interneten elérhető eszközt a Honeywell gyártotta , majd a Lantronix, az SMA, a Beck IPC, a Siemens és a Rockwell Automation rendszerei jöttek sorban.

A Positive Technologies publikációja itt érhető el: https://www.ptsecurity.com/upload/corporate/ww-en/analytics/ICS-Security-2017-eng.pdf

GE D60 Line Distance Relay sérülékenységek

Kirill Nesterov, a Kaspersky Lab munkatársa két sérülékenységet azonosított a General Electric D60 Line Distance Relay berendezéseinek 7.11-es és korábbi firmware-verzióiban. Az első hiba egy puffer-túlcsordulás, a második pedig egy memóriakezelési hiba. Mindkét sérülékenység távoli kódfuttatási lehetőséget ad egy, a hibát sikeresen kihasználó támadónak.

A gyártó a hibákat a legújabb firmware-verzióban javítottam, amit már elérhetővé tett a weboldalán.

A sérülékenység részleteiről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-046-02

Sérülékenység Nortek rendszerekben

Evgeny Ermakov és Sergey Gordeychik egy 'command injection' sérülékenységet találtak a Nortek Linear eMerge E3 sorozatú eszközeinek V0.32-07e és korábbi verzióiban. A sérülékenységet kihasználva egy támadó magas jogosultsági szintű kódfuttatásra lehet képes.

A gyártó az E3-as eszközök felhasználói programozási útmutatójában (a 47. oldalon) leírt eljárás szerint frissítését javasolja minden, érintett verziót használó ügyfelének.

A sérülékenységről bővebben információkat az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-046-01

Sérülékenységek Cisco ipari tűzfalakban

A Cisco bejelentése szerint egy, a tűzfal-szoftvereiben (mind a régebbi Security Appliance-ekben, mind az új, FirePower termékcsalád modelljeiben) használt XML parser olyan hibát tartalmaz, ami authentikáció nélkül biztosít lehetőséget egy támadónak távoli kódfuttatásra vagy a rendszer újraindítására. A sérülékenység az alábbi verziókat érinti:

- 8.x (a gyártói támogatás már megszűnt);
- 9.0 (a gyártói támogatás már megszűnt);
- 9.1;
- 9.2;
- 9.3;
- 9.4;
- 9.5;
- 9.6;
- 9.7;
- 9.8;
- 9.9.

A hibát a gyártó a következő verziókban javította:

- 9.1.7.23;
- 9.2.4.27;
- 9.4.4.16;
- 9.6.4.3;
- 9.7.1.21;
- 9.8.2.20;
- 9.9.1.2.

A sérülékenységgel kapcsolatban számos további részletet a Cisco publikációjában lehet találni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20180129-asa1#vulnerable

Schneider Electric Floating License Manager sérülékenységek

A gyártó bejelentése szerint az alábbi, Schneider Electric Floating License Manager-t használó termékeiben három sérülékenységet azonosítottak:

- SCADA Expert Vijeo Citect / CitectSCADA 7.30-as és 7.40-es verziók;
- CitectSCADA 2015 és 2016;
- Vijeo Historian / Citect Historian 4.40 és 4.50;
- CitectHistorian 2016;
- Citect Anywhere.

A gyártó a hibákat a Floating License Manager v2.1.0.0 verzióban javította.

A sérülékenységről bővebben a Schneider Electric weboldalán lehet olvasni.

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

A Schneider Electric által kiadott biztonsági figyelmeztetés szerint sérülékenység található a Flexera FlexNet Publisher komponensben, amit az alábbi Schneider Electric termékekben használnak:

- EcoStruxure Power Monitoring Expert 8.2 (Standard, DC, HC kiadások);
- StruxureWare Power Monitoring Expert 8.1 (Standard, DC, HC kiadások);
- StruxureWare Power Monitoring Expert 8.0 (Standard, DC, HC, kiadások);
- StruxureWare Power Monitoring Expert 7.2.x;
- Energy Expert 1.x (korábbi nevén Power Manager);
- EcoStruxure Power SCADA Operations 8.x (korábbi nevén PowerSCADA Expert), csak az Advanced Reports and Dashboards modul.

A gyártó a hibát javító patch-eket elérhetővé tette a weboldalán.

A sérülékenység részleteiről a Schneider Electric bejelentésében lehet olvasni.

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.

Január közepén az AV-TEST antivirus megoldásokat tesztelő cég kiadott egy összefoglalót a kutatásaikról, ami szerint a Spectre/Meltdown néven ismertté vált CPU-sérülékenységekhez megjelent proof-of-concept exploitra építve mostanra több, mint 130 különböző malware-mintát találtak. Bár a minták többsége az eredeti PoC kódra épül, már találtak olyan variánstis, amit JavaScript-ben írtak, így az elterjedtebb böngészők (Internet Explorer, Firefox, Chrome) is támadási kísérletek eszközei lehetnek.

A kutatók szerint az eddig talált malware-minták alapján a támadók még a kódjaik tesztelésénél tartanak, azonban ez azt is jelenti, hogy néhány hónapon belül készen állhatnak, hogy a céljaik (bármi is legyen) elérése érdekében felhasználják a most tökéletesítés alatt álló malware-eket.

A processzor gyártók és operációs rendszer fejlesztők az elmúlt egy hónapban számos mikrokód és szoftverfrissítést adtak ki, amivel próbálják csökkenteni a sérülékenységek jelentette kockázatokat, azonban ezek számos esetben igen komoly stabilitási problémákat okoztak (visszavont frissítései a Microsoft-nak és a RedHat-nek is voltak, a Microsoft pedig soron kívüli patch-et adott ki, hogy a Windows operációs rendszerek blokkolni tudják az Intel x86-os mikrokód frissítését, miután kiderült, hogy a Windows operációs rendszereknél működési zavarok jelentkezhetnek, ha az operációs rendszer nincs felkészítve a processzor mikrokód frissítésére).

Az ICS rendszerek frissítése ilyen körülmények között érthető okokból majdnem biztos, hogy többnyire még a gyártóknál sem kezdődött el, ez pedig azt jelenti, hogy nagyon jó eséllyel ezek a rendszerek önmagukban teljesen védtelenek lesznek, amikor megjelennek az első célzott vagy tömeges támadásokhoz használt malware-ek. Ahhoz, hogy ezt meg lehessen előzni, jelenleg csak egyetlen megoldás látszik, a már unalomig ismételt kockázatcsökkentő intézkedéseket kell mielőbb alkalmazni, elsődlegesen az ICS rendszerek szeparálását a vállalati és nyilvános hálózatoktól.

Vyaire Medical CareFusion Upgrade Utility sérülékenység

Mark Cross független biztonsági kutató egy DLL injectiont lehetővé tevő hibát fedezett fel a Vyaire Medical CareFusion Upgrade Utility nevű, Windows XP-n futó megoldásának 2.0.2.2 és korábbi verzióiban.

A gyártó a 2.0.2.2-es verziót és a Windows XP platformot már nem támogatja, ebben a verzióban és platformon a hibát nem is fogják javítani, helyette a 2.0.3.0 verziót ajánlják, ami Windows 7 és újabb operációs rendszer verziókon fut.

A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-037-01

Schneider Electric IGSS SCADA sérülékenység

Ivan Sanchez, a Nullcode munkatársa helytelenül implementált ASLR (Address Space Layout Randomization) és DEP (Data Execution Prevention) memóriakezelési eljárásokból adódó sérülékenységet talált a Schneider Electric IGSS SCADA V12 és korábbi verzióiban.

A gyártó a hibát a V13-as verzióban javította.

A sérülékenységről bővebb információkat az ICS-CERT és a Schneider Electric publikációiban lehet találni.

Sérülékenység WAGO PFC200 sorozatú berendezésekben

Reid Wightman, a CODESYS munkatársa egy nem megfelelő authentikációból adódó sérülékenységet fedezett fel a CODESYS Runtime alkalmazás alábbi verzióiban:

- CoDeSys Version 2.3.X;
- CoDeSys Version 2.4.X.

A CoDeSys Runtime az alábbi WAGO berendezéseket is érinti, amennyiben azok a 02.07.07(10)-nél korábbi firmware verziót futtatják:

- 750-8202;
- 750-8202/025-000;
- 750-8202/025-001;
- 750-8202/025-002;
- 750-8202/040-001;
- 750-8203;
- 750-8203/025-000;
- 750-8204;
- 750-8204/025-000;
- 750-8206;
- 750-8206/025-000;
- 750-8206/025-001;
- 750-8207;
- 750-8207/025-000;
- 750-8207/025-001;
- 750-8208;
- 750-8208/025-000.

A WAGO a hibákat javító patch-et a FW11-gyel elérhetővé tette.

A sérülékenység további részletei az ICS-CERT publikációjában érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-044-01

Schneider Electric IGSS Mobile (for Andriod and iOS) sérülékenységek

A gyártó két sérülékenységről publikált részleteket, amik az IGSS Mobile for Android 3.01-es és korábbi illetve IGSS Mobile for iOS 3.01-es és korábbi verzióit érintik. Az első sérülékenység egy man-in-the-middle támadást tesz lehetővé, a második pedig a jelszavak olvasható formában történő tárolásából adódik.

A hibát javító verziók már elérhetőek a Google Play illetve Apple Store-okban.

A sérülékenységek részleteit a Schneider Electric által kiadott tájékoztató tartalmazza.

Sérülékenység Schneider Electric StruxureOn Gateway-ekben

A gyártó által kiadott bejelentés alapján a StruxureOn Gateway minden, 1.2-esnél korábbi verziójában megtalálható az a sérülékenység, aminek kihasználásával egy támadó tetszőleges fájlt tölthet fel a sérülékeny rendszerekre és ezen keresztül távoli kódfuttatási jogosultságot szerezhet.

A hibát a gyártó a StruxureOn Gateway 1.2-es verziójában javította.

A sérülékenységgel kapcsolatban bővebb információkat a Schneider Electric bejelentésében 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.

A tegnap reggeli poszt után néhány órával látott napvilágot a hír, hogy a moszkvai nukleáris kutatóközpontban (ahol egyébként az orosz nukleáris fegyverekkel kapcsolatos kutatásokat is végzik), a kutatásokhoz használt szuperszámítógépen találtak cryptovalutát bányászó szoftvert.

Az incidens ebben az esetben a jelek szerint nem egy sikeres támadáskövetkezménye volt, hanem a központban dolgozó mérnökök közül néhányan úgy gondolták, hogy nem probléma, ha a kutatásokhoz használt szuperszámítógép teljesítményének egy részét cryptovaluta bányászatára fordítják. Az incidensért felelős mérnököket a hírek szerint akkor kapták rajta, amikor a szuperszámítógépet az Internetre próbálták csatlakoztatni - ez nem volt kifejezetten jó ötlet a részükről, mert ennek köszönhetően kerültek az orosz Szövetségi Biztonsági Szolgálat, az FSZB őrizetébe.

Ez az eset is kiválóan mutatja, hogy bár nagyon fontosak azok a műszaki biztonsági intézkedések, amikről én is rendszeresen írok a blogon, az egész nem sokat ér, ha a kritikus infrastruktúrákat üzemeltető emberek biztonságtudatossága nem megfelelő - és ez egy olyan feladat, aminek soha nem lehet a végére érni.

A részletekről számos különböző hírforrás beszámolt, többek között:

BBC - http://www.bbc.com

TheHackerNews - https://thehackernews.com

ArsTechnica - https://arstechnica.com

Ahogy az elmúlt év végén a cryptovaluták értéke soha nem látott magasságokba emelkedett, úgy nőtt az azt bányászó malware-ek és a velük végrehajtott támadások száma is. Egyes hírek szerint a WannaCry néven elhíresült (és több ICS rendszer leállításában is szerepet játszó) malware-hez hasonlóan az EternalBlue exploitot kihasználva terjedő, de ezúttal nem ransomware-ként, hanem cryptobányászként viselkedő malware kezd terjedni, aminek az IT biztonsági szakma a WannaMiner nevet adta. Mostanáig ezek a cryptobányász malware-támadások nem érintettek ICS rendszereket (vagy legalábbis publikusan ilyen hír nem volt elérhető), a héten azonban ez is megváltozott. Egy európai szennyvízkezelő cég Windows XP-alapú GE Digital CIMPLICITY SCADA szerverein a Monero cryptovalutát bányászó malware-t talált a Radiflow nevű IT biztonsági cég.

Az incidenssel kapcsolatban már több cikk is megjelent, a részleteket az eWeek és a SecurtiyWeek oldalain lehet olvasni.

Kérdésből persze több is felmerül az emberben, de a válaszok egyáltalán nem adnak okot bizakodásra.

1. Meglepő-e, hogy az ICS rendszereket is elérték a cryptobányász malware-ek? A válasz röviden: nem. Ahogy ebben az esetben is látható, a SCADA szoftver egy kb. 5 éve nem támogatott operációs rendszerre volt telepítve, vagyis a rendszerben számos olyan ismert és nem javított hiba van, amit egy támadó kihasználhat, hogy saját kódot futtasson. Ha ehhez hozzátesszük azt a tényt, hogy az ICS biztonsági szakma minden erőfeszítése ellenére folyamatosan nő az Internetről elérhető ICS rendszerek és berendezések száma, csak az meglepő ebben az incidensben, hogy nem került napvilágra jóval korábban egy hasonló eset.

2. Mire lehet számítani a jövőben? Véleményem szerint a hasonló incidensek száma nőni fog - az persze nem világos, hogy ezek mekkora hányada lesz publikálva, de abban biztos vagyok, hogy a helyzet nem fog javulni, sőt romlani fog.

Mit lehet tenni, hogy megelőzzünk egy hasonló incidenst?

Elsősorban az ICS biztonsági szakértők által gyakran hangoztatott intézkedéseket kell bevezetni illetve fenntartani, ha már bevezették:

- Az ICS berendezéseket és rendszereket nem szabad publikus hálózatokra csatlakoztatni!
- Az ICS és vállalati IT rendszereket megfelelő hálózati szegmentálással kell egymástól elválasztani! Ennek tervezéséhez és megvalósításához a Purdue-modell ad némi kapaszkodót.
- A megfelelő hálózati szegmentálás után mélységi védelmet kell kiépíteni! Ehhez én célszerűnek tartom különböző gyártók különböző működési elvre épülő megoldásainak kombinálását (pl. eltérő gyártó végpontvédelmi megoldásainak alkalmazását a vállalati és ipari hálózatokban működő számítógépeken, különböző gyártóktól származó tűzfalak, stb. használatát).
- A megelőzés mellett fel kell készülni arra is, ha a támadók bizonyulnak jobbnak és átjutnak a kiépített védelmi vonalakon, megfelelő incidens észlelési képességeket kell kialakítani! Az ICS rendszerek nagyfokú statikussága ebben az esetben nagy segítség lehet, hiszen a jóval ritkább és kisebb számú változás mindegyikét ki lehet vizsgálni, ha a megfelelően képzett szakemberekből álló csapat rendelkezésre áll.
- Jól átgondolt és rendszeresen tesztelt incidenskezelési eljárásokat kell kialakítani és begyakoroltatni az abban résztvevő munkatársakkal!

A fenti (értelemszerűen nem teljes) lista persze nem fog senkit 100%-os biztonsággal megmenteni egy hasonló incidenstől, de esélyt biztosít arra, hogy a támadási kísérletek nagyobb hányadát tudják elhárítani és ha a támadók mégis bejutnának az ICS rendszerekbe, minél előbb képesek legyenek észlelni az incidenst, kizárni a támadókat és megszüntetni a tevékenységük negatív hatásait.

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

Ariele Caltabiano, a kimiya néven is ismert biztonsági kutató a ZDI-vel együttműködve publikált egy puffer-túlcsordulásra visszavezethető sérülékenységet, ami a Fuji Electric V-Server VPR adatgyűjtő és kezelő rendszerének 4.0.1.0 és korábbi verzióit érinti.

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

A sérülékenység részleteit az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-032-01

Sérülékenység CODESYS webszerverekben

Zhu WenZhe, az Istury IOT biztonsági labor munkatársa szintén egy puffer-túlcsordulásos hibát fedezett fel a 3S-Smart Software Solutions GmbH által gyártó CODESYS webszerverének minden, 2.3-nál korábbi Windows-alapú verziójában. A hiba a CODESYS runtime system minden, V1.1.9.19-nél korábbi verzióját is érinti.

A sérülékenységet a gyártó a V1.1.9.19-es patch-ben és a CODESYS V2.3 web server for Windows verziókban fogja javítani.

A sérülékenységgel kapcsolatos további információkat az ICS-CERT publikációjában található: https://ics-cert.us-cert.gov/advisories/ICSA-18-032-02

Sérülékenységek Gemalto Sentinel License Manager-ben

A Kaspersky Lab munkatársai több hibát is találtak a Gemalto Sentinel License Manager termékében. A sérülékenységek minden HSP SRM, Sentinel HASP és Sentinel LDK terméket érintenek, ha azokon a Sentinel LDK RTE 7.55-nél korábbi verzió fut.

A hibák között DoS-támadáshoz használható null pointer hivatkozás, több puffer-túlcsordulás és nem megfelelő hozzáférés-kezelés is található.

A gyártó a hibákkal kapcsolatban azt javasolja az érintett verziókat használó ügyfeleinek, hogy frissítsék az általuk hasznlát Sentinel LDK RTE verzióját 7.6-ra vagy az elérhető legújabb verzióra.

A sérülékenységről bővebben az ICS-CERT bejelentésében vagy a Kaspersky Lab cikkében lehet olvasni.

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

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

Tavaly decemberben elég nagy port kavart ICS biztonsági körökben a hír, hogy egy meg nem nevezett Közel-keleti országban egy olyan ICS malware-t fedeztek fel, ami a Schneider Electric Triconex SIS rendszerét fertőzte meg. Ezt volt az ICS malware-ek sorában az első olyan kártevő, ami kifejezetten SIS rendszer ellen készült.

A hét elején egy nagyon érdekes kérdéseket feszegető blogposzt jelent meg a SANS Industrial Control Systems Security Blogon.

A legnyilvánvalóbb kérdés továbbra is az, hogy vajon miért az SIS rendszert vették célba a támadók? Amennyire a jelenleg rendelkezésre álló információk alapján meg lehet ítélni, ennek a támadásnak csak kétféle célja lehetett:

1. Az SIS által felügyelt folyamatok teljes leállítása
2. A biztonsági leállítási folyamatok akadályozása, szabotálása

Az igazán érdekes kérdés pedig az: hol van a Triton/TriSIS DCS-t, a létesítmény vezérlő rendszerét célzó párja?

További részleteket és a blogbejegyzéshez hasonlóan érdekes hozzászólásokat a fent hivatkozott bejegyzésben lehet olvasni.

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

A ZDI-nek az rgod néven tevékenykedő biztonsági kutató jelentett két, eddig nem ismert sérülékenységet, amik az Advantech WebAccess/SCADA (korábban WebAccess) V8.2_20170817-nál korábbi verzióit érintik.

A hibák között egy könyvtárbejárásos támadást lehetővé tevő és egy SQL injection sérülékenység található.

Az Advantech a hibákat a WebAccess/SCADA 8.3.0 verziójában javította.

A sérülékenységgel kapcsolatos részleteket az ICS-CERT bejelentése tartalmazza: https://ics-cert.us-cert.gov/advisories/ICSA-18-023-01

Sérülékenység Philips egészségügyi rendszerekben

Az ICS-CERT bejelentése szerint egy, a nem megfelelő munkamenet lejáratból adódó hibát azonosítottak a Philips által gyártott, szív- és érrendszeri képalkotó és adatkezelő rendszereinek 2.3.0 és korábbi verzióiban.

A gyártó jelenleg is dolgozik a hiba javítását tartalmazó új verzión.

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

Siemens Desigo PXC berendezések sérülékenysége

Can Demirel és Melih Berk Eksioglu a Biznet Bilisim munkatársai egy nem megfelelő authentikációból adódó sérülékenységet azonosítottak a Siemens Desigo PXC V6.00.204-nél korábbi verziójú termékei:

- Desigo Automation Controllers Compact PXC12/22/36-E.D;
- Desigo Automation Controllers Modular PXC00/50/100/200-E.D;
- Desigo Automation Controllers PXC00/64/128-U Web modullal;
- Desigo Automation Controllers for Integration PXC001-E.D;
- Desigo Operator Unit PXM20-E.

A Siemens a hibát a V6.00.204 és újabb verziókban javította.

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

Sérülékenység Nari rendszerekben

Kirill Nesterov és Alexey Osipov Kaspersky Labs munkatársai egy, a bevitt adatok nem megfelelő ellenőrzéséből adódó sérülékenységet azonosítottak a Nari PCS-9611-es relé, vezérlő és monitoring berendezéseiben.

A gyártó mostanáig semmilyen információt vagy javítást nem adott ki a sérülékenységgel kapcsolatban.

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

Sérülékenységek Siemens TeleControl rendszerekben

A Siemens ProductCERT három sérülékenységet azonosított a TeleControl Server Basic nevű termékének V3.1-nél korábbi verzióiban. A hibák között authentikáció megkerülést lehetővé tevő, jogosultság kezelést érintő és szolgáltatás-megtagadásos támadást lehetővé tevő hiba is található.

A gyártó a hibák javítása érdekében a legújabb elérhető TeleControl Server Basic verzióra történő frissítést javasolja.

A sérülékenységről további információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

Sérülékenység Phoenix Compact mGuard ipari hálózati eszközökben

A Phoenix Contact egy nem megfelelő integritás-ellenőrzésből adódó hibát azonosított az mGuard firmware-ek 7.2-től 8.6.0-ig terjedő verzióiban.

A hibát a gyártó a 8.6.1-es firmware-verzióban javította, amit az alábbi termékekhez a weboldaláról lehet letölteni:

- MGUARD CENTERPORT;
- MGUARD DELTA TX/TX;
- MGUARD DELTA TX/TX VPN;
- MGUARD GT/GT;
- MGUARD GT/GT VPN;
- MGUARD PCI4000 VPN;
- MGUARD PCIE4000 VPN;
- MGUARD RS2000 TX/TX VPN;
- MGUARD RS2000 TX/TX-B;
- MGUARD RS2005 TX VPN;
- MGUARD RS4000 TX/TX;
- MGUARD RS4000 TX/TX VPN;
- MGUARD RS4000 TX/TX VPN-M;
- MGUARD RS4000 TX/TX-P;
- MGUARD RS4004 TX/DTX;
- MGUARD RS4004 TX/DTX VPN;
- MGUARD SMART2;
- MGUARD SMART2 VPN;
- MGUARD RS2000 3G VPN;
- MGUARD RS4000 3G VPN;
- MGUARD CORE TX VPN;
- MGUARD RS2000 4G VPN;
- MGUARD RS4000 4G VPN.

A sérülékenység részletei az ICS-CERT bejelentésében találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-030-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.