Az elmúlt hét ismét nem múlt új ICS sérülékenységek nélkül.

Sérülékenységek Westermo berendezésekben

Mandar Jadhav, a Qualys Security munkatársa 3 sérülékenységet azonosított a Westermo alábbi termékeiben:

- MRD-305-DIN, 1.7.5.0-nél régebbi verziójú szoftverek használata esetén és
- MRD-315, MRD-355, MRD-455 1.7.5.0-nél régebbi verziójú szoftverek használata esetén.

A hibák között Cross-site request forgery és beégetett felhasználói azonosítók/jelszavak illetve titkosítási kulcs vannak.

A gyártó a hibák javítása érdekében a legfrissebb elérhető verzió (1.7.7.0) telepítését javasolja.

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

Rockwell Automation Allen-Bradley switch-ek sérülékenysége

A Rockwell Automation alábbi, Allen-Bradley termékcsaládjához tartozó, Cisco IOS és IOS XE kódbázisára épülő ipari hálózati eszközeivel kapcsolatban a Cisco által azonosított hibáról jelent meg publikáció az ICS-CERT weboldalán:

- A 15.2(5)EA.fc4 és korábbi firmware verziót használó alábbi eszközök
- Allen-Bradley Stratix 5400 ipari switch-ek;
- Allen-Bradley Stratix 5410 ipari switch-ek;
- Allen-Bradley Stratix 5700 és ArmorStratix™ 5700 ipari menedzselhető switch-ek;
- Allen-Bradley Stratix 8000 moduláris menedzselhető switch-ek;
- A 15.6(3)M1 és korábbi firmware verziót használó Allen-Bradley Stratix 5900 router-ek;
- A 15.2(4)EA és korábbi firmware verziót használó Stratix 8300 moduláris menedzselhető switch-ek.

A Cisco által azonosított hiba egy SNMP RCE-t lehetővé tevő sérülékenység. A hiba javítása érdekében a Stratix 8300-as eszközökre az ügyfeleknek javasolt a v15.2(4a)EA5 illetve későbbi firmware-verziót telepíteni.

További kockázatcsökkentést célzó javaslatokat és részletes információkat a sérülékenységgel kapcsolatban az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-208-04

Delta Industrial Automation rendszerek sérülékenységei

A ZDI által publikált nulladik napi sérülékenységeket Ghirmay Desta és egy axt név mögött megbújó személy fedezték fel. A hibák a PMSoft (2 stack-based puffer túlcsordulásra visszavezethető, távoli kódvégrehajtást lehetővé tevő hiba) és a WPLSoft (heap- és stack-based puffer-túlcsordulásokből eredő távoli kódvégrehajtást lehetővé tevő és memória-kezelési hibára visszavezethető távoli kódvégrehajtást lehetővé tevő hibák, szám szerint összesen 9 darab) termékcsaládokat érintik. A sérülékenységek közül többnél a ZDI publikációi megemlítik, hogy a gyártó és az ICS-CERT szerint az érintett szoftverek egy újabb verziója javítja a fenti hibákat, de a ZDI ezzel kapcsolatos gyártói bejelentésről nem tud.

A sérülékenységekről további részleteket a ZDI bejelentései tartalmaznak:
http://www.zerodayinitiative.com/advisories/ZDI-17-697/
http://www.zerodayinitiative.com/advisories/ZDI-17-698/
http://www.zerodayinitiative.com/advisories/ZDI-17-699/
http://www.zerodayinitiative.com/advisories/ZDI-17-700/
http://www.zerodayinitiative.com/advisories/ZDI-17-701/
http://www.zerodayinitiative.com/advisories/ZDI-17-702/
http://www.zerodayinitiative.com/advisories/ZDI-17-703/
http://www.zerodayinitiative.com/advisories/ZDI-17-704/
http://www.zerodayinitiative.com/advisories/ZDI-17-705/
http://www.zerodayinitiative.com/advisories/ZDI-17-706/
http://www.zerodayinitiative.com/advisories/ZDI-17-707/

Schneider Electric Wonderware ArchtestrA Logger sérülékenységek

A Schneider Electric által a saját weboldalán közzé tett bejelentés szerint a PowerSCADA Expert v8.2-ben használt Wonderware ArchtestrA Logger komponensben több sérülékenységet azonosítottak. A hibák között távoli kódvégrehajtást lehetővé tevő hiba, memóriaszivárgás és szolgáltatás megtagadásos támadást (DoS) lehetővé tevő hiba is van.

A gyártó a hibákat javító verziót a weboldalán elérhetővé tette.

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

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á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 labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A SANS ICS rendszerekhez kialakított képzésének haladó kurzusa (amint már a tanfolyam sorszámában az 500-as előtag is mutat) jelentős részben a Robert M. Lee által kidolgozott Active Cyber Defense Cycle (ACDC) köré épül. A tanfolyam, aminek jelenlegi (2017 nyár) tematikáját is Rob dolgozta ki, négy nagy fejezetre oszlik, amiket az egy hetes képzés első négy napjának programját adja. Az elméleti oktatás mellett mindegyik tanfolyami napon hangsúlyos a labor környezetben végzett gyakorlatok szerepe is.

Az első napon az ACDC alapvető bemutatása fenyegetésekkel kapcsolatos információgyűjtés különböző módszereit és az ICS rendszerek információgyűjtéssel kapcsolatos támadási fejezeteit mutatja be. A nap laborjai során fel kell építeni a tanfolyamon kapott CYBATIworks PLC-t (ami egy apró útkereszteződést szimuláló eszköz kicsi jelzőlámpákkal, de van Shodan keresőmotorral történő ICS információgyűjtés is.

A második nap az aktív védelmi intézkedések "egyszerűbb" lépéseivel, az ICS rendszerek eszközeinek azonosításával és hangsúlyosan a hálózatbiztonsági monitoring feladataival foglalkozik. A nap laborjai között az IDS-ekkel és a hálózati (napló?)elemzéssel kapcsolatos feladatok is vannak.

A harmadik napon az incidenskezelés és az incidensek során történő nyomrögzítés (forensics) mellett külön fejezet tárgyalja, hogyan célszerű egy ICS incidenskezelő csoportot felépíteni, továbbá a folyamatvezérlő rendszerek üzembiztonságának és az incidenskezelés kapcsolatának kérdései is saját szekciót kapnak. A labor témái között megjelenik az ICS rendszerekben üzem közben történő adatgyűjtés, az összegyűjtött adatok ellenőrzésének és elemzésének és az IoC-knek a témái is.

A negyedik nap témája az ICS rendszerek és környezetek fenyegetéseinek mélyebb megértése köré épül. A korábban összegyűjtött bizonyítékok és a malwere-ek elemzése mellett szóba kerülnek a kompromittálás felismerését segítő jelzések (IoC-k) felismerésének módszerei is. A negyedik nap gyakorlatai között memóriából kinyert adatok elemzését és YARA szabályok írását lehet gyakorolni.

Az ötödik egyben utolsó nap egy egész napos gyakorlat köré épül, két forgatókönyvön keresztül az előző négy napon áttekintett elméleti és gyakorlati tudás alkalmazására ad lehetőséget a tanfolyam résztvevőinek.

A tanfolyamhoz 2017. július 7-e óta tartozik a GIAC (jelenleg) legújabb vizsgája és minősítése, a GRID (GIAC Response and Industrial Defense), amiről terveim szerint a közeli jövőben fogok egy rövid áttekintést adni.

Az elmúlt hét megint hozott néhány új ICS sérülékenységet.

Sérülékenység BMC Medical egészségügyi rendszerekben

Az ICS-CERT bejelentése szerint a MedSec egy, a bevitt adatok nem megfelelő ellenőrzéséből eredő sérülékenységet fedezett fel a BMC Medical Luna CPAP Machine nevű termékének 2017. július 1-je előtt kiadott verzióiban. A jelenleg rendelkezésre álló információk szerint az érintett berendezésekhez a gyártó sem javítást, sem más, kockázatcsökkentő intézkedést nem biztosít.

A sérülékenységgel kapcsolatban részleteket az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-17-227-01

Puffer-túlcsordulás Advantech WebOp berendezésekben

Az ICS-CERT publikációja szerint Ariele Caltabiano (másnéven kimiya) egy puffer-túlcsordulásos hibát talált az Advantech WebOp operátori panelekben, amit kihasználva egy támadó távoli kódfuttatási lehetőséghez juthat.

A gyártó mostanáig nem volt képes megerősíteni a sérülékenység létezését, így egyelőre javítás sem érhető el, azonban a hibát kihasználó exploit már publikus.

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

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

Az ICS-CERT bejelentése szerint a gyártó két sérülékenységet azonosított a DoseWise Portal 1.1.7.333-as és 2.1.1.3069-es verzióiban. A DoseWise egy web-alapú radiológiai ellenőrző rendszer.

A hibák között beégetett felhasználói azonosítók és olvasható formában tárolt érzékeny adatok vannak.

A gyártó jelenleg is dolgozik a hibákat javító verziókon, amik várhatóan még augusztus folyamán meg fognak jelenni. A javítások megjelenéséig a Philips az általános hálózatbiztonsági intézkedések bevezetését illetve a 1433/tcp port elérésének blokkolását javasolja (kivéve azokat az eseteket, amikor a DoseWise adatbázisa egy dedikált SQL szerveren fut).

A sérülékenységek részleteiről az ICS-CERT bejelentésében lehet további információkat találni: https://ics-cert.us-cert.gov/advisories/ICSMA-17-229-01

Automated Logic Corporation rendszerek sérülékenységei

Gjoko Krstic, a Zero Science Lab munkatársa három hibát talált az Automated Logic Corporation (ALC) WebCTRL, i-Vu, SiteScan Web rendszereinke alábbi verzióiban:

- ALC WebCTRL, i-Vu, SiteScan Web 6.5 és korábbi verziók;
- ALC WebCTRL, SiteScan Web 6.1 és korábbi verziók;
- ALC WebCTRL, i-Vu 6.0 és korábbi verziók;
- ALC WebCTRL, i-Vu, SiteScan Web 5.5 és korábbi verziók;
- ALC WebCTRL, i-Vu, SiteScan Web 5.2 és korábbi verziók.

A fenti verziók közül a gyártó a 6.0 és újabb verziókhoz biztosít támogatást, az 5.5, 5.2 illetve korábbi verziókat használó ügyfeleiknek a mielőbbi verzióváltást ajánlják, ha javítani szeretnék a most felfedezett sérülékenységeket.

A sérülékenységeket az alábbi hibajavítások telepítésével lehet megszüntetni:

- WebCTRL 6.0, Cumulative Patch #13;
- WebCTRL 6.1, Cumulative Patch #7;
- WebCTRL 6.5, Cumulative Patch #7 + WS65_Security_Update2.update;
- i-Vu 6.0, Cumulative Patch #13;
- i-Vu 6.5, Cumulative Patch #7 + WS65_Security_Update2.update;
- SiteScan Web Version 6.1, Cumulative Patch #7;
- SiteScan Web Version 6.5, Cumulative Patch #7 + WS65_Security_Update2.update.

A sérülékenységekkel kapcsolatban részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-234-01

SpiderControl SCADA MicroBrowser sérülékenység

Karn Ganeshen a ZDI-vel együttműködve talált egy puffer-túlcsordulásos hibát a SpiderControl SCADA MicroBrowser Versions 1.6.30.144 és korábbi verzióiban.

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

A sérülékenységről bővebb információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-234-02

SpiderControl SCADA Web Server sérülékenység

Szintén Karn Ganeshen és a ZDI találtak egy könyvtárbejárást lehetővé tevő sérülékenységet a SpiderControl SCADA Web Server menedzsment platformjában. A gyártó a hibát a 2.02.0100-as verzióban javította.

A sérülékenységgel kapcsolatosan további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-234-03

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 labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Idén év elején egy atlantai férfi 34 hónapos börtönbüntetést kapott, mert a Georgia-Pacific papírgyár korábbi alkalmazottjaként az elbocsátásakor vissza nem vett VPN-hozzáférésével bejelentkezett a papírgyár hálózatába és a saját szoftvereit telepítve nem engedélyezett változtatásokat végzett termelésirányító rendszerben. Az incidens közel 1,1 millió dolláros kárt okozott a Georgia-Pacific-nek.

Ez az eset kiválóan mutatja, hogy a belső ember(ek) által végrehajtott támadások milyen komoly fenyegetést jelentenek az ipari rendszereket üzemeltető szervezetek számára. Ennek számos oka van:

1. A távoli hozzáférés mára széles körben elterjedt az ICS rendszerek esetében is, ami nagyságrendekkel növeli ezeknek a rendszereknek a biztonsági kitettségét. Természetesen az ICS rendszerek távoli elérésének számos pozitív következménye is van (növekvő produktivitás, alacsonyabb üzemeltetési és üzemeltetés-támogatási költségek, kényelmesebb és munkavédelmi szempontból biztonságosabb munkavégzés, stb.), a használatukból adódó kockázati szint emelkedést nem szabad figyelmen kívül hagyni. Különösen azért nem, mert számos olyan esetről lehet tudni, amikor a VPN-megoldást (vagy sok évvel ezelőtt a betárcsázós modemet) egy, az OT-ben dolgozó mérnök egy projekthez kapcsolódóan, "csak a projekt idejére, ideiglenesen" helyezte üzembe, aztán ezt a megoldást elfelejtették vagy n+1. vészhelyzeti tartalék megoldásként mégis meghagyták és a mai napig üzemel. Jellemzően az ilyen módosítások soha, sehol nem kerülnek dokumentálásra, így esély sincs arra, hogy az ICS rendszerek kockázatelemzései/sérülékenység vizsgálatai során ezekről a felmérést végző szakemberek tudomást szerezzenek (hacsak a vakszerencse nyomra nem vezeti őket), így pedig az ilyen megoldások kockázatainak csökkentésére sincs mód. Ne legyen azonban kétségünk, egy felkészült támadó (nem is beszélve egy elégedetlen alkalmazottról) tudni fog az ilyen biztonsági résekről és nem fog hezitálni, hogy kihasználja-e a saját céljai eléréséhez.

2. Az ipari hálózatok hagyományos IT biztonsági kontrollok és monitoring terén rosszul teljesítenek. Ezt a témát már többször boncolgattam én is itt, a blogon, az ipari rendszerek és hálózatok IT biztonsági szempontból jellemzően rosszabbul teljesítenek, mint a legtöbb vállalati IT hálózat. Emiatt az ICS rendszerek biztonságáért felelős szakemberek gyakran nem vagy csak rossz hatásfokkal képesek kikényszeríteni a hozzáférési, biztonsági és változáskezelési szabályok betartását. Tovább rontja a helyzetet, hogy az ipari hálózatokban gyakran hiányoznak a naplózás és naplóelemzés funkciók, amik miatt nagyon gyengék az események észlelésével kapcsolatos kontrollok is, így pedig egy incidens esetén az azt elszenvedő szervezetnek nagyon kicsi esélye van a kiváltó ok gyors és költséghatékony beazonosítására.

3. Nem megfelelő átláthatóság az ICS vezérlési funkciók esetén. A hiányzó naplózás és naplóelemzés másik következménye, hogy az egyes szervezetek nem rendelkeznek tiszta képpel és nem képesek visszamenőleg ellenőrizni az OT-ben dolgozó mérnökök illetve a szállítók és támogatók munkatársai által a folyamatvezérlő rendszerekben végrehajtott változtatásokat. Emiatt, ha bárki a felsoroltak közül (vagy akár egy külső támadó) ártó szándékú változtatásokat hajt végre a rendszerben és ez akár komoly üzemzavarhoz is vezethet. Ez az ICS biztonság egy olyan vakfoltja, amit egy tapasztalt belső ember nagyon hatékonyan lehet képes kihasználni.

Valósidejű, ICS-fókuszú hálózatbiztonsági monitoring alkalmazása

A hálózatbiztonsági monitoring (NSM) az ICS biztonság egyik alapköve. Igaz ez az IT biztonságra is és fokozottan igaz az ICS kiberbiztonság területére, ahol az IT biztonsági monitoring funkciókon túl külön figyelmet kell fordítani az ipari vezérlési folyamatok minél részletesebb és zártabb naplózására és ellenőrzésére. Egyrészt ez segíthet időben észlelni az ártó szándékú beavatkozásokat, ezzel megelőzni egy komoly incidenst, de ha megelőzni nem is sikerül egy támadást, a részletes ICS NSM segítséget tud nyújtani az incidenskezelési folyamat során az incidens által okozott károk mielőbbi felszámolásában és az üzemszerű működés gyors helyreállításában.

Amikor ezt a posztot elkezdem írni, az ICS sérülékenységek sorozat CXXIX része még alig több, mint 36 órája élesedett, mégis már most 7 újabb ICS-CERT bejelentés van azon a listámon, amin a rövid összefoglalra váró hivatkozásokat gyűjtöm.

Az alább felsorolt sérülékenységekkel az idén eddig eltelt alig 7,5 hónap alatt több sérülékenységről számoltam be (pontosan 263-ról), mint tavaly egész évben (261). Nyilván az én gyűjtésem nem teljes (nem is lehet az), de minimum aggasztónak tartom az ICS rendszerekkel kapcsolatosan publikussá váló szoftveres (és jóval ritkábban hardveres) hibák számának ilyen ütemű növekedését.

Moxa SoftNVR-IA Live Viewer sérülékenység

Karn Ganeshen egy DLL Hijacking-re lehetőséget adó hibát talált a Moxa SoftNVR-IA Live Viewer 3.30.3122-es és korábbi verzióiban. A gyártó a hibát a 3.4-es verzióban javította.

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

Sérülékenység az OSISoft PI Integrator termékeiben

Az ICS-CERT bejelentése szerint az OSISoft 2 sérülékenységet talált és jelentett az ICS-CERT-nek, amik az alábbi termékeiket érintik:

- PI Integrator a SAP HANA 2016-hoz;
- PI Integrator a Business Analytics 2016 - Data Warehouse-hoz (minden verzió érintett);
- PI Integrator a Business Analytics 2016 - Business Intelligence-hez (minden kiadás érintett);
- PI Integrator a Business Analytics és SAP HANA SQL Utility 2016-hoz;
- PI Integrator a Microsoft Azure 2016-hoz.

A hibák között nem megfelelő jogosultságkezelés és Cross-site scripting található. A sérülékenységekkel kapcsolatos bővebb információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-220-01

ABB rendszerek sérülékenységei

Bertin Jose és Fernandez Ezequiel egy könyvtárbejárást lehetővé tevő sérülékenységet találtak az ABB alábbi termékeiben:

- SREA-01 A, B és C kiadásainak 3.31.5-nél korábbi verziói;
- SREA-50 A kiadásának 3.32.8-nál korábbi verziói.

A sérülékenységhez az HMS Industrial Networks Ab készített patch-et, amit az ABB az SREA-01 legutolsó verzióján tesztelt, de az ICS-CERT információi szerint az SREA-50 legutolsó verziójánál is alkalmazható.

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

Sérülékenységek a Fuji Electric Monitouch V-SFT rendszerében

A Fuji Electric Monitouch V-SFT 5.4.43.0-nál korábbi verzióiban két független kutató, Fritz Sands és kimiya találtak 3 hibát, amit az ZDI-nek jelentettek. A hibák között két puffer-túlcsordulás és egy nem megfelelő jogosultságkezelés található. A sérülékenységeket a gyártó a Monitouch V-SFT 5.4.43.0 verzióban javította.

A hibákról további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-222-04

Solar Controls rendszerek sérülékenységei

A Solar Controls rendszereivel kapcsolatban az ICS-CERT két hibát is publikált. Mindkettőt Karn Ganeshen fedezte fel. Az első egy DLL Hijacking-et lehetővé tevő hiba, ami a WATTConfig M Software 2.5.10.1-nél régebbi verzióit érinti.

A második hiba szintén DLL Hijacking-re ad lehetőséget a támadóknak, ez a HCDownloader 1.0.1.15-nél korábbi verzióiban található meg.

A gyártó egyik hiba esetén sem reagált az ICS-CERT megkeresésére, így a sérülékenységekkel kapcsolatban javítások sem érhetőek el.

További részleteket a WATTConfig M Software sérülékenységével kapcsolatban itt található: https://ics-cert.us-cert.gov/advisories/ICSA-17-222-03
A HCDownloader sérülékenységgel kapcsolatos bejelentés itt érhető el: https://ics-cert.us-cert.gov/advisories/ICSA-17-222-02

SIMPlight SCADA Software sérülékenység

A SIMPlight SCADA Software 4.3.0.27-nél régebbi verzióiban ismét Karn Ganeshen talált DLL Hijacking-et lehetővé tevő hibát. A Solar Controls-hoz hasonlóan a SIMPlight sem reagált az ICS-CERT megkeresésére, vagyis jelen pillanatban erre a sérülékenységre sincs elérhető javítás.

A hibával kapcsolatos ICS-CERT publikáció itt érhető el: https://ics-cert.us-cert.gov/advisories/ICSA-17-222-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á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 labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Az Independent írországi kiadása augusztus 6-án számolt be egy, az EirGrid (az ír villamosenergia-ipari rendszerirányító) illetve északír leányvállalata, a SONI elleni támadásokról.

Cathal McMahon, az Independent újságírójának információi szerint a támadók az ír rendszerirányítók távközlési szolgáltatójának, a Vodafone-nak a hálózatához szereztek hozzáférést idén áprilisban, majd ezután az EirGrid által használt routereken egy GRE (Generic Routing Encapsulation) tunnel-t hoztak létre, amivel le tudták hallgatni a hálózati forgalmat.

Az Independent cikke szerint a támadók az áprilisi betörés után több, mint két hónapig anélkül tudtak tevékenykedni az EirGrid hálózatában, hogy felfedezték volna őket, ez végül egy hónapja történt meg.

További részleteket az Independent.ie oldalán és az ennek nyomán született SecurityAffairs és BitDefender publikációkban lehet olvasni.

Fontos megjegyeznem, hogy bár az Independent cikke azt állítja, hogy a támadók akár jelentős áramkimaradást okozó üzemzavart is előidézhettek volna, jelenleg semmilyen publikusan elérhető információ nem támasztja alá ezt az állítást. Abból, amit eddig tudni lehet, minden jel arra utal, hogy ez az incidens az információszerzésről szólt (az ICS Cyber Kill Chain szerint ez az első fázis, az IT rendszerek kompromittálása a második fázishoz szükséges adatok összegyűjtése érdekében). Természetesen nem állítom, hogy ez a támadás nem lehet egy újabb, már az EirGrid (és/vagy a SONI) ICS rendszerei elleni támadást előkészítő művelet, de egyelőre erre semmilyen bizonyíték nem utal.

Az elmúlt héten 3 gyártó termékeivel kapcsolatban publikáltak újonnan felfedezett sérülékenységeket, köztük van két 0. napi hiba is.

Sérülékenységek Mitsubishi Electric rendszerekben

Az ICS-CERT és a ZDI publikációi szerint a Mitsubishi Electric Europe B.V. által forgalmazott E-Designer 7.52-es verziójának 344-es build-jében Andrea “rgod” Micalizzi talált három sérülékenységet. Az E-Designer a Mitsubishi E1000-es termékeinél használt HMI programozására szolgáló megoldás.

Az rgod által talált hibák között két puffer-túlcsordulás és egy nem megfelelő memória-kezelésből származó hiba van. A hibákkal kapcsolatban javításról nincs információ, a gyártó az érintett verziót használó ügyfeleknek azt javasolja, hogy vagy biztonságos, tűzfalakkal védett hálózatban használják az E-Designer-t vagy helyettesítsék az E-Designer-t a Mitsubishi újabb termékeibe épített interfészekkel. Az E-Designer-hez a gyártó már nem ad támogatást, így a jövőben sem várható javítás a most publikált hibákhoz.

A sérülékenységekkel kapcsolatban bővebb információ az ICS-CERT és a ZDI publikációiban található:

http://www.zerodayinitiative.com/advisories/ZDI-17-509/
http://www.zerodayinitiative.com/advisories/ZDI-17-510/
http://www.zerodayinitiative.com/advisories/ZDI-17-511/
http://www.zerodayinitiative.com/advisories/ZDI-17-512/
http://www.zerodayinitiative.com/advisories/ZDI-17-513/
http://www.zerodayinitiative.com/advisories/ZDI-17-514/
http://www.zerodayinitiative.com/advisories/ZDI-17-515/
http://www.zerodayinitiative.com/advisories/ZDI-17-516/
http://www.zerodayinitiative.com/advisories/ZDI-17-517/
http://www.zerodayinitiative.com/advisories/ZDI-17-518/

Schneider Electric rendszer sérülékenysége

Az ICS-CERT augusztus 3-án publikálta a Schneider Electric Pro-face GP-Pro EX termékének 4.07.000 verziójában Karn Ganeshen által talált, tetszőleges kódvégrehajtást eredményező hibát.

A gyártó a hibát a 4.07.100-as verzióban javította, amit a weboldalán tett elérhetővé.

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

0. napi sérülékenység az Eaton ELCSoft termékében

A TrendMicro-hoz tartozó ZDI által publikált információk szerint Ariele Caltabiano két puffer-túlcsordulásos hibát talált az Eaton ELCSoft nevű rendszerében (a bejelentés nem tartalmaz verziószámot, így feltételezhetjük, hogy minden verziót érintenek a hibák).

A sérülékenységekről néhány további részletet a ZDI publikációiban lehet találni:

http://www.zerodayinitiative.com/advisories/ZDI-17-519/
http://www.zerodayinitiative.com/advisories/ZDI-17-520/

Sérülékenységek Siemens Healthineers Mobilett Mira Max rendszerekben

A Siemens ProductCERT bejelentése alapján a gyártó javította az EternalBlue SMBv1 sérülékenységet a Mobilett Mira Max VE10S XP009/17/S nélküli verzióiban megtalálható hibát, ami 6 különböző kritikus sérülékenységért felelős.

A bejelentés elérhető a Siemens ProductCERT weboldalán: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_SSA-131263.pdf

0. napi sérülékenységek az Advantech WebAccess termékében

A ZDI 44 különböző publikációt adott ki, amik számos különböző Advantech WebAccess sérülékenységről szólnak. A hibákra jelenleg nincs elérhető javítás, amit különösen súlyossá az tesz, hogy a legtöbb hiba távoli kódfuttatást tesz lehetővé a sérülékeny rendszerekben.

Részleteket a ZDI bejelentéseiben lehet olvasni:

http://www.zerodayinitiative.com/advisories/ZDI-17-529/
http://www.zerodayinitiative.com/advisories/ZDI-17-530/
http://www.zerodayinitiative.com/advisories/ZDI-17-531/
http://www.zerodayinitiative.com/advisories/ZDI-17-532/
http://www.zerodayinitiative.com/advisories/ZDI-17-533/
http://www.zerodayinitiative.com/advisories/ZDI-17-534/
http://www.zerodayinitiative.com/advisories/ZDI-17-535/
http://www.zerodayinitiative.com/advisories/ZDI-17-536/
http://www.zerodayinitiative.com/advisories/ZDI-17-537/
http://www.zerodayinitiative.com/advisories/ZDI-17-538/
http://www.zerodayinitiative.com/advisories/ZDI-17-539/
http://www.zerodayinitiative.com/advisories/ZDI-17-540/
http://www.zerodayinitiative.com/advisories/ZDI-17-541/
http://www.zerodayinitiative.com/advisories/ZDI-17-542/
http://www.zerodayinitiative.com/advisories/ZDI-17-543/
http://www.zerodayinitiative.com/advisories/ZDI-17-544/
http://www.zerodayinitiative.com/advisories/ZDI-17-545/
http://www.zerodayinitiative.com/advisories/ZDI-17-546/
http://www.zerodayinitiative.com/advisories/ZDI-17-547/
http://www.zerodayinitiative.com/advisories/ZDI-17-548/
http://www.zerodayinitiative.com/advisories/ZDI-17-549/
http://www.zerodayinitiative.com/advisories/ZDI-17-550/
http://www.zerodayinitiative.com/advisories/ZDI-17-551/
http://www.zerodayinitiative.com/advisories/ZDI-17-552/
http://www.zerodayinitiative.com/advisories/ZDI-17-553/
http://www.zerodayinitiative.com/advisories/ZDI-17-554/
http://www.zerodayinitiative.com/advisories/ZDI-17-555/
http://www.zerodayinitiative.com/advisories/ZDI-17-556/
http://www.zerodayinitiative.com/advisories/ZDI-17-557/
http://www.zerodayinitiative.com/advisories/ZDI-17-558/
http://www.zerodayinitiative.com/advisories/ZDI-17-559/
http://www.zerodayinitiative.com/advisories/ZDI-17-560/
http://www.zerodayinitiative.com/advisories/ZDI-17-561/
http://www.zerodayinitiative.com/advisories/ZDI-17-562/
http://www.zerodayinitiative.com/advisories/ZDI-17-563/
http://www.zerodayinitiative.com/advisories/ZDI-17-564/
http://www.zerodayinitiative.com/advisories/ZDI-17-565/
http://www.zerodayinitiative.com/advisories/ZDI-17-566/
http://www.zerodayinitiative.com/advisories/ZDI-17-567/

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 labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A Hórusz forgatókönyvben (Horus scenario) megfogalmazott elmélet és annak bizonyítása Willem Westerhof munkája, aki az amszterdami egyetem (Hogeschool van Amsterdam) hallgatójaként, diplomamunkaként dolgozott ezen a témán az ITsec Security Services B.V.-nél töltött gyakorlata alatt.

Westerhof munkájában azt vizsgálta, hogy az Európában egyre növekvő (jelenleg 90 GW-nál nagyobb) fotovoltalikus (napenergia) termelési kapacitáson keresztül hogyan lehet befolyásolni az európai villamosenergia-átviteli rendszer egyensúlyát, ezen keresztül pedig egy komoly áramszünetet előidézni.

A napenergia-termelés két módon is hatással lehet az átviteli rendszerre, egyrészt a termelés helyén történő felhasználással csökkenteni tudja a hagyományos vagy megújulókra épülő nagyerőművektől a fogyasztókhoz szállítandó teljesítményt, másrészt a termelés helyén fel nem használt energia betáplálásra kerül a villamosenergia-rendszerbe és el kell szállítani azokra a helyekre, ahol igény van erre a teljesítményre.

Most persze bárki mondhatja, hogy a háztartási kiserőművek teljesítménye nem elég nagy ahhoz, hogy egy ilyenen keresztül érezhető hatást lehessen gyakorolni az európai átviteli rendszerre, a probléma azonban az, hogy egyre több ilyen kiserőmű létesül és ezek közül egyre többnek van Internet-kapcsolata is, vagyis a kitettségük egy Interneten keresztül érkező támadásnak eléri azt a szintet, amikor érdemes foglalkozni a kérdéssel.

Westerhof matematikai modellekkel és az európai villamosenergia-rendszerről publikusan elérhető adatok alapján építette fel az elméletét, majd ennek bizonyítására a gyakorlatban is elkezdte vizsgálni a fotovoltalikus inverterek terén jelentős szereplőnek számító SMA berendezéseit. A vizsgálatok során 17 sérülékenységet azonosított (ez a szám később a gyártó kérésére 21-re változott), ezek közül végül 14 kapott hivatalos CVE azonosítót, ezek az alábbiak:

- CVE-2017-9851
- CVE-2017-9852
- CVE-2017-9853
- CVE-2017-9854
- CVE-2017-9855
- CVE-2017-9856
- CVE-2017-9857
- CVE-2017-9858
- CVE-2017-9859
- CVE-2017-9860
- CVE-2017-9861
- CVE-2017-9862
- CVE-2017-9863
- CVE-2017-9864

A fenti sérülékenységek a CVSSv3 alapján 0.0-tól (informális) 9.0-ig (kritikus) terjedő besorolásokat kaptak. Westerhof a szakmailag elfogadott eljárásnak megfelelően jelezte a gyártónak 2016 decemberében a felfedezett sérülékenységeket, majd 2017 elején megosztotta az elméletet és a sérülékenységeket az illetékes kormányzati szervekkel és a villamosenergia-rendszer felügyeleti szerveivel.

Westerhof következtetése abból indul ki, hogy az egyre szaporodó megújuló erőművekben használt eszközök biztonsága általánosságban nem jobb és nem rosszabb, mint az általa tesztel SMA invertereké, így egy képzett támadót feltételezve a Hórusz forgatókönyvet megvalósíthatónak tartja. Legrosszabb esetben a támadó vagy támadók elég eszközt vonhatnak irányításuk alá ahhoz, hogy komolyabb üzemzavarokat és ezáltal áramkimaradásokat tudjanak előidézni (Ezzel kapcsolatban én azért kíváncsi lennék az európai rendszerirányításban dolgozó szakemberek véleményére is.)

A Hórusz forgatókönyvről további részleteket itt lehet olvasni: https://horusscenario.com/

Az elmúlt hét ismét meglehetősen sok ICS sérülékenység publikálását hozta.

NXP i.MX termékcsaládot érintő sérülékenységek

Az ICS-CERT bejelentése szerint a Quarkslab munkatársai két sérülékenységet azonosítottak az NXP i.MX termékeiben. Az alábbi eszközökben egy puffer-túlcsordulást találtak:

- i.MX 50;
- i.MX 53;
- i.MX 6ULL;
- i.MX 6UltraLite;
- i.MX 6SoloLite;
- i.MX 6Solo;
- i.MX 6DualLite;
- i.MX 6SoloX;
- i.MX 6Dual;
- i.MX 6Quad;
- i.MX 6DualPlus;
- i.MX 6QuadPlus;
- Vybrid VF3xx;
- Vybrid VF5xx és
- Vybrid VF6xx.

A másik hiba egy nem megfelelő tanúsítvány-ellenőrzésből adódik, ami az alábbi típusú eszközöket érinti:

i.MX 28;
i.MX 50;
i.MX 53;
i.MX 7Solo
i.MX 7Dual
Vybrid VF3xx;
Vybrid VF5xx;
Vybrid VF6xx;
i.MX 6ULL;
i.MX 6UltraLite;
i.MX 6SoloLite;
i.MX 6Solo;
i.MX 6DualLite;
i.MX 6SoloX;
i.MX 6Dual;
i.MX 6Quad;
i.MX 6DualPlus és
i.MX 6QuadPlus.

A gyártó közleménye szerint a fenti hibák hardveres hibák, így szoftveres javítás nem várható hozzájuk.

A sérülékenységekkel kapcsolatban az NXP közleménye itt, az ICS-CERT bejelentése itt olvasható: https://ics-cert.us-cert.gov/advisories/ICSA-17-152-02

PDQ Manufacturing termékek sérülékenységei

Az ICS-CERT bejelentése szerint Billy Rios és Jonathan Butts, a WhiteScope munkatársai, valamint Terry McCorkle független biztonsági kutató két sérülékenységet találtak a PDQ Manufacturing alábbi termékeiben:

- a LaserWash G5 és G5 S Series minden verziója;
- a LaserWash M5 minden verziója;
- a LaserWash 360 és 360 Plus minden verziója;
- a LaserWash AutoXpress és AutoExpress Plus minden verziója;
- a LaserJet minden verziója;
- a ProTouch Tandem minden verziója;
- a ProTouch ICON minden verziója és
- a ProTouch AutoGloss minden verziója.

A sérülékenységek között egy nem megfelelő authentikáció és a bizalmas adatok titkosításának a hiánya található.

A gyártó megerősítette a sérülékenységek létezését és dolgozik azok javításán, az átmeneti időszakra az alábbi intézkedéseket javasolja:

- Minden esetben bizonyosodjanak meg róla, hogy a PDQ berendezéseket nem lehet elérni az Internet irányából, azokat biztonságos tűzfalak mögött kell üzemeltetni;
- Minden eszközön a telepítésnél le kell cserélni az alapértelmezett gyári jelszavakat egy egyedi jelszóra;
- Minden hálózatot (vezetékes vagy Wi-Fi) a beépített biztonsági funkciók bekapcsolása mellett javasolt használni;
- A routerek port forwarding funkciójának használatát kerülni kell. A port forward alkalmazása növelheti a rendszer kitettségét az Internet irányából és hozzáférést biztosíthat olyan személyeknek, akiknek nincs jogosultságuk a rendszer használatára;
- Ne osszanak meg vagy írjanak le jelszavakat könnyen elérhető helyekre!

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

Mirion Technologies termékek sérülékenységei

Az ICS-CERT bejelentése szerint Ruben Santamarta, az IOActive munkatársa két sérülékenységet fedezett fel a Mirion Technologies alábbi termékeiben:

DMC 3000 Transmitter Modul;
iPam Transmitter f/DMC 2000;
RDS-31 iTX és különböző változatai (az RSD31-AM csomag is);
DRM-1/2 és különböző változatai (a Solar PWR csomag is);
DRM és RDS-alapú Boundary Monitor eszközök;
Külső transmitterek;
Telepole II és
MESH jelismétlők.

A sérülékenységek között nem megfelelő erősségű titkosítás és a rendszerben beégetett titkosítási kulcsok használata található.

A fenti hibákról bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-208-02

Continental AG Infineon S-Gold 2 sérülékenységek

Mickey Shkatov, Jesse Michael és Oleksandr Bazhaniuk, a McAfee Advanced Threat Research Team-jének munkatársai számos sérülékenységet találtak a Continental AG Infineon S-Gold 2 (PMB 8876) típusú kommunikációs chipsetjében, amit számos autógyártó (pl. BMW, Nissan, Infiniti, Ford, stb.) használ különböző modelljeiben. Az ICS-CERT bejelentése szerint az alábbi modellek lehetnek érintettek:

- A BMW 2009-2010 között gyártott számos modellje;
- Ford - néhány régebbi modell érintett, ezekhez 2016 óta fut egy, a 2G modem frissítését célzó kampány;
- Infiniti 2013 JX35;
- Infiniti 2014-2016 QX60;
- Infiniti 2014-2016 QX60 hibrid;
- Infiniti 2014-2015 QX50;
- Infiniti 2014-2015 QX50 hibrid;
- Infiniti 2013 M37/M56;
- Infiniti 2014-2016 Q70;
- Infiniti 2014-2016 Q70L;
- Infiniti 2015-2016 Q70 hibrid;
- Infiniti 2013 QX56;
- Infiniti 2014-2016 QX 80;
- Nissan 2011-2015 Leaf.

A hibák között puffer-túlcsordulás és nem megfelelő memóriakezelés is található. A Continental AG megerősítette a sérülékenységek létezését, de sem a javításukra, sem a kockázatok csökkentésére vonatkozóan nem adott információt. Az érintett autógyártók egyénileg kezelik az érintett modellek esetén a kockázatok csökkentését.

A sérülékenységekkel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-208-01

Sérülékenységek a Siemens Healthineers molekuláris képalkotó rendszerében

A Siemens ProductCERT bejelentése szerint 4 kritikus súlyosságú hibát találtak a Siemens Healthineers molekuláris képalkotó rendszerében. A sérülékenységek a Windows 7 és a HP Client Automation komponensekkel kerültek a rendszerbe és az alábbi verziókat érintik:

- Siemens PET/CT rendszerek: Minden Windows 7-alapú verzió;
- Siemens SPECT/CT rendszerek: Minden Windows 7-alapú verzió;
- Siemens SPECT rendszerek: Minden Windows 7-alapú verzió;
- Siemens SPECT munkaállomások/Symbia.net: Minden Windows 7-alapú verzió.

A gyártó jelenleg is dolgozik a sérülékenységek javításán.

A fenti hibákról további információkat a Siemens ProductCERT publikációjából lehet megtudni: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-822184.pdf

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á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 labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A múlt heti posztban végre eljutottunk az ICS Cyber Security Kill Chain bemutatásához, átnéztük a támadások első szintjét, ma pedig pedig a második szint ismertetésére térünk rá.

Az ICS CSKC esetén az első fázis csak arra szolgál, hogy a támadóknak lehetőségük legyen elindítani a második szint első fázisát, ami ismét a felderítésről szól, de ezúttal már az ipari rendszerek felderítése a cél. Ebben a fázisban a legtöbb kifejezetten ICS rendszereket célzó támadók a már kompromittált vállalati hálózatból kilopott adatok alapján próbálják beazonosítani az ipari rendszereket és azok gyenge pontjait. Ez az elemzés akár igen hosszú időt is igénybe vehet, éppen ezért az ICS CSKC első és a második szintje között akár hosszabb idő is eltelhet, mire a támadók úgy gondolják, hogy sikeresen azonosították a kihasználható gyenge pontokat.

Amikor a támadók úgy gondolják, hogy már rendelkeznek az ICS rendszer támadásához szükséges tudással, következik az ellenőrzési fázis, amikor tesztelniük kell, hogy helyesek voltak-e az elemzések nyomán kialakított feltételezéseik. Ehhez jellemzően olyan tesztkörnyezetet kell használniuk, ami azonos vagy legalábbis hasonlít a célba vett ICS rendszerre. Még a legegyszerűbb ICS rendszerek elleni támadás (pl. egy szolgáltatás-megtagadással járó scannelés) esetén is előzetes tesztekre van szükség, hogy a támadók biztosak lehessenek abban, hogy az adott művelet a várt eredményt fogja hozni. Az ennél jelentősebb hatást kiváltani akaró támadások esetén sokkal komolyabb tesztelésekre is szükség lehet, akár arra is, hogy a tesztekhez fizikai ICS berendezéseket és a szükséges szoftvereket is beszerezzék és felhasználják. Az egyes ipari szektorok szereplőinek ugyan nem nagyon van lehetőségük figyelemmel kísérni az ICS gyártók eladásait (még kevésbé a használt ipari eszközök és szoftverek újraértékesítését), az egyes kormányokra ez az állítás nem teljesen igaz.

Az ICS CSKC utolsó fázisa az ICS rendszer vagy rendszerek elleni támadás. Ebben a fázisban a támadók a korábban kifejlesztett képességeiket felhasználva már kifejezetten azzal a céllal indítanak támadást az ICS rendszer ellen, hogy fizikai folyamatokat tudjanak az irányításuk alá vonni. Ennek a támadásnak a komplexitása igen nagy mértékben attól függ, hogy a célba vett ICS rendszer biztonsága milyen szintet ér el, milyen a fizikai folyamat vezérlése és ellenőrzése, milyen a rendszerbe épített biztonsági (safety) kontrollok kialakítása és mi a támadók által elérni kívánt hatás. Egy ICS rendszer ellen végrehajtott szolgáltatás-megtagadásos támadást természetesen sokkal könnyebb végrehajtani, mint egy, a Stuxnet-hez vagy az ukrán villamosenergia-szektor elleni támadásokhoz hasonló műveltet. Ahhoz, hogy a támadók komoly károkat tudjanak okozni (mint például a 2014-ben történt német acélkohóban bekövetkezett incidensnél), a támadóknak teljes mértékben kontrollálniuk kell az ICS rendszerek által felügyelt folyamatokat. Bár az ICS környezetek támadásának számos módja van, mégis három nagy csoportba lehet osztani az ilyen támadásokat:

1. Szolgáltatás-megtagadás:
- a felügyeleti funkciók használhatatlanná tétele (Denial of View)
- a kontroll funkciók használhatatlanná tétele (Denial of Control)
- a biztonsági funkciók használhatatlanná tétel (Denial of Safety)
2. Funkciók elvesztése:
- a felügyeleti funkciók elvesztése (Loss of View)
- a kontroll funkciók elvesztése (Loss of Control)
3. Funkciók módosítása:
- a felügyeleti funkciók módosítása (Manipulation of View)
- a kontroll funkciók módosítása (Manipulation of Control)
- szenzorok és egyéb berendezések módosítása (Manipulation of Sensors and Instruments)
- a biztonsági funkciók manipulálása (Manipulation of Safety)

Ez az a pont, ahol nagyon jelentős különbség lehet egy IT és egy ICS rendszer elleni támadás hatásaiban, mert míg egy IT rendszer elleni támadás nagyon rosszul érintheti egy szervezet életét (akár az adott szervezet létezését is veszélyeztetheti), az ICS rendszerek és rajtuk keresztül a fizikai folyamatok támadása nagyon gyakran emberek sérülésével, súlyosabb esetben halálával járhat. Ennek ellenére az ICS közösség mind a mai napig nem érti teljes mélységében, hogy a kibertámadások milyen nagyon súlyos hatással lehetnek az ipari rendszerekre és folyamatokra. Emiatt elengedhetetlen, hogy az IT és OT biztonsággal foglalkozó szakemberek az eddigieknél sokkal hatékonyabban működjenek együtt egymással és a szabály- és törvényalkotókkal annak érdekében, hogy minél teljesebb képpel rendelkezhessünk az ICS rendszerek elleni támadások következményeit illetve az ICS rendszerek elleni támadások elkövetőinek céljait illetően. Ahogy az ipari rendszereket alkotó berendezések esetén sem az a kérdés, hogy tönkremennek-e és cserélni kell-e őket, hanem csak az a kérdés, hogy ez mikor következik be, ugyanez igaz az ICS rendszerek kibertbiztonságára is. Mindkét esetben a megfelelő tudással és tapasztalattal rendelkező mérnököknek fel kell készülniük az ilyen esetek bekövetkezésére és rendelkezniük kell nem csak a szükséges tudással, eszközökkel és személyzettel, hanem a megfelelő eljárásokkal is.