Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

Petwrap/Petya.SMA: Az EternalBlue második eljövetele is érint ipari rendszereket

A WannaCry után ezúttal a Petya ransomware új változata is ipari rendszereket érintő támadásokat hajtott végre

2017. július 01. - icscybersec

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/

ICS sérülékenységek CXX

Sérülékenység Siemens XHQ rendszerekben

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.

Újabb autógyárat állítottak le a WannaCry ransomware-féreg miatt

A májusi Renault, Nissan és Dacia leállások után most a Honda egyik gyára állt le

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.

ICS sérülékenységek CXIX

Ecava IntegraXor és Siemens SIMATIC CP sérülékenységek

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.

ICS sérülékenységek CXVIII

Cambium Networks ePMP sérülékenységek

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.

ICS sérülékenységek CXVII

OSISoft PI, Schneider Electric és Trihedral VTScada sérülékenységek

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.

Crashoverride ICS malware framework

Újabb, a villamosenergia-rendszerek elleni támadásokhoz fejlesztett malware-t fedezett fel az ESET és a Dragos, Inc.

A hét elején a kiberbiztonsági és ICS biztonsági szakma az ESET és a Dragos, Inc. által felfedezett és Crashoverride vagy Industroyer néven ismertté vált malware-től volt hangos.

A Dragos kutatói bizonyítottnak látják, hogy ez a malware (igazából egy malware framework-ről írnak) volt a felelős a 2016. december 17-i, Kijevtől északra található, 330 kV-os Ukrenergo alállomáson történt incidensért.

A malware framework több helyen is "crash"-ként hivatkozik magára, emiatt kapta a kutatóktól a Crashoverride nevet. A Dragos szerint a Crashoverride az első, kifejezetten villamosenergia-rendszerek ellen tervezett és bevetett malware framework és a negyedik a célzottan ICS rendszerek ellen létrehozott malware-ek sorában (a Stuxnet, a BlackEnergy2 és a Havex után).

A Crashoverride nem kifejezetten egyetlen gyártó termékeit vagy egyetlen ICS rendszert céloz, ehelyett a villamosenergia-rendszerek működésével és kommunikációjával kapcsolatos tudásra épít, ilyen formán bármikor újra be lehet vetni bármelyik európai, Közel-keleti vagy ázsiai villamosenergia szektorban működő szervezet ICS rendszerei ellen. A vizsgálat idején a malware az Európában valamint a Közel- és Távol-Keleten elterjedt ICS protokollokat (IEC 101, IEC 104 és IEC 61850) használó rendszerek elleni támadásokra képes, de a Dragos szakértői szerint minimális módosításokkal bármikor képessé tehetik DNP3 protokollt használó rendszerek elleni támadásra is.

A Crashoverride lehetőséget ad a támadók számára, hogy egyszerre több helyszínen működő ICS rendszerek ellen intézzenek támadást, de az eddig rendelkezésükre álló információk alapján úgy vélik, hogy az így előidézett üzemzavarok nem lennének nagyon súlyosak, várhatóan órákra, esetleg napokra tudnának komolyabb fennakadásokat okozni a villamosenergia-ellátásban, nem pedig hetekre vagy még hosszabb időre.

A Crashoverride más, korábban ICS rendszerekkel kapcsolatba hozott malware-ekkel szemben nem kémkedésre és adatgyűjtésre lett tervezve, az egyetlen funkciója olyan támadások végrehajtása, ami áramkimaradásokat okoz.

A malware-t újabb protokoll-modulokkal kiegészítve más iparágak ellen is be lehet vetni, azonban a támadók mindezidáig nem mutatták jelét annak, hogy más iparágak ICS rendszerei elleni támadásokhoz szükséges tudással is rendelkeznének - ez persze csak feltételezés, de biztosat csak akkor lehet majd tudni, ha adott esetben más iparág(ak) elleni támadásoknál is megjelenne a Crashoverride.

A Dragos elemzése itt található, az ESET blogbejegyzését itt lehet olvasni, a US-CERT/NCCIC publikációja pedig itt érhető el: https://www.us-cert.gov/ncas/alerts/TA17-163A

Ez utóbbival kapcsolatban Rendition Infosec oldalán írtak arról a tanácsról, ami egy kicsit zavarbaejtő, lévén arról szól, hogy tegyük meg a szükséges lépéseket az ún. watering-hole támadások ellen. Lévén az ilyen támadások pont arról szólnak, hogy a célba vett szervezetek/személyek által egyébként is látogatott, legitim weboldalak/szerverek kompromittálásával helyeznek el a támadáshoz használt szoftverkomponenseket, így az ilyen támadások megelőzése gyakorlatilag lehetetlen.

2017-es Kaspersky ICS biztonsági felmérés

Az ICS rendszereket üzemeltető szervezetek több, mint felét érte kibertámadás az elmúlt egy évben

A Kaspersky idén február és április között végzett felmérését 359 ipari területen dolgozó kiberbiztonsági szakértő töltötte ki.

A felmérés főbb megállapításai:

1. Jelentős eltérések vannak az érintett szervezetek ICS incidensekkel kapcsolatos gondolatai és a valóság között. A válaszadók 83%-a gondolja úgy, hogy megfelelő a felkészültségük egy ICS rendszereket célzó kibertámadás elhárítására, de a megkérdezett szervezetek fele évi 1-5, 4 %-uk pedig hatnál több támadást észlelt a rendszereik ellen az elmúlt évben. Felmerül a kérdés, hogy vajon ezeknél a szervezeteknél min kéne változtatni az IT biztonsági startégiában és a védelmi intézkedésekben, hogy képesek legyenek megvédeni az üzleti és technológiai folyamataikat?

2. A legnagyobb fenyegetést a felmérésben kérdezett vállalatok számára továbbra is a "hagyományos" malware-támadások jelentik.

3. Szintén érdekes eltérés van a belső fenyegetések (munkatársak által szándékosan vagy véletlen hibából előidézett incidensek) megítélésében. A válaszadók elképzelései és a valóság itt is jelentős különbségeket mutat, a megkérdezett szervezetek a belső fenyegetéseket sokkal hátrébb sorolták hatásaikat illetően, mint a külső fenyegetéseket (partnerektől vagy a beszállítói láncból kiinduló incidensek).

4. A megkérdezett szervezetek 86%-a rendelkezik elfogadott ICS biztonsági szabályzattal, azonban az ICS biztonsági incidensekből szerzett tapasztalatok azt mutatják, hogy önmagában az ICS biztonsági szabályzat nem elegendő. A vállalati IT biztonság területén is tapasztalható szakemberhiány az ICS biztonság területén fokozottan érezteti a hatását és ez nagyon aggasztó helyzetet teremt, hiszen pont azok a szakemberek hiányoznak a legnagyobb számban, akik képesek lehetnének felvenni a harcot a gyakran kritikus folyamatok vezérléséért felelő rendszerek elleni külső és belső forrásból érkező támadásokkal.

5. A megkérdezett szervezetek többsége ugyanakkor egészen jó helyzetben van a modern ICS biztonsági kihívásokra adott válaszok terén, a cégek többsége már feladta az ICS rendszerek fizikai leválasztására építő biztonsági intézkedéseket. A válaszadók 42 %-a tervezi a következő egy évben hálózati anomália észlelő rendszer bevezetését az ipari rendszereihez kapcsolódóan és a biztonságtudatossági képzést tervezők aránya is magas.

A Kaspersky által készített felmérésről további részleteket a blog.kaspersky.com-on megjelent cikkben lehet olvasni.

 

ICS sérülékenységek CXVI

Sérülékenységek Rockwell Automation és Digital Canal Structural rendszerekben

Rockwell Automation PanelView sérülékenység

Az ICS-CERT publikációja szerint a Rockwell Automation PanelView Plus 6 700-1500, grafikai terminál és logikai modul termékeinek alábbi verzióiban fedezett fel a gyártó egy hiányzó jogosultságkezelésből adódó hibát:

- 6.00.04;
- 6.00.05;
- 6.00.42;
- 6.00-20140306;
- 6.10.20121012;
- 6.10-20140122;
- 7.00-20121012;
- 7.00-20130108;
- 7.00-20130325;
- 7.00-20130619;
- 7.00-20140128;
- 7.00-20140310;
- 7.00-20140429;
- 7.00-20140621;
- 7.00-20140729;
- 7.00-20141022;
- 8.00-20140730 és
- 8.00-20141023.

Az OS 2.31 és későbbi verziókat futtató grafikus terminálokat a hiba nem érinti.

A sérülékenységet az alábbi verziókra történő frissítéssel lehet javítani:

- V7.00 használata esetén a V7.00-20150209-re történő frissítéssel;
- V8.00 használata esetén a V8.00-20160418-ra történő frissítéssel;
- V8.10 használata esetén a V8.10-20151026-ra történő frissítéssel;
- V8.20 használata esetén a V8.20-20160308-ra történő frissítéssel;
- V9.00 használata esetén a V9.00-20170328-ra történő frissítéssel.

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

Digital Canal Structural Wind Analysis sérülékenység

Peter Cheng a Digital Canal Structural Wind Analysis nevű szerkezei tervező szoftverében talált egy puffer-túlcsordulási hibát, ami a szoftver 9.1-es és korábbi verzióit érinti.

A gyártó a hibát a legújabb verzióban javította, amit bárki szabadon letölthet a Digital Canal Structural FTP szerveréről.

A hibával kapcsolatban további információk az ICS-CERT bejelentésében olvashatóak: https://ics-cert.us-cert.gov/advisories/ICSA-17-157-02

A most ismertetett sérülékenységekkel kapcsolatban az ICS-CERT ezúttal is a szokásos 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.

ICS sérülékenységek CXV

Moxa és Phoenix Broadband Technologies LLC rendszerek sérülékenységei

Moxa OnCell sérülékenységek

Maxim Rupp a Moxa OnCell termékcsaládjának alábbi nagysebességű ipari átjáróiban talált több sérülékenységet:

- OnCell G3110-HSPA Version 1.3 build 15082117 és korábbi verziók;
- OnCell G3110-HSDPA Version 1.2 Build 09123015 és korábbi verziók;
- OnCell G3150-HSDPA Version 1.4 Build 11051315 és korábbi verziók;
- OnCell 5104-HSDPA;
- OnCell 5104-HSPA;
- OnCell 5004-HSPA.

A hibák között van olyan, ami lehetővé teszi a felhasználói jelszavak brute-force támadását, jelszavak olvasható formában történő tárolása és CSRF is.

Az OnCell G31x0-HSPA és OnCell 5x04-HSPA eszközöket használó ügyfeleinek a gyártó az 1.4 vagy későbbi firmware-verziók alkalmazását javasolja, az OnCell G31x0-HSDPA és OnCell 5x04-HSDPA modelleket használóknak pedig a HTTP konzol elérés HTTPS-re cserélését (vagy SNMP/Telnet használatát, amit én személy szerint egy kicsit vitathatónak találok). Az OnCell G31x0-HSDPA és OnCell 5x04-HSDPA modellek életciklusa a Moxa közlése szerint már kifutott, ennek ellenére további segítségért azt javasolják, hogy az érintett ügyfelek lépjenek kapcsolatba a Moxa-val.

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

Phoenix Broadband Technologies LLC PowerAgent SC3 Site Controller sérülékenység

Az ICS-CERT publikációja szerint Iñaki Rodríguez egy beégetett jelszót talált a Phoenix Broadband Technologies LLC által gyártott PowerAgent SC3 Site Controller rendszer v6.87-nél korábbi verzióiban. A hibát kihasználva egy támadó képes lehet jogosulatlan hozzáférést szerezni a szünetmentes tápellátást biztosító akkumulátorok felügyeletét ellátó rendszerhez.

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

A hibával kapcsolatos további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-152-01

A fenti kockázatok csökkentése érdekében az ICS-CERT ezúttal is az ismert 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.

süti beállítások módosítása