A SecurityAffairs.co cikke szerint az amerikai energiaügyi minisztérium (DoE) az első olyan gyakorlat szervezéséhez kezdett hozzá, aminek a forgatókönyve szerint az USA villamosenergia-rendszerét ért kibertámadás utáni, teljes leállást okozó üzemzavart kell elhárítaniuk a résztvevőknek. A hírek szerint a Liberty Eclipse névre keresztelt gyakorlat egy hetes lesz és a New York közelében található Plum szigetén kerül megrendezésre. A gyakorlat célja egyértelmű, a DoE igyekszik felkészíteni az amerikai villamosenergia-szektor szereplőit a súlyos incidensek minél hatékonyabb elhárítására. A kérdés igazán az, hogy Európában és (ami számunkra még fontosabb, Magyarországon) a döntéshozók mikor fogják elég nagynak ítélni a kockázatokat, hogy hasonló, teljes szektorokat felölelő gyakorlatokat szervezzenek?

A Liberty Eclipse-ről bővebben a securityaffairs.co és az E&E News weboldalain lehet olvasni.

Opto22 rendszerek sérülékenysége

Robert Hawes egy sérülékenységet fedezett fel az Opto22 alábbi rendszereiben:

- PAC Control Basic Versions R10.0a és korábbi verziók;
- PAC Control Professional Versions R10.0a és korábbi verziók.

A gyártó a hibát a legújabb verzióban javította. A sérülékenységgel kapcsolatban bővebb információkat az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-247-01

Sérülékenységek Ice Qube rendszerekben

Maxim Rupp két sérülékenységet talált az Ice Qube Thermal Management Center rendszerének 4.13-nál korábbi verzióiban.

A gyártó a hibákat a Thermal Management Center 4.13-as és ennél újabb verzióiban javította. A sérülékenységekről további részleteket az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-249-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.

A Pen Test Partners nevű IT biztonsági cég kutatói 20 különböző, tengerjáró hajók vezérléséhez használt OT rendszert vizsgáltak és számos olyan hibát találtak, amiket kihasználva támadók hozzáférhetnek többek között a motorok, ballaszt szivattyúk vezérlő rendszereihez és a hajók esetén általánosan használt ECDIS (Electronic Chart Display and Information System) rendszerekhez is.

A feltárt sérülékenységek között számos olyan, súlyos hiba is van, ami az ICS kiberbiztonsággal foglalkozó szakemberek számára nem számítanak újdonságnak (pl. a rendszerek adminisztrátori felületeinek Telnet-en vagy HTTP-n keresztüli elérése), a hajók vezérlőrendszerei esetén azonban mostanáig senki nem mérte fel a kockázatokat.

A Pen Test Partners kutatásairól részletesebben itt lehet olvasni: https://www.pentestpartners.com/security-blog/hacking-tracking-stealing-and-sinking-ships/

Qualcomm Life Capsule DTS sérülékenység

Elad Luz, a CyberMDX munkatársa egy távoli kódfuttatást lehetővé tevő hibát jelentett az NCCIC-nek, ami a Qualcomm Life Capsule Datacaptor Terminal Server (DTS) termékének egyik komponensét, az Allegro RomPager beágyazott webszerver 4.01-4.34-es verzióit érinti.

A gyártó kiadott egy új firmware verziót, ami csökkenti a sérülékenység okozta kockázatokat. A sérülékenység részleteiről az ICS-CERT bejelentésében lehet bővebben olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-240-01

Sérülékenységek Schneider Electric PLC-kben

Az ICS-CERT két bejelentést is megjelentetett, amikben a Schneider Electric által gyártott ModiCon M221 PLC-k sérülékenységeiről adnak tájékoztatást.

Az első bejelentésben ismertetett sérülékenységeket a New Orleans-i egyetem munkatársai, Irfan Ahmed, Hyunguk Yoo, Sushma Kalle és Nehal Ameen fedezték fel és a ModiCon M221 minden, 1.6.2.0-nál korábbi firmware verzióit érintik.

A gyártó a hibákat az 1.6.2.0 firmware verzióban javította. További részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-01

A másik, sérülékenységről szóló bejelentésben szereplő hiba szintén a a ModiCon M221 minden, 1.6.2.0-nál korábbi firmware verzióit érinti. A hibát a gyártó ebben az esetben is az 1.6.2.0 verzióban javította. Ennek a sérülékenységnek a részleteit ebben a publikációban lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-02

Sérülékenység Schneider Electric PowerLogic rendszerekben

A Schneider Electric, Ezequiel Fernandez-zel és Bertin Jose-val együttműködve egy Cross-Site Scripting sérülékenységet azonosított a PowerLogic PM5560 2.5.4-nél korábbi firmware verzióiban.

A gyártó a hibát a 2.5.4-es verzióban javította. A sérülékenységről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-03

ABB eSOMS sérülékenység

Az ABB egy nem megfelelő authentikációból adódó sérülékenységet jelentett az NCCIC-nek. A hiba az eSOMS 6.0.2-es verzióját érinti.

A gyártó a hibát tervei szerint a szeptember végén publikálásra kerülő új eSOMS verzióban fogja javítani, addig is kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további részleteket illetve az ABB kockázatcsökkentő javaslatait az ICS-CERT weboldalán lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-240-04

Sérülékenységek Philips rendszerekben

A gyártó 9 különböző sérülékenységet jelentett az NCCIC-nek, amik a Philips e-Alert rendszerének R2.1 és korábbi verzióit érintik.

A hibák közül négyet a júniusban megjelent R2.1 már javította, a maradék öt sérülékenység javítását a gyártó 2018 végére igéri. A sérülékenységekről további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-242-01

Lehetséges malware-fertőzött USB adathordozók Schneider Electric rendszerekhez kapcsolódóan

A gyártó bejelentése szerint lehetséges, hogy az alábbi rendszereihez kapcsolódó USB adathordozók közül néhány malware-fertőzött lehet:

- Conext Combox (sku 865-1058) és
- Conext Battery Monitor (sku 865-1080-01) termékekkel érkező USB adathordozók.

Az USB adathordozókon rendszerdokumentációk és a rendszerek működéséhez nem nélkülözhetetlen szoftverkomponensek találhatók. A gyártó ajánlása az esettel kapcsolatban az érintett USB adathordozók törlése. A szükséges rendszerdokumentációkat és szoftvereket az ügyfelek a Schneider Electric weboldaláról is le tudják tölteni.

Az esettel kapcsolatosan bővebb infomációkat a Schneider Electric weboldalán lehet találni.

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.

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.