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

ICS Cyber Security blog

ICS Cyber Security blog

Újabb részletek a Triton/Trisis ICS malware-támadásról

2018. január 20. - icscybersec

December közepén én is írtam a arról a malware-támadásról, ami a hírek szerint egy szaúdi ipari szervezet Schneider Electric által gyártó SIS rendszerét (Safety Instrumented System) érte. A Triconex nevű SIS rendszer elleni támadásról a gyártó az elmúlt héten (január 16-a és 18-a között) Miami-ban tartott S4x18 konferencián osztott meg újabb részleteket. Vizsgálataik alapján a támadók egy nulladik napi sérülékenységet találtak a Triconex SIS rendszerben és ezt kihasználva juttattak egy RAT (Remote Access Trojan) kártevőt a megtámadott SIS rendszerbe. A Schneider Electric szakemberei szerint ez a malware az első RAT a malware-ek sorában ami képest volt SIS rendszert megfertőzni.

Az S4x18 konferencián a témában elhangzott további részletekről a DarkReading cikkében lehet olvasni: https://www.darkreading.com/vulnerabilities---threats/schneider-electric-triton-trisis-attack-used-0-day-flaw-in-its-safety-controller-system-and-a-rat/d/d-id/1330845

ICS sérülékenységek CXLVII

Sérülékenységek Advantech, Delta Electronics, General Motors és Shanghai OnStar, Rockwell Automation, Moxa és WECON rendszerekben

Sérülékenységek Advantech WebAccess rendszerekben

Több biztonsági kutató összesen hét különböző sérülékenységet fedezett fel az Advantech WebAccess 8.3-nál korábbi verzióiban. A hibák között Untrusted Pointer Dereference, puffer-túlcsordulás, könyvtárbejárást lehetővé tevő hiba, SQL injection, a bevitt adatok nem megfelelő ellenőrzése, a feltöltött fájlok nem megfelelő ellenőrzése és memóriakezelési hiba is található.

A hibákat a gyártó a WebAccess 8.3-as verziójában javította.

A sérülékenységekkel kapcsolatos részletekről az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-18-004-02A

Delta Electronics rendszerek sérülékenységei

Steven Seeley, a Source Incite munkatársa 4 sérülékenységet azonosított a Delta Industrial Automation Screen Editor 2.00.23.00 és korábbi verzióiban. A hibák között puffer-túlcsordulás, különböző memóriakezelési hibák is találhatóak.

A gyártó a hibákat a DOPSoft Version 2-ben javította.

A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-004-01

Sérülékenységek General Motors és Shanghai OnStar iOS kliensekben

Charles Gans három sérülékenységet fedezett fel a GM által is használt Shanghai OnStar rendszerek iOS klienseinek 7.1-es verziójában. A hibák között érzékeny adatok olvasható formában történő tárolása, man-in-the-middle támadásra lehetőséget adó hiba és nem megfelelő authentikáció is található.

A rendelkezésre álló információk alapján javítás a fenti hibákra még nem érhető el. A GM kockázatcsökkentő intézkedéseket javasol ügyfelei számára. A kockázatcsökkentő intézkedések és a sérülékenységek részletei az ICS-CERT bejelentésében olvashatóak: https://ics-cert.us-cert.gov/advisories/ICSA-17-234-04

Rockwell Automation kontrollerek sérülékenysége

Thiago Alves, az alabamai egyetem munkatársa jelentett egy puffer-túlcsordulási hibát, ami az Allen-Bradley MicroLogix 1400-as sorozatú kontrollereinek B és C sorozatú verzióit érinti, amennyiben a 21.002 vagy korábbi firmware-verziók valamelyikét futtatják:

- 1766-L32AWA
- 1766-L32AWAA
- 1766-L32BWA
- 1766-L32BWAA
- 1766-L32BXB
- 1766-L32BXBA

A hibát a gyártó a 21.003-as verziójú firmware-ben javította.

A sérülékenységgel kapcsolatos részletek az ICS-CERT publikációjában találhatóak: https://ics-cert.us-cert.gov/advisories/ICSA-18-009-01

Sérülékenységek Phoenix Contact hálózati eszközökben

Ilya Karpov és Evgeniy Druzhinin, a Positive Technologies munkatársai két sérülékenységet azonosítottak, amik a Phoenix Contact 3xxx, 4xxx és 48xxx sorozatú switch-einek 1.0-tól 1.32-ig terjedő firmware-verzióiban találhatóak meg. A hibákat kihasználva lehetőség van authentikációs hibákat kihasználni és bizalmas adatokhoz hozzáférni.

A hibákat a gyártó az 1.33 és későbbi verziókban 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-011-03

Sérülékenység Moxa MXView hálózatmenedzsment szoftverekben

Karn Ganeshen egy könyvtárbejárást lehetővé tevő hibát azonosított a Moxa MXview v2.8 és korábbi verzióiban. A gyártó a hibát a v2.9-es verzióban javította.

A sérülékenységgel kapcsolatban további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-18-011-02

Sérülékenységek WECON rendszerekben

Több biztonsági kutató munkájaképpen két, puffer-túlcsorduláson alapuló sérülékenységet azonosítottak a WECON LEVI Studio HMI Editor nevű termékének v1.8.29 és korábbi verzióiban. A gyártó a hibákat a legújabb verzióban javította.

A sérülékenységekkel kapcsolatos további információkat az ICS-CERT vonatkozó publikációjában lehet elérni: https://ics-cert.us-cert.gov/advisories/ICSA-18-011-01

A fenti sérülékenységek negatív hatásainak csökkentése érdekében az ICS-CERT az alábbi kockázatcsökkentő intézkedések bevezetését javasolja:

- Minimálisra kell csökkenteni az ipari/egészségügyi rendszerek/hálózatok kapcsolatát az Internettel, az ilyen eszközök közvetlen Internetre történő csatlakoztatását kerülni kell;
- Az ipari/egészségügyi rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari/egészségügyi rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak;
- Amikor csak lehetséges el kell távolítani, le kell tiltani vagy meg kell változtatni az alapértelmezett felhasználói fiókok nevét és jelszavát;
- A nyers erőn (brute force) alapuló jelszótörések elleni védekezés jegyében felhasználói fiók-kizárási szabályokat célszerű alkalmazni;
- Erős jelszavak alkalmazását kikényszerítő szabályokat kell alkalmazni;
- Harmadik féltől származó alkalmazással célszerű monitorozni az adminisztrátori szintű jogosultságok kiadását;
- Az alapértelmezett beállításokat, amennyiben lehetséges, meg kell változtatni;
- A futó szolgáltatások hardening-jét célszerű elvégezni (csak azok a szolgáltatások fussanak, amik nélkülözhetetlenek);
- Biztonságos felhasználókezelési és hozzáférési szabályokat kell életbe léptetni;
- A megbízhatónak tartott firmware és szoftver-verziókból célszerű (valamilyen szinten tűzálló páncélszekrényben) elzárt fizikai példányokkal rendelkezni (lehetőleg egyszer írható adathordozón, pl. CD/DVD, stb.);
- Ismerni kell a normális működéshez tartozó hálózati forgalmat;
- Ki kell alakítani a biztonsági naplózás és naplóelemzés képességét és ezekre építve a megfelelő riasztási eljárásokat;
- Az új beállításokat labor körülmények között célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Gateway to (s)hell

Thomas Roth előadása a 34. Chaos Computer Conference-en

December utolsó napjaiban ismét megrendezték a német Chaos Computer Club éves konferenciáját, a Chaos Computer Conference-t, rövidebb nevén a C3-at. Az idei volt a 34. alkalom, ezért a tradícionális elnevezés, 34C3.

Idén egyetlen ICS témájú előadást találtam, ami elérhető YouTube-on, ezt Thomas Roth tartotta, aki a különböző ICS gateway-ek sérülékenységeiről és az ezek kihasználásához szükséges támadási módokról beszélt. Az előadás felvételét itt lehet megtalálni: https://www.youtube.com/watch?v=Itgwb3rn7gE

Processzor-sérülékenységek hatása az ICS rendszerekre

Spectre és Meltdown az ICS világában

A héten két, az IT biztonsági szakma és a mainstream sajtó által egyaránt széles körben tárgyalt sérülékenységről publikáltak részleteket. Az x86-os architektúrájú CPU-k (jellemzően Intel és AMD) mellett az ARM processzorok is érintettek, ez pedig azt jelenti, hogy az IT eszközök bőven több, mint 90%-a érintett lehet. A legnagyobb operációs rendszer gyártók némelyike (Microsoft, RedHat, a Google az Android esetén, stb.) már kiadta vagy kiadni készül olyen frissítéseket, amikben javítják a hibákat, de ismerve az egyes szervezetek és felhasználók patch-elési szokásait, ezek a hibajavítások még jó esetben is hetekig, rosszabb esetben évekig nem lesznek telepítve - és ez is csak azokra a platformokra vonatkozik, ahol van/lesz elérhető frissítés (elég a különböző, nagy mobil eszköz gyártó vállalatok egyedi Andoid-verzióira gondolni, amikhez viszonylag gyorsan, kb. a következő modell megjelenésekor megszűnik a támogatás).

Mit is jelent ez a két sérülékenység az ICS rendszerek/eszközök üzemeltetői számára? Mivel a legtöbb ICS berendezés és rendszer az érintett CPU architektúrákra épül, ezért nagyjából biztosan állíthatjuk, hogy az ICS rendszerek döntő többsége érintett lehet. Tovább rontja a helyzetet, hogy az ICS rendszerek esetén még abban az esetben is lassan szoktak hibajavításokat telepíteni, ha a gyártó kiad hibajavításokat az adott eszközökhöz (és ahogy a héten korábban erről már írtam, az ICS világában az IT-nál sokkal gyakoribb a gyártói támogatással már nem rendelkező eszközök akár hosszú éveken át történő használata). Ráadásul napjainkban a SCADA és DCS rendszerek túlnyomó többsége már x86-os CPU-kra és Windows/Linux operációs rendszerekre épül, amikhez ugyan a hírek szerint legalábbis részben már elérhetőek a javítások, de a SCADA/DCS-gyártók jellemzően csak a saját, laborban végzett teszteléseik után szoktak engedélyt adni az ügyfeleiknek a patch-ek SCADA/DCS rendszerekre történő telepítésére, az üzemeltetők pedig ezt szinte minden esetben megvárják, mert nem akarják a rendszereik gyártói garanciáját kockázatatni egy, a gyártó által jóvá nem hagyott patch telepítésével. Sajnos az is nagyon elterjedt gyakorlat az ICS rendszerek világában, hogy a patch-eket még az esetlegesen már meglévő gyártói jóváhagyás esetén sem telepítik, úgy gondolva, hogy ezeket a rendszereket az ilyen sérülékenységeket kihasználó malware-ek és támadók úgy sem lesznek képesek elérni - arról pedig már számtalanszor írtam én is itt a blogon, hogy ezek a hiedelmek milyen károsak és hány esetben bizonyították sikeres támadások ennek az ellenkezőjét.

Ebben az esetben (illetve esetekben) tovább bonyolítja a helyzetet, hogy ez első hírek szerint a már elérhető patch-ek alkalmazása után az érintett rendszereknél jelentős (a hírek 5-30, időnként 50%-os) performancia-vesztés jelentkezett a hibajavítás előtti állapothoz képest, márpedig az ICS rendszerek döntő többsége jellemzően nem rendelkezik ekkora performancia-tartalékkal. Egyes SCADA és DCS rendszereknél láttam olyan méretezést, ahol a rendszer névleges teljesítménye legalább a rendszer tervezett csúcsteljesíményének a kétszerese, de egyrészt ezek a performancia-tartalékok azért vannak az adott rendszerekben, hogy a stabil működést garantálják minden esetben, másrészt számos olyan eszköz van (különösen a lvl1-lvl0 eszközök), ahol alig valamekkora performancia tartalék áll rendelkezésre. Ebbe a kicsi tartalékba az 5% talán még beleférhet egyes eszközöknél, de a 30-50% biztosan nem. Ismerve az ICS fejlesztők és üzemeltetők gondolkodását, ezeknél a rendszereknél és eszközöknél el fognak tekinteni a sérülékenységek patch-elésétől, ekkor pedig csak az ICS sérülékenységeknél gyakran ismételt kockázatcsökkentő intézkedések maradnak lehetőségként, hogy a sérülékeny rendszereket valahogyan megpróbálják a szakemberek megvédeni azoktól a támadási kísérletektől, amit az IT biztonsági szakma már most biztosra vesz a következő néhány hétben-hónapban.

Én minden esetre azt javaslom minden ICS rendszert üzemeltető kollégának, hogy vizsgálja meg a rendszereit és egyeztessen a gyártókkal, hogy az általa használt rendszerek/berendezések érintettek-e és elérhetőek-e már a javítások. Ha pedig van a gyártó által jóváhagyott javítás, kezdjen egyeztetéseket az érintett szakterületekkel a javítások telepítésének a lehetőségeiről.

ICS sérülékenységek - 2017 ICS sérülékenységi statisztikái

Hosszú idő óta az elmúlt egy héten nem jelentek meg új ICS sérülékenységi információk az általam követett forrásokban, ezért a heti ICS sérülékenységekről szóló posztot felhasználom arra, hogy egy rövid összefoglalást készítsek a 2017-ben általam újraközölt ICS sérülékenységekről.

2017-ben összesen 430 ICS rendszerekkel/berendezésekkel kapcsolatos sérülékenységről szóló információ adtam közre a blogon keresztül, ami közel 65%-os növekedést jelentett 2016-hoz képest. A CVSSv3 alapján történő besorolás szerint a kritikus sérülékenységek számában még ennél is nagyobb volt a növekedés, 2016-hoz képest 72%-kal több kritikus sérülékenység került publikálásra (2016-ban 47, 2017-ben 81), a magas besorolású sérülékenységek esetén ez a szám már 80% fölött van (107 és 193), a közepes kategóriájú sérülékenységeknél pedig 58% volt a növekedés (96 és 152). Csökkenést egyedül az alacsony besorolású sérülékenységeknél tapasztaltam (11 és 4).

A 2017-ben publikált sérülékenységek nagyon nagy többsége (95%-a) távolról is kihasználható. A sérülékenységek gyártók szerinti bontásában nincs nagy meglepetés, a nagy gyártók végeztek idén is az "élen".

Ahogy ezek a statisztikák is mutatják, az ICS rendszerek/berendezések sérülékenységi helyzete korántsem jó, azonban még ezt a képet is tovább rontja, ha azt nézzük, hogy a publikált sérülékenységekkel kapcsolatosan elérhetőek-e hibajavítások? A 430 sérülékenység több, mint harmadához a sérülékenység publikálásakor nem volt elérhető javítás, vagyis ezeket a sérülékenységeket 0. napi sérülékenységként kell kezelni és ezeknek az eseteknek egy igen tekintélyes hányadában a gyártó is kijelentette, hogy az adott termék/verzió támogatási ciklusa végére ért és soha nem fognak javítást kiadni az adott sérülékenységgel kapcsolatban (nagyon sok mindenért jogosan lehet kárhoztatni a Microsoft-ot, de amikor a redmond-i gyártó látta, hogy az EternalBlue sérülékenység milyen hihetetlen komoly károkat okoz a WannaCry ransomware-kampány idején, saját korábbi kijelentésével szembemenve is adott ki javítást egyes, már nem támogatott, de széles körben használt operációs rendszer verzióihoz). Tekintettel arra, hogy a legtöbb ICS rendszer/berendezés életciklusa 15-20 év is lehet, az ilyen, gyártói támogatással már nem rendelkező, de publikusan elérhető sérülékenységeket tartalmazó rendszerek még igen sokáig a mindennapjaink fontos folyamatait vezérlő szereplői lehetnek. Éppen ezért fontos, hogy foglalkozzunk az ICS rendszerek kiberbiztonsági kérdéseivel.

Mi vár az ICS biztonság világára 2018-ban?

Már a 2017 is elég mozgalmas év volt az ICS kiberbiztonságban dolgozók számára (elég csak a CrashOverride és Triton/Trisis ICS malware-ekre gondolni), de a jelek szerint 2018-ban sem fogunk unatkozni. Lássuk, milyen kihívásokat jósolnak a jövő évre az ICS világában dolgozóknak:

Az újabb ransomware-ek között már olyanok is lehetnek, amik kifejezetten ipari rendszereket céloznak.

2017-ben több nagy ransomware illetve ransomware/wiper malware-támadást éltünk át és már ezek között is több olyan volt, ami súlyos károkat okozott ipari környezetekben is. 2018-ra vannak olyan várakozások, hogy megjelennek az első, kifejezetten ipari rendszereket célzó zsarolóvírusok is - idén a Georgia Institute of Technology munkatársai kutatási céllal már készítettek egy olyan proof-of-concept malware-t (amit LogicLocker-nek nevezetek el), ami képes volt különböző gyártók vezérlőit megfertőzni. Ismerve az ICS eszközök gyakori biztonsági hiányosságait (most elsősorban a gyenge authentikációra és a hibajavítások hiányára vagy késedelmes telepítésére), egyáltalán nem túlzás egy ilyen malware-támadás lehetőségét komolynak, hatását pedig súlyosnak nevezni.

Az ipari dolgok Internete (IIoT) egyre nagyobb kihívásokat fog jelenti biztonsági szempontból

Az IIoT az elmúlt néhány évben egyre nagyobb teret nyer az ICS világában, ennek oka többnyire a modernizáció és a költséghatékonyság egyre nagyobb nyomása az ipari szereplők üzleti részlegei felől. Magyarországon egy további tényező erősítheti az IIoT alkalmazását, ez pedig az egyre több területen, így lassan az ipari szereplőknél is súlyosabbá váló, képzett munkaerő hiánya, amit például a gyártásban vagy akár a közmű szektorban egy ideig még ellensúlyozni lehet az automatizálás fokozásával.

Az automatizálás növelése azonban egyre jobban elmossa a (fizikai elkülönítés) jelentette határokat az üzleti/vállalati és az ipari hálózatok, illetve egyre gyakrabban az ipari hálózatok és az Internet illetve egyéb publikus hálózatok között, ami a korábbiaknál nagyságrendekkel nagyobb fenyegetéseket és támadási felületeket jelentenek az ICS rendszerek számára.

Az ICS kiberbiztonsági szakemberek hiánya egyre súlyosabb lesz

Bár világszerte már ezres nagyságrendben vannak minősített és tapasztalt ipari biztonsági szakemberek, az igény az ilyen, speciális biztonsági ismeretekkel rendelkező profikra sokkal gyorsabb ütemben nő, mint ahogy új szakemberek tudnak megjelenni a piacon. Ebből a szempontból a helyzet talán még rosszabb, mint (az egyébként szintén komoly hiányszakmának számító) IT biztonsági szakemberek esetében, hiszen az ICS világában gyakran azokat a technikákat és eszközöket sem lehet használni, amik az IT biztonság világában mindennaposnak számítanak.

Magyarországon jelenleg gyakorlatilag szó sem esik erről a témáról - nem véletlenül indítottam két éve a blogot, de egyelőre nem igazán látszik, hogy a hazai ICS közösség aktivizálná magát az ICS kiberbiztonság témájában. Az nyilvánvaló, hogy érdeklődés a téma iránt van (ez általában látható azokon a ritka előadásokon, amiket a témában néhányan időnként tartanak), de azok a szakemberek, akik az ICS kiberbiztonság területén tevékenykednek, továbbra is bezárkóznak a saját munkahelyük elefántcsont tornyába és még egymással sem igen osztják meg a tapasztalataikat.

Egyre nagyobb valószínűség egy súlyos ICS incidensre

Na nem mintha az elmúlt évek ICS incidensei (a Stuxnet, majd a német acélkohóban bekövetkezett incidens és a 2015-ös és 2016-os ukrán villamosenergia-rendszer elleni támadások) ne lettek volna önmagukban is súlyos incidensek, de a Triton/Trisis malware megjelenés és felhasználása egyre inkább abba az irányba mutat, hogy a különböző helyi és globális politikai konfliktusokban (a Közel-Keleten Szaúd-Arábia és Irán konfliktusában, a Távol-Keleten Észak-Korea és Dél-Korea illetve az USA egyre romló viszonya, illetve Oroszország egyre komolyabb kibertér-képességei, amiket mind több állítás szerint fel is használnak az orosz politikai érdekek érvényesítéséhez) egyre nagyobb esélye lehet egy olyan incidensnek, ami nagyon súlyos, akár végzetes hatással járhat az ICS rendszerek által felügyelt/vezérelt ipari folyamatokra, vagy akár (ahogy a Triton/Trisis malware esetén már az SIS rendszer volt a célpont) emberéletet is követelhet az incidens.

A rossz jelek és előérzetek mellett azért pozitív várakozások is vannak 2018 kapcsán. Az első és talán legfontosabb, hogy már érezhetően nő az ICS világban élő és dolgozó ipari automatizálási (OT) mérnökök biztonságtudatossága. Személy szerint is érzem, hogy az OT mérnökök már gondolnak olyan biztonsági szempontokra is, amiket néhány évvel ezelőtt még csak nem is értettek, miért fontosak ezek a dolgok. Ugyanígy kezdik megérteni az OT-ben az események átláthatóságának értékét is, így aztán egyre inkább magától értetődővé válik olyan, tradicionálisan az IT biztonság világából ismert megoldásoknak, mint például a SIEM (Security Incident and Event Management, naplóelemző) rendszerek.

Fókuszba kerül az épületautomatizálási rendszerek biztonsága

Sok éven át az épületautomatizálási rendszerek biztonsága nem került fókuszba, még azután a Stuxnet után a figyelem középpontjába került az ICS rendszerek biztonsága. Annak ellenére volt ez így, hogy általában az épületautomatizálási rendszerek felelnek a szervezetek szervertermeinek/szerverszobáinak hűtéséért és szünetmentes tápellátásáért, ezeken keresztül pedig a teljes vállalati IT rendelkezésre állására is hatással lehetnek.

Kiberbiztonsági keretrendszerek növekvő alkalmazása az ICS rendszereknél

Bár itthon és a világban is ritka, hogy törvényi kötelezettsége lenne az ICS rendszereket üzemeltető szervezeteknek a különböző ICS biztonsági keretrendszerek alkalmazására, mégis az elmúlt években egyre terjed a kifejezetten ICS rendszerek kiberbiztonságával foglalkozó keretrendszerek, mint pl. az NIST 800-82 vagy a NERC-CIP alkalmazása. Várhatóan ez a folyamat csak gyorsulni fog, még akkor is, ha a jogszabályok ezt továbbra sem fogják megkövetelni, de a különböző szervezetek egyre inkább felismerik, hogy ezeknek a keretrendszereknek az alkalmazásával nagy mértékben lehet javítani az ICS rendszerek kiberbiztonsági helyzetét.

Biztonságosabb ICS eszközök és rendszerek

Ahogy az ICS rendszereket használó szervezetek biztonságtudatossága is magasabb szintre lép, az ICS eszközöket és rendszereket gyártó vállalatok közül egyre több ismeri fel, hogy nem elég az ipari folyamatvezérlési funkciókban kiszolgálni az ügyfeleik igényeit, hanem ugyanígy fontossá vált az ICS rendszerek kiberbiztonsága is. Várhatóan egyre több ICS eszköz és rendszer lesz képes titkosított protokollokon keresztül kommunikálni és talán eljutunk végre ahhoz a régen várt állapothoz, hogy az ICS rendszerek biztonsági funkciói gyári alapértelmezés szerint be lesznek kapcsolva és akkor lehet kikapcsolni őket, ha az ügyfél kifejezetten ki akarja kapcsolni őket.

Bár ez egy kifejezetten örömteli fejlemény, azonban figyelembe kell venni, hogy a legtöbb ipari rendszert 15-20 éves életciklussal tervezték és helyezték üzembe, ezért még hosszú ideig nem lesz lehetőség minden régi ICS rendszert lecserélni az újabb, biztonságosabb verziókra. Emiatt még sokáig szükség lesz a mélységi védelem és a biztonságos ICS architektúra modellben leírt elvek gyakorlati alkalmazására.

ICS sérülékenységek CXLVI

Moxa és Schneider Electric rendszerek sérülékenységei

Sérülékenység Moxa NPort készülékekben

Federico Maggi egy, a felhasználói adatok nem megfelelő kezeléséből adódó sérülékenységet jelentett az ICS-CERT-nek, ami a Moxa alábbi eszközeit érinti:

- NPort W2150A 1.11-nél korábbi firmware-jei;
- NPort W2250A 1.11-nél korábbi firmware-jei.

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

A sérülékenységgel kapcsolatos további részleteket az ICS-CERT bejelentésében lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-17-355-01

Schneider Electric rendszerek sérülékenységei

Gjoko Krstic két sérülékenységet jelentett a Schneider Electric-nek, amik a francia gyártó Pelco VideoXpert Enterprise rendszerének 2.1-nél korábbi összes verzióját érinti.

A hibák között könyvtár-bejárásos támadást lehetővé tevő és nem megfelelő hozzáférés kontrollból adódó sérülékenység is található.

A gyártó a 2.1-es verzióban javította.

A sérülékenységről további információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-355-02

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.

Kriptovalutát bányászó malware a Transneft rendszereiben

Az orosz olajipar szállítási kapacitásainak jelentős részét felügyelő Transneft rendszereit a hírek szerint a Monero nevű kriptovaluta bányászatára fejlesztett malware fertőzte meg. A cég képviselői szerint a malware-fertőzés hatással lehetett volna a Transneft feldolgozó kapacitására. Az utóbbi idők kriptovaluta-árfolyamainak drasztikus kilengései nyomán lehetett arra számítani, hogy megnő a Bitcoin és más kriptovaluták bányászatára speciálizált malware-ekkel végrehajtott támadások száma, az azonban még mindig nem számít mindennapi hírnek, hogy ezek a kártevők viszonylag könnyen utat találnak az ipari folyamatok felügyeletéért és irányításáért felelős rendszerekbe is.

ICS sérülékenységek CXLV

Sérülékenységek WECON, Siemens, Ecava, PEPPERL+FUCHS/ecom instruments és ABB rendszerekben

WECON LeviStudio HMI sérülékenység

Michael DePlante a ZDI-vel együttműködve tájékoztatta az ICS-CERT-et egy, a WECON LeviStudio HMI berendezéseiben talált puffer túlcsordulásból eredő sérülékenységet. A hiba a LeviStudio HMI minden verziójában megtalálható.

A hibát a gyártó a legfrissebb, weboldalán

http://www.we-con.com.cn/en/download.aspx?id=45

elérhető verzióban javította.

A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT publikációjában lehet megtalálni: https://ics-cert.us-cert.gov/advisories/ICSA-17-353-05

Siemens LOGO! Soft Comfort sérülékenység

Tobias Gebhardt egy integritás-ellenőrzés nélküli kódletöltésből adódó hibát jelentett a Siemens-nek, ami a LOGO! Soft Comfort V8.2-nél korábbi verzióiban található meg.

A hibát a gyártó a LOGO! Soft Comfort V8.2-es verziójában javította.

A sérülékenység részleteiről az ICS-CERT bejelentésében lehet bővebben olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-353-04

Sérülékenység Ecava Integraxor rendszerekben

Steven Seeley, Michael DePlante és Brad Taylor két SQL injection sérülékenységet fedeztek fel az Ecava Integraxor 6.1.1030.1 és korábbi verzióiban.

A gyártó a hibákat a 6.1.1215.0 verzióban javította.

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

Sérülékenység PEPPERL+FUCHS/ecom instruments eszközökben

A PEPPERL+FUCHS/ecom instruments a Mathy Vanhoef által felfedezett KRACK sérülékenységgel kapcsolatos információkat jelentett a CERT@VDE-nek. A KRACK sérülékenység az alábbi, vezeték nélküli kommunikációra képes eszközeiket érinti, amennyiben azok a WPA2 protokollt használják:

- Tab-Ex 01;
- Ex-Handy 09;
- Ex-Handy 209;
- Smart-Ex 01;
- Smart-Ex 201;
- Pad-Ex 01;
- i.roc Ci70-Ex;
- CK70A-ATEX;
- CK71A-ATEX;
- CN70A-ATEX;
- CN70E-ATEX.

Az Android alapú eszközök esetén a gyártó jelenleg is dolgozik a hiba javításán. A Microsoft Windows alapú eszközöket használó ügyfeleiknek azt tanácsolják, hogy telepítsék a Microsoft által kiadott patch-eket.

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-17-353-02

Sérülékenység ABB Ellipse rendszerekben

A gyártó a felhasználók bejelentkezési adatainak olvasható formában történő továbbításából adódó hibát jelzett az ICS-CERT-nek. A sérülékenység az alábbi verziókat érinti:

- Az Ellipse 8.3-tól 8.9-ig terjedő, 2017 december előtt kiadott verziói.

A hibát a gyártó az alábbi verziókban javította:

- Ellipse 8.5.26 Release 7, 2017 decemberi kiadás;
- Ellipse 8.6.21 Release 5, 2017 decemberi kiadás;
- Ellipse 8.7.18 Release 7, 2017 decemberi kiadás;
- Ellipse 8.8.12 Release 7, 2017 decemberi kiadás;
- Ellipse 8.9.6 Release 7, 2017 decemberi kiadás.

A sérülékenységről további részleteket az ICS-CERT publikációja tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-353-01

KRACK sérülékenység Siemens SIMATIC eszközökben

A Siemens ProductCERT által kiadott közlemény szerint 5 különböző, KRACK-hez kapcsolódó sérülékenységet azonosítottak az alábbi Siemens SIMATIC eszközökben:

- SIMATIC RF350M: minden Summit Client Utility-t tartalmazó verzió V22.3.5.16-nál korábbi verziók esetén;
- SIMATIC RF650M: minden Summit Client Utility-t tartalmazó verzió V22.3.5.16-nál korábbi verziók esetén.

A Siemens a hibákat a V22.3.5.16-os verzióban javította.

A sérülékenység részleteit a Siemens ProductCERT kiadványa tartalmazza: https://www.siemens.com/cert/pool/cert/siemens_security_advisory_ssa-418456.pdf

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:

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.

Triton/Trisis malware

Felfedezték az ötödik, kifejezett ICS rendszerek ellen fejlesztett malware-t

December 14-én egymással párhuzamosan a FireEye és a Dragos, Inc. is publikált egy-egy elemzést az általuk Triton (FireEye) illetve Trisis (Dragos) névre keresztelt, kifejezetten ipari rendszerek ellen tervezett és fejlesztett malware-ről.

Az elemzések alapján a Triton/Trisis malware-t a Schneider Electric által gyártott Triconex SIS-re (Safety Instrumented System) fókuszálva írták. Mindkét biztonsági cég publikációja szerint a malware-t eddig egyetlen helyen azonosították, egy Közel-keleti ipari szereplőnél, ahol a támadás által érintett SIS vezérlők egy ún. "fail-safe" leállást (ilyen esetekben az SIS rendszer a fizikai folyamatok teljes leállítását hajtják végre annak érdekében, hogy megelőzzék egy nem biztonságos állapot kialakulását) hajtott végre, amikor az alkalmazás redundáns komponenseinek egyikében hibára futott a programkód ellenőrzése.

Az érintett Triconex SIS rendszert számos iparágban használják, tekintve azonban, hogy minden SIS rendszer különböző és a folyamatvezérlésre gyakorolt hatásuk megértéséhez az adott folyamat mélyreható ismerete szükséges, a szakértők nem számítanak arra, hogy a Triton/Trisis szélesebb körben is felbukkanna - akár csak más, Triconex-et használó szervezeteknél sem. A célzott támadás elméletét erősíti az is, hogy a FireEye elemzése szerint az SIS kompromittálása után nem sokkal a támadók fel is töltötték a Triton/Trisis malware-t a rendszerbe. Ez a FireEye munkatársai szerint arra enged következtetni, hogy már elő volt készítve a malware, aminek a megírásához hosszabb időre és nem mindenki számára hozzáférhető eszközökre is szükségük lehetett.

Az incidens esetén a célba vett szervezet az elemzések szerint legalább két, ICS biztonsági legjobb gyakorlatot is figyelmen kívül hagyott, az SIS rendszer össze volt kapcsolva a folyamatirányító hálózattal és a Triconex SIS "Run" mód helyett "Program" módban működött (a Triconex "Run" módban nem engedélyezi a programban változtatások végrehajtását, "Program" módban azonban lehetőség van erre, ezért volt lehetősége a Triton/Trisis malware-nek érdemi változtatásokat végrehajtani az SIS rendszerben). Bár az ICS biztonsági legjobb gyakorlatok betartása sem jelent 100%-os védelmet egy hasonló támadás esetén, mégis jelentősen megnehezíthetik a támadók dolgát és könnyebbé tehetik a megtámadott szervezet számára a támadás minél előbbi felfedezését.

Bár maga a Triton/Trisis malware nem alkalmas arra, hogy nagyobb volumenű támadásokhoz használják fel, most, hogy a malware részletei nyilvánosságra kerültek, várható, hogy más támadói csoportok is célba fognak venni különböző SIS rendszereket (mint ahogy a Stuxnet nyilvánosságra kerülése után is elszaporodtak az ICS rendszerek elleni támadási kísérletek).

Meg kell jegyezni, hogy egy SIS rendszer kompromittálása önmagában még nem jelenti azt, hogy az adott folyamatirányító rendszer biztonsági (safety) funkciói is sérülnének. A folyamatirányító rendszerek biztonsági funkcióinak tervezése számos egyedi képesség meglétét és szabványok betartását igényli annak érdekében, hogy az adott folyamat biztonsági szintje megfeleljen az elvárásoknak. Mindaddig, amíg (egy akár IT biztonsági szempontból kompromittált) SIS rendszer a tervezésének megfelelően látja el a biztonsági (safety) funkcióit és szükség esetén (mint ahogy a mostani publikációkban leírt esetben is történt) képes fail-safe állapotban megállítani a fizikai folyamatokat, egy ilyen incidens nem jelent veszélyt az emberéletre vagy a környezetre.

További részleteket a Triton/Trisis malware-ről a FireEye és a Dragos, Inc. publikációiban lehet olvasni.

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