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.

Java-sérülékenységek a Schneider Electric Trio TView szoftverében

A Schneider Electric bejelentése szerint a Trio TView szoftver TBUMPROG - TVIEW 3.27.0 és korábbi verzióiban használt Java Runtime Enviroment 1.6.0u27 számos ismert sérülékenysége miatt az érintett TView verziók is érintettek. A gyártó bejelentésében több, mint 360 különböző, 2011 és 2017 között kiadott CVE van felsorolva. A sérülékenységeket a Schneider Electric a weboldalán elérhető Trio TView Software 3.29.0 verzióban javította.

A sérülékenységekkel kapcsolatban további részleteket a Schneider Electric bejelentése tartalmaz.

Sérülékenységek Schneider Electric PowerSCADA termékekben

Az ICS-CERT publikációja szerint a gyártó több hibát is talált a PowerSCADA termékcsalád alábbi tagjaiban:

- A PowerSCADA Expert v8.1 és v8.2 verzióival forgalmazott PowerSCADA Anywhere 1.0-s verziója;
- A PowerSCADA Citect Anywhere 1.0-s verziója.

A Schneider Electric a most publikált hibákat az érintett szoftverek 1.1-es verziójában javította. A sérülékenységekről bővebb informáiót az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-201-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.

A Cyber Security Kill Chain két posztban történt bemutatása után ma végre rátérünk az ipari rendszerek elleni kibertámadások sajátosságaira, amihez Michael J. Assante és Robert M. Lee, a SANS ICS biztonsági oktatóinak publikációját használtam fel.

Az ICS rendszerek elleni kibertámadások több szempontból is jelentős eltéréseket mutathatnak a vállalati IT rendszerek elleni támadásoktól, legyenek azok akár jelentős szakmai felkészültséget igénylő APT-támadások. Az ICS rendszerek elleni támadások esetében a támadások hatásai és összetettségük, valamint a támadók által az ipari környezetek és automatizált folyamatok ismerete mind jelentős különbséget mutat. Az ICS rendszerek elleni kibertámadások sikere nagyon nagy mértékben azon múlik, hogy a támadó mennyire jól ismeri és érti az egyes automatizált folyamatokat, az azok hátterében álló mérnöki döntéseket és a különböző biztonsági (safety) rendszerek működési elvét. Ahhoz, hogy egy támadó ennek a tudásnak a birtokába kerülhessen, két szintű támadást kell sikeresen végrehajtania a célba vett ICS rendszer ellen. Ez a több szintű támadás lehetőséget ad a védelem olyan kialakítására, hogy a támadóknak minél több erőforrást kelljen a támadásra fordítani, a célba vett szervezet biztonsági munkatársainak pedig javítja az esélyeit a támadás minél korábbi fázisban történténő észlelésére.

A két szintű támadás első szintje a támadó oldalán a tervezés, felkészülés és a támadás végrehajtása. A tervezés fázisban a CSKC felderítési feladatait hajtja végre a támadó, ahogy korábban írtam róla, bár nehéz a támadók felderítési és adatgyűjtési tevékenységét észlelni, azért korántsem lehetetlen, például különböző forgalom- és webes látogatottsági adatok elemzéséből beazonosítani azokat a támadói attribútumokat, amik adott esetben a felderítésben vesznek részt.

A támadás előkészítületi fázisában a "fegyverkezés", vagyis a támadó kódok előkészítése (weaponization) és a pontos célpontok meghatározása és kiválasztása (targeting) történik. Ehhez a támadók felhasználhatnak scripteket és különböző eszközöket, de végezhetik emberi erőforrásokkal is. Amennyiben a támadók több célpontot akarnak egyszerre támadni, ebben a fázisban dönthetik el, hogy melyik célpontot tartják fontosabbnak, mint a többit, vagy prioritást adhatnak a fontosabbnak tartott célpontnak.

Ebben a fázisban az ICS rendszereket védők szintén a CSKC bemutatásánál már ismertetett, széleskörű malware-analízist végezve készülhetnek fel a leginkább. Nagyon nagy előnye lehet a védőknek, hogy az ICS rendszerek nagyságrendekkel statikusabbak, mint a vállalati IT rendszerek, így egy, az ICS rendszerbe bejutó malware-t elvileg sokkal könnyebben észlelni lehet, hiszen a statikusság miatt sokkal könnyen alkalmazás fehérlistákat összeállítani és alkalmazni.

A következő fázis a betörés kísérlet. Ennek folyamán a támadóknak valamilyen módon be kell juttatniuk a támadáshoz használt malware-t vagy malware-eket a célba vett szervezet rendszerébe. Ehhez leggyakrabban adathalász e-maileket és/vagy e-mailekhez csatolt PDF fájlokat, vagy egyéb dokumentumokat, számolótáblákat szoktak használni az átlagos, vállalati hálózatok elleni kibertámadások esetén csakúgy, mint az ICS rendszerek elleni támadásoknál (erre a legszemléletesebb példa az ukrán áramszolgáltatók elleni, 2015. decemberi támadás volt, ahol XLS fájlokba bújtatott BlackEnergy v3 malware-t használtak a támadók a kezdeti hozzáférések megszerzéséhez.

A sikeres betörés után a támadók ebben az esetben is a hozzáféréseik biztosítását végzik el, felépítik a kommunikációs csatornáikat a különböző Command&Control (C2) szerverekhez és hozzákezdhetnek a támadás eredeti célját jelentő tevékenységekhez Itt ér véget az ICS Cyber Security Kill Chain első fázisa. A CSKC esetén megkezdődne az adatok ellopása, a bankszámlák kiürítése vagy a számos egyéb cél eléréséhez közvetlenül szükséges tevékenység.

Az ICS CSKC első szintje itt ér véget és itt fejezem be a mai posztot is, a jövő héten a második szinttel és az ICS rendszerek elleni támadás fázisaival fogom folytatni.

Microsoft szerver szolgáltatás és WebDAV sérülékenységek Siemens Healthineers rendszerekben

A Siemens ProductCERT bejelentése szerint két hibát találtak a Siemens Healthineers alábbi molekuláris képfeldolgozó termékeiben:

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

Az első hiba a Microsoft Windows szerver szolgáltatásoknak küldött távoli eljárás-hívásokban (RPC) távoli kódfuttatásra ad lehetőséget egy támadónak, a másik hiba pedig WebDAV szolgáltatás hibájára építve szintén távoli kódfuttatást tesz lehetővé. Mindkét hibát authentikáció nélkül is ki lehet használni.

A Siemens jelenleg is dolgozik a hibák javítását tartalmazó frissítéseken.

A sérülékenységekről további részleteket a Siemens ProductCERT bejelentésében lehet olvasni: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-814457.pdf

Rockwell Automation MicroLogix kontrollerek sérülékenysége

Az ICS-CERT publikációja szerint Mark Gondree, a Sonoma State University valamint Francisco Tacliad és Thuy Nguyen, az amerikai haditengerészet posztgraduális iskolájának munkatársai egy, a bevitt adatok nem megfelelő ellenőrzéséből adódó sérülékenységet azonosítottak a Rockwell Automation MicroLogix 1100-as kontroller-családjának alábbi tagjaiban:

- 1763-L16BWA;
- 1763-L16AWA;
- 1763-L16BBB;
- 1763-L16DWD.

A gyártó a hibát a MicroLogix 1100-as kontrollerek FRN 16.0 illetve későbbi verzióiban már javította.

A sérülékenységről bővebb információkat az ICS-CERT és a Rockwell Automation publikációiban 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.

Siemens SIMATIC Sm@rtClient Android App sérülékenységek

A Siemens ProductCERT és ICS-CERT bejelentései szerint Karsten Sohr és Timo Glander, a brémai egyetemen működő TZI munkatársai két sérülékenységet találtak a Siemens SIMATIC Sm@rtClient Android-os alkalmazásaiban, egészen pontosan a SIMATIC WinCC Sm@rtClient for Android V1.0.2.2-nél korábbi verzióiban és a SIMATIC WinCC Sm@rtClient Lite for Android V1.0.2.2-nél korábbi verzióiban. Az első sérülékenység egy közbeékelődéses (Man-in-the-middle) támadást, a másik pedig authentikáció-megkerülést tesz lehetővé.

A Siemens a fenti sérülékenységeket az App V1.0.2.2-es verziójában javította, amit a felhasználók a Google Play Store-ból tölthetnek le.

Bővebb információt ezekről a sérülékenységekről az alábbi helyeken lehet találni:
https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-589378.pdf
https://ics-cert.us-cert.gov/advisories/ICSA-17-194-03

Siemens SiPass Integrated sérülékenységek

A Siemens 4 különböző hibát talált a SiPass Integrated V2.70-nél korábbi verzióiban. A hibák között nem megfelelő authentikáció, nem megfelelő jogosultság-kezelés, rendszeren kívüli eszközök számára hozzáférhető kommunikációs csatorna és visszafejthető formában tárolt jelszavak vannak.

A gyártó a hibákat a SiPass V2.70-es verziójában javította.

A sérülékenységekről további részleteket a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

GE Communicator sérülékenység

Az ICS-CERT bejelentése szerint Kimiya, az iDefense Labs (ami az Accenture Security egyik vállalata) egy puffer-túlcsordulási hibát talált a GE okosmérőinek programozásához és ellenőrzéséhez használt Communicator eszközeinek 3.15-ös és korábbi verzióiban.

A GE a hibát a 4.0-ás verzióban javította.

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-194-02

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 Cisco Talos kutatócsoportja nemrég egy olyan támadás-sorozatról számolt be ahol a célpontok az amerikai kritikus infrastruktúrához tartozó szervezetek voltak, a támadási módszert pedig template-injection-ként ismeri a szakma. A hírek szerint több gyárat, nukleáris erőművet és más villamosenergia-ipari céget is érintettek a támadások az USA-n belül és azon kívül is, többek között a Wolf Creek atomerőművet Kansas államban.

A Wolf Creek-i atomerőmű és az amerikai Energiaügyi minisztérium (Department of Energy, DoE) szerint a támadók "csak" a vállalati IT rendszerekig jutottak, az ipari rendszerekhez nem szereztek hozzáférést. Az FBI és a Belbiztonsági minisztérium közös jelentése szerint a támadók legalább május óta aktívan keresték a hozzáférési lehetőségeket az érintett szervezetek rendszereihez és a vizsgálat első eredményei alapján olyan technikákat használtak, amik a Crouching Yeti, az Energetic Bear és a Dragonfly néven ismertté vált csoportokhoz köthetik őket.

Az FBI/DHS jelentés szerint a támadók kártékony kóddal preparált Office dokumentumokat küldtek e-mail csatolmányként vezető beosztású mérnököknek a célba vett szervezeteknél, ezekkel akartak felhasználói azonosítókat és jelszavakat gyűjteni, amik hozzáférést biztosítanak az adott szervezet informatikai hálózatához. A jelentés szerint a támadók egyebek mellett watering-hole és közbeékelődéses módszereket is használtak.

A Talos munkatársainak elemzése szerint a támadásokhoz használt Word dokumentumok jellemzően önéletrajzoknak illetve környezettanulmányoknak látszanak és a megszokott módszerekkel ellentétben nem VBA makrókat vagy más scripteket használnak a malware célbajuttatására. Ezek helyett, ha a csali dokumentumot megnyitják, a Word megnyitása közben letölt egy template fájlt egy, a támadók által irányított Samba szerverről. Az így végrehajtott template injection támadással lehetővé válik a támadók számára, hogy Samba felhasználói adatokat gyűjtsenek.

A malware-t vizsgáló szakértők szerint a támadók célja az adatgyűjtés lehet és a hozzáférések gyűjtése jövőbeli, kritikus infrastruktúrákat vezérlő folyamatirányító rendszerek elleni támadás előkészítéseként.

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

Az ICS-CERT publikációja szerint Ariele Caltabiano a ZDI-vel együttműködve talált memória-korrupciós sérülékenységet a Fuji Electric V-Server 3.3.22.0 és ennél korábbi verzióiban. A hibát kihasználva egy támadó távoli kódfuttatási lehetőséghez juthat.

A Fuji Electric elkészítette és publikálta a hibát javító patch-et, ami a weboldaláról tölthető le.

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

Sérülékenységek ABB rendszerekben

Az ICS-CERT szintén tegnap (magyar idő szerint hajnalban) tette közzé azokat a sérülékenységeket, amiket Maxim Rupp fedezett fel az alábbi rendszerekben:

- VSN300 WiFi Logger Card 1.8.15 és korábbi verziói;
- VSN300 WiFi Logger Card for React 2.1.3 és korábbi verziói.

A hibák között van, ami a nem megfelelő authentikációs eljárásból ered és egy másik, ami pedig a hozzáférés és jogosultság-kezelés hibájából lehetőséget ad arra, hogy a "Guest" felhasználóval a rendszer konfigurációs fájljaihoz történő hozzáférésre.

A gyártó a hibákat a VSN300 WiFi Logger Card 1.9.0 és újabb, illetve a VSN300 WiFi Logger Card for React 2.2.5 és újabb verzióiban javította.

A sérülékenységekről bővebb információkat az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-192-03

XSRF sérülékenység az OSIsoft PI Coresight termékében

A tegnap napon az ICS-CERT két OSIsoft termékkel kapcsolatos bejelentést is közzétett, az első a PI Coresight-ban a gyártó által talált XSRF sérülékenységről szól. A hiba a PI Coresight 2016 R2 és korábbi verzióit érinti. A gyártó minden érintett terméket használó ügyfelének azt javasolja, hogy frissítsenek a PI Vision 2017 vagy újabb verziókra, amikben ez a hiba már javításra került. A sérülékenység részletei elérhetőek az ICS-CERT publikációjában: https://ics-cert.us-cert.gov/advisories/ICSA-17-192-04

Sérülékenység az OSIsoft PI ProcessBook és PI ActiveView termékekben

Szintén a gyártó jelentette az ICS-CERT-nek, hogy a PI ProcessBook 2015 R2 (3.6.0) és korábbi verziói, illetve a PI ActiveView 2015 R2 (3.6.0) és korábbi verziói olyan, harmadik féltől származó komponenseket is tartalmaznak, amikben sérülékenység található.

A gyártó az érintett termékeket használó ügyfeleinek a PI ProcessBook 2015 R2 SP1 (3.6.1)-re illetve a PI ActiveView 2015 R2 SP1 (3.6.1)-re történő frissítést javasolja.

A hibával kapcsolatos további információk az ICS-CERT bejelentésében érhetők el: https://ics-cert.us-cert.gov/advisories/ICSA-17-192-05

Sérülékenység Schweitzer Engineering rendszerekben

Az ICS-CERT bejelentése szerint Jason Holcomb, a Revolutionary Security munkatársa egy nem megfelelő hozzáférés-kontrollból származó hibát fedezett fel a Schweitzer Engineering Laboratories SEL-3620 és SEL-3622-es sorozatú, Security Gateway R202, R203, R203-V1, R203-V2, R204 és R204-V1 típusú ipari tűzfalaiban. A hiba csak akkor jelentkezik, amikor a tűzfalakon a NAT funkció be van kapcsolva. A hiba javítását a gyártó az ügyfelek kérésére CD-ROM-on adja át.

A sérülékenységgel kapcsolatos további információkat az ICS-CERT bejelntésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-17-192-06

WannaCry ransomware-rel és Petya (NotPetya/Petwrap/ExPetr/GoldenEye/stb.) kapcsolatos hírek az ipari rendszerek világából

Az elmúlt napokban számos gyártó publikált információkat az ipari termékeikkel kapcsolatos májusi WannaCry ransomware és a június végi Petya wiper malware-ek által kihasznált sérülékenységekről és az azokkal kapcsolatos ellenintézkedésekről. Helyszűke miatt itt most csak felsorolom őket a publikációikra mutató linkekkel együtt:

- Becton, Dickinson and Company (BD)
- Emerson Automation Solutions
- Rockwell Automation
- Honeywell
- Dräger
- ABB
- Johnson & Johnson
- Schneider Electric
- Beckman Coulter
- Philips
- Smiths Medical

A fenti bejelentésekkel kapcsolatban az ICS-CERT is kiadott egy összefoglalót, ami itt érhető el: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-181-01C

Az pedig a saját, megbízható forrásaimból származó hír, hogy a Siemens egyik SCADA-fejlesztő telephelyén az elmúlt napokban több WannaCry-fertőzés is történt. A részletek egyelőre homályosak, de az világosan látszik, hogy ez a ransomware közel másfél hónappal a WannaCry megjelenése után is jelentős kockázatokat rejthet.

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.