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.

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.

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.

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.

Ma a múlt héten elkezdett, Cyber Security Kill Chain bemutatását folytatom.

4. A sérülékenység kihasználása (Expoitation): Hozzáférés szerzése a célba vett rendszeren

A támadók tevékenységei: A támadóknak ahhoz, hogy hozzáférést szerezzenek a célba vett rendszeren, ki kell használniuk egy vagy több korábban felfedezett sérülékenységet - ezek adódhatnak szoftveres, hardveres vagy emberei hibákból. Ebben a fázisban egyaránt elképzelhetőek a támadó által kiváltott sérülékenység-kihasználások (a legtöbb szerver oldali sérülékenység ilyen) vagy olyan, emberi hibákból adódó támadási vektorok, mint például egy kártékony kódot tartalmazó e-mail megnyitása vagy egy ártó szándékú webhelyre mutató hivatkozás követése.

A védők tevékenységei: A célba vett rendszerek esetén a hagyományos hardening-technikák nyújthatnak bizonyos fokú ellenálló képességet, de például a nulladik napi sérülékenységeket célzó támadások elhárításához egyedi képességekre is szükség van. A védekezésben fontos szerep jut a biztonságtudatossági képzéseknek, a fejlesztők biztonságos fejlesztési technikákra történő oktatása, rendszeres sérülékenység vizsgálatok és betöréstesztek végrehajtása. Kiemelten kell foglalkozni a végponti berendezések hardening-jével, elsősorban az adminisztratív jogosultságok szigorú korlátozásával, a kódvégrehajtás lehetőségének minimálisan szükséges szintre történő korlátozásával és az olyan szoftverek alkalmazásával, amikkel csökkenteni lehet egy támadás sikerességének az esélyét (az ilyen szoftverek közül a legismertebb talán a Microsoft EMET, aminek a fejlesztése a hírek szerint rövidesen megszűnik, azonban helyette több ingyenes és fizetős megoldás is néhány perces kereséssel elérhető).

5. Hátsó ajtók telepítése (Installation): Hídfő kiépítése az áldozat rendszerében

A támadók tevékenységei ebben a fázisban a megszerzett hozzáférés(ek) hosszabb időn át történő fenntartására koncentrálnak, különböző hozzáférési módok kialakításával, pl. webshell vagy különböző backdoor-ok telepítésével. Egyes támadók arra is figyelnek, hogy az így létrehozott fájlok létrehozási/utolsó módosítási dátumát visszaállítsák, hogy úgy tűnjön, a fájl az adott rendszer telepítésekor lett létrehozva.

A védők tevékenységei: A védők ebben a fázisban leginkább a különböző végponti biztonsági eszközökkel, host IPS-ekkel és más végpontvédelmi megoldásokkal tudnak védekezni. Fontos továbbá, hogy megértsék, az adott malware, amivel a támadók hozzáférést szereztek az adott rendszerhez, adminisztrátori vagy felhasználói jogosultságokkal fertőz. A védekezésben sokat segíthet a végponti folyamatok auditálására illetve a fájl konzisztencia ellenőrzésre használható megoldások, valamint a digitálisan aláírt futtatható állományok tanúsítványainak vizsgálata is. Érdemes ellenőrizni a támadáshoz használt malware fordításának idejét is, amiből elég jó következtetéseket lehet levonni arra vonatkozóan, hogy egy új vagy egy régebbi malware-rel van-e dolguk a védőknek.

6. Irányítás (Command&Control - C2): A kompromittált rendszer távoli vezérlése

A támadók tevékenységei: Ebben a fázisban a támadók olyan kétirányú kommunikációt próbálnak építeni a kompromittált eszköz és egy, a saját irányításuk alatt lévő szerver között, amivel később is a céljaiknak megfelelően tudják használni az adott eszközt. Az ilyen szervereket hívják Command&Control, röviden C2 szervereknek. A leggyakoribb C2 csatornák a webes, DNS és e-mail protokollok.

A védők tevékenységei: A védők számára ebben a fázisban nyílik utoljára lehetőség arra, hogy megakadályozzák a támadók műveleteit, azzal, hogy blokkolják a C2 csatornákat. Ha ez sikeres, a támadók nem tudják majd irányítani a megfertőzött eszközt és így a védők megelőzhetik a nagyobb károkat. A védekezés során hasznos eszköz lehet a malware-analízis, amivel be lehet azonosítani az adott malware által használt C2 infrastruktúrát és ezzel lehetőség nyílik tökéletesen blokkolni a C2 forgalmat. A hálózaton végzett biztonsági hardening (az Internetes jelenléthez használt pontok számának minimalizálása és a leggyakoribb forgalmak, pl. HTTP, DNS proxy-kon keresztül történő átengedése). Szintén hatékonyabbá teheti a védekezést a nyílt forrású információgyűjtésből (és a szektoriális jellegű együttműködésekből!) származó újabb és újabb C2 infrastruktúrák adatai.

7. A cél elérése (Actions on objectives)

A támadók tevékenységei: Az utolsó fázisban a támadók már azt teszik, amiért az egész műveletet elkezdték. Felhasználói adatokat gyűjtenek össze és lopnak ki a megtámadott rendszerből, magasabb (jellmezően adminisztrátori) jogosultságokat próbálnak szerezni, a megtámadott szervezet belső hálózatát próbálják felderíteni és további rendszerekben próbálják megvetni a lábukat vagy akár használhatatlanná tesznek rendszereket, felülírnak vagy titkosítanak adatokat.

A védők tevékenységei: Ha egy IT biztonsági incidens eljut a CSKC 7. fázisáig, akkor a védőknek már az kell, hogy legyen az elsődleges szempontjuk, hogy minél rövidebb idő alatt meg tudják szakítani a támadók hozzáférését a kompromittált rendszerekhez, ugyanis minél tovább van hozzáférésük a támadóknak egy rendszerhez, annál nagyobb károkat tudnak okozni. Ahhoz, hogy a védők minél előbb meg tudják szüntetni a támadók hozzáféréseit, jól kidolgozott és begyakorolt incidenskezelési forgatókönyveket kell alkotni és elengedhetetlen a felelős vezetők bevonása és egy hatékony kommunikációs terv kialakítása. A műszaki megoldásokból ebben a fázisban azok a megoldások a leginkább hatékonyak, amelyekkel észlelni lehet a nagyobb mennyiségű kimenő adatot, a nem engedélyezett felhasználói fiókok használatát, az incidenskezelésben használható különböző vizsgálati eszközök előtelepítését az egyes végpontokra és a hálózati forgalom rögzítését végző eszközöket, amelyek adataiból a vizsgálat során fel lehet építeni a támadás menetét.

Utólagos elemzések - a támadási minták azonosítása

A fentiek alapján elemzett támadások alapján egészen jó képet lehet kapni az egyes támadások közötti hasonlóságokról. A védők ezek alapján megtanulhatják felismerni és meghatározni a támadásokat és megérteni a támadók céljait. A CSKC alkalmazásával a szervezetek megelőzhetik a jövőbeli támadások egy részét és ellenállóbbá válhatnak azokkal, amelyek mégis be fognak következni.

Az elmúlt egy hétben ismét számos új, ICS rendszereket érintő sérülékenységi információ látott napvilágot, nem teljesen függetlenül a WannaCry ransomware-támadások utóhatásaitól.

Sérülékenység a Miele Professional PG 85 sorozatú berendezésekben

Jens Regel, a Schneider & Wulf munkatársa mindenfajta előzetes egyeztetés nélkül publikált egy, a Miele Professional PG 85 sorozatú berendezéseiben felfedezett, könyvtár-bejárást lehetővé tevő hibát. A sérülékenység az alábbi verziókat érinti:

- PG8527, 2.02, 2.51, 2.52 és 2.54-es verziók;
- PG8528, 2.02, 2.51, 2.52 és 2.54-es verziók;
- PG8535, 1.00 és 1.04-es verziók;
- PG8536, 1.10 és 1.14-es verziók.

A gyártó a hiba javítását május 4-én adta ki, a sérülékeny verziókat használó ügyfelek az alábbi verziókra frissítve javíthatják a hibát:

- PG8527, 2.02-es verzió esetén a 2.12-es verzióval;
- PG8527, 2.51-es verzió esetén a 2.61-es verzióval;
- PG8527, 2.52-es verzió esetén a 2.62-es verzióval;
- PG8527, 2.54-es verzió esetén a 2.64-es verzióval;
- PG8528, 2.02-es verzió esetén a 2.12-es verzióval;
- PG8528, 2.51-es verzió esetén a 2.61-es verzióval;
- PG8528, 2.52-es verzió esetén a 2.62-es verzióval;
- PG8528, 2.54-es verzió esetén a 2.64-es verzióval;
- PG8535, 1.00-ás verzió esetén az 1.10-es verzióval;
- PG8535, 1.04-es verzió esetén az 1.14-es verzióval;
- PG8536, 1.10-es verzió esetén az 1.20-as verzióval;
- PG8536, 1.14-es verzió esetén az 1.24-es verzióval.

A hibával kapcsolatban bővebb információkat az ICS-CERT bejelentésében és a gyártó sajtóközleményéből lehet megtudni.

Schneider Electric Wonderware sérülékenység

Karn Ganeshen egy helytelen alapértelmezett jogosultsági beállításból fakadó sérülékenységet talált a Wonderware InduSoft Web Studio v8.0 Patch 3 és azt megelőző verzióiban. A hiba kihasználásával egy támadó képes lehet a jogosultsági szintjének emelésére a sérülékeny rendszerekben.

A Schneider Electric a hibát a Wonderware InduSoft Web Studio v8.0 + Service Pack 1 verzióban javította.

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

Sérülékenység B. Braun Medical rendszerekben

Marc Ruef és Rocco Gagliardi of scip AG munkatársai egy URL átirányítást lehetővé tevő hibát találtak a B. Braun Medical alábbi SpaceCom moduljaiban:

- A 8713142U cikkszámú SpaceCom modulok 012U000040-nél korábbi verziói;
- A 8713140U cikkszámú SpaceStation berendezések 8713160U cikkszámú SpaceCom moduljainak 012U000040-nél korábbi verziói.

A B. Braun Medical a hibát a 012U000040-es verzióban javította, amit (telepítési tanácsokkal együtt) a gyártó FTP-szerveréről lehet letölteni.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSMA-17-082-02

Sérülékenység egyes Rockwell Automation Allen-Bradley MicroLogix rendszerekben

A Rockwell Automation Allen-Bradley MicroLogix alábbi berendezéseit érintő hibát egymástól függetlenül David Formby és Raheem Beyah, a GeorgiaTech és a Fortiphyd Logic, Inc. kutatói, valamint Ilya Karpov, a Positive Technologies munkatársa fedezték fel:

- MicroLogix 1100 PLC-k:
- 1763-L16AWA, A és B sorozat, 16.00 és ennél korábbi verziók;
- 1763-L16BBB, A és B sorozat, 16.00 és ennél korábbi verziók;
- 1763-L16BWA, A és B sorozat, 16.00 és ennél korábbi verziók;
- 1763-L16DWD, A és B sorozat, 16.00 és ennél korábbi verziók;
- MicroLogix 1400 PLC-k:
1766-L32AWA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BWA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BWAA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BXB, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32BXBA, A és B sorozat, 16.00 és ennél korábbi verziók;
1766-L32AWAA, A és B sorozat, 16.00 és ennél korábbi verziók.

A kutatók által feltárt hibák az alábbiak:
- A korábbi TCP szekvencia-számokból megjósolható a következő érték, amit kihasználva egy támadó képes lehet meghamisítani az érintett eszközök kommunikációját;
- Egyszer használatos értékek ismételt felhasználása az alkalmazott titkosítási eljárásban;
- A felhasználói adatok sima HTTP GET-tel történő továbbítása lehetőséget ad a felhasználói adatok rögzítésére;
- Nincs semmilyen kontroll a nyers erőn alapuló jelszótörési kísérletek kivédésére;
- Gyenge jelszavak használatának lehetősége.

A hibát a Rockwell Automation a MicroLogix 1400 B sorozatú eszközeihez kiadott, FRN 21.00 firmware-verzióban javította. A MicroLogix 1100 A és B, valamint az 1400 A sorozatú eszközökhöz a gyártó már nem adta ki a hibák javítását tartalmazó firmware-verziót, helyett a kockázatokat csökkentő intézekdések bevezetését javasolja:

- Ha nem szükséges, le kell tiltani az érintett eszközök beépített webszerverét;
- Az érintett eszközöket futási módban kapcsolva megvédhetjük a a sérülékeny berendezéseket.

A sérülékenységgel kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-115-04

Moxa OnCell sérülékenységek

Maxim Rupp három hibát talált a Moxa alábbi, nagy sebességű, ipari szintű átjáróiban:

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

A hibákról dióhéjban:
- Az első sérülékenységet a nyers erőn alapuló jelszótörések elleni védelem hiánya okozza;
- A második hiba a jelszavak olvasható, szöveges formában történő tárolásából adódik;
- A harmadik hiba pedig egy CSRF.

A fenti hibákat a Moxa csak az alábbi modellek esetén javíotta, az OnCell G31x0-HSPA és OnCell 5x04-HSPA modellek esetén az 1.4-es vagy újabb firmware-verziók már javítják a fenti sérülékenységeket. Az OnCell G31x0-HSPA és OnCell 5x04-HSPA modellek esetén a felhasználók számára javasolt letilteni a HTTP kapcsolatokat és helyette inkáb a HTTPS használatát tanácsolják.

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

EternalBlue (WannaCry) sérülékenység Siemens Healthineers egészségügyi rendszerekben

A Siemens számos, Siemens Healthineers termékcsaláddal kapcsolatos bejelentést publikált, amikben az alábbi termékek EternalBlue sérülékenységére és annak már elérhető javításaira hívják fel a figyelmet:

- syngo Multimodality Workplace (MMWP) minden verziója;
- MAGNETOM® MRI rendszerek minden verziója;
- Molekuláris képalkotó rendszerek:
- PET/CT rendszerek: minden modell minden verziója;
- SPECT/CT rendszerek: minden modell minden verziója;
- SPECT rendszerek: minden modell minden verziója;
- SPECT rendszerek: minden modell minden verziója;
- Laboratóriumi diagnosztikai rendszerek:
- Atellica® COAG 360 minden verziója;
- BCS® XP minden verziója;
- BN ProSpec® minden verziója;
- Atellica NEPH 630 minden verziója;
- BEP 2000 Advance® minden verziója;
- Quadriga BeFree minden verziója;
- ADVIA® 2120i minden verziója;
- ADVIA 120 minden verziója;
- Sysmex® CS-2000i/2100i minden verziója;
- Sysmex CS-2500 minden verziója;
- Sysmex CS-5100 minden verziója;
- ADVIA 560 minden verziója;
- ADVIA Chemistry 1800 minden verziója;
- ADVIA Chemistry 2400 minden verziója;
- ADVIA Chemistry XPT minden verziója;
- ADVIA Centaur® XP minden verziója;
- ADVIA Centaur CP minden verziója;
- ADVIA Centaur XPT minden verziója;
- Dimension Vista® minden verziója;
- IMMULITE® 1000 minden verziója;
- IMMULITE 2000 minden verziója;
- syngo® Laboratory Connectivity Manager: minden verziója;
- syngo Laboratory Data Manager minden verziója;
- Aptio® Automation minden verziója;
- ADVIA Automation minden verziója;
- VersaCell® minden verziója;
- VersaCell X3 minden verziója;
- VivaTM minden verziója;
- Röntgenográfiai, mobil röntgen és mammográfiai rendszerek:
- Mammomat Inspiration® minden verziója;
- Mammomat Fusion® minden verziója;
- syngo® MammoReport minden verziója;
- Mammomat Novation minden verziója;
- AXIOM® Aristos FX/MX/VX/TX minden verziója;
- MULTIX® M minden verziója;
- MULTIX® Swing mFD minden verziója;
- Mobilett XP digital® minden verziója;
- Molekuláris diagnosztikai rendszerek:
- VERSANT kPCR Molecular System minden verziója;
- VERSANT kPCR Sample Prep minden verziója;
- Tissue Preparation System minden verziója;
- Onkológiai sugárkezelő rendszerek:
- RTT minden verziója;
- Coherence Therapist / Primeview 3i minden verziója;
- Coherence Oncologist minden verziója;
- Coherence Dosimetrist minden verziója;
- Coherence Physicist minden verziója;
- Syngo RT Therapist minden verziója;
- Syngo RT Oncologist minden verziója;
- Syngo RT Dosimetrist minden verziója;
- ModuLeaf minden verziója;
- Simview 3000/NT minden verziója;
- Beamview NT minden verziója;
- Lantis minden verziója;
- Mosaiq (Elekta product) minden verziója;
- Biograph mMR rendszer minden verziója;
- Point-of-Care rendszerek:
- RAPIDPoint 400 minden verziója;
- RAPIDPoint 500 minden verziója;
- RAPIDLab 1200 minden verziója;
- CLINITEK AUWi minden verziója;
- Terápiás rendszerek:
- Artis minden típus és verzió;
- Sensis minden típus és verzió;
- Leonardo/X-Workplace minden verzió;
- Arcadis Family minden verzió;
- Ultrahang rendszerek:
- ACUSON SC2000™ ultrahang rendszer: 4.x és 5.x verziók;
- syngo® SC2000™ Workplace: 4.x és 5.x verziók;
- ACUSON X700™ ultrahang rendszer: 2.0-nál korábbi verziók;
- ACUSON P500™ ultrahang rendszer minden verzió;
- ACUSON P300™ ultrahang rendszer minden verzió;

A felsorolt termékek EternalBlue sérülékenység általi érintettségéről további információkat az alábbi, Siemens ProductCERT publikációkból lehet megtudni:

http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-354910.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-832636.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-161640.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-286693.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-492736.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-966341.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-774661.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-740012.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-709509.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-023589.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-701903.pdf
http://www.siemens.com/cert/pool/cert/siemens_security_bulletin_ssb-412479.pdf

Ezzel párhuzamosan az ICS-CERT újabb, ICS/egészségügyi gyártók által kiadott publikációkat adott közre az EternalBlue sérülékenység által érintett különböző ipari rendszerekről:

- GE;
- Philips;
- Smith Medical;
- Johnson & Johnson;
- Medtronic;
- Tridium;
- Emerson Automation Solutions;
- Honeywell;

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.

Schneider Electric SoMachine rendszerek sérülékenységei

Zhou Yu, független biztonsági kutató két sérülékenységet talált a Schneider Electric SoMachine nevű, PLC programozásra használható szoftverének 2.1.0 és korábbi verzióiban. Az első hiba egy puffer túlcsordulás, a második pedig DLL hijack támadást tesz lehetővé.

A gyártó a sérülékenységek által érintett ügyfeleinek azt tanácsolja, hogy frissítsenek a SoMachine HVAC Programming Software 2.2-es verziójára.

A sérülékenységekről további részleteket a Schneider Electric és az ICS-CERT bejelentéseiből lehet megtudni.

Schneider Electric VAMPSET sérülékenység

Kushal Arvind Shah, a Fortinet-nél működő Fortiguard Labs munkatársa egy memóriakorrupciós hibát fedezett fel a VAMPSET 2.2.189-nél korábbi verzióiban.

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

A hibával kapcsolatban további információkat a gyártó és az ICS-CERT által kiadott tájékoztatókból lehet szerezni.

Hanwha Techwin SRN-4000 sérülékenység

Can Demirel és Faruk Unal, a Biznet Bilisim munkatársai egy authentikáció nélküli, adminisztrátori szintű hozzáférést biztosító hibát találtak a Hanwha Techwin SRN-4000 típusú eszközeinek SRN4000_v2.16_170401-nél korábbi verzióiban.

A gyártó a hibát a RN4000_v2.16_170401-es és újabb verziókban már javította.

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

Detcon SiteWatch Gateway sérülékenység

Maxim Rupp független biztonsági kutató két sérülékenységet (nem megfelelő authentikáció, olvasható formában tárolt jelszavak) fedezett fel a Detcon SiteWatch Gateway nevű termékeiben. A sérülékenységek a SiteWatch Gateway minden verzióját érintik, a gyártó közlése szerint a mobil kommunikációs termékeket azonban nem.

A gyártó már nem forgalmazza az érintett SiteWatch Gateway termékeket és támogatást sem nyújt hozzájuk.

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

EternalBlue sérülékenység ipari rendszerekben

A WannaCry ransomware-támadásokat lehetővé tevő, EternalBlue-nak nevezett SMB-sérülékenységgel kapcsolatban jelentetett meg egy figyelmeztetést, amiben az alábbi, ipari rendszereket gyártó cégek bejelentéseit gyűjtötték össze az EternalBlue sérülékenységgel kapcsolatban:

- Rockwell Automation;
- Becton, Dickinson and Company;
- Schneider Electric;
- ABB;
- Siemens.

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 ICS rendszerek elleni kibertámadások nagyon sok jellemzőjükben különböznek az IT rendszerek elleni támadásoktól, ez még akkor is igaz, ha az utóbbi időben nyilvánosságra került jelentősebb ICS biztonsági incidenseknek komoly IT biztonsági része is volt.

Ahhoz, hogy mélyrehatóbban tudjunk foglalkozni az ICS Cyber Security Kill Chain-nel, először kicsit át kell tekinteni, hogy mi is az ennek a keretrendszernek az alapját adó Cyber Security Kill Chain, ezt fogjuk egy kicsit részletesebben áttekinteni a mai és a jövő heti posztban.

Mi az a Cyber Security Kill Chain?

A CSKC-t a Lockheed Martin munkatársai dolgozták ki 2011-ben és munkájuk során (ahogy a kiberbiztonság során már oly sokan előttük) ők is az angolszász katonai terminológiához nyúltak vissza. A Kill Chain kifejezés a katonai zsargonban az ellenséggel való harcérintkezés fázisait foglalja össze.

Ennek mintájára alkották meg a Lockheed-Martin munkatársai a CSKC-t, ami az APT-nek is nevezett kibertámadások jellemző felépítését ismerteti, mind a támadók, mind a védekezésben résztvevő kiberbiztonsági szakemberek feladatait ismertetve az egyes fázisokban. A CSKC 7 fázisra bontja a kifinomult kibertámadásokat, ezek az alábbiak (már az egyes fázisok neve is egészen jól visszautal arra, hogy ez a keretrendszer a katonai terminológiából építkezik):

1. Felderítés (Reconnaissance): A célpont(ok) beazonosítása.

A támadók tevékenységei: Ebben a fázisban a támadók a műveleteik megtervezését végzik, információt gyűjtenek, hogy megértsék a megtámadni tervezett rendszer működését, esetleges hibák után kutatnak, amiknek a kihasználásával elérhetik a céljaikat. Ehhez e-mail címeket gyűjtenek,  a megtámadni tervezett szervezet munkatársait próbálják beazonosítani a közösségi oldalakon, átvizsgálják a sajtóban megjelent híreket, konferencia-résztvevők listáit és felmérik a szervezet Interneten elérhető szervereinek körét.

A védők tevékenységei: A támadók felderítéssel kapcsolatos tevékenységeit normális esetben nehéz lehet észlelni, de ha sikerül, az így szerzett információk nagy segítséget jelenthetnek a támadók céljainak azonosításában. Ilyen információkat lehet találni az Interneten elérhető szerverek logjaiban, a látogatásokról készült webes analitikákból (böngésző statisztikák, látogatási idők, stb.).

2. “Fegyverkezés” (Weponization): Felkészülés a műveletre.

A támadók tevékenységei: A támadók ebben a fázisban a korábban gyűjtött és elemzett adatokra építve elkezdik a felkészülést magára a támadásra. Ehhez általában publikusan vagy csak zárt körben elérhető, esetleg házon belül, egyedileg fejlesztett eszközöket (exploit kit-eket, egyedi exploit-okat) használnak. A fájl-alapú exploit-okhoz elkészítik a megfelelő csali-dokumentumokat és előkészítik a kompromittált eszközökre szánt hátsó ajtókat biztosító szoftvereket, valamint a C2 (command&control) infrastruktúrákat majd lefordítják a megalkotott programkódokat.

A védők tevékenységei: A CSKC-nek ez az a fázisa, ami alapvető fontosságú a védők számára, hogy megértsék. Annak ellenére, hogy nem képesek észlelni a támadók tevékenységét ebben a fázisban, mégis a széleskörű malware-elemzés (nem csak azt vizsgálva, hogy milyen kártékony kódot használ az adott malware, hanem a teljes működési modelljét), segíthet átlátni a támadók módszereit és segíthet olyan eszközöket és technikákat kifejleszteni, amik javítják az adott szervezet észlelési képességeit. Fontos részlet lehet, hogy egy adott malware mikor készült. Egy régebben készült malware újra és újra megjelenhet az adott szervezetnél (hiszen a támadók gyakran nem képesek vagy nem akarnak jelentős erőforrásokat fordítani egy új malware létrehozására, csak újrahasznosítanak egy régebbit), azonban egy új, korábban nem ismert malware megjelenése valószínűleg aktív, célzott támadásra utalhat. A védőknek ehhez a fázishoz érdemes fájlokat és meta-adatokat gyűjteni, ami segítségükre lehet a később elemzések során. Érdemes figyelemmel követni, hogy a támadók milyen eszközöket (exploit kit-ek, újrahasznosított egyedi fejlesztési malware-ek, stb.) milyen támadásoknál használtak, azok széles körben használtak vagy csak néhány, jól meghatározható esetben?

3. A támadás megindítása (Delivery): A malware célba juttatása

A támadók tevékenységei: Ebben a fázisban a támadók szinte kizárólag két módszerrel szoktak élni, az első az aktív támadás, amikor az Interneten elérhető szervereket veszik célba és azok sérülékenységeit kihasználva szereznek hozzáférést. A másik módszernél a különböző csali eszközöket (e-maileket vagy fizikai adathordozókat juttatnak a célponthoz vírusos fájlokkal, különböző közösségi oldalakon végrehajtott műveleteket vagy fertőző weboldalak, gyakran legitim weboldalakon elhelyezett exploitokat használva).

A védők tevékenységei: A védekezésben résztvevőknek ebben a fázisban van először igazi esélyük arra, hogy megakadályozzák a támadókat abban, hogy elérjék a céljaikat. Ehhez célszerű elemezniük a malware-ek célba juttatását és későbbi irányítását szolgáló infrastruktúrát. A védőknek meg kell érteniük a célba vett szerverek működését, a velük kapcsolatba kerülő emberek feladatait, szerepüket és felelősségeiket, valamint az ezekkel kapcsolatban elérhető információkat. Fontos pont, hogy a védők megértsék, a támadók mi alapján választották ki a célpontjukat. A legtöbb esetben a védők számára is elérhetőek a támadók által használt eszközök (vagy legalábbis ezek egy része), ezeket tanulmányozva a támadás korai fázisában nagyobb esély nyílhat a megállítására. Szintén vizsgálni kell, hogy melyik napszakban indult egy támadás, ha a támadók láthatóan munkaidőn kívül tevékenykednek, akkor jó okkal lehet feltételezni (bár korántsem 100%-os biztonsággal), hogy egy célzott támadással van dolgunk. Ebben a fázisban az is nagyon fontos, hogy az összes releváns logot összegyűjtsék, mert még ha nem is sikerül megakadályozni a támadást, később sokat segíthet, ha be lehet azonosítani, mikor és hogyan kezdődött a támadás.

A jövő heti blogposztban befejezzük a Cyber Security Kill Chain áttekintését, utána pedig belekezdünk az ICS Cyber Security Kill Chain részletekbe menő bemutatásába.

Phoenix Contact GmbH mGuard sérülékenységek

Az ICS-CERT bejelentése szerint a Phoenix Contact GmbH mGuard hálózati eszközökben több sérülékenységet is talált gyártó:

- mGuard firmware-ek 8.3.0-tól 8.4.2-es verziókig terjedően.

A gyártó a 8.5.0 firmware-verzióban javította a hibákat, amik között egy DoS-támadást lehetővé tevő hiba és egy nem megfelelő authentikáció található.

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

Satel Iberia SenNet Data Logger és elektromos mérőórák sérülékenysége

Karn Ganeshan biztonsági kutató egy olyan hibát fedezett fel a Satel Iberia SenNet Data Logger nevű termékében és elektromos mérőóráiban, amit kihasználva egy támadó teljes hozzáférést szerezhet a sérülékeny rendszerekhez:

- SenNet Optimal DataLogger V5.37c-1.43c és korábbi verziói;
- SenNet Solar Datalogger V5.03-1.56a és korábbi verziói;
- SenNet Multitask Meter V5.21a-1.18b és korábbi verziói.

A gyártó a sérülékeny verziókat használó ügyfeleinek azt tanácsolja, hogy lépjenek kapcsolatba a terméktámogatási csoporttal és igényeljék a fenti rendszerekhez a legújabb szoftver-verziót.

A sérülékenységről további részleteket az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-131-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.

Az elmúlt nagyjából 48 órában a szakmai és igen jelentős részben a mainstream sajtó is a WannaCry néven elhíresült ransomware-féreg támadásaitól volt hangos. Bár mindezidáig nem érkezett olyan hír, hogy ipari környezeteket vagy rendszereket is elértek volna a támadások, de kritikus infrastruktúrák (kórházak, telekommunikációs szolgáltató cégek, stb.) szerte a világon és részben Magyarországon is érintettek (amiről eddig tudni lehet, az a Telenor és a T-csoport egyes vállalatainak érintettségéről szólnak).

Arról, hogy mi is a WannaCry vagy WannaCrypt0r 2.0, csak röviden írok, ahogy a poszt végén található linkekből látszik, a szaksajtó és a különböző IT biztonsági cégek két napja nagyjából másról sem írnak. A támadások alapjául a Shadow Brokers nevű hackercsoport által az NSA-től ellopott, majd publikált sérülékenységek egyike, a Windows rendszereket érintő MS17-010-es biztonsági frissítésben részletezett, számos (már elavult vagy aktív támogatással rendelkező) Windows verziót érintő, SMBv1-et érintő hiba szolgált (egyes források szerint SMBv2 is érintett, de a Microsoft hibával kapcsolatos publikációja csak a v1-et említi). Egy forrásom szerint egyébként a hibát az MS17-008-as biztonsági és az MS17-006 havi összesített frissítések tartalmazzák. A támadások pénteken délután váltak egyre komolyabbá, 18:00 körül már 74 országból érkeztek hírek egyre komolyabb károkról, többek között a brit egészségügyi szolgálat (NHS) rendszereit is használhatatlanná tette.

A támadás olyan méreteket öltött, hogy a Microsoft, soron kívül és saját szabályait félretéve javítást adott ki a már nem támogatott operációs rendszereihez (Windows XP, Windows Server 2003 család, Vista, 8) is. Most (vasárnap este) úgy tűnik, hogy viszonylagos nyugalom van (miután egy brit biztonsági kutató mondhatni véletlenül elérte, hogy a WannaCry leálljon, miután regisztrálrta azt a domaint, amit aktívnak látva a WannaCry felfüggesztette a működését), de szakértők szerint a következő nagyobb támadási hullám a hétfő reggeli munkakezdéshez kapcsolódhat, amikor ismét tömegesen jelenhetnek meg a hálózatokon még nem frissített számítógépek, illetve a támadók (bárki is álljon e mögött a ransomware-kampány mögött) bármikor módosíthatják a kódjukat, hogy az eddigi védelmi intézkedések hatástalanok legyenek (kivéve persze az SMBv1 hiba javítását).

Hogy hogyan hat ez a támadás az ICS rendszerekre? Ezt egyelőre nehéz megmondani, de az alábbi, ICS biztonsági körökben rendszeresen hangoztatott problémák tökéletes terepet kínálnak egy ilyen szinten virulens féregnek:

1. Internetre csatlakoztatott ICS rendszerek: Bár hosszú évek óta nagyon sok ICS kiberbiztonsággal foglalkozó kutató hangoztatja, hogy az ipari rendszerek közvetlen Internet kapcsolatait minél előbb meg kell szüntetni (az már világos, hogy az ipari hálózatok teljes, fizikai szeparálása a legtöbb szervezetnél üzleti és/vagy technológiai okok miatt nem megoldható), tíz és százezrével találhatóak az Interneten ipari rendszerek.

2. Napjainkban az ipari rendszerek egyik legelterjedtebb operációs rendszere a Microsoft Windows, ennek a családnak is jellemzően a régebbi verziói (főként Windows XP és 2003 verziók, de a termelésirányításban sok helyen akár még Windows NT 4.0-val is találkozhatnak a bennfentesek), ami bizony azt jelenti, hogy ezeknél a rendszereknél az üzemeltetőknek szombatig esélyük sem volt telepíteni a hibajavítást.

3. Az, hogy már minden Windows 2000-nél újabb Windows verzióhoz van elérhető hibajavítás a célba vett SMBv1 sérülékenységhez, nem jelenti azt, hogy napokon (vagy akár heteken) belül védettek lehetnek az érintett ipari rendszerek. Pont az ICS rendszerek sajátos patch-menedzsment eljárása (illetve sok esetben a patch-menedzsment eljárás teljes hiánya) miatt akár hónapokra is szükség lehet, amíg egy-egy rendszerre felkerül a most kiadott frissítés.

Ha a fenti problémák nem lennének önmagukban is elég súlyosak és együtt egyenesen a tökéletes forgatókönyv egy ICS biztonsági incidenshez, az elmúlt évek tendenciája, hogy a különböző nemzetállamok  kormányai (és nem csak globális nagyhatalmak, hanem regionális hatalmak, sőt, akár kisebb országok is) ipari méretekben kezdték felhalmozni a különböző elterjedt operációs rendszerek sérülékenységeit és készítettek ezeket a sérülékenységeket kihasználó exploit-okat, amik most már lassan menetrendszerűen kerülnek nyilvánosságra, hogy utána a legkülönbözőbb hacker-csoportok használják fel ezeket a saját céljaikra, kifejezetten aggasztó kéne hogy legyen az ICS biztonságért és a kritikus infrastruktúrákért felelős vezetők számára.

Egyelőre nem látható, hogy a WannaCry-támadásoknak hol lehet a vége és milyen hatással lehet az egyes országok (kritikus) infrastruktúráira, de úgy gondolom, hogy az ICS biztonság helyzete minden ilyen, IT biztonsági incidenssel csak tovább romlik, a megoldás pedig messzebb van tőlünk, mint korábban bármikor.

Néhány alaposabb sajtócikk a WannaCry-ról:

Kaspersky Blog
TrendMicro Blog