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

ICS Cyber Security blog

ICS Cyber Security blog

Nem célzott malware-támadások hatása az ICS rendszerekre

A Dragos Inc. tanulmánya szerint évente átlagosan 3000 nem célzott malware-támadás éri az ipari rendszereket

2017. március 25. - icscybersec

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

ICS sérülékenységek XCIX

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

Rockwell Automation Connected Components Workbench sérülékenység

Ivan Sanchez jelentte a Rockwell Automation-nek, hogy Connected Components Workbench nevű, szoftverkonfigurációs platformjuk alábbi verzióiban DLL hijacking hibát talált:

- Developer Edition, v9.01.00 és korábbi verziók:
  - 9328-CCWDEVENE;
  - 9328-CCWDEVZHE;
  - 9328-CCWDEVFRE;
  - 9328-CCWDEVITE;
  - 9328-CCWDEVDEE;
  - 9328-CCWDEVESE;
  - 9328-CCWDEVPTE;
- Free Standard Edition (minden támogatott nyelven), v9.01.00 és korábbi verziók.

A gyártó a hibát a Connected Components Workbench, Version 10.00 illetve a Version 10.01 (minden támogatott nyelven) verziókban javította.

A hibával kapcsolatban további információkat az ICS-CERT publikációjában lehet találni: https://ics-cert.us-cert.gov/advisories/ICSA-17-047-01

Rockwell Automation FactoryTalk Activation sérülékenység

A Rockwell Automation a FactoryTalk Activation nevű, FactoryTalk Services Platform komponensben talált egy hibát, amit kihasználva egy már sikeresen bejelentkezett felhasználó tetszőleges (akár emelt jogosultsági szintű) kódfuttatási lehetőséget szerezhet. A hiba a FactoryTalk Activation Service, Version 4.00.02 és korábbi verzióiban van jelen. Ezt a komponenst a Rockwell Automation számos termékében használja:

- Arena,
- Emonitor,
- FactoryTalk AssetCentre,
- FactoryTalk Batch,
- FactoryTalk EnergyMetrix,
- FactoryTalk eProcedure,
- FactoryTalk Gateway,
- FactoryTalk Historian Site Edition (SE),
- FactoryTalk Historian Classic,
- FactoryTalk Information Server,
- FactoryTalk Metrics,
- FactoryTalk Transaction Manager,
- FactoryTalk VantagePoint,
- FactoryTalk View Machine Edition (ME),
- FactoryTalk View Site Edition (SE),
- FactoryTalk ViewPoint,
- RSFieldBus,
- RSLinx Classic,
- RSLogix 500,
- RSLogix 5000,
- RSLogix 5,
- RSLogix Emulate 5000,
- RSNetWorx,
- RSView32,
- SoftLogix 5800,
- Studio 5000 Architect,
- Studio 5000 Logix Designer,
- Studio 5000 View Designer,
- Studio 5000 Logix Emulate.

A hibát a Rockwell Automation a FactoryTalk Activation Version 4.01-ben javította és minden, érintett rendszerét használó ügyfelének a mielőbbi frissítést javasolja. Kockázatcsökkentő intézkedésként a KB939382-es tudásbázis cikkben leírtak alkalmazását javasolja.

A sérülékenységről további információkat az ICS-CERT bejelentéséből lehet megtudni: https://ics-cert.us-cert.gov/advisories/ICSA-17-047-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.

ICS sérülékenységek XCVIII

Sérülékenység a Cisco ipari környezetbe szánt hálózati eszközeiben

A máricus 7-én, a Wikileaks által nyilvánosságra hozott CIA-s exploit-gyűjtemény (amiről nagyon sokan írtak az azóta eltelt közel két hétben, a szerintem egyik legérdekesebb nézőpontot képviselő írás itt található: http://freszbook.blogspot.hu/2017/03/a-cia-vs-wikleaks-margojara.html) nyomán a Cisco kritikus besorolással tette közzé az IOS és az IOS XE szoftvereik Cluster Management Protocol-jában felfedezett, távoli kódfuttatást (Remote Code Execution, RCE) lehetővé tevő hibát. A sérülékenység 319 különböző Cisco terméket érint, amennyiben a 15.2(5.5.15i)E2-nél korábbi verziójú firmware-t használnak. Minket ezek közül most csak a kifejezetten ipari környezetekbe szánt eszközök érdekelnek igazán (bár a nem ipari felhasználásra tervezett eszközök is jelen lehetnek vezérlőközpontok, alállomások és más létesítményekben, pl. informatikai géptermekben üzemeltetve):

- Cisco IE 2000-16PTC-G Industrial Ethernet Switch;
- Cisco IE 2000-16T67 Industrial Ethernet Switch;
- Cisco IE 2000-16T67P Industrial Ethernet Switch;
- Cisco IE 2000-16TC Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-E Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-N Industrial Ethernet Switch;
- Cisco IE 2000-16TC-G-X Industrial Ethernet Switch;
- Cisco IE 2000-24T67 Industrial Ethernet Switch;
- Cisco IE 2000-4S-TS-G Industrial Ethernet Switch;
- Cisco IE 2000-4T Industrial Ethernet Switch;
- Cisco IE 2000-4T-G Industrial Ethernet Switch;
- Cisco IE 2000-4TS Industrial Ethernet Switch;
- Cisco IE 2000-4TS-G Industrial Ethernet Switch;
- Cisco IE 2000-8T67 Industrial Ethernet Switch;
- Cisco IE 2000-8T67P Industrial Ethernet Switch;
- Cisco IE 2000-8TC Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G-E Industrial Ethernet Switch;
- Cisco IE 2000-8TC-G-N Industrial Ethernet Switch;
- Cisco IE 3000-4TC Industrial Ethernet Switch;
- Cisco IE 3000-8TC Industrial Ethernet Switch;
- Cisco IE-3010-16S-8PC Industrial Ethernet Switch;
- Cisco IE-3010-24TC Industrial Ethernet Switch;
- Cisco IE-4000-16GT4G-E Industrial Ethernet Switch;
- Cisco IE-4000-16T4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4GC4GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4GS8GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4S8P4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4T4P4G-E Industrial Ethernet Switch;
- Cisco IE-4000-4TC4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GS4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GT4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8GT8GP4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8S4G-E Industrial Ethernet Switch;
- Cisco IE-4000-8T4G-E Industrial Ethernet Switch;
- Cisco IE-4010-16S12P Industrial Ethernet Switch;
- Cisco IE-4010-4S24P Industrial Ethernet Switch;
- Cisco IE-5000-12S12P-10G Industrial Ethernet Switch;
- Cisco IE-5000-16S12P Industrial Ethernet Switch.

A sérülékenységet javító patch kiadását a gyártó későbbre ígéri. Mivel a sérülékenység kihasználásához szükség van az érintett eszközökön futó telnet szolgáltatásra, workaroundként a telnet letiltása lehet a megoldás - feltéve, hogy az adott eszközöket a szervezet képes a telnet-nél biztonságosabb módon is üzemeltetni.

További részleteket a sérülékenységgel kapcsolatban a Cisco publikációja tartalmaz: https://tools.cisco.com/security/center/content/CiscoSecurityAdvisory/cisco-sa-20170317-cmp

ICS sérülékenységek XCVII

Hardver-tervezési hiba miatt sérülékenyek a MEMS gyorsulásmérők

Az ICS-CERT bejelentése szerint amerikai egyetemi kutatók egy csoportja (Timothy Trippel, Ofir Weisse, Peter Honeyman és Kevin Fu a University of Michigan-ről és Wenyuan Xu a  University of South Carolina-ról) egy hardver-tervezési hiba okozta sérülékenységet találtak számos, MEMS gyorsulásmérő szenzort használó eszközben:

Bosch BMA222E,
STMicroelectronics MIS2DH,
STMicroelectronics IIS2DH,
STMicroelectronics LIS3DSH,
STMicroelectronics LIS344ALH,
STMicroelectronics H3LIS331DL,
InvenSense MPU6050,
InvenSense MPU6500,
InvenSense ICM20601,
Analog Devices ADXL312,
Analog Devices ADXL337,
Analog Devices ADXL345,
Analog Devices ADXL346,
Analog Devices ADXL350,
Analog Devices ADXL362,
Murata SCA610,
Murata SCA820,
Murata SCA1000,
Murata SCA2100,
Murata SCA3100.

A sérülékenységgel kapcsolatban javításról egyelőre nincs információ, a Robert Bosch GmbH két dokumentumot publikált az esettel összefüggésben, az elsőben további információkat közöl a sérülékenységről, a másodikban pedig az érintett eszközök kezelésével és szerelésével kapcsolatos információkat adtak közre. Egy másik gyártó, az InvenSense Inc. bejelentésében szintén elismerte, hogy az érintett szenzort használó termékeik egyes esetekben a tervezettől eltérően működhetnek.

A sérülékenységgel kapcsolatban további információkat az ICS-CERT publikációjában lehet olvasni: https://ics-cert.us-cert.gov/alerts/ICS-ALERT-17-073-01

Shodan - keresőmotor ICS rendszerek keresésére fejlesztve

Hosszú ideje szerepel a listámon egy blogposzt a Shodan kereső motorról, de ma végre eljött a napja, hogy erről is beszéljünk.

A Shodan-t 2009-ben John Matherly hobbiként kezdte fejleszteni. A projekt elsődleges célja a különböző, Internetre csatlakoztatott eszközök egy, a megszokottól eltérő katalogizálása volt. Míg a Google, a Bing, a Yahoo és a többi nagy keresőoldal az Interneten elérhető tartalom alapján  katalogizálja a különböző weboldalakat és egyéb szolgáltatásokat, a Shodan az eszközök által visszaadott meta-adatok alapján indexeli és teszi kereshetővé a szolgáltatásokat.

A Shodan projekt kezdetben HTTP, HTTPS, FTP, SSH, Telnet, SNMP, SIP és RTSP protokollokra koncentráltak, mára a Shodan által felismert és katalogizált protokollok száma meghaladja a 170-et. Igazán ismertek akkor lettek, amikor 2013-ban a CNNMoney.com-on megjelent egy cikk, amiben a Shodan-ról, már mint olyan keresőről írtak, amivel Internetre csatlakoztatott folyamatirányító rendszereket (a cikkben a közlekedési lámpákat vezérlő PLC-ről volt szó) lehet találni.

A Project SHINE-ban Bob Radvankovsky, egy az USA-ban igen elismert ICS biztonsági kutató a Shodan-t használta arra, hogy felmérje az Internetre csatlakoztatott ICS rendszerek számát. A kutatást 2012 áprilisában kezdte és 2013 végére több, mint 64 gyártó több, 1 milliónál is több ICS eszközét találta meg az Interneten a Shodan segítségével és ez a szám naponta 2000-8000 darabbal nőtt!

A Shodan számos lehetőséget ad arra, hogy gyártók, portok, városok vagy országok alapján keressünk, ami kiváló eszközzé teszi, ha sérülékeny, Internetre csatlakoztatott ICS eszközöket keresünk.

A Shodant anonim módon lehet használni, lehetőség van ingyenes regisztrációra (ekkor már lehetőség van a kereséséi eredmények mentésére, ehhez több féle fájlformátumot, JSON-t, XML-t, CSV-t támogatnak és lehet riportokat készíteni a keresések eredményeiből, a riportokhoz vezetők linkeket e-mailben küldik el a regisztrációkor megadott e-mail címre). A következő szint a (jelenleg) 49 amerikai dollárért történő regisztráció, ez a most rendelkezésre álló információk szerint egyszeri összeg és véglegesen hozzáférést biztosít a Shodan összes funkciójához, többek között a Shodan API fejlesztői dokumentációhoz, lehetőséget ad térképre helyezni a keresési találatokat, számos ismert és elterjedt szoftverrel teszi integrálhatóvá a Shodan-t (többek között a Metasploit-tal, a Maltego-val, a Google Chrome-mal, stb.) és az ingyenes változatoktól eltérően itt már nincs meg az 50-es limit a találatok megjelenítésénél.

Sajnos nem csak biztonsági kutatók, hanem a támadók is előszeretettel használják a Shodan-t, ezért az ICS rendszerek biztonságáért felelős szakembereknek is csak azt tudom ajánlani, hogy (ammennyiben a saját szervezetük nem tiltja az ilyen eszközök használatát) rendszeresen ellenőrizzék az általuk használt publikus IP címeket és szolgáltatásokat, hogy minél inkább tisztában legyenek azokkal az információkkal, amiket egy potenciális támadó ki tud nyerni a Shodan-ból.

ICS sérülékenységek XCVI

Sérülékenység az LCDS LAquis SCADA nevű rendszerében

Karn Ganeshen, az egyik legtermékenyebb ICS sérülékenységekre vadászó biztonsági kutató a brazil LCDA (Leao Consultoria e Desenvolvimento de Sistemas LTDA ME) SCADA rendszerében talált egy nem megfelelő hozzáférés-vezérlésből eredő hibát. A sérülékenység a LAquis SCADA 4.1 és minden, 2017. január 20-a előtt megjelent verzióját érinti.

A gyártó a hiba javítását elérhetővé tette a weboldalán: http://laquisscada.com/instale1.php

A sérülékenységről további részleteket ezúttal is az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-17-075-01

Az ICS-CERT szokásos módon ezúttal is a 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á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.

ICS sérülékenységek XCV

Fatek Automation PLC Ethernet modul sérülékenység

Az ICS-CERT tegnapi publikációja szerint az alábbi Fatek Automation PLC-kben használt Ether_cfg szoftverkonfigurációs eszközben puffer túlcsordulási hibát fedezett fel egy meg nem nevezett biztonsági kutató:

- CBEH V3.6 Build 170215-nél korábbi verziók;
- CBE V3.6 Build 170215-nél korábbi verziók;
- CM55E V3.6 Build 170215-nél korábbi verziók;
- CM25E V3.6 Build 170215-nél korábbi verziók.

A gyártó a hibát az Ether_cfg szoftverkonfigurációs eszköz új verziójában javította, amit a weboldaláról lehet letölteni: http://www.fatek.com/en/technical.php?act=software&catId=12

A sérülékenységgel kapcsolat további információkat a Fatek Automation és az ICS-CERT publikációi tartalmaznak.

A fenti sérülékenység és általában az ICS 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.

ICS sérülékenységek XCIV

Sérülékenységek Schneider Electric rendszerekben

Az elmúlt néhány napban több Schneider Electric termékkel kapcsolatban jelentek meg friss sérülékenységi információk.

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

A Schneider Electric házon belül talált egy, a felhasználói adatok kezelésével kapcsolatos hibát a Wonderware Intelligence 2014R3 és korábbi verzióiba beágyazottan használt Tableau Server/Desktop szoftver 7.0-tól 10.1.3-ig terjedő verzióiban. A hibát kihasználva egy támadó adminisztrátori szintű jogosultságot szerezhet a sérülékeny rendszereken.

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

Tableau Analytics Dashboard Server v10.1.4
Tableau Analytics Client v10.1.4
Wonderware Intelligence 2014 R3

A sérülékenységről további információkat a Schneider Electric és az ICS-CERT publikációi tartalmaznak.

Schneider Electric ClearSCADA sérülékenység

Sergey Temnikov és Vladimir Dashchenko, a Kapersky Lab Critical Infrastructure Defense Team-jének munkatársai fedeztek fel egy sérülékenységet a Schneider Electric ClearSCADA termékének alábbi verzióiban:

- ClearSCADA 2014 R1 (build 75.5210) és minden korábbi verziója;
- ClearSCADA 2014 R1.1 (build 75.5387) és minden korábbi verziója;
- ClearSCADA 2015 R1 (build 76.5648) és minden korábbi verziója;
- ClearSCADA 2015 R2 (build 77.5882) és minden korábbi verziója.

A hiba lehetővé teszi, hogy a sérülékeny rendszerek a bevitt adatokat bármilyen ellenőrzés nélkül dolgozzák fel, ezzel lehetővé válik egy támadó számára, hogy megzavarja vagy akár meg is szakítsa a sérülékeny rendszer üzemszerű működését.

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

- ClearSCADA 2014 R1.1 hotfix build 75.6239
- ClearSCADA 2015 R1.1 Service Pack (build 76.6191)
- ClearSCADA 2015 R2 hotfix build 77.6181

A ClearSCADA 2013R2 és ennél korábbi verzióit futtató felhasználók számára a Schneider Electric azt javasolja, hogy frissítsenek a ClearSCADA 2015R2 verzióra a hiba javítása érdekében.

A hibajavítás alkalmazása mellett a gyártó az alábbi kockázatcsökkentő intézkedések alkalmazását is javasolja a ClearSCADA termékcsaládot használó ügyfeleinek:

- Gondoskodjanak a ClearSCADA rendszerek és hálózati interfészeik fizikai biztonságáról;
- Megfelelően konfigurált tűzfalak alkalmazásával korlátozzák az egyes hálózati szegmensek közötti forgalmat a feltétlenül szükséges portokra és protokollokra;
- Minden külső hozzáférés esetén használjanak VPN-megoldást;
- A felhazsnálói biztonsági beállítások használatával és rendszeres auditálásával csökkentsék a DoS-támadások kockázatait;
- A ClearSCADA rendszerek kulcsfelhasználói fiókjainál a megfelelő biztonsági szabályok konfigurálásával tegyék minél nehezebbé a jogosulatlan bejelentkezéseket.

A sérülékenységről bővebb információkat a Schneider Electric és az ICS-CERT bejelentéseiben lehet olvasni.

A fenti sérülékenységekkel kapcsolatban az ICS-CERT ezúttal is az általános kockázatcsökkentési intézkedések alkalmazására hívja fel a figyelmet:

- 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 SCADA Strangelove története

Az elmúlt bő egy évben már többször írtam már a SCADA Strangelove csoport munkáiról. A SCADA Strangelove egy orosz kutatókból álló csoport, ami elsősorban a különböző ICS/SCADA rendszerek biztonságát vizsgálja. Összesen 29-en vannak, név szerint:

- Alexander Timorin
- Alexander Tlyapov
- Alexander Zaitsev
- Alexey Osipov
- Andrey Medov
- Artem Chaykin
- Denis Baranov
- Dmitry Efanov
- Dmitry Nagibin
- Dmitry Serebryannikov
- Dmitry Sklyarov
- Evgeny Ermakov
- Gleb Gritsai
- Ilya Karpov
- Ivan Poliyanchuk
- Kirill Nesterov
- Roman Ilin
- Roman Polushin
- Sergey Bobrov
- Sergey Drozdov
- Sergey Gordeychik
- Sergey Scherbel
- Sergey Sidorov
- Timur Yunusov
- Valentin Shilnenkov
- Vladimir Kochetkov
- Vyacheslav Egoshin
- Yuri Goltsev
- Yuriy Dyachenko

Céljuk, saját bevallásuk szerint az, hogy megmentsék az emberiséget az ipari katasztrófáktól és (az ő szóhasználatukkal "megőrizzék a lényeg tisztaságát"). Elmondásuk szerint a Stuxnet nyilvánosságra kerülése után kezdtek foglalkozni az ICS rendszerek biztonságával és elég gyorsan felmérték, hogy az ICS rendszerek már az élet minden területén jelen vannak. További megállapításaik:

- Jellemzően régi technológiát képviselnek, a klasszikus vagy modern biztonsági alapelvek bármilyen alkalmazása nélkül;
- Az ICS rendszerek (elvileg) izolált hálózatokban működnek, de idővel mindig kiderül, hogy ezek a hálózatok más hálózatokhoz vannak csatlakoztatva, ezek a "más hálózatok" pedig már gyakran rendelkeznek Internet-kapcsolattal is;
- Ma már több, nyilvánosan elérhető eszköz (Shodan és Censys keresők, zmap, masscan) érhető el az Internetre csatlakoztatott ICS rendszerek felderítésére
- Az ICS rendszereket üzemeltető mérnökök a mai napig azzal érvelnek, hogy "Ez már nagyon régen így működik - ne nyúlj hozzá!";
- A valóság azonban az, hogy a támadók igenis képesek és készek hozzányúlni az ICS rendszerekhez;
- A SCADA Strangelove alapítóit ezek a tények aggodalommal töltötték el;
- Nem voltak hajlandóak elfogadni a korábbi megközelítéseket, így  hát elhatározták, hogy változtatnak a helyzeten - és 2012-ben, 4 taggal megszületett a SCADA Strangelove.

2013 és 2016 között jelentős fejlődésen ment át a csapat, a taglétszám 30 fő fölé nőtt, több, mint 100 0. napi sérülékenységet azonosítottak a legkülönbözőbb iparágakban (közlekedéstől a megújuló energia-rendszerekig) használt ICS rendszerekben. A feltárt hibák között voltak memóriakezeléssel kapcsolatos, webes, ipari protokollokat érintő hibák, backdoor-ok, hibás kriptográfiai modulok és beégetett gyári jelszavak is. A felfedezett sérülékenységek egyetlen nagyobb ICS gyártók termékeit sem kímélték - SCADA szerverek és kliensek, PLC-k, HMI-ok és MMI-ok, RTU, védelmi relék, konverterek, okosmérők, ipari switch-ek és GSM/GPRS-modemek egyaránt voltak a SCADA Strangelove által vizsgált és sérülékenynek talált ipari eszközök között.

A SCADA Strangelove tagjai különböző cégeknél dolgoznak és megvannak a saját projektjeik, de a csapatnak vannak hosszú távú projektjei is, ilyenek a SCADAPASS és a SCADASOS.

SCADAPASS

A SCADAPASS a különböző ICS eszközök gyári, beégetett jelszavainak gyűjtésére fókuszáló projekt. Legutóbb 2015. december 27-én tették közzé a gyűjtemény utolsó verzióját (erről egyébként anno én is hírt adtam, mindmáig ez a poszt a legolvasottabb a blogon)

SCADASOS

A SCADASOS ((in)Secure Open SmartGrids) projekt célja, hogy minél nagyobb mértékben csökkentse az olyan SmartGrid eszközök számát, amik Internet-kapcsolattal rendelkeznek. Az elmúlt években több, mint 80.000-rel csökkent azoknak az eszközöknek a száma, amiket az Internetről el lehet érni. Ez azonban még mindig csak csepp a tengerben, hiszen újabb és újabb gyártók és ICS rendszerek kerülnek elő, ahol nem csak a rendszert telepítő és üzemeltető szakemberek tudatlansága vagy nemtörődömsége, de adott esetben a gyártó ajánlása is ahhoz vezet, hogy az ICS rendszert vagy egyes komponenseit az Internetre csatlakoztassák (igen jó példa erre a december elején az ICS-CERT által publikált Locus Energy berendezések sérülékenységéről szóló bejegyzés is).

A SCADASOS projekt célja a SmartGrid, valamint a fotovoltalikus (napenergia) és szélerőmű-farmok kiberbiztonsági helyzetének javítása.

A SCADA Strangelove-ról további információkat a weboldalukon lehet megtudni.

ICS sérülékenységek XCIII

Sérülékenységek Eaton és Schneider Electric rendszerekben

Sérülékenység az Eaton xComfort Ethernet Communication Interface-ben

Maxim Rupp, az egyik legismertebb ICS biztonsági kutató az ICS-CERT bejelentése szerint egy hozzáférés-kezelési hibát fedezett fel az Eaton xComfort ECI 1.07-es és korábbi verzióiban. A hibát kihasználva egy támadó a megfelelő URL-en authentikáció nélkül férhető hozzá a sérülékeny rendszerek fájljaihoz.

A gyártó a sérülékeny verziót használói ügyfelei számára azt javasolja, hogy frissítsenek a legújabb verzióra, amiben a hibát már javították.

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-061-01

Schneider Electric Conext ComBox sérülékenység

Arik Kublanov és Mark Liapustin, a Nation-E Ltd. munkatársai a Schneider Electric Conext ComBox, model 865-1058-as eszközein használt V3.03 BN 830-nál korábbi firmware-verzióiban találtak hibát, amit kihasználva a sérülékeny eszközök túlterhelhetőek, aminek hatására újraindulhatnak.

A gyártó a hiba javítását a V3.03 BN 830-as firmware-ben már elérhetővé tette.

A sérülékenységről további információkat az ICS-CERT bejelentésében és a Schneider Electric publikációjában lehet olvasni.

A fenti hibákkal kapcsolatban az ICS-CERT ezúttal is az általános kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

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.

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