A múlt hét szerdája óta nem kis izgalomban tartja a szakértőket, hogy a közelmúlt egyik legizgalmasabb biztonsági eseménye, a CrySyS Lab által felfedezett DuQu vírus vizsgálata során a Kaspersky Lab munkatársai egy „rejtélyes” kódrészletet találtak, amelynek értelmezése nem kis gondot okoz.

Az IT café is többször foglalkozott az új, a nagy ipari rendszereket fenyegető kártékony szoftverrel, a DuQunak elnevezett speciális programmal, mely rokona a világbotrányt kiváltó Stuxnetnek, és amelyet egy európai vállalatnál találtak meg. Mint megírtuk, bár az első komoly hivatalos közleményt a Symantec adta ki a DuQuról, de ez a híradás gyakorlatilag teljes mértékben a magyar kutatók nem szignált munkájára épült, így a felfedezés dicsősége magyar szakembereké, a BME-n működő CrySyS Lab munkatársaié, az ő eredményeik alapján indult meg a szélesebb körű vizsgálat.

E folyamat részeként a Kaspersky hivatalos blogján jelent meg egy közlemény, mely arról szól, hogy a malware egyik része, az irányító, a command-and-control szerverekkel kommunikáló kód egy eleme a szakemberek számára nem értelmezhető, az is felvetődött, hogy egy egyedi, a vírus számára kialakított nyelven íródott. A blogbejegyzés szerint ennek megfejtése közös munkát igényel, ezért is tették közzé kutatásuk eredményeit, hátha a nemzetközi közösségben akadnak jó ötletek.

Nagyításhoz klikk! a képre

Aleszandr Gosztyev, a Kaspersky vezető biztonsági szakértője azt írja egy másik helyen, hogy míg a DuQu egyéb részei a C++ nyelven íródtak és a Microsoft Visual C++ 2008-at használták hozzá compilernek, a szóban forgó kódrészletnél ez nem igaz. Gosztyev és munkatársai annyit már megállapítottak, hogy milyen egyéb nyelvek azok, amelyek szintén nem jöhetnek szóba, többek között sem az Objective C, sem a Java, sem a Python, sem az Ada, sem a Lua. A specifikus, külön e célra létrehozott nyelv mellett felmerült annak a lehetősége is, hogy esetleg egy olyan, igen szűk területen alkalmazott nyelvről van szó, melyet csak nagyon kevesen használnak.

Megkérdeztük a problémáról Bencsáth Boldizsárt, a felfedező CrySyS csapatának tagját is (aki egyébként február elején részt vett a Kaspersky Security Analyst Summit meghívásos konferenciáján is, amelyen 90 profi résztvevő közül ő nyerte meg a belső – crypto challenge – versenyt). Bencsáth Boldizsár elmondta, hogy a DuQu vizsgálata miatt folyamatosan kapcsolatban állnak a Kasperskyvel is, a nevezetes kódot már a bejegyzés megjelenése előtt ismerték. A szakember levelében megírja, hogy ők sem nagyon tudtak elboldogulni a kóddal:

„A struktúra valóban nagyon bonyolult a Duqu kódban, és mi a 10 napos analízisünk során nem is nagyon tudtunk részletekbe menni a kommunikációs modul kódjával. Egyértelműen bonyolítja az analízist az objektumorientált struktúra, de nekünk a laborban nincs elég tapasztalatunk, hogy megítéljük egy ilyen kódról, hogy nem a »szokásos« nyelvek valamelyikével készült. Ugyanakkor a Kaspersky esetén már nagy tapasztalatú és a top A/V cégek közé tartozó szereplőről van szó, tehát elég egyértelmű, hogy nemcsak valamilyen egyszerű félrenézésről van szó, hanem ezt a programmodult tényleg valami speciális rendszerben vagy módon készítették. Az is elképzelhető, hogy valami konverterrel alakították át C kódra valami másból, azért néz ki ilyen furán. Az analízis során természetesen a gépi kód látszik, tehát nem az a baj, hogy nem érthető, hogy mit csinál a program, de pusztán a gépi kódból sokkal nehezebb pontosan érteni a működését, ha nem ismert a programozási környezet. Könnyebb téveszteni, nehezebb felismerni esetleg fontos dolgokat, vagy sok idő megy el esetleg feleslegesen olyan dolgok vizsgálatával, amelyek a programozási környezet ismeretében triviálisak lennének.”

Majd általánosabban fogalmazva Bencsáth így folytatja: „A Duquban és a  Stuxnetben nemcsak az a fő különlegesség, hogy milyen technológiára épül és milyen bonyolult, hanem maga a tény, hogy milyen céllal fejlesztették ki, és hogy használták fel. Ennek megfelelően a technikai részletek azért fontosak, hogy jobban megérthető legyen a  támadás maga is, hogy jobban tudjunk minden apró részletet. Ezek rávilágíthatnak a támadók módszereire, ami pedig a hosszú távú védekezést segítheti. Másodlagosan pedig nyilván érdekes kérdés, hogy kik is készítették a kódot, és még ha a támadók esetleg soha nem is lesznek felderíthetők, de a technikai hozzáállásuk, tudásuk, módszertanuk igen, és ez is érdekes. Megtudni tehát azt, hogy a modult milyen programnyelven írták segíthet abban, hogy jobban megértsük magát a kódot, de túlmutat ezen. A Kaspersky cikkeiben a »mystery« (rejtély) kifejezés pont ezért nagyon találó. Nem arról van szó, hogy a vizsgált dolgok kitalálása, megfejtése nélkül valami óriási horderejű dolgot nem ismerünk meg, hanem olyan apró rejtélyekről van szó, amelyeket nem értünk, és amelyek megoldása közelebb visz az egész ügy megértéséhez.

Nagyításhoz klikk! a képre

Ilyen rejtélyből egyébként számos van még. Nem tudjuk, pontosan mit jelentenek a kódba ágyazott varázsszámok (0xAE, 36, dátumok, a Stuxnet esetén a myrtus és guave stringek, stb.). Nem tudjuk, hogy miért alkalmaztak egyes módszereket (XOR obfuscated formátumú fonttárolás a dropperben, .zdata tömörített szekció az LZO valamilyen módosításával, az egyik minta esetében pl. volt digitális aláírás a driveren, a többi minta esetén nem – miért?). Nem tudjuk pontosan, hogy miért CentOS szervereket használtak C&C szervernek stb.” – zárja kommentárját Bencsáth Boldizsár.

A „rejtélyes” kód feloldására egyébként nemrég egy triviális válasz is született, ugyanis (köszönet az információért Buheratornak) William Pitcock azt írta egy Twitter-bejegyzésben, hogy a Kaspersky munkatársainak ki kéne szabadulni a kábszer gőzéből („put the crackpipe down”), mivel a kérdéses programrész egyszerűen a Microsoft COM technológiájával készült.

Biztosat egyelőre még nem lehet mondani, folytatása következik.