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?

Sérülékenységek Universal Robots rendszerekben

A Milánói Műszaki Egyetem és a TrendMicro munkatársai két sérülékenységet azonosítottak a Universal Robots CB 3.1, SW 3.4.5-100 verziójú, robotok vezérlésére használt szoftverében. A gyártó a sérülékenységekkel kapcsolatban kockázatcsökkentő intézkedéseket javasol, hibajavításról jelenleg nincs információ. A sérülékenységekről további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-191-01

Schweitzer Engineering Laboratories rendszerek sérülékenységei

Gjoko Krstic, az Applied Risk munkatársa három sérülékenységet azonosított a Schweitzer Engineering alábbi termékeiben:

- Compass Version 3.0.5.1 és korábbi verziói;
- AcSELerator Architect Version 2.2.24.0 és korábbi verziói.

A gyártó a hibákat a SEL Compass v3.0.6.1 és későbbi verzióiban illetve a SEL AcSELerator v2.2.29.0 és későbbi verzióiban javította.

A sérülékenységek részleteit az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-191-02

Sérülékenység Eaton rendszerekben

Ghirmay Desta a TrendMicro ZDI-vel együttműködve egy sérülékenységet talált az Eaton 9000X Drive 2.0.29 és korábbi verzióiban.

A gyártó a hibát egy frissítéssel javította, ami már elérhető a weboldalán.

A sérülékenységgel kapcsolatosan bővebb információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-193-01

Sérülékenység PEPPERL+FUCHS rendszerekben

Eyal Karni, Yaron Zinar és Roman Blachman, a Preempt Research Labs munkatársai, egy, a nem megfelelő authetnikációból adódó sérülékenységet fedeztek fel a PEPPERL+FUCHS alábbi rendszereiben:

- VisuNet RM, minden modell;
- VisuNet PC, minden modell;
- BTC, minden modell.

A gyártó a hibával kapcsolatos javításokat már minden érintett modellhez elérhetővé tette. A sérülékenységgel kapcsolatos további információkat az ICS-CERT weboldalán lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-18-198-03

WAGO e!DISPLAY sérülékenységek

T. Weber, a SEC Consult munkatársa 3 sérülékenységet azonosított a WAGO e!DISPLAY HMI-ainak alábbi típusainak FW 01 firmware-jében:

- 762-3000;
- 762-3001;
- 762-3002;
- 762-3003.

A gyártó a hibákat az FW 02 firmware-verzióban javította. A sérülékenység részleteit az ICS-CERT publikációjában lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-198-02

ABB Panel Builder sérülékenység

Michael DePlante, a Leahy Center és Michael Flanders, a Trend Micro munkatársai egy eddig ismeretlen sérülékenységet találtak, ami az ABB Panel Builder 800 minden verzióját érinti.

A gyártó jelenleg is vizsgálja a ZDI által neki jelentett hibát és amíg a javítást tartalmazó új verzió kiadásra kerül, kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységről bővebben az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-198-01

Sérülékenység Moxa NPort berendezésekben

Mikael Vingaard egy sérülékenységet jelentett az NCCIC-nek, ami a Moxa NPort 5210, 5230 és 5232 típusú soros-Ethernet interfészeinek 2.9-es (17030709-es build) és korábbi verzióit érinti.

A gyártó a hibát az NPort eszközök legújabb firmware-verziójában javította. 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-18-200-04

Sérülékenységek Echelon rendszerekben

Daniel Crowley és IBM X-Force Red csapat 4 sérülékenységet azonosítottak az Echelon alábbi rendszereiben:

- SmartServer 1 minden verziója;
- SmartServer 2 minden 4.11.007-esnél korábbi verziói;
- i.LON 100 all minden verziója;
- i.LON 600 minden verziója.

A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-200-03

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

George Lashenko, a CyberX munkatársa egy sérülékenységet talált az AVEVA alábbi rendszereiben:

- InTouch 2014 R2 SP1 és korábbi verziói;
- InTouch 2017;
- InTouch 2017 Update 1;
- InTouch 2017 Update 2.

A sérülékenységről részletesebb információkat az ICS-CERT weboldalán lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-200-02

AVEVA rendszerek sérülékenységei

A Tenable Research munkatársai egy sérülékenységet fedeztek fel az AVEVA alábbi termékeiben:

- InduSoft Web Studio v8.1 és v8.1SP1;
- InTouch Machine Edition v2017 8.1 és v2017 8.1 SP1.

A sérülékenységgel kapcsolatosan részleteket az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-18-200-01

Sérülékenységek Siemens rendszerekben

A Siemens ProductCERT bejelentése szerint két sérülékenységet azonosítottak az alábbi Siemens termékekben, amik a kihasználásával DoS-támadást lehet indítani az érintett berendezések ellen:

- IEC 61850 protokollhoz használható EN100 Ethernet modulok V4.33-nál korábbi firmware-verziói;
- PROFINET IO protokollhoz használható EN100 Ethernet modulok minden verziója;
- Modbus/TCP protokollhoz használható EN100 Ethernet modulok minden verziója;
- DNP3/TCP protokollhoz használható EN100 Ethernet modulok minden verziója;
- IEC 104 protokollhoz használható EN100 Ethernet modulok minden verziója;
- CP 300-as vagy CP100-as CPU-val szerelt SIPROTEC 5 berendezések V7.80-nál korábbi firmware-verziók;
- CP 200-as CPU-val szerelt SIPROTEC 5 berendezések minden verziója.

A sérülékenységek részleteit a Siemens ProductCERT bejelentésében lehet megtalálni: https://cert-portal.siemens.com/productcert/pdf/ssa-635129.pdf

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.

Robert M. Lee napjaink talán egyik legfelkészültebb szakembere, aki az ICS rendszerek fenyegetéseinek elemzésével kapcsolatban előadásokat tart. Túl azon, hogy rendszeresen lehet különböző ICS biztonsági konferenciákon találkozni vele, Ő írta a SANS Institute ICS515: ICS Active Defense and Incident Response című tanfolyamának teljes tanfolyami anyagát is.

Néhány héttel ezelőtt egy, az idei ICS Security Summit-on tartott előadásának teljes felvétele került fel a YouTube-ra.

A 45 perces előadásban részletesen szóba kerülnek a 2017-es évben megismert, ICS rendszereket célzó fenyegetések - és ilyenekben a tavalyi év kifejezetten gazdag volt.

Az ICS Threat Intelligence egy meglehetősen összetett és nehéz téma, ennek ellenére én mindenkinek ajánlani tudom, akiknek feladata a különböző ipari vezérlőrendszerek biztonságának szavatolása.

Az Ukrán Biztonsági Szolgálat (SBU) a héten tett közzé adatokat arról, hogy VPNFilter malware-t felhasználva támadást intéztek Dnyepropetrovszk közelében található Auly-i víztisztító alállomás ellen. A hírek szerint a támadók hozzáfértek a folyamatirányító és az SIS (safety) rendszerekhez is, de az SBU gyorsan észlelte a támadást és képesek voltak elhárítani azt.

Ezeknek a híreknek a tükrében már kevésbé meglepő az az információ, hogy miért keresett egy SOHO-eszközöket célzó malware Modbus/TCP protokollt a hálózati forgalmakban.

Az incidensről egyelőre kevés konkrétumot lehet tudni, meglepő módon az Index.hu hírportál ebben az esetben előbb hozta le a hírt, mint a szakmai hírportálok világszerte.

Amint újabb részletek kerülnek nyilvánosságra, frissíteni fogom a posztot.

Rockwell Automation Allen-Bradley Stratix sérülékenységek

A gyártó 5 különböző sérülékenység részleteiről számolt be az ICS-CERT-nek, amik az alábbi, Cisco ASA-alapú ipari tűzfalaikat érintik:

- 1783-SAD4T0SBK9
- 1783-SAD4T0SPK9
- 1783-SAD2T2SBK9
- 1783-SAD2T2SPK9

A gyártó a hibák javítását tartalmazó frissítésen jelenleg is dolgozik. 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-18-184-01

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.

Alig egy hónapja írtam a Xenotime néven hivatkozott és többek között a (feltételezések szerint) szaúdi ipari létesítmény SIS (safety) rendszere elleni támadásért is felelősség tehető támadókról szóló Dragos elemzésről, nemrég pedig egy újabb publikációt adtak ki, ezúttal az általuk Dymalloy-nak nevezett csoportról.

A Dymalloy csoport tevékenysége bizonyíthatóan 2015-ig nyúlik vissza, de egyes jelek szerint már 2011-ben is aktívak lehettek. A támadók hagyományosnak tekinthető eszközökkel, célzott adathalászattal és ún. watering-hole támadásokkal juttatnak be malware-eket ipari létesítményekhez köthető weboldalakra, így próbálnak felhasználói adatokat szerezni, amikkel további hozzáférésekhez juthatnak.

A Dymalloy olyan malware-eket használ, mint például a Goodor, a DorShel vagy a Karagany. Ezek olyan, megvásárolható malware-ek, amik nem köthetőek kizárólag egyetlen támadói csoporthoz, így együtt használva viszont egyedi jellemzője a Dymalloy csoportnak, ugyanakkor kerülik az egyedi eszközök és malware-ek használatát, ami nehezíti a tevékenységük pontos azonosítását.

A Dragos elemzése szerint a Dymalloy használja a Mimikatz nevű nyílt forrású szoftvert, amivel Windows-alapú rendszerek memóriájából lehet felhasználói jelszavakat kinyerni. Ugyancsak a Dragos elemzői szerint a Dymalloy és a Symantec által Dragonfly-nak nevezett, 2011 és 2014 között megfigyelt ICS rendszerek elleni támadások között lehet kapcsolat.

Ahogy azt már sokan elmondták, a különböző támadókat és támadói csoportokat nagyon nehéz, már-már lehetetlen a jellemzőik alapján azonosítani, azonban az ehhez hasonló elemzések segíthetnek jobban megérteni azokat a támadókat, akiknek a különböző ICS rendszerek kompromittálása lehet a célja, így mindenképp hasznosnak tartom az ilyen anyagokat mindazok számára, akik ICS rendszerekkel dolgoznak, különösen, ha feladataik között az ipari rendszerek biztonságos működése is megjelenik.

Sérülékenységek Medtronic MyCareLink Patient Monitor berendezésekben

Peter Morgan, a Clever Security munkatársa 2 sérülékenységet azonosított a Medtronic alábbi berendeseiben:

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

A gyártó a hibákat három frissítésben fogja javítani, arról viszont jelenleg nincs információ, hogy a javítások mikor lesznek elérhetőek. A sérülékenységekről bővebb információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSMA-18-179-01

Siemens SICLOCK rendszerek sérülékenységei

A Siemens ProductCERT tegnap 6 különböző sérülékenységről publikált részleteket, amik a Siemens SICLOCK TC100 és TC400 típusú ipari óráinak minden verzióját érintik.

A hibák között DoS-támadást, authentikáció-megkerülést, jogosulatlan firmwar-módosítást lehetővé tevő hiba és jelszavak olvasható formában történő tárolása is van.

A hibákkal kapcsolatban a Siemens ProductCERT kiadványa nem szól hibajavításról, de több javaslatot tesz kockázatcsökkentő intézkedésekre.

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.