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

ICS Cyber Security blog

ICS Cyber Security blog

Videók az S4x16 Europe-ról I

Interjú az ICS-CERT igazgatójával

2016. május 26. - icscybersec

A Digital Bond egy közel 20 éves múltra visszatekintő tanácsadó cég, ami az egyik első ICS biztonsággal foglalkozó vállalat. A Digital Bond a szervezője a minden év januárjában megrendezett SCADA Security Scientific Symposium-nak (S4) is, aminek ma már Európában és Japánban is van egy-egy rendezvénye. Az idei S4xEurope (ami egyébként Bécsben lesz június 9-10-én) felvezetéseként jelent meg egy kb. háromnegyed órás élő interjú videófelvétele, amin Marty Edwards, az ICS-CERT igazgatója beszél DHS által életre hívott és működtetett szervezet múltjáról, jelenéről és feladatairól.

A videó elérhető a Digital Bond blog-ján vagy közvetlenül a YouTube-on.

ICS sérülékenységek XXXIV

Moxa MiiNePort sérülékenységek

Az ICS-CERT tegnap publikált bejelentése alapján Kam Ganeshen független biztonsági kutató több hibát fedezett fel a Moxa MiiNePort soros porti szervermoduljában, amit számos iparágban használnak. A hibák az alábbi MiiNePort verziókat érintik:

- MiiNePort_E1_7080 Firmware Version 1.1.10 Build 09120714,
- MiiNePort_E1_4641 Firmware Version 1.1.10 Build 09120714,
- MiiNePort_E2_1242 Firmware Version 1.1 Build 10080614,
- MiiNePort_E2_4561 Firmware Version 1.1 Build 10080614, és
- MiiNePort E3 Firmware Version 1.0 Build 11071409.

A hibák között van érzékeny konfigurációs adatok olvasható szöveges formában történő tárolás, XSRF és gyenge (valójában nem létező) authentikációs adatkezelés - ez utóbbi konkrétan azt jelenti, hogy a gyári alapértelmezett beállítások szerint nincs kezdeti jelszó konfigurálva a MiiNePort eszközökön.

A hibák javítását a gyártó május végére ígéri, amíg ez elérhetővé válik, az alábbi intézkedéseket javasolja a MiiNePort felhasználóknak:

- Tiltsák le a 80/tcp (http) és 23/tcp (telnet) portokat;
- A következő portok elérését korlátozzák, hogy csak megbízható rendszerek illetve távoli adminisztrátori feladatokat végző szakemberek használhassák őket: 161/udp (SNMP), 4800/udp, 4900/udp, 4900/tcp;
- Az eszközökhöz csak jelszó megadása után lehessen elérni.

Az ICS-CERT a szokásos, kockázatcsökkentő intézkedéseket javasolja a hibákkal kapcsolatban:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

További részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-145-01

Manuális vezérlés, mint alternatív megoldás ICS rendszerek elleni támadások esetén?

Az ICS/SCADA rendszerek világában az incidenskezeléssel és incidens utáni helyreállítással kapcsolatban az uralkodó nézet még nemrég is az volt, hogy az HMI/MMI-ok ellenőrzött image-ből történő helyreállítása legrosszabb esetben is néhány nap alatt lehetővé teszik az üzemszerű működés maradéktalan helyreállítását.

Az ukrán áramszolgáltatókat érintő tavaly év végi incidens nyomán ez a nézet most megváltozni látszik, egyrészt Ukrajnából is érkeznek olyan hírek, hogy a támadás után több hónappal még mindig részlegesen manuális vezérlést alkalmaznak egyes Ivano-frankovszki alállomásokon, annak ellenére, hogy az ICS rendszereket "csak" szoftveresen tették tönkre (letörölve/felülírva a SCADA rendszer egyes számítógépein a fájlokat és szándékosan hibás firmware-frissítéseket végrehajtva egyes alállomási RTU-kon). Ezzel párhuzamosan egy nemrégiben megjelent, az amerikai Belbiztonsági Minisztérium (DHS) által kiadott ismertető szerint az incidens utáni helyreállás akár 6 hónapot is igénybe vehet - feltéve, hogy az ICS rendszer nem károsodott jelentősen! Ha fontosabb berendezések is károsodnak és azokat cserélni kell, ez az idő akár 9-18 hónap is lehet.

Az USA-ban egyre hangosabbak azok a szakemberek (egyik szószólójuk Joe Weiss), akik próbálják felhívni a figyelmet a kritikus infrastruktúrák védelmi szintjének elégtelenségére. Joe legújabb blogpostjában azt a kérdést teszi fel, hogy az amerikai villamosenergia-szektor és nukleáris erőművek egy esetleges kibertámadás esetén hogyan tudják biztosítani a manuális vezérléshez szükséges integritást. Ezzel a témával itthon is célszerű lenne foglalkozni, tapasztalataim szerint a hazai közműszolgáltatók és egyéb kritikus infrastruktúrához sorolt szervezetek jelentős részénél gondolják úgy, hogy képesek a kritikus ICS rendszerek nélkül, manuálisan ellátni a minimális feladatokat.

Sajnos ahogy az Unfettered blogon hivatkozott, Sandia National Laboratory-nál dolgozó Ray Parks tapasztalta, azoknál a szervezeteknél, ahol magabiztosan állítják, hogy a manuális vezérlésre is felkészültek, néhány kérdés után többnyire kiderül, hogy a valóság meglehetősen távol áll a tervektől, amik csak hamis biztonságérzetet adnak.

A manuális vezérlés, mint vészforgatókönyv működőképességét két további tényező is rontja. Az egyik, hogy azok az idősödő és lassan nyugdíjba vonuló szakemberek, akik még ismerték az egyes ipari rendszerek automatizált irányítása előtt bevett üzemeltetési eljárásokat, szépen lassan lecserélődnek fiatalabb kollégákra, akik azonban már csak az ICS/SCADA rendszereken keresztül vezérlési eljárásokat ismerik, soha nem kellett a manuális vezérlési eljárásokkal megismerkedniük. Most, az ukrán incidens után egyes helyeken már vannak arra irányuló kezdeményezések, hogy ilyen jellegű teszteket és gyakorlatokat is beépítsék a képzési tervekbe.

A másik probléma az Internet of Things (IoT) térhódítása az ipari rendszerek esetén. Egyrészt az IoT még az általános IT szintjénél is rosszabb helyzetben van, ami a biztonságot illeti, másrészt ez a trend csak még jobban erősíti az automatizált működést, ami tovább csökkenti a sikeres manuális vezérlésre történő visszatérés esélyeit.

A kérdés, hogy a kritikus infrastruktúrák képesek-e hosszabb ideig manuális vezérlésre hagyatkozva ellátni az alapvető feladataikat, egyelőre megválaszolatlan, de az biztos, hogy mindazoknak, akik ilyen szervezeteknél az ICS rendszerek üzemeltetésével és/vagy biztonságával, illetve BCP/DRP-tervezéssel foglalkoznak, mindenképpen foglalkozniuk kéne a témával.

ICS sérülékenységek XXXIII

Resource Data Management Intuitive 650 TDB Controller sérülékenységek

Az ICS-CERT tegnap publikált bejelentése alapján Maxim Rupp két hibát talált a Resource Data Management által gyártott Intuitive650 TDB Controller nevű termékének 2.1-es és korábbi verzióiban. A hibák között jogosultságszint-emelés és CSRF is található. A hibák távolról is kihasználhatóak.

A gyártó a V2.1.24-es verzióban javította a fenti hibákat.

Az ICS-CERT a hibával kapcsolatban a szokásos, kockázatcsökkentő intézkedéseket javasolja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari rendszerek/hálózatok távoli eléréséhez biztonságos módszereket (pl. VPN) kell használni, de szem előtt kell tartani azt is, hogy az egyes VPN-megoldásoknak is lehetnek sérülékenységeik és ezeket is folyamatosan frissíteni kell a legújabb elérhető verzióra. Nem szabad elfelejteni továbbá azt sem, hogy a VPN csak annyira biztonságos megoldás, mint az eszköz, amit a VPN-en keresztül a védett hálózathoz csatlakoztatnak!

A sérülékenységekkel kapcsolatban további információkat az ICS-CERT bejelentés tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-140-01

ICS sérülékenységek XXXII

Moxa EDR-G903 Secure Router, IRZ RUH2 3G és Siemnens SIPROTEC sérülékenységek

Az ICS-CERT tegnapi bejelentéseiben két ipari rendszer sérülékenységeire hívta fel a figyelmet.

Moxa EDR-G903 Secure Router sérülékenységek

Maxim Rupp számos hibát fedezett fel a Moxa EDR-G903 Secure Router nevű, all-in-one VPN/tűzfal/NAT Layer-3 eszközének V3.4.11 és korábbi verziós szoftvereiben. A hibák között van jogosultság-szint emelést lehetővé tevő hiba, jelszavak szöveges formában történő tárolása, memóriaszivárgás, szolgáltatás-megtagadást (DoS) és authentikáció nélküli fájlfeltöltést lehetővé tevő hiba is.

Ezek a hibák távolról is kihasználhatóak. A gyártó a V3.4.12-es verziójú firmware-ben javította a hibákat és az érintett termékét használó ügyfeleinek kérésre elérhetővé teszi.

A hibával kapcsolatban további információkat az ICS-CERT bejelentésében lehet olvasni: https://ics-cert.us-cert.gov/advisories/ICSA-16-042-01

IRZ RUH2 3G sérülékenység

Az IRZ (orosz ipari rendszereket fejlesztő cég) RUH2 soros-Ethernet interfészében az ICS-CERT fedezett fel korlátozás nélküli fájlfeltöltésen alapuló, firmware-felülírást lehetővé tevő sérülékenységet. A hibát távolról is ki lehet használni.

A gyártó az érintett eszközöket használó ügyfeleinek azt tanácsolja, hogy az RUH2 típusú eszközöket cseréljék RUH2b vagy RUH3 típusra. A sérülékenységről további információkat a gyártó weboldala (http://www.irz.net/en/support), valamint az ICS-CERT bejelentése (https://ics-cert.us-cert.gov/advisories/ICSA-16-138-01) tartalmaz.

Az ICS-CERT mindkét sérülékenységgel kapcsolatban a szokásos kockázatcsökkentő tanácsokat adja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

Siemens SIPROTEC 4 és SIPROTEC Compact sérülékenység

A Siemens ma publikált bejelentése szerint a SIPROTEC 4 és Compact nevű termékeiben több olyan hibát fedeztek fel, amiket kihasználva érzékeny adatokhoz férhet hozzá egy támadó. Az érintett termékek a következők:

- SIPROTEC 4 és SIPROTEC Compact eszközökben használt EN100 Ethernet modul V4.26 és korábbi verziói;
- A SIPROTEC Compact  7SJ80, 7SK80, 7SD80,7RW80, 7SJ81, 7SK81 modelljeiben található Ethernet Service Interface A portja (minden firmware verzió érintett).

A gyártó a hibát az EN100 modulokhoz kiadott V4.27-es firmware-verzióban javította. Azon ügyfeleinek, akik nem tudnak firmware-t frissíteni, a Siemens hálózatbiztonsági intézkedések alkalmazását javasolja (tűzfalak, hálózatszegmentálás és VPN használatát).

A sérülékenységgel kapcsolatban a Siemens ProductCERT-en és az ICS-CERT bejelentésében található további információ.

ICS sérülékenységek XXXI

Sérülékenység Cisco ipari Ethernet switch-ekben

A Cisco által május 13-án közzétett bejelentés alapján a Cisco Industrial Ethernet 4000 és 5000 sorozatú switch-ekben olyan, IPv4 csomagfeldolgozási hibát találtak. A hiba az alábbi szoftververziókat érinti:

- Cisco Industrial Ethernet 4000 Series Switch-ek, amik Cisco IOS Software Releases 15.2(2)EA, 15.2(2)EA1, 15.2(2)EA2, vagy 15.2(4)EA verziókat futtatnak;
- Cisco Industrial Ethernet 5000 Series Switch-ek, amik Cisco IOS Software Releases 15.2(2)EB vagy 15.2(2)EB1 verziókat futtatnak.

A hibára workaround nincs, a Cisco az alábbi javított verziójú firmware-ek telepítését javasolja:

- Cisco Industrial Ethernet 4000 Series Switch-ek esetén: 15.2(2)EA3 és 15.2(4)EA1;
- Cisco Industrial Ethernet 5000 Series Switch-ek esetén: 15.2(2)EB2

További információkat a Cisco által kiadott figyelmeztetés tartalmaz.

ICS sérülékenységek XXX

Meteocontrol WEB'log sérülékenységek

Az ICS-CERT legutóbbi, május 12-i bejelentése Karn Ganeshen független biztonsági kutató által a Meteocontrol WEB'log szoftverében talált sérülékenységekről szól.

A hibák az alábbi verziókat érintik:

- Basic 100 minden verziója,
- Light minden verziója,
- Pro minden verziója és
- Pro Unlimited minden verziója.

A hibák között van adminisztratív feladatokhoz használt weboldalak authentikáció nélkül történő elérésének lehetősége, shell-szerű hozzáférés authentikáció nélkül és érzékeny adatok szöveges formában történő tárolása.

A hibákat távolról is ki lehet használni.

A gyártó a hibákat a legújabb, weboldalán elérhető verzióban javította és azt javasolja a felhasználóknak, hogy WEB'log rendszereket tűzfallal védjék és ne legyen közvetlen Internet-kapcsolatuk.

Az ICS-CERT ezen túlmenően a szokásos, kockázatcsökkentő intézkedéseket javasolja:

- Minimálisra kell csökkenteni az ipari rendszerek/hálózatok kapcsolatát az Internettel;
- Az ipari rendszereket/hálózatokat tűzfalakkal kell elválasztani a vállalati hálózatoktól;
- Az ipari 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!

További részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-133-01

ICS biztonsági tanácsok a tömegközlekedési rendszerekkel dolgozók számára

A Belden ipari biztonsági témákkal foglalkozó blogjában jelent meg egy cikk, amiben a világ minden részén rohamosan fejlődő és terjeszkedő tömegközlekedési rendszert kiszolgáló ICS rendszerek biztonságát befolyásoló problémákat és ezek negatív hatásait ellensúlyozó tanácsokat szedtek össze.

Az egyik legfontosabb problémaként itt is az ICS rendszerek Ethernet hálózatokkal történő összekötését említik, a szokásos körülmények mentén: növelni kell a teljesítményt és kapacitást, de mindeközben a költségek csökkentése legalább ennyire fontos (ha nem fontosabb), ezért a tömegközlekedést kiszolgáló ICS rendszereknél is egyre jobban terjednek a költséghatékony standard IT technológiák, protokollok és operációs rendszerek, amelyek magukkal hozzák a nyílt interfészeket és standard protokollokat. Ahogy ezeket a technológiákat egyre nagyobb mértékben integrálják a tömegközlekedés irányító és kommunikációs rendszereibe, úgy nőnek azok a kockázatok is, amiket ezeknek a technológiáknak a már ismert, de még nem javított vagy még nem is ismert hibái jelentenek a tömegközlekedés biztonságára nézve.

Felmerülhet a kérdés, hogy a kiberbiztonság jelenthet-e olyan szintű kockázatot, amivel már foglalkozni kell, amikor a tömegközlekedésbe olyan biztonsági (safety) protokollok vannak beépítve évtizedek óta, amik számos esetben sikeresen előztek meg baleseteket és tömegszerencsétlenségeket? Tény, hogy az üzembiztonsági intézkedések a közvetlen kockázatok többségét hatékonyan csökkentik egy elfogadható szintre, azonban a kiberbiztonsági kockázatok nagyobb része nem közvetlenül, jóval inkább közvetett módon jelenik meg a tömegközlekedés ICS rendszerei esetén, különösen, hogy amint ezek az ICS rendszerek egyre összetettebbek lesznek, úgy lesz egyre nehezebb elérni a megbízható üzembiztonsági szintet.

Fontos kiemelni, hogy a kiberbiztonsági kockázatok nem kizárólag az ICS rendszerek biztonságát (safety) befolyásolhatják, hanem lehetőséget kínálnak a teljes ellátási láncra hatást gyakorolni, amelyek gyorsan válhatnak olyan hatássá, amik közvetlenül érintik a tömegközlekedés működését. Például a tartalék alkatrészek késleltetésével el lehet érni, hogy egy vonatot ki kelljen vonni a forgalomból, ezzel befolyásolva a menetrendet (ez Magyarországon nem feltétlenül jelent komoly eseményt, de vannak országok, pl. Japán, ahol még a kisebb késések sem elfogadhatóak) vagy akár a szolgáltatás egészét.

A megnövekedett kiberbiztonsági kockázatok miatt számos ICS biztonsági szabvány született az elmúlt években, amik a tömegközlekedési rendszerek kiberbiztonsági kockázatainak elfogadható mértékűre történő csökkentését célozzák. Ilyen szabvány többek között:

- APTA (American Public Transportation Association);
- Securing Control and Communication Systems in Transit Environments – Part 1;
- RSSB (UK Railway Safety and Standards Board, a railway stakeholder group);
- Rail Cybersecurity Guidance to Industry;
- Transportation Industrial Control System (ICS)Cybersecurity Standards Strategy;
- ENISA Railway;
- ISA/IEC 62443.

Ezek a szabványok számos intézkedést tartalmaznak, amiknek a bevezetése (különösen ICS környezetben) jócskán elhúzódhat, de néhány egyszerűbb, alapvető intézkedéssel jelentős javulást lehet elérni a tömegközlekedésben használt ICS rendszerek biztonságát illetően:

1.) Kockázatelemzés

Minden biztonsági intézkedést célszerű kockázatelemzéssel kezdeni, nincs ez máshogy az ICS rendszerek esetén sem. A hatékony ICS kiberbiztonság megteremtésének alapja, hogy tudjuk, milyen rendszerek, eszközök és folyamatok alkotják az ICS rendszert és értsük ezek funkcióit és üzemszerű működését, ezután lehet elvégzeni a kockázatok értékelését, ami módszertanában nem különbözik bármelyik másik informatikai rendszerrel kapcsolatban végzett kockázatelemzéstől.

2.) Tervezzünk több szintű védelmi stratégiát

A kockázatelemzés után a következő lépés a hálózat biztonságának megtervezése, amiről több szintű (vagy mélységi) védelem (Defense in Depth) néven számos helyen lehet részletekbe menő leírásokat találni. Egy jól tervezett és kialakított több szintű védelmi stratégiának mindenképpen részét képezik az alábbiak:

- Egyetlen ponton elhelyezett biztonsági eszköz/eljárás helyett több rétegbe szervezett eszközök és eljárások;
- A védelem egyes szintjei különbözzenek a többitől, ezzel is nehezítve hogy egy támadó könnyen jusson át a teljes védelmen;
- Az egyes védelmi szintek eltérő fenyegetések ellen legyenek optimalizálva;
- Az azonos biztonsági követelményekkel rendelkező eszközöket tartalmazó zónák biztonsági szintjét az ISA/IEC 62443 szabvány szerint azonos szintűre kell kialakítani.

Helyesen kialakított mélységi védelem egy véletlenszerűen vagy célzottan bekövetkező biztonsági incidens hatásait korlátozni tudja arra a hálózati zónára, ahol az bekövetkezett. Ha mindemellett a megfelelő monitoring rendszer is ki van építve, akkor a megfelelő emberek vagy csoportok rövid időn belül elkezdhetnek dolgozni az incidens minél előbb történő behatárolásán és felszámolásán.

3.) Elsőként a kritikus fontosságú eszközök biztonságát kell megteremteni

A kritikus fontosságúnak tartott eszközöket is priorizálni kell. Például a vasúti személyszállítás esetén az egyik legfontosabb berendezés az az RTU, ami a vasúti jelzőrendszert irányítja, illetve a hálózati infrastruktúra, ami kommunikáció-alapú vonatirányító rendszer (Communications-Based Train Control - CBTC - system) működését biztosítja.

ICS sérülékenységes XXIX

Panasonic FPWIN Pro sérülékenységek

Az ICS-CERT tegnap publikált bejelentése alapján a Panasonic FPWIN Pro PLC programozó szoftverében több hibát talált Steven Seeley biztonsági kutató. A hibák az FPWIN Pro alábbi verzióit érinti:

- FPWIN Pro version 5.x,
- FPWIN Pro version 6.x,
- FPWIN Pro version 7.122 és korábbi verziók

A sérülékenységeket az alábbi hibák okozzák:

- Heap-based buffer overflow
- Access of uninitialized pointer
- Out-of-bounds write
- Type confusion

A fenti sérülékenységeket csak lokálisan és csak felhasználói interakción keresztül lehet kihasználni, ezért mind a négy hiba viszonylag alacsony pontszámot, 4,2-t kapott a CVSSv3 alapján.

A hibákat a gyártó a 7.130-as verzióban javította, az 5.x verziókhoz, mivel már elérték a támogatási időszakuk végét, nem készül javítás, a 6.x verziókhoz pedig csak 2016 szeptemberéig van gyártói támogatás, ezért az ezeket a verziókat használó szervezeteknek a Panasonic azt tanácsolja, hogy frissítsenek újabb (7.x) verzióra.

Az ICS-CERT szokás szerint ad néhány tanácsot, amik alkalmazásával a javítás telepítéséig is csökkenteni lehet a sérülékenységekből származó kockázatokat:

- Ne kattintson kéretlen e-mail-ben érkezett linkre vagy csatolmányra!
- A felhasználók biztonságtudatosságát fejleszteni kell, többek között az e-mail-es csalások, a social engineering és az adathalász támadások témaköreiben.

További részleteket az ICS-CERT bejelentése tartalmaz: https://ics-cert.us-cert.gov/advisories/ICSA-16-131-01

Kutatók PLC-ket célzó férget készítettek

A számítógépes férgek igen hosszú ideje (egyes források szerint 1978 óta) léteznek, azonban az ipari rendszerek speciális komponenseit (PLC-ket, RTU-kat, stb.) nem fertőzték meg (vagy ha igen, akkor erről az érintett rendszerek üzemeltetői mélyen hallgattak). Az idei Black Hat Asia konferencián azonban az OpenSource Security munkatársai (Ralf Spenneberg, Maik Brüggemann és Hendrik Schwartke) egy olyan kísérleti féregről tartottak előadást, amit kifejezetten PLC-környezetben történő terjedésre fejlesztettek ki, egészen pontosan a Siemens SIMATIC S7-1200v3 vezérlőket képes megfertőzni.

A férget PLC-Blaster-nek nevezték el és működése többnyire emlékeztet a hagyományos férgekére. A kutatók legvalószínűbb fertőzési vektorokként a PLC-k gyártóit illetve az eszközök szállítás során történő megfertőzését (itt most mindenki gondoljon példának okáért az NSA TAO által használt módszerekre) tartják. Ha egy, a féreg által megfertőzőtt eszköz bekerül a megfelelő hálózatba, a féreg elkezdi scannelni a hálózatot a 102/tcp portot keresve, ami hasonló eszközök jelenlétére utalhat. Ha olyan PLC-t talál, ami még nincs megfertőzve, a féreg nagyjából 10 másodpercre leállítja a PLC-t, ez idő alatt áttölti a saját kódját, majd újraindítja. A kutatók szerint a féreg a Siemens TIA-Portalt utánozva másolja magát és a SIMATIC S7-1200 CPU szoftverekben a gyártó által 2016. március 14-én publikált javítással foltozott hibát kihasználva tudja fertőzni a PLC-ket.

Az OpenSource Security kutatói itt azonban még nem álltak meg a proof-of-concept féreg fejlesztésével és további funkciókat adtak hozzá, képes Command&Control szerverrel kommunikálni, működhet Socks4 proxy-ként, képes szolgáltatás-megtagadás (DoS) támadást indítani és manipulálni tudja a PLC-ből kimenő adatokat.

További részleteket a kutatásról készített 16 oldalas dokumentum tartalmaz.

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