Ipari és folyamatirányítási informatikai rendszerek biztonságáról magyarul.

ICS Cyber Security blog

ICS Cyber Security blog

Kibertámadás a török áramkimaradások hátterében?

2017. január 12. - icscybersec

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.

ICS sérülékenységek LXXXI

OSIsoft PI termékek sérülékenységei

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!

Újabb részletek a december 17-i ukrán áramszünetről

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.

ICS sérülékenységek LXXX

St. Jude Medical orvosi berendezés sérülékenysége

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.




ICS sérülékenységek LXXIX

Sérülékenységek Rockwell Automation rendszerekben

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!

A Burlington Electric elleni malware támadás margójára

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?

ICS kiberbiztonsági tanfolyamok és minősítések II

SANS ICS410: ICS/SCADA Security Essentials

A SANS amerikai székhelyű képzőközpont nem először kerül szóba a blogon, többször hivatkoztam már cikkeket az ICS kiberbiztonsággal foglalkozó blogjukról, most pedig az ICS biztonsággal kapcsolatos képzéseik közül a belépő szintű tanfolyamot mutatom be röviden.

A SANS nem csak ICS témakörben tart tanfolyamokat, fejlesztőknek, általános IT biztonsággal foglalkozó szakembereknek és az IT menedzsmentben dolgozóknak is számos képzésük van, a teljesen kezdőktől a haladó szintig mindenki találhat a saját tudásához mérten újat mutató tanfolyamot - ennek azonban ára van, a SANS képzései jellemzően több ezer amerikai dollárért vagy euróért érhetőek el. Földrajzilag nagyon változatos helyeken tartják a képzéseket, a nagyobb érdeklődésre számot tartó képzések közül időnként egyet-kettőt még Budapestre is elhoznak, de a specializáltabbakért (ilyenek többek között az ICS-specifikus tanfolyamok is) bizony utazni kell - jobb esetben csak Nyugat-Európába (esetleg a Közel-Keletre), de vannak bizony olyan tanfolyamok, amikért az USA-ba kell menni.

Az ICS410 egy 5 napos képzés. Mint a SANS 400-as sorozatú tanfolyamai, ez is a belépő szint az adott témakörbe (a most következő leírás a 2016 végi állapotot mutatja be, mivel a képzést folyamatosan próbálják igazítani az ICS biztonság egyre gyorsabban változó világához, az idő múlásával egyre komolyabb eltérések is lehetnek).

Első nap

Lévén belépő szintű képzés, az ICS410 azzal kezdődik, hogy az első napon, az ICS rendszerek alapjainak ismertetésével megpróbálnak minden résztvevőnek egy szilárd alapot adni. Mivel ennek a tanfolyamnak az anyagából építkezik a GICSP minősítéshez (amiről korábban már itt írtam) tartozó vizsga is, ezért az első előadás a GICSP-ről szól. A folytatásban ismertetésre kerülnek az ICS rendszerek által vezérelt folyamatok és azok az iparágak, ahol ilyen rendszereket használnak, majd a legjellemzőbb eszközökről is szó esik, amelyek a hagyományos operációs rendszerekkel szemben valamilyen valós idejű OS-t futtatnak.

Ezután a PLC-k bemutatása következik, majd egy-egy Velocio PLC-n a PLC programozásba is egy futó betekintést kapnak a tanfolyam résztvevői és ki is próbálhatják, hogy nekik ez mennyire megy.

A következő előadásban a SCADA rendszerek felügyeleti komponenseinek bemutatása történik, külön tárgyalva a DCS-ek és SCADA-k közötti különbségeket.

Ezután az HMI programozást is érinti a tanfolyam résztvevői, a korábban programozott PLC által vezérelt folyamatot lehet egy (akár interaktívvá tehető) felületen megjeleníteni - merthogy ennek a Velocio PLC-nek nincs webes felülete, csak a beépített LED-eken lehet követni a működést, ha nem készítünk hozzá HMI-t.

A következő fejezetben az IT és az ICS közötti különbségeket mutatják be, majd az ICS rendszerek fizikai biztonságát is érinti a tanfolyam.

A nap utolsó fejezetében az ICS hálózatok tervezési alapelveivel ismertetik meg a résztvevőket, ehhez a Purdue referencia architektúra modellt használják (amiről szintén írtam már korábban).

Második nap

A második nap az ICS kiberbiztonságot a támadók szempontjából vizsgálja a képzés. Az első blokkban az ICS rendszerekkel kapcsolatos adatok megszerzésének lehetőségeit mutatják be, egyaránt használva szoftveres (Nmap) és Internetes (Shodan, Google) eszközöket. A továbbiakban az általános IT biztonsági (social enginnering, adathalászat, malware-ek, stb.) és ICS specifikus (ICS malware-ek, mint a Stuxnet/Duqu/Flamer malware-család, a Havex/Dragonfly vagy a Blackenergy-család, az HMI-ok és egyéb ICS komponensek elleni) fenyegetések bemutatása után a gyakorlatban is ki lehet próbálni olyan, az IT biztonságban már mindennaposnak számító támadásokat, mint a webes alkalmazások elleni különböző támadások (password fuzzing, SQL injection, stb.).

Ezután az ICS rendszerek szerveri elleni támadási lehetőségek áttekintése következik, majd az ICS rendszerek hálózati kommunikációja elleni támadások bemutatásával folytatják. Ennek a blokknak a végén ismét egy labor keretében lehet próbát tenni a Modbus kommunikáció módosításával, a nap végén pedig az ICS eszközök firmware-jeinek módosításával is megismerkednek a tanfolyam résztvevői.

Harmadik nap

A tanfolyam harmadik napja az ICS rendszerek munkaállomásain és szerverein használt operációs rendszereket mutatja be részletesebben. Ennek során a Windows-, Linux-, Unix-alapú operációs rendszerek ugyanúgy terítékre kerülnek, mint a mainframe rendszerek. Szóba kerülnek az egyes operációs rendszerek központi menedzsmentjének lehetőségei, a hardening során alkalmazható megoldások, az automatizáláshoz használható scirpt-nyelvek bemutatása mellett Windows Powershell gyakorlat és a Bastille Linux-szal történő ismerkedés is része ennek a napnak. Ezek mellett szó esik a tűzfalakról, a naplózásról és a különböző ICS adatbázisokról is.

Negyedik nap

A negyedik nap az ICS rendszerek hálózatairól szól, az Ethernet hálózatok és a TCP/IP protokoll bemutatása után a tanfolyam rátér a TCP/IP-alapú ICS-specifikus protokollok bemutatására - ehhez egy Modbus/TCP capture fájl szolgál alapul a gyakorlat során.

Ezután a Purdue-modellben az első napon már bemutatott zónák közötti forgalomellenőrzéshez használható eszközök (tűzfalak, egyirányú átjárók vagy más néven adat diódák) rövid ismertetése következik, majd az előadás áttér a honeypot-ok ICS rendszerekben történő alkalmazására.

A következő nagyobb blokk az ICS rendszerek esetén használt különböző vezeték nélküli kommunikációs protokollok (műholdas, Bluetooth, WiFi, stb.) és a hozzájuk kapcsolódó védelmi megoldások bemutatására koncentrál, ehhez a témához megint tartozik egy hálózati csomagok elemzésére épülő gyakorlat.

A nap utolsó részében az ICS rendszerek leginkább speciális eszközeivel (terepi/üzemi berendezések) és a hálózati titkosítás alapjaival ismertetik meg a tanfolyam hallgatóit.

Ötödik nap

A tanfolyam utolsó napja az ICS kiberbiztonság irányításával foglalkozik és ennek megfelelően az adatok osztályozásának ismertetésével kezdődik (ez egyébként egy érdekes része a tanfolyamnak, mert ahogy az első nap az IT és ICS közötti különbségek között elhangzott, az IT főleg az adatokra, az ICS pedig a folyamatokra koncentrál és a tanfolyam tematikája a folyamatok osztályozásáról nem beszél),  majd a mélységi védelem kialakításának fontosságát hangsúlyozzák.

Ezután a biztonsági szabályok, majd a üzletmenet-folytonosság tervezése, valamint a kockázatértékelés és az auditálás részleteit ismerteti a képzés.

A meglehetősen hosszú elméleti blokk után az első gyakorlat a támadási fa-elemzését gyakoroltatja a tanfolyam résztvevőivel, majd ezután a jelszavak és a különböző kiberbiztonsági incidensek kezelésének lehetőségeit ismertetik. Az incidenskezelés a témája a következő gyakorlati foglalkozásnak is. A képzés a legfontosabb amerikai és európai ICS kiberbiztonsággal foglalkozó szervezetek és információforrások ismertetésével zárul.

ICS sérülékenységek LXXVIII

Sérülékenységek Fidelix és WAGO ICS termékekben

Fidelix FX-20 sérülékenység

Semen Rozhkov, a Kaspersky Lab munkatársa egy könyvtár bejárásos sérülékenységet talált a Fidelix FX-20-as sorozatú épületautomatilázásban használt vezérlőiben. A hiba 11.50.19-nél régebbi verziókat érinti.

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

További részleteket a hibáról az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-357-01

WAGO Ethernet web-alapú menedzsment rendszer sérülékenységek

Maxim Rupp független biztonsági kutató ezúttal a németországi székhelyű WAGO Ethernet eszközeinek web-alapú menedzsment funkciójában talált egy authentikáció megkerülést lehetővé tevő hibát. A hiba az alábbi termékekben található meg:

- WAGO 750-8202/PFC200, FW04-nél korábbi verziók (az FW04 2015. augusztusban jelent meg);
- WAGO 750-881 FW09-nél korábbi verziók (az FW09 2016. augusztusban jelent meg), valamint
- WAGO 0758-0874-0000-0111;

A gyártó a hibával kapcsolatban az alábbi tanácsokat adta ügyfeleinek:

- Ha nincs külön jelezve, a WAGO Ethernet eszközeit csak helyi hálózatban történő használatra szánják;
- Vezérlő komponenseket vagy vezérlésre használt hálózatokat ne csatlakoztassanak nyílt vagy kevésbé védett hálózatokra (pl. Internet, irodai hálózatok, stb.). A WAGO ajánlása szerint a vezérlő komponenseket vagy vezérlésre használt hálózatokat tűzfalakkal kell védeni;
- Az automatizáláshoz használt komponensek fizikai vagy elektronikus hozzáférését az engedélyezett személyekre kell korlátozni;
- Az eszközök gyári jelszavait az első használatkor meg kell változtatni! Ez az intézkedés csökkenti az engedély nélküli hozzáférések kockázatát;
- Ha távoli hozzáférést kell biztosítani a vezérlő komponensekhez vagy vezérlésre használt hálózatokhoz, VPN-t kell használni!
- Rendszeresen fenyegetés-elemzéseket kell végezni és ellenőrizni kell, hogy az ellenintézkedések megfelelnek-e a szervezet biztonsági szabályzatainak!
- A mélységi védelem elveit kell követni a vezérlőrendszerek kialakítása és üzemeltetése során.

A hibával kapcsolatosan további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-357-02

A sérülékenységekkel kapcsolatban az ICS-CERT mint általában, most is a kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

Újabb áramkimaradás Ukrajnában

Ismét kibertámadás állhat a háttérben?

Az Ukrenergo weboldalán egy ideig olyan hír volt olvasható (jelenleg csak egy karbantartásról szóló oldal érhető el az Ukrenergo webszerverén), amely szerint december 17-én, szombaton 23:53-kor a Kijev mellett található északi (Petrivtsi) 330 kV-os alállomáon történt üzemzavar miatt mintegy egy órán át az ukrán főváros egy részében és a környező régió egyes részeiben áramszünet volt. Az üzemzavar a Kyivenergo és a Kyivoblenergo áramszolgáltatók területeit érintette. Az üzemzavar viszonylag gyors elhárítását egyes források szerint ismét a manuális vezérlésre történő átállással oldották meg. Az esetről az Ukrenergo igazgatója saját Facebook-oldalán is írt.

Az üzemzavar okát jelenleg is vizsgálják, a nyilatkozat szerint egyes alállomási rendszerek meghibásodását és a kibertámadás lehetőségét sem zárták ki. A vizsgálatokba a rendőrséget is bevonták és a hivatalos vizsgálatok lezárultáig az Ukrenergo távvezérelt alállomásai esetén helyi vezérlésre váltottak.

A hír hallatán többeknek a tavaly december 23-i, nyugat-ukrajnai áramszolgáltatók elleni kibertámadás jutott eszébe, azonban a mostani esetnél még nincs bizonyíték erre - ezek az esetek azonban újra és újra arra hívják fel a figyelmet, hogy a kritikus infrastruktúrák védelme a kibertérből érkező fenyegetése ellen messze nem megfelelő.

A hír egyelőre a szaksajtót még nem igazán érte el, mindeddig csak a SecurityWeek oldalán láttam, hogy írtak róla: http://www.securityweek.com/ukraine-power-outage-possibly-caused-cyberattack

Szerk: A SANS ICS Security Blog-ja és Robert M. Lee is publikáltak egy-egy cikket a témában.

Szerk2: Mostanra több szakmai híroldal is átvette a hírt innen-onnnan: https://hotforsecurity.bitdefender.com/blog/hackers-suspected-of-causing-power-outage-in-ukraine-17419.html
http://securityaffairs.co/wordpress/54572/cyber-warfare-2/ukraine-power-outage.html
http://www.darkreading.com/attacks-breaches/ukraine-investigates-possible-cyberattack-in-kiev-blackout/d/d-id/1327771
http://www.theregister.co.uk/2016/12/21/ukraine_electricity_outage/
http://uawire.org/news/ukrenergo-claims-that-blackouts-in-kyiv-could-have-been-caused-by-hackers

ICS sérülékenységek LXXVII

Sérülékenységek Visonic, Moxa, Delta Electronics, OmniMetrix és Siemens rendszerekben

Ez a hét ismét több új ICS rendszerrel kapcsolatban hozott új sérülékenységeket.

Visonic PowerLink2 sérülékenységek

A Visonic PowerLink2 minden, 2016 októbere előtt megjelent firmware-verzióját érintő sérülékenységet Aditya K. Sood fedezte fel. A hibák között XSS és bizalmas rendszeradatokat hozzáférhetővé tevő hiba is található.

A gyártó a még támogatással rendelkező verziókat használó ügyfeleknek a 2016 októberinél későbbi firmware-re történő frissítést javasolják, a gyártói támogatással nem rendelkező verzióknál pedig a frissebb verzióra váltást ajánlják.

A hibákkal kapcsolatban további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-348-01

Moxa DACenter sérülékenységek

Zhou Yu független biztonsági kutató a Moxa DACenter nevű OPC interfész-megoldásában talált több hibát. A hibák a DACenter 1.4 és ennél régebbi verzióit érinti. A sérülékenységek között program-összeomlást előidéző és nem megfelelően kezelt keresési feltételek okozta hibák találhatóak.

Mivel a DACenter termékvonal az életciklusa végén jár, a gyártó az MX-AOPC UA termékre történő váltást ajánlja minden, érintett terméket használó ügyfele számára. A DACenter számára a Moxa nem készít olyan frissítést, ami ezeket a hibákat javítaná. Azon ügyfelek számára, akik sérülékeny DACenter verziót használnak, a Moxa az ügyféltámogatási csoporttal történő kapcsolatfelvételt javasolja.

A sérülékenységekről további információkat az ICS-CERT publikációjából lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-16-348-02

Sérülékenységek Delta Electronics termékekben

A TrendMicro-hoz tartozó ZDI biztonsági kutatói, axt és Ariele Caltabiano több sérülékenységet találtak a Delta Electronics alábbi termékeiben:

- WPLSoft V2.42.11-nél korábbi verziói;
- ISPSoft 3.02.11-nél korábbi verziói és
- PMSoft 2.10.10-nél korábbi verziói.

A hibák között puffer-túlcsordulást illetve szabálytalan fájl olvasást és végrehajtást lehetővé tevő hiba is található.

A sérülékenységekkel kapcsolatban a gyártó az alábbi verziókra történő frissítést javasolja:

- ISPSoft V3.02.11;
- PMSoft V2.10.10;
- WPLSoft V2.42.11;

A hibákról több információt az ICS-CERT weboldalán és a ZDI alábbi publikációiban lehet olvasni:

http://www.zerodayinitiative.com/advisories/ZDI-16-672/
http://www.zerodayinitiative.com/advisories/ZDI-16-663/
http://www.zerodayinitiative.com/advisories/ZDI-16-662/
http://www.zerodayinitiative.com/advisories/ZDI-16-661/
http://www.zerodayinitiative.com/advisories/ZDI-16-660/
http://www.zerodayinitiative.com/advisories/ZDI-16-659/
http://www.zerodayinitiative.com/advisories/ZDI-16-658/
http://www.zerodayinitiative.com/advisories/ZDI-16-657/
http://www.zerodayinitiative.com/advisories/ZDI-16-656/
http://www.zerodayinitiative.com/advisories/ZDI-16-655/
http://www.zerodayinitiative.com/advisories/ZDI-16-654/
http://www.zerodayinitiative.com/advisories/ZDI-16-653/
http://www.zerodayinitiative.com/advisories/ZDI-16-652/
http://www.zerodayinitiative.com/advisories/ZDI-16-651/
http://www.zerodayinitiative.com/advisories/ZDI-16-650/
http://www.zerodayinitiative.com/advisories/ZDI-16-649/

OmniMetrix OmniView sérülékenységek

Az OmniMetrix OmniView nevű, vezérlőközpontokban használt rendszerében Bill Voltmer, az Elation Technologies LLC munkatársa talált két sérülékenységet is. A hibák az OmniView 1.2-es verzióját érintik. Az első hiba a webes bejelentkezési adatok titkosítás nélkül http-csatornán történő továbbítása, a második pedig lehetőséget ad támadóknak, hogy brute-force támadást hajtsanak végre a felhasználói jelszavak kitalálása érdekében.

A gyártó a hibákat a legújabb verzióban javította, ettől a verziótól kezdve az alkalmazás https protokollt használ és kötelező erős jelszavakat használni.

A hibával kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-350-02

Siemens Desigo PX Web modul sérülékenységek

A Siemens Desigo PX webes moduljában Marcella Hastings, Joshua Fried és Nadia Heninger, a Pennsylvania Egyetem munkatársai találtak egy gyenge véletlenszám-generáló alkalmazás használatából adódó sérülékenységet. A hiba az alábbi termékeket érinti:

- Desigo PX PXC00-E.D, PXC50-E.D, PXC100-E.D, PXC200-E.D automatizálási vezérlők PXA40-W0, PXA40-W1, PXA40-W2 Desigo PX web moduljai, amik a V6.00.046-nál korábbi firmware verziókat használják;
- Desigo PX PXC00-U, PXC64-U, PXC128-U automatizálási vezérlők P PXA30-W0, PXA30-W1, PXA30-W2 Desigo PX web moduljai, amik a V6.00.046-nál korábbi firmware verziókat használják.

A sérülékenység abból adódik, hogy a nem kellően véletlenszerű véletlenszám-generáló alkalmazás használata miatt a https-titkosításhoz használt privát kulcsot egy támadó bizonyos körülmények között képes lehet megszerezni.

A hibát a Siemens a Desigo PX Web modulok V6.00.046-os firmware-verziójában javította.

A hibával kapcsolatban további információkat a Siemens ProductCERT publikációja tartalmaz: http://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-856492.pdf

Szerk: A hibával kapcsolatban megjelent az ICS-CERT publikációja is: https://ics-cert.us-cert.gov/advisories/ICSA-16-355-01

Fatek Automation PLC WinProladder sérülékenység

A Fatek Automation PLC WinProladder nevű termékében egy, a ZDI-vel együttműködő kutató talált puffer-túlcsordulást okozó hibát. A hiba a PLC WinProladder 3.11-es verziójának 14701-es build-jét érinti. A gyártó mindezidáig nem készített javítást a hibára, ezért a ZDI felvette a kapcsolatot az ICS-CERT-tel, majd saját szabályai szerint publikálta a sérülékenység részleteit.

További információkat a hibáról az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-350-01

A 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!

süti beállítások módosítása
Mobil