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.