Tweets by @buherablog
profile for buherator at IT Security Stack Exchange, Q&A for IT security professionals

A BitBetyár Blog

Túljártál a nagyokosok eszén? Küldd be a mutatványodat! (e-mail a buherator gmailkomra jöhet)

Full-Disclosure / Névjegy / Coming out


Promó

H.A.C.K.

Címkék

0day (110) adobe (87) adobe reader (21) anonymous (26) apple (60) az olvasó ír (49) blackhat (20) botnet (22) bug (200) buherablog (44) buhera sörözés (39) bukta (49) deface (38) dns (22) dos (29) esemény (82) facebook (26) firefox (64) flash (33) gondolat (31) google (59) google chrome (36) hacktivity (37) hírek (117) incidens (224) internet explorer (88) iphone (35) java (50) jog (22) kína (21) kriptográfia (68) kultúra (21) linux (24) malware (43) microsoft (142) móka (48) mozilla (23) office (26) oracle (40) os x (43) patch (197) php (20) politika (31) privacy (58) programozás (22) safari (34) sql injection (62) windows (85) xss (77) Címkefelhő

Licensz

Creative Commons Licenc

DuQu - Így rejtőzködnek napjaink virtuális fegyverei

2011.10.22. 15:02 | buherator | 11 komment

Az utóbbi napok elég izgalmasan teltek: mint kiderült, a világon elsőként a BME-n működő CrySys labor munkatársai észlelték és elemezték ki a Stuxnet utódjának tekintett DuQu trójait - nem kell kontógyárosnak lenni ahhoz, hogy feltételezzük, a kötvetkező virtuális ütközethez kis hazánkban keresett valaki információt, lenyúlható titkos kulcsot, rejtőzködésre alkalmas proxy-t, vagy ki tudja mi mást. 

Idő közben sikerült részletesebben átnéztem a Symantec által publikált elemzést (amely mellékletként az itthoni kollegák eredményeit is tartalmazza). Sajnos ez sem segített kikergetni a fülemből az Alexander Sotirov által oda helyezett bolhát: ha a biztonsági szoftverek gyártói - kompetenciájukról méltó tanúságot téve - ilyen szép elemzéseket képesek publikálni, miért nem kapták el a termékeik a kártevőt már településkor? Nézzük hát meg, milyen módszereket használ a DuQu a felismerés elkerüléséhez!

A leírtak az első felfedezett változatra érvényesek, a későbbi variánsok kisebb eltéréseket mutatnak.


(c) Symantec

A kártevő betöltéséért egy kernel driver ( amost tárgyalt esetben ez a jminet7.sys) felelős. Ez a driver titkosítva tartalmazza egy Registry kulcs nevét, valamint az ebben tartalmazott adatok megfejtéséhez szükséges titkosító kulcsot. Ezen paraméterek megfejtéséhez egy bedrótozott értéket használ. 

Megjegyzés: ilyen esetekben a titkosítás inkább obfuszkációt jelent, egyszerű algoritmusokat alkalmaznak, melyek lényege első sorban nem a kód megismerhetetlenségének biztosítása, hanem a mintaalapú felismerés megnehezítése.

Miután megvan, hogy hova kell nyúlni a Registry-ben, a driver ellenőrzi, hogy Safe Mode-ban, vagy debuggerben fut-e, bármely esetben megszakítja a futását (ez a viselkedés szintén a .SYS-be drótozott paraméterek segítségével ki/bekapcsolható).

A Registry adatai egy újabb titkosító kulcs mellett tartalmazzák a betöltendő DLL fájl nevét (ebben az esetben netp191.pnf), és annak a folyamatnak a nevét, ahová ezt a modult be kell majd tölteni. A DLL teljes egésze titkosított, kibontani az előbb Registryből nyert kulccsal lehet. A netp191.pnf egy RPC-t használó betöltő, és ez a komponens végzi a szoftver eltávolítását is a 36 napos élettartam (ez az érték egy titkosított konfigurációs fájlból származik) lejárta után.


(c) CrySys

A folyamat innentől egy matryoshka babára emlékeztet: A netp191.pnf a 302-es számú erőforrásban egy másik beágyazott, titkosított DLL-t tartalmaz, melynek .zdata szekciójában tömörítetten, speciális formátumban tárolódik egy újabb DLL, a C&C adatokat tartalmazó konfiguráció, és a 302-es DLL-hez hasonló újabb DLL (ez a tartalmazó DLL másolata, a .zdata szekció nélkül). 

A 302-es erőforrás négy féle képpen képes betölteni a .zdata-ban található modult: 

  • 0: Az ntdll.dll metódusainak hookolásával eléri, hogy be lehessen tölteni csak a memóriában létező, virtuális függvény-könyvtárakat. A módszert számos helyen használják, többek között a Meterpreter-ben is. Ez egy elég nehezen detektálható technika, remek összefoglaló olvasható a témában Skape tolmácsolásában
  • 1: Ebben az esetben a betöltő egy futtatható template állományt csomagol ki önmagából, amely képes betölteni egy DLL-t, majd meghívni annak egy exportált metódusát. 
  • 2: Hasonló az 1-eshez, de a betöltő először megpróbálja hagyományos API hívásokkal kiterjeszteni a jogosultságait
  • 3: Hasonló a 2-eshez, de egy meglévő processz nevét használja a template állomány kicsomagolásakor.

A betöltő a .zdata-ban található payload DLL-t tölti be, és átad neki egy, a kicsomagolt konfigurációs adatokra mutató pointert. A payload ezek után megkezdi a kommunikációt az abban megadott C&C szerverrel HTTPS illetve HTTP protokollt használva. A payload funkcionalitása alapvetően futtatható állományok letöltésére és indítására terjed ki. A kommunikáció úgy történik, hogy egy JPG kép (lásd az előző posztot) után csapják a fertőzött gépről kiküldeni szánt adatokat, AES-sel titkosítva, egy egyeztetett session kulcsot használva. 


 

Fontos látni, hogy a fent vázolt komponensek egymástól függetlenül működnek, egy betöltő gond nélkül lecserélhető a payload változtatása nélkül, és fordítva, a payload betöltése után pedig tetszőleges bináris futtatható az áldozat számítógépén. Mivel azonban a modulok egymásba ágyazottak, és titkosítottak (esetleg tömörítettek), a minta alapú felismerés akkor sem vezet eredményre, ha már ismert komponenseket hasznosítanak újra a támadók. 

Azt is meg kell jegyezünk ugyanakkor, hogy a fejlesztők által alkalmazott technikák egyáltalán nem ismeretlenek. Az eddigi elemzések lényegében két önvédelmi módszert tárták fel:

  1. A debugolás illetve a csökkentett mód detektálását
  2. Az ismert AV-k kilövésére tett kísérletet

Az első folyamat a kernel driver titkosítatlan részében zajlik, és bár legitim szoftverek esetében is elfogathatók lehetnek ezek a lépések, a heurisztika adhatna rá egy kisegyest. A második esettel kapcsolatban szintén felkeltheti a figyelmet, ha valaki tucatnyi biztonsági szoftver folyamatának létezésére kérdezget rá. Az NTDLL függvényeire rakott hookok szintén okot adhatnak gyanúra, az RWX memóriaterületek foglalása (az 1-3-as betöltők valószínűleg csinálnak ilyet) pedig ugyanúgy ki kellene hogy verje a biztosítékot. Kódemuláció elleni védelemről egyáltalán nem szólnak jelentések, de erre lehet hogy nem is lenne szükség, hiszen a DuQu kernel drivere majdnem megegyezik a Stuxnet azonos komponensével! 

Ha a C&C kommunikációt nézzük, már nehezebb az ügy, de hálózat-szintű védelemmel eleve nagyságrendekkel kevesebb helyen lehet találkozni, mint AV-val. Ennek ellenére elmondható, hogy sem a Stuxnet, sem a DuQu nem hozott radikális változást a rejtőzködési technikák frontján, ennek ellenére a tapasztalat azt mutatja, hogy az új csodatrójai felbukkanása ismét készületlenül érte a biztonsági szoftvereket. 

Címkék: malware trójai antivirus av heurisztika stuxnet duqu anti debug

Kommentek:

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

kutyacica 2011.10.22. 21:35:38

A duqu/stuxnet parhuzamot nem egeszen ertem. Utobbit ket dolog emelte ki a tobbi malware sample kozul amibol sokezerszam van naponta: egy rakat 0day es a fertozes utja (nem dbd hanem usb) + egy nem mindennapi programot tamado payload. Volt obfuscation ott is, de nem az tette kulonlegesse.

De a duqu eseteben nem olvastam se uj 0dayrol, se spec. payloadrol, olvastam viszont c&c szerverrol.

Azt irod nem kell conteo-gyarosnak lenni ahhoz, hovy az ember lassa az osszefuggest. Nekem nem egyertelmu.

Ezt ki tudod fejteni bovebben? Gondolom a symantec osszefoglaloban van errol sokkal bovebben de en nem olvastam azt el.

kutyacica 2011.10.23. 01:35:18

na vegigolvastam ezt a riportot.

azt eddig is ertettem hogy a hasonlosagbol kitunik hogy aki ezt a duqut irta, az ismerte a stuxnetet es felhasznalta az otleteit/reszeit.

amit nem ertettem, es most sem lettem okosabb, mitol egyertelmu, hogy a duqu szerzoje azonos es/vagy ismerte a stuxnet forraskodjat?

a crysys riportban ertekeznek arrol, hogy ez nem egyertelmuen megallapithato. egesz pontosan:

" At this point in time, we do not know more about their relationship, but we believe that the creator of Duqu had access to the source code of Stuxnet. [...] It is very hard to precisely characterize the similarities of the kernel driver codes of Duqu and
Stuxnet. [...] They are very similar, but there are clear differences. [...] it would be just mere speculation from us to say which code is originated from which code, or if one code is based on the reverse‐engineering of the other, or, at the end, it is also possible that someone wanted to write a Stuxnet‐alike clone and he/she wanted to us to believe that the authors have relations. "

a symantec ebbol mar csak annyit vett at: "The
threat was written by the same authors, or those that have access to the Stuxnet source code"

idovel persze gondolom kiderul majd tobb reszlet, aztan okosabbak leszunk. nem tudom elegge hangsulyozni: imho a crysys munka szuper, Levente nagyon franko labort vezet, orulok hogy a nemzetkozi figyelem kozeppontjaba kerultek es gratulacio nekik.

persze az is lehet, hogy a Symantecnek rakas mas informacio is rendelkezesre allt mielott ezt igy kijelentettek. Ezt izgalmas lenne tudni ketsegkivul, erre vonatkozott a kerdesem.

Meg egy dolog ami bosszantott egy kicsit a symantec, kaspersky iromanyokban. tobb helyen beszelnek arrol, hogy ezt vagy azt a fajlt mikor forditottak le. csak eppen a PE header informacio megbizhatatlan ennek a megallapitasara (d'oh), szoval ezek a datumok vagy igazak, vagy sem.

Hunger 2011.10.23. 04:20:08

"mint kiderült, a világon elsőként a BME-n működő CrySys labor munkatársai észlelték és elemezték ki a Stuxnet utódjának tekintett DuQu trójait"

azt lehet tudni, hogy hol észlelték? ;)

buherator · http://buhera.blog.hu 2011.10.23. 12:16:45

@kutyacica: A DuQu és a Stuxnet több helyen teljes bináris egyezést mutat, nagyon hasonlóak a "magic number"-k, a tömörített zdata szekcióban ugyanúgy vannak elhelyezve a fájlok, stb. Ebben a szakmában kifejezetten szeretnek kötözködni az emberek, de a két szoftver kapcsolatát most senki sem vitatja. Symantec anyagot ajánlom, keress rá a stuxnet szóra!

@Hunger: Nyilván nem :)

Hunger 2011.10.23. 16:03:49

@buherator: logikus, hogy valamelyik hazai CA volt a target, de vicces mekkora kuss van róla a médiában... ;)

kz71 2011.10.24. 14:24:40

self management...valaki beírhatott volna már Bruce bátyó blogjába is, hogy hunen van a név 8-)

www.schneier.com/blog/archives/2011/10/new_malware_duq.html

neTTudddkII

kutyacica 2011.10.24. 20:47:27

@buherator: ok koszi, de ez nem valaszolta meg a kerdesemet. Csak hogy megismeteljem, azt nem vitatom egyaltalan hogy a duqu a stuxneten alapszik. Arra keresem a valaszt, hogy mi igazolja, hogy a stuxnet forraskodjan alapszik.

Annak eldontese ket binaris alapjan hogy az egyik a masik patchelese vagy kodjanak ujraforditasa, szamomra egy nehez problemanak tunik, ezert lenyugoz a magabiztossag, amivel ezt a Symantec kijelenti.

Ezert aztan abban bizakodom, hogy valami olyan technikat alkalmaztak, amit en nem ismerek es most majd jol megismerek. En ilyesminek viszont a Symantec riportban nem talaltam nyomat. Mashol irtak errol?

buherator · http://buhera.blog.hu 2011.10.24. 21:17:55

@kutyacica:

Szerintem a válasz jórészt nem technikai. Egy igen nyomós érv lehet a minta származási helye, ami ugyan nem nyilvános, de biztos, hogy nem a sarki közértesnéninél találták. Szintén figyelemreméltó, hogy a támadók milyen gyorsan reagáltak a C&C szerver lelövésével és új változatok gyártásával (erről asszem Mikko Hypponen SecTor-os keynotejában volt szó, de nem tuti). Utóbbi tény ellene szól a patchelésnek, ugyanis elég nehéz rövid kiadási ciklusokat tartani, ha a binárisban turkál az ember.

Emellett ez a magyarázat egyszerűen sokkal valószínűbb, mint hogy valaki vette a fáradtságot, hogy visszafejtsen egy obfuszkált malware-t, módosította a binárisokat, megváltoztatva a kicsomagoló rutinokat is, frissítve a kilövendő AV-k listáját, majd az új algoritmusokat használva újracsomagolja a cuccot, kitesztelje, és eljuttassa valami fontos helyre. Ja, és mindezt rögtön két (három?) variánsra...

buherator · http://buhera.blog.hu 2011.10.25. 08:59:47

@kutyacica: Messze van az még, de persze jó lenne
süti beállítások módosítása