Az ICS kiberbiztonságnak, bár még alig másfél évtizedes történettel rendelkezik, máris számos mérföldköve van. Az egyik első ezek közül az Aurora teszt, amit számos amerikai állami szervezettől verbuvált szakember részvételével hajtottak végre 2007. márciusában. A teszt során Mike Assante (aki sajnálatos módon 2 éve, 2019. júliusában hunyt el) néhány sornyi számítógépes kóddal távolról rövid úton tönkretette a teszthez Alaszkából beszerzett, 27 tonnás, 2,25 MW teljesítményű generátort. Azt, hogy Mike Assante pontosan mit is csinált, én (nem lévén villamosmérnök) nem értem (az angol tudásom ide már kevés, ehhez szerintem szakembernek kell lenni, szerencsére akad a blog körül néhány ilyen személy, remélem lesz olyan, aki ebben tud segíteni: "First, they increased the frequency above which the power grid operates to then explode the brake system in charge of lowering the operating frequency. This frequency difference between the generator and the network triggered a response from the relays that damaged the brakes and caused severe shocks in the machine, resulting in an explosion three minutes after it was reconnected to the network."), de az eredmény ebben a ma már YouTube-on is elérhető videóban jól látható: https://www.youtube.com/watch?v=LM8kLaJ2NDU

A teszttel kapcsolatos további részletek (beleértve, hogy milyen feltételeknek kell teljesülni úgy kiberbiztonsági, védelmi és villamosenergia-rendszer szinten, hogy az Aurora teszt során bemutatott támadás sikeres legyen), valamint a hasonló támadások elleni védekezést segítő intézkedésekre vonatkozó tanácsok az Incibe-CERT weboldalán érthetőek el. Aki részletesebben is szeretne az Aurora tesztről olvasni, annak Andy Greenberg Sandworm című könyvének 10. fejeztetét (Flashback: Aurora) tudom ajánlani, ahol jóval részletesebben is leírják ezt a tesztet.

Hitachi ABB Power Grids TropOS sérülékenységek

A Hitachi ABB Power Grids összesen 12 sérülékenységről közölt információkat a DHS CISA-val, amiket a TropOS termékcsalád 8.9.4.8-as és korábbi firmware-verzióiban találtak.

A gyártó a hibát a 8.9.4.9-es és újabb firmware-verziókban javította. A sérülékenységekkel kapcsolatos további részleteket az ICS-CERT publikációja tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-236-01

Sérülékenység Hitachi ABB Power Grids rendszerekben

Az ICS-CERT bejelentése szerint egy sérülékenységet azonosítottak a Hitachi ABB Power Grids alábbi rendszereiben:

- Retail Operations 5.7.2-es és korábbi verziói;
- Counterparty Settlement and Billing (CSB) 5.7.2-es és korábbi verziói.

A gyártó a hibát az érintett termékek 5.7.3-as és későbbi verzióiban javította. A sérülékenységről bővebb információkat az ICS-CERT bejelentésében lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-236-02

Johnson Controls rendszerek sérülékenysége

A Johnson Controls egy sérülékenységről osztott meg információkat a DHS CISA-val, ami a Controlled Electronic Management Systems (CEM Systems) AC2000 10.1-től 10.5-ig terjedő verzióit érinti.

A hibát a gyártó a 10.5 Server Feature Pack 2, 10.6-os és ezek után következő jövőbeli verziókban fogja javítani, ezek megjelenéséig pedig kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-238-01

Sérülékenység Annke rendszerekben

Andrea Palanca, a Nozomi Networks munkatársa egy sérülékenységet jelentett a DHS CISA-nak, amit az Annke N48PBB NVR rendszereinek V3.4.106 build 200422-es és korábbi verzióiban talált.

A gyártó a hibával kapcsolatban a legújabb, elérhető verzióra történő frissítést javasolja. A sérülékenység részleteiről az ICS-CERT publikációjából lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-238-02

Delta Electronics TPEditor sérülékenység

Kimiya, a ZDI-vel együttműködve egy sérülékenységről tájékoztatta a DHS CISA-t, amit a Delta Electronics TPEditor v1.98.06-os és korábbi verzióiban talált.

A gyártó a hibát a v1.98.07-es verzióban javította. A sérülékenységről további információkat az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-236-03

Sérülékenységek Delta Electronics DIAEnergie rendszerekben

Michael Heinzl 8 sérülékenységgel kapcsolatban osztott meg információkat a DHS CISA-val, amik a Delta Electronics DIAEnergie nevű megoldásának 1.7.5-ös és korábbi verzióit érintik.

A gyártó a hibákat a várhatóan 2021. szeptember 15-én megjelenő új verzióban fogja javítani. A sérülékenységekkel kapcsolatos részletek az ICS-CERT weboldalán érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-21-238-03

Delta Electronics DOPSoft sérülékenység

Egy névtelenségbe burkolózó biztonsági kutató a ZDI-n keresztül egy sérülékenységről tájékoztatta a DHS CISA-t, amit a Delta Electronics DOPSoft 4.00.11-es és korábbi verzióiban talált.

A gyártó jelenleg is dolgozik a hiba javításán. A sérülékenység részleteiről az ICS-CERT publikációjából lehet többet megtudni: https://us-cert.cisa.gov/ics/advisories/icsa-21-238-04

Sérülékenységek B. Braun infúziós rendszerekben

A McAfee munkatársai 5 sérülékenységet találtak a B. Braun infúziós rendszereiben. Az érintett rendszerek listáját és a sérülékenységekkel kapcsolatos további részleteket a McAfee weboldalán lehet megtalálni.

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.

A Stibnite csoport némileg egyedülálló ebben a sorozatban, mert az elemzések szerint kifejezetten azeri szélerőművek elleni támadásokra specializálódtak. A csoport első azonosítása a Cisco Talos csapatának 2020. októberében megjelent, PoetRAT malware-ről szóló elemzéséhez köthető, a csoport egyes feltételezések szerint legalább 2019. vége óta aktív lehet.

Módszereik közé kártékony kódot tartalmazó fájlok és felhasználói adatok lopására készített weboldalak jellemzőek, ezen felül a Talos által PoetRAT-nak nevezett malware is az egyik azonosítójukká vált.

A csoportról készült Dragos elemzés itt található.

Sérülékenység NTZ Mekhanotronika Rus. LLC vezérlő panelekben

A Schneider Electric publikációja szerint egy Windows 10 sérülékenység érinti az NTZ Mekhanotronika Rus. LLC alábbi vezérlő paneljeit:

- SHFK-MT-104 DIVG.424327.104-35-ös készülékek 3203-as sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-41-es készülékek 3520-as sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.01-es és SHFK-MT-104 DIVG.424327.104-36.20-as készülékek 3297-3316 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.21-es és SHFK-MT-104 DIVG.424327.104-36.25-ös készülékek 3368-3372 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.26-os és SHFK-MT-104 DIVG.424327.104-36.65-ös készülékek 3318-3357 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.66-os és SHFK-MT-104 DIVG.424327.104-36.70-es készülékek 3505-3509 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.71-es és SHFK-MT-104 DIVG.424327.104-36.80-as készülékek 3373-3382 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.81-es és SHFK-MT-104 DIVG.424327.104-37.11-es készülékek 3394-3423 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-37.12-es és SHFK-MT-104 DIVG.424327.104-37.21-es készülékek 3510-3519 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-37.22-es és SHFK-MT-104 DIVG.424327.104-37.81-es készülékek 3552-3611 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-37.82-es és SHFK-MT-104 DIVG.424327.104-38.01-es készülékek 3697-3715 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.02-es és SHFK-MT-104 DIVG.424327.104-38.38-as készülékek 3729-3765 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.39-es és SHFK-MT-104 DIVG.424327.104-38.58-as készülékek 3794-3813 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.59-es és SHFK-MT-104 DIVG.424327.104-38.78-as készülékek 3815-3834 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.79-es és SHFK-MT-104 DIVG.424327.104-39.13-as készülékek 3835-3867 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-40-es készülékek 3814-es sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-45-ös készülékek 3822-es sorozatszámú példányai.

A hibával kapcsolatban a CVE-2021-31166-os azonosító számú sérülékenységhez kiadott javítás telepítését javasolják. A sérülékenységről bővebben a Schneider Electric publikációjából lehet tájékozódni.

Windows 7 sérülékenység NTZ Mekhanotronika Rus. LLC vezérlő panelekben

A Schneider Electric bejelentése szerint az NTZ Mekhanotronika Rus. LLC alábbi, Windows 7-es operációs rendszerre épülő vezérlő paneljeit érinti két súlyos sérülékenység:

- SHAIIS-MT-111 DIVG.424327.111-02-es készülékek 2847 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-04-es készülékek 2522 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-06-os készülékek 2558 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-08-as készülékek 2559 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-11-es készülékek 2704 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-12-es készülékek 2825-ös, 2828-as és 2831-es sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-14-es készülékek 2916 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-16-os készülékek 3036 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-19-es készülékek 3113 sorozatszámú példányai;
- SHAIIS-MT-111 DIVG.424327.111-20-as készülékek 3201 sorozatszámú példányai;
- SHASU-MT-107 DIVG.424327.107-01-es készülékek;
- SHASU-MT-107 DIVG.424327.107-02-es készülékek 2555 sorozatszámú példányai;
- SHASU-MT-107 DIVG.424327.107-08-as készülékek 3043 sorozatszámú példányai;
- SHFK-MT DIVG.424327.104-08-as készülékek 2686 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-09-es 2623 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-10-es 2846 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-14-es 2521 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-24-es 2712 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-25-ös 2823-as, 2826-os és 2829-es sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-27-es 2889 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-28-as 2915 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-30-as 3008 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-32-es 3035 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-33-as 3080 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-34-es 3112 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-35-ös 3203 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.01 SHFK-MT-104 DIVG.424327.104-36.20-as 3297-3316 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.21 SHFK-MT-104 DIVG.424327.104-36.25-ös 3368-3372 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.26 SHFK-MT-104 DIVG.424327.104-36.65-ös 3318-3357 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.66 SHFK-MT-104 DIVG.424327.104-36.70-es 3505-3509 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.71 SHFK-MT-104 DIVG.424327.104-36.80-as 3373-3382 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-36.81 SHFK-MT-104 DIVG.424327.104-37.11-es 3394-3423 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-37.12 SHFK-MT-104 DIVG.424327.104-37.21-es 3510-3519 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-37.22 SHFK-MT-104 DIVG.424327.104-37.81-es 3552-3611 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-37.82 SHFK-MT-104 DIVG.424327.104-38.01-es 3697-3715 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.02 SHFK-MT-104 DIVG.424327.104-38.38-as 3729-3765 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.39 SHFK-MT-104 DIVG.424327.104-38.58-as 3794-3813 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.59 SHFK-MT-104 DIVG.424327.104-38.78-as 3815-3834 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-38.79 SHFK-MT-104 DIVG.424327.104-39.13-as 3835-3867 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-40-es 3814 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-41-es 3520 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-43-as 3906 sorozatszámú példányai;
- SHFK-MT-104 DIVG.424327.104-45-ös 3822 sorozatszámú példányai.

A hibákat a Microsoft által kiadott Windows 7 frissítések telepítésével lehet javítani. A sérülékenységekről további részleteket a Schneider Electric bejelentése tartalmaz.

CODESYS sérülékenységek Schneider Electric PacDrive termékekben

A Schneider Electric weboldalán megjelent információk szerint 3, CODESYS V2 runtime-ban talált sérülékenység érinti a Programmable Automation Controller (PacDrive) M összes verzióját.

A hibát a gyártó a PacDrive M-ben már nem javítja, ehelyett a PacDrive 3-as verzióra történő váltást javasolják. A sérülékenységek részleteiről a Schneider Electric weboldalán lehet olvasni.

Schneider Electric AccuSine termékek sérülékenységei

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

- AccuSine PCS+/PFV+ V1.6.7-nél korábbi verziói;
- AccuSine PCSn V2.2.4-nél korábbi verziói.

A gyártó a hibát az érintett termékek újabb verzióiban javította. A sérülékenységgel kapcsolatos további részleteket a Schneider Electric publikációjában lehet megtalálni.

Sérülékenységek Schneider Electric termékekben

A Schneider Electric által közzétett bejelentés szerint 4 sérülékenységet találtak az alábbi termékeikben:

- Modicon M580 CPU (BMEP* és BMEH* sorozatú eszközök) minden verziója;
- Modicon M340 CPU (BMXP34* sorozatú eszközök) minden verziója;
- Modicon MC80 (BMKC80* sorozatú eszközök) minden verziója;
- Modicon Momentum Ethernet CPU (171CBU* sorozatú eszközök) minden verziója;
- PLC Simulator for EcoStruxure™ Control Expert, beleértve minden Unity Pro változatot is (korábbi nevén EcoStruxure™ Control Expert) minden verziója;
- PLC Simulator for EcoStruxure™ Process Expert beleértve minden HDCS változatot is (korábbi nevén EcoStruxure™ Process Expert) minden verziója;
- Modicon Quantum CPU (140CPU* sorozatú eszközök) minden verziója;
- Modicon Premium CPU (TSXP5* sorozatú eszközök) minden verziója.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységek részleteiről a Schneider Electric bejelentéséből lehet tájékozódni

Schneider Electric Pro-face GP-Pro EX rendszerek sérülékenysége

A Schneider Electric által nyilvánosságra hozott információk szerint egy sérülékenységet azonosítottak a GP-Pro EX V4.09.250-es és korábbi verzióiban.

A gyártó a hibát a V4.09.300-as verzióban javította. A sérülékenységgel kapcsolatos bővebb információkat a Schneider Electric weboldalán kell keresni.

Sérülékenységek Schneider Electric termékekben

A Schneider Electric publikációja szerint a Cisco Talos által az AT&T Labs Compressor (XMilI) and Decompressor (XDemill) komponensekben talált 12 sérülékenység érinti az alábbi Schneider Electric termékeket is:

- EcoStruxure Control Expert minden verziója (beleértve a korábbi Unity Pro verziókat is);
- EcoStruxure Process Expert minden verziója (beleértve a korábbi HDCS verziókat is);
- SCADAPack RemoteConnect for x70.

A hibákkal kapcsolatban a gyártó kockázatcsökkentő intézkedések bevezetését javasolja. A sérülékenységekről bővebb a Schneider Electric publikációja tartalmaz.

Schneider Electric Harmony/Magelis HMI-ok sérülékenysége

A Schneider Electric által 2021. augusztus 10-én nyilvánosságra hozott információk szerint az alábbi szoftvereikkel konfigurált Harmony/Magelis HMI termékekben található egy sérülékenység:

- A Vijeo Designer bármelyik, V6.2 SP11-nél korábbi verziójával konfigurált HMI-ok:
- Harmony/Magelis STO
- Harmony/Magelis STU
- Harmony/Magelis GTO
- Harmony/Magelis GTU
- Harmony/Magelis GTUX
- Harmony/Magelis GK
- Vijeo Designer Basic bármelyik, V1.2-nél korábbi verziójával konfigurált Harmony/Magelis GXU HMI-ok;
- EcoStruxure™ Machine Expert bármelyik, V2.0-nál korábbi verziójával konfigurált Harmony/Magelis SCU.

A gyártó a hibát az érintett konfiguráló szoftverek újabb verzióiban javította. A sérülékenységről további részleteket a Schneider Electric bejelentésében lehet elérni.

Sérülékenységek Moxa EDR-810 sorozatú routerekben

A Moxa bejelentése alapján az EDR-810-es sorozatú secure routereinek 5.9-es és korábbi firmware-verzióiban 4 sérülékenységet fedezett fel Danny Rigby és Alan Chang, a Modux munkatársai.

A hibákat javító biztonsági javításokat a Moxa Technical Support-on keresztül lehet elérni. A sérülékenységek részleteiről a Moxa weboldalán lehet tájékozódni.

xArrow SCADA rendszerek sérülékenységei

Sharon Brizinov, a Claroty munkatársa és Michael Heinzl 3 sérülékenységet jelentettek a DHS CISA-nak, amiket az xArrow SCADA/HMI rendszereinek 7.2-es és korábbi verzióiban találtak.

A hibák javításáról jelenleg nincs információ. A sérülékenységekről bővebben az ICS-CERT publikációjában lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-229-03

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

Selim Enes Karaduman, 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 Advantech WebAccess/NMS hálózatmenedzsment megoldásának v3.0.3_Build6299-esnél korábbi verzióit érinti.

A gyártó a hibát a 3.0.3-as verzió újabb build-jeiben javította. A sérülékenységgel kapcsolatos további részleteket az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-229-02

ThroughTek megoldások sérülékenysége

Jake Valletta, Erik Barzdukas és Dillon Franke, a Mandiant munkatársai egy sérülékenységet fedeztek fel a ThroughTek alábbi megoldásaiban:

- Kalay P2P Software Development Kit (SDK) 3.1.5-ös és korábbi verziói;
- a nossl tag-gel ellátott SDK verziók;
- azok a firmware-verziók, amik nem használna AuthKey-t az IOTC kapcsolatokhoz;
- a DTLS mechanizmus nélküli AVAPI modult használó firmware-verziók;
- P2PTunnel-t vagy RDT modult használó firmware-verziók.

A hiba javítására a gyártó az SDK verzió frissítését és kockázatcsökkentő intézkedések alkalmazását ajánlja. A sérülékenységről bővebben az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-229-01

Sérülékenységek AVEVA SuiteLink Server-ekben

Sharon Brizinov, a Claroty munkatársa, 6 sérülékenységet jelentett az AVEVA-nak, amiket a gyártó alábbi termékeiben fedezett fel:

- AVEVA System Platform 2020 R2 P01-es és korábbi verziói;
- AVEVA InTouch 2020 R2 P01-es és korábbi verziói;
- AVEVA Historian 2020 R2 P01-es és korábbi verziói;
- AVEVA Communication Drivers Pack 2020 R2-es és korábbi verziói;
- AVEVA Operations Integration Core 3.0 és korábbi verziói;
- AVEVA Data Acquisition Servers minden verziója;
- AVEVA Batch Management 2020-as és korábbi verziói;
- AVEVA MES 2014 R2-es és korábbi verziói.

A gyártó a hibákat az egyes érintett termékek újabb verzióiban javította. A sérülékenységek részleteiről az ICS-CERT publikációjából lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-231-01

Siemens SINEMA Remote Connect Client sérülékenység

Amir Preminger, a Claroty munkatársa egy sérülékenységet jelentett a Siemens-nek, ami a gyártó alábbi termékeit érinti:

- SINEMA Remote Connect Client minden, V3.0 SP1-nél korábbi verziója.

A gyártó a hibát a V3.0 SP1-es és újabb verziókban javította. A sérülékenységről bővebb információk a Siemens ProductCERT bejelentésében érhetőek el.

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.

Bár már több, mint öt és fél éve fut a blog, de továbbra is a magasan legolvasottabb posztom a 2015. december 20-án megjelent, "ICS rendszerekkel kapcsolatban ismétlődő kifejezések" című poszt, amiből én azt a (meglehet talán helytelen) következtetést vonom le továbbra is, hogy a blogon elég sok, az ICS kiberbiztonság terülétével csak most ismerkedő kolléga fordul meg. Éppen ezért mindig örülök, amikor olyan anyagokat találok, amikből a témával csak ismerkedők is sok újdonságot tanulhatnak. Nemrég a SANS Institute weboldalán indult egy sorozat, ami pont az ICS biztonság világába történő bevezetést tűzte ki céljának. A mai napig 2 rész jelent meg a sorozatból, csak remélni tudom, hogy szerzők folytatni fogják.

Az első rész az abszolút alapoktól indít, röviden bemutatja, mik is az ipari folyamatirányító rendszerek, az átlagember hol találkozhat ilyenekkel illetve milyen iparágakban nélkülözhetetlenek az ICS rendszerek. Röviden bemutatják az ICS rendszerek legfontosabb komponenseit (szenzorok és szelepek, vezérlők, menedzsment és felügyeleti rendszerek illetve a kapcsolódó üzleti rendszerek - a kapcsolódó üzleti rendszereket sokáig nem tekintették a folyamatvezérlési rendszerek szerves részének, de az elmúlt 5-8 év eseményei és leginkább a Hydro, majd a Colonial Pipeline incidensek megmutatták, hogy még egy olyan incidens is milyen pusztító hatással lehet a fizikai folyamatok irányítására, amik az ICS rendszereket közvetlenül nem érintették) és hosszabban tárgyalják az ICS kiberbiztonság kihívásait, köztük az (IT-s mércével nézve) elavult rendszerek biztonsága okozta feladatokat, valamint az új fejleményeket és fenyegetéseket.

A második részben jelentős szerepet kap a Purdue-modell bemutatása és a SANS ICS 410-es tanfolymának referencia modelljének ismertetése, majd röviden áttekinti az ICS biztonság szempontjából releváns nemzetközi szabványokat és ezek alapján mutatja be, hogy a biztonság-centrikus architektúra-tervezés milyen sokkal tud hozzájárulni a jövő ICS rendszereinek kiberbiztonsági helyzetének javításához. A második rész végén még egy rövid szószedet is található, alátámasztva a poszt elején írt tapasztalatomat, hogy mennyire fontos is az ICS biztonsággal épp ismerkedők számára egy ilyen gyűjtemény.

Siemens SIMATIC S7 készülékek sérülékenysége

Jian Gao egy sérülékenységet jelentett a Siemens-nek, amit a gyártó S7-1200 CPU családjának (beleértve a SIPLUS változatokat is) 4.5.0 verziójában.

A gyártó a hibát a 4.5.1-es és későbbi verziókban javította. A sérülékenységgel kapcsolatos további információkat a Siemens ProductCERT és az ICS-CERT publikációiban lehet megtalálni.

Sérülékenységek Siemens Solid Edge rendszerekben

Xina1i, a ZDI-vel együttműködve 3 sérülékenységről közölt információkat a DHS CISA-val, amiket a Siemens Solid Edge SE2021 MP7 előtti verzióiban fedezett fel.

A gyártó a hibákat a Solid Edge SE2021MP7 és későbbi verzióiban javította. A sérülékenységekről részleteket a Siemens ProductCERT és az ICS-CERT bejelentései tartalmaznak.

Siemens SIMATIC NET CP termékek sérülékenységek

A Siemens két sérülékenységről osztott meg információkat a DHS CISA-val, amiket az alábbi termékeikben találtak:

- SIMATIC NET CP 1543-1 (beleértve a SIPLUS változatokat is) minden, v3.0-nál korábbi verziója;
- SIMATIC NET CP 1545-1 minden verziója.

A gyártó a SIMATIC NET CP 1543-1-hez kiadta a hibákat javító verziókat. A sérülékenységekkel kapcsolatban további információkat a Siemens ProductCERT és ICS-CERT weboldalain lehet olvasni.

Sérülékenység Siemens SGT rendszerekben

A Siemens egy sérülékenységet jelentett a DHS CISA-nak, ami az alábbi termékeiket érinti, amennyiben azokhoz harmadik féltől származó komponenseket használnak:

- SGT-100 minden verziója;
- SGT-200 minden verziója;
- SGT-300 minden verziója;
- SGT-400 minden verziója;
- SGT-A20 minden verziója;
- SGT-A35 minden verziója;
- SGT-A64 minden verziója.

A sérülékenységhez tartozó bővebb információk a Siemens ProductCERT és az ICS-CERT publikációiban lehet elérni.

Intel CPU sérülékenységek Siemens ipari termékekben

A Siemens DHS CISA felé tett bejelentése szerint az alábbi termékeiket érinti 12, Intel CPU-kban talált sérülékenység:

- SIMATIC Drive vezérlő család minden verziója;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC Field PG M5 minden verziója;
- SIMATIC Field PG M6 minden verziója;
- SIMATIC IPC127E minden verziója;
- SIMATIC IPC427E minden verziója;
- SIMATIC IPC477E minden verziója;
- SIMATIC IPC477E Pro minden verziója;
- SIMATIC IPC527GE minden verziója;
- SIMATIC IPC547G minden verziója;
- SIMATIC IPC627E minden verziója;
- SIMATIC IPC647E minden verziója;
- SIMATIC IPC677E minden verziója;
- SIMATIC IPC847E: All BIOS versions prior to v25.02.10
- SIMATIC ITP1000 minden verziója;
- SIMATIC S7-1500 CPU 1518-4 PN/DP MFP (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC S7-1500 CPU 1518F-4 PN-DP MFP minden verziója;
- SINUMERIK 828D HW PPU.4 minden verziója;
- SINUMERIK MC MCU 1720 minden verziója;
- SINUMERIK ONE / SINUMERIK 840D sl HT 10-es kézi terminálok minden verziója;
- SINUMERIK ONE PPU 1740 minden verziója.

A gyártó a hibákkal kapcsolatban BIOS frissítéseket javasol. A sérülékenységekről bővebb információk a Siemens ProductCERT és az ICS-CERT bejelentéseiben érhetőek el.

Siemens SINEC NMS sérülékenység

Noam Moshe, a Claroty munkatársa egy sérülékenységet jelentett a DHS CISA-nak, ami a Siemens SINEC NMS minden, v1.0 SP2-nél korábbi verzióját érinti.

A gyártó a hibát a v1.0 SP2 és újabb verziókban javította. A sérülékenység részleteiről a Siemens ProductCERT és az ICS-CERT weboldalain lehet olvasni.

Sérülékenységek Siemens rendszerekben

Az Open Design Alliance illetve Mat Powell (a ZDI-vel együttműködve) 3 sérülékenységről közöltek információkat a DHS CISA-val, amiket a Siemens alábbi megoldásaiban találtak:

- JT2Go minden, v13.2.0.2-nél korábbi verziója;
- Teamcenter Visualization minden, v13.2.0.2-nél korábbi verziója.

A gyártó a hibákat az érintett rendszerek v13.2.0.2-es és újabb verzióiban javította. A sérülékenységekkel kapcsolatos bővebb információk a Siemens ProductCERT és az ICS-CERT publikációiban lehet elérni.

Siemens Automation License Manager sérülékenység

A Siemens egy sérülékenységről közölt információkat a DHS CISA-val, ami az alábbi rendszereiket érinti:

- Automation License Manager 5 minden verziója;
- Automation License Manager 6 minden, v6.0 SP9 Update 2-nél korábbi verziója.

A gyártó a hibát az Automation License Manager 6 v6.0 SP9 Update 2-esés újabb verzióiban javította. A sérülékenységről bővebben a Siemens ProductCERT és az ICS-CERT bejelentéseiben lehet olvasni.

Fájl parsing sérülékenységek Siemens rendszerekben

Kai Wang, a Qi’anxin csoport Legendsec csapatának tagja, az Open Design Alliance és a ZDI közös erőfeszítéseinek köszönhetően 7 sérülékenységről jutott el információ a DHS CISA-hoz, amiket a Siemens alábbi rendszereiben találtak:

- JT2Go minden, v13.2.0.1-nél korábbi verziója;
- Teamcenter Visualization minden, v13.2.0.1-nél korábbi verziója.

A gyártó a hibákat a v13.2.0.1-es és újabb verziókban javította. A sérülékenységek részleteiről a Siemens ProductCERT és az ICS-CERT weboldalain lehet tájékozódni.

Authorizációs sérülékenység Siemens ipari megoldásokban

A Siemens egy sérülékenységről hozott nyilvánosságra információkat, ami az alábbi ipari környezetekbe szánt rendszereiket érinti:

- SIMATIC Drive vezérlő család minden, V2.9.2-nél korábbi verziója;
- SIMATIC ET 200SP Open Controller CPU 1515SP PC2 (beleértve a SIPLUS változatokat is) minden verziója;
- SIMATIC S7 PLCSIM Advanced minden, V2-nél későbbi és V4-nél korábbi verziója;
- SIMATIC S7-1200 CPU család (beleértve a SIPLUS változatokat is) V4.4-es verziója;
- SIMATIC S7-1500 CPU család (beleértve az ET200 CPU-kat és SIPLUS változatokat is) minden, V2.5-nél újabb és V2.9.2-nél korábbi verziója;
- SIMATIC S7-1500 szoftveres vezérlő minden, V2.5-nél újabb verziója;
- TIM 1531 IRC (beleértve a SIPLUS NET változatokat is) V2.1-es verziója.

A gyártó a hibát javító újabb verziókat már elérhetővé tette. A sérülékenységgel kapcsolatos részletek a Siemens ProductCERT publikációja tartalmazza.

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

Michael Heinzl 3 sérülékenységet jelentett a DHS CISA-nak, amiket a Horner Automation Cscape nevű fejlesztői környezetének 9.90 SP5-ösnél korábbi verzióiban talált.

A gyártó a hibákat a Cscape 9.90 SP5-ös verziójában javította. A sérülékenységekről további információkat az ICS-CERT bejelentésében lehet találni: https://us-cert.cisa.gov/ics/advisories/icsa-21-224-02

Sérülékenység Cognex rendszerekben

Amir Preminger, a Claroty munkatársa egy sérülékenységet jelentett a DHS CISA-nak a Cognex In-Sight OPC Server nevű megoldásának v5.7.4 (96) és korábbi verzióival kapcsolatban.

A gyártó a hibát az In-Sight OPC Server 5.9.2-es és későbbi verziókban javította. A sérülékenység részleteiről az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-224-01

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

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

Augusztus 5-én GéPé kolléga (írásai mind gyakoribb és örömtelibb vendégek ezen a blogon is) egy fontos posztot jelentetett meg a SeConSys blogján, amiben Joe Weiss írásai nyomán az ICS rendszerek technológia-közeli berendezéseinek védelmi megoldásai (illetve azok hiánya) kérdéseit boncolgatta.

Régóta érlelődik bennem egy poszt a témával kapcsolatban, még inkább Joe idestova 4 éve kitartóan hangoztatott érveinek az én nézőpontomból történő vizsgálatáról, szóval most végképp eljött az ideje, hogy erről én is írjak.

Talán már írtam róla, hogy Joe Weiss blogját 2014 óta olvasom és Joe-t 2015. október óta ismerem személyesen (egyszerűen leült mellém a bárpulthoz a szállodában, ahol egy konferencia miatt voltam), a vele folytatott hosszabb beszélgetések adták meg az utolsó lökést, hogy elindítsam ezt a blogot és mind mélyebben ássam bele magam az ICS kiberbiztonság témájába. Szóval Joe egyfajta korai mentor volt számomra és mindig csodálattal néztem azt a kitartást, amit ő és néhány hozzá hasonló úttörő tanúsított az ICS biztonság ügye iránt. 2017-re már elég nyilvánvaló volt, hogy az ICS biztonság nem csupán egy maroknyi üldözési mániás őrült hagymázas rémálma, egyre több ICS rendszer üzemeltető és a szállítói oldal is egyre inkább felismerte, hogy a témával bizony foglalkozni kell. Joe ekkor kezdett arról beszélni, hogy az ICS biztonság nem csak az OT hálózatok biztonságát jelenti, hanem az ICS végponti berendezések kiberbiztonsága is súlyos hiányosságokkal küzd. Az elmúlt évek során ebbéli meggyőződése odáig fejlődött, hogy posztjaiban és egyéb megnyilatkozásaiban már vagy-vagy választásként beszél az OT hálózatbiztonságról és az ICS végponti eszközök kiberbiztonságáról.

Tavaly, már a COViD-járvány alatt volt egy hosszabb Zoom-beszélgetésünk, ahol próbáltam finoman érdeklődni, hogy vajon nem lenne jobb úgy megközelíteni ezt a témát, hogy nem választani kell az OT hálózatbiztonság és a (Purdue-modell szerinti) L1/L0 eszközök biztonsága között, hanem inkább azokat mint egymás kiegészítő biztonsági kontrolljait kéne nézni, az OT hálózatbiztonsághoz úgyis inkább klasszikus IP hálózatbiztonsági (IT biztonsági) mérnökökre van szükség, a L1/L0 eszközök biztonsága pedig olyan téma, amihez a folyamatirányítási logikát mélyebben ismerő mérnökök értenek jobban. Végső soron pedig ismét ugyanoda jutunk: ahhoz, hogy az ICS kiberbiztonság a rendszer minden szintjén egyenszilárd lehessen, az IT, IT biztonsági és folyamatirányítási mérnökök eddiginél és jelenleginél sokkal jobb, hatékonyabb és szorosabb együttműködése szükséges. Mindaddig, amíg a résztvevő mérnökök külön-külön, egymást nem partnernek, inkább ellenfélnek vagy nehezítő tényezőnek tekintve dolgoznak, a támadók mindig találni fognak olyan gyenge pontokat, amiket mindkét (vagy mindhárom) csapat kihagyott a biztonságosabb rendszerekért folytatott munka során és ezeket kihasználva képesek lesznek megzavarni a fizikai folyamatok irányítását.

Ráadásul már az sem lenne elég, ha az IT/OT hálózatbiztonsági és folyamatirányítási mérnökök között létezne egy, a mostaninál sokkal jobb szakmai együttműködés, hiszen a Colonial Pipeline-incidens elég világosan megmutatta (bár nem ez volt az első ilyen incidens, de ennek volt az átlagemberek életére olyan széleskörű negatív hatása, amit már nem tudott senki, a mainstream média és a politikai döntéshozók sem figyelmen kívül hagyni), hogy elég, ha a fizikai folyamatokra épülő üzleti rendszerek némelyike esik áldozatául egy kiberbiztonsági incidensnek, már egy ilyen eset is vezethet oda, hogy az ICS rendszerek leállítása (és ezen keresztül a fizikai folyamatok leállítása) lesz a kisebbik rossz.

Összefoglalva (és válaszolva GéPé kérdéseire):

"Mi a véleményetek a technológia közeli védelem megerősítésének vázolt koncepciójáról?"

Mindenképp szükségesnek gondolom a L1/L0 eszközök kiberbiztonsági képességeinek és védelmi szintjének javítását (érdekes adalék egyébként, hogy egy távoli munkatársam, aki ismeri Joe-t, vitatja Joe azon állítását, hogy a L1/L0 eszközökben semmilyen kiberbiztonsági funkció ne lenne, de konkrét példákat, mint ellenérve még tőle sem láttam) és a SIGA OT Solutions által készített megoldás is lehet olyan jó, mint bármelyik OT hálózatbiztonsági termék, ezt igazán majd az idő és a gyakorlati alkalmazás fogja megmutatni.

"Egy ilyen védelem valóban csökkentené-e egy zsarolóvírusos támadó késztetését?"

Ebben viszont nem hiszek. A ransomware-bandák azért működnek hosszú évek óta ilyen sikeresen, mert kis befektetés mellett tudtak nagy tömegeket támadni (amíg a fő célpontjaik a magánszemélyek voltak), aztán felismerték, hogy a vállalatok elleni támadásokkal jóval nagyobb összegeket is követelhetnek, majd azt, hogy ha a civilizációnk alapjait biztosító ipari folyamatokat irányító szervezetek automatizált rendszereit támadják, sokkal komolyabb nyomást tudnak gyakorolni, hiszen az adatok helyreállításánál sokkal fontosabb, hogy a folyamatvezérlés működjön. Viszont a támadók (némi OSINT felderítéssel) azt is megtudhatják, hogy milyen ügyviteli rendszereket kell ahhoz támadniuk, hogy siker esetén a célpont szervezet fizikai folyamatirányítása majdnem vagy pontosan ugyanannyira megbénuljon, mintha a (jó esetben) sokkal nehezebben hozzáférhető ICS rendszereket és különösképpen a L1/L0 eszközöket támadnák. Éppen ezért én nem számítok arra, hogy a közeli jövőben csökkenne az ipari szervezetek elleni zsarolóvírus-támadások száma, inkább csak növekedni fog.

Első körben ennyit gondoltam hozzátenni a témához (így is hosszabb lett ez a poszt, mint elsőre gondoltam, tovább is tartott megírni, mint eredetileg terveztem), de remélem ez a téma nem itt és most hal el, hanem többen elkezdenek írni a vele kapcsolatos gondolatairól.

Sérülékenységek Swisslog Healthcare pneumatikus csőposta rendszerekben

Barak Hadad és Ben Seri, az Armis munkatársai összesen 8 sérülékenységet találtak a Swisslog Healthcare pneumatikus csőposta megoldásának Nexus Control Panel komponensének 7.2.5.7-esnél korábbi verzióiban.

A gyártó a hibákat (egy kivételével) a 7.2.5.7-es verzióban javította. A sérülékenységek részleteit az ICS-CERT publikációjában lehet megtalálni: https://us-cert.cisa.gov/ics/advisories/icsma-21-215-01

Advantech WebAccess/SCADA rendszerek sérülékenységei

Chizuru Toyama, a TXOne IoT/ICS Security Research Labs munkatársa, a ZDI-vel együttműködve három sérülékenységet jelentett a DHS CISA-nak, amiket az Advantech alábbi rendszereiben fedezett fel:

- WebAccess/SCADA 8-as 8.4.5-nél korábbi verziói;
- WebAccess/SCADA 9-es 9.0.1-nél korábbi verziói.

A gyártó a hibákat javító újabb verziókat már elérhetővé tette. A sérülékenységekről bővebb információkat az ICS-CERT bejelentése tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-217-04

mySCADA myPRO sérülékenységek

Michael Heinzl 4 sérülékenységről közölt információkat a DHS CISA-val a mySCADA myPRO 8.20.0-nál korábbi verzióival kapcsolatban.

A gyártó a hibákat a v8.20.0 és újabb verziókban javította. A sérülékenységekkel kapcsolatban bővebb információkat az ICS-CERT weboldalán lehet olvasni: https://us-cert.cisa.gov/ics/advisories/icsa-21-217-03

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

Egy névtelenségbe burkolózó biztonsági kutató, a ZDI-vel együttműködve 3 sérülékenységről közölt infromációkat a DHS CISA-val, amiket a FATEK Automation FvDesigner nevű, HMI termékeihez használható szoftverében talált.

A gyártó nem reagált a DHS CISA hibákkal kapcsolatos megkeresésére. A sérülékenységről bővebb információkat az ICS-CERT publikációjában lehet elérni: https://us-cert.cisa.gov/ics/advisories/icsa-21-217-02

HCC Embedded InterNiche TCP/IP stack sérülékenységek

Amine Amri, Stanislav Dashevskyi és Daniel dos Santos, a Forescout valamint Asaf Karas és Shachar Menashe, a VDOO munkatársai összesen 14 sérülékenységet találtak a HCC Embedded alábbi TCP/IP stack-jeiben:

- InterNiche stack minden, v4.3-nál korábbi verziója;
- NicheLite minden, v4.3-nál korábbi verziója.

A sérülékenységek közül 4 (CVE-2020-35683, CVE-2020-35684, CVE-2020-35685 és CVE-2021-31401) a Siemens alábbi megoldásaiban is megtalálhatóak:

- SENTRON 3WA COM190-es minden, V2.0.0-nál korábbi verziója;
- SENTRON 3WL COM35-ös minden, V1.2.0-nál korábbi verziója;
- SENTRON 7KM PAC Switched Ethernet PROFINET Expansion Modul minden, V3.0.4-nél korábbi verziója.

A hibákat a HCC az érintett megoldásaik v4.3-as verziójában javította és a Siemens is kiadta a javításokat tartalmazó újabb verziókat. A sérülékenységek részleteiről az ICS-CERT és a Siemens ProductCERT bejelentéseiben lehet olvasni.

Sérülékenységek ARC Informatique rendszerekben

Az ARC Informatique bejelentése szerint 3 sérülékenységet találtak a PcVue nevű megoldásuk 8.10-esnél újabb, de 12.0.17-esnél korábbi verzióióban.

A sérülékenységekkel kapcsolatban további információkat a gyártó weboldalán lehet találni (authentikáció után).

Moxa ipari switch-ek sérülékenysége

A Moxa által publikált információk szerint Liu Jinyong, a Qi An Xin Group Inc. ipari folyamatirányítási biztonsági laborjának munkatársa egy sérülékenységet fedezett fel a Moxa EDS-405A sorozatú Ethernet switch-einek 3.8-as és korábbi firmware-verzióiban.

A gyártó a hibát a 3.10-es és újabb firmware-verziókban javította. A sérülékenységgel kapcsolatos további részleteket a Moxa weboldalán lehet megtalálni.

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.

A blogon már két vendégposzt is foglalkozott az USA-ban kiadott elnöki rendelettel (EO 13920, Executive Order on Securing the United States Bulk-Power System) és annak a Biden-adminisztráció hivatalba lépése utáni változásaival. A Claroty nemrég rögzített podcast-jában pont ezekről a változásokról és Biden elnök 100 napos, a villamosenergia-rendszer kiberbiztonságát javítani célzó intézkedéseiről lehet hallani.

A felvétel fontosabb témái:

- Az IT-OT konvergencia által generált kockázatok;
- A villamosenergia-rendszer egyedi fenyegetései;
- Hogyan lehet a legjobb kiberbiztonsági ellenállóképességet beépíteni a villamosenergia-rendszer IT és OT rendszereibe?
- Karrierlehetőségek a villamosenergia-szektorban kiberbiztonsági szakterületen;
- Az amerikai Energy ISAC (E-ISAC) küldetése.

A podcast felvételét innen lehet letölteni.

Sérülékenységek KUKA rendszerekben

Chen Jie, az NSFOCUS munkatársa két sérülékenységről közölt információkat a DHS CISA-val, ami a KUKA alábbi rendszereit érinti:

- KR C4 minden, 8.7-nél korábbi verziója;
- KSS minden verziója.

A gyártó a hibákkal kapcsolatban kockázatcsökkentő intézkedések alkalmazását javasolja. A sérülékenységek részleteiről az ICS-CERT publikációjából lehet tájékozódni: https://us-cert.cisa.gov/ics/advisories/icsa-21-208-01

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

Parul Sindhwad és Dr. Faruk Kazi, a COE-CNDS Lab munkatársai egy sérülékenységről tájékoztatták a DHS CISA-t, amit a Mitsubishi Electric alábbi termékeiben találtak:

- GOT2000 GT27-es, GT25-ös és GT23-as modelljeinek minden 01.19.000 és 01.39.010 közötti verziói, amennyiben használják a “MODBUS/TCP Slave, Gateway” kommunikációs meghajtó szoftvert;
- GT SoftGOT2000 minden, 1.170C és 1.256S közötti verziói, amennyiben használják a a “MODBUS/TCP Slave” kommunikációt.

A gyártó a hibát javító újabb verziókra történő frissítést javasolja. A sérülékenységgel kapcsolatos továbib információk az ICS-CERT bejelentésében érhetőek el: https://us-cert.cisa.gov/ics/advisories/icsa-21-208-02

Geutebrück kamerák sérülékenységei

Titouan Lazard és Ibrahim Ayadhi, a RandoriSec munkatársai tucatnyi sérülékenységről osztottak meg információkat a DHS CISA-val, amiket a Geutebrück alábbi eszközeiben használt, UDP Technology-tól származó firmware-ben találtak:

- E2 sorozatú kamerák – G-CAM 1.12.0.27-es és korábbi, valamint 1.12.13.2-es és 1.12.14.5-ös verziói
- EBC-21xx;
- EFD-22xx;
- ETHC-22xx;
- EWPC-22xx;
- Encoder G-Code1.12.0.27-es és korábbi, valamint 1.12.13.2-es és 1.12.14.5-ös verziói
- EEC-2xx;
- EEN-20xx.

A gyártó a hibákat az 1.12.14.7-es és újabb firmware-ekben javította. A sérülékenységekkel kapcsolatos további részletek az ICS-CERT weboldalán olvashatóak: https://us-cert.cisa.gov/ics/advisories/icsa-21-208-03

Sérülékenység LCDS rendszerekben

Michael Heinzl egy sérülékenységet jelentett a DHS CISA-nak a Leão Consultoria e Desenvolvimento de Sistemas Ltda ME LAquis SCADA rendszerének 4.3.1.1011 és korábbi verzióival kapcsolatban.

A gyártó a hibát a 4.3.1.1079-es és újabb verziókban javította. A sérülékenységről bővebb információkat az ICS-CERT publikációja tartalmaz: https://us-cert.cisa.gov/ics/advisories/icsa-21-208-04

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

Kimiya, a ZDI-vel együttműködve két sérülékenységről közölt részleteket a DHS CISA-val, amiket a Delta Electronics DIAScreen v1.1.0-nál korábbi verzióiban fedezett fel.

A gyártó a hibát az 1.1.0 verzióban javította. A sérülékenységről további információk az ICS-CERT bejelentésében olvashatóak: https://us-cert.cisa.gov/ics/advisories/icsa-21-208-05

Wibu-Systems CodeMeter Runtime sérülékenység

Ahogy a múlt héti sérülékenységi posztban már a Siemens egyes rendszerei kapcsán említésre került, a Tenable munkatársai két sérülékenységet találtak a Wibu-Systems CodeMeter Runtime v7.21a-nál korábbi verzióiban.

A gyártó a hibával kapcsolatban a v7.21a vagy újabb verziókra történő frissítést javasolja. 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-21-210-02

Sérülékenység Hitachi ABB Power Grids rendszerekben

A Hitachi ABB Power Grids egy sérülékenységről tájékoztatta a DHS CISA-t, amit az eSOMS 6.3-as és korábbi verziójú termékeikben találtak.

A gyártó a hibát a 6.3.1-es és későbbi verziókban javította. A sérülékenységgel kapcsolatos további információkat az ICS-CERT publikációja tartalmazza: https://us-cert.cisa.gov/ics/advisories/icsa-21-210-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.