Schneider Electric Modbus protokoll sérülékenységek

Az ICS-CERT publikációja szerint a Schneider Electric Modicon PLC-iben hazsnált Modbus protokollban két sérülékenységet azonosított Eran Goldstein, a CRITIFENCE munkatársa. A hibák a Modicon Modbus protokoll minden verziójában jelen vannak. Az első hiba az authentikációs adatokat tartalmazó hálózati csomagok újraküldésével az authentikációs folyamat megkerülését teszi lehetővé, a második pedig a biztonságos rendszertervezés alapelveinek megsértéséből adódik.

A gyártó a fenti hibákkal kapcsolatban kockázatcsökkentő intézkedésekre vonatkozó javaslat-csomagot tett közzé:

- A Momentum M1E vezérlők közül a 171CBU98090-es és 171CBU98091-es modellek összes verzióját használó ügyfeleknek azt javasolják, hogy tűzfalak alkalmazásával kontrollálják az eszközök 502/tcp portjára irányuló vagy onnan kiinduló kapcsolatokat, mert ezeknél az eszközöknél egyéb kompenzáló kontrollok nem állnak rendelkezésre.
- A Modicon M340, M580, Premium és Quantum felhasználók számára a Schneider Electric az alábbi intézkedések bevezetését javasolja:
 - Engedélyezzék a PLC-hez történő csatlakozáshoz szükséges authentikációt;
 - Engedélyezzék az M340-es, Premium és Quantum eszközökön azt a védelmi funkciót, amivel tiltani lehet a távoli kapcsolatokat illetve a futtatás/leállítás parancsokat;
 - Engedélyezzék a PLC-ken az ACL-ek működését (én már csak azt az egyet szeretném tudni, hogy ha ezek a funkciók mind léteznek a Schneider Electric PLC-in, miért is nem az az alapértelemezett beállítás, hogy működnek is és ha a felhasználási körülmények indokolják, ki lehet kapcsolni őket?)
 
A fenti hibákkal kapcsolatban további információkat a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

A Ponemon Institute a Siemens megbízásából készített egy felmérést az USA olaj és gázipari szereplői körében azt kutatva, hogy az ebben a szektorban működő cégek hogyan látják a szervezeteik kiberbiztonsági kockáaztait. A felmérésről készült publikáció néhány hete jelent meg, ebben 8 pontban foglalták össze a fontosabb megállapításokat:

1. A válaszadók 59 %-a szerint az OT (Operations Technology) kockázatai nagyobbak, mint az IT kockázatok és 67 % szerint az ipari rendszerek kockázatai az elmúlt években jelentősen nőttek, elsősorban a kiberbiztonsági helyzet romlása miatt.

2. Az olaj- és gáztársaságok egyöntetűen profitálnak a digitalizációból, de a válaszadók 66 %-a szerint ugyanakkor a digitalizáció jelentős kockázatnövekedést is hozott.

3. A felmérésben résztvevők 68 %-a tapasztalt már kibertámadást, mégis nagyon sok szervezetnél nem veszik elég komolyan az OT kiberbiztonsági kockázatait vagy az ezzel kapcsolatos stratégia kialakítását.

4. A válaszolók 61 %-a szerint az ipari rendszereik esetében alkalmazott biztonsági megoldások és eljárások nem biztosítanak megfelelő szintű védelmet.

5. A megkérdezettek 65 %-a gondolta úgy, hogy a legnagyobb fenyegetést a saját munkatársak hanyagsága jelenti és 15 % válaszolta azt, hogy ártó szándékú külső támadó - ezzel is megerősítve az igényt a fejlett monitoring megoldásokra, amikkel a munkatársak által végrehajtott műveleteket  lehet viselkedéselemzésnek alávetni.

6. A válaszadóknak csak 41 %-a mondta azt, hogy folyamatosan monitorozzák az ICS infrastruktúrát, hogy értékelni tudják a fenyegetéseket és támadásokat. A felmérések szerint az OT-t érő támadások 46 %-át az érintett szervezetek észre sem veszik. Ezek a számok azt mutatják, hogy komoly fejlesztésekre lenne szükség az olaj- és gázszektor szervezeteinél annak érdekében, hogy jobban átlássák és megértsék, mi történik a rendszereikkel egy adott pillanatban.

7. A felmérésben résztvevők 68 %-a szerint a biztonsági elemzés alapvető vagy nagyon fontos a hatékony biztonság kialakításához.

8. A válaszolóknak kevesebb, mint kétharmada mondta azt, hogy a felhasználói viselkedést elemző rendszerek és a biztonsági hardeningen átesett végponti eszközök hatékony eszközök a biztonság megteremtésében. 62 % szerint az adatok rendszerek és rendszerelemek közötti küldése során alkalmazott titkosítás nagyon hatékony, ennek ellenére sok szervezet nem tervezi ezeknek a technológiáknak az alkalmazását.

A PI tanulmánya (benne számos további érdekes részlettel) szabadon elérhető a BusinessWire oldalán.

Talán nem vagyok egyedül azzal a véleményemmel, hogy egyszer érdekes lenne hasonló kutatást magyar ipari szereplőkkel elvégezni.

Az ICS-CERT bejelentése szerint Sebastian Neef, az Internetwache.org munkatársa több sérülékenységet fedezett fel a német Certec EDV GmbH Atvise scada nevű termékének 3.0 és ennél korábbi verzióiban. A hibák Cross-site scripting és fejléc-befecskendezéses támadásra adnak lehetőséget, amiken keresztül egy támadónak tetszőleges kódfuttatásra nyílik lehetősége, ezzel akár az eszköz sértetlenségét is befolyásolhatja.

A gyártó a hibákat a 3.1-es verzióban javította, amit az érintett ügyfelek a Certec EDV Gmbh weboldaláról tölthetnek le.

A sérülékenységekről további információkat az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-17-096-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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Tegnap este egy érdekes cikket olvastam a hwsw.hu-n arról, hogy miért esett ki tavaly decemberben a Delta Airlines adatközpontja és mi okozta a kiesést. A részletek a cikkben olvashatóak, dióhéjban az történt, hogy az áramkimaradás idejére üzembe helyezett tartalék generátorok védelmi reléiben használt PLC-k feszültségingadozást észleltek az áramszolgáltató vonalán bekövetkezett betáp-kiesés után, amit a PLC belső logikája úgy értelmezett, hogy az adatközpont villamosenergia-rendszerében valahol rövidzárlat van, ezért a generátorokat védve nem engedte csatlakoztatni őket az adatközponti hálózatra. Emiatt a generátorok fogyasztók nélkül, "üresben" működtek, a szerverek pedig a szünetmentes áramforrások lemerülése után leálltak.

A cikk szerint hasonló történt már az Amazon egyik adatközpontjában is, abban az esetben a PLC gyártója még az Amazon kifejezett kérésére sem volt hajlandó olyan, módosított firmware-t szállítani a védelmi relék PLC-ihez, amiben felülbírálható lett volna a generátort védő logika. Emiatt - írja a hwsw.hu - az Amazon adatközpontjaiban ma már azok a villamosmérnökök írják a PLC-k firmware-jeit, akik az adatközponti villamosenergia-ellátásért felelősek. Itt meg is érkeztünk a ma poszt elején feltett kérdéshez: ICS biztonsági szempontból jó-e, ha az OT munkatársai írják a saját maguk üzemeltette eszközökön futó szoftvereket?

Az ICS kiberbiztonság területén dolgozók hosszú ideje próbálják terjeszteni azt a nézetet, hogy a biztonságos programozásnak az ipari rendszerek világába is utat kell találni. Ennek megértése és alkalmazása az ICS gyártók részéről még a IT szoftverfejlesztők meggyőzésénél is fontosabb feladat kéne, hogy legyen, hiszen egy IT-ban használt szoftver életciklusa jellemzően 1-2-3 év lehet és ez az idő egyre csökken, ráadásul a feltárt hibákat rövid idő alatt lehet javítani. Ezzel szemben az ICS rendszereknél egy már élesbe állított rendszert 10-15-20 évig fognak használni és jóval ritkábbak a hibajavítások telepítésének lehetőségei is.

Természetesen ezzel nem azt mondom, hogy ez egy elhibázott út, hiszen ha egy szervezet a beszállítóitól nem kapja meg azt a funkcionalitást egy rendszerben, amire szüksége van és van lehetősége egyedileg fejleszteni, akkor nem igen van más lehetősége. Azonban ha ezt választják, mindenképp nagyon alapos kockázatelemzéseket kell folytatniuk a saját fejlesztésű szoftverek teljes életciklusa során és ha ilyen alapvető fontosságú szoftverelemeket fejlesztenek házon belül, hangsúlyt kell fektetniük a szoftverfejlesztés biztonsági szempontú minőségbiztosítására is, különben elképzelhető, hogy egy funkcionalitásában már-már tökéletes, de a támadók számára könnyen kompromittálható rendszert építenek, ami immár a szoftveres sérülékenységei miatt nem lesz képes az elvárásoknak megfelelően működni.

Schneider Electric Interactive Graphical SCADA System Software sérülékenység

Az ICS-CERT publikációja szerint Karn Ganeshen egy DLL Hijacking hibát talált a Schneider Electric IGSS Software 12-es és korábbi verzióiban. A gyártó a hibával kapcsolatban azt javasolja az érintett ügyfeleknek, hogy az IGSS-t futtató Windows operációs rendszereket cseréljék Windows 10-re, amiben már kötelező a DLL-ek használata esetén a fix útvonalak használata.

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

Marel élelmiszer-feldolgozó rendszerek sérülékenységei

A Marel egy izlandi, az élelmiszer iparban és az agráriumban jelen lévő automatizálási vállalat. Az ICS-CERT-en megjelent információk alapján Daniel Lance két hibát talált az alábbi termékeikben:

- Az alábbi termékekkel használt M3000, M3210-es terminálok, M3000 desktop szoftver, MAC4 kontroller:
  - A320;
  - A325;
  - A371;
  - A520 Master;
  - A520 Slave;
  - A530;
  - A542;
  - A571;
  - Check Bin Grader;
  - FlowlineQC T376;
  - IPM3 Dual Cam v132;
  - IPM3 Dual Cam v139;
  - IPM3 Single Cam v132;
  - P520;
  - P574;
  - SensorX13 QC flow line;
  - SensorX23 QC Master;
  - SensorX23 QC Slave;
  - Speed Batcher;
  - T374;
  - T377;
  - V36;
  - V36B;
  - V36C;
- A Sensor X23 és Sensor X25 röntgengépek;
- Az MWS2 mérőrendszer.

Az első hibát a fenti rendszerekbe beégetett jelszavak okozzák, a másodikat pedig a rendszerekbe ellenőrzés nélkül feltölthető fájlokkal lehet kihasználni.

A gyártó mostanáig nem készített javítást a fenti sérülékenységekhez.

További információkat az ICS-CERT bejelentésében lehet olvasni a sérülékenységekről: https://ics-cert.us-cert.gov/advisories/ICSA-17-094-02

Rockwell Automation rendszerek sérülékenységei

A Rockwell Automation a nemrég publikált IOS/IOS XE CMP hiba nyomán fedezte fel, hogy a sérülékeny IOS és IOS XE kódokat használó Allen-Bradley Stratix és ArmoredStratix ipari környezetbe tervezett hálózati eszközeit is érinti a CIA exploit-gyűjteményének napvilágra kerülésével ismertté vált hiba.

Átmeneti kockázatcsökkentő intézkedésként a Rockwell Automation is azt javasolja, hogy az sérülékeny eszközöket használó ügyfelei tiltsák le az érintett hálózati eszközökön a Telnet szolgáltatást. Amennyiben valaki nem teheti meg, hogy letiltja a Telnet szoltáltatást, infrastructura ACL-ek (iACL) alkalmazásával csökkentheti a sérülékenység okozta támadási felületet. Ezzel kapcsolatban a Rockwell Automation-nél regisztrációval rendelkező ügyfelek a 1040270-es számú tudásbázis cikkben találhatnak további információkat.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-094-03

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

CODESYS Web Server sérülékenységek

David Atch, a CyberX munkatársa 2 hibát fedezett fel a 3S-Smart Software Solutions GmbH által gyártott CODESYS Web Server nevű termékében. A hibák a 2.3 és ennél korábbi verziókban található meg.

Az első hiba lehetővé teszi egy támadó számára, hogy speciális webszerver hívásokkal a jogosultsági rendszert megkerülve tetszőleges fájlt töltsön fel a CODESYS Web Server-re, ami távoli kódfuttatási lehetőséget biztosíthat a támadónak. A másik hiba egy verem túlcsordulási hiba.

A gyártó a sérülékenység által érintett ügyfelek számára azt javasolja, hogy telepítsék a V.1.1.9.18 verziójú hibajavítást.

A sérülékenységről további információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-087-02

Schneider Electric Wonderware InTouch Access Anywhere sérülékenység

Ruslan Habalov és Jan Bee, a Google ISA Assessments Team tagjai 3 hibát találtak a Schneider Electric Wonderware InTouch Access Anywhere termékében. A hibák a Wonderware InTouch Access Anywhere 11.5.2 és ennél korábbi verzióit érintik. A hibák között Cross-site request forgery mellett van egy speciális URL-en keresztül bejelentkezés adatokat elérhetővé tevő hiba és nem megfelelően implementált TLS titkosítás is található.

A Schneider Electric a hibákat a Wonderware InTouch Access Anywhere 2017 (17.0.0) verzióban javította.

A sérülékenységről további információkat az ICS-CERT bejelentésében lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-089-01

Schneider Electric Modicon PLC sérülékenységek

David Formby és Raheem Beyah, a Georgia Tech és a Fortiphyd Logic Inc. munkatársai 3 különböző sérülékenységet találtak a Schneider Electric Modicon PLC-inek különböző verzióiban.

Az első hiba, ami a nem kellően véletlenszerű értékek generálásával megjósolhatóvá teszi a kezdeti TCP szekvencia értéket, az alábbi Modicon PLC-ket érinti:

- Modicon M221, ha 1.5.0.0-nál régebbi firmware-verzióval működnek;
- Modicon M241, ha 4.0.5.11-nél régebbi firmware-verziót futtatnak;
- Modicon M251, ha 4.0.5.11-nél régebbi firmware-verzióval működnek.

A második sérülékenység a webes alkalmazás által használt, nem kellően véletlenszerű session-szám generálására vezethető vissza, ami a következő Modicon PLC-kben található meg:

- Modicon M241, ha 4.0.5.11-nél régebbi firmware-verziót futtatnak;
- Modicon M251, ha 4.0.5.11-nél régebbi firmware-verzióval működnek.

A harmadik hibát az okozza, hogy az alább felsorolt PLC-k a felhasználói adatokat a hálózaton keresztül Base-64 kódolással küldik át:

- Modicon M241, minden firmware-verziónál;
- Modicon M251, minden firmware-verziónál.

A gyártó a nem megfelelően véletlenszerű véletlenszám-generálásból adódó hibákra kiadta a hibákat javító frissítéseket, amiket az ügyfelek a a Schneider Electric szoftverfrissítő megoldásokon, a SoMachine 4.2-es és a SoMachineBasic 1.5-ös verzióival érhetik el. A felhasználói adatok nem megfelelő titkosítással történő hálózati továbbításából adódó hibára mostanáig nem érkezett javítás. Ezzel a hibával kapcsolatban a gyártó néhány kockázatcsökkentő tanácsot tett közzé:

- Az érintett eszkzöket és a velük kapcsolatba kerülő minden hardvert és szoftvert az ISA/IEC 62443-as szabványában foglaltaknak megfelelő tervezési és üzemeltetési szabályok szerint javasolt telepíteni és üzemeltetni;
- A helyi hálózat forgalmát a hálózati eszközökön szabályozva a minimálisan szükségesre javasolt korlátozni;
- Amennyiben lehetséges, kerülni kell a vezeték nélküli hálózatok használatát. Ha ez nem megoldható, kizárólag WPA2 szintű titkosítással javasolt vezeték nélküli kommunikációt használni;
- Ismeretlen számítógépeknek ne tegyék lehetővé a hálózati hozzáférést;

A Modicon PLC-k fenti hibáival kapcsolatban a gyártó és az ICS-CERT publikációi tartalmaznak további rézsleteket:

http://www.schneider-electric.com/en/download/document/SEVD-2017-075-01/
http://www.schneider-electric.com/en/download/document/SEVD-2017-075-02/
http://www.schneider-electric.com/en/download/document/SEVD-2017-075-03/
https://ics-cert.us-cert.gov/advisories/ICSA-17-089-02

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áltasáok 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ű (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 laborkörülményekben célszerű tesztelni, mielőtt az éles (és tartalék) rendszerekben alkalmaznák azokat.

Ma már több, különböző ICS/SCADA-biztonsági képzést lehet találni, de ezek közül az első az Idaho National Labs (INL) 5 napos ICS Cyber Security Advanced Training névre hallgató képzése volt, amit még a 2000-es évek derekán, jóval a Stuxnet nyilvánosságra kerülése előtt szerveztek meg először az amerikai Belbiztonsági Minisztérium (Department of Homeland Secuirty, DHS) fennhatósága alatt. Azóta évente többször is megrendezik ezt a képzést, amire elsősorban az USA-ban működő, ICS rendszereket üzemeltető szervezetek munkatársait (elsősorban az OT és az IT biztonsági területeken dolgozó szakembereket) várják, de lehetőség van máshonnan, többek között Európából is jelentkezni ezekre a képzésekre. Itthon is dolgozik néhány több ICS üzemeltető, akiknek már volt lehetőségük végigcsinálni az Idaho Falls-i képzést.

Maga a tanfolyam 5 (igazából csak 4,5) napból áll, ebből az első három nap tantermi oktatás és a bemutatott támadási és védekezési módok és eljárások gyakorlásáról szól. A negyedik és ötödik napon a résztvevők egy szimulált ipari szervezet elleni támadást modellező gyakorlat védekező (kék) illetve támadó (piros) csapataiba kerülnek beosztásra és a valós körülményekhez erősen hasonlító szituációkban kell bizonyítaniuk, hogy mennyit sikerült tanulniuk az első három nap során.

A tantermi képzés 13 fejezetre van felosztva, ezek az alábbiak:

1. Alapvető ICS és SCADA rendszerek áttekintése
2. Hálózatbiztonsági alapok - offenzív eszközök (ismerkedés a BacktTrack/Kali Linux-szal - nekem egy 2010 tavaszi képzés anyagát sikerült átnéznem, ebben még a BackTrack 4-et oktatták -, Metasploit-tal, Nessus-szal)
3. Hálózatbiztonsági alapok - defenzív eszközök (IDS/IPS-alapok, hálózatszegmentálás, hálózati auditáló és elemző ezsközök, naplózás és naplóelemzés)
4. A biztonságtudatosság szerepe (az incidenskezelés rövid áttekintése, az ICS-CERT szerepe, az ICS-CERT és a malware-elemzés)
5. Nyomrögzítsés ICS/SCADA rendszerekben észlelt incidensek után
6. ICS/SCADA rendszerek gyakori sérülékenységei
7. Ismerkedés a Cyber Security Evaluation Toolkit-tel (CSET)
8. Hálózatfelderítési technikák és eszközök
9. A Metasploit Framework-ről bővebben
10. A Snort IDS-ről bővebben
11. A hálózatbiztonsági hibák kihasználási módjai
12. Linux üzemeltetési alapok
13. Windows üzemeltetési alapok

Akit a képzés bővebben is érdekel, az Idaho National Labs weboldalán további információkat találhat.

Sérülékeny Cisco IOx alkalmazások

A Cisco bejelentése szerint az IOx alkalmazás környezetekben használt Data-in-Motion folyamatban egy verem túlcsordulásos hibát találtak. A sérülékenység a Cisco 800-as sorozatú ipari router-ei közül alábbiakat érinti, amennyiben az 1.0.0.0 vagy az 1.1.0.0 verziót futtatják:

- Cisco IR809;
- Cisco IR829.

A hiba kihasználásával egy támadó root jogosultsággal távoli kódfuttatási lehetőséghez juthat. A gyártó az IOx 1.2.4.2-es verzióban javította a hibát.
A sérülékenységről további információkat a Cisco bejelentésében lehet olvasni: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170322-iox

Schneider Electric VAMPSET memóriakorrupciós hiba

A Schneider Electric egy memóriakorrupciós hibát azonosított a VAMPSET nevű, védelmi relékhez használt konfigurációs szoftver eszközében. A sérülékenység a VAMPSET v2.2.189-nél korábbi verzióiban található meg. A gyártó a hibát a v2.2.191-es verzióban javította.

A sérülékenységről bővebb információkat a gyártó által publikált dokumentumból lehet megtudni.

Siemens RUGGEDCOM sérülékenységek

A Siemens legújabb sérülékenységi publikációjában a RUGGEDCOM ROX I minden verzióját érintő hibákról számol be. Összesen öt különböző sérülékenységről van szó, amik a RUGGEDCOM ROX I eszközök integrált webszerverével hozhatóak kapcsolatban. A bejelentésben az alábbi hibákról írnak:

- Tetszőleges fájlokhoz történő olvasási jogosultság szerzése bármilyen jogosultságú, sikeres authentikáció után;
- Cross-site scripting;
- Session hijacking;
- Jogosultsági rendszer megkerülését lehetővé tevő hiba;
- Cross-site scripting.

A gyártó által publikált információk alapján egyelőre nincs hír a fenti hibákat javító szoftverfrissítésről. A Siemens az alábbi kockázatcsökkentő intézkedések bevezetését javasolja az sérülékenységek által érintett eszközeit használó ügyfelei számára:

- Tiltsák le az eszközök webes interfészét;
- Tiltsák le az eszközökön a Vendég és Operátor felhasználói fiókokat;
- Korlátozzák az eszközök elérését, hogy csak a megbízható adminisztrátorok rendelkezzenek hozzáféréssel;
- Alakítsanak ki mélységi védelmet (Defense-in-Depth) és alkalmazzák a Siemens saját, Cell protection védelmi koncepcióját;
- Használjanak VPN-megoldást az egyes, kiemelten fontos hálózati zónák közötti kommunikáció biztonságosabbá tételéhez.

A sérülékenységekkel kapcsolatban további részleteket a Siemens ProductCERT bejelentése tartalmaz.

LCDS LAquis SCADA sérülékenység

Karn Ganeshen a ZDI-vel együttműködve talált egy könyvtár-bejárást lehetővé tevő hibát, ami a LAquis SCADA 4.1.0.3237-nél korábbi verzióiban.

A sérülékenységet a gyártó a 4.1.0.3237-es verzióban javította, amit a weboldalán tudnak letölteni a sérülékeny verziót használó ügyfelek.

A hibáról további információkat az ICS-CERT bejelentésében lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-082-01

Sérülékenységek BD PerformA és KLA termékekben

A gyártó Becton, Dickinson and Company (BD) jelezte az ICS-CERT-nek, hogy több termékében beégetett jelszavak vannak használatban BD Kiestra adatbázis-hozzáférések esetében. Az érintett termékek:

- PerformA, 2.0.14.0 és korábbi verziók;
- KLA Journal Service, 1.0.51 és korábbi verziók.

A gyártó a sérülékenység hatásának csökkentése érdekében egy frissítést készített, ami az alábbi verziókban jelenik meg:

- PerformA, Version 2.0.14.0;
- KLA Journal Service, Version 1.0.51;
- Kiestra Database, Version 3.0.61.

Ezzel kapcsolatban a legérdekesebb részlet, hogy ezeket a frissítéseket az érintett eszközök az ICS-CERT bejelentése szerint távolról fogják megkapni - ebből arra lehet következtetni, hogy gyártónak alapértelmezetten távoli hozzáférése van minden telepített rendszerhez.

A BD további kockázatcsökkentő intézkedéseket is javasol:

- Az adatbázis, fájl-, alkalmazás és mentő szervereken le kell tiltani az SMB1 protokollt, amennyiben az aktív;
- A 3050/tcp portot kizárólag a BD Kiestra alkalmazás számára kell elérhetővé tenni.

A sérülékenységről további információkat a gyártó és az ICS-CERT bejelentései tartalmaznak további részleteket.

Az elmúlt években a különböző (szakmai és mainstream) sajtóorgánumok újra és újra szenzációként hozták le, amikor ipari rendszerekben vagy kritikus infrastruktúrák egyes rendszereiben fedeztek fel malware-eket. Ezek döntő többsége nem az ipari rendszerek elleni célzott támadáshoz fejlesztett malware-ek voltak, általában egy-egy általános kártevő talált magának utat az ICS rendszerekig. Egy másik látható tendencia, hogy különböző IT biztonsági területen tevékenykedő cégek kezdik felkapni az ICS biztonság témáját, gyakran nagyobbnak mutatva a veszélyt, mint amekkora az valójában.

Ezek a körülmények késztették a Dragos Inc. alapítóját, Robert M. Lee-t a MIMICS (Malware In Modern Industrial Control Systems) projekt elindítására. A MIMICS publikus adatokból (pl. a VirusTotal-ra feltöltött fájlok elemzéséből) próbál adatokat leszűrni  az ICS rendszerekben felfedezett malware-ekre vonatkozóan. Ennek a kutatásnak az első fázisáról jelent meg a héten egy blogpost, ami három jelentős megállapítást tartalmaz:

1. A nem célzott, általános IT malware-támadások száma az ICS rendszerekben nagy

A kutatás első fázisában a Dragos munkatársai 2003-tól napjainkig mintegy 30.000 mintát találtak olyan fertőzött fájlokból, amik ICS rendszerekhez tartoznak. Ezek között a legnagyobb számban a gyorsan terjedő malware-családok képviselői (pl. Ramnit) találhatóak, jóval kisebb számban találhatóak meg a különböző trójaiak, amik viszont már hozzáférést is adhatnak támadóknak a megtámadott ICS rendszerhez, amennyiben azoknak van Internet-kapcsolatuk. Az utóbbi kategóriába tartozó malware-ek, bár nem célzott támadások eszközei, mégis jelentős negatív hatásuk lehet az ipari rendszerekre/kritikus infrastruktúrákra.

Az elemzés alapján éves szinten nagyjából 3000 ipari helyszínen tűnhetnek fel tradícionális IT malware-ekre visszavezethető, nem célzott támadásból származó fertőzések. Ezek az incidensek még nem jelentik azt, hogy az ipari környezetekben/kritikus infrastruktúrákban bármelyik pillanatban katasztrófa történhet, de az ICS rendszereket üzemeltetőknek tudniuk kell, hogy egyszerű biztonsági eszközök és eljárások (pl. hálózatbiztonsági monitoring) bevezetésével jelentősen javítani tudják az ICS rendszerek biztonsága mellett a megbízhatóságukat is.

2. A célzott, ICS rendszerek elleni malware-támadások nem is olyan ritkák

Bár a kifejezetten ICS rendszerek ellen készült malware-ek száma alacsony, nyilvánosságra mindmáig csak három (Stuxnet, Havex, BlackEnergy2) került és további egyről vagy kettőről lehet pletykákat hallani, illetve az elmúlt évben két proof-of-concept malware-ről röppentek fel hírek, a Stuxnet nagyon magasra tette a mércét az ICS rendszerek támadására kialakított malware-ek esetén. Az érem másik oldala, hogy az ukrán áramszolgáltatók elleni 2015 decemberi támadás megmutatta azt is, hogy egy támadónak nem szükséges magas szinten specializált malware-t használni ahhoz, hogy komoly üzemzavart tudjon előidézni egy ipari rendszerben.

Az ICS rendszerekre szabott malware-ek egy kis csoportját képezik az ICS témájú malware-ek, azok a kártevők, amiket a támadók legitim ICS alkalmazásnak álcáznak, így próbálva rávenni az ICS rendszerek felhasználóit és üzemeltetőit. A kutatás során az egyik vizsgált feltételezés az volt, hogy sok IT biztonsági cég nem tudják, mit kell keresniük, hogy meg tudják különböztetni a legitim szoftvereket az ICS témájú malware-ektől. A Dragos munkatársai vagy egy tucatnyi ICS témájú malware-támadással kapcsolatban találtak információkat. Ebből a tucatnyi malware-ből az egyik különösen érdekes volt, ez Siemens PLC vezérlő szoftvernek álcázta magát és először 2013-ban tűnt fel. Több különböző antivirus gyártó terméke fals pozitívnak jelezte ezt a malware-t és az elmúlt 4 évben végül 10 különböző helyen tűnt fel, legutóbb most, 2017 márciusában - vagyis 4 évvel az első feltűnése után egy magát Siemens PLC szoftverként feltűntető malware még mindig aktív fertőzéseket tud okozni. A konkrét eset részleteinek kiderítésén a MIMICS kutatásban résztvevők jelenleg is dolgoznak. Ez persze nem egyedi eset, ráadásul Európában a különböző kritikus infrastruktúráknak csak az EU NIS nemzeti jogrendszerekbe illesztése fogja előírni a kiberbiztonsági incidensek jelentésének kötelezettségét, így még csak megtippelni sem lehet, hogy jelenleg vajon hány európai ipari rendszerben észlelhetnek malware-támadásokat - és hány ilyen támadás történhet meg úgy, hogy észre sem veszik?

3. Üzemeltetés biztonsági problémák

A kutatás következő hipotézise szerint számos legitim ICS szoftverkomponenst sorolhatnak be malware-ként a különböző antivirus rendszerek, amikor valaki helytelenül feltölti őket a VirusTotal-ra vagy más, hasonló nyilvános adatbázisba. A kutatás során több ezer különböző ICS szoftverkomponenst találtak ezekben adatbázisokban, többek között HMI, történeti adatbázis-telepítőket, de több mint száz különböző projektfájlt és számos, ICS rendszerrel kapcsolatos jelentést (köztük az USA Nukleáris Szabályozó Bizottságának, az NRC-nek a jelentéseit is!). Nagyon fontos következtetésnek tűnik, hogy az ICS rendszereket üzemeltető szervezetek IT biztonságért felelős munkatársai számára egyértelmű információkat kell biztosítani a legitim szoftverekről (az egyszerűbb tulajdonságoktól egészen a fájlok checksum-jaiig) és mik azok az állományok, amiket nem szabad feltölteni az Internetre (ezzel is csökkentve annak az esélyét, hogy egy támadó hozzájuthasson egy, a szervezet által használt fájlhoz, hogy a későbbi támadása előtt tanulmányozhassa azt).