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 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)

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, 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.
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 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.

Termé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.

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 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.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 a célját.

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

„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).

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.

„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 Stuxnet által fertőzött országok megoszlása

A kép forrása: Microsoft Malware Protection Center

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

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 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

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

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-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:

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
Megvárja, míg a helyi erők előkészülnek a worst-case-re.
Elballag a vezénylő szekrényhez, és RUN-P-be teszi a PLC-t.
Módosít, majd vissza RUN módba.
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

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 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á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

Redundancia 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.

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

A vezető kiadja az engedélyező jelet (külön jobb- vagy baloldalit, de ez most lényegtelen.)
Egy közvetlen vezetéken (UIC-vezeték) a jel továbbításra kerül
A vezénylő is beolvassa a jelet
A fékvezénylők jelzik, hogy a vonat álló helyzetben van (v<5km/h)
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)
A WTB link két, egymástól független vezetéken továbbítja a táviratot.
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:
Az UIC vezetéken érkező direkt jelzést,
A WTB felől MVB-n érkező engedélyező jelet,
é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)

Az 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/4387678 3/sysclean.zip?func=cslib.csFetch&nodeid=43932305

Ennek leírása:

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

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

Installálja a Microsoft Path-ot http://support.automation.siemens.com/WW/llisapi.dll?func=ll&objid=43876783&nodeid 0=10805583&caller=view&lang=de&siteid=csius&aktprim=0&objaction=csopen&extranet=stan dard&viewreg=WW#MS%20Security%20Patch
Válassza le a gépet a hálózatról
Adminisztrátor jogokkal futtassa a SIMATIC Security Updates-t http://support.automation.siemens.com/WW/llisapi.dll?func=ll&objid=43876783&nodeid 0=10805583&caller=view&lang=de&siteid=csius&aktprim=0&objaction=csopen&extranet=stan dard&viewreg=WW#SIMATIC_Security_Update_verf%C3%BCgbar__
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. Alkalmazzon csoportházirendet, illetve acsoportházirend-objektumokat! (Group Policy Object, GPO) 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ész, második rész.

Források

Bevezetés:

The Christian Science Monitor

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

Sztori:

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

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

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

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

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

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

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

http://www.wired.com/threatlevel/2010/09/stuxnet/ Sulinet: Atomenergia http://sdt.sulinet.hu/Player/Default.aspx?g=6617c1dd-f0aa-4d21-82a3- 93b849401066&cid=f3ba64b7-0cc1-4402-ad1b-5bc04a3f76af

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

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

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

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

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

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

Hatásmechanizmus:

When there is more at risk than just information – Langner

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

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

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

Microsoft Malware Protection Center: The Stuxnet Sting

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

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

MS10-061: Printer Spooler Vulnerability

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

F-secure: Stuxnet Questions and Answers

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

Wikipedia / Nulladik napi támadás

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

Wikipedia / Exploit

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

Hogyan védekezzünk:

Siemens forum / Joel Langill

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

Wikipedia / legkisebb jogosultság elve

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

Wikipedia / csoportházirend-objektumok

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

A Stuxnet és hatásai (első rész)

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.

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.

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.

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.

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 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 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é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.