Sérülékenységek Schneider Electric Ampla MES rendszerekben

Az ICS-CERT múlt heti bejelentése szerint Ilya Karpov, a Positive Technologies munkatársa két hibát is talált a Schneider Electric Ampla MES (Manufacturing Execution System - termelésirányítási rendszer) 6.4-es és korábbi verzióiban. A sérülékenységek között az érzékeny adatok titkosítás nélküli továbbítása és a nem megfelelő erősségű titkosítás található.

A gyártó a hibákat az Ampla MES 6.5-ös verziójában javította.

A sérülékenységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-187-05

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

Szintén az ICS-CERT hozta nyilvánosságra, hogy Andrey Zhukov, a USSC kutatója három hibát (puffer-túlcsordulás, nem megfelelően kontrollált memóriakezelés, null-pointer hivatkozás), amik a Schneider Electric Wonderware ArchestrA Logger 2017.426.2307.1 és korábbi verzióiban találhatóak meg.

Az érintett naplózómegoldást a Schneider Electric Wonderware, Avantis, SimSci és Skelta szoftvereiben használja, a gyártó minden érintett termékét használó ügyfelének azt javasolja, hogy az ArchestrA Logger-t frissítsék a 2017.517.2328.1-es verzióra a lehető leghamarabb.

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

Siemens SIMATIC Logon sérülékenység

A Siemens ProductCERT bejelentése szerint a Tenable Network Security munkatársai egy DoS-támadást lehetővég tevő hibát találtak a SIMATIC Logon 1.6-osnál régebbi verzióiban.

A Siemens minden, érintett verziót használó ügyfelének azt tanácsolja, hogy frissítsék a SIMATIC Logon-t az 1.6-os verzióra.

A sérülékenységgel kapcsolatban részletesebb információkat a Siemens ProductCERT publikációjában lehet olvasni: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-804859.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.

Az amerikai igazságügyi minisztérium (Department of Justice, DoJ) közleménye nyomán több helyen is lehozták a hírt, hogy egy Adam Flanagan nevű pennsylvaniai férfit egy év egy nap börtönbüntetésre ítéltek, mert a bíróság szerint bizonyíthatóan károkat okozott több keleti parti viziközmű szolgáltató rendszerében. Flanagan 2007 és 2013 között egy okosmérőkat gyártó cégnél dolgozott, többek között a főként viziközmű vállalatok által alkalmazott Tower Gateway Basestations (TGB) nevű eszközök telepítéséért volt felelős, majd amikor 2013 novemberében egyelőre ismeretlen okok miatt elbocsátották a munkahelyéről, úgy döntött, hogy azzal fogja büntetni a vállalatot, hogy leállít több TGB-t, ezzel megbénítva a viziközmű vállalatok hálózatait és több TGB-n megváltoztatta a jelszavakat is, trágár kifejezéseket használva új jelszónak. Az érintett közműcégeknek vissza kellett állniuk a régi megoldásra és mérőóra-leolvasókat kell kiküldeniük az ügyfelekhez.

Legjobb tudomásom szerint ez az első olyan eset, amikor egy elkövetőre rábizonyítják egy ipari rendszer elleni támadás végrehajtását és letöltendő börtönbüntetésre ítélik.

Siemens Reyrolle eszközök sérülékenységei

A Siemens Reyrolle eszközök opcionális EN100 Ethernet moduljainak V4.29.01-est megelőző firmware-verzióiban 5 hibát talált a gyártó a Siemens ProductCERT publikációja szerint. A sérülékenységek között több webes felületen keresztüli adatszivárgást lehetővé tevő hiba, authentikáció megkerülésével adminisztrátori hozzáférést lehetővé tevő hiba, és DoS-t előidéző hiba is van.

A Siemens a fenti hibákat a V4.29.01-es firmware-verzióban javította.

A sérülékenységekről bővebb információkat a Siemens ProductCERT bejelentése tartalmaz: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-452237.pdf

Sérülékenységek SIPROTEC és SIPROTEC Compact berendezésekben

A Siemens ProductCERT bejelentése szerint 6 különböző hibát fedeztek fel a SIPROTEC 4 és SIPROTEC Compact eszközök alábbi verzióiban:

- a SIPROTEC 4 és SIPROTEC Compact opcionális EN100 Ethernet moduljainak:
- a PROFINET IO firmware-változatának V1.04.01-nél korábbi verziói;
- a Modbus/TCP firmware-változatának minden verziója;
- a DNP3/TCP firmware-változatának minden verziója;
- az IEC-104 firmware-változatának minden verziója;
- a SIPROTEC Merging Unit 6MU80-as V1.02.02-nél korábbi verziói;
- a SIPROTEC 7SJ66-os, 7SD686-os, 7SJ686, 7UT686 minden verziója.

A sérülékenységek között több webes felületen keresztüli adatszivárgást lehetővé tevő hiba, authentikáció megkerülésével adminisztrátori hozzáférést lehetővé tevő hiba, és DoS-t előidéző hiba is van.

A hibák javítását a Siemens az alábbi firmware-ekben végezte el:

- a SIPROTEC 4 és SIPROTEC Compact opcionális EN100 Ethernet moduljainál:
- a PROFINET IO firmware-változat V1.04.01;
- a Modbus/TCP firmware-változat V1.10.01;
- a SIPROTEC Merging Unit 6MU80 esetében a V1.02.02-es firmware-verzióban;
- a SIPROTEC 7SJ66 V4.23-as firmware-verziójában;
- a SIPROTEC 7SJ686 V4.86-os firmware-verziójában;
- a SIPROTEC 7UT686 V4.01-es firmware-verziójában;
- a SIPROTEC 7SD686 V4.04-es firmware-verziójában.

A hibákról további részleteket a Siemens ProductCERT publikációjában lehet olvasni: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-323211.pdf

Sérülékenységek Siemens OZW eszközökben

A Siemens ProductCERT bejelentése szerint Stefan Viehböck, a SEC Consult munkatársa két sérülékenységet azonosított az OZW672-es és OZW772-es eszközök összes firmware-verziójában. Az első hibát kihasználva egy támadó az FTP-szolgáltatáson keresztül hozzáférhet és módosíthatja a történeti adatbázisban tárolt adatokat. A második hiba Man-in-the-Middle támadásra ad lehetőséget.

A Siemens ProductCERT bejelentésében nem esik szó a fenti hibák javításáról, de a gyártó több tanácsot is megfogalmazott az érintett eszközöket használó ügyfeleinek:

- Védjék a sérülékeny eszközöket az illetéktelen hozzáférésektől;
- Tiltsák le az integrált szolgáltatásokat a 21/tcp porton;
- A web portált a termékek dokumentációjában leírt beállításokkal használják;
- Ha a web portál használata nem lehetséges, az integrált web szervert csak megbízható hálózaton használják.

A fenti hibákkal kapcsolatban további információkat a Siemens ProductCERT bejelentésében lehet találni:
https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-563539.pdf

Advantech WebOP Designer 0-day sérülékenység

A ZDI egy Ariele Caltabiano által felfedezett és mostanáig nem javított sérülékenységet tett közzé. A sérülékenység a WebOP Designer .pm3 fájljainak hibás feldolgozásából eredően egy puffer-túlcsorduláson keresztül távoli kódfuttatást tesz lehetővé.

A hibával kapcsolatban részleteket a ZDI bejelentésében lehet olvasni: http://www.zerodayinitiative.com/advisories/ZDI-17-452/

Sérülékenység Newport XPS rendszerekben

Az ICS-CERT bejelentése szerint a Newport által gyártott XPS eszközök alábbi vezióiban egy nem megfelelő authentikációból adódó sérülékenységet talált Maxim Rupp:

- az XPS-Cx vezérlők minden verziója;
- az XPS-Qx vezérlők minden verziója.

A sérülékenységet kihasználva egy támadó authentikció nélkül tudja olvasni és módosítani az érintett eszközök konfigurációját.

A gyártó közleménye szerint a hibát a vezérlők következő, XPS-Dx generációjában fogja javítani, addig is az ICS-CERT-tel közösen az alábbi kockázatcsökkentő intézkedéseket javasolja az érintett verziókat használó ügyfeleinek:

- A vezérlőket és azok hálózatait ne csatlakoztassák nyílt hálózatokra (pl. Internet vagy irodai hálózatok), ezeket az eszközöket és hálózatokat tűzfalakkal szeparálják más hálózatoktól;
- Limitálják a vezérlők fizikai és elektronikus hozzáféréseit a szükséges és arra feljogosított személyekre;
- Az üzembe helyezésnél cseréljék le az eszközök gyári jelszavait;
- Rendszeresen cseréljék le a rendszerekben használt jelszavakat;
(Bár az utóbbi két tanács általában sokat segít egy incidens megelőzésében, jelen sérülékenység ellen pont nem jelentenek védelmet, hiszen ebben az esetben a támadónak nem szükséges ismernie a jelszót a rendszerhez történő hozzáféréshez.)
- Ha szükséges a távoli hozzáférés az eszközökhöz, használjanak VPN-megoldást;
- Rendszeresen hajtsanak végre fenyegetettség-elemzések és vizsgálják, hogy az ellenintézkedések megfelelnek-e a szervezet biztonsági szabályzataiban előírtaknak;
- Alakítsanak ki mélységi védelmet a rendszerekhez történő hozzáférések szigorításához.

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

Siemens Viewport sérülékenység

Az ICS-CERT és a Siemens ProductCERT bejelentései alapján a Viewport for Web Office Portal 1453-nál korábbi verzióiban egy nem megfelelő authentikációból fakadó sérülékenységet fedezett fel Hannes Trunde, a Kapsch BusinessCom AG munkatársa. A sérülékenységet kihasználva egy támadó adminisztrátori jogosultságú távoli kódfuttatást idézhet elő a sérülékeny rendszerekben.

A Siemens a hibát a Viewport for Web Office Portal 1453-as verziójában javította, a frissítés mellett az alábbi intézkedések végrehajtását javasolja az érintett rendszereket használó ügyfeleinek:

- Az érintett rendszerek 80/tcp és 443/tcp portjainak elérését csak a feltétlenül szükséges helyekről engedélyezzék;
- A 80/tcp porton történő elérést kapcsolják ki és csak a 443/tcp porton, kliens tanúsítvánnyal történő hitelesítés után engedélyezzék a hozzáférést;
- Alkalmazzanak mélységi védelmet az érintett rendszerek esetén.

A hibával kapcsolatban további részleteket az ICS-CERT és a Siemens ProductCERT bejelentései tartalmaznak.

Intel AMT sérülékenység Siemens termékekben

A nemrég közzétett, Intel AMT (Active Management Technology) sérülékenység, amely számos Core i5, Core i7 és Xeon processzort használó számítógépet érint, az ICS-CERT és a Siemens ProductCERT közleményei szerint számos Siemens terméket is érintenek:

- SIMATIC ipari PC;
- SINUMERIK Panel Control Unit (PCU);
- SIMOTION P320.

A hiba javítását a Siemens egy új firmware-verzióban tette elérhetővé ügyfelei számára. A gyártó további javaslatai az érintett termékeket használó ügyfelei számára:

- A BIOS-ban az iAMT minden esetben legyen "unconfigured" vagy "disabled";
- Kongrollálják az érintett számítógépekhez történő távoli hozzáféréseknél a 16992/tcp, 16993/tcp, 16994/tcp, 16995/tcp, 623/tcp és 664/tcp portok elérését.

A sérülékenységgel kapcsolatban további részletek az ICS-CERT és a Siemens ProductCERT bejelentéseiben olvashatóak.

Sérülékenységek Schneider Electric U.motion Builder rendszerekben

Az ICS-CERT publikációja szerint az rgod néven ismert személy a TrendMicro ZDI-vel együttműködve hét különböző hibát fedezett fel a Schneider Electric U.motion Builder 1.2.1 és korábbi verzióiban. A hibák között SQLi, könyvtárbejárást lehetővé tevő hiba, nem megfelelő authentikció, beégetett jelszó, nem megfelelő hozzáférés-vezérlés, DoS és hibaüzeneten keresztüli érzékeny információ-megjelenítés is van.

A gyártó a hibák javítását az augusztus végére tervezett firmware-upgrade-ben ígéri.

A hibákról részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-180-02

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 elmúlt napokban nem voltam gépközelben, így csak az események mögött járva tudom összefoglalni az újabb, nagyszabású ransomware-kampány ICS rendszereket érintő eseményeit.

Június 27-én, Közép-európai idő szerint dél körül érkeztek az első hírek egy újabb kiterjedt ransomware-kampányról. A támadások ezúttal Ukrajnában és Oroszországban kezdődtek, majd igen gyorsan elterjedtek szerte Európában és a világon. A WannaCry támadásokhoz hasonlóan ezúttal is részben a Windows operációs rendszerek SMBv1 sérülékenységét kihasználó exploit köré épült a ransomware, ami az első hírek szerint ezúttal a Petya egyik új variánsát juttatta be a sérülékeny rendszerekbe.

A híradások szerint elsőként ismét ukrán szervezeteket tarolt le a támadás, ezúttal a az ukrán M.E.Doc nevű cég MEDoc nevű, ABEV-szerű alkalmazásának egyik frissítésébe csempészték be az ismeretlen támadók az első fertőzéseket okozó kódot.

Az ukrán szervezetek mellett ezúttal is számos egyéb áldozata lett a ransomware-féregnek, a dán szállítmányozási és energiaszektorban egyaránt jelentős szereplőnek számító Maersk mellett az orosz Rosneft rendszerei is áldozatul estek a zsaroló vírusnak, ráadásul a Rosneft saját közleménye szerint az olajcégnek át kellett állnia a tartalék folyamatirányító rendszerére, vagyis kijelenthetjük, hogy esetükben nagyon súlyos incidensről van szó. Egyes hírek szerint Ukrajnában az Ukrenergo és a Kyevenergo villamosenergia-ipari cégek is érintettek a támadásban és bár arról egyelőre nincs hír, hogy ezeknél a cégeknél az ipari rendszereket is elérte volna ransomware, az már megerősítést nyert, hogy az egyik ukrán villamosipari vállalat ügyviteli rendszereiben igen komoly fennakadásokat okozott a támadás.

Egyes források szerint viszont a Csernobil környékén használt sugárzásmérő rendszer érintett a támadásban, ez, ha megerősítést nyer, szintén nagyon komoly biztonsági (és nem csak ICS kiberbiztonsági, de akár safety) incidenst jelenthet.

A támadás azonosítását segíthetik az alábbi IoC-k (Indicator of Compromise adatok):

Ismertté vált Command&Control szerverek IP címei:

185.165.29.78
84.200.16.242
111.90.139.247

A támadásokhoz kapcsolható a wowsmith123456@posteo.net e-mail cím is. Miután ez nyilvánosságra került, a szolgáltató elérhetetlenné tette a postafiókot.

Az ESET témában megjelent cikke alapján a ransomware a megtámadott számítógépek Master Boot Record-ját próbálja titkosítani, ha ezt nem sikerül elérnie, akkor a számítógépen található összes fájlt titkosítja. Azzal kapcsolatban, hogy a ransomware hogyan jut be az egyes hálózatokba, több elmélet is kering kedden este, egyesek szerint fertőzött Microsoft Word dokumentumokat vagy fertőzött weboldalakra mutató hivatkozásokat tartalmazó e-mail-ek hordozzák a kezdeti fertőzést. A helyi hálózatra történő bejutást követően képes az EternalBlue néven elhíresült SMBv1 sérülékenységet kihasználva, illetve a Windows admin share-eket és a PsExec-et használja a hálózaton belüli további terjedésre - ezzel pedig akár az EternalBlue patch-csel ellátott Windows rendszereket is képes lehet megfertőzni.

A ransomware-rel párhuzamosan természetesen a hisztéria is ismét végigfertőzte a világot, az IT biztonsági portálok és blogok a mainstream sajtóval versenyezve, rendkívüli híradásként hozták le az újabb támadás részleteit. Pedig ha jól belegondolunk, csak azon lehet csodálkozni, hogy nagyjából egy hónapot kellett várni a komolyabb második támadási hullámra. Ahogy egy energiaszektorban dolgozó ismerősömmel erről beszéltünk, aki akarta és tudta, már patch-elte a rendszereit, így, ha nem is 100%-osan, de biztonságban érezhette magát, aki pedig nem tehette vagy nem akarta telepíteni az SMBv1 hibát javító patch-et, azt nagy valószínűséggel a mostani incidens sem fogja rávenni arra, hogy tegye meg. Ha olyan (jellemzően ipari vagy egészségügyi) rendszert üzemeltet az adott szervezet, ahol a gyártó jóváhagyása nélkül nem tanácsos semmilyen javítást telepíteni, akkor a funckióvesztés okozta kockázatot jó eséllyel nagyobbnak fogják érezni, mint egy esetleges ransomware-támadást, ha pedig valaki a WannaCry támadások után sem érezte fontosnak a hibajavítást, azt valószínűleg a mostani incidens sem fogja meggyőzni az ellenkezőjéről.

Mit tehetnek azok, akik mégis szeretnék úgy érezni, hogy tettek valamit annak érdekében, hogy nagyobb biztonságban tudják a rendszereiket a mostani és a következő hetekben-hónapokban valószínűleg még újra és újra felbukkanó EternalBlue-leszármazottaktól?

1. Telepítsék a Microsoft által kiadott, SMBv1 hibát javító frissítéseket. A Microsoft nem véletlenül adta ki ezeket a javításokat már évek óta nem támogatott verziókra (XP, 2003) is.
2. Az adott szervezet számára fontos rendszereket szeparálják azoktól a hálózati zónáktól, ahol a számítógépek és egyéb eszközök bármilyen Internet-eléréssel rendelkezhetnek. Ipari rendszerek esetén nagyon erősen javasolt a Purdue-modell ICS-specifikus változatának helyi sajátosságokhoz illeszkedő kialakítása.
3. A határvédelmi rendszerek mindig legyenek az elérhető legújabb verzióra frissítve.
4. Legyen minden fontos rendszerről és adatról több példányos, geodiverzifikált, lehetőleg offline mentés. Ne felejtsük el, hogy a mentés csak annyit ér, amennyire baj esetén helyre lehet belőle állítani a szükséges adatokat/rendszereket! A rendelkezésre álló mentéseket emiatt rendszeresen tesztelni is kell!
5. A szervezet készüljön fel az ehhez hasonló incidensek bekövetkezése esetén követendő eljárásrendek (katasztrófa-elhárítási terv - DRP, üzletmenet-folytonossági terv - BCP) végrehajtására. Nagyon jó, ha ezek a tervek léteznék és 1-2 évente frissítjük is őket, de ha az érintett munkatársak nem tudják, hogy egy éles helyzetben hol kell lenniük és mit kell tenniük vagy kivel kell együttműködniük és az illetőnek mi a telefonszáma, akkor bizony szükség esetén a terv nem sokat fog érni. Rendszeresen teszteljük a BCP és DRP terveket!

Az elmúlt napokban nagyon sok cikk jelent meg a témában, én most csak a Microsot elemzését linkelem: https://blogs.technet.microsoft.com/mmpc/2017/06/27/new-ransomware-old-techniques-petya-adds-worm-capabilities/

A Siemens ezúttal az alábbi XHQ verziókban fedezett fel egy, a nem megfelelő hozzáférés-vezérlésből származó sérülékenységet:

- XHQ 4 minden, a V4.7.1.3-nál régebbi verziója;
- XHQ 5 minden, a V5.0.0.2-nél régebbi verziója.

A Siemens a hibát az XHQ legújabb verzióiban javította. A sérülékenységről további részleteket az ICS-CERT és a Siemens ProductCERT publikációiban lehet olvasni.

Több, mint egy hónap telt el a WannaCry világméretű fertőzéshulláma óta és az elmúlt napokban ismét a zsarolóvírustól volt hangos a szakmai és a mainstream sajtó: a Honda egyik, Tokió melletti gyárát WannaCry fertőzés miatt kellett leállítani. Felmerül a kérdés, hogy 5 héttel a WannaCry megjelenése után hogyan fordulhat elő, hogy még mindig ilyen szintű károkat okozhat egy olyan kártevő, amit egy egyszerű Windows patch telepítésével meg lehetne előzni, de a különböző ipari rendszerek esetén, amilyen a többek között az autógyártásban használt termelésirányító rendszerek is, a frissítések telepítése több okból sem olyan egyszerű, mint a vállalati IT rendszerek esetén:

1. Bár a Microsoft, szakítva azzal az álláspontjával, hogy a Windows XP és Windows Server 2003 már évek óta nem támogatott operációs rendszerek, a WannaCry által kihasznált SMBv1 hibát javító patch-et kiadta ezekre az operációs rendszerekre is, ezek telepítése a különböző ICS rendszerekre korántsem biztos, hogy már megtörtént.

2. Vannak olyan ICS rendszerek (jellemzően, bár nem kizárólag épp a termelésirányítás területén), ahol még a Windows XP és Server 2003-nál is régebbi operációs rendszereket is használnak. Nem olyan régen én is láttam még ipari környezetben egy-egy kósza Windows 2000 Server-t, Windows 98-at de még MS-DOS 6.22-t is!

3. Ha elérhető is egy javítás az adott sérülékenységre, ICS rendszerek esetén az üzemeltetők (OT) az ICS gyártó hozzájárulása nélkül jellemzően nem telepítenek semmilyen hibajavítást, mert az nemcsak a gyártói garancia automatikus elvesztését jelentheti, hanem azt is kockáztatnák, hogy adott esetben egyes funkciók működése bizonytalanná válhat.

A fentiek ellenére az OT, az IT és az IT/ICS biztonsági szakterületek együttműködésének javításával sokat lehetne javítani az ehhez hasonló incidensek esetén a megelőzés, a malware-támadások mielőbbi felfedezése és az incidensek elhárításának hatékonyságán.

A tegnapi napon ismét két ICS rendszerekkel kapcsolatos sérülékenység látott napvilágot.

Ecava IntegraXor sérülékenység

A Tenable Network Security munkatársai egy SQL injection-t találtak az Ecava IntegraXor 5.2.1231.0 és korábbi verzióiban. A gyártó a sérülékenységgel kapcsolatban azt javasolja minden érintett ügyfelének, hogy frissítsenek az IntegraXor 6.0.522.1-es vagy újabb verziójára.

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

Siemens SIMATIC CP sérülékenység

A Siemens ProductCERT publikációja alapján egy authentikációs hibát azonosítottak a SIMATIC CP 44x-1 RNA V1.4.1-nél korábbi verzióiban, aminek kihasználásával egy támadó authentikáció nélkül adminisztrátori jogosultságokat szerezhet a sérülékeny rendszerekben. A Siemens a hibát a V1.4.1-es verzióban javította.

Bővebb információkat a hibáról a Siemens ProductCERT bejelentésében lehet találni: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-126840.pdf

A fenti sérülékenységek esetén is hasznosak lehetnek az ICS-CERT szokásos kockázatcsökkentő intézkedései:

- 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.

Karn Ganeshen (aki az utóbbi néhány hónapban megfigyeléseim szerint aktívabb, mint Maxim Rupp) ezúttal a Cambium Networks ePMP nevű, hálózati hozzáférés-vezérlő rendszerében talált két hibát. Furcsa módon mindkét hiba a hozzáférés-vezérlő rendszer hozzáférés illetve jogosultságkezelésével kapcsolatos. A hibák az ePMP minden verzióját érintik. A gyártó a sérülékenységeket a 3.4-RC7 és újabb verziókban javította.

A hibákról bővebb információkat az ICS-CERT publikációjából lehet szerezni: https://ics-cert.us-cert.gov/advisories/ICSA-17-166-01

A most napvilágot látott sérülékenységekkel kapcsolatban az ICS-CERT a szokásos kockázatcsökkentő intézkedések alkalmazá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.

Az elmúlt napokban ismét számos, nem egy esetben 0. napi ICS sérülékenység látott napvilágot.

OSISoft PI Server és WebAPI 2017 sérülékenységek

Az ICS-CERT két publikációban hozta nyilvánosságra a gyártó által az alábbi termékekben talált sérülékenységeket:

- PI Data Archive 2017-nél korábbi verziói;
- PI Web API 2017-nél (1.9.0-nál) régebbi verziói.

A PI Data Archive-ban két, nem megfelelő authentikációból adódó sérülékenységet, a PI Web API-ban pedig egy Cross-site Request Forgery-t találtak a gyártó munkatársai.

Az OSISoft mindhárom hibát javította a szoftverek legújabb verzióiban.

A hibákkal kapcsolatban bővebb információt az ICS-CERT alábbi publikációiban lehet találni:
https://ics-cert.us-cert.gov/advisories/ICSA-17-164-02
https://ics-cert.us-cert.gov/advisories/ICSA-17-164-03

Trihedral VTScada sérülékenységek

Karn Ganeshen 3 sérülékenységet talált a Trihedral VTScada 11.2.26-nál korábbi verzióiban. Az első hiba az erőforrások nem megfelelő kezeléséből adódóan gyakorlatilag DoS-támadásra ad lehetőséget, a második hiba egy XSS, a harmadik pedig abból adódik, hogy a web szerver egyes fájljait authentikáció nélkül is el lehet érni.

A gyártó a hibákat a 11.2.26-os verzióban javította, Karn Ganeshen pedig igazolta, hogy a patch valóban javította a fenti hibákat.

A sérülékenységekről további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-164-01

Schneider Electric U.motion 0. napi sérülékenységek

A ZDI 11 darab 0. napi sérülékenységet publikált a Schneider Electric U.motion termékével kapcsolatban, miután 120 nappal a gyártó értesítése után sem kaptak választ a megkeresésükre. A sérülékenységek az alábbi kategóriákba tartoznak:

- SQLi RCE;
- információszivárgás;
- könyvtár bejáráson keresztüli fájlfeltöltési lehetőség és RCE;
- könyvtár bejáráson keresztüli információszivárgás;
- authentikáció-megkerülést lehetővé tevő hiba;
- helyi jogosultsági szint emelést lehetővé tevő hiba.

A sérülékenységekkel kapcsolatban részleteket a ZDI alábbi bejelentéseiben lehet olvasni:

http://www.zerodayinitiative.com/advisories/ZDI-17-383/
http://www.zerodayinitiative.com/advisories/ZDI-17-384/
http://www.zerodayinitiative.com/advisories/ZDI-17-385/
http://www.zerodayinitiative.com/advisories/ZDI-17-386/
http://www.zerodayinitiative.com/advisories/ZDI-17-387/
http://www.zerodayinitiative.com/advisories/ZDI-17-388/
http://www.zerodayinitiative.com/advisories/ZDI-17-389/
http://www.zerodayinitiative.com/advisories/ZDI-17-390/
http://www.zerodayinitiative.com/advisories/ZDI-17-391/
http://www.zerodayinitiative.com/advisories/ZDI-17-392/

Az ICS-CERT az ipari rendszerek sérülékenységei kapcsán továbbra is az ismert kockázatcsökkentő intézkedések alkalmazá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.