Még nyáron a helpnetsecurity.com-on megjelent egy 5 részes cikksorozat, aminek célja, hogy azok az IT biztonsági szakemberek, akik érdeklődnek az ICS kiberbiztonság témája iránt, megértsék azokat az alapvető különbségeket, amik nélkül egy tapasztalt IT biztonsági szakember is komoly hibákat véthet, ha ICS rendszerekkel kell dolgoznia (én már a saját bőrömön tapasztaltam ilyet...).

A cikksorozat első részében az ICS/OT világ rövid áttekintése mellett szó esik a biztonság különböző aspektusairól (security és safety) és az IT illetve OT biztonsági szempontok hierarchiájáról. Röviden áttekintésre kerül a Purdue-modell (erről korábban már én is írtam itt a blogon) és végül nagyon röviden említésre kerül néhány modern ICS biztonsági eszköz és intézkedés. A cikksorozat első része itt érhető el: https://www.helpnetsecurity.com/2018/07/13/ot-ics-landscape/

A második részben a szerző megpróbálja összegyűjteni, hogy mi motiválhatja az ICS rendszerek ellen támadást indító személyeket/cosportokat, majd a Stuxnet és az ukrán villamosenergia-rendszer elleni támadások példáján részletesebben is bemutatja, hogyan sikerült korábban többször is nagyon súlyos következményekkel járó támadásokat vezetni fontos ICS rendszerek ellen. A második részt itt lehet elolvasni: https://www.helpnetsecurity.com/2018/07/19/hackers-exploit-critical-infrastructure/

A harmadik rész nagyrészt a SCADA rendszerekkel és sérülékenységeikkel foglalkozik, egy rövid kitekintéssel az autókban használt folyamat szabályózó eszközök világába: https://www.helpnetsecurity.com/2018/07/26/scada-vulnerabilities-in-ics-architectures/

A negyedik rész tovább boncolgatja a SCADA és autókba épített vezérlő rendszerek sérülékenységeit és igyekszik néhány biztonsági alapelvet is megfogalmazni: https://www.helpnetsecurity.com/2018/07/26/scada-vulnerabilities-in-ics-architectures/

Az utolsó, ötödik részben a szerző részletesen foglalkozik az IT hálózatok felől az OT rendszerek és hálózatok felé irányuló fenyegetésekről (amik, ezt nem lehet elégszer hangsúlyozni, nem feltétlenül kell, hogy ártó szándékúak legyenek - elég arra gondolni, hogy milyen alapvető és jelentős különbségek vannak az IT és az OT közötti gondolkodásmódban és gyakorlatokban és rögtön be lehet látni, hogy az IT-ban legjobb gyakorlatként kezelt eljárások önmagukban is jelentős kockázatokat hordozhatnak az OT rendszerekre nézve, az OT-ben megszokott eljárások pedig lassúnak tűnhetnek az IT számára): https://www.helpnetsecurity.com/2018/08/02/protecting-industrial-cybersecurity/

 A blog lassan 3 éves fennállása alatt a legolvasottabb posztom az ICS rendszerekkel kapcsolatos alapfogalmakat összegyűjtő poszt volt, remélem, hogy ez a link- és cikk-gyűjtemény is sokak számára hasznos lesz.

Yokogawa rendszerek sérülékenysége

Az ICS-CERT publikációja szerint a gyártó a japán CERT-tel együttműködve hozott nyilvánosságra részleteket egy puffer túlcsordulásos hibáról, ami az alábbi termékeiket érinti:

- ASTPLANNER: R15.01 és korábbi verziók;
- iDefine for ProSafe-RS: R1.16.3 és korábbi verziók;
- STARDOM: VDS R7.50 és korábbi verziók;
- FCN/FCJ Simulator R4.20 és korábbi verziók;
- TriFellows: 5.04 és korábbi verziók.

A gyártó a hibákat az érintett rendszerek firmware-jeinek legújabb verzióiban javította. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-233-01

Sérülékenység Philips IntelliVue rendszerekben

Az ICS-CERT bejelentése alapján egy felhasználó jelentett egy sérülékenységet a Philips-nek, ami az IntelliVue Information Center iX B2 verzióját érinti.

A gyártó kockázatcsökkentő intézkedéseket dolgozott ki arra az időre, amíg 2018. szeptemberben ki tudja adni a hibát javító új verziót. 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/ICSMA-18-233-01

BD Alaris rendszerek sérülékenységei

Az ICS-CERT publikációja alapján Elad Luz, a CyberMDX munkatársa egy, a nem megfelelő authentikációból adódó sérülékenységet fedezett fel a BD alábbi egészségügyi rendszereiben:

- Alaris GS 2.3.6 és korábbi verziói;
- Alaris GH 2.3.6 és korábbi verziói;
- Alaris CC 2.3.6 és korábbi verziói;
- Alaris TIVA 2.3.6 és korábbi verziói.

A gyártó a hibával kapcsolatban kockázatcsökkentő intézkedésekre vonatkozó javaslatokat tett közzé, a hiba javításáról jelenleg nincs információ. A sérülékenység részleteiről további részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-235-01

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áltatások 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ű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A Dragos által Allanite néven emlegetett csoport az ICS rendszerek mellett üzleti/vállalati hálózatokat is célba vesz, tevékenységük során elsősorban amerikai és Nagy-britanniai szervezetek, főként villamosenergia-ipari szereplők rendszerei és hálózatai ellen folytatnak felderítő és információszerző támadásokat.

A Dragos fenyegetés-elemző szakembereinek véleménye szerint az Allanite tevékenysége az ICS rendszerek esetében két fő célt szolgál, minél jobban megérteni az ICS rendszer és a rendszer által irányított folyamatok felépítését és működését illetve birtokolni azokat a hozzáféréseket, amiket felhasználva üzemzavarokat idézhetnek elő a villamosenergia rendszerekben.

A jelenleg ismerhető adatok alapján feltételezhető, hogy az Allanite legalább 2017 májusa óta aktív és a tevékenységük erős hasonlóságot mutat a DHS által Paletto Fusion nevű, amerikai vilalmosenergia-ipari cégeket célzó támadásokkal és kapcsolatot véltek felfedezni a Symantec által Dragonfly, a Dragos által Dymalloy néven emlegetett támadókkal. A Dragos elemzése szerint bár az Allanite a célpontok kiválasztása és a használt módszerek tekintetében mutat hasonlóságokat a Dragonfly/Dymalloy csoporttal, de a technikai képességeiket jelentősen különbözőnek tartják.

Az Allanite adathalász e-mail-támadásokkal és ún. watering hole-támadásokkal próbál weboldalakat kompromittálni és bejelentkezési adatokat szerezni, amikkel utána képesek hozzáférést szerezni a célba vett hálózatokhoz, ide értve az adott szervezetek ICS rendszereiből gyűjtött képernyőképeket is. Az Allanite ilyen jellegű tevékenysége a megfigyelések alapján mostanáig csak az információszerzésre terjedt ki, nincs bizonyíték arra, hogy a csoportot bármilyen, üzemzavart okozó tevékenységhez lehetne kapcsolni.

Az Allanite jellemzően nem használ malware-eket, ezek helyett az adott rendszerekben legitimnek számító eszközöket és a Windows operációs rendszerekben megtalálható eszközöket használják fel.

A Dragos publikációját az Allanite-ról itt lehet elérni: https://www.dragos.com/blog/20180510Allanite.html

Ez az esettanulmány egy olyan, incidensről szól, amikor a BSI egy ICS rendszer vezérlőközpontjából kapott feltételezhető malware fertőzésről szóló értesítést. A bejelentések vizsgálata során fény derült arra, hogy egy ICS szervíztechnikus egy USB adathordozót csatlakoztatott az ICS rendszer egyik fejlesztői számítógépéhez. A számítógépre telepített antivírus szoftver riasztott, mert az adathordozón egy különböző Windows verziókat megfertőzni képes malwaret talált.

A BSI vizsgálata során kiderült, hogy a szervíztechnikus ugyanezt az USB adathordozót néhány nappal korábban csatlakoztatta ugyanehhez a számítógéphez, ekkor az antivírus szoftver nem riasztott, pedig mindkét alkalommal az elérhető legfrissebb vírusadatbázissal működött, az antivírus szoftver gyártója pedig már hetekkel korábban kiadta azt a vírusadatbázis frissítést, ami tartalmazta a szóban forgó malware mintját.

A szervíztechnikus és a BSI munkatársai végül megállapították, hogy a malware a technikus saját számítógépéről került az USB adathordozóra, amikor zenéket másolt rá magának. Amikor idáig jutottak a vizsgálatban, a BSI munkatársainak meg kellett határozniuk az érintett ICS rendszerek számát és biztosítaniuk kellet, hogy fertőzés nem terjed tovább.

A malware eltávolítása azonban nem bizonyult egyszerű feladatnak, mert az érintett ICS rendszer produktív számítógépein a valós idejű folyamatirányítási és szabályozó hatósági követelmények miatt nem volt antivírus megoldás telepítve, így már az is kérdéses volt, hogy a produktív rendszer számítógépei egyáltalán fertőzöttek-e?

Több megoldási lehetőség mérlegelése és elvetése után végül az antivírus szoftver gyártójának egy telepítést nem igénylő szoftverével vizsgálták meg a kérdéses számítógépeket, amelyek közül több, de nem az összes, fertőzött volt. A malware eltávolítása után folytatódott az incidens vizsgálata, ami során kiderült, hogy a hibázó technikus korábban egy fontos biztonsági intézkedést már végrehajtott az ICS rendszerben, ami kulcsfontosságúnak bizonyult abban, hogy az incidens nem lett sokkal súlyosabb, ez pedig az volt, hogy az ICS rendszer semmilyen módon nem tudott kommunikálni az Interneten, így a folyamatirányító rendszert megfertőző malware nem tudott kapcsolatba lépni azokkal a vezérlő (Command&Control, C2) szervereivel, amiken keresztül adatokat tudott volna lopni vagy további utasításokat fogadhatott volna.

Az érintett szervezet egyik munkatársa azt javasolta, hogy végezzenek malware-elemzést, ami alapján ki tudnák deríteni a fertőzés várható hatásait. Ha a folyamatirányító rendszerben egy ilyen hatást ki tudnak zárni, akkor nem szükséges eltávolítani a kártékony kódot. Ezt a lehetőséget végül a döntéshozók kizárták, mert egyrészt nem volt elég idő a malware-elemzés elvégzésére, másrészt pedig nem állt rendelkezésre olyan, megfelelően képzett, minősített és megbízhatónak tekintett vállalat, ami elvégezte volna az elemzést. Alternatív megoldásként a feltételezhetően fertőzött számítógépek újratelepítése is felmerült. Számos ok miatt (nem voltak megfelelő vészhelyzet-kezelési eljárások kidolgozva a folyamatirányító rendszer leállásának esetére, nem volt minden szoftverkomponens, konfiguráció és rendszerdokumentáció azonnal elérhető) végül ezt a lehetőséget is elvetették.

Tanulságok

- Az eset legfontosabb tanulsága, hogy az ICS rendszereket üzemeltető szervezeteknek nem szabad csupán a saját munkavállalóik biztonságtudatosságára koncentrálni, ugyanígy képezni kell a fontosabb rendszerekhez, pl. ICS rendszerekhez/berendezésekhez hozzáféréssel rendelkező külső szakértőket is;
- Kötelező és általánosan érvényes szabályokat kell bevezetni az informatikai eszközök munkahelyi és magán célú használatára vonatkozóan;
- Vészhelyzeti menedzsment-eljárásokat kell kialakítani (és ezeket rendszeresen tesztelni is kell!);
- Az ICS rendszereknél használt adathordozókat az ICS rendszer elemeihez történő csatlakoztatás előtt minden esetben egy független, naprakészre frissített antivírus megoldással rendelkező munkaállomáson kell megvizsgálni. Egy ilyen megoldás előnye, hogy az ICS rendszerben használt cserélhető adathordozók vírusellenőrzése megoldott, annak kockáztatása nélkül, hogy az antivírus szoftver az ICS rendszer egyes elemeinek sérülését okozhatják;
- Az ICS rendszer számítógépein az operációs rendszer beépített megoldásával vagy más, külső szoftveres megoldással korlátozni kell a cserélhető adathordozók használatát.

Az esettanulmány BSI által publikált eredeti (német nyelvű) változata itt érhető el.

Medtronic MyCareLink sérülékenységek

Billy Rios, Jesse Young és Jonathan Butts, a Whitescope LLC munkatársai két sérülékenységet találtak a Medtronic alábbi, betegek állapotának monitorozására használt eszközeiben:

- 24950 MyCareLink Monitor minden verziója;
- 24952 MyCareLink Monitor minden verziója.

A gyártó az egyik sérülékenység javítását már elkészítette, a másik sérülékenység javításán pedig jelenleg is dolgoznak. A sérülékenységek részletes leírását az ICS-CERT publikációja tartalmazza: https://ics-cert.us-cert.gov/advisories/ICSMA-18-219-01

Medtronic MiniMed sérülékenységek

Billy Rios, Jesse Young és Jonathan Butts, a Whitescope LLC munkatársai a Medtronic MiniMed inzulin befecskendező rendszereiben is két sérüléeknységet találtak. A hibák az alábbi modelleket érintik:

- MMT - 508 MiniMed inzuli pumpa;
- MMT - 522 / MMT - 722 Paradigm REAL-TIME;
- MMT - 523 / MMT - 723 Paradigm Revel;
- MMT - 523K / MMT - 723K Paradigm Revel;
- MMT - 551 / MMT - 751 MiniMed 530G.

A gyártó a publikált információk szerint nem készít javítást a most felfedezett hibákra. A sérüléeknységekről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-219-02

Sérülékenységek Delta Electronics rendszerekben

Mat Powell a ZDI-vel együttműködve két sérüléeknységet fedezett fel a Delta Electronics alábbi termékeiben:

CNCSoft Version 1.00.83 és korábbi verziói;
ScreenEditor Version 1.00.54.

A gyártó a hibával kapcsolatos javítás a CNCSoft esetén már elérhetővé tette. A sérülékenységek további részletei az ICS-CERT publikációjában érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-219-01

Siemens Automation License Manager sérüléeknységek

A gyártó bejelentése szerint Vladimir Dashchenko, a Kaspersky Lab munkatársa két sérülékenységet talált a Siemens Automation License Manager alábbi verzióiban:

Automation License Manager 5, minden 5.3.4.4-nél korábbi verziója;
Automation License Manager 6, minden 6.0.1-nél korábbi verziója.

A Siemens a hibáka az 5.3.4.4 illetve a 6.0.1 verziókban javította. A sérülékenységekről bővebben a Siemens ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-920962.pdf

Sérülékenységek Siemens TIA Portal-okban

A Siemens publikációja alapján Younes Dragoni, a Nozomi Networks munkatársa két sérüléeknységet azonosított az alábbi Siemens termékekben:

SIMATIC STEP 7 (TIA Portal) és WinCC (TIA Portal) V10, V11, V12 minden verziója;
SIMATIC STEP 7 (TIA Portal) és WinCC (TIA Portal) V13 minden verziója;
SIMATIC STEP 7 (TIA Portal) és WinCC (TIA Portal) V14 minden, V14 SP1 Update 6-nál korábbi verziója;
SIMATIC STEP 7 (TIA Portal) és WinCC (TIA Portal) V15 minden, V15 Update 2-nél korábbi verziója.

A sérüléeknységekkel kapcsolatban nincs hír javításról, a gyártó kockázatcsökkentő intézkedések bevezetését javasolja az érintett ügyfeleinek. A sérüléeknységek részletei a Siemens ProductCERT publikációjában találhatóak: https://cert-portal.siemens.com/productcert/pdf/ssa-979106.pdf

OpenSSL sérülékenységek Siemens ipari rendszerekben

A Siemens ProductCERT bejelentése szerint a CVE-2017-3737 számú OpenSSL sérüléeknység érinti az alábbi termékeiket:

- MindConnect IoT2040: V03.01-nál korábbi verziók;
- MindConnect Nano (IPC227D): V03.01-nál korábbi verziók;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC (OC1): V2.1-nél korábbi verziók;
- SIMATIC HMI WinCC Flexible: minden verzió;
- SIMATIC IPC DiagBase: minden verzió;
- SIMATIC IPC DiagMonitor: minden verzió;
- SIMATIC S7-1200: minden verzió;
- SIMATIC S7-1500: V2.5.2-nél korábbi verziók;
- SIMATIC S7-1500 Software Controller: minden verzió;
- SIMATIC STEP 7 (TIA Portal): V15 Update 2-nél korábbi verziók;
- SIMATIC WinCC (TIA Portal): V15 Update 2-nél korábbi verziók;
- SIMATIC WinCC OA V3.14: minden verzió;
- SIMATIC WinCC OA V3.15: minden verzió;
- SIMATIC WinCC OA V3.16: minden verzió;
- SINUMERIK Integrate Access MyMachine szervízmérnöki kliens: V4.1.7 és korábbi verziók;
- SINUMERIK Integrate operátori kliens: 2.0.11 és korábbi verziók illetve 3.0.11 és korábbi verziók.

Az érintett rendszerek közül az alábbiakhoz elérhető hibajavítás:

- MindConnect IoT2040: V03.01-nál korábbi verziók;
- MindConnect Nano (IPC227D): V03.01-nál korábbi verziók;
- SIMATIC S7-1500: V2.5.2-nél korábbi verziók;
- SIMATIC STEP 7 (TIA Portal): V15 Update 2-nél korábbi verziók;
- SIMATIC WinCC (TIA Portal): V15 Update 2-nél korábbi verziók;
- SINUMERIK Integrate Access MyMachine szervízmérnöki kliens: V4.1.7 és korábbi verziók;
- SINUMERIK Integrate operátori kliens: 2.0.11 és korábbi verziók illetve 3.0.11 és korábbi verziók.

A sérüléeknységgel kapcsolatosan bővebb információkat a Siemens ProductCERT bejelentésében lehet olvasni: https://cert-portal.siemens.com/productcert/pdf/ssa-179516.pdf

Sérülékenységek NetComm Wireless ipari routerekben

Aditya K. Sood négy sérüléeknységet fedezett fel a NetComm Wireless 4G LTE router-einek 2.0.29.11 és korábbi verzióiban.

A gyártó az eszközökhöz kiadott legújabb firmware-verzióban javította a hibákat. A sérüléeknységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-221-02

Creston rendszerek sérüléeknységei

Jackson Thuraisamy, a Security Compass munkatársa és Ricky Lawshae (alias “Fejnélküli Zeke”) több sérüléeknységet fedeztek fel a Creston alábbi rendszereiben:

- TSW-X60, 2.001.0037.001-nél korábbi firmware-verziók használata esetén;
- MC3, 1.502.0047.001-nél korábbi firmware-verziók használata esetén.

A gyártó a hibákat a legújabb elérhető firmware-verziókban javította. A sérüléeknységrőbl bővebb információk az ICS-CERT weboldalán érhetőek el: https://ics-cert.us-cert.gov/advisories/ICSA-18-221-01

Sérülékenységek Philips IntelliSpace rendszerekben

Az ICS-CERT bejelentése szerint a Philips két sérülékenységet azonosított az alábbi termékeiben:

- IntelliSpace Cardiovascular 3.1 és korábbi verziói;
- Xcelera 4.1 és korábbi verziói.

A hibákkal kapcsolatos javítást a gyártó már elérhetővé tette. A sérüléeknységgel kapcsolatos további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-226-01

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áltatások 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ű (valamilyen szinten tűzálló 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.

Néhány nappal ezelőtt én is írtam arról egy rövidebb bejegyzést, hogy a Taiwan Semiconductors több gyáregységét is le kellett állítani malware-fertőzések miatt. Időközben kiderült, hogy a fertőző malware ismét a már jól ismert, az EternalBlue sérülékenységet kihasználó WannaCry ransomware volt. Az eset ismét számos aggasztó problémára hívja fel a figyelmet:

1. A patch-elés hiánya: sokan, sokszor (néhányszor én is, itt a blogon) elmondták és leírták, hogy ICS rendszerek esetén a patch-elés nehéz és lassú folyamat, időnként pedig nem megoldható (különösen, ha a gyártó által már semmilyen szinten nem támogatott az adott ICS rendszer). Nekem ugyan nincsenek információim arról, hogy a TSMC milyen Windows verziókat használ a termelésirányító rendszereiben, de egyrészt az EternalBlue sérüléeknységet a Microsoft a tavalyi nagy WannaCry-fertőzések idején még a Windows XP/2003 operációs rendszerekhez is kiadta a javítást, másrészt, ha ezt semmiképpen nem tudják telepíteni vagy még ennél is régebbi, sérüléekny verziókat használnak, akkor sem érthető, hogy hogyan és miért nem sikerült olyan egyéb, kockázatcsökkentő intézkedéseket (hálózatszegmentálás és virtuális patch-elés, USB adathordozó kontroll, stb.) bevezetni, amivel meg lehetne előzni egy ilyen méretű incidenst?
2. Változik-e az incidens után bármi az érintett szervezet vonatkozó eljárásaiban, összegyűjtik-e és alkalmazzák-e az eset tanulságait?
3. Vajon hány további szervezetnél és ICS rendszernél lehet ugyanez a helyzet?

Sajnos van egy olyan érzésem, hogy a WannaCry-ról nem most hallottunk utoljára ICS rendszerekkel kapcsolatban.

Davolink sérülékenység

Ankit Anubhav, NewSky Security munkatársa egy sérülékenységet azonosított a Davolink DVW-3200N típusú berendezéseinek 1.00.06-nál korábbi firmware-verzióiban. A hiba lehetővé teszi a rendszerben használt algoritmussal hash-elt jelszavak visszafejtését.

A gyártó a hibát az 1.00.06-os firmware-verzióban javította. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-212-01

Sérülékenység Johnson Controls rendszerekben

Dan Regalado, a Zingbox munkatársa egy, a hibaüzenetek nem megfelelő kezeléséből adódó információszivárgás sérülékenységet jelentett az NCCIC-nek, ami a Johnson Controls alábbi rendszereit érinti:

- Metasys System, Versions 8.0 és korábbi verziók;
- BCPro (BCM) minden, 3.0.2-nél korábbi verziója.

A gyártó a hibát a Metasys v8.1-ben illetve a BCPro Workstation in BCPro v3.0 verzióiban javította. A sérülékenységgel kapcsolatosan további információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-212-02

WECON LeviStudioU sérülékenységek

Az NSFOCUS nevű biztonsági kutatókból álló csoport, Ghirmay Desta és Mat Powel két sérülékenységet találtak a WECON LeviStudioU 1.8.29 és 1.8.44-es verzióiban.

Az ICS-CERT publikációja itt elérhető publikációja szerint a legújabb LeviStudioU verzióra történő frissítés javíthatja a sérülkenységek némelyikét.

Sérülékenység AVEVA InTouch rendszerekben

A Google biztonsági csapata egy Cross-site Scripting sérülkenységet jelentett a gyártónak, ami az InTouch Access Anywhere 2017 Update 2 és korábbi verzióit érinti.

A hibát a gyártó az InTouch Access Anywhere 2017 Update 2b vagy későbbi verzióiban javította. A sérülkenység részleteit az ICS-CERT weboldalán lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-212-04

AVEVA Wonderware License Server sérülékenység

Egy névtelenségbe burkolózó biztonsági kutató egy memóriakezelési hibát jelentett az AVEVA-nak, ami a Wonderware License Server v4.0.13100 verzióit érinti, amennyiben használják az ArchestrAServer.lic funkciót. A Wonderware License Server-t az alábbi rendszerekhez szállítja az AVEVA:

- Wonderware Information Server 4.0 SP1 és korábbi verziók;
- Historian Client 2014 R4 SP2 P02 és korábbi verziók.

A hiba javítása már elérhető. A sérülkenység részleteiről az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-212-05

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áltatások 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ű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A Bloomberg által lehozott hír szerint a Taiwan Semiconductor Manufacturing Co., a világ legnagyobb chip gyártójának több gyára is leállt augusztus 3-án éjjel egy malware fertőzés miatt. A TSMC az Apple és a Qualcomm számára is gyárt chipeket és jelenleg a világ első számú gyártójának számít. A TSMC szerint a malware több, a gyártási folyamatban használt eszközt is megfertőzött. A hírek szerint a fertőzés kiterjedése az egyes gyárakban eltérő és az érintett gyárak újraindítása (a ferőzés által érintett eszközök körének meghatározása és a Malware eltávolítása után) legkorábban vasárnap történhet meg. További részletek egyelőre nem ismertek, a TSMC hétfőn, az incidens kiértékelése után ígér bővebb tájékoztatást.

Nem ez az első eset, amikor egy malware utat talál magának egy gyár termelésirányító rendszereihez, elég csak a tavalyi WannaCry-támadások idején leállt gyárak eseteire gondolni. A hasonló esetek megelőzésére nyilván nincs 100%-os módszer (a legújabb vélemények szerint már a vállalati és ICS hálózatok teljes fizikai elkülönítése sem biztosít teljes biztonságot), azonban más intézkedésekkel együtt a Purdue-modell szerinti hálózat-szeparáció és kapcsolatok kialakítása a vállalati és ICS hálózatok között nagyságrendekkel képes csökkenteni egy sikeres támadás esélyét, amikor pedig nem sikerül megelőzni az incidens bekövetkeztét, segíthet minél előbb észlelni azt.

Valamivel több, mint egy hete három, Németországban történt, ICS rendszereket érintő incidensekről szóló esettanulmányokat találtam, amiket a német Szövetségi Információbiztonsági Hivatal (Bundesamt für Sicherheit in der Informationstechnik, BSI) publikált. A mai posztban ezek közül az egyiket fogom röviden összefoglalni, a következő két hét posztjaiban pedig a másik kettőt.

Uszodai ICS rendszer kiberbiztonsága

Ahogy sok más esetben, ennél az incidensnél is a kiindulópont a talán legfontosabb ICS biztonsági szabály be nem tartása volt, az uszoda vezérlőrendszerét, amivel a víz hőmérsékletét és a vízhez adagolt klór-alapú tisztítószer mennyiségét kontrollálták, valamilyen ok miatt elérhetővé tették az Internetről is. A szóban forgó ICS rendszer emellett számos, szokásosnak nevezhető sérülékenységet hordozott, amiket kihasználva a támadók a rendszer beállításainak módosításához szükséges jogosultságot tudtak szerezni - nem is igazán nehezen.

Amikor a BSI a fentiek miatt megkereste az ICS rendszerért felelős személyeket, kommunikációs problémák is adódtak (ez az ICS kiberbiztonsági témáknál sajnos egyáltalán nem számít egyedinek, a biztonsági szakemberek és a folyamatirányításért felelős mérnökök szinte soha nem értik a másik területről érkező kollégák szempontjait és gyakran még a szakzsargon sem ugyanaz, így könnyen félreérthetik, amit a másik mondani próbál), ami oda vezetett, hogy egy, az incidensben érintett IP címet minden további egyeztetés nélkül blokkolt az ICS rendszer üzemeltetője.

A rendszerért felelős személlyel ezalatt tovább folyt az egyeztetés, aminek a részletei ismét csak azt mutatják, hogy minden téren jelentős külöbségek és hiányosságok fedezhetőek fel az ICS kiberbiztonsági témákban érintett csoportoknál (álljanak azok akár IT/információbiztonsági vagy ipari folyamatirányítási területről érkező mérnökökből - az IT biztonsági szakemberek nem igazán vagy egyáltalán nem értik az ICS rendszerek által vezérelt ipari folyamatokat, az OT mérnököknek pedig - tisztelet az igen ritka kivételeknek - szinte egyáltalán nincs fogalmuk az ICS rendszerek kiberbiztonsági kockázatairól).

Az esettanulmány legfontosabb része, hogy mit is lehet tanulni belőle:

- Az első, amit az ICS kiberbiztonság világában sokan egyre többször hangoztatnak (én is unaloming ismétlem a blogposztjaimban): az ICS rendszereknek nincs keresnivalójuk az Interneten!
- Ugyanilyen fontos, hogy az ICS rendszerekhez történő legitim hozzáféréseket nem szabad blokkolni! Az ICS rendszereket üzemeltető szervezeteknek az IT biztonsági incidenskezelési, katasztrófa-elhárítási és üzletmenet-folytonossági terveik mellett illetve azok részeként kifejezetten az ICS rendszerekre és berendezésekre vonatkozó (és rendszeresen tesztelt!) incidenkezelési eljárásokkal kell rendelkezni, hogy ne a hozzáférések teljes körű blokkolása legyen az egyetlen intézkedés, amit egy incidens során képes megtenni a szervezet.
- Külső hálózatokból történő hozzáférést (ide értve az Internetet és az adott szervezet partnereinek hálózataiból történő, akár bérelt vonalat használó) minden esetben alaposan kiértékelt üzleti igénnyel kell alátámasztani és minden ilyen esetben VPN-megoldások alkalmazásával kell megfelelően biztonságossá tenni.

Az esettanulmány BSI által publikált eredeti (német nyelvű) változata itt érhető el.

A héten több külföldi és hazai hírportál hozta le hírként, hogy a Department of Homeland Security szerint az orosz támadók számos kritikus infrastruktúrához tartozó szervezet rendszereit kompromittálták.

A DHS a héten és a jövő héten összesen négy webinart tartott/fog tartani a témában. Az első két előadás prezentációjához jelenleg nincs közvetlen hivatkozásom, de ha valakinek szüksége van rájuk, írjon és elküldöm neki. Az előadások alapján a támadók akár több száz rendszert kompromittáltak és még néhány fizikailag teljesen szeparált hálózatba is utat találtak.

A webinarok elég nagy visszhangot keltettek, ugyanakkor az eddig két prezentációban nem igazán voltak új információk, inkább csak a korábbi DHS publikációkból megismerhető információk összefoglalásának tekinthetjük. A SCADASec levelezőlistán meg is jelent egy vélemény, ami szerint ezeknek az információknak a nagy része az elmúlt években már nyilvánosságra kerültek (pl. az orosz malware-ek már 2014 októberében megjelentek az amerikai villamosenergia-rendszerben). Éppen ezért felmerül a kérdés, hogy ez a nagy port kavart bejelentésnek mi az oka és miért éppen most kellett megtenni?