Az ICS-CERT tegnapi publikációja szerint Mohammed Shameem egy cross-site scripting sérülékenységet talált a Schneider Electric homeLYnk Controller nevű termékében. A hiba a homeLYnk Controller, LSS100100, V1.5.0-nál korábbi összes verzióját érinti.
A gyártó a hibát egy most kiadott, új firmware-verzióban javította, amit innen lehet letölteni.
A sérülékenységről további információkat az ICS-CERT bejelentésében és a gyártó által kiadott tájékoztatóban lehet olvasni.
A tegnapi napon az ICS-CERT ismét két ICS gyártó termékeivel kapcsolatos sérülékenységi információkat adott közre.
Phoenix Contact mGuard sérülékenység
A Phoenix Contact munkatársai az mGuard 8.4.0 verziójú firmware-t futtató eszközein fedezett fel egy sérülékenységet. A hiba lényege, hogy a 8.4.0-es firmware-verzióra történő frissítés során a rendszerben ismét az alapértelmezett gyári jelszó kerül beállításra akkor is, ha azt korábban már (alapvető ICS kiberbiztonsági intézkedésként) megváltoztatták. A gyártó a hibát a 8.4.1-es és újabb firmware-verziókban javította és ezek használatát, illetve ha valaki korábban elvégezte a 8.4.0 verzióra történő frissítést, akkor a WebUI felületen vagy parancssorból mindenképp változtassa meg az admin felhasználó jelszavát. Ha az mGuard eszközön az SSH és/vagy a HTTPS hozzáférés be volt kapcsolva, akkor a gyártó azt javasolja, hogy flash-eljék az eszközt és cseréljék privát kulcsot és jelszót/jelmondatot.
A sérülékenységről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-336-05
Sérülékenység GE Proficy rendszerekben
A GE által a Proficy név alatt futó termékekben egy olyan hibát fedezett fel a gyártó, amit kihasználva egy sikeresen authentikált támadó hozzáférhet a rendszerben tárolt felhasználói jelszavakhoz. A sérülékenység az alábbi termékeket és verziókat érinti:
- Proficy HMI/SCADA iFIX Version 5.8 SIM 13 és korábbi verziók;
- Proficy HMI/SCADA CIMPLICITY Version 9.0 és korábbi verziók, valamint
- Proficy Historian Version 6.0 és korábbi verziók.
A gyártó mindhárom érintett szoftverhez új verziókat adott ki, amikben javította a fenti hibát:
- Proficy HMI/SCADA iFIX Version 5.8 SIM 14 (bejelentkezés után érhető el)
- Proficy HMI/SCADA CIMPLICITY Version 9.5 (A GE Digital Support képviselővel egyeztetett módon érhető el.)
- Proficy Historian Version 7.0 (A GE Digital Support képviselővel egyeztetett módon érhető el.)
A hibával kapcsolatban további részleteket az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-336-05
Az ICS-CERT a fenti sérülékenységekkel kapcsolatban ezúttal is a szokásos kockázatcsökkentő intézkedések alkalmazását javasolja:
- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- Az 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!
Tavaly év végén, a szokásos körülmények között ismét megrendezték a német Chaos Computer Club C3 (Chaos Computer Congress) konferenciáját, ahol idén is volt egy ICS kiberbiztonság témájú előadás. Ezúttal is nagyon sok előadás volt a legkülönbözőbb témakörökben (külön szekciók voltak az etikai, közösségi és politikai, a művészeti és kulturális, a kiberbiztonsági, az űrkutatási, a tudományos és a hardver-fókuszú előadásoknak).
Idén Ali Abbassi, a hollandiai Twente Egyetem Distributed and Embedded Systems Security Group PhD hallgatója és Majid Hashemi, biztonsági kutató tartottak előadást a PLC-k bemenő és kijövő adatainak módosítási lehetőségeiről.
Az előadás prezentációja és teljes felvétele is elérhető.
A tegnapi napon ismét több ICS rendszerre vonatkozóan publikált sérülékenységi információkat az ICS-CERT (illetve egy esetben ennek nyomán a ZDI).
Advantech WebAccess sérülékenységek
Az Advantech WebAccess termékeivel kapcsolatban nem először írok különböző sérülékenységekről, ezúttal a Tenable Network Security nevű cég (többek között a Nessus automatizált sérülékenységvizsgáló eszköz gyártója) fedezett fel két hibát a WebAccess 8.1-es verziójában. Az első hiba egy SQLi, a második pedig authentikáció megkerülést tesz lehetővé.
A gyártó a fenti hibák a WebAccess 8.2-es verziójában javította, amit innen lehet letölteni.
A sérülékenységekkel kapcsolatban további információkat az ICS-CERT illetve a ZDI bejelentéseiben lehet olvasni.
VideoInsight Web Client sérülékenység
A VideoInsight Web Client nevű termékében Juan Pablo Lopez Yacubian, szabadúszó argentín biztonsági szakember fedezett fel egy SQLi hibát, ami a 6.3.5.11 és ezt megelőző verziókban található meg. A gyártó a hibát a 6.3.6.11-es verzióban javította, a hibát felfedező szakember pedig tesztelte, hogy valóban javítja a hibát. A javított verzió elérhető a gyártó weboldalán: www.downloadvi.com
A hibáról további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-012-02
Sérülékenységek Carlo Gavazzi VMU-C rendszerekben
Karn Ganeshen neve szintén nem ismeretlen az ICS sérülékenységekkel foglalkozók körében, ezúttal a Carlo Gavazzi által gyártott VMU-C eszközökben fedezett fel több sérülékenységet.
A hibák a VMU-C berendezések alábbi típusait és firmware-verzióit érintik:
- VMU-C EM A11_U05-nél korábbi firmware esetén és
- VMU-C PV A17-nél korábbi firmware használata esetén.
A sérülékenységek között az első authentikáció nélkül is hozzáférést biztosít a rendszer legtöbb (de nem az összes) funkciójához. A második sérülékenység CSRF-támadást teszt lehetővé, a harmadik pedig abból adódik, hogy a rendszer egyes bizalmas információkat sima szöveges fájlokban, olvasható formában tárol.
A gyártó a hibákat a VMU-C EM berendezések esetén az A11_U05-ös, a VMU-C PV berendezéseknél az A17-es firmware-ben javította, a javított verziók elérhetőek a Carlo Gavazzi weboldalán: http://www.gavazzi-automation.com/nsc/HQ/EN/energy_efficiency_monitoring
A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-012-03
Az ICS-CERT a most publikált hibák esetén is az általánosan használható kockázatcsökkentési 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 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!
A török energiaügyi miniszter, Berat Albayrak nyilatkozata szerint részben kibertámadások okozhatták az utóbbi időkben Isztambult és több már területet érintő áramkimaradásokat. Az energiaügyi minisztérium első jelentése szerint az áramkimaradásokat a szokatlanul erős havazás okozta, azonban később az Anadolu török hírügynökség minisztériumi forrásai megerősítették, hogy az üzemzavarok oka részben kibertámadás volt. A minisztériumi forrás szerint számos betörési kísérletet észleltek a török villamosenergia-rendszerhez kapcsolódóan és az észlelt támadási kísérleteket el is hárították. Véleménye szerint ezek a támadások a török villamosenergia-rendszer elleni szabotázsakció előkészítésének jelei is lehetnek.
A hivatalos török (politikai) álláspont szerint ezek az események is a Fethullah Gülen-hez köthető mozgalom kísérletei a török állam stabilitásának aláásására, azonban egyes elismert szakértők szerint a török hatóságok a kibertámadást csak (az elmúlt időszak jelentősebb incidensei után népszerű) kifogásként emlegetik, hogy megmagyarázzák az öregedő infrastruktúra és esetleges (nem kiberbiztonsági) szabotázsakciók miatt bekövetkező üzemzavarokat.
Az ICS-CERT legújabb publikációja szerint Vint Maggs, a Savannah River Nuclear Solutions munkatársa talált hibát az OSIsoft PI Coresight és PI Web API termékeinek alábbi verzióiban:
- PI Coresight 2016 R2 és korábbi verziók;
- PI Web API 2016 R2, ha a PI AF Services 2016 R2 integrated install kit használatával történt a telepítés.
A hiba miatt a szerverek log fájljaiból minden, sikeresen authentikált felhasználó képes lehet bizalmas adatokat kinyerni. A sérülékenység sikeres kihazsnálásával egy támadó jogosulatlanul leállíthatja a sérülékeny rendszert illetve képes lehet tartományi hitelesítő adatokat használni.
A sérülékenységgel kapcsolatban a gyártó a weboldalán tett közzé kockázatcsökkentő intézkedésekre vonatkozó javaslatokat: https://techsupport.osisoft.com/Troubleshooting/Alerts/AL00312
A sérülékenységről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-010-01
A hibával kapcsolatban az ICS-CERT ismét kockázatcsökkentő intézkedések alkalmazásának 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 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!
Karácsony előtt írtam róla, hogy 2015 december után 2016-ban is volt egy komoly üzemzavar az ukrán villamosenergia-rendszer. Az S4x17 konferencián a napokban újabb információk láttak napvilágot, ezek alapján egy több bizonyíték van arra, hogy ismét kibertámadás okozta az üzemzavart, ezúttal a támadók az alállomási RTU-k vezérléséhez szereztek hozzáférést és ezeket működtetve okozták az üzemzavart.
Több híroldal is arról írt tegnap, hogy ukrán kiberbiztonsági szakértők az elmúlt hetekben végzett vizsgálatok alapján arra a következtetésre jutottak, hogy az újabb incidens mögött is orosz támadók állnak (volt, ahol egyenesen úgy fogalmaztak, hogy ugyanazok a támadók, akik a 2015-ös incidens előidézéséért voltak felelősek).
Az S4x17-en Marina Krotofil, egy ukrán származású, jelenleg a Honeywell-nél dolgozó ICS kiberbiztonsági szakértő felvetette annak a lehetőségét, hogy a támadók az ukrán villamosenergia-rendszert egyfajta tesztkörnyezetként használják és itt tesztelik a kritikus infrastruktúrák elleni támadási módszereiket. Marina egy előre rögzített videófelvételt is lejátszott, amiben egy másik ukrán kutató, Oleksii Yasynskyi több kiberbűnözői csoport együttműködéséről beszélt. Azt is megemlítették, hogy a jelek szerint ugyanezek a támadók voltak felelősek az elmúlt időszakban több értékes célpontot (pl. ukrán pénzügyi szektorban működő szervezetek, az ukrán pénzügyminisztérium és az államkincstár rendszereit) ért támadásokért.
A szakértők szerint a 2016-os incidens a 2015-ösnél is összetettebb volt, a támadók különböző csoportjai magas szinten működtek együtt az egyes részfeladatok végrehajtása során. Maga a támadás utolsó fázisa a vizsgálatok szerint 2016. december 6-tól 20-ig tartott, de az első fázis már július 14-én egy célzott adathalász e-mail elküldésével megkezdődött. Az így szerzett jogosultságokkal és legitim adminisztrátori eszközök használatával a támadók igyekeztek minél több jelszó összegyűjteni a célba vett szerverekről és munkaállomásokról, majd ezek birtokában olyan, komoly szakmai hozzáértést igénylő egyedi malware-eket készítettek, amivel a már a fontosabb rendszereket vették célba. A támadás korai fázisában használt makrovírus is komoly hozzáértést igénylő munka volt, az elemzések szerint a kód 69%-a arra szolgált, hogy minél nehezebb legyen értelmezni azt, 30%-a az utólagos elemzés nehezítését szolgálta és csak 1%-a szolgálta a célba vett rendszer kompromittálására használt malware elindítását. A malware működése során is kiemelt figyelmet fordítottak arra, hogy minél nehezebb legyen kielemezni a működését, ennek érdekében például a malware különböző memóriaterületekre írja be magát és egyszerre mindig csak azokat a részeit csomagolja ki, amelyekre a működés adott fázisában szüksége van.
Az egy évvel korábbi támadáshoz hasonlóan most is felmerült a gondolat, hogy a támadás az azt végrehajtók képességeinek demonstrálására szolgált. Marina Krotofil szerint ezt támasztja alá az is, hogy a támadásnak nem voltak hosszan tartó, drámai hatásai, pedig a támadóknak lehetőségük lett volna sokkal nagyobb üzemzavart is előidézni.
Bár a részletes elemzésekhez még több időre lesz szükség, az már most látszik, hogy a kritikus infrastruktúrák elleni kifinomult támadásoknak egyre nagyobb a kockázata és a bekövetkezési valószínűsége is folyamatosan nő. Minél jobban kéne felhasználni a még rendelkezésre álló időt minden kollégának, aki ilyen szervezetek kiberbiztonságáért felel.
Szerk: Ma hajnalban lehozta a hírt a The Register is. Normális esetben csak simán behivatkoznám a cikket a poszt végére, de ennek a cikknek a lábjegyzetében megjelent néhány olyan gondolat, ami mellett nem tudok szó nélkül elmenni. Bár az igaz, hogy az ukrán villamosenergia-rendszer elleni támadásokat minden jel szerint komoly technikai tudással és erős (szinte biztosan állami) háttérrel rendelkező profik hajtották végre, az az állítás, hogy az ipari vezérlő rendszerek nagyfokú bonyolultságuk, szabadalmaztatott és gyakran nem dokumentált protokolljaik miatt az ipari rendszerek szakértőin kívül mások számára nem érthetőek, nem jelent semmilyen védelmet. Ez a hozzáállás már 10 évvel ezelőtt sem jelentett megbízható védelmet az ICS rendszerek számára, a Stuxnet óta eltelt időszakban látott újabb és újabb incidensek, különösképpen pedig a két ukrán incidens rámutat arra, hogy egyre nagyobb a veszélye és a valószínűsége további támadásoknak.
Szintén érdekes és vitatható az az állítás, hogy a támadók számára problémás lenne az ukrán incidensek előidézése során gyűjtött tapasztalatok felhasználása az USA villamosenergia-rendszere elleni támadások során. Nyilván az ukrán és a különböző amerikai szervezetek (erőművek, rendszerirányítók, áramszolgáltatók) rendszereiben jelentős különbségek lehetnek, azonban az alkalmazott eszközök közötti eltérések csak a támadások felderítési fázisait tolja ki időben, ha képzett támadóknak elég idejük van feltérképezni a célba vett hálózatot és rendszereket, akkor a jelenlegi helyzetben lehetőségük lehet módot találni egy komoly károkkal járó üzemzavar előidézésére.
Az első és legnehezebb lépés a kritikus infrastruktúrák biztonságosabbá tételéhez vezető úton, hogy belássuk, milyen komoly kihívásokkal nézünk szembe és szakítsunk a régi beidegződésekkel és tagadás helyett nézzünk szembe a problémával.
Szerk: A SecurityWeek.com január 19-én megjelent cikkében már arról ír, hogy az Ukrenergo, az ukrán villamosipari rendszerirányító hivatalos közleményében megerősítette, hogy kibertámadás okozta a december 17-i üzemzavart.
Az ICS-CERT ma hajnalban megjelent publikációja szerint a St. Jude Medical Merlin@home nevű kommunikációs berendezésében felfedezett hiba közbeékelődéses (Man-in-the-middle) támadást teszt lehetővé. A hiba a Merlin@home 8.2.2-nél korábbi verzióiban található meg.
A Merlin@home-ot szívbeteg páciensekbe beültetett kardiológiai implantátumok ütemezett adatátviteleire és napi ellenőrzéseinek elvégzésére lehet használni.
A gyártó a hibát a Merlin@home 8.2.2-es verzióban javította. Az eszközök a St. Jude Medical tájékoztatása szerint automatikusan fogják megkapni a frissítést, amennyire azok csatlakoznak Ethernet-, WiFi-, mobil vagy vezetékes telefon-hálózatra.
Ahogy 2016. december elején, a Locus Energy berendezéseinek sérülékenysége nyomán megjelent ICS-CERT bejelentésről szóló posztban már megfogalmaztam, a különböző folyamatvezérlő eszközök publikus hálózatokra történő csatlakoztatása minden, ICS kiberbiztonsági alapelvnek ellentmond, orvosi folyamatvezérlő eszközök esetén pedig kifejezetten veszélyes lehet - a jelek szerint a gyártó nem osztja ezeket a nézeteket.
Pozitív fejlemény azonban, hogy a hibával kapcsolatban az amerikai élelmiszer és gyógyszerügyi hatóság (FDA) is kiadta a saját figyelmeztetését. Amennyire én tudom, ez egy új gyakorlat, a tavalyi év során az ICS-CERT-től már láttam orvosi rendszer sérülékenységéről szóló bejelentést, akkor még szó sem volt arról, hogy az FDA foglalkozna a problémával.
A hibával kapcsolatban további információkat a St. Jude Medical és az ICS-CERT publikációiban lehet találni.
5 nap telt el 2017-ből és máris itt vannak az első ICS rendszereket értintő sérülékenységekről szóló publikációk.
Sérülékenység Rockwell Automation Logix5000 programozható automatizálási vezérlőkben
Az ICS-CERT bejelentése szerint a gyártó egy stack-alapú puffer-túlcsordulási hibát azonosított a Logix5000 vezérlőiben, ami egyes, FRN 16.00 és későbbi firmware-verziókat futtató eszközöket érinti:
FRN 16.00:
- ControlLogix 5560-as kontrollerek (V16.020-tól V16.022-ig);
- ControlLogix L55-ös kontrollerek (V16.020-tól V16.022-ig);
- ControlLogix 5560-as redundáns kontrollerek (V16.020-tól V16.022-ig);
- GuardLogix 5560-as kontrollerek (minden verzió);
- FlexLogix L34-es kontrollerek (minden verzió);
- 1769 CompactLogix L23x-es kontrollerek (minden verzió);
- 1769 CompactLogix L3x-es kontrollerek (V16.020-tól V16.023-ig) és
- 1768 CompactLogix L4x-es kontrollerek, (V16.020-tól V16.025-ig).
FRN 17.00:
- SoftLogix 5800-as kontrollerek (minden verzió);
- ControlLogix 5560-as kontrollerek (minden verzió);
- GuardLogix 5560-as kontrollerek (minden verzió);
- 1769 CompactLogix L23x-es kontrollerek (minden verzió);
- 1769 CompactLogix L3x-es kontrollerek (minden verzió) és
- 1768 CompactLogix L4x-es kontrollerek (minden verzió).
FRN 18.00:
- SoftLogix 5800-as kontrollerek (minden verzió);
- RSLogix Emulate 5000-es kontrollerek (minden verzió);
- ControlLogix 5560-as kontrollerek (minden verzió);
- ControlLogix 5570-es kontrollerek (minden verzió);
- GuardLogix 5560-as kontrollerek (minden verzió);
- 1769 CompactLogix L23x-es kontrollerek (minden verzió);
- 1769 CompactLogix L3x-es kontrollerek (minden verzió);
- 1768 CompactLogix L4x-es kontrollerek (minden verzió) és
- 1768 Compact GuardLogix L4xS-es kontrollerek (minden verzió).
FRN 19.00:
- SoftLogix 5800-as kontrollerek (minden verzió);
- RSLogix Emulate 5000-es kontrollerek (minden verzió);
- ControlLogix 5560-as kontrollerek (minden verzió);
- ControlLogix 5570-es kontrollerek (minden verzió);
- ControlLogix 5560 redundáns kontrollerek (minden verzió);
- GuardLogix 5560-as kontrollerek (minden verzió);
- 1769 CompactLogix L23x-es kontrollerek (minden verzió);
- 1769 CompactLogix L3x-es kontrollerek (minden verzió);
- 1768 CompactLogix L4x-es kontrollerek (minden verzió) és
- 1768 Compact GuardLogix L4xS-es kontrollerek (minden verzió);
FRN 20.00:
- SoftLogix 5800-as kontrollerek (minden verzió);
- RSLogix Emulate 5000-es kontrollerek (minden verzió);
- ControlLogix 5560-as kontrollerek (V20.010-től V20.013-ig);
- ControlLogix 5570-es kontrollerek (V20.010-től V20.013-ig);
- ControlLogix 5560 redundáns kontrollerek (V20.050-től V20.055-ig);
- ControlLogix 5570 redundáns kontrollerek (V20.050-től V20.055-ig);
- GuardLogix 5560-as kontrollerek (V20.010-től V20.017-ig);
- GuardLogix 5570-es kontrollerek (V20.010-től V20.017-ig);
- 1769 CompactLogix L23x-es kontrollerek (V20.010-től V20.013-ig);
- 1769 CompactLogix L3x-es kontrollerek (V20.010-től V20.013-ig);
- 1769 CompactLogix 5370 L1 kontrollerek (V20.010-től V20.013-ig);
- 1769 CompactLogix 5370 L2 kontrollerek (V20.010-től V20.013-ig);
- 1769 CompactLogix 5370 L3 kontrollerek (V20.010-től V20.013-ig);
- 1768 CompactLogix L4x-es kontrollerek (V20.011-től V20.016-ig) és
- 1768 Compact GuardLogix L4xS-es kontrollerek (V20.011-től V20.016-ig).
FRN 21.00:
- SoftLogix 5800-as kontrollerek (minden verzió);
- RSLogix Emulate 5000-es kontrollerek (minden verzió);
- ControlLogix 5570-es kontrollerek (minden verzió);
- ControlLogix 5570 redundáns kontrollerek (minden verzió);
- GuardLogix 5570-es kontrollerek (minden verzió);
- 1769 CompactLogix 5370 L1 kontrollerek (minden verzió);
- 1769 CompactLogix 5370 L2 kontrollerek (minden verzió) és
- 1769 CompactLogix 5370 L3 kontrollerek (minden verzió).
A gyártó a FlexLogix kontrollerek kivételével az összes érintett termékhez új verziójú firmware-verziókat adott ki, amikben javította a hibát.
A Rockwell Automation minden ügyfelének azt javasolja, hogy elővigyázatosságból és a mostanihoz hasonló puffer-túlcsordulási hibák okozta kockázatok csökkentése érdekében, amikor lehetséges, hajtsák végre az alábbi intézkedéseket:
- Megfelelő hálózatbiztonsági kontrollokat (pl. tűzfalakat) kell alkalmazni annak biztosítására, hogy csak engedélyezett helyekről lehessen elérni az eszközöket;
- Az ipari zónán kívülről blokkolni kell minden hálózati forgalmat a 2222/tcp, 2222/udp illetve 44818/tcp és 44818/udp portokon;
- Amennyiben lehetséges, a kontrollereket RUN módban kell működtetni Remote RUN vagy Remote Program mód helyett és így megelőzni minden kártékony célú módosítást.
A hibával kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-343-05
Rockwell Automation MicroLogix 1100 és 1400 típusú eszközök sérülékenységek
Az ICS-CERT publikációja szerint Alexey Osipov és Ilya Karpov, a Positive Technologies munkatársai több hibát is azonosítottak az Allen-Bradley MicroLogix 1100-as vezérlők alábbi verzióiban:
- 1763-L16AWA, A és B sorozatú eszközök, amik a 14.000 és korábbi firmware-verziókat használják;
- 1763-L16BBB, A és B sorozatú eszközök, amik a 14.000 és korábbi firmware-verziókat használják;
- 1763-L16BWA, A és B sorozatú eszközök, amik a 14.000 és korábbi firmware-verziókat használják és
- 1763-L16DWD, A és B sorozatú eszközök, amik a 14.000 és korábbi firmware-verziókat használják.
Ugyancsak érintettek az 1400-as vezérlők alábbi verziói:
- 1766-L32AWA, A és B sorozatú eszközök, amik a 15.004 és korábbi firmware-verziókat használják;
- 1766-L32BWA, A és B sorozatú eszközök, amik a 15.004 és korábbi firmware-verziókat használják;
- 1766-L32BWAA, A és B sorozatú eszközök, amik a 15.004 és korábbi firmware-verziókat használják;
- 1766-L32BXB, A és B sorozatú eszközök, amik a 15.004 és korábbi firmware-verziókat használják;
- 1766-L32BXBA, A és B sorozatú eszközök, amik a 15.004 és korábbi firmware-verziókat használják és
- 1766-L32AWAA, A és B sorozatú eszközök, amik a 15.004 és korábbi firmware-verziókat használják.
A hibák között érzékeny információk olvasható formában történő továbbítása és adminisztrátori funkciók nem megfelelő kezelését lehetővé tévő hiba található.
A gyártó a hibákat az alábbi, új firmware-verziókban javította:
- 15.000 a MicroLogix 1100 B sorozatú eszközök esetében és
- 16.000 a MicroLogix 1400 B sorozatú eszközök számára.
A MicroLogix 1100 és 1400 típusú eszközök A sorozataihoz a firmware-verziók esetén a gyártó a hibát már nem javítja. Azoknak az ügyfeleknek, akik még A sorozatú berendezéseket használnak, a gyártó azt javasolja, hogy ha megtehetik, tiltsák le a webszerver működését. Ez az intézkedés megfelelő védelmet jelent a most felfedezett hibák kihasználása ellen.
A sérülékenységekről bővebb információt az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-336-06
A fenti hibákkal kapcsolatban az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedések alkalmazását javasolja:
- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel;
- Az 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!
December 30-án (Európában már 31-én) a Washington Post weboldalán megjelent egy cikk, amiben azt állították, hogy orosz támadók betörtek a Vermont állambeli Burlington Electric Department rendszereibe és malware-t telepítettek legalább egy számítógépre. Másnap a WP helyesbítést tett közzé, amely szerint mostanáig nincsenek arra utaló jelek, hogy valóban kompromittálták volna a Berlington Electric rendszerét, a malware-t pedig egy, a villamosenergia-rendszerhez nem csatlakoztatott számítógépen, egy notebook-on találták. A hírt (már a WP helyesbítése után, január 2-án) lehozta az itcafe.hu is, korrekt módon feldolgozva a rendelkezésükre álló információkat. Úgy döntöttem, hogy egy kicsit én is körbejárom a hírt.
A WP cikkéhez mindenképp fontos tudni, hogy a DHS és a US-CERT december 29-én jelentette meg a GRIZZLY STEPPE címmel ellátott, orosz ártó szándékú kibertér-műveletekre figyelmeztető publikációját. (A GRIZZLY STEPPE-pel kapcsolatban egy igen részletes, negatív és pozitív meglátásokat egyaránt tartalmazó kritika olvasható Robert M. Lee blogján.) Ismerve az elmúlt év utolsó néhány hetének kiberbiztonsággal kapcsolatos híreit az USA-ból, egyáltalán nem meglepő (bár nem is örvendetes), hogy a jelek szerint vannak, akik a fenyegetések mostanáig történt alábecslése után hirtelen mindenhol orosz hackereket vélnek felfedezni. Az eddig rendelkezésünkre álló információk szerint ez az eset valóban nem egy ICS kiberbiztonsági incidens, azonban néhány dolgot nem árt leszögezni (és hozzá kell tenni, hogy annak ellenére, hogy mint a blogon leírtak általában, az alábbiak is az én személyes, szakmai véleményem, ugyanezt gondolja több ismerősöm is, akiknek átfogó és alapos ismereteik vannak az USA villammosenergia-rendszerének ICS kiberbiztonságával kapcsolatban).
1. Feltételezhetően orosz támadók korábban bizonyítottan juttattak be malware-t az amerikai villamosenergia-hálózatba. Ezzel kapcsolatban érdemes elolvasni a DHS által kiadott, 2015 júniusi ICS-CERT Monitor-t. Ebben ismételten felhívták az ICS rendszereket üzemeltetők figyelmét arra, hogy kiemelten fontos az ICS rendszerek Internet-kapcsolatát megszüntetni - hivatkozva a BlackEnergy malware-rel amerikai kritikus infrastruktúrák ellen elkövetett támadásokra (a BlackEnergy egyik variánsát használták - feltételezések szerint orosz - támadók az ukrán áramszolgáltatók elleni, 2015. decemberi támadások során is).
2. Vannak olyan vélemények, amelyek szerint az európai (és más fejlettebb országok) kritikus infrastruktúráiban használt ICS rendszereihez már ma is hozzáféréssel rendelkeznek különböző külföldi, állami támogatással rendelkező támadók és a nukleáris fegyverek világából ismert MAD (Mutually Assured Destruction - kölcsönösen biztosított megsemmisítés) elve alapján egyelőre senki nem indított elsőként támadást egy másik ország ellen, tudva, hogy a saját rendszereit ő sem lesz képes megvédeni egy hasonló támadástól.
A Burlington Electric incidenssel kapcsolatban jelenleg több a kérdés, mint a biztos válasz. Nincs publikusan elérhető információ arról, hogy milyen malware-t találtak a fertőzött notebook-on és azt sem lehet tudni, mikor történt a fertőzés. Nem tudjuk, hogy a fertőzött számítógépet milyen feladatokra használták, a pontosított hírek szerint "az erőművet vezérlő hálózatra nem csatlakoztatott" eszközről van szó. Annyi minden esetre jól látszik, hogy az ICS rendszerekkel illetve a kritikus infrastruktúrákkal kapcsolatos kiberbiztonsági incidensek száma egyre gyorsabban növekszik. A kérdés már csak az, mikor történik a következő komoly incidens és mit fogunk tenni annak érdekében, hogy megelőzzük vagy legalább képesek legyünk csökkenteni a károkat, amiket okozni fog?