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

ICS Cyber Security blog

ICS Cyber Security blog

104-es protokollra vonatkozó Snort fejlesztéseket tett közzé a Talos

2017. február 04. - icscybersec

Az IEC 60870-5-104, közismertebb (és rövidebb) nevén a 104-es protokoll elsősorban Európában terjedt el széles körben az ICS rendszerek közötti kommunikáció eszközeként. A Talos, a Cisco biztonsági laborja december második felében 33 új Snort szabályt tett elérhetővé, kifejezetten a 104-es protokollon történő kommunikáció jobb elemzésének támogatására. Ezekkel az új szabályokkal az ipari folyamatirányító rendszereket üzemeltető szervezetek egy újabb eszközt kapnak, hogy képesek legyenek ellenőrizni a 104-es protokollon történő adatforgalmazást és a lehető leggyorsabban tudják feltárni a különböző (szándékos vagy véletlen hibából bekövetkező) incidensek hátterét. Annak érdekében, hogy ezek a szabályok a lehető leghatékonyabb forgalomelemzést biztosítsák, körültekintően kell konfigurálni őket, az egyes hálózatok egyedi karakterisztikáit figyelmbe véve. Például a SIDS 41053-41077-es szabály számos TypeID-t képes azonosítani, ezt a szabályt akkor célszerű engedélyezni, ha a védendő ICS rendszerben nem használják ezeket a TypeID-kat. A SIDS 41078-41079-es szabály az ICS hálózatba be- illetve onnan kilépő 104-es protokoll alapú kommunikációt figyeli. Amennyiben az adott ICS rendszernél az üzemszerű működéshez nem szükséges a 104 protokollra alapuló kommunikációnak elhagynia az ICS hálózatot, ezt a szabályt javasolt bekapcsolni.

A Cisco még 2013-ban jelentette be a SourceFire felvásárlását, azóta tartozik a portfóliójukba a FirePower termékcsalád, amelyeknél ezeket az új szabályokat is használni lehet.

Természetesen a különböző ICS rendszerek esetén az IPS-ek blokkolás funkcióját csak nagyon körültekintően szabad alkalmazni, azonban ezek az eszközök (még az inline IPS-ek is) alkalmasak IDS-módban is működni, amikor nem blokkolják, csak észlelik (és a beállítások szerint akár riasztanak is) gyanús hálózati forgalom esetén. Ezek az eszközök nagy segítséget jelenthetnek az ICS rendszerek elleni támadások mielőbbi felfedezése során, így mindenképp célszerű megfontolni az alkalmazásukat.

ICS sérülékenységek LXXXVII

Az elmúlt napokban ismét több ICS rendszerrel kapcsolatos sérülékenységről jelentek meg új információk.

Ecava IntegraXor sérülékenység

Az ICS-CERT publikációja szerint Brian Gorenc független biztonsági kutató és Juan Pablo Lopez, a ZDI munkatársa egy SQLi sérülékenységet találtak az Ecava IntegraXor 5.0.413.0 verziójában.

A gyártó a hibát az IntegraXor V5.2.722.2-es frissítésében javította, amit a weboldaláról lehet letölteni.

https://www.integraxor.com/download-scada/

A hibával kapcsolatban további részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-031-02

Sérülékenységek a BINOM3 multifunkciós mérőberendezéseiben

Karn Ganeshen független biztonsági kutató 5 különböző sérülékenységet talált a BINOM3 multifunkciós mérőberendezéseiben. A hibák a BINOM3 minden univerzális multifunkciós mérőeszközét érintik.

A hibák között cross-site scripting, hozzáférés-kezelési hiba, CSRF, érzékeny információk olvasható formában történő tárolása és nem megfelelő felhasználói adatkezelés is van.

A gyártó nem adott ki javítást vagy sérülékenységek okozta kockázatnövekedés csökkentésére vonatkozó javaslatokat.

A hibáról többet az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-031-01

A fenti sérülékenységekkel kapcsolatban az ICS-CERT ezúttal is a szokásos kockázatcsökkentő intézkedések végrehajtá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!

Belden Hirschmann Industrial HiVision sérülékenység

A gyártó által publikált bejelentés szerint a Hirschmann Industrial HiVision hálózatmenedzsment megoldás hibáját, ami miatt a korlátozott jogosultságú felhasználók írási jogosultságot szerezhetnek a HiVision által menedzselt eszközökön.

A hiba a 06.0.00-06.0.05 és a 07.0.00 verziókat érinti. A gyártó a hibát a 06.0.06 és a 07.0.01 verziókban javította.

A sérülékenységről további információkat a Belden bejelentése tartalmaz.

Schneider Electric StruxureWare Data Center Expert sérülékenység

A gyártó bejelentése szerint a StruxureWare Data Center Expert nevű termékének 7.3.1 és korábbi verzióiban a felhasználói fiókok jelszavait olvasható formában tárolja a rendszer a memóriában. A sérüléeknységet Ilya Karpov, a Positive Technologies munkatársa fedezte fel. A hibát a gyártó a 7.4.0 és újabb verziókban már javította.

A sérülékenységről bővebb információkat a Schneider Electric bejelentése tartalmaz.

Milyen lesz az ICS kiberbiztonság 2017-ben?

Gondolatok és várakozások az ipari rendszerek kiberbiztonságának következő egy évéről

Néhány nappal ezelőtt a SecurityWeek.com-on jelent meg Barak Perelman írása, amiben 6 pontban foglalja össze, mire számít az ICS kiberbiztonság területén 2017-ben. A mai posztban ezeket fogom a saját gondolataimmal megtűzdelve bemutatni.

1. Az újabb ICS malware-ek egyre nagyobb fenyegetést fognak jelenteni.

Barak Perelman szerint csak idő kérdése, hogy mikor fog megjelenni egy olyan új malware, ami már szándékosan ICS rendszereket fog célba venni. Az ilyen malware-ek készítéséhez szükséges tudás és technológia egy ideje már rendelkezésre áll. Egy ilyen, az Interneten szabadon eresztett malware súlyos következményekkel járhat, látva, hogy az ipari eszközök milyen nagy számban érhetőek el az Interneten - dacára annak, hogy számos ICS biztonsági szakértő folyamatosan hangoztatja, hogy ezzel mekkora kockázatnak teszik ki a kritikus infrastruktúrákat. A szerző szerint ilyen támadásokra mostanáig csak a potenciális fizikai és politikai következmények miatt nem került sor. Én azért ezt egy kicsit árnyaltabban látom. Először is egy, a Stuxnet-hez hasonló ICS malware előállítása, bár az eszközök és a tudás számos helyen rendelkezésre áll (elsősorban állami hátterű cosportoknál), egy ilyen malware-t nem csak előállítani, tesztelni is kell. Ez a célzott, egy vagy néhány típusú ICS berendezésből álló környezetre szabott malware esetén megfelelő anyagi háttérrel rendelkező cosportok esetén képesek lehetnek beszerezni a teszteléshez szükséges eszközöket. Ahhoz azonban, hogy széles körben komoly fenyegetést jelentő malware-t tudjanak előállítani, majd sikeresen bevetni sok rendszer ellen, jól univerzálisabb, sok különböző típusú (és emiatt várhatóan különböző sérülékenységeket hordozó) eszköz esetén kell tesztelni. Ez a feladat a Stuxnet-nél is egy (vagy akár több) nagyságrenddel bonyolultabb feladat, mint a mai napig ICS biztonsági mérföldkőnek tekintett Stuxnet esetén (ami korántsem kizárólag kibertámadás volt, jóval inkább egy első osztályú hírszerzési művelet, aminek korábban elképzelhetetlenül kifinomultnak tartott kiberbiztonsági része is volt) .

Máaodszor, bár a bizonyíthatóan kibertámadásra visszavezethető ICS incidensek száma az elmúlt években folyamatosan nő és a hatásaik is egyre súlyosabbak, ezeket a támadásokat (a Stuxnet-et, ami már egy 7 éves történt, nem számítva) soha nem egy (vagy több) ICS malware okozta, hanem (amennyire ezt a publikusan elérhető információk alapján meg lehet ítélni) "hagyományos" malware-eket használtak, amiket az egyes esetekhez célzottan alakítottak át, majd az így szerzett hozzáférések birtokában a támadók folytatták a hálózatok és rendszerek felderítését és az ICS incidensek előidézését.

Harmadszor pedig (és talán ez jelenleg a legnagyobb visszatartó erő az állami hátterű támadók esetén) vannak olyan feltételezések egyes, kritikus infrastruktúrák ICS kiberbiztonsági szakemberei között, hogy az elmúlt években az összes jelentősebb világpolitikai szereplő kiépíthette a saját hozzáféréseit a rivális hatalmak kritikus infrastruktúráit kiszolgáló ICS rendszerekben és pontosan tudják, hogy a saját rendszereik éppolyan védtelenek, mint azok, amikhez a saját csoportjaik rendelkeznek hozzáféréssel. Ez a helyzet kicsit hasonló, mint a nukleáris fegyverkezésből ismert MAD (Mutually Assured Destruction - kölcsönösen biztosított megsemmisítés).

2. A kiber-fizikai hadviselés valósággá válik

Elsősorban az USA-ban beszélnek egyre inkább kiberháborúról - időnként már amerikai kormányzati szereplők is (az elmúlt napokban már a frissen beiktatott elnök, Donald Trump sem vonta kétsége, hogy az USA kiberbiztonsági szempontból kiemelt kockázatokkal kell, hogy szembenézzen, bár természetesen az elnökválasztás során történt incidenseknek a választás eredményére gyakorolt hatását nem ismerte el - ellenben az USA kormánya a választáshoz használt szavazórendszert igen gyorsan a kritikus infrastruktúra részévé nyilvánította).

Való igaz, a kibertér visszavonhatatlanul a hadviselés ötödik területévé vált (a szárazföld, a tengerek, a levegő és a világűr után). Én úgy gondolom, hogy az idei évben az eddigi tendenciák fognak folytatódni, vagyis sokkal inkább elszigetelt támadásokra lehet majd számítani, ahol továbbra sem lehet majd tudni, hogy ki és pontosan milyen céllal hajtotta végre a támadást. Ez szerintem még mindig távol áll a háború fogalmától - vagy legalábbis újraértelmezi a háború fogalmát.

3. Az ICS hacktivisták tevékenysége egyre kiemelkedőbb lesz

Az 1. pontnál leírtak egy része szerintem itt is igaz. A különböző hacktivista csoportok nagyon jók a hagyományos IT rendszerek elleni sikeres akciókban, de a kiber-fizikai környezetek számukra úgy vélem (még) idegenek és nem tartom valószínűnek, hogy rendelkeznének azzal a háttérrel, hogy a hiányzó ismereteket meg tudják szerezni - még egy célzott támadáshoz szükséges, korlátozott számú berendezés beszerzése is komoly forrásokat igényelhet.

4. A zsaroló támadások ipari környezeteket is célba fognak venni

Manapság már bárki áldozata lehet egy zsaroló támadásnak és azzal, hogy az ipari rendszerek fizikai szeparálása egyre kevesebb helyen valósul meg, az adatok illetve számítógépek támadása után várhatóan csak idő kérdése, hogy a ransomware-ek ipari eszközöket is célbe vegyenek.

Látva, hogy a fájlok után egyes ransomware-ek hogyan váltottak a teljes számítógép túszul ejtésére, egyáltalán nem tartom elképzelhetetlennek, hogy egyes ipari eszközöket és rendszereket is célba vegyenek, így szerintem is csak idő kérdése, hogy az első, ipari rendszereket túszul ejtő ransomware-ről szóló híreket olvashassuk - abban azonban nem vagyok biztos, hogy ez már 2017-ben be fog következni.

5. A támadok "piros gomb"-képességet fognak fejleszteni

Barak Perelman szerint az ICS rendszerek elleni támadások viszonylag könnyen lehetőséget adnak a támadóknak arra, hogy kiépítsék a célba vett rendszerekben a saját hozzáféréseiket és ezeket a hozzáféréseket tartalékolják és egyfajta "piros gombként" használják fel egy nagyobb, összehangolt támadás részeként vagy "tárgyalási alapként" (bár lehet, hogy a zsarolás erre az esetre is pontosabb kifejezés lehet majd).

Ez az a pont, ahol úgy gondolom, hogy nem kizárt, hogy ez a helyzet már részben most is előállt, egyáltalán nem lennék meglepve, ha kiderülne, hogy az utóbbi évek ukrán villamosenergia-rendszer elleni támadásai tulajdonképpen (legalábbis részben) ilyen céllal történtek.

6. Egyre több kritikus infrastruktúra fog feltűnni a találati listákban az Internetes keresések eredményeként

Az a tendencia, hogy egyre több ICS rendszernek van kapcsolata különböző felhő-megoldásokkal, egyre inkább azt eredményezi, hogy ezek az ICS rendszerek közvetlenül vagy áttételesen kapcsolatba kerülnek az Internettel, így pedig a különböző keresőmotorok (mint pl. a Shodan) képesek lesznek katalogizálni őket és így kereshetővé válnak gyakorlatilag bárki számára. Az pedig, hogy az ICS gyártók egyre több rendszer esetén hozzák be a távoli menedzsment, felhős működési mód és vezeték nélküli kommunikáció funkcióit, az ICS rendszerek számára egyre nagyobb külső fenyegetést fognak jelenteni.

Ezzel is teljes mértékben egyet tudok érteni, az Industrial IoT és az Industrial Cloud kifejezésekről egyre többet lehet hallani és olvasni az Industry 4.0 (vagyis a negyedik ipari forradalom kapcsán), azonban az a hatalmas lelkesedés, amivel az ipari rendszerek gyártói és üzemeltetői az új technológiákat építik be a rendszereibe, nem sok helyet hagy azoknak a (szerintem józanabb) hangoknak, akik ezeknek a technológiáknak a biztonságra gyakorolt (negatív) hatássaira próbálják meg felhívni a figyelmet.

ICS sérülékenységek LXXXVI

Sérülékenységek Eaton és Belden termékekben

A tegnapi napon két, ICS sérülékenységekkel kapcsolatos bejelentést tett közzé az ICS-CERT.

Eaton ePDU sérülékenység

Az első az ICS sérülékenységek kapcsán a blogon is gyakran emlegetett Maxim Rupp által az Eaton ePDU nevű, rack-szekrényekbe szerelhető eszközök szoftverében felfedezett sérülékenység, ami könyvtár-bejárásos támadásra ad lehetőséget és ezen keresztül egy támadó hozzáférhet az eszköz konfigurációs állományaihoz. A hiba az alábbi termékeket érinti:

- az EAMxxx 2015. június 30-a előtt gyártott példányai;
- az EMAxxx 2014. január 31-e előtt gyártott példányai;
- az EAMAxx 2014. január 31-e előtt gyártott példányai;
- az EMAAxx 2014. január 31-e előtt gyártott példányai és
- az ESWAxx január 31-e előtt gyártott példányai.

Mivel a fenti termékek támogatását a gyártó 2014. január 31-én illetve 2015. június 30-án beszüntette, ezért a hibával kapcsolatos javítást nem fog kiadni. Azoknak az ügyfeleinek, akik még mindig az érintett termékeket használják, az Eaton weboldalán elérhető, elektromos áram elosztó rendszerek kiberbiztonságával kapcsolatos publikációjának mélységi védelemről szóló ajánlásainak alkalmazását javasolja.

A hibával kapcsolatos további részleteket az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-026-01

Belden Hirschmann GECKO sérülékenység

Davy Douhine, a RandoriSec munkatársa ugyancsak egy könyvtár-bejárásos támadást lehetővé tevő hibát talált a Belden Hirschmann GECKO Lite Managed switch-einek 2.0.00 és ennél korábbi firmware-verzióiban. A gyártó a 2.0.01-es verzióban javította a hibát és elérhetővé tette a weboldalán.

A hibával kapcsolatosan bővebb információkat a Belden és az ICS-CERT publikációiban lehet találni.

ICS sérülékenységek LXXXV

Schneider Electric Wonderware Historian sérülékenység

Az ICS-CERT bejelentése szerint Ruslan Habalov és Jan Bee, Google ISA Assessments Team munkatársai egy, a bejelentkezési adatok kezelésével kapcsolatos hibát azonosítottak a Schneider Electric Wonderware Historian 2014 R2 SP1 P01 és korábbi verzióiban.

A hiba javításáról jelenleg nincs információ. A gyártó az alábbi kockázatcsökkentő intézkedéseket javasolja:

1. Be kell azonosítani, hogy a bejelentkezési adatok a rendszerben hol vannak használva. Ilyen funkciók lehetnek többek között:
 - Wonderware Historian kliens;
 - Wonderware InTouch és Application Object scriptek;
 - Wonderware Information Server konfiguráió és
 - Egyedi, nem a Schneider Electric által fejlesztett alkalmazások, amik a történeti adatokhoz férnek hozzá.
2. A nem használt felhasználói fiókokat az SQL Server Management Studio-ban le kell tiltani.
3. A használatban lévő felhasználói fiókok esetén le kell cserélni a fiókokhoz tartozó jelszavakat.

A gyártó ajánlásain túl az ICS-CERT ezúttal is az ismert kockázatcsökkentő intézkedések végrehajtá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 hibáról további információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-024-01

33C3: On Smart Cities, Smart Energy, And Dumb Security

Előadás az okosmérők kiberbiztonsági problémáiról

A tavaly év végi, 33. C3 másik, ICS kiberbiztonsági témához kapcsolódó előadását Netaniel Rubin, a VAUltra munkatársa tartotta az okosvárosok és az okos villamosenergia-rendszer alapját képező okos mérőórák biztonsági problémáiról és ezek lehetséges hatásairól. Az előadásról készült felvétel itt érhető el.

Maga az előadás is érdekes, de legalább ilyen érdekesek az utána elhangzó kérdések. Különösen az első kérdezőn/hozzászóló megjegyzése érdekes, mert nagyon jól mutatja, hogy milyen sokan még mindig csak a tagadás állapotában vannak az ICS kiberbiztonsági problémákkal kapcsolatban.

Az előadásról egy részletesebb cikk jelent meg a SecurityWeek oldalán.

ICS sérülékenységek LXXXIV

Schneider Electric homeLYnk Controller sérülékenység

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.

ICS sérülékenységek LXXXIII

Sérülékenységek Phoenix Contact és GE Proficy rendszerekben

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!

33C3: Pin Control Attack

PLC-k elleni támadási lehetőségek bemutatója a 33C3-on

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ő.

ICS sérülékenységek LXXXII

Advantech WebAccess, VideoInsight Web Client és Carlo Gavazzi VMU-C sérülékenységek

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!

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