Következmények

 

Matrix Now!A Stuxnet az első a sorban, és szinte biztosak lehetünk abban, hogy nem az utolsó.

 Eddig teljes iparágak ringatták magukat abban a hitben, hogy rendszerük biztonságos, és ez a „Titanic-szindróma” most kapott léket, az első, valóban hatalmas méretű pusztítást végző kártevő kapcsán. Persze, még nyugtathatjuk a lelkünket, hogy ugyan már, ez „csak” az agresszor Iránnal történt, és hogy ők ezt simán megérdemlik, de érdemes belegondolni, hogy amott viszont forr a düh, PC-kkel és jó programozókkal ők is rendelkeznek – ne legyenek illúzióink, a válasz-csapás kódja már íródik.

 Felvetődött bennem, hogy ezt a cikket egyfajta „ötletadó”-nak is lehet tekinteni, de – ezt a Stuxnet példáján láttuk – az ilyen jellegű vírusok nem az iskolából az otthoni számítógépük elé bevetődő tinik szórakozásai. Ezeknek a kifejlesztését jórészt állami pénzből finanaszírozzák, szakértők bevonásával, akik nem egy ilyen cikkből fognak ötleteket meríteni. Ha eddig nem volt, ezután például Iránnak biztosan lesz ilyesmire is pénze.

A védekezés viszont sajnos nem állami pénzből történik, hanem lelkes programozók, IT-sek munkája nyomán válhatnak védettebbé a rendszerek, az ötleteket nekik szánom, hátha a saját elképzeléseikhez hozzá tudok ezzel valamit tenni.

 A továbbiakban néhány – közép és hosszútávon megvalósítható védekezési lehetőséget fogok felvetni, a tűzoltás a következő fejezetben található.

A cikk első részét itt lehet elérni.

Ami nem működik

 

A rövidtávú (tűzoltó) megoldások, melyeket a következő fejezetben írok le, sajnos közép- és hosszútávon hasznavehetetlenek, mert nem számolnak az emberi tényezővel. Képletesen, a folyosót hiába mossuk fel ragyogó tisztára, ha ott perceken belül mindenki ismét sáros csizmával vágtázhat keresztül.

Mindig lesznek olyan „okos tojás” és/vagy sértett alkalmazottak, akik a legszigorúbb policity-ket is kijátsszák, és csak sikerül majd azt a bizonyos USB egységet a terminálhoz csempészni, mely majd például Allah nevében fog tarolni.

Emberi tényező

 

Mottó: Képzeljük el, hogy a kezelői terminálhoz egy csimpánzt ültetünk. Játsszuk le gondolatban, hogy az szórakozásból az összes színes és nem színes gombot végignyomkodja - a legelképesztőbb kombinációkban is. Ezzel a gondolatkísérlettel egy unatkozó operátor kreativitását meg sem tudjuk közelíteni.

Paranoia

 

Sokszor látom munkám során, hogy a vezetők és az operátorok is végletesen megbíznak a technikában, a rendszerek jelzéseiben, és sokszor, saját józan logikájukat is félresöpörve elhiszik azt, amit a gép állít. Ez a kényelmes hozzáállás nagyon komoly hibákhoz vezethet.

A kezelő, a programozó, a rendszer tervezője és a kivitelezője is tévedhet, és ezek a tévedések igen sok szituációban felerősítik egymást, és nagyon végzetes következményeket eredményezhetnek.

Egy egészséges gyanakvás – enyhe paranoia – minden ilyen rendszer esetében jól jöhet.

Mottó: Attól, hogy nem vagy paranoiás, még nem biztos, hogy nem üldöznek.

RUN / RUN-P

Az S7-300-as RUN (védett mód) funkciójaAz S7-315-ös gépeken (is) található az a bizonyos üzemmód választó forgó-kapcsoló, mellyel a RUN-P, RUN, STOP, MRES állások között lehet választani. Ez a kapcsoló a legtöbb helyen RUN-P állásba van állítva, pusztán kényelmi okok miatt. (Ne felejtsük el, a Stuxnetben elrejtett kód egy része S7-315-ösökre lett fejlesztve).

 

 A RUN-P egy programozói mód, mely alatt a kódot a működő PLC-n is lehet módosítani. A RUN a régebbi PLC-ken (lásd a képen) védett módú futtatást eredményez, azaz a kódot „futtában” nem lehet módosítani.

 

A módosítás menete normális helyeken, előírásszerűen:

 

1. A programozó tájékoztatja az arra illetékeseket a módosítás jellegéről, az esetleges kiesés vagy bekövetkező nem elvárt események jellegéről és valószínűségéről

2. Megvárja, míg a helyi erők előkészülnek a worst-case-re. 

3. Elballag a vezénylő szekrényhez, és RUN-P-be teszi a PLC-t.

4. Módosít, majd vissza RUN módba.

5. Távozás előtt beírja az üzemnaplóba, hogy mit módosított, és hogy a PLC-t visszatette RUN-ba.

Ez a kapcsoló az újabb 300-asokon már nincs, csak RUN mód, az S7-400-asokon pedig nem is volt.

Program dokumentáció és forráskód kezelése

 

A Stuxnet „sikerét” annak a ténynek köszönheti, hogy a megírói az utolsó csavarig ismerték a cél-hardvert, és az utolsó bitig annak programját. A program pontos ismerete nélkül egy ilyen támadás ennyire hatékonyan nem hajtható végre. A porosodó dossziékat el kell zárni vagy egy külön helységbe, vagy egy páncélszekrénybe, a fejlesztői másolatokat és a programozói gépet felügyelni és rendesen jelszavazni kell.

No Windows

 

No Windows, please!Az egységes és univerzális operációs rendszer elve magában hordozza a könnyű támadás lehetőségét, legalább két okból:

-         Tömegesen elterjedt, ezért érdemes rá kártevőket fejleszteni. A speciális – ipari létesítményeket támadó – kártevőket pedig lehet az elődökre építeni. A Stuxnet például valószínűleg a Conficker alapjain íródott.

-         Túl sok, univerzális funkciót gyömöszölnek ezekbe az operációs rendszerekbe, melyekre egy ipari rendszernek semmi szüksége, de ezek a rendszer integráns részei (pl. beépített böngésző, multimédia, multi-user,..). Ezek a funkciók mind tele vannak nem publikált biztonsági résekkel, melyek csak krekkereikre várnak.

A gyártók ennek ellenére többnyire csak Windows-os platformra fejlesztik alkalmazásaikat, és persze ennek is több oka van:

-         bevált, mindenki ismeri ezeket a felületeket, a felhasználók nem idegenkednek tőle, mert otthon is csak ez fut.

-         Egységes interfész rendszereket kínálnak, így a speciális driver-ek is viszonylag egyszerűen illeszthetők és integrálhatók, pl. OPC-n keresztül

-         Olcsók. 

Ezen a fronton így először a nagy gyártókat kell meggyőzni a felől, hogy ideje lenne váltani, és talán a Stuxnet is ebbe az irányba tereli őket (és a Windows CE-t is nyugodtan el lehet felejteni).

Vannak persze olyan rendszerek, melyek már elve nem a Windows-ra épülnek, helyette Unix, Linux rendszerekre települnek. Egyelőre kisebb berendezéseknél, az légiközlekedésben, űrkutatásban, hadiiparban és célgépek vezérlésénél például a VxWorks kezd felfutni.

Standard megoldások háttérbe szorítása

 

Régi rögeszmém, hogy az összetett fejlesztői rendszerek (például a PCS7, Comos, ..) sokkal több kárt okoznak létükkel, mint amennyi előnyük van, és ez az érvrendszerem újabb ponttal bővült. Egy analógiával élve: Amennyiben egy gyári riasztós autónk van – lehet az akármilyen drága – sokkal nagyobb esélyünk van arra, hogy ellopják, mintha a sarki szervizben a Jani belekókányol egy immobilizert. Egyszerűen azért, mert míg az előbbit a tolvaj rutinból ismeri, ez utóbbi plusz időt jelent neki, ami számára egyenlő a lebukással.

Egy vírus működése a tolvajénál jelentősen egyszerűbb. Csak azzal az analógiával boldogul, mellyel szerzője felruházta. Az attól való kisebb eltérések is jó eséllyel blokkolják a működését, hiszen a kódot rejteni kell, így az nem lehet túl nagy, ezáltal túl nagy „intelligenciával” nem rendelkezhet. Mint az a Stuxnet működésénél is láttuk, amennyiben nem a szerzők által lekódolt struktúrába fut bele a vírus, jó eséllyel kárt így is tud okozni, de annak nagyságrendje jelentősen kisebb lesz az egyedi megoldások mellett.  

A fejlesztői rendszerek megoldásai a fenti érvelés mentén sérülékenyek, csakúgy, mint az S7 Standard Könyvtárának a funkciói. Ha nekem vírust kellene írnom, szinte biztos, hogy a standard PID hívását támadnám (a PID egy szabályzástechnikai eljárás), mert jellemzően az igen érzékeny funkciók PID-del működnek (ez nem biztos, hogy Standard PID, de sok esetben az). Ennek hívása – szintén standard szerint – többnyire az OB35-ben található. Tegyük át a hívást egy másik „Weckalarm” OB-ba, állítsuk át annak az idejét is 100 ms-ra, bár ezt nem muszáj, és egy „Jani féle” kókányolással már kissé védettebbé tettük rendszerünket – talán.

 

 

 

 

 

 

 

 

 

 

 

 

 

Meglátásom szerint vissza kell térni az egyedi kódolásokhoz, a hamis biztonságot nyújtó standard kódolási megoldásoktól, így amennyiben a behatoló kód fejlesztője nem ismeri behatóan a rendszerünket, annak sok esélye nincs a kódunkon való kiigazodáson.

 Egy általánosan (tehát nem a berendezésünkre) megírt behatoló kód szinte biztosan analógiákra fog menni, és sajnos a nagy berendezéseket nagyon nehéz lesz ettől pusztán a kód szintjén megvédeni (gondoljunk például a jól elhelyezett BEA-kra).

Rendszer-redundancia

 

rendszerszintű redundanciaRedundancia már ma is létezik, és alkalmazzák is, de többnyire csak a rendszereken belül. Ha például az egyik PLC kiesik, rögtön egy másik áll be a helyére – ez az un. „H”-s – rendundáns – PLC rendszerek zanzásított funkcionalitása. Szinte biztos vagyok benne, hogy az iráni natanz-i urándúsító létesítményben is ilyen “H”-s rendszer működött, és ezt sikerült a Stuxnet-nek tönkretennie – ez ugyanis nem rendszer-redundancia.

 A rendszer-redundancia azt jelenti, hogy több, egymástól független rendszer felügyeli az adott technológiát, és az a technológiának is saját vezénylője van. A saját vezénylő csak abban az esetben hajt végre a külső rendszerek felől érkező parancsot, amennyiben az eltérő rendszerektől egységes utasítást kap. A saját vezénylő “black-box”-ként kell, hogy üzemeljen, azaz menet közben nem lehet változtatni a programját.

 

A fenti leírást egy élő példán keresztül szeretném szemléltetni.

 A lenti képen egy korszerű vonat ajtóengedélyező jelének a rendszer-redundanciáját próbálom szemléltetni. A séma gyakorlatilag gyártó-független, bár az Alstom metrók kapcsán nem vagyok meggyőződve afelől, hogy a francia gyártó modellje is ennyire összetett.

Ajtónyitás engedélyzése

 

Nézzük végig az ajtónyitás engedélyezésének a menetét:

1: A vezető kiadja az engedélyező jelet (külön jobb- vagy baloldalit, de ez most lényegtelen.)

2: Egy közvetlen vezetéken (UIC-vezeték) a jel továbbításra kerül

3: A vezénylő is beolvassa a jelet

4: A fékvezénylők jelzik, hogy a vonat álló helyzetben van (v<5km/h)

5: A vezénylő MVB telegramot ad ki az engedélyezésről (a háttérben egy redundáns ZSG fut, mely az elsődleges feladatait veszi át meghibásodás esetén)

6: A WTB link két, egymástól független vezetéken továbbítja a táviratot.

7: A fogadó WTB link összehasonlítja a két táviratot, és egyezés esetén továbbítja azt az MVB-n

Minden ajtó saját ajtóvezérlővel (TSG) rendelkezik, ezek hasonlítják össze a beérkező információkat:

8: Az UIC vezetéken érkező direkt jelzést,

9: A WTB felől MVB-n érkező engedélyező jelet,

10: és a fékek felől érkező álló helyzet (Stillstand) jelzést.

Ha az összes jelzés konzisztens, csak akkor engedélyezi az utasoknak az ajtó nyitását.

A fent leírtak szerint például a centrifugákat is ellenőriztethették volna például olyan PLC-vel, melynek kódja közvetlenül nem módosítható, mert nem Profibuszon vagy Etherneten kommunikálnak, és a szerzőknek rögtön kissé rögösebb útjuk támadt volna:

Tűzoltás (gyors megoldások a Stuxnet ellen)

 

tűzoltásAz első két pont kifejezetten a Stuxnet feltárásában és kezelésében próbál segítséget nyújtani, míg a többi pont általános védekezési intézkedéseket fogalmaz meg.

 

 

 

1. A  TrendMicro által kifejlesztett Tool Sysclean felismeri és eltávolítja a gépről a vírust. A program a Siemens oldaláról letölthető: http://support.automation.siemens.com/WW/llisapi.dll/csfetch/43876783/sysclean.zip?func=cslib.csFetch&nodeid=43932305

Ennek leírása:

http://support.automation.siemens.com/WW/llisapi.dll?func=cslib.csinfo&lang=de&objid=43876783&caller=view

 A fenti vírusirtót először az "Automatically Clean Infected Files" opció kikapcsolásával futtassuk. Amennyiben a programfertőzést észlel,

          1. Installálja a Microsoft Path-ot

          http://support.automation.siemens.com/WW/llisapi.dll?func=ll&objid=43876783&nodeid0=10805583&caller=view&lang=de&siteid=csius&aktprim=0&objaction=csopen&extranet=standard&viewreg=WW#MS%20Security%20Patch

          2. Válassza le a gépet a hálózatról

          3. Adminisztrátor jogokkal futtassa a SIMATIC Security Updates-t

          http://support.automation.siemens.com/WW/llisapi.dll?func=ll&objid=43876783&nodeid0=10805583&caller=view&lang=de&siteid=csius&aktprim=0&objaction=csopen&extranet=standard&viewreg=WW#SIMATIC_Security_Update_verf%C3%BCgbar__

          4. Takarítsa le a gépét a “Sysclean”-nel, aktivált "Automatically Clean Infected Files" funkcióval.

2. Az alábbi oldalak elérését mindenképpen blokkolni kell:

www.mypremierfutbol.com, www.todaysfutbom.com

 3. Alkalmazzunk anti-virus/anti-malware programokat, és ezeken állítsuk be a „full-scan” opciót.

Alkalmazzuk az MS aláírás-ellenőrző programjait: Security Essentials, Forefront Client Security, Live OneCare, Forefront Threat Management Gateway, and Live Safety Platform. Sajnos ezek jellemzően nem kerültek a PCS7/WinCC termékeken előtelepítésre.

 4. A hálózaton belül minden gépen tiltsuk le az USB használatot (a registry módosításával, például)

 5. Amennyiben lehetséges, a belső és külső hálózatokat szeparálni kell. Amennyiben ez nem megoldható, úgy vagy a tűzfalat kell rendkívül paranoiás módra állítani, vagy adatátjátszókat kell bevetni (pl. OPC szerver, kommunikációs interfészek, melyek valamely, nem IP bázison továbbítják az adatokat, mondjuk RS485 vagy Profibus közbeiktatásával)

 6. Alkalmazza a legkisebb jogosultság elvét! (least-privileged user account, LUA), lásd a Wikipedián: http://hu.wikipedia.org/wiki/Legkisebb_jogosults%C3%A1g_elve

 7. Alkalmazza a csoportházirendet, illetve a csoportházirend-objektumokat! (Group Policy Object, GPO) lásd a Wikipedián:

http://hu.wikipedia.org/wiki/Csoporth%C3%A1zirend

Források

Bevezetés:

The Christian Science Monitor

http://www.csmonitor.com/USA/2010/0921/Stuxnet-malware-is-weapon-out-to-destroy-Iran-s-Bushehr-nuclear-plant

 

Sztori:

Cserháti András: A Stuxnet vírus és az iráni atomprogram

http://csatweb.csatolna.hu/tagok/csa/stuxnet_cikk.pdf

Abel Danger: ‘DEADFOO7’computer virus ('deadfoot') - clandestine nuclear-weapons procurement - Guild of Contract Hits - D2 Banking’s digital-data archives

http://www.abeldanger.net/2010/11/deadfoo7computer-virus-deadfoot.html

 

Homeland Security Newswire: Stuxnet may turn Bushehr into a new Chernobyl

http://homelandsecuritynewswire.com/stuxnet-may-turn-bushehr-new-chernobyl

 

Wired: Blockbuster Worm Aimed for Infrastructure, But No Proof Iran Nukes Were Target

http://www.wired.com/threatlevel/2010/09/stuxnet/

 

Sulinet: Atomenergia

http://sdt.sulinet.hu/Player/Default.aspx?g=6617c1dd-f0aa-4d21-82a3-93b849401066&cid=f3ba64b7-0cc1-4402-ad1b-5bc04a3f76af

 

The Register: Stuxnet worm slithers into China, heralds alien invasion

http://www.theregister.co.uk/2010/10/01/stuxnet_china_analysis/

 

The Jeruzalem Post: Stuxnet may have destroyed 1,000 centrifuges at Natanz

http://www.jpost.com/Defense/Article.aspx?id=200843

 

HVG: Amerikai segítséggel fejleszthette Izrael az iráni atomerőművet támadó vírust

http://hvg.hu/Tudomany/20110121_stuxnet_iran_amerika_izrael

 

Hatásmechanizmus:

When there is more at risk than just information – Langner

http://www.langner.com/en/blog/

 

HUP: Trójai terjed az új Windows sebezhetőségen keresztül

http://hup.hu/cikkek/20100719/trojai_terjed_az_uj_windows_sebezhetosegen_keresztul

 

Microsoft Malware Protection Center: The Stuxnet Sting

http://blogs.technet.com/b/mmpc/archive/2010/07/16/the-stuxnet-sting.aspx

http://blogs.technet.com/b/mmpc/archive/2008/11/25/more-ms08-067-exploits.aspx

MS10-061: Printer Spooler Vulnerability

http://blogs.technet.com/b/srd/archive/2010/09/14/ms10-061-printer-spooler-vulnerability.aspx

 

F-secure: Stuxnet Questions and Answers

http://www.f-secure.com/weblog/archives/00002040.html

 

Wikipedia / Nulladik napi támadás

http://hu.wikipedia.org/wiki/Nulladik_napi_t%C3%A1mad%C3%A1s

 

Wikipedia / Exploit

http://hu.wikipedia.org/wiki/Exploit

 

Hogyan védekezzünk:

Siemens forum / Joel Langill

http://www.automation.siemens.com/WW/forum/guests/PostShow.aspx?PageIndex=1&PostID=225690

 

Wikipedia / legkisebb jogosultság elve

http://hu.wikipedia.org/wiki/Legkisebb_jogosults%C3%A1g_elve

 

Wikipedia / csoportházirend-objektumok

http://hu.wikipedia.org/wiki/Csoporth%C3%A1zirend

 

A cikk első részét itt lehet elérni.

A cikk az ob121.com oldalon.

A bejegyzés trackback címe:

http://ob121.blog.hu/api/trackback/id/tr842661019

Kommentek:

A hozzászólások a vonatkozó jogszabályok  értelmében felhasználói tartalomnak minősülnek, értük a szolgáltatás technikai  üzemeltetője semmilyen felelősséget nem vállal, azokat nem ellenőrzi. Kifogás esetén forduljon a blog szerkesztőjéhez. Részletek a  Felhasználási feltételekben.