2018. december 13., csütörtök

A Stuxnet és hatásai









A Stuxnet és hatásai



ne legyenek illúzióink, a válasz-csapás kódja már íródik

Myrtus Projekt

A Stuxnet-et spekulációk és legendák lengik körül, a valós hatásmechanizmusát csak kevesen ismerik, így az érdeklődő a magyar nyelvű internetes oldalakon jószerivel csak találgatásokkal és feltevésekkel találkozhat. A Google-be bepötyögve aStuxnet” keresőszót, nagyjából 3 millió találatot ad, a keresési feltételeket a magyar nyelvre szűkítve még mindig marad 30 ezer találat. A megjelent cikkek jobb esetben általánosan fogalmaznak a vírussal kapcsolatban, rosszabb esetben pedig pontatlan vagy hamis tényeket közölnek.
Ebben a cikkben a Stuxnet pontos hatásmechanizmusát szeretném feltárni, de még mielőtt elmerülnénk a laikusok számára értelmetlen részletekben, megkísérelem összefoglalni a vírus történetét – itt viszont sajnos én is csak találgatásokra tudok hagyatkozni. Aki ezen a területen több információval rendelkezik, kérem, saját érdekében hallgasson ezekről!
Ennek a dokumentumnak a megírásához sok, sokszor csak találgatásokba menő forrást használtam fel. Megpróbálok ezek között súlyozni, és saját, 15 éves ipari programozói rutinomra támaszkodva egy objektivitásra törekvő, de alapvetően szubjektív írást összelapátolni.
Több cikkben is kifejtik, hogy a Stuxnet nem vírus, hanem a pontos metodika szerint féreg (worm) és/vagy rejtőzködő (rootkit). Ennek ellenére a Stuxnet, kártevő és vírus szavakat rokon értelmű szavakként kezelem a cikkben, így kevesebb lesz talán a szóismétlés.

A háttér (elsősorban laikusoknak)

Az ipari rendszerek irányítását világszerte speciális cél-számítógépekkel, az un. PLC-kel (Programable Logic controller, németül: SPS - Speicherprogrammierbare Steuerung) végzik. Ezeken a kontrollereken speciális nyelvű program fut. A program működésébe természetesen időnként be kell avatkozni, illetve azt sem árt tudni, hogy éppen mit művel a rendszerünk, erre a célra az un. HMI-k (human-machine interface) szolgálnak.
Ha összetettebb feladatokat is szeretnénk a terminálokon végeztetni, mint mondjuk adat-archiválás, osztott irányítás, idődiagram-kezelés, akkor SCADA-t (Supervisory Control And Data Acquisition) vetünk be erre a célra. A SCADA-k olyan program-rendszerek, melyek többnyire valamely Windows operációs rendszeren futnak, és szerveren vagy szervereken keresztül csatlakoznak a PLC-khez. A lenti képen egy ilyen rendszer látható – ezt nem a cikk céljából rajzoltam, és ez látszik is rajta. A vállalatirányítási szisztémák természetesen több rendszert is tartalmaznak, de most csak a SCADA-t és a PLC-t vegyük a nagyítónk alá, a későbbiekben ugyanis róluk fog szólni ez a történet.
A Stuxnet terjedése
Sokszor, amikor az ilyen rendszerekről beszélgetünk a megbízókkal, felmerül a kérdés, hogy a Windows alkalmazása mennyire teszi sérülékennyé ezeket a technológiákat, és bizalomgerjesztő választ sajnos nem tudok adni: „Nagyon”. A Windowsra számolatlanul fejlesztik a vírusokat elvetemült krekkerek, és a vírusirtó technológia mindig csak lekövetni tudja ezeket a károkozókat.
Krekker: (angolul cracker) Míg a hackerek a rendszerbehatolásaikat és –töréseiket a későbbiekben publikálják és nem élnek vissza ezekkel az információkkal (etikus hacking), addig a krekkerek a sötét oldal képviselői. A töréseket, vírusokat, backdoorokat adatszerzésre, zsarolásra és károkozásra használják fel. A krekking egyik minősített esete a Stuxnet léte.
- Akkor még mindig ott van a SCADA, mely védettebb lehet a vírusoktól – érkezhet a következő, reménykereső kérdés, de a válasz ismét elkeserítő: Nemhogy védettebbek lennének ezek, mint a többi program, hanem éppen ellenkezőleg. A gyári jelszók szinte minden esetben alkalmazhatók belépéshez, több a SCADA-kra épülő termék ezeknek az „alap” jelszavaknak a megváltoztatását sem engedi meg (Nem akarok konkrét nevekkel tippeket adni) – bár a szakmában mindenki tudja, mire gondolok.
A SCADA-kból ráadásul nincs túl nagy választék a piacon, a nagyok (Inellution Fix, Intouch, WinCC) a piac nagy részét lefedik. Ezek gyenge pontjainak a feltárása – meg merem kockáztatni – nem nagy kaland, szakmabeliek bármelyik hibáiból kisebb litániát dobnak össze a munka utáni sörözéskor.
Amennyiben a SCADA jelszavakkal rendelkezik a kártevő, onnan bármely adatokat ki tud olvasni, és internetes kapcsolat esetén ezeket továbbítani tudja megírója felé, aki kielemezheti a technológia működését – és ez még csak a kisebbik baj. Nagyobb gond az – mint a Stuxnet története is rávilágít erre – a behatoló a SCADA és azon keresztül a PLC-k működését is befolyásolni tudja, illetve a PLC-k felől érkező hamis információkat tud megjeleníteni a kijelzőkön, megtévesztve ezzel a kezelőszemélyzetet.
PLC-k a vírusok számára közvetlenül nem érhetők el, mert nem fut rajtuk operációs rendszer, vagy olyan program, ami fertőzhető lenne, csak egy lefordított célprogram, ami ciklikusan hajtódik végre.
A programokat egy ún. programozói állomáson – ez egy Windows-os PC vagy laptop, Simatic fejlesztői környezettel – lehet fejleszteni, és innen lehet letölteni a PLC-kre. Ez az egész folyamat Achilles-sarka, ugyanis egy fertőzött géppel a PLCprogramokat felül lehet írni. A PLC-ken a Stuxnet a valós adatok helyett hamisított információkat továbbított a SCADA felé, miközben apránként tönkretette a PLC-k által felügyelt urániumdúsító centrifugákat és ez alatt az idő alatt a termelést is „szabotálta”.

Sztori

A kártevő 2010. júniusában „bukott le” a fehérorosz „VirusBlokAda” cég által Iránban, a Bushehr erőmű egyik gépén, és azóta bebizonyosodott, hogy több, mint 100.000 számítógépet fertőzött meg, a Simatic WinCC SCADA-kat keresve. Csak Iránban 45.000 felügyeleti számítógép és szerver tartalmazta a vírust (Info: Homeland Security Newswire, 2011. február).
A felfedezés óta bebizonyosodott, hogy a Stuxnet vírus az erőműre közvetlen fenyegetést nem jelentett, mert annak az urániumdúsító berendezések voltak a célpontjai. Közvetett értelemben azonban az a tény mindenképpen fenyegető, hogy egy vírus bejutott a létesítménybe.
A Stuxnet-et feltételezések szerint az USA-ban vagy/és Izraelben fejlesztették ki (több találgatásban is felmerült az izraeli hadsereg high tech különítményének, a Unit8200-nak a neve). Erre utal (de akár figyelem-elterelés is lehet), hogy a kód az alábbi hivatkozást tartalmazza: 1979 május 9; ezen a napon végezték ki a prominens zsidó üzletembert, Habib Elghanian-t Iránban, Izraelnek való kémkedés vádjával.
Több feltevés szerint az izraeli Dimonában egy tesztkörnyezetet építettek ki Simatic rendszerrel és IR-1 centrifugákkal, és itt fejlesztették ki a Stuxnet támadó blokkját. A munkához az amerikai Idaho National Laboratory (INL) szakemberei adtak tanácsokat (vagy akár részt is vettek a fejlesztésben).
Az iráni urándúsító centrifugák kifejeszése a pakisztáni Abdul Qadeer Khan nevéhez köthető, aki a holland Urenco-nál is dolgozott, majd a cég által kifejlesztett berendezéseket „másodhasznosította” a pakisztáni atomfegyver-programban, és az általa „honosított” berendezéseket Pak-1 vagy P-1 néven fejlesztették és terjesztették a Közel-Keleten, többek között Líbiában és Iránban.

Az uránimcentrifuga működési elveTermészetes környezetben az uránérc 99,3 % 238 U ból és 0,7 % 235 U uránium izotópokból áll össze. Mindenféle maghasadásos nukleáris tevékenységhez természetesen a ritkább 235-ösre van szükség, ennek kiválasztására több technológia is ismert, például a hőmérséklet diffúzió, a gázdiffúzió, légáramoltatásos leválasztás, elektromágneses-, lézeres- vagy plazma-szeparáció, Zippe- vagy a gáz-centrifugázás.
Gázcentrifugázás: két uránizotóp tömege alig (mindössze három neutrontömegnyivel) különbözik egymástól. Az szobahőmérsékleten szilárd uránt melegítve és adalékolva gáz halmazállapotú vegyületté (urán-hexafluoriddá, UF6) alakítják át, s a két izotópot többnyire gázcentrifugákkal választják szét. Az izotópokból álló keverékből a nehezebb izotóp a centrifuga palástja mentén, a valamelyest könnyebb pedig a tengelyhez közelebb halmozódik fel. Így a palástról elvezetett keverék 238-as izotópban dúsabb, míg a tengely közeléből kiáramló gáz 235-ösban gazdagabb. A dúsítást – az elérendő koncentrációtól függően – több, egymás mellett elhelyezett, sorba kötött centrifugával végzik. Egy-egy urándúsító üzem akár több ezer centrifugából állhat. A berendezések kerületi sebessége a 600 m/s-os sebességet is elérheti.

Az urándúsító centrifugákat is hajtó motorok nagyfrekvenciás átalakítóinak a technikai adatait azoknak a gyártóitól, a finn Vacon-tól és az iráni Fararo Paya-tól szerezték meg. Ez az „adatszerzés” még a szakértőket is meglepte, hiszen a Fararo Paya-t olyan szinten próbálták elrejteni az iráni hatóságok, hogy az IAEA (International Atomic Energy Agency: Nemzetközi Atomenergia-ügynökség) se tudott róla.
A fejlesztésbe rendkívül sok energiát és időt öltek, erre utal a kártevő komplexitása és fejlett hatásmechanizmusa, így szinte kizárt a magányos krekker teóriája, aki otthon, hobbiból fejlesztette volna a kódot. Itt egy komoly szakértőkből álló team-nek kellett állnia a háttérben, a fertőzés jól irányzott volta, és az, hogy a kártevő elérte a célját, profi kivitelezőket és bőséges finanszírozást feltételez. A fejlesztés a "Myrtus" projekt keretein belül történt, erre utal a beforgatott kód path-je:
\myrtus\src\objfre_w2k_x86\i386\guava.pdb.
"Myrtus" lehet egy hivatkozás a bibliai Eszterre, aki megmentette a perzsáktól az ókori zsidó államot, de lehet akár a „My RTU”s (remote terminal unit – távoli elérésű terminál) is.
A kódban található egy elgépelt hivatkozás is (ez akár a fejlesztőkre is utalhat, mert egy anyanyelvi angol nem vét ilyen hibát): A hivatkozás eredetije a DEADFOOT, ez a pilóták szlengjében a hajtómű-meghibásodást jelenti, és ezt sikerült DEADF007-nek gépelni a kódban (a kódoló a két „o” betüt 0-nak, a „T”-t pedig 7-esnek nézte).
James Bond után szabadon, „rázva, nem keverve”. A fejlesztéshez kiindulásként valószínűleg, egy korábbi kártevő, a Conficker kódját használták. A féreg tevékenységéről egy maláj és egy dán szerverre folyamatosan jelentéseket küldött (www.mypremierfutbol.comwww.todaysfutbom.com), majd a nantanz-i támadás után ezeket a szervereket lekapcsolták üzemeltetőik.

Eredmény

2010. november 16.-án Irán leállította az urándúsítóit, miután a centrifugák több, mint 20%-a megsemmisült a Stuxnet tevékenysége nyomán, azaz a kártevő elérte a célját.
Az iráni urándusító program nantanz-i telepe
Az iráni urándusító program nantanz-i telepe
A kép forrása: Assets.knowledge.allianz.com
Nantanz városa körülbelül 225 kilométerre, délkeletre található Teherántól, oázisai híresek az itt termelt körtéről, mellyel egész Iránt innen látják el. Nem túl pc poén, de ide kívánkozik: lehet, hogy hamarosan világítani is fognak, ugyanis itt található a legnagyobb urándúsító telep is.
A mindösszesen 100.000 m2 alapterületű csarnokokat légvédelmi okokból 8 méterrel a föld alá telepítették, majd a későbbiekben – az izraeli haditechnika fejlődésével szinkronban - még több földet hordtak rá.
2009-ben a berendezés 8000 centrifugájából 5000 működött, és egy újabb telep létesítésébe fogtak Qom közelében. A pakisztáni P-1-es centrifuga iráni változának a kódneve az IR-1, és ennek a továbbfejlesztett változatai rendre IR-2, IR-3,.. névre hallgatnak. Egy centrifugában viszonylag kis mértékű dúsítás érhető el, ezért ezeket úgynevezett kaszkádokba szervezik.
A kaszkádokban a dúsított HF6 egyik irányban való áramoltatásával szemben a csökkentett 235 U koncentrációjú HF6 a másik irányban mozog. A kaszkádok párhozamos kötésekkel is rendelkeznek. Feltételezések szerint a centrifugákat 164 elemű, 15 fokozatú kaszkádokba szervezték.

A kártevő – persze megint csak feltételezések szerint – az igazi pusztítást a natanz-i urándúsító létesítményben fejtette ki, itt jó eséllyel kb. ezer IR-1 típusú urándúsító centrifugát égetett le. Ezeknek a berendezéseknek a hajtómotorja 1007 cps-nél (cycles per second, másodpercenkénti fordulatszám) is már tönkremegy, a Stuxnet viszont rövidebb fázisokra, észrevétlenül 1064 cps-es tempót diktált nekik, széthajtva őket.
Szintén Iránból származó – így meg nem erősített hírek szerint – a natanz-i urándúsító létesítmény igazgatóját eltávolították, több – először csak felfüggesztett – tudóst kémkedéssel vádoltak meg, illetve néhányan eltűntek közülük.

főnöki szemle
Főnöki szemle a nantanzi urániumdúsítóban - a kép Mahmoud Ahmadinejad 2008-as látogatásakor készült. Háttérben az ominózus centrifugák, fotó: Getty Images.

Habár az iráni hatóságok állítják, hogy a fertőzést megszüntették, minden szakértő tudja, hogy mindaddig, míg az alkalmazott technológiát nem cserélik le, az újabb – a Stuxnethez hasonló felépítésű, de eltérő működésű behatoló fertőzése csak idő kérdése. A Bushehr atomerőmű kapcsán emlegetett Csernobil-analógia bár nem következhet be (alapvetően a csernobili berendezés és az ott történtek nem vethetők össze az iráni erőművel), de – és ezt a Stuxnet fényesen bizonyította – ezek a programok iszonyú károkat okozhatnak.

Hatásmechanizmus

Ez a legkomplexebb malware, melyet az utóbbi öt vagy több évben láttam” mondta Nicolas Falliere, a Symantec kódfejtője. „Ez az első ismert eset, amikor egy kártevő nem a hitelkártya információkat és nem a személyes adatokat akarja megszerezni, hanem technológiai rendszert támad. Ez egy egyedülálló és nem túl felvillanyozó tény.”
A kód visszafejtése meglehetősen sok időt vett igénybe, mivel komplexitása mellett a mérete – fél Mbyte – is meglehetősen nagy.
A teljes hatásmechanizmust két alfejezetre bontom: A terjedés” fejezetben a károkozó terjedését kívánom ismertetni, mely még nevezhető „hagyományos” metódusnak, és a legtöbb fertőzött gépen a Stuxnet tevékenysége ezzel le is zárul (amennyiben nem találja meg a WinCC-t ott).
A „pusztítás” fejezetben a PLC-ken kiváltott hatását írom le a vírusnak.

Terjedés

A vírus terjedését fejlesztői nem bízták a véletlenre, rögtön három, „nulladik napi támadás”-t (Zero-Day Vulnerability) is indít a rendszer ellen.
Nulladik napi támadás (zero-day vagy zero-hour támadás) - Wikipedia: egy biztonsági fenyegetés, ami valamely számítógépes alkalmazás olyan sebezhetőségét használja ki, ami még nem került publikálásra, a szoftver fejlesztője nem tud róla, vagy nem érhető még el azt foltozó biztonsági javítás. Zero-day exploitnak nevezik azt a tényleges kódot, amit a támadók használnak a sérülékenység kiaknázására, mielőtt a szoftver fejlesztője tudna arról.
Bővebben a lásd a Wikipedia szócikkét.
Stuxnet 3 Zero-Day Vulnerability

A” verzió: LNK Exploit

Az „autorun” eszközök helyett a malware egy, a Windows parancsikonokat feldolgozó kódjában levő sebezhetőséget használ ki.
Amint felhasználó a fertőzött USB meghajtót megnyitja az Windows Explorer-ben vagy egyéb más fájlkezelőben, amely képesikonok megjelenítésére (például Windows Explorer), a rosszindulatú kód automatikusan végrehajtódik minden további felhasználói interakció nélkül. Mivel a StuxNet leginkább az USB-ken terjed, ezért klasszikus besorolás szerint ez a malware egy „féreg” (worm).

Exploit  Wikipedia: (ang.: kihasználás, kiaknázás) informatikai biztonsági fogalom: olyan forráskódban terjesztett vagy bináris program, adathalmaz vagy parancssorozat, amely alkalmas egy szoftver vagy hardver biztonsági résének, illetve hibájának kihasználására, így érve el a rendszer tervezője által nem várt viselkedést. Ez alatt a nem várt viselkedés gyakran a rendszergazdai jogok megszerzését, jogosultságnövelést (privilege escalation) vagy szolgáltatásmegtagadást (denial of service-t) értünk.
Bővebben a lásd a Wikipedia szócikkét.

B” verzió: PRC Exploit

Az exploit véletlenszerűen megnyit egy portot 1024 és 10000 között, és itt web szerverként viselkedik. Véletlenszerűen próbál gépeket fertőzni a hálózaton, és ha ez összejön, HTTP-n keresztül másolja magát a nyitott porton. Másolás közben előszeretettel használja a .JPG kiterjesztést, majd véletlenszerű névvel .dll-ként menti magát a gépen.

C” verzió: Spool Server Exploit

Xp-s, osztott nyomtató szervereken minden további nélkül tud terjedni ez az exploit, a többi Windows termékeken csak bizonyos körülmények között. Ezt a rést elsősorban a Stuxnet használja ki.
Induláskor számba veszi az összes hálózati nyomtató szervert, és megkísérel „Guest-ként ezekhez csatlakozni. Amennyiben ez sikerül, másolja és futtatja magát.

Futtatás

A Stuxnet először egy backdoor funkciót aktivál (Worm:Win32/Stuxnet.A) a sérült rendszeren, majd két - rootkit funkciókkal ellátott - drivert telepít fel (mrxcls.sysmrxnet.sys).
A driver-ek a Realtek Semiconductor Corp érvényes aláírásával rendelkeztek kezdetekben. Ez arra utalhat, hogy a malware szerzője valahogyan hozzáfért a Realtek privát kulcsához. A hírek szerint a Verisign azonban a a felfedezést követő hétvégén visszavonta a Realtek érintett certificate-jét.
A két driver:
  • WinNT/Stuxnet.A trójai (trojan): elrejti a .lnk fájlokat
  • WinNT/Stuxnet.B trójai (trojan): titosított adatsorokat tölt a memóriába, melyek által kiváltott funkciókat a következő al-fejezetben („pusztítás”) ismertetek.
A Stuxnet által fertőzött országok megoszlása
A kép forrása: Microsoft Malware Protection Center
A Stuxnet fertőzési jellemzői
A kép forrása: Microsoft Malware Protection Center
A vírus terjedéséhez egy adalék, hogy – mint a felső ábrán az jól látható – igen célirányosan indult világgá. Bár - számomra – Indonézia kissé kakukktojás, de a másik két listavezető atomprogramjai igencsak ellenérzéseket indukálnak amerikai és izraeli kormánykörökben is.

Pusztítás

s7otbxdx.dll fájl a „SIMATIC Device Operating System” egyik eleme, ezt írja felül a Win32/Stuxnet.A. A DLL a fertőzés után három 64-bites titkosított fájlt fog tartalmazni, melyek adott kiváltó események hatására kikódolásra és letöltésre kerülnek.
A Simatic S7 PLC-kről egy rövidebb összefoglalást itt talál.
A kódok közül kettőt az S7-315-ösöknek és egyet az S7-417-eseknek szántak a fejlesztők. A 300-as sorozatú 315-ösöket kisebb berendezések irányításához szokás használni, míg a 400-as sorozatú 417-t (mondjuk 417-4H) jellemzően már jóval komolyabb (H”-s, F”-es vagy „FH”-s - redundáns és/vagy hibatűrő) rendszerekhez szokás használni. A két 315-és kód szerkezetében hasonló és csak néhány kisebb eltérés található bennük.
Mindhárom kód alátámasztja, hogy írói rendkívül célirányosan fejlesztették ezeket, a célhardver felépítésével és működésével tisztában voltak – a támadást sebészi pontossággal tervezték és hajtatták végre a vírussal.

DeadF007

A 315-ös program hozzávetőleg 3000 sor hosszú Step7 AWL kódot és négy kisebb adatblokkot (DB 888...891) tartalmaz. A programkód két FC-t (FC 1865 és FC 1874) generál és ezeket az OB1-be és OB35-be beágyazza.
A kód öt szakaszt futtat, ebből a leghosszabb a károkozások közötti kivárás, ez 13-90 nap lehet. A legrövidebb a „pusztítási” szakasz, amikor a korábban már megemlített Deadfoot (vagy Dead007) feltételek összejönnek (ezeket az alkalmazott módból, a felügyelet jellegéből és a kivárási időből rakja össze a vírus).
A Deadfoot feltételek fennállása mellett – akár 50 perc hosszan is – a PLC eredeti funkcionalitását a vírus egy BEC-cel (conditional block end: feltételes blokk-lezárás) felfüggeszti, és a centrifugák sebességét először 1410 Hz-re viszi fel, majd 2 Hz-re csökkenti.
Ezzel egyrészt a rotort teszi idővel tönkre, illetve az addig szeparálódott HF6-ot keveri össze. A program a rejtőzködésre játszik, a ritkán és véletlenszerűen végrehajtott szabotázsakció hosszú ideig nem észlelhető, főleg, hogy a SCADA rendszer és az azt felügyelő operátor ebből gyakorlatilag semmit nem „lát”. A támadott aktuátorra a kimenő paramétereket a program a fixen rögzített DB 888-ból olvassa.
Fontos része a kódnak – mely a fejlesztők ismereteiről sokat elárul – a DP_RECV (Standard Library/ FC2) funkció működésének módosítása. Normál körülmények között ez a funkció – DP Slave oldalon – átveszi a DP-Master által továbbított kimeneti állapotokat a megadott DP területen.
A 417-esre szánt program kissé összetettebb a maga 12.000 soros AWL-jével, és tíz adatblokkjával. Két adatblokk (DB8062,DB8063) statikusként kerül letöltésre, egy dinamikusként (DB8061), a többieket pedig a kód generálja ki (DB8064..DB8070). Kifejezetten érdekes ezek közül a statikus DB8063, melynek mérete 26,790 byte, és egy 16 kbyte-os, 164 * 6-os tömböt tartalmaz. A kigenerált kód az OB1-ből meghívásra kerülő FC-kből áll.
Szakértők eleinte úgy vélték, hogy ez a blokk a Bushehr elleni támadást hajtotta volna végre, de Ralph Langner vírusbiztonsági szakértő szerint ennek a 315-ös PLC-k fölötti S7-400-as „megbolondítása” volt a célja.
Míg az S7-300-asok egyértelműen a rotorokat és az egyedi centrifugák vezénylését végezték, szerinte a 400-as a technológiát és annak szelepeit felügyelte. A fent említett tömb jó eséllyel a szelepek funkcióinak a felülírását végezte, erre utal annak 164 * 6 –os tagolása. Ezt a DB-t (DB8063) például a – szintén generált – FC6068 hívta egy 164-es ciklusban, melyet viszont az FC6070hívott fel hatszor.
Valószínűleg a nantanzi centrifugák 6 darab 164 elemű kaszkádba voltak rendezve, így a vírus ennek a 984 centrifugának a fokozatos tönkretételét valósította meg.

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ómamost 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ó.

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

S7-315 2 DP RUN / RUN-P módAz 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 RUNba.
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áltak, 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 PCS7Comos, ..) 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.
OB35 - OB38 csere
Meglátásom szerint vissza kell térni az egyedi kódolásokhoz, a hamis biztonságot nyújtó standard kódolási megoldásokhoz, í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

rendszer-redundancia sémájaRedundancia 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óengedélyező jel a vonaton
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. 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. 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:
black-box PLC séma

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.
Ennek leírása:
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. Válassza le a gépet a hálózatról
  2. 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 EssentialsForefront Client SecurityLive OneCareForefront 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. Alkalmazzon csoportházirendet, illetve acsoportházirend-objektumokat! (Group Policy ObjectGPO) lásd a Wikipedián:http://hu.wikipedia.org/wiki/Csoporth%C3%A1zirend

Hozzászólás

Amennyiben a leírtakhoz hozzá szeretne szólni, kérem, ezt az ob121.blog.hu oldalon tegye meg.
Itt a cikket terjedelmi okok miatt két részre tagoltam: első részmásodik rész.

Források

Bevezetés:

The Christian Science Monitor

Sztori:

Cserháti András: A Stuxnet vírus és az iráni atomprogram
Abel Danger: ‘DEADFOO7’computer virus ('deadfoot') - clandestine nuclear-weapons procurement - Guild of Contract Hits - D2 Banking’s digital-data archives
Homeland Security Newswire: Stuxnet may turn Bushehr into a new Chernobyl
Wired: Blockbuster Worm Aimed for Infrastructure, But No Proof Iran Nukes Were Target
The Register: Stuxnet worm slithers into China, heralds alien invasion
The Jeruzalem Post: Stuxnet may have destroyed 1,000 centrifuges at Natanz
HVG: Amerikai segítséggel fejleszthette Izrael az iráni atomerőművet támadó vírust

Hatásmechanizmus:

When there is more at risk than just information – Langner
HUP: Trójai terjed az új Windows sebezhetőségen keresztül
Microsoft Malware Protection Center: The Stuxnet Sting
MS10-061: Printer Spooler Vulnerability
F-secure: Stuxnet Questions and Answers
Wikipedia / Nulladik napi támadás
Wikipedia / Exploit

Hogyan védekezzünk:

Siemens forum / Joel Langill
Wikipedia / legkisebb jogosultság elve
Wikipedia / csoportházirend-objektumok


2011.02.14. 14:40

Myrtus Projekt


A Stuxnet-et spekulációk és legendák lengik körül, a valós hatásmechanizmusát csak kevesen ismerik, így az érdeklődő a magyar nyelvű internetes oldalakon jószerivel csak találgatásokkal és feltevésekkel találkozhat. A Google-be bepötyögve a „Stuxnet” keresőszót, nagyjából 3 millió találatot ad, a keresési feltételeket a magyar nyelvre szűkítve még mindig marad 30 ezer találat. A megjelent cikkek jobb esetben általánosan fogalmaznak a vírussal kapcsolatban, rosszabb esetben pedig pontatlan vagy hamis tényeket közölnek.
 Ebben a cikkben a Stuxnet pontos hatásmechanizmusát szeretném feltárni, de még mielőtt elmerülnénk a laikusok számára értelmetlen részletekben, megkísérelem összefoglalni a vírus történetét – itt viszont sajnos én is csak találgatásokra tudok hagyatkozni. Aki ezen a területen több információval rendelkezik, kérem, saját érdekében hallgasson ezekről!
 Ennek a dokumentumnak a megírásához sok, sokszor csak találgatásokba menő forrást használtam fel. Megpróbálok ezek között súlyozni, és saját, 15 éves ipari programozói rutinomra támaszkodva egy objektivitásra törekvő, de alapvetően szubjektív írást összelapátolni.
 Több cikkben is kifejtik, hogy a Stuxnet nem vírus, hanem a pontos metodika szerint féreg (worm) és/vagy rejtőzködő (rootkit). Ennek ellenére a Stuxnet, kártevő és vírus szavakat rokon értelmű szavakként kezelem a cikkben, így kevesebb lesz talán a szóismétlés.

A háttér (elsősorban laikusoknak)


Az ipari rendszerek irányítását világszerte speciális cél-számítógépekkel, az un. PLC-kel (Programable Logic controller, németül: SPS - Speicherprogrammierbare Steuerung) végzik. Ezeken a kontrollereken speciális nyelvű program fut. A program működésébe természetesen időnként be kell avatkozni, illetve azt sem árt tudni, hogy éppen mit művel a rendszerünk, erre a célra az un. HMI-k (human-machine interface) szolgálnak. Ha összetettebb feladatokat is szeretnénk a terminálokon végeztetni, mint mondjuk adat-archiválás, osztott irányítás, idődiagram-kezelés, akkor SCADA-t (Supervisory Control And Data Acquisition) vetünk be erre a célra. A SCADA-k olyan program-rendszerek, melyek többnyire valamely Windows operációs rendszeren futnak, és szerveren vagy szervereken keresztül csatlakoznak a PLC-khez. A lenti képen egy ilyen rendszer látható – ezt nem a cikk céljából rajzoltam, és ez látszik is rajta. A vállalatirányítási szisztémák természetesen több rendszert is tartalmaznak, de most csak a SCADA-t és a PLC-t vegyük a nagyítónk alá, a későbbiekben ugyanis róluk fog szólni ez a történet.
 
Sokszor, amikor az ilyen rendszerekről beszélgetünk a megbízókkal, felmerül a kérdés, hogy a Windows alkalmazása mennyire teszi sérülékennyé ezeket a technológiákat, és bizalomgerjesztő választ sajnos nem tudok adni: „Nagyon”. A Windowsra számolatlanul fejlesztik a vírusokat elvetemült krekkerek, és a vírusirtó technológia mindig csak lekövetni tudja ezeket a károkozókat. 
Krekker: (angolul cracker) Míg a hackerek a rendszerbehatolásaikat és –töréseiket a későbbiekben publikálják és nem élnek vissza ezekkel az információkkal (etikus hacking), addig a krekkerek a sötét oldal képviselői. A töréseket, vírusokat, backdoor-okat adatszerzésre, zsarolásra és károkozásra használják fel. A krekking egyik minősített esete a Stuxnet léte.
- Akkor még mindig ott van a SCADA, mely védettebb lehet a vírusoktól – érkezhet a következő, reménykereső kérdés, de a válasz ismét elkeserítő: Nemhogy védettebbek lennének ezek, mint a többi program, hanem éppen ellenkezőleg. A gyári jelszók szinte minden esetben alkalmazhatók belépéshez, több a SCADA-kra épülő termék ezeknek az „alap” jelszavaknak a megváltoztatását sem engedi meg (Nem akarok konkrét nevekkel tippeket adni) – bár a szakmában mindenki tudja, mire gondolok.
 A SCADA-kból ráadásul nincs túl nagy választék a piacon, a nagyok (Inellution Fix, Intouch, WinCC) a piac nagy részét lefedik. Ezek gyenge pontjainak a feltárása – meg merem kockáztatni – nem nagy kaland, szakmabeliek bármelyik hibáiból kisebb litániát dobnak össze a munka utáni sörözéskor. 
 Amennyiben a SCADA jelszavakkal rendelkezik a kártevő, onnan bármely adatokat ki tud olvasni, és internetes kapcsolat esetén ezeket továbbítani tudja megírója felé, aki kielemezheti a technológia működését – és ez még csak a kisebbik baj. Nagyobb gond az – mint a Stuxnet története is rávilágít erre – a behatoló a SCADA és azon keresztül a PLC-k működését is befolyásolni tudja, illetve a PLC-k felől érkező hamis információkat tud megjeleníteni a kijelzőkön, megtévesztve ezzel a kezelőszemélyzetet.
 A PLC-k a vírusok számára közvetlenül nem érhetők el, mert nem fut rajtuk operációs rendszer, vagy olyan program, ami fertőzhető lenne, csak egy lefordított célprogram, ami ciklikusan hajtódik végre.
 A programokat egy ún. programozói állomáson – ez egy Windows-os PC vagy laptop, Simatic fejlesztői környezettel – lehet fejleszteni, és innen lehet letölteni a PLC-kre. Ez az egész folyamat Achilles-sarka, ugyanis egy fertőzött géppel a PLC programokat felül lehet írni.
 A PLC-ken a Stuxnet a valós adatok helyett hamisított információkat továbbított a SCADA felé, miközben apránként tönkretette a PLC-k által felügyelt urániumdúsító centrifugákat és ez alatt az idő alatt a termelést is „szabotálta”.

Sztori


A kártevő 2010. júniusában „bukott le” a fehérorosz  „VirusBlokAda” cég által Iránban, a Bushehr erőmű egyik gépén, és azóta bebizonyosodott, hogy több, mint 100.000 számítógépet fertőzött meg, a Simatic WinCC SCADA-kat keresve. Csak Iránban 45.000 felügyeleti számítógép és szerver tartalmazta a vírust (Info: Homeland Security Newswire, 2011. február).
A felfedezés óta bebizonyosodott, hogy a Stuxnet vírus az erőműre közvetlen fenyegetést nem jelentett, mert annak az urániumdúsító berendezések voltak a célpontjai. Közvetett értelemben azonban az a tény mindenképpen fenyegető, hogy egy vírus bejutott a létesítménybe.
 A Stuxnet-et feltételezések szerint az USA-ban vagy/és Izraelben fejlesztették ki (több találgatásban is felmerült az izraeli hadsereg high tech különítményének, a Unit8200-nak a neve). Erre utal (de akár figyelem-elterelés is lehet), hogy a kód az alábbi hivatkozást tartalmazza: 1979 május 9; ezen a napon végezték ki a prominens zsidó üzletembert, Habib Elghanian-t Iránban, Izraelnek való kémkedés vádjával.
 Több feltevés szerint az izraeli Dimonában egy tesztkörnyezetet építettek ki Simatic rendszerrel és IR-1 centrifugákkal, és itt fejlesztették ki a Stuxnet támadó blokkját. A munkához az amerikai Idaho National Laboratory (INL) szakemberei adtak tanácsokat (vagy akár részt is vettek a fejlesztésben).
Az iráni urándúsító centrifugák kifejeszése a pakisztáni Abdul Qadeer Khan nevéhez köthető, aki a holland Urenco-nál is dolgozott, majd a cég által kifejlesztett berendezéseket “másodhasznosította” a pakisztáni atomfegyver-programban, és az általa “honosított” berendezéseket Pak-1 vagy P-1 néven fejlesztették és terjesztették a Közel-Keleten, többek között Líbiában és Iránban.

Természetes környezetben az uránérc 99,3 % 238U –ból és 0,7 % 235U uránium izotópokból áll össze. Mindenféle maghasadásos nukleáris tevékenységhez természetesen a ritkább 235-ösre van szükség, ennek kiválasztására több technológia is ismert, például a hőmérséklet diffúzió, a gázdiffúzió, légáramoltatásos leválasztás, elektromágneses-, lézeres- vagy plazma-szeparáció, Zippe- vagy a gáz-centrifugázás. 




Gázcentrifugázás: két uránizotóp tömege alig (mindössze három neutrontömegnyivel) különbözik egymástól. Az szobahőmérsékleten szilárd uránt melegítve és adalékolva gáz halmazállapotú vegyületté (urán-hexafluoriddá, UF6) alakítják át, s a két izotópot többnyire gázcentrifugákkal választják szét.Az izotópokból álló keverékből a nehezebb izotóp a centrifuga palástja mentén, a valamelyest könnyebb pedig a tengelyhez közelebb halmozódik fel. Így a palástról elvezetett keverék 238-as izotópban dúsabb, míg a tengely közeléből kiáramló gáz 235-ösban gazdagabb.
A dúsítást – az elérendő koncentrációtól függően – több, egymás mellett elhelyezett, sorba kötött centrifugával végzik. Egy-egy urándúsító üzem akár több ezer centrifugából állhat. A berendezések kerületi sebessége a 600 m/s-os sebességet is elérheti.
Az urándúsító centrifugákat is hajtó motorok nagyfrekvenciás átalakítóinak a technikai adatait azoknak a gyártóitól, a finn Vacon-tól és az iráni Fararo Paya-tól szerezték meg. Ez az “adatszerzés” még a szakértőket is meglepte, hiszen a Fararo Paya-t olyan szinten próbálták elrejteni az iráni hatóságok, hogy az IAEA (International Atomic Energy Agency: Nemzetközi Atomenergia-ügynökség) se tudott róla.
A fejlesztésbe rendkívül sok energiát és időt öltek, erre utal a kártevő komplexitása és fejlett hatásmechanizmusa, így szinte kizárt a magányos krekker teóriája, aki otthon, hobbiból fejlesztette volna a kódot. Itt egy komoly szakértőkből álló team-nek kellett állnia a háttérben, a fertőzés jól irányzott volta, és az, hogy a kártevő elérte a célját, profi kivitelezőket és bőséges finanszírozást feltételez.  
A fejlesztés a "Myrtus" projekt keretein belül történt, erre utal a beforgatott kód path-je: \myrtus\src\objfre_w2k_x86\i386\guava.pdb.
A "Myrtus" lehet egy hivatkozás a bibliai Eszterre, aki megmentette a perzsáktól az ókori zsidó államot, de lehet akár a “My RTU”s (remote terminal unit – távoli elérésű terminál) is.
A kódban található egy elgépelt hivatkozás is (ez akár a fejlesztőkre is utalhat, mert egy anyanyelvi angol nem vét ilyen hibát): A hivatkozás eredetije a DEADFOOT, ez a pilóták szlengjében a hajtómű-meghibásodást jelenti, és ezt sikerült DEAD007-nek gépelni a kódban (a kódoló a két „o” betüt 0-nak, a „T”-t pedig 7-esnek nézte). James Bond után szabadon, "rázva, nem keverve".
A fejlesztéshez kiindulásként valószínűleg, egy korábbi kártevő, a Conficker kódját használták. A féreg tevékenységéről egy maláj és egy dán szerverre folyamatosan jelentéseket küldött (www.mypremierfutbol.com, www.todaysfutbom.com), majd a nantanz-i támadás után ezeket a szervereket lekapcsolták üzemeltetőik.

Eredmény

2010. november 16.-án Irán leállította az urándúsítóit, miután a centrifugák több, mint 20%-a megsemmisült a Stuxnet tevékenysége nyomán, azaz a kártevő elérte az egyik célját.
A kártevő – persze megint csak feltételezések szerint – az igazi pusztítást a natanz-i urándúsító létesítményben fejtette ki, itt jó eséllyel kb. ezer IR-1 típusú urándúsító centrifugát égetett le. Ezeknek a berendezéseknek a hajtómotorja 1007 cps-nél (cycles per second, másodpercenkénti fordulatszám) is már tönkremegy, a Stuxnet viszont rövidebb fázisokra, észrevétlenül 1064 cps-es tempót diktált nekik, széthajtva őket.
Főnöki szemle a nantanzi urániumdúsítóban - a kép  Mahmoud Ahmadinejad 2008-as látogatásakor készült. Háttérben az ominózus centrifugák, fotó: Getty Images.
Nantanz városa körülbelül 225 kilométerre, délkeletre található Teherántól, oázisai híresek az itt termelt körtéről, mellyel egész Iránt innen látják el. Nem túl pc poén, de ide kívánkozik: lehet, hogy hamarosan világítani is fognak, ugyanis itt található a legnagyobb urándúsító telep is.
A mindösszesen 100.000 m alapterületű csarnokokat légvédelmi okokból 8 méterrel a föld alá telepítették, majd a későbbiekben – az izraeli haditechnika fejlődésével szinkronban - még több földet hordtak rá.
2009-ben a berendezés 8000 centrifugájából 5000 működött, és egy újabb telep létesítésébe fogtak Qom közelében. A pakisztáni P-1-es centrifuga iráni változának a kódneve az IR-1, és ennek a továbbfejlesztett változatai rendre IR-2, IR-3,.. névre hallgatnak.
Egy centrifugában viszonylag kis mértékű dúsítás érhető el, ezért ezeket úgynevezett kaszkádokba szervezik. A kaszkádokban a dúsított HF6 egyik irányban való áramoltatásával szemben a csökkentett 235U koncentrációjú HF6 a másik irányban mozog. A kaszkádok párhozamos kötésekkel is rendelkeznek. Feltételezések szerint a centrifugákat 164 elemű, 15 fokozatú kaszkádokba szervezték.
 Szintén Iránból származó – így meg nem erősített hírek szerint – a natanz-i urándúsító létesítmény igazgatóját eltávolították, több – először csak felfüggesztett – tudóst kémkedéssel vádoltak meg, illetve néhányan eltűntek közülük.
Habár az iráni hatóságok állítják, hogy a fertőzést megszüntették, minden szakértő tudja, hogy mindaddig, míg az alkalmazott technológiát nem cserélik le, az újabb – a Stuxnethez hasonló felépítésű, de eltérő működésű behatoló fertőzése csak idő kérdése. A Bushehr atomerőmű kapcsán emlegetett Csernobil-analógia bár nem következhet be (alapvetően a csernobili berendezés és az ott történtek nem vethetők össze az iráni erőművel), de – és ezt a Stuxnet fényesen bizonyította – ezek a  programok iszonyú károkat okozhatnak.  

Hatásmechanizmus


Ez a legkomplexebb malware, melyet az utóbbi öt vagy több évben láttam” mondta Nicolas Falliere, a Symantec kódfejtője. “Ez az első ismert eset, amikor egy kártevő nem a hitelkártya információkat és nem a személyes adatokat akarja megszerezni, hanem technológiai rendszert támad. Ez egy egyedülálló és nem túl felvillanyozó tény.”
 A kód visszafejtése meglehetősen sok időt vett igénybe, mivel komplexitása mellett a mérete – fél Mbyte – is meglehetősen nagy.
 A teljes hatásmechanizmust két alfejezetre bontom:
 A “terjedés” fejezetben a károkozó terjedését kívánom ismertetni, mely még nevezhető “hagyományos” metódusnak, és a legtöbb fertőzött gépen a Stuxnet tevékenysége ezzel le is zárul (amennyiben nem találja meg a WinCC-t ott).
A “pusztítás” fejezetben a PLC-ken kiváltott hatását írom le a vírusnak.

Terjedés


A vírus terjedését fejlesztői nem bízták a véletlenre, rögtön három, “nulladik napi támadás”-t (Zero-Day Vulnerability) is indít a rendszer ellen.
Nulladik napi támadás (zero-day vagy zero-hour támadás) - Wikipedia:  egy biztonsági fenyegetés, ami valamely számítógépes alkalmazás olyan sebezhetőségét használja ki, ami még nem került publikálásra, a szoftver fejlesztője nem tud róla, vagy nem érhető még el azt foltozó biztonsági javítás. Zero-day exploitnak nevezik azt a tényleges kódot, amit a támadók használnak a sérülékenység kiaknázására, mielőtt a szoftver fejlesztője tudna arról.
 Bővebben a lásd a Wikipedia szócikkét:http://hu.wikipedia.org/wiki/Nulladik_napi_t%C3%A1mad%C3%A1s
 

A” verzió: LNK Exploit

 Az „autorun” eszközök helyett a malware egy, a Windows parancsikonokat feldolgozó kódjában levő sebezhetőséget használ ki.
 Amint felhasználó a fertőzött USB meghajtót megnyitja az Windows Explorer-ben vagy egyéb más fájlkezelőben, amely képes ikonok megjelenítésére (például Windows Explorer), a rosszindulatú kód automatikusan végrehajtódik minden további felhasználói interakció nélkül. Mivel a StuxNet leginkább az USB-ken terjed, ezért klasszikus besorolás szerint ez a malware egy „féreg” (worm).
 A Microsoft biztonsági közleménye:
Exploit – Wikipedia: (ang.: kihasználás, kiaknázás) informatikai biztonsági fogalom: olyan forráskódban terjesztett vagy bináris program, adathalmaz vagy parancssorozat, amely alkalmas egy szoftver vagy hardver biztonsági résének, illetve hibájának kihasználására, így érve el a rendszer tervezője által nem várt viselkedést. Ez alatt a nem várt viselkedés gyakran a rendszergazdai jogok megszerzését, jogosultságnövelést (privilege escalation) vagy szolgáltatásmegtagadást (denial of service-t) értünk.
 Bővebben a lásd a Wikipedia szócikkét: http://hu.wikipedia.org/wiki/Exploit

B” verzió: PRC Exploit

Az exploit véletlenszerűen megnyit egy portot 1024 és 10000 között, és itt web szerverként viselkedik. Véletlenszerűen próbál gépeket fertőzni a hálózaton, és ha ez összejön, HTTP-n keresztül másolja magát a nyitott porton. Másolás közben előszeretettel használja a .JPG kiterjesztést, majd véletlenszerű névvel .dll-ként menti magát a gépen.

C” verzió: Spool Server Exploit

 Xp-s, osztott nyomtató szervereken minden további nélkül tud terjedni ez az exploit, a többi Windows termékeken csak bizonyos körülmények között.
 Ezt a rést elsősorban a Stuxnet használja ki. Induláskor számba veszi az összes hálózati nyomtató szervert, és megkísérel „Guest”-ként ezekhez csatlakozni. Amennyiben ez sikerül, másolja és futtatja magát.

Futtatás

A Stuxnet először egy backdoor funkciót aktivál (Worm:Win32/Stuxnet.A) a sérült rendszeren, majd két - rootkit funkciókkal ellátott - drivert telepít fel (mrxcls.sys, mrxnet.sys).
A driver-ek a Realtek Semiconductor Corp érvényes aláírásával rendelkeztek kezdetekben. Ez arra utalhat, hogy a malware szerzője valahogyan hozzáfért a Realtek privát kulcsához. A hírek szerint a Verisign azonban a a felfedezést követő hétvégén visszavonta a Realtek érintett certificate-jét.
 A két driver:
 - WinNT/Stuxnet.A trójai (trojan): elrejti a  .lnk fájlokat
 - WinNT/Stuxnet.B trójai (trojan): titosított adatsorokat tölt a memóriába, melyek által kiváltott funkciókat a következő al-fejezetben („pusztítás”) ismertetek.
 









 









A képek forrása: Microsoft Malware Protection Center
A vírus terjedéséhez egy adalék, hogy – mint a felső ábrán az jól látható – igen célirányosan indult világgá. Bár - számomra – Indonézia kissé kakukktojás, de a másik két listavezető atomprogramjai igencsak ellenérzéseket indukálnak amerikai és izraeli kormánykörökben is. 

Pusztítás 

A s7otbxdx.dll fájl a  „SIMATIC Device Operating System”  egyik eleme, ezt írja felül a Win32/Stuxnet.A. A DLL a fertőzés után három 64-bites titkosított fájlt fog tartalmazni, melyek adott kiváltó események hatására kikódolásra és letöltésre kerülnek.
 A Simatic S7 PLC-kről egy rövidebb összefoglalást itt talál.
 A kódok közül kettőt az S7-315-ösöknek és egyet az S7-417-eseknek szántak a fejlesztők. A 300-as sorozatú 315-ösöket kisebb berendezések irányításához szokás használni, míg a 400-as sorozatú 417-t (mondjuk 417-4H) jellemzően már jóval komolyabb (H”-s, F”-es vagy “FH”-s  - redundánsés/vagy hibatűrő) rendszerekhez szokás használni. A két 315-és kód szerkezetében hasonló és csak néhány kisebb eltérés található bennük.
 Mindhárom kód alátámasztja, hogy írói rendkívül célirányosan fejlesztették ezeket, a célhardver felépítésével és működésével tisztában voltak – a támadást sebészi pontossággal tervezték és hajtatták végre a vírussal.

DeadF007

 A 315-ös program hozzávetőleg 3000 sor hosszú Step7 AWL kódot és négy kisebb adatblokkot(DB 888...891) tartalmaz.  A programkód két FC-t (FC 1865 és FC 1874) generál és ezeket az OB1-be és OB35-be beágyazza.
A kód öt szakaszt futtat, ebből a leghosszabb a károkozások közötti kivárás, ez  13-90 bap lehet. A legrövidebb a „pusztítási” szakasz, amikor a korábban már megemlített Deadfoot (vagy DeadF007) feltételek összejönnek (ezeket az alkalmazott módból, a felügyelet jellegéből és a kivárási időből rakja össze a vírus).
A Deadfoot feltételek fennállása mellett – akár 50 perc hosszan is – a PLC eredeti funkcionalitását a vírus egy BEC-cel (conditional block end: feltételes blokk-lezárás) felfüggeszti, és a centrifugák sebességét először 1410 Hz-re viszi fel, majd 2 Hz-re csökkenti. Ezzel egyrészt a rotort teszi idővel tönkre, illetve az addig szeparálódott HF6-ot keveri össze. A program a rejtőzködésre játszik, a ritkán és véletlenszerűen végrehajtott szabotázsakció hosszú ideig nem észlelhető, főleg, hogy a SCADA rendszer ebből gyakorlatilag semmit nem észlel. A támadott aktuátorra a kimenő paramétereket a program a fixen rögzített DB 888-ból olvassa.
Fontos része a kódnak – mely a fejlesztők ismereteiről sokat elárul – a DP_RECV (Standard Library/ FC2) funkció működésének módosítása. Normál körülmények között ez a funkció – DP Slave oldalon – átveszi a DP-Master által továbbított kimeneti állapotokat a megadott DP területen.
A 417-esre szánt program kissé összetettebb a maga 12.000 soros AWL-jével, és tíz adatblokkjával. Két adatblokk (DB8062, DB8063) statikusként kerül letöltésre, egy dinamikusként (DB8061), a többieket pedig a kód generálja ki (DB8064..DB8070). Kifejezetten érdekes ezek közül a statikus DB8063, melynek mérete 26,790 byte, és egy 16 kbyte-os, 164 * 6-os  tömböt tartalmaz. A kigenerált kód az OB1-ből meghívásra kerülő FC-kből áll. 
Szakértők eleinte úgy vélték, hogy ez a blokk a Bushehr elleni támadást hajtotta volna végre, deRalph Langner vírusbiztonsági szakértő szerint ennek a 315-ös PLC-k fölötti S7-400-as„megbolondítása” volt a célja. 
Míg az S7-300-asok egyértelműen a rotorokat és az egyedi centrifugák vezénylését végezték, szerinte a 400-as a technológiát és annak szelepeit felügyelte. A fent említett tömb jó eséllyel a szelepek funkcióinak a felülírását végezte, erre utal annak 164 * 6 –os tagolása. Ezt a DB-t (DB8063) például a – szintén generált – FC6068 hívta egy 168-as ciklusban, melyet viszont az FC6070 hívott fel hatszor.  
Valószínűleg a nantanzi centrifugák 6 darab 164 elemű kaszkádba voltak rendezve, így a vírus ennek a 984 centrifugának a fokozatos tönkretételét valósította meg.

A Stuxnet és hatásai (második rész)


2011.02.14. 17:45

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: 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: 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:
 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
          2. Válassza le a gépet a hálózatról
          3. Adminisztrátor jogokkal futtassa a SIMATIC Security Updates-t
          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:

Források

Bevezetés:

The Christian Science Monitor

Sztori:

Cserháti András: A Stuxnet vírus és az iráni atomprogram
Abel Danger: ‘DEADFOO7’computer virus ('deadfoot') - clandestine nuclear-weapons procurement - Guild of Contract Hits - D2 Banking’s digital-data archives

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

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

Sulinet: Atomenergia

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

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

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

Hatásmechanizmus:

When there is more at risk than just information – Langner

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

Microsoft Malware Protection Center: The Stuxnet Sting
MS10-061: Printer Spooler Vulnerability


Wikipedia / Nulladik napi támadás

Wikipedia / Exploit

Hogyan védekezzünk:

Siemens forum / Joel Langill

Wikipedia / legkisebb jogosultság elve

Wikipedia / csoportházirend-objektumok

DuQu - Stuxnet reloded


2011.11.05. 21:11

Az előzményekről már ezen a blogon is írtam (A Stuxnet és hatásai (első rész második rész), ezeket most röviden összefoglalom. A Stuxnet vírus egy sebészi pontossággal megvalósított támadás eszköze, melynek célja az iráni urániumdúsító program megfékezése volt, és ezt a célt el is érte.
Egy olyan behatolót sikerült fejlesztőinek létrehoznia, mely az internet nélkül (ezek a létesítmények úgyis szeparálva vannak a világhálótól), USB-pendrive-on terjed. A Stuxnet támadása legtöbb esetben csak egyfázisú, gyakorlatilag trójaiként terjed. Amennyiben viszont észleli, hogy az adott gép S7 PLC kommunikációra is alkalmas, a második fázist is elindítja.
Ennek a mechanizmusának a megértéséhez tegyünk egy kisebb kitérőt az ipari irányítástechnika világába (ha esetleg ön ismeri ezeknek a működését, kérem lapozzon, mert önnek fáldalmasan laikus leírás következik).

PLC-k

Ábra: Ob121.com
A fenti ábrán egy ipari felügyeleti rendszer sémája látható. Jobb oldalon a felügyelt technológiai rendszerek (robotok, motorok) míg bal oldalt a felügyeleti eszközök találhatók. A “SCADA kliens”-ek találhatók a vezénylőkben, ezekről lehet a rendszer működését követni illetve irányítani.
A fenti S7-400 pár irányítja a rendszer működését. Ez egy speciális nyelvrendszerrel programozható egység (PLC – programmable logic controller), ami automatizálási célokra került kifejlesztésre. Ez egy - számítógépes szemmel nézve - rendkívül buta berendezés, mert rendkívül korlátozott lehetőségeibe a képernyő, billentyűzet, egér meg bármiféle kezelői felület már (többnyire) nem fér be, viszont a letöltött programot gyorsan és megbízhatóan futtatja.
Ez a program biztosítja a részrendszerek, berendezések együttes és összehangolt működését, meghibásodás, kezelői beavatkozás esetén ez változtatja meg a teljes rendszer „összhangját”, és ez adja a jelentéseket a felügyeleti egységeknek a rendszer működéséről (státusz, diagnózis, hibaüzenetek).
Bővebben a PLC-rendszerekről itt olvashat)
 Ha egy behatoló „ütni” akar, a fenti ábra alapján egyértelmű ennek a módja: Meg kell változtatni a PLC-n (PLC-ken) futó programot, úgy, hogy az irányított rendszer működését káros módon befolyásolja, emellett viszont hamisított jelentéseket kell küldenie a felügyelet felé „minden rendben” tartalommal. A Stuxnet ezt tudja végrehajtani:
első fokozata gond nélküli terjedést tesz lehetővé számára a TCP/IP protokollal elérhető egységek között (a fenti ábrán a zöld színű vonalak). Amennyiben megtalálja a programozói gépet, életbe lép a következő szint:
második fokozata rövid időre a programozói gépen keresztül hozzáfér a vezérlőhöz (a felnti ábrán a kékes színű „mpi” vezetéken keresztül az „S7-400h pár”-hoz), és annak megváltoztatja a programját azáltal, hogy annak néhány modulját felülírja.
Az első fokozattal nincs nagy gond, hiszen az egységes Windows rendszerrel a korábbi behatolók is gond nélkül boldogultak (és sajnos, tegyük hozzá rögtön, a speciális PLC fejlesztő rendszerek nagy része csak Windows-on hajlandó futni).
A második fokozat érdekes kérdéseket vet fel: - honnan tudja egy behatoló program, hogy az adott programot hogyan kell átírnia úgy, hogy a fenti eseménysort kiválthassa?
A válasz meghökkentő a Stuxnet esetén : a behatoló program nagyon pontosan tudta, hogy mit és hogyan kell manipulálnia – egy adott rendszer esetében. A többi megtámadott rendszer esetén a Stuxnet (elméletileg) nem okozhat károkat, mert az adott modulokat az előre leprogramozott tartalommal nem találja, a károkozót csak egy célpontra fejlesztették.

Stuxnet (2009)

Az urániumdúsítás egy rendkívül összetett, de a felügyelet szempontjából egy dög unalmas munka. 5000, az álló embernél magasabb csőben pörögnek a centrifugák, melyek kívülről nem láthatók, mert hűtőrendszer burkolja ezeket.
(Bővebben az urániumdúsítás folyamatáról itt olvashat)
Főnöki szemle a nantanzi urániumdúsítóban - a kép  Mahmoud Ahmadinejad 2008-as látogatásakor készült. Háttérben az ominózus centrifugák, fotó: Getty Images.
Ezek a centrifugák nagyon nagy és egyenletes sebességgel (~ 1000 fordulat per másodperc, ~60.000 rpm) működnek, és rendkívül kis súlykülönbség alapján szeparálják az urániumot.
A centrifugák sebességének a változtatása két dolgot eredményez:
- a sebesség csökkentése majd növelése a szeparáció összeomlását
- a sebesség túlfutása a centrifugák élettartamának csökkenését, vagy azoknak a tönkremenetekét.
Ez volt a célja a Stuxnet kifejlesztőinek, a támadás célpontja pedig az iráni Nantanz város melleti urániumdúsító volt. A támadáshoz ismerni kellett a centrifugák paramétereit és programozását, illetve a program szerkezetét is, de mindez a fejlesztők számára nem jelentett akadályt.
A centrifugák manipulációjából a rendszert felügyelő technikusok nem láttak – nem láthattak semmit, mert a vírus a PLC-k által kiadott státuszjelentéseket is felülírta.
2010. november 16.-án Irán leállította az urándúsítóit, miután a centrifugák több, mint 20%-a megsemmisült a Stuxnet tevékenysége nyomán, azaz a kártevő elérte a célját.
 Az előző – Stuxnetről szóló – bejegyzésemben már írtam, hogy a Stuxnet az első a sorban, és szinte biztosak lehetünk abban, hogy nem az utolsó. Ralph Langner, hamburgi hálózatbiztonsági szakértő, a Stuxnet egyik leleplezője nyilatkozta a júliusban , Tallinban megtartott NATO-Konferencián: “Ez a fajta hadviselés változásokat fog hozni. Több, hasonló támadást is fogunk a jövőben látni”.
Nos, a saga folytatódik, itt a követő behatoló.

DuQu (2011)

A magyar CrySyS Adat- és Rendszerbiztonság Laboratórium azonosított egy dropper fájlt, mely egy MS 0-day kernel hibát használ fel. A behatóló a “~DQ” prefix-szel egy fájlt generál, nevét innen kapta (DuQu).
A Symantec megállapította, hogy a DuQu terjedési mechanizmusa gyakorlatilag megegyezik a Stuxnet-tel, de annak egészen specifikus céljával szemben a DuQu – a Symantec feltevése szerint – egy Stuxnet-szerű támadás előfutára – kódját az előd fejlesztői írták, vagy annak kódjából fejtették vissza. A behatoló Kevin Haley, a Symantec Security Response igazgatója szerint Word-fájllal terjed.
A DuQu a potenciálisan megtámadható rendszerekről, és a rendszerek fejlesztőiről / gyártóiról gyűjt adatokat. Az elsősorban távoli hozzáférésű trójai (remote access Trojan - RAT)nem tartalmaz ipari kódot (elődjével szemben).
A viszonylag ártalmatlan szerkezete nem zárja ki olyan – egyelőre fel nem tárt - variánsainak a létezését, melyek például Stuxnet-szerű támadásra alkalmasak. A támadók a DuQu-n keresztül a fertőzőtt gépre telepítenek egy infostealer-t, mely rögzíti a billentyűleütéseket.
A behatólónak két variánsa ismert, az egyik 2011 szeptember 1-jén keletkezett. A trójai egy tajvani cég digitális tanúsítványát használja, mely 2012 augusztus 2.-ig érvényes, de 2011 október 14.-én visszavonásra került.
A DuQu HTTP és HTTPS protokolokon keresztül képes kommunikálni a command-and-control (C&C) szerverrel, a begyűjtött információkat egy enyhén titkosított és tömörített helyi fájlba tárolja.
A behatoló saját protokollt alkalmaz az átvitelhez, melyet valószínűleg .JPG fájloknak álcázva valósít meg. A kód 36 napig marad aktív a fertőzött gépen, ezután törli magát.

Elterjedtség

 
Kép: Symantec
A Symantec Franciaországban, Hollandiában, Svájcban, Ukrajnában, Iránban, Szudánban, Vietnamban és Indiában bukkant a DuQu által fertőzött gépekre, de a fertőzés feltételezhetően elérte Nagy-Britániát, Indonéziát, Ausztriát és Magyarországot is.

Védekezés

Jerry Bryant, a Microsoft szóvivője szerint cége tisztában van a DuQu kockázataival: "Partnereinkkel azon dolgozunk, hogy kijavítsuk a biztonsági rést, melyet a DuQu kihasznál."
Mindenesetre amíg nem sikerül a fenyegetést elhárítani, senki ne nyisson ki e-mail-ben érkező és ismeretlen forrásból származó Word-dokumentumot.
Jelenleg (2011. nov. 4) itt tartok az események követésében, amennyiben újabb információk kerülnek napvilágra, ezt a bejegyzést is bővíteni fogom.

További fejlemények


2011. nov. 4: Gyorsjavítás érkezett a Windowsokhoz
A Microsoft tegnapi tájékoztatója ismerteti, hogy a mindeddig feltáratlan hiba a win32k.sys beágyazottbetűkészlet-feldolgozó alrendszerében található, és ez lehetővé teszi, hogy közvetlenül rendszer szintű kódfuttatást történjék a Wordből. A hiba az összes Windows-verziót érinti.
A gyorsjavítás telepítője letölthető a Microsoft terméktámogatási oldaláról. A végleges javítás kiadásának időpontja még ismeretlen, de annyi bizonyos, hogy leghamarabb a jövő héten, a szokásos havi frissítéskor érkezhet. (Forrás: IT café)
2011. nov. 4: CC szerver Belgiumban
egy új command-and-control irányító szervert fedeztek fel Belgiumban (77.241.93.160), amelyet le is állítottak (Forrás: IT café)

Források, előzmények




PLC alapok



Rövid történet

A PLC első definiciója a General-Motors-nál (GM Hydramatic) született meg, 1968-ban, az alábbi kritériumokkal:
  1. A vezérlőnek egyszerűnek kell lennie, és igény szerint bármikor új programot lehet rá tölteni
  2. A vezérlőnek biztonságosabbnak kell lennie, mint egy elektromechanikus megoldás, és ár - érték arányban meg kell előznie ezeket a megoldásokal
Richard Morley, Tom Boissevain, George Scwerk és Jonas Landau a Modicon 84 társaságábanA berendezés kifejlesztését az ez időben ugrásszerűen fejlődő félvezető technológiák tették lehetővé. A nyerő megoldást a Bedford-beli (Massachusetts) Associates of Bedford szállította le. Az első PLC-t Richard Morley (Modicon) és Odo J. Struger (Allen Bradley) építette meg "Modicon 084" néven 1969-ben. Morley elvetette, hogy csodakütyüjüket "computer" névvel illessék, mert a készüléket inkább a elektronikai-technikai szakembereknek szánta, akiket elriasztott volna (az akkoriban) rendkívül tudományos computer szócska, így inkább a vezérlőnél (en: controller) állapodtak meg. Az akkori vezérlőktől - a GM elvárásoknak megfelelően kifejlesztett - letölthető létra (en:ladder logic - LAD, de: Kontaktplan - KOP) program külömbözetette meg, mely nyelvszerűség az áramútrajzok logikáját tükrözte. A controller így kiegészült a programable logic jelzővel, így összeállt a PLC szókapcsolat.
A német piacra elsőként a Klaschka nevű cég tört be a PLC szóból tükörfordítással született első SPS-sel, 1974-ben.
A Siemens a Simatic S3-mal, az első SPS-ével 1971-ben állt elő, de ez a berendezés még meglehetősen kiforratlan volt, és nem is terjedt el. A valódi Simatic SPS történet 1979-ben, a Hannover Fair-en kezdődött, ahol bemutatták az S5 sorozat első darabjait. (A Simatic család történetének a kezdete 1958. árpilis 2.-ára datálható, ekkor történt meg a termék bejegyzése, és ekkor került gyártásba a Simatic G-sorozat, ami ugyan germánium-bázisú volt, de nem rendelkezett menthető programmal).
A PLC ma jellemzően egy saját operációs rendszerrel rendelkező, modulárisan felépített vezérlőberendezés, mely rendelkezik legalább egy porttal, ahol a program feltölthető rá.
A PLC programok közös jellemzője a ciklusorientált végrehajtás, mellyel programozásuk jelentősen eltér a PC (MAC) bázisú programnyelvektől.

Besorolás

Legegyszerűbb besorolás szerint vannak az "alap" PLC-k, és vannak az Ex, F, H, FH rendszerek. A legnagyobb gyártók minden kategóriában indítanak versenyzőt, a kisebbek általában megmaradnak az "alap" kategóriában. A külömbség a specializált és "alap" rendszerek között az, hogy milyen speciális elvárásoknak kell megfelelni a rendszernek. A fenti betűjelzések jellemzően az árakat és projektálás bonyolultságát nagyságrendekkel emelik. Vegyük ezeket sorra.

Ex  (ATEX): Robbanásveszélyes környezet

fr: Atmosphère explosible de: explosionsgefährdeten Bereichen en: explosive atmosphere
ex logo a Wikipedia-rólAz "Ex" betűpárral a robbanásbiztos berendezéseket jelölik, melyek az ATEX irányelv besorolása alá esnek. Az ATEX minősítést bevizsgálás után adhat ki a gyártó a berendezéseire, az alábbi kategóriákba besorolva azt:

1. Berendezéscsoport (Gerätegruppe I)

Ide tartoznak a bányaberendezések, a föld alatti- és fölötti fejtőberendezések.
  1. M1 (ATEX CE Marking Group 1) kategória : nagyon magas bizonsági követelmény
  2. M2 (ATEX CE Marking Group 2) kategória : magas bizonsági követelmény

2. Berendezéscsoport (Gerätegruppe II)

Robbanásveszényes környezetben alkalmazott berendezések.
  • 1. kategória (Kategorie 1) : állandó vagy gyakori veszély - nagyon magas bizonsági követelmény
    • Zone 0: veszélyt jelentő anyag : gáz
    • Zone 20: veszélyt jelentő anyag : por
  • 2. kategória (Kategorie 2) : alkalmi veszély - magas bizonsági követelmény
    • Zone 1: veszélyt jelentő anyag : gáz
    • Zone 21: veszélyt jelentő anyag : por
  • 3. kategória (Kategorie 3) : ritka vagy rövid időre fellépő veszély - normál bizonsági követelmény
    • Zone 2: veszélyt jelentő anyag : gáz
    • Zone 22: veszélyt jelentő anyag : por
Az Ex környezet jellemzően csak a hardverrel szemben állított követelmények szintjét emeli meg, programozási szempontból jelentős külömbséget nem jelent a "normál" programozáshoz képest.

"F" hibatűrő rendszerek

de: Fehlersichere Systeme, en: failsafe, fault - tolerant systems
A fail-safety rendszerek az emelt bizonsági követelményeknek megfelelő PLC-ket jelölik. Fontos kritériumuk ezeknek a rendszereknek, hogy melyik un. SIL szintnek felelnek meg.

SIL Norma

de: Sicherheitsanforderungsstufe, en: Safety Integrity Level
A SIL a funkcionális biztonságot hivatott definiálni az IEC 61508/IEC61511 normával. A norma 5 biztonsági szintet határoz meg, ezek első közelítésben (egyszerűen) így definiálhatók:

Kiesési valószínűség
low demand (PFD)
high demand (PFPH)
Lehetséges kár mértéke
Siemens Simatic vonzata
SIL 0
low demand
high demand
Elhanyagolható.
Normál PLC.
SIL 1
>=10-2 -tól <10-1 -ig
>=10-6/h-tól <10-5/h-ig
Kisebb személyi sérülések, kisebb környezeti (berendezésben okozott) károk.
Normál PLC megfelelő redundanciák bizosításával, Distributed Safety vagy Safety Matrix, F-es PLC
SIL 2
>=10-3 -tól <10-2 -ig
>=10-7/h -tól <10-6/h -ig
Súlyosabb (akár végleges) személyi sérülések, egy személy halála, komoly környezeti (berendezésben okozott) károk.
Normál PLC megfelelő redundanciák bizosításával, Distributed Safety vagy Safety Matrix, F-es PLC
SIL 3
>=10-4 -tól <10-3 -ig
>=10-8/h -tól <10-7/h -ig
Több személy halála, tartós és nagy mértékű környezeti károk, berendezésben okozott totálkár
Distributed Safety vagy Safety Matrix, F-es vagy FH-s PLC, biztonsági PLC-vel lebiztosított (többszörösen) redundáns PLC-s rendszer
SIL 4
>=10-5 -tól <10-4 -ig
>=10-9/h -tól <10-8/h -ig
katasztrófa, tömegkatasztrófa (Seveso, Csernobil, Bhopal, Escheden)
biztonsági PLC-vel lebiztosított (többszörösen) redundáns PLC-s rendszer

A SIL4 előírásrendszere (önálló) Simatic F PLC-vel nem teljesíthető.
low demand : Kiesés-valószínűség középértékének elvárás szerinti szintje a tervezett funkciónál (Probability of Failure on Demand (PFD))
high demand : egy kiesés következtében bekövetkező baleset valószínűsége / óra (Probability of Failure Per Hour (
PFPH))

Beckhoff F kártyákA SIL norma besorolása persze a fenti táblázatban a megfelelő sorra való rábökésnél sokkal összetettebb feladat. Ehhez egy un. hatásanalízist kell készíteni (de:Auswirkungsanalyse), aminek a metódusát az FMEA (en: Failure Mode and Effects Analysis de: Fehlermöglichkeits- und Einflussanalyse) eljárás foglalja magába, de ez már egy másik, az automatizálástól szerencsére független "iparág".
A SIL norma egy esemény (kiesés) bekövetkezésének valószínűsége szerint sorolja a biztonsági szinteket a fenti táblázatban. A norma külömbséget tesz a "low demand" és "high demand" valószínűség között. Nagy általánosságban a külömbség, hogy azokra a rendszerekre, melyek ritkán válthatnak ki balesethez vezető eseménysort (pl. egy vészállj gomb) a "low demand" érvényes. "high demand" körbe tartozik a norma alá vont biztonsági rendszer minden, folyamatosan működő eleme.
A gyártóval szemben a norma előírása, hogy a SIL 2-ig saját felelőségre állapíthatja meg a besorolásokat, a SIL3-4 szintekre viszont külső, független szakértőt (pl. TÜV) kell bevonnia.
EchoPod Ultrasonic F-es szintérzékeloA (PLC) SIL értékének meghatározásához fontos momentum, hogy a SIL előírás mindig az egész rendszerre vonatkozik, és azt a teljes rendszernek kell teljesítenie. Így például egy SIL1-2-es rendszerhez korántsem biztos, hogy F-es PLC-t kell bevetni, hiszen a teljes rendszer tartalmazhat olyan redundáns elemeket, melyek a PLC-re eső "elvárást" jelentősen csökkentik. Vasúttechnikában például igencsak ritkán szokott a vonatok fedélzetére F-es rendszer kerülni, mert a PLC-n kívülirendszer (un. konvencionális vezénylés) annyi redundanciát tartalmaz, mely a baleset bekövetkezésének az esélyét jelentősen csökkenti.
A német fejlesztő cégek jellemzően SIL1-2-t hagyományos, redundanciába szervezett PLC-kel szokták megvalósítani. A programozók kezét a programozási szabályok rendszerbe foglalásával kötik meg. Ez az irányelv (de: Richtlinie) dokumentum tartalmazza a kőbe vésett szabályokat, például csak SCL-t használunk, AWL-t csak a végső esetben, GOTO-t csak kivételes esetben (hibára kiugrás) lehet használni, stb. TÜV bevonása esetén ők először az irányelvet bogarásszák végig, majd megnézik, hogy ez a programkódban mennyire következetesen lett vegighurcolva. Ha a ez a következetesség <100%, akkor ott fejek fognak hullani - a programozokkal kezdve a sort.
A másik irányban, egy SIL4-es rendszert is ki lehet építeni Simatic berendezésekkel, annak ellenére, hogy a Simatic PLC-k maximum csak SIL3-at "tudnak". Személy szerint én is írtam már pályabizosítási (Stellwerk) rendszerhez F-es programot, S7-317F-re - nem állítom, hogy rózsás menet volt, de átment a TÜV-ön (és használják is).
A legtöbb, magára valamit is adó PLC gyártó rendelkezik fail-safety rendszerrel, melyeket jellemzően aranyáron mérnek. Az F-es redszerelemeket sárga színnel külömböztetik meg.

meg a többi norma

A mértékegységeknek - csakúgy, mint a normáknak - hátrányuk, hogy már a szabványosítási kísérletek előtt is léteztek, így minden ellenkező törekvés ellenére létezni is fognak, millió változatban.
A SIL mellett a biztonsági szintek jellemzésére még megtalálható a DIN 19250 (DIN V VDE 0801), a TÜV-SK és az EN-954-1.
Ezeknek a nagyjából megfeleltetését ábrázoltam az oldalra biggyesztett táblázatban. A táblázatot önszorgalomból raktam össze, remélem, megfelel a valóságnak, mert már tényleg rosszul voltam attól, hogy minden technikai leírás más normára hivatkozik.


"F" rendszer konfigurálása

Simatic
A Simatic környezetben a 300-as és a 400-as család tagjaival lehet "F"-es rendszert megvalósítani. A 300-as családból 2 plc áll a rendelkezésünkre, a 315F és a 317F. A 315F tényleg csak kisebb alkalmazások megvalósításához elegendő memóriával rendelkezik, jellemzően a 317F alkalmas összetettebb műveletekre. A 300-as család gépein csak a "distributed safety" opcionális programnyelvvel lehet "F" blokkot programozni. A program tartalmazhat "normál" programot, normál I/O műveletekkel és "F"-es blokkot zárt programkezeléssel, speciális "F" I/O műveletekkel és korlátozott átjárási lehetőséggel a normál program felé.
Fizikai megvalósításban a normál I/O kártyákat és az "F" I/O kártyákat leválasztó kártyával kell szeparálni egymástól.
A Simatic "F" (Simatic Safety Integrated) az alábbi normáknak felel meg:
  • IEC 61508: 2000 SIL 1 - 3
  • EN 594-1: 1997 Kat. 2 - 4
  • IEC 61511: 2003
  • EN 60204-1: 1997
  • EN 62061: 2005 SIL 1 -3
  • NFPA 79-2002, NFPA 85
  • UL 1998, UL 508 und UL 991
  • EN ISO 13849-1: 2006 PL a - e
A Simatic "F"-es PLC-kről bővebben itt olvashat.
Az "F"-es Simatic rendszerek programozásáról bővebben itt olvashat: Distributed SafetySafety Matrix.

"H"-s, rendundáns rendszerek

de: redundanten hochverfügbaren Steuerungen en: highly available control system
A "H"-s rendszerek célja a magasabb rendelkezésre állás, melynek több megvalósítási szintje is lehetséges.
A legegyszerűbb, és legolcsóbb megoldás az, ha az irányítástechnikai rendszer minden eleméből található raktáron, és a gyártást olyan személyzet (is) felügyeli, akik a kieső egység helyére a legrövidebb idő alatt tartalékot tudnak "varázsolni". Nem túl feszes rendelésre termelő gyártósoroknál ez a rendelkezésre állás már elegendő szokott lenni.
Ennél egy szinttel magasabb az a rendelkezésre állási fokozat, amikor egy un. hideg tartalék rendszer (jellemzően csak PLC) is beépítésre kerül. Ez lehetővé teszi, hogy az elsődleges rendszer kiesésekor a másodlagos rendszer felfutása után (hidegindulás, programbetöltés, helyzetfelismerés és indulás) az üzembe áll. Nyilvánvaló módon ez alatt a felfutási idő alatt a technológia vagy leáll, vagy kontroll nélkül marad. A felfutási idő rendszer (PLC) függő, de sok esetben ez a kieső idő megengedhetetlen.
Valós, vagy valódi redundáns rendszerről akkor beszélhetünk, ha a tartalék rendszer az elsődlegessel párhuzamosan fut (STAND-BY), és az elsődleges rendszer kiesésekor nagyon kis időn belül átveszi a vezénylést.
Megvalósítás terén létezik szoftveres redundancia, amikor speciális programok segítségével a programozónak kell a redundanciát biztosítania. Itt természetesen fennáll a programozói tévedés lehetősége, és jelentős időt vesz el az értékes ciklusidőből ennek a programnak a futása.
Jóval hatékonyabb és gyorsabb (no meg persze drágább) megoldás a hardveres redundancia. Ebben az esetben a hardver (illetve az abba integrált szoftver, ami független a felhasználói programtól) biztosítja a redundanciát. Külön csatornán keresztül frissíti a STAND-BY gép memóriájának tartalmát, és annak indulási kritériumait is felügyeli. A hardveres redundancia nem igényel szoftveres feljesztést vagy speciális fejlesztői rendszert, ugyanis ennek kezelése szoftveres oldalról nem látható (csak ha tényleg kíváncsiak vagyunk rá).
A redundáns rendszerek Achilles-sarka természetesen az az elem, melyet nem biztosítanak le tartalék rendszerrel. Előfordulhat, hogy a rendundáns PLC rendszerünkhöz csak egy 230 V-os betáplálást használunk, így bár látszólag megbízható a rendszerünk, melybe milliókat öltünk, egy néhány ezer forintos kismegszakító is kiütheti azt.
A fenti példán egy részben redundáns technológiai séma látható. Azért részben, mert voltaképpen az S7-400-as pár, az arra csatlakozó S7-300m-ek, és a SCADA rendszer redundáns, a többi rendszer nem az. Talán ebből a példából is kiderül, hogy nem szükségszerű, hogy a teljes technológiai rendszer legyen tartalékkal kiváltható, elegendő, ha annak csak a legfontosabb részeit tesszük redundánssá. Az alábbi elemekről a nevükre kattintva bővebb információhoz is juthat:
Vámos Sándor 2010.04.11. plcCode4You forum 11.04.2010 18:59:52

felhasznált források

license

Creative Commons License
Erre a dokumentumra a 
Creative Commons-Lizenz 3.0 szabályai érvényesek.
A dokumentum továbbfelhasználása engedélyhez kötött. Részleteiben is csak forrásmegjelöléssel
(pl: 
forrás:wwww.ob121.com) használható.
Engedélykérés, további információ: 
mail kukac ob121.com



Malware "Duqu"A féreg minden esetben


2011/10/22  · A rosszindulatú program Duqu készen áll a következő támadás ipari ellenőrző rendszerek. Mennyire sebezhető vagy, megmutatta unokatestvére Stuxnet két évvel ezelőtt Iránban.
















"Little Brother" a Stuxnet felszínre az európai© DPA
Duqu: a "kistestvér" a Stuxnet megjelent Európában
A mérnökök a kontroll szobában a natanzi urándúsító üzem Iránban, ment minden rendesen. Azok vezérlő képernyők, a rotorok a centrifuga egy egységes dorombolta frekvenciája az 1064 fordulat másodpercenként - ez nem feltétlenül szükséges, hogy külön a kívánatos öngyújtó a nehezebb urán izotópokat. A szakember nem tudja, mi volt igazán az alumínium csövek történik. 
Egy rövid ideig a rotor gyorsult 1410 fordulat másodpercenként, egy hónappal később, ő lelassult megállt, majd ismét gyorsult. A finom centrifugálás gáz volt a jól mérhető, de halálos stressz: Ők fokozatosan kiesett, több mint 900 több mint 5000 váltotta egy éven belül. Végül van, hogy észrevette a technikusok, hogy látták a saját képernyőjén egy rossz film, nem a valóság: Az ellenőrzési rendszerek nyújtja be őket a régi adatokat, ők rögzített normál működés során.Ez volt a film távol a világ heal gazdagodás egy bunker 20 méter a föld alatt, a büszkesége az iráni rezsim. Ahogy törte is a fejét Irán nukleáris programjának lecserélésre került.

Stuxnet - született 2009-ben

2009-ben, egy féreg jött a világra, egy szoftvert szakember később megkeresztelkedett "Stuxnet". Egy trójai, hogy lóg jól álcázott számítógépes hálózat (angolul: beragadt). A férfi, aki leleplezte a férget, Ralph Langner Hamburg, beszél ma az első cyber fegyvert a történelemben. Ez a fegyver működött egészen eltérően minden korábbi próbálkozások. Szüksége volt az internet nem, ez pontosabb és romboló. És drágábbak, mint bármilyen hagyományos támadás: Néhány millió dollárt lehetne kikapcsolni közel ezer centrifuga mélyen bunkered. "Ez a fajta háború megváltoztatta a tájat. Meglátjuk több ilyen támadások" Langner figyelmeztetett júniusában egy NATO konferencián Tallinn.
További cikkek
Mivel a múlt héten a világ láthatja, hogy a következő támadás készül. A Symantec, a vezető a számítógépes biztonság, figyelmeztette a közvéleményt "Duqu". "Majdnem olyan nagy fenyegetés Stuxnet, de egy teljesen más célra," jegyezte meg a számítógépet. A féreg nem érinti az ellenőrző rendszerek, adatok gyűjtése róluk, hanem a gyártók és a szolgáltatók. "A támadók által keresett információért, mint tervezési dokumentumok, amelyek segítik őket, hogy végre a jövőben támadás ipari ellenőrző létesítmény" A Symantec írta az elemzés során a vírus.
Pontosan hol észlelte Duqu, a számítógép lehet félhomályban. 14-én Október voltak egy "kutató laboratórium erős nemzetközi kapcsolatok" említett, az új fenyegetés. A labor fedezte Duqu a különböző számítógépes rendszerek Európában. A szóvivő a vállalat Siemens, a világ vezető ipari rendszerek, azt mondta ez a sajtó, jelenleg a társaság a számítógép nélküli fertőzés Duqu ismert.Ez nem csinál semmit: a féreg van programozva, hogy el kell távolítani után 36 nap magának a rendszernek, amelyet korábban ő kémkedett.

Fekete dobozok

Vezérlő egységek, irányítók angol, fontos részét képezi a modern világban. Kapsz mindenütt használható, ahol a folyamatok automatikusan szabályozott. Minden van egy közlekedési lámpa vezérlő, amely meghatározza, hogy milyen hosszú a zöld fázis. Ez lehet a határokon kapcsolódik más vezérlők és meghosszabbítja a piros fázis, amikor egy kocsi közeledik. Minden automatizált gyártás - ez a töltelék palackok vagy összeszerelése járművek - szabályozza irányítók munkafolyamatokat. Nem növény, nem repülésirányító központ, nincs gát most sokkal nélkül a vezérlő.
Annak ellenére, hogy itt vagy minden számítógépet, saját maguk nem számítógép. Vezérlők fekete dobozok, gyakran kisebb, mint egy cipősdoboz. Ők se monitor se billentyűzet. Önnek nem kell a hálózati kapcsolat, és nem a saját biztonsági rendszer. A növények kommunikálnak szenzorok és aktorok. A Natanz, megy, mint ez: Egy érzékelő méri a frekvenciáját a rotor egy centrifuga, összehasonlítja ezt az információt a tárolt referencia értéket, majd elektromos impulzusokat küld a motor, a forgórész felgyorsul vagy lelassul.
Stuxnet volt az első ismert számítógépes féreg, hogy már azt a vezérlő. Addig is, a digitális támadások szolgáltak megbénítja weboldalak, szerverek és hálózatok vagy kém. Ez közvetetten okozott fizikai kárt. Így volt ez alatt a támadás észt szerverek 2007-ben, nem pedig egy ideig lehet pénzt felvenni ATM-ek, a gép nem tudott hozzáférni fiókadatait, mert a hálózat megszakad.

A fegyver volt a befejezési

Az urándúsító üzem natanzi nem függ egy kívülről elérhető hálózat. Valaki Stuxnet már valószínűleg csempészett az USB stick egy technikus vagy tudós hozzáféréssel Natanz. A féreg mászik egy olyan hordozható számítógépet, és onnan a növény. Volt programozva, hogy mindig csak három fertőzött több számítógépen.
Száll a Stuxnet, szakértők csodálkoztak, mert a féreg kihasználta a ugyanazt a négy sebezhetőség a Windows operációs rendszer - általában a vírusok terjednek csak egy biztonsági rés. Még akkor is egyértelmű volt, hogy nem amatőr hacker volt a munka. De ez csak azokra a támogatási rendszer. Még kifinomultabb volt a vád: Ez állt kód fog futni csak egy egészen különleges növény-design. A Natanz, a féreg kerestem szerinti elemzése Ralph Langner a Siemens vezérlők a Simatic S7-300. A rosszindulatú modulok aktívak voltak, amikor csatlakoztak a frekvenciaváltó gyártója Vacon (Finnország) és Fararo Paya (Irán) és a munka egy adott frekvencia-tartományban. A fegyver így megtalálták a célt, a kezelőelemek a gáz centrifugák.

"Ez szigorúan titkos"

"A támadók pontosan tudta, mit keres. Szüksége volt tudni, hogy a részletes konfiguráció a rendszer. Ez szigorúan titkos", mondja Langner, aki konzultál, mint egy szakértő a biztonsági ellenőrző rendszerek ipari fogyasztók. Abban az esetben, natanzi tekintette ügynökök - spekuláció az amerikai CIA és az izraeli Moszad - megszerezte ezt a tudást. A következő cyberattack Duqu lehetne ezt a feladatot.
A Symantec azt állítja, hogy a fejlesztők a Duqu volt hozzáférése a forrás fájl Stuxnet. Mivel csak a fejlesztő ismert, mind a férgek jöttek az azonos feladótól.Langner kifejezve óvatos: Ez is lehetséges, hogy a fejlesztők a Stuxnet egyes modulok plagizált volna, anélkül, hogy ismerné a forrás fájlt. Ez lehetővé rekonstrukciós módszerek is Langner kérte megfejteni a rosszindulatú Stuxnet modulokat. Proliferáció, ellenőrizetlen elterjedése fegyverek is vannak a digitális világban. "Ez nagyon nehéz építeni az első cyber fegyvert. De másolja őket, csak akkor kell egy átlagos mérnök", mondja Langner.

Eredménytelen fenyegetések

Elrettentés ebben az esetben bármely többet, mint a hagyományos világban.Fenyegetések ellen, játékos, aki senki nem tudja meg, nincs hatása. Langner kéri, hogy a gyártó az ellenőrzési rendszerek nem csak a biztonsági rések a szoftver, hogy lehet programozni a vezérlő. Arra is felállított biztonsági rendszerek a vezérlők magukat. A vezetők elutasítják azt. ". Szabályozók eredendően ellenőrzési rendszerek és semmilyen biztonsági rendszerek Az Ön feladata, hogy biztosítsa a magas szintű termelékenység," mondja Siemens szóvivője Wieland Simon és tisztázza egyértelműen: ". A személy-és vagyonvédelmi rendszer a vezérlők nem építünk"
Siemens, amely termel minden harmadik szállítottak világszerte adatkezelő a meglévő biztonsági architektúrát, hogy elegendő. A vezérlők kínálnak "a magas fokú stabilitás és a biztonság," mondta Simon. A Stuxnet támadás nem volt célja egy adott márka vagy feldolgozási technológia.

Duqu lassan kinyitja az ajtót

Mennyire kiszolgáltatott a vezérlő szoftver a Siemens, Dillon Beresford bebizonyította idén augusztusban. Az amerikai biztonsági szakértő bizonyította egy konferencián Las Vegas-ban, mielőtt az összeszerelt tömeg, ahogy belép egy hátsó ajtón a vezérlők a Simatic S7-sorozat, amely egy fix ott elhelyezett jelszót, és a programozott a vezérlő. Beresford sikerült úgynevezett visszajátszás támadás, mint a Stuxnet megjelölve Natanz. Képes a támadó parancsokat küld az ellenőrzési rendszer az ECU. Ezek a parancsok egy későbbi lejátssza a behatoló távolról kell vezérelni egy speciális ellenőrzési egység.
Tényleg akartam Beresford rések már közzétesznek egy konferencián májusban.A sürgetésére a US Department of Homeland Security és a Siemens, s elhalasztotta a bemutatót, hogy a vállalat csatlakoztassa a hiányosságokat saját szoftver. De Beresford jelentett a türelmi idő után, hogy a korrekciók nem voltak megfelelőek, és a Siemens közölte ügyfeleivel megfelelően. Ma a Siemens, amelyeket azonosított Beresford biztonsági rések csak akkor releváns, ha a támadó közvetlenül az automatizálási hálózat létesítmény található. Normális üzemben biztosított maga ellen ilyen helyzeteket. De még ha a védelem volt a legnagyobb Natanz, Stuxnet nem volt ott. Duqu most arról, hogy nyissa ki az ajtót, a következő műtéti.

Online keresések, a trójaiak, a kód és a hatóságok


2011/10/22  · A szövetségi kormány világossá vált, hogy ő maga fejlesztett felügyeleti szoftver jobb, mint megvenni a magán cégek. Mert csak ő tudja, mit ő.








Számítógép-kód© DPA
Teljes átláthatóságot trójai lapkák szövetségi és állami kéri az ellenzék. Solo: Ez az átláthatóság valószínűleg nem ad. A Belügyminisztérium kérdezte országok között, hiszen valóban van olyan zugehe. És nem kapott információt."None", mondja a minisztérium.Regret? Outrage? - Nincs ilyen. "Az állam nem köteles tájékoztatást, ami megfelel a föderalista elvének." Vagy: Mi nem tudom, nem fog nekem meleg. 
Meglepő módon, nem volt, de egy kis pontosítás: Szerdán volt az elnöke a szövetségi bűnügyi rendőrség (BKA), Joerg Ziercke, egy bizalmas ülésen a parlamenti bizottság Belügy kapcsolatos trójaiak és válaszoljon a kérdésekre. A tisztviselők szerint Zierke, szállított a hesseni társaság Digitask szoftver használat előtt még vizsgálják. Ők nem kap a forráskódot, mert a gyártó neki kalapot, mint egy üzleti titok. Addig is, azt mondták, volt Digitask tehát jöhet számításba, mivel ezek lehetővé teszik a vállalat betekintést a forráskódot. De most már világos volt, hogy a hatóságok nem volt elég információ annak igazolására, hogy a szoftver a számukra valóban csak annyit tudnak lehet.

Egyszerű funkció teszt

A forráskód a programozás a szoftver alakítja át bináris kód, tudja olvasni a számítógép processzora. Itt megy néhány információ - mint a programozó hozzászólás - elveszett. Kizárólag a bináris kód olvasható, milyen lehet egy szoftver minden feltételezi egy csomó tapasztalat és az idő. Vannak olyan eszközök, hogy mivel a hackerek használta a Chaos Computer Club való elemzés, de még tartott hét, és a szoftver, így még mindig nem teljesen megoldott. Nélkül a forráskód, a tisztek a BKA hagyott mást, mint erre.
További cikkek
Ez lehet az oka a hatóságokkal folytatott használata előtt a szoftver által szolgáltatott Digitask egy meglehetősen egyszerű funkciót teszt. Azt is végrehajtani egy ismeretlen szoftver, amely ellenőrzött környezetben, és nyomon követheti a viselkedését a szoftver. De szigorúan szólva, lehet jellemezni csak meghatározni, hogy mi a program nem tudja, mit tehetne semmit azon túl még. A rejtett funkció betöltése kiegészítő modulok tehát felfedezni nem egyhangú véleményét szakértők.
A hatóságok tisztában voltak azzal, hogy ez a nem termel teljes bizonyossággal a szoftverrel. Tartottak a funkció vizsgálat még elégséges, mert nem látott okot a bizalmatlanság Digitask. Digitask egy biztonsági által jóváhagyott Department of Trade Company. A visszaélés kockázatot elhanyagolhatónak tekinthető.

Igényeihez igazított

Az adatvédelmi tisztviselő a Szövetség, Peter Schaar, a belső bizottság felkért vizsgálatára trójai lapkák vezetett az éles kritika Zierckes változatok. "Én is ragaszkodik ahhoz, hogy megkapom a lehetőséget, hogy vizsgálja felül a forráskód", mondta Schaar ezt az újságot. "Ha nem ellenőrzik a lehet, nem tudom megítélni, mi a szoftver valóban képes." Crowd már tervezik a közeljövőben, hogy a trójaiak a Vám Kriminológiai Hivatal ellenőrzést. Most már inkább a kinevezést. De először is, a szoftver a szövetségi és az állami rendőrség a vizsgálat alatt. Szerdán Schaars munkavállalók elhagyják Wiesbadenben, a trójaiak játszani a BKA.
Sok esetben a gyártók tartsa vissza a forráskódot, hogy fenntartsa felett forgalmazását a szoftver. Ki ezt a kódot lehet módosítani a program kis erőfeszítés és alkalmazkodik az új követelményeknek. Pontosan ez az, amit a hatóságok tesznek saját bevallása szerint minden használat előtt a trójaiak.Minden egyes új verzió a szoftver szükséges, de aztán megint felkérik a gyártó - és a díjazást.

Alternatív Loser Store

A cég Digitask aki programozott a trójaiak volt, szerint a biztonsági források, mint "nem az alternatív szolgáltatók." 2001 óta a Belügyminisztérium foglalkozik az ellenőrző számítógépes kommunikáció. 2006-ban, a projekt csoport jött létre.Egy évvel később Digitask szoftverek távközlési felügyeleti számítógépek használják az úgynevezett források távközlési lehallgatás. Ők úgy döntöttek, egy privát cég, mert a szoftver volt olcsóbb és könnyen hozzáférhető, azt mondják.
Továbbá, programokat aktualizálni kell a lehallgatás forrás, ami nagyon drága. Az online keresés, kémkedett merevlemezek és egyéb tárolóhelyek, azonban a saját fejlesztésű szoftver. A piaci tanulmány azt mutatják, 2008-ban, hogy nem magán szolgáltató lenne használható szoftver az online keresések tud nyújtani. A program, amelynek fejlesztési költsége 680.000 € működött 2010-ig.

"Ez nem történhet meg"

Volt, csapkodott, hogy a jelenlegi által szállított Digitask trójai a forrás TKU most nem a hatóságok félvállról venni. "Ez biztosan Digitask kap, és ez aggaszt bennünket", mondja egy magas rangú biztonsági tisztviselő. "Ez nem történhet meg." Miért most meg kell kötni Digitask. A kapcsolási konferencián belügyminiszterei a szövetségi és állami bejelentés belügyminiszter Hans-Peter Friedrich (CSU) csütörtökön, hogy a BKA kialakítja a szoftver a forrás lehallgatás a jövőben is. Amíg a konferencia Interior miniszterek négy hét, a Hatóság dolgozzon ki egy koncepciót a "kiválósági központ". A fejlesztés valószínűleg - mint az online keresések - több évet vesz igénybe. Addig is továbbra is támaszkodni a privát szoftver cég. Ahhoz, hogy ezek egységes országos szintű teljesítmény - és egy szakértői csoportot, amely ellenőrzi a megfelelést.Felügyelt? Lásd fent.
Az országok volna Frederick terveket jóváhagyták. De a munkavállalók még nem erősítette véglegesen. Ellenállás - hogyan is? - A Bajorországban. De még a biztonsági ügynökségek, a tervek találkozó nem csak lelkesedéssel. Vannak még biztonsági aggályok. A sikeres támadás egy központi szoftver azaz minden hatóságok érinti. Júliusban egy csoportja a hackerek feltörték a rendszert véletlenül talál "Patras", és egy szerver a vám nyilvántartások eltávolítjuk. Ők tartalmazott állásfoglalási profilokat felügyeleti műveletek, nyert a közös nyomozócsoportok szövetségi rendőrség, a vámhatóság és a különböző állami rendőrség.

A hivatalos trójaiakAnatomy of a digitális kártevők


2011/10/09  · Mivel az állami osztották trójai programok: a ​​hírhedt Chaos Computer Club találtam a felügyeleti szoftver, elemezték - és az apróra vágott. Az eredmény megdöbbentő. A trójai képes olvasni az elménket és ellenőrzése a számítógép távolról.
By FRANK RIEGER





Mi az állam trójaiak képes
© FAZ
27- Február 2008 kicsapjuk az Alkotmánybíróság történelmi ítéletet. Ahhoz, hogy kösse meg a vitát a szövetségi trójai - Hivatalos német "online keresés" - a német legfelsőbb bíróság bejelentette, hogy új alapjog titkosságát és integritását informatikai rendszerek. Úgy kezdődött, nagyon magas korlátok hírszerző és bűnüldöző szervek, ha akarnak beszivárogni a számítógépek a polgárok hozzáférés a digitális élet és az adatok nyomok. Az ítélet azonban tartalmaz egy átjáró okot adó között ravasz megfigyelők az első olvasat során, hogy teljes mértékben frown: Ez a szakasz az úgynevezett "forrás távközlési felügyelet".
A kormány képviselői a nyomozó hatóságok már Karlsruhe tárgyaláson azzal érvelt, hevesen, hogy szükség van egy módja annak, hogy elkapjam a titkosított kommunikáció már a számítógépen a gyanúsított, mielőtt titkosított. A bíróság ezt tette szándékát, hogy nem zárja be teljesen, így egy úgynevezett "forrás távközlési felügyelet" - de csak "ha korlátozódik csak megfigyelési adatok folyamatos távközlési folyamat. Ezt kell biztosítani a műszaki és jogi követelményeknek. "

Beavatkozás ellenőrizhetetlen mélység

Akkor hogyan kell működnie egy ilyen garancia a gyakorlatban technikailag már a szóbeli meghallgatás szövetségi trójaiak Karlsruhe, a rendkívül ellentmondásos kérdés. A bíróság elismerte a veszély minden esetben, és azt írta: "egy komplex informatikai rendszer céljából a távközlési felügyelet technikailag beszivárgott (, forrás távközlési felügyelet"), majd a beszivárgás vette a legfőbb akadálya, hogy a rendszer egészét kém. A kapott fenyegetés messze azon túl, amit van csatlakoztatva puszta ellenőrzésének jelenlegi távközlési. "









© CHAOS COMPUTER CLUB
A technikai háttere ezeket az aggályokat, hogy egy már telepített a számítógépen backdoor programmal könnyen hozzá lehessen igazítani úgy, hogy tartalmazza funkciók vagy lehetett tölteni a hálózaton keresztül, amelyek messze túlmutatnak az alkotmányosan megengedett. Erről a backdoor funkciókat lehetne majd ellenőrizhetetlen mélyen a védett központi területe a magánélet az érintett személy, hogy beavatkozzon.
óta az uralkodó, több mint három év telt el, és a német nyomozó hatóságok nem maradtak tétlen.

A kifogás kész

A büntetőeljárásban az ország volt az elmúlt hónapokban bizonyítékok felhasználásának trójaiak kommunikációs monitoring: Ha valamilyen információt a fájlban, a fentiekből, hogy a telefon megy Vizsgálat messzire, vagy úgy tűnik screenshotok a számítógép a vádlott, a megmagyarázhatatlan eredetű .Megterhelő a szemében nyomozók - e-mailek, chat beszélgetéseket dokumentálni, mint az úgynevezett kép különböző. Kért és engedélyezett bírói az úgynevezett "forrás távközlési felügyelet", mint egy normál telefon monitoring.Vádolják ellenállni a behatolás a privát szféra, hogy szólaljanak fel úgy, hogy a nyomozó hatóságok, hogy a használt szoftver a távoli monitoring, biztonsági szolgálat ellenőrizni származik. Ő is külön fogalmazták szerint megfelelő monitoring intézkedés. Kiterjedt minőségbiztosítási folyamatok célja annak biztosítása, hogy nem történt többlet a jogszerű lehallgatás képességek is.
Különös hangsúlyt mindig az, hogy a funkcionális kiterjesztése a "forrás távközlési felügyelet", hogy "online keresés" teljesen ki van zárva kell kémkedett amellyel minden adatot a számítógép és minden számítógépes funkció távvezérelhető.
Volt egy független szakmai vizsgálat ezen információk és a folyamatok még nem, akkor kellett támaszkodnia biztosítsa a hatóságoknak.
Egyes kémprogramok áldozatok nyilvánvalóan akart többet megtudni, mi történik a számítógépükön, és hogy valójában mi is szoros megfigyelés alatt mindent. Ennek során az elmúlt hetekben több lemez találkozott a híres barna borítékokat névtelenül a Chaos Computer Club.
után törvényszéki vizsgálatát a lemez egy csoportja által CCC hackerek valójában a néhány lemez egy hivatalos számítógép bugs szoftver. A trójai változatok nagyon hasonlóak egymáshoz, és csak kisebb eltérések. A fájlok egykor kémkedett az áldozatok már törlésre csak dilettáns és ez könnyen rekonstruálni szabványos számítógép kriminalisztika eszközök.

Következtetések, hogy a funkció

A hackerek kapott a részletes vizsgálatot. Amit ott talált meglepte még edzett cinikusok. Elemezze a rosszindulatú szoftverek hasonló a post mortem vizsgálat egy ismeretlen faj élő lények. Próbálják azonosítani az egyedi funkciókat, mint például a szem, a fül, a légzőszervi, keringési, emésztőrendszeri és hangképző.Ennek hatására Ön zoom összehasonlításokat ismert struktúrák - mint például, hogy a szemében gerincesek jellemzően lencse, szaruhártya, tanuló, üvegtest és a retina találhatók. Kezdőár jelenlétének vagy ezek hiányában ismert struktúrákat tanúskodik, valószínű funkcióit és kapcsolatait a anatómia.
A hasonló módszerek is azonosított, funkciók és kapcsolatok egy ismeretlen malware, amely jelen van, még csak a gépi kódot. Machine kódot kell olvasni, szemben az eredeti, egy magas szintű programozási nyelv, mint a C + + írásbeli és később lefordított gépi kód programkódot az emberek nehezen és megérteni.Ha valaki azt akarja, hogy felfedezzék, mi okozza egy bizonyos rutin a trójai, akkor keresse meg az első dolog, amit funkciók az operációs rendszer használnak.Az operációs rendszer a számítógép rendelkezik néhány nagyon alapvető által igényelt funkciókat minden program fut a számítógépen. Ezek közé tartozik az olvasás és írás a fájlok, küldhetnek és fogadhatnak adatokat a hálózaton keresztül, billentyűleütéseket, termel hangok és kimenet, vagy akár a kezdete programokat. Egyes részei a rosszindulatú programok és különböző feladatok elvégzésére, beleértve használatát különböző operációs rendszer funkcióit, amiből levonható az a következtetés, hogy a funkció, mint a patológus lehet következtetni jelenlétében lencse optikai érzékszerv.

Hibás végrehajtását a titkosítási

Különösen érdekes volt a vizsgálat azonnali meghatározott része a szoftver, amely felelős a távirányító a trójaiak a hálón. Futtatása után egy újonnan fertőzött számítógép, a malware köti titokban az összes programot, és elküldi őket, hogy egy fix konfigurációs szerverhez, amely érdekes módon az Egyesült Államokban - a jól ismert külföldi joghatóság - egy pár csomagot, hogy jelezze szándékát, hogy szolgálja. A csomagokat küldött a szerver védi egy AES titkosítást. AES bizonyított szabványos titkosítási módszerekkel, amely a kódolási és dekódolási ugyanazzal kulcs. Ez a kulcs azonos a CCC küldött trójai változatok, úgy tűnik, hogy újra felhasználható különböző megfigyelési esetekben. Visszafejteni a kommunikáció a szerver és elemezze a hacker éppen bontsa ki a kulcsot az egyik trójaiak, és megteszi a trójaiak egy szigetelve a külvilágtól hálózaton működik. Ők azonban észre, hogy a titkosítás műszakilag helytelenül hajtják végre, úgy, hogy még nem ismeri a legfontosabb következtetéseket a tartalma által benyújtott adatok a trójaiak a szerver lehetséges.
A trójai küld periodikusan egyfajta szlogen használt, hogy jelezze, hogy az amerikai szerver, hogy ez valójában egy trójai, hogy ellenőrzik. A hivatalos szlogenje rosszindulatú szoftverek számára szerver hozzáférés van C3PO-R2D2-POE. Úgy látszik, a programozók volt egy Star Wars fan: C3PO és POE nevezzük protokolldroid a sci-fi univerzumban a Star Wars saga, amely felelős a zökkenőmentes kommunikációt a különböző népek és idegen fajokkal. A droid R2D2 javítani űrhajók.
Miután a trójaiak e szlogen jelezte a jelenlétét, és még küldött néhány kiegészítő információt, mint például egyfajta digitális ügyszám, ő vár parancsokat a szerver.A CCC hackerek rémült meg, hogy a rosszindulatú szoftver, amely veszi a parancsokat minden védelem nélkül vagy hitelesítés.

Által nem észlelt víruskereső szoftverek

A parancsok azok kizárólag az egyes számok egytől 18, és néhány paraméter.Ahhoz, hogy kiadja a parancsokat nem lesz titkosítás használatban, nincs kriptográfiai hitelesítés vagy azzal egyenértékű. Mindenhol máshol a hálózaton, mint például az online banki vagy akár flörtölni portálok, amelyek már a hagyományos fedezeti mechanizmusok. Az egyetlen feltétel az elfogadását megrendelések az állam, hanem a kémprogramok, hogy néznek ki, mintha azok érkeznek az IP-címét a továbbítási szerver. A színlelve hamis feladó címe könnyű jól. Így a hivatalos számítógépes bug már megnyitott egy scheunentorgroßes biztonsági rést, amely lehet használni könnyen.
A funkciók érhetők el ezzel a távoli interfész is, felfedve. Ezek összetétele és típusú tervezési nem hagy kétséget afelől, hogy ez egy létrehozott nyomozók szippantás program. Hallgassa meg az internetes hívások a Skype, és figyelembe screenshotok a böngésző ablak található, az előtérben pontosan a funkciók, amelyek a nyomozó hatóságok többször hangosan követelte, hogy megkerülje titkosítást, ami egy "normális" hallgat lehetetlen. "Kereskedelmi" trójai programok, mint például a használt terjedésű online banki adatokat is, a többi, a tetején, hogy a használt eddiginél elegánsabb mechanizmusokat. A népszerű víruskereső programok, a trójai teljesen ismeretlen.

Ways of digitális bizonyíték hamisítás

Messze a legmegdöbbentőbb jellemzője, amely a részt vevő hackerek először azt akarta nem hittek a szemüknek, hívják az alábbi paranccsal a 14. Ez lehetővé teszi, hogy a tulajdonos a trójai parancs betölteni bármilyen programot a hálózaton keresztül a fertőzött számítógépre, és futtatni őket anélkül, hogy az érintett felhasználó észre semmit. Pontosan alkotmányosan erősen problematikus vonása a nyomozó hatóságok azt állították határozottan, hogy ő nem volt a "forrás távközlési felügyelet" tartalmazó program található az elemzésben. A betöltés részeinek a program lehet bármilyen, telepítse a határait a Szövetségi Alkotmánybíróság megengedett széles határok ellenőrzésére modulokat használó pl. mikrofon és a kamera a számítógéphez, mint egy űrfelügyeleti bug - ez a nagy digitális lehallgatók és Spähangriff. Hasonlóképpen lehet telepíteni e Programmnachladen funkciókat, amelyek segítenek keresni a merevlemez a beszivárgott számítógép és fájlok tölthetők le - a pontos meghatározása "online keresés". A csatlakoztatott eszköz programot tolnák még titokban fájlokat a hálózaton keresztül a számítógéphez vagy változtassa meg a tárolt adatokat.
Technikailag, így könnyen létre digitális bizonyítékok nélkül megakadályozása kémkedett e bizonyítani, vagy akár lehetett. Talált a merevlemezen képeket vagy filmeket, amelyek megmutatják a gyermekek bántalmazása, vagy más nehezen terhelő bizonyíték lehetett volna elhelyezni ott is. Az ilyen "bizonyíték" lenne "talált", például egy későbbi roham a számítógép és a törvényszéki jelenti, hogy nem felismerhető hamis.

Több, mint egy távközlési lehallgatás

, Hogy ha egy számítógépet beszivárgott, nem több bizonyíték biztonság, az egyik a legsúlyosabb kritikái behördlichem Computerverseuchen valaha. Ez most kiderül, hogy a közismert nevén "forrás távközlési felügyelet" bejelentett digitális kém egy Programmnachladefunktion és a tetején, hogy ez a funkció még kezdetleges ellen biztosítani visszaélés mások által, megerősítette a legrosszabb forgatókönyv. Tény, hogy ezek több, mint egy szövetségi trójai, nem korlátozott szoftver távközlési.
Minden aggályokat, amelyeket megfogalmazott a kritikusok a szövetségi Trojan-használat és segített meggyőzni a Legfelsőbb Bíróság, hogy a szövetségi trójai ítélet is megerősítette - nyilvánul meg a szoftver célja, hogy csak alkalmas távközlés. A Programmnachladens teljes távirányító, a manipuláció és értékelése a számítógép beszivárgott műszakilag lehetséges, még akkor is, ha a jogi felhatalmazás a "forrás távközlési felügyelet" volt.
A részletes elemzés ezen Programmnachladefunktion a Vámkódex hacker találkozott egy másik érdekes részlet. Míg a többi trójai szoftver nincs jelentős ügyletek ellen feltárása feladatait gép kódelemzés volt egy kísérlet abzutarnen különösen ezt a kényes funkciót, és leplezni tevékenységüket.

Forwarding szerverek külföldön

Ebből a célból, az egyes szoftver összetevők végén futtatni elvégzésére utáni töltött keresztül a hálózati program, és szétszórt darab a puzzle összetételre kerül csak akkor, ha szükségessé válik. Csak az összetett puzzle, akkor megadja a natív kód rutin, az újratöltés monitoring modul van beállítva, hogy hatékonyan működjön. A megbízó és a trójai programozók tudatában voltak a látszólag hatalmas alkotmányos megsértését, és megpróbálta eltussolni tetteikért.
A trójai kódját is, semmi sem utal a gyártó a szoftver. 2008-ban azonban, a belső levelezést az igazságügyi hatóságok nyilvánosságra került, amikor egy német cég kínál olyan trójai a Skype lehallgatás, amelynek alkalmassága összhangban áll az elemzett a CCC hackerek trójaiak. Még bérlése egy továbbítási szerver külföldön, hogy álcázza az IP-címet a trójai vezérlőállás említésre került az ajánlatot.
A beszivárgás a számítógép a gyanúsított két lehetőség szerepeltek: a létesítmény fizikai hozzáférést a számítógéphez - elképzelni egy rejtett behatolás, vagy egy biztonsági ellenőrzés - és az elektronikus csempészet. Az utóbbi történik, mint a dokumentumok használt észak-afrikai diktatúrák trójaiak vált ismertté. Általában e-mail mellékletként, vagy automatikus beillesztés a trójai programok, a letöltések a megcélzott személy

A felügyelő nézni

Még a szokásos "szállítás" a trójai nélkül - újratöltve modulok - funkciói valószínűleg igénybe a kormányzati snooping szoftvert kérdést. A gyors egymásutánban is screenshotok tartalmát a böngésző, az azonnali üzenetküldés és az e-mail programok készülnek, amelyek azt mutatják, a jelenlegi tartalmát minden program ablakban.
Egyre több és több ember használja web-alapú cloud szolgáltatások minden jelentős tevékenység a számítógépen. Akár webmail szolgáltatások, szövegszerkesztő és táblázatkezelő a Google Docs vagy fotót szolgáltatások - sok fut ma a böngészőn keresztül. És a tartalmát a böngésző ablak az állam teszi trójaiak parancsra néhány másodpercig a képernyő lövés. Az akvizíció kiterjeszti eddig nem csak a tiszta távközlés.
Mint egy flip-füzetet, a felügyelő figyeli a megjelenése szöveg válnak gondolatok, számítások, feljegyzések és e-mailek - egy képernyőképet a másik után. Soha elküldött üzenetek, amelyek az író hagyni, ehelyett küldje el földet, így a monitor kiszolgálón. Sok ember megszokta, hogy a gondolatait és érzéseit digitálisan rögzíteni, amit majd küldje el, de nem feltétlenül. Kétségtelen tartalmazhatnak ilyen intim megjegyzések szigorúan védett magterület, a Legfelsőbb Bíróság látni akarta őrizni. Most, a végén egy egyszerű engedélyezési távközlési felügyelet a személyes fájlokat a nyomozók és hírszerző ügynökségek.
További cikkek

Felügyeleti képességek az illegális szektor

Kiküszöbölése érdekében a kitettség a jelenlegi nyomozati lépések, a Chaos Computer Club tájékoztatták időben a közzétételét a részleteket a trójai állam, a Szövetségi Belügyminisztérium. Az állam vizsgált trójai hasonló funkció egy parazita, megbúvó az agyban az ő áldozata, hozzáférés hivatkozik az ő érzékszervei, és közvetíti a jeleket, hogy ő Úr és a Mester. A hatóságok egyértelműen visszaélt a beléjük vetett bizalma, és titokban történik pontosan mit csináltak a Legfelsőbb Bíróság tilos. A hivatalos malware vált eszköz, amely úgy lett kialakítva, hogy kivonat titkos digitális élet nyomait és ötleteket a számítógéphez a gyanúsított, és átadni egy gombot, még a nagy hallgatás és Spähangriff.
Az alapvető kérdés, hogy mennyi bizalmat hozható nyomozó hatóság alkalmazása az új technikai eszközöket nyerni, elemzése révén az állítólagos "forrás távközlési felügyelet" trójai új sürgősségi. Ez minden bizonnyal nem az első alkalom, hogy a rendőrség használt technikai eszközök "kreatív". Ez azonban az első alkalom, hogy ellentétben az explicit szavazás Karlsruhe, rendszeresen elvégzett egy titkos kiterjesztése felügyeleti képességek a régióban egyértelműen törvénytelen, sőt a nyilvánosságnak félrevezették erről.

Ismételt támadások az alapvető jogok

Az alapvető bizalom, hogy az új felügyeleti képességek és hatásköröket alkalmazzák a belső politikusok annyira magasztalt moderálás véglegesen elpusztult. És ismét a bíró fenntartott bizonyult fogatlan és elégtelen az alapvető jogok védelme a kémkedés. Az a kérdés, ahol a határok digitális magánélet, ami mindig igaz, megint sürgősen.
A katalógus a megengedett nyomozati intézkedések és módszereket kell meghatározni a jövőben sokkal pontosabb és kötelező, mert a technológiai szürke területek gyakran ahhoz vezet, hogy az alapvető jogok megsértésének, amelyeket nem szankcionált. Az is nagy idő a jogalkotó követelni szisztematikus fellendülés és megtiltotta az illegálisan szerzett bizonyítékok megfelelő szankciókról és ellentételezés szabályait. A csábítása az angolszász jogi műanyag "gyümölcse tiltott fa", mondta illegálisan megszerzett adatokat már kiderült túl nagy.


Nincsenek megjegyzések:

Megjegyzés küldése