Még a nyáron futottam bele Sarah Fluchs cikkébe a medium.com-on, amiben a szerző arról ír, hogy a PLC programozás során is meg kell honosítani a biztonságos fejlesztési gyakorlatot.

Ahogy Sarah is ír erről, a PLC programozással foglalkozók az első, tapogatózó biztonsági kérdésekre még nagyon magabiztosan szokták azt válaszolni, hogy ők aztán nem programoznak, de ahogy tovább folyik a beszélgetés, viszonylag gyorsan eljut társalgás oda, hogy PLC-ket azért programoznak és időnként el is bizonytalanodnak, hogy vajon a PLC programozás számít-e?

A válasz egyértelmú igen, de tudomásul kell venni, hogy az IT programozás egészen más környezetben fejlődött azzá, amit ma ismerünk. Lévén az IT hálózatok már hosszú évtizedek óta egyre meghatározóbbak az IT fejlesztők gondolkodását és fejlesztési gyakorlatait illetően, ez pedig azt is magával hozta (kb. a 2000-es évektől egyre gyorsuló ütemben), hogy az IT fejlesztők (akár tetszett nekik, akár nem) szépen lassan hozzászoktak a biztonságos(abb) fejlesztési módszertanok alkalmazásához.

Ezzel szemben a PLC programozás nagyon eltérő prioritások mentén fejlődött azzá, ami ma. A PLC működése során a legfontosabb prioritás (a safety biztosítása mellett) a valós idejű műveletek elvégzésének megbízható garantálása (ez ugye az OT/ICS biztonsági célok közül a másik a safety mellett, amire korábban már hivatkoztunk a CIA-hármason túl, vagyis a reliability). Ráadásul nagyon sokáig (igazából az elmúlt 8-10 évet nem számolva) a PLC-k jellemzően nem vagy nem igazán kommunikáltak IP hálózatokon, az I/O moduljaikon, néhány környező PLC-n és a folyamatirányító rendszereiken kívül mással jellemzően nem volt kapcsolatuk (ez az a történelmi alap, amire az OT/ICS mérnökök mind a mai napig gyakran hivatkoznak, amikor amellett érvelnek, hogy a kiberbiztonsági kérdések miért is nem vonatkoznak az általuk üzemeltetett rendszerekre - épp csak azt felejtik el vagy arról nem tudnak, hogy a rendszereik és berendezéseik egyre inkább részei egy IP hálózatnak, jobb esetben megfelelő logikai szeparáltság mellett, rosszabb esetben a vállalat ügyviteli hálózatából, legrosszabb esetben pedig külső hálózatokból és az Internetről is elérhető módon működnek).

A cikk két hibás feltételezést is megcáfol:

1. A PLC-k esetén nincs szükség biztonságos fejlesztési eljárásokra
2. A PLC programozásra nem lehet alkalmazni a biztonságos fejlesztés eljárásokat

A PLC-k működési sajátosságai adnak néhány olyan pluszt a biztonságos PLC programozáshoz, amire elsőre nem is gondolna az ember. Ezeket és néhány példát is a cikkben lehet megtalálni: https://medium.com/swlh/the-top-20-secure-plc-coding-practices-project-32729f6d4814

Az utóbbi években egyre népszerűbbekké váltak a különböző, kiberbiztonsági podcast-ek és ebből az ICS kiberbiztonság sem tudott kimaradni, így elérkezettnek látom az időt ennek a blogposzt-sorozatnak a beindítására.

Az ICS biztonsági podcast-ek sorozet első részében a FireEye munkatársának, Luke McNamara-nak a felvételét hoztam, aki Nathan Brubaker-rel, a FireEye által felvásárolt Mandiant fenyegetéselemzéssel foglalkozó csoportjának vezetőjével beszélget. A felvétel itt érhető el.

Tegnapi a hír hogy ismét ransomware-támadás érte a világ egyik legnagyobb energetikai cégcsoportját az ENEL-t. Első alkalommal, idén júniusban a Snake/ENAKS zsarolóvírus jutott be az ENEL inormatikai rendszereibe (erről akkor én is írtam), most pedig a hírek szerint a Netwalker ransomware mögött álló csoport követel váltságdíjat a titkosított fájlok visszaállításáért és azért, hogy ne tegyék közzé az ellopott, összesen mintegy 5 TB-nyi, bizalmas információkat tartalmazó fájlokat.

Az egyértelműen látszik, hogy az idei év egyik legjelentősebb kiberbiztonsági kockázatát a zsarolóvírusok jelentik az ipari szervezetek számára is, még ha a legtöbb esetben közvetlenül a folyamatirányító rendszerekre esetenként nincsenek is hatással (a mostani esetben sincs információ arról, hogy ICS rendszereket érintene az incidens, bár kizárni sem lehet ezt a forgatókönyvet). A kérdés már csak az, vajon a hazai ipari szereplők mennyire felkészültek a hasonló incidensekre?

A jelenlegi járványhelyzet az ICS biztonsági konferenciákra is nagyon komolyan rányomja a bélyegét. A héten az éves ICS Cyber Security Conference nevű rendezvényt tartották teljesen virtuális formában, szemben az eddig, tizensok éves hagyományokkal. Eddig szinte minden évben Atlanta volt a konferencia helyszíne.

Figyelembe véve, hogy a virtuális forma alternatívája a konferencia elmaradása volt, így végső soron jó volt ez a virtuális forma (a konferencia keretét adó rendszer szerintem egészen jól sikerült), de azért a hagyományos konferencia szerintem minden szempontból jobb megoldás - amikor ez utóbbira lehetőség nyílik.

A virtuális forma miatt érezhetően kevesebb volt az előadás és a kiállító is, de összességében ez sem volt igazán meglepő. Ami meglepő volt, az (a szintén a hagyományokkal szemben nem az első, hanem az utolsó napon) megrendezett workshop-nap volt. Én ezen a napon az ICS Red Team Blue Team workshop-on vettem részt, ami egy meglepően jó (és hosszú, közel 9 órás) program volt a ThreatGen munkatársainak vezetésével.

Összességében nem volt rossz az idei 4 nap, de azért erősen remélem, hogy jövőre már visszatérhetünk a normális konferenciák világába.

Különösen azért, mert az ICS biztonsági világ egy másik, nyugodtan ikonikusnak nevezhető rendezvénye, az S4X21 konferenciával kapcsolatban épp a napokban jelentette be a szervező Dale Peterson, hogy a járvány miatt 2021. januárban nem fogják megrendezni a floridai South Beach-en.

Allen-Bradley rendszerek sérülékenységei

A Cisco Talos kutatólaborjának munkatársa, Jared Rittle 5 sérülékenységet talált az Allen-Bradley Flex IO 1794-AENT/B 4.003 berendezéseiben.

A gyártó mostanáig nem adott ki javítást a hibákra. A sérülékenységek részleteit három Talos publikációban lehet megtalálni:

https://talosintelligence.com/vulnerability_reports/TALOS-2020-1005
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1006
https://talosintelligence.com/vulnerability_reports/TALOS-2020-1007

Sérülékenység Fieldcomm rendszerekben

Reid Wightman, a Dragos munkatársa egy sérülékenységet fedezett fel a Fieldcomm alábbi rendszereiben:

- HART-IP Developer kit, Release 1.0.0.0;
- hipserver, Release 3.6.1.

A gyártó a hibával kapcsolatban a kockázatcsökkentő intézkedések fontosságát hangsúlyozta. A sérülékenységgel kapcsolatban további információkat az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-04

Flexera rendszerek sérülékenységei

Egy névtelenségbe burkolózó biztonsági kutató egy sérülékenységet azonosított a Flexera InstallShield 2015 SP1-es és korábbi verzióiban, amit számos más gyártó termékeibe építettek be.

A hibával kapcsolatban az érintett termékeket használó ügyfeleknek ajánlott felvenni a kapcsolatot a rendszereik gyártóival, akiktől további információkat kaphatnak a sérülékenységhez kapcsolódó teendőkről. A sérülékenység részleteiről az ICS-CERT weboldalán lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-03

Sérülékenység LCDS rendszerekben

Egy névtelen biztonsági kutató, a ZDI-vel együttműködve egy sérülékenységről közölt információkat a DHS CISA-val, ami az LCDS (Leão Consultoria e Desenvolvimento de Sistemas Ltda ME) SCADA rendszerének 4.3.1.870-esnél korábbi verzióit érinti.

A gyártó a hibát a 4.3.1.870 és újabb verziókban javította. A sérülékenységgel kapcsolatos bővebb információkat az ICS-CERT publikációjában lehet elolvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-02

Moxa NPort berendezések sérülékenységei

Evgeniy Druzhinin és Ilya Karpov, a Rostelecom-Solar munkatársai 6 sérülékenységet találtak a Moxa NPort IAW5000A-I/O típusú berendezéseinek 2.1-es és korábbi firmware-verzióiban.

A gyártó a hibákat a legújabb firmware-verzióban javította. A sérülékenységekről bővebb információkat az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-287-01

Sérülékenység Advantech WebAccess/SCADA rendszerekben

Sivathmican Sivakumaran, a Trend Micro ZDI munkatársa egy sérülékenységet fedezett fel az Advantech WebAccess/SCADA 9.0 és korábbi verzióiban.

A gyártó a hibát a 9.0.1-es és későbbi verziókban javította. A sérülékenység részleteiről az ICS-CERT bejelentéséből lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-20-289-01

Advantech R-SeeNet rendszerek sérülékenysége

rgod, a ZDI-vel együttműködve egy sérülékenységről közölt részleteket a DHS CISA-val, ami az Advantech R-SeeNet nevű megoldásának 1.5.1-től 2.4.10-ig terjedő verzióit érinti.

A gyártó a hibát az R-SeeNet 2.4.11-es és későbbi verzióiban javította. A sérülékenységgel kapcsolatos további információkat az ICS-CERT weboldalán lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-289-02

Sérülékenységek Siemens SIPORT MP rendszerekben

A Siemens ProductCERT egy sérülékenységet jelentett a DHS CISA-nak a SIPORT MP nevű termékük 3.2.1-nél korábbi verzióival kapcsolatban.

A gyártó a hibát a 3.2.1-es verzióban javította. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT publikációiban lehet olvasni.

Siemens Desigo Insight sérülékenységek

Davide De Rubeis, Damiano Proietti, Matteo Brutti, Stefano Scipioni és Massimiliano Brolli, a TIM Security Red Team Research munkatársai 3 sérülékenységet találtak a Siemens Desigo Insight nevű termékében. A sérülékenységek a Desigo Insight minden verzióját érintik.

A gyártó a hibákat a 6.0 SP5 Hotfix 2 és későbbi verziókban javította. A sérülékenységekről részletesebb információkat a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet találni.

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

Michiel Evers és Niels Pirotte három sérülékenységet találtak a Schneider Electric alábbi termékeiben:

- EcoStruxure™ Power Monitoring Expert 9.0, 8.x és 7.x verziói;
- EcoStruxure™ Energy Expert 2.0;
- Power Manager 1.1, 1.2 és 1.3 verziói;
- StruxureWare™ PowerSCADA Expert with Advanced Reporting and Dashboards Module 8.x;
- EcoStruxure™ Power SCADA Operation with Advanced Reporting and Dashboards Module 9.0.

A sérülékenységek javításával kapcsolatos és egyéb további információkat a Schneider Electric weboldalán lehet megtalálni.

Schneider Electric termékek sérülékenysége

A Schneider Electric publikációja alapján egy sérülékenységet azonosítottak az alábbi termékeikben:

- Acti9 Smartlink SI D minden, 002.004.002-nél korábbi verziója;
- Acti9 Smartlink SI B minden, 002.004.002-nél korábbi verziója;
- Acti9 PowerTag Link / Link HD minden, 001.008.007-nél korábbi verziója;
- Acti9 Smartlink EL B minden, 1.2.1-nél korábbi verziója;
- Wiser Link minden, 1.5.0-nál korábbi verziója;
- Wiser Energy minden, 1.5.0-nál korábbi verziója.

A gyártó a hibát az érintett termékek legújabb verzióiban javította. A sérülékenységről bővebben a Schneider Electric publikációjában lehet olvasni.

Schneider Electric rendszereket is érint a Wibu-Systems CodeMeter sérülékenység

Néhány hete én is beszámoltam a Wibu-Systems CodeMeter licenc menedzser termékében talált sérülékenységekről. Ehhez kapcsolódik a Schneider Electric egyik új bejelentése, amely szerint az alábbi termékeiket is érintik az akkor talált sérülékenységek:

- EcoStruxure Machine Expert minden verziója;
- E+PLC400 minden verziója;
- E+PLC100 minden verziója;
- E+PLC_Setup minden verziója;
- EcoStruxure Machine SCADA Expert minden verziója.

A hiba javításáig a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebb információkat a Schneider Electric bejelentése tartalmaz.

Schneider Electric Modicon berendezések sérülékenysége

Yang Dong, a DingXiang Dongjian Security Lab munkatársa egy sérülékenységet talált a Schneider Electric Modicon termékcsaládjának alábbi tagjaiban:

- az M340 CPU-k BMX P34x modelljeinek 3.20-as firmware-verziója;
- az M340 Ethernet kommunikációs modulok alábbi modelljei:
   - BMX NOE 0100 (H) 3.3-asnál korábbi verziói;
   - BMX NOE 0110 (H) 6.5-ösnél korábbi verziói;
   - BMX NOC 0401 2.10-esnél korábbi verziói;
- Premium processorok integrált Ethernet COPRO-val:
   - TSXP574634, TSXP575634 és TSXP576634 modelljeinek 6.1-es verziója;
- a Premium kommunikációs modulok:
   - TSXETY4103 modell 6.2-esnél korábbi verziói;
   - TSXETY5103 modell 6.4-esnél korábbi verziói;
- Quantum processorok integrált Ethernet COPRO-val:
   - 140CPU65xxxxx modell 6.1-esnél korábbi verziói;
- Quantum kommunikációs modulok:
   - 140NOE771x1 modell 7.1-esnél korábbi verziói;
   - 140NOC78x00 modell 1.74-esnél korábbi verziói;
   - 140NOC77101 modell 1.08-asnál korábbi verziói.

A gyártó a sérülékenységet az érintett termékekhez kiadott újabb verziókban javította. A sérülékenységgel kapcsolatosan részleteket a Schneider Electric weboldalán lehet találni.

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

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

Március végén, amikor a COViD-19 első hulláma már teljes komolyságával (bár korántsem olyan statisztikákat produkálva, mint most, szinte napra pontosan 6 hónappal később) sokkolta a világot, írtam arról, hogy a járvány milyen hatással lehet az ICS rendszerek kiberbiztonságára.

Az elmúlt fél évben történt incidensek nagyjából beigazolták a várakozásokat, erről jelent meg nyár végén egy felmérés a Claroty-tól (regisztráció után itt érhető el).

A felmérésben a Claroty munkatársai vizsgálták a 2020. első félévében publikált ICS sérülékenységek számát (az NVD adatbázisa alapján), ezek a statisztikák azt mutatják, hogy az egy évvel korábbi azonos időszakhoz képest 2020 első felében több, mint 10%-kal magasabb volt a publikált sérülékenységek száma és ezek több, mint 75%-a súlyos vagy kritikus besorolást kapott. A felmérésben elérhető további statisztikák is az ICS sérülékenységek számának folyamatos emelkedését mutatják.

Ami azonban talán még fontosabb kérdés, hogy vajon a tavaszi első hullám esetén rohamtempóban bevezetett tömeges távoli/otthoni munkavégzés megteremtése során "ideiglenesen" áthágott/félresöpört biztonsági szabályokat azóta a cégek hány százalékat állította helyre - vagy legalább kezdett hozzá a normális időszakban elvárt biztonsági szint visszaállításához?

Tartok tőle, hogy a jövőben számos olyan incidensről fogunk hallani, aminek egyik kiváltó oka a járvány miatt félretett biztonsági megfontolásokból eredt.

Sérülékenységek Pepperl+Fuchs rendszerekben

T. Weber, a SEC Consult Vulnerability Lab munkatársa a CERT@VDE-vel együttműködve három sérülékenységet jelentett a Pepperl+Fuchs-nak, amik a gyártó alábbi rendszereit érintik:

P+F Comtrol RocketLinx termékcsalád
- ICRL-M-8RJ45/4SFP-G-DIN berendezéseinek 1.2.3 és korábbi firmware-verziói;
- ICRL-M-16RJ45/4CP-G-DIN berendezéseinek 1.2.3 és korábbi firmware-verziói.

A gyártó a hibákkal kapcsolatban firmware-frissítést és kockázatcsökkentő intézkedésekre vonatkozó ajánlásokat tett közzé. A sérülékenységekről további információkat a Pepperl+Fuchs publikációja tartalmaz.

Mitsubishi Electric MELSEC rendszerek sérülékenysége

Yossi Reuven, a SCADAfence munkatársa egy sérülékenységet fedezett fel a Mitsubishi Electric MELSEC iQ-R sorozatú eszközeinek alábbi moduljaiban:

- R00/01/02CPU minden verziója;
- R04/08/16/32/120(EN)CPU minden verziója;
- R08/16/32/120SFCPU minden verziója;
- R08/16/32/120PCPU minden verziója;
- R16/32/64MTCPU minden verziója.

A gyártó tervei szerint az elkövetkező hónapokban megjelenő új verzióban fogja javítani a hibát, addig is kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységgel kapcsolatos részleteket az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-282-02

Sérülékenység Sensormatic Electronics rendszerekben

Joachim Kerschbaumer egy sérülékenységet jelentett a Johnson Controls-nak, a Sensormatic Electronics anyavállalatának, ami a Sensormatic Electronics American Dynamics victor Web Client nevű termékének v5.4.1 és korábbi verzióit érinti.

A gyártó a hibát az 5.6-os verzióban javította. A sérülékenység részleteit az ICS-CERT weboldalán lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-20-282-01

A fenti sérülékenységekkel kapcsolatban az ICS-CERT az alábbi kockázatcsökkentő intézkedések fontosságát hangsúlyozza:

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

Zsarolóvírus-támadás ért egy nagy angolszász egészségügyi szolgáltatót

Szeptember végén napokig cikkezett a szaksajtó a Universal Health Services nevű, az USA-ban és Nagy-Britanniában szolgáltató egészségügyi szervezet rendszereit érte súlyos ransomware-támadás, aminek következtében a több, mint 400 egészségügyi szolgáltató központot működtető cég számos rendszerét kellett leállítaniuk - egyes források szerint a telefonokon kívül mindent elvesztettek. Az első hírek arról szóltak, hogy a Ryuk néven ismert zsarolóvírus jutott be az UHS hálózatába.

Az incidens részleteiről az alábbi cikkekben lehet olvasni:

SecurityMagazin.com
SecurityWeek.com
HotForSecurity (BitDefender blog)
The Register
CyberScoop

Ransomware-támadás francia tengeri szállítmányozó cég ellen

Szintén szeptember végén érkezett hír arról, hogy az EternalBlue sérülékenységet kihasználó 2017-es és a 2018-ban a kínai Cosco Shipping rendszereit ért támadások után ismét egy tengeri szállítmányozó vállalatot, ezúttal a francia logisztikai óriás, a CMA CGM S.A. egyes rendszerei szenvedtek el ransomware-támadást. Egyes források szerint ebben az esetben (hasonlóan az áprilisi, portugál EDP elleni támadáshoz) a Ragnar Locker ransomware áll az incidens hátterében.

Az incidensről bővebben a Lloyd's List Maritime Intelligence weboldalán lehet olvasni.

Sérülékenység Moxa eszközökben

Az amerikai NSA egy sérülékenységről közölt információkat a Moxa-val, ami a gyártó EDR-810-es sorozatú ipari routereinek 5.6-os és korábbi firmware-verzióit érinti.

A hibával kapcsolatban a gyártó kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről további információkat a Moxa publikációja tartalmaz.

B&R Automation rendszerek sérülékenységei

Nikolay Sokolik és Hay Mizrachi, az OTORIO munkatársai összesen hat sérülékenységet találtak a B&R Automation alábbi rendszereiben:

- SiteManager minden, v9.2.620236042-nél korábbi verziója;
- GateManager 4260 és 9250 minden, v9.0.20262-nél korábbi verziója;
- GateManager 8250 minden, v9.2.620236042-nél korábbi verziója.

A gyártó a hibákat az érintett termékek legújabb verzióiban javította. A sérülékenységek részleteit az ICS-CERT bejelentésében lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsa-20-273-03

Yokogawa WideField sérülékenység

A Parity Dynamics egy sérülékenységet fedezett fel a Yokogawa WideField3 nevű, FA-M3 PLC-inek programozásához használható szoftverének R1.01-től R4.03-ig terjedő verzióiban.

A gyártó a hibát az R.04-es verzióban javította. A sérülékenységgel kapcsolatban további információkat az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-20-273-02

Sérülékenységek MB Connect line rendszerekben

Alik Koldobsky, Ofir Manzur, Hay Mizrachi, Nikolay Sokolik és Haviv Vaizman, az OTORIO munkatársai négy sérülékenységet azonosítottak az MB Connect line alábbi rendszereiben:

- mymbCONNECT24 v2.6.1 és korábbi verziói;
- mbCONNECT24 v2.6.1 és korábbi verziói.

A gyártó a hibákat az érintett termékek 2.6.2-es és újabb verzióiban javította. A sérülékenységekről bővebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-20-273-01

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

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

A múlt héten jelentek meg hírek arról, hogy ransomware-támadás érte a Luxottica nevű gyártót. Maga a cégnév valószínűleg nem sokaknak ismerős (nekem sem volt az), de a Luxottica tervez és gyártó számos világmárkát a szemüvegek (és napszemüvegek) terén, sok egyéb mellett pl. a Ray-Ban-t, de gyártanak a Giorgio Armani, Burberry, Versace, Dolce and Gabbana számára is.

A rendelkezésre álló informácók alapján egyelőre nem lehet megmondani, hogy a Luxottica termelésirányítási rendszereit érintette-e az incidens, az viszont biztos, hogy szeptember 21-én a második műszakban dolgozó munkásaikat SMS-ben értesítették arról, hogy a műszakot felfüggesztették.

Egyes források szerint a támadók egy Citrix eszköz tavaly publikált és nem patch-elt sérülékenységét kihasználva tudták bejuttatni a zsarolóvírust a cég hálózatába.

Az idei év egyértelműen a különböző ipari szervezetek (elsősorban a különböző, termelésirányítási rendszereket használó vállalatok) elleni kibertámadások (döntő többségében zsarolóvírus-támadások) évének látszik. Évekkel ezelőtt, az első komolyabb ransomware-támadások után már voltak biztonsági szakemberek, akik számítottak erre a tendenciára, most úgy tűnik, igazuk lett, csak azt nem találták el, milyen gyorsan kezdenek ipari szervezeteket célba venni a támadók.