středa 25. dubna 2012

CVE-2012-0158 Exploit v přírodě


Od minulého týdne jsme byli svědky mnoha speciálně vytvořené soubory využívání CVE-2012-0158 a zranitelnosti v MSCOMCTL.OCX v Microsoft Office a některých dalších produktů společnosti Microsoft. Toto zneužití může být provedena v různých formátech, včetně formátu RTF, Word a Excel souborů. Jsme již našli vytvořený RTF a Word soubory ve volné přírodě. V škodlivého RTF, je zranitelný OLE soubor s vestavěnými \ \ objocx objektu a značky.
Následující obrázek ukazuje příklad vytvořený soubor ve formátu RTF obsahující zranitelné OLE soubor. Můžete vidět podpis OLE souboru D0CF11E0. ...
Škodlivý RTF soubor
Po otevření vytvořený soubor s zranitelné aplikace, stejně jako v jiných souborech dokumentů využívají, vidíme nevinného souboru lodě jako návnadu, zatímco v pozadí, jsou instalovány trojské soubory. Zde jsou typické kroky instalace malwaru plynoucí z zranitelné aplikace, Word v tomto příkladu:
1. Vytvořený dokument se otevře aplikace Word procesu.
2. Zneužití této chyby spustí shell kódu v OLE souboru.
3. Shellcode nainstaluje Trojan (y) na oběti stroj. Obvykle je instalován Trojan v následující cestě:
% USERPROFILE% \ Local Settings \ Temp \ (jméno souboru). Exe
4. Shell kód spustit nový proces aplikace Word a otevře jako návnadu nevinného soubor dokumentu, vložené v dokumentu. Typicky návnada souboru klesl na:
% USERPROFILE% \ Local Settings \ Temp \ (jméno souboru). Doc
5. Shellcode ukončí Word proces, který otevřel vytvořený dokument.
Protože kroků 4 a 5, uvidí uživatelé Word ukončete a ihned obnovení s návnadou souboru. Vidíte-li tento příznak, obraťte se na správce systému.
Tyto dokumenty obvykle vyráběné dorazí jako e-mailových příloh. Uživatelé by měli vždy opatrní při otevírání nevyžádaných e-mailů. Dále doporučujeme instalaci nejnovější opravy, od Patch Tuesday dubnové. (Viz Věstník Microsoft pro více informací: http://technet.microsoft.com/en-us/security/bulletin/ms12-027~~HEAD=pobj )
McAfee zjistí tyto škodlivé soubory dokumentů, jako jsou:
  • Exploit-CVE2012-0158: Detection pro MS Office soubory, jako je MS Word a MS Excel
  • ! Exploit-CVE2012-0158 rtf: RTF soubory, které obsahují citlivé OLE kontejnery

Duqu FAQ


Aktualizováno dne 27. březen 2012 (Přejděte do dolní části)

Jedná se o aktivní vyšetřování Global Research společnosti Kaspersky Lab a Analysis Team. Budeme aktualizovat tento dokument dotazy podle potřeby.

Co přesně je Duqu? Jak je to souvisí s Stuxnet?

sledovat Ryan Naraine na twitteru
Duqu je sofistikovaný Trojan, který se zdá k byli napsáni stejnými lidmi, kteří vytvořili nechvalně známého červa Stuxnet. Jeho hlavním cílem je působit jako backdoor do systému a usnadní krádeže soukromých informací. To je hlavní rozdíl v porovnání s Stuxnet, který byl vytvořen k provádění průmyslové sabotáže.Je také důležité zdůraznit, že zatímco Stuxnet je schopen replikovat z jednoho počítače do druhého pomocí různých mechanismů, Duqu je Trojan, který nevypadá, že replikovat sama o sobě.

Má tohoto cíle by žádné PLC / SCADA zařízení? Přesně, kdo / co jsou cíle? Víme?

Na rozdíl od Stuxnet, Duqu se nezaměřuje na PLC / SCADA zařízení přímo, i když některé z jeho podprogramů může být použita k odcizení informací týkajících se průmyslových zařízení. Zdá se, že Duqu byl vytvořen za účelem sběru zpravodajských informací o jeho cílech, které mohou zahrnovat skoro vše, co je k dispozici v digitální podobě na počítači oběti.

Jak Duqu infikovat počítače? Může šířit prostřednictvím USB zařízení?

V případech jsme analyzovali, Duqu infikuje počítač prostřednictvím cíleného útoku zahrnující Word dokument, který užívá CVE-2011-3402 zranitelnost. To je 0-day zranitelnosti v jádře Win32k.sys součástí systému Windows, která umožňuje útočníkům spustit kód s nejvyšší úroveň oprávnění, obcházet skoro většina z ochranných mechanismů z Windows nebo bezpečnostního softwaru. Podle našich poznatků, Duqu je jediný malware pomocí této chyby zabezpečení se infikovat počítače. Všechny společnosti Kaspersky Lab bezpečnostní řešení odhalit tuto chybu zabezpečení, pod názvem Exploit.Win32.CVE-2011-3402.a z 6. listopadu 2011.

Existuje nějaký exploit, a to zejména zero-day v Duqu?

Tam je opravdu 0-day zranitelnost se používá k infikování počítačů v počáteční fázi. Společnost Microsoft vydala poradenství (2639658) se základními informacemi a zmírnění kroků .

Jak AV prodejci vědomi této hrozby? Kdo oznámil to?

Duqu byla upozorněna bezpečnostní komunity v maďarských CrySyS Research Lab . Oni byli první, kdo poukazují na podobnost s Stuxnet a provést to, co zůstává nejdůkladnější analýzu malwaru dosud.

Když byla tato hrozba poprvé spatřil?

První Duqu útoky byly spatřeny již v polovině dubna 2011. Útoky pokračovaly v následujících měsících až do 18. října, kdy byla zpráva o Duqu zveřejněny.

Kolik variant Duqu existují? Existují velké rozdíly ve variantách?

Zdá se, že existuje nejméně sedm variant řidičů Duqu, spolu s několika dalšími komponenty. To vše jsou detekovány s různými názvy od různých antivirových společností, vytváří dojem, že existuje několik různých variant. V době psaní tohoto článku, jsme si vědomi dvou Infostealer komponent a sedmi řidičů.Navíc máme podezření na existenci alespoň další Infostealer složky, která měla možnost přímo vyhledávat a krást dokumenty z oběti stroje.

Hovoří se, že to konkrétně zaměřuje na certifikační orgány . Je to pravda?

Zatímco tam jsou opravdu zprávy naznačující, že hlavním cílem je Duqu ukrást informace z CA, není tam žádný jasný důkaz v tomto okamžiku na podporu tohoto tvrzení. Naopak jsme přesvědčeni, že hlavním účelem Duqu byla jiná a CA byly jen vedlejší obětí.

Symantec tvrdí, toto je zaměřena na konkrétní organizace, případně s cílem shromáždit specifické informace, které by mohly být použity pro budoucí útoky. Jaké druhy dat jsou hledají a jaké budoucích útoků jsou možné?

Jedním z podezření, že byl použit Duqu ukrást certifikáty od certifikačních autorit, které mohou být použity k podpisu škodlivý kód, aby bylo těžší chytat. Funkčnost backdoor v Duqu je ve skutečnosti dosti složitý a může být použit pro mnohem víc. V podstatě to může ukrást všechno, ale vypadá to, že útočníci byli především zájem o sběr hesel, takže na ploše obrazovky (špehovat uživatele) a krást různé druhy dokumentů.

Je příkaz-a-Control Server používá Duqu stále aktivní? Co se stane, když nějaká infikovaný počítač kontakty C & C?

Počáteční Duqu C & C server, který moderoval v Indii již není aktivní. Stejně jako v případě Stuxnet, to bylo docela rychle vytáhl v režimu offline, jakmile novinky zlomil. Kromě toho jsme si vědomi další C & C serveru v Belgii, která byla také rychle offline. Vlastně se zdá, že každý Duqu cílený útok použít samostatný C & C server.

Proč je Duqu nakonfigurován pro spuštění na 36 dní?

Možná, že autor byl fanoušek kulatých čísel, jako je 6x6? :) Ve skutečnosti je doba, po kterou Duqu běží v systému definován v konfiguračním souboru a pohybuje se mezi útoky. Viděli jsme také případy, kdy byla doba stanovená na 30 dnů.

Kdo stojí za tímto útokem?

Stejný gang, který byl za Stuxnet. Kupodivu se zdá, že se zvedl zájem o astronomii, infostealer spustitelný soubor má část souboru JPEG zvedl o Hubble Space Telescope ("Interakce galaxie NGC 6745 System"):
Obrázek zachycuje následek přímé kolize dvou galaxií (!), Několik milionů let dříve. si můžete přečíst příběh zde .
UPDATE (15. listopadu 2011):

Otázka: Co přesně je ukraden z cílových počítačích?

Při aktivaci hlavní Duqu programu těla se připojí k jeho C & C serverem a stažení aktualizace a doplňkové moduly. Jeden takový modul je Duqu "infostealer," pro které jsou známy dvě verze a další jsou věřil k existovali v různých bodech v čase.
"Infostealer" modul je stažen do paměti a proveden prostřednictvím techniky procesu vstřikování používaného Stuxnet a Duqu, aby se zabránilo dočasné soubory. Toto je děláno s cílem zajistit, aby "infostealer" složka (a další Duqu aktualizace), nezachytí, nebo zanechali na infikovaný počítač. To také znamená, že mají omezenou životnost, v podstatě až do příštího restartu systému.
Nejsilnější verze "infostealer" má schopnost zachytit stisky kláves, to dělá screenshoty celé obrazovky (poprvé) a aktivního okna, sbírá IE historii procházení a různé údaje týkající se konfigurace systému sítě.K dispozici je také kód, který může dělat procházení sdílených položek v síti. Všechny tyto informace jsou pěkně zabalené do souboru, který je zapsán do složky TEMP%% ve výchozím nastavení. Je BZIP2 komprimovaný formát s modifikovanými záhlaví. Díky BZIP2 komprese, soubory jsou menší, než si myslíte.
Tyto "komponenty" infostealer jsme viděli vytvářet soubory s názvem "~ DQx.tmp". Kromě toho jsme si vědomi jiných souborů s názvem "souboru ~ DFxxxxx.tmp" a "~ DOxxxxx.tmp". "DF" a "DO" mají podobný formát a zdá se, byly získány od starší verze "infostealer". Oni také obsahují více informací, včetně různých souborů obětí PC, jako je Word nebo Excel dokumenty. V "~~~HEAD=NNS DF" soubory jsou obecně mnohem větší, vzhledem k jejich další obsah souborů.
Ve všech případech, které lze snadno rozeznat v záhlaví "ABh91AY & SY". Najdete-li takové soubory v počítači pak s největší pravděpodobností jste se stali obětí Duqu. Pokud chcete skenovat systém pro takové soubory, milí lidé v CrySyS mít sadu nástrojů , které mohou pomoci.

Otázka: Slyšel jsem, že Duqu a Stuxnet jsou psány stejnými lidmi. Také jsem slyšel, že Duqu a Stuxnet jsou psány různými lidmi. Jaká je pravda?

Duqu a Stuxnet mají spoustu věcí společných. Použití různých šifrovacích klíčů, včetně těch, které nebyly zveřejněny, před Duqu, vstřikovacích techniky, využití zero-day exploitu, využití odcizených certifikátů k podepisování ovladačů, to vše nás věří, jak bylo napsáno stejný tým.
Takže, co to přesně znamená? Jednoduše řečeno, různí lidé mohou pracovali na Duqu a Stuxnet, ale s největší pravděpodobností pracovali pro stejnou "nakladatelství." Pokud chcete analogii, Duqu a Stuxnet je jako Windows a Office. Oba jsou od společnosti Microsoft, i když různí lidé mohli na nich pracoval.

Otázka: Jaká je souvislost mezi Duqu a Showtime Dexter?

V incidentech jsme analyzovali, Duqu přijede do systému ve formě dokumentu aplikace Microsoft Word.Dokument obsahuje exploit pro zranitelnost známou jako CVE-2011-3402 . To je přetečení zásobníku v závislosti na Win32k.sys, které se týkají True Type fonty. Ke zneužití této konkrétní chyby, útočník potřebuje k řemeslu speciální True Type písmo a vložit ji do dokumentu, například dokumentu aplikace Word.
Nyní, na připojovací části - v incidentu jsme se analyzovat (a to platí i pro další známé události), útočníci použili písmo, pravděpodobně s názvem "Dexter Regular", a "Showtime Inc," (c) 2003 . To je další žert přitáhl autory Duqu, protože Showtime Inc kabelové vysílání společnost za televizním seriálu Dexter, o CSI lékař, který také se stane být sériový vrah, který pomstí zločinci v některých post-moderní zvrácenosti charakteru Charles Bronson je v Death Wish.

Otázka: Takže, Duqu autoři sociopat, sérioví vrazi, kteří mají zájem počítačového malware?

Doufáme, že oni jsou jen fanoušci Dexter.

Otázka: Stuxnet obsahuje konkrétní proměnnou, která ukazuje na 9. května 1979 , datum, kdy byl prominentní židovský obchodník tzv. Habib Elghanian popraven popravčí četou v Teheránu. Jsou tyto termíny v Duqu stejně?

Zajímavé je, že stejná konstanta se nachází v Duqu také. Maďarský CrySyS laboratoř byla první poukázat na využití 0xAE790509 v Duqu. V případě Stuxnet je číslo 0x19790509 použít jako infekce kontroly, v případě Duqu, konstanta je 0xAE790509.
Co je méně známo, že 0xAE790509 byl také použit v Stuxnet, ale před Duqu to nebyla zařazena do žádné z veřejných analýz jsme zvyklí.
Tam je také mnoho jiných míst, kde se používá konstantní 0xAE, a to jak v Duqu a Stuxnet.
Nakonec je konstanta 0xAE240682 používá Duqu jako součást dešifrování rutiny pro jeden z PNF známých souborů. V případě, že vás zajímá, 24. června 1982 je opravdu zajímavé datum - podívejte se na případ letu BA 9 .
* Výzkum společnosti Kaspersky Lab pro výzkum a Global Analysis Team.
Další literatura:
  • Část první . Spojení mezi Duqu a Stuxnet týden 20 říjen 2011
  • Část druhá . Jeden z prvních skutečných případů infekce se konala v Súdánu. 25 říjen 2011
  • Část třetí . Detekce hlavní chybějící článek - kapátko, které provedla počáteční systémové infekce.02.11.2011
  • Část čtvrtá: Zadejte pana B. Jasona a televizoru Dexter. Puzzle s fotkou NGC 6745 galaxie a televizním seriálu Dexter. 11.11.2011
  • Část pátá . Recenze komponentů Duqu je. 15.listopadu 2011
  • Část šestá . Zkoumá velení a řízení infrastruktury, kterou využívají Duqu. 30.listopadu 2011
  • Část sedmá . Stuxnet / Duqu: Vývoj ovladačů. 28.prosince 2011
  • Část osmá . Tajemství Duqu rámce
  • Devět částí . Tajemství Duqu rámce vyřešen
  • Část deset . Tajemství Duqu: Část Deset

  • Podcast

    Costin Raiu globálního výzkumu společnosti Kaspersky Lab a mluví Analysis Team o vyšetřování Duqu, pravděpodobnost, že to bylo napsáno ve stejném týmu jako Stuxnet, zda vláda je za jeho rozvoj a jaké chyby provedené autoři.
    Stáhněte si podcast z Threatpost webu.

    Tajemství Duqu rámce vyřešen


    Pátrání po identifikaci

    V mé předchozí blogpost o rámcové Duqu, jsem popsal jednu z největších zbývajících záhad asi Duqu - zvláštností C & C komunikačního modulu, který se zdá být napsána v jiném jazyce než zbytek kódu Duqu.Pokud jde o technické odborníky, jsme našli na tuto otázku velmi zajímavý a záhadný a my jsme chtěli sdílet s komunitou.
    Zpětnou vazbu jsme dostali předčil naše nejdivočejší očekávání. Máme více než 200 připomínek a 60 a více e-mailové zprávy s návrhy o možných jazycích a rámců, které by byly použity pro generování rámcového Duqu kód. Rádi bychom říci velký "Děkujeme!" všem, kteří se podíleli na této cestě, aby nám pomohli identifikovat záhadný kód.
    Podívejme nejoblíbenější návrhy jsme dostali od Vás:
    • Varianty LISPu
    • Dále
    • Erlang
    • Google Go
    • Delphi
    • OO C
    • Staré kompilátory pro C + + a dalších jazycích
    Díky některé velmi užitečné a znalý připomínky, můžeme nyní říci, s vysokým stupněm jistoty, že jsme našli správnou odpověď. Chtěl bych citovat nejdůležitější připomínky, které nám pomohlo vyřešit hádanku:
    igorsk Simple Object Orientace (pro C)

    Zdá se, že někdo po dobu reddit odst. http://www.reddit.com/r/ReverseEngineering/ ) jackpot: kód úryvky vypadají _very_ podobného, ​​co by to přinést: http:// daifukkat.su / wiki / index.php / SOO
    Existuje několik dalších OO rámce pro C, ale oni neodpovídají také: http://ooc-coding.sourceforge.net/ http://sooc.sourceforge. net /
    Jonwil Re: Ostatní C / C + +?

    Viděl jsem, jak GCC pracuje interně a jeho ABI (pro množství různých verzí), a mohu potvrdit, že kód Duqu rozhodně není generován GCC. Nevím, jak ostatní C + + kompilátory práce, ale věci, které vidím v ASM (např. kde se odkazy na funkce odejít, jak "to" ukazatel je předán atd.) nevyplývá, že C + + se mi, ale něco úplně jiného. (Jako výše uvedené "objektově orientované" rámců pro C, které existují)
    igorsk Re: Ostatní C / C + +?

    jsem 99% jistý, strojový kód byl vytvořen MSVC. Je to něco, co budete mít pocit, který má zkušenosti, ale mohu poukázat na dvě věci, které jsou zcela charakteristické pro MSVC: 1), které používá ESI jako první kandidát na dočasné uskladnění, 2) "pop ecx" místo "add esp, 4" .
    Také jsme obdrželi dvě velmi zajímavé e-mailové zprávy. Pascal Bertrand aka bps a další autor, který se raději zůstat v anonymitě navrhl, že kód byl generován z vlastní objektově orientované C dialekt, obecně zvané "OO C".
    Připomínky byly velmi důležité, protože nám umožnila sledovat přesnou kompilátor používaný v projektu: Microsoft Visual Studio kompilátoru. Jsem strávil více času experimentovat s různými verzemi překladačů MSVC a různých zdrojových kódů a kompilace možností se snaží reprodukovat binární kód konstruktoru funkce uvedené v předchozí blogpost a nakonec podařilo.

    Demontáž původního kódu Duqu: konstrukce spojené seznam třídy

    Ručně rozložit C kód, který má stejný kód
    Výše C kód, když sestaven s MSVC 2008 a možnosti / O1 (minimalizovat velikost) / OB1 (pouze rozšířit __ inline) vyrábí operační kódy shodné s těmi v binární Duqu. Změna pořadí operací a if / else bloky mění výsledný kód, MSVC 2005 kompilátor produkuje trochu jiný kód, taky. Takže lze říci, s vysokým stupněm jistoty, že výsledný binární byla sestavena s MSVC 2008 a možnosti / O1 / OB1 a vstupní zdrojový kód byl čistý C.
    Takže, co to znamená? Stručně řečeno, existují dva velmi pravděpodobné odpovědi na naši úvodní otázku:
    1. Kód byl psán používat vlastní OO C rámec založený na makra preprocesoru nebo vlastních směrnic.To bylo navrhl vaše komentáře, protože to je nejčastější způsob, jak zkombinovat objektově orientované programování s C.
    2. Všechny kód byl napsán v C OO ručně, bez rozšíření do jazyka. Nemůžeme popřít, tuto možnost úplně, protože technicky je téměř nemožné rozlišit kód psaný s makro směrnic z ručně kopírování vložený kód.
    Soudě podle množství podobně vypadající kódu v každém konstruktoru funkce a funkce členů, lze předpokládat, že zdrojový kód byl použit předzpracování a varianta 1 je blíže k pravdě.
    Nyní existuje několik open-source "OO C" rámce k dispozici, a některé z nich vyrábějí kódu staveb, které jsou velmi podobné těm, které v kódu Duqu. Nejlepší zápas jsme našli, je SOO (Simple Object Orientace pro C), ale to nemohlo být použity v Duqu, protože to bylo jen zveřejněn při Trojan už ve volné přírodě.
    Bez ohledu na to, která z těchto dvou variant je pravda, že důsledky jsou působivé. Užitečná knihovna obsahuje 95 kB na řízené událostmi kód napsaný s OO jazyka C, který nemá automatickou správu pamětí nebo bezpečné uvedeme. Tento druh programování je více obyčejně nachází v komplexu občanských států softwarových projektů, spíše než současný malware. Dále musí být celá akce řízené architektury byly vyvinuty jako součást kódu Duqu nebo jeho rozšíření OOC.
    Neexistuje žádná jednoduchá vysvětlení, proč byl OO C namísto C + +, ale jsme viděli podobné případy v minulosti. S mluvil s některými lidmi, kteří dávají přednost takové techniky, dali dva hlavní důvody:
    1. Oni nevěří C + + kompilátory, což jsou většinou lidé, kteří začali programovat v dávných dobách, kdy byl assembler nejlepší volba. C byla přímá evoluční krok po assembleru a rychle se stal standardem. Když C + + byla publikována, mnoho starých školních programátorů raději vyhýbat, protože nedůvěra v přidělování paměti a dalších temných jazykových prvků, které způsobují nepřímé provádění kódu (například konstruktéři).
    2. Extrémní přenositelnost. Ještě jednou, za starých časů (10-12 let) C + + není zcela standardizována a to bylo možné, aby C + + kód, který by se kompilovat MSVC ale nekompiluje se s (řekněme) Watcom C + +. Pokud byste chtěli jít na extrémní přenositelnost a zaměřit všechny stávající platformu venku, měli byste jít s C.
    Oba důvody se objeví uveďte kód byl napsán týmem zkušených, "staré školy" vývojářů.

    Závěry

    • Rámcová Duqu se skládá z "C" kód kompilován s MSVC 2008 pomocí speciální volby "/ O1" a "/" OB1
    • Kód byl pravděpodobně napsán s vlastní rozšíření C, obecně nazýván "OO C"
    • Event-driven architektury byl vyvinut jako součást rámce Duqu nebo jeho rozšíření OO C
    • C & C kód mohl být znovu z již existujícího softwarového projektu a je začleněn do trojan Duqu
    Všechny výše uvedené závěry ukazují spíše profesionální tým vývojářů, které se zdají být opětovné použití staršího kódu napsaný top "old school" vývojářů. Tyto techniky jsou běžně vidět v profesionální software a téměř nikdy v dnešní malware. Opět se jedná naznačují, že Duqu, stejně jako Stuxnet, je "jediná svého druhu" kus malware, který vyniká jako klenot z velkého množství "němý" škodlivého programu jsme normálně vidět.

    Tajemství Duqu rámce


    Zatímco analýzu složek Duqu , jsme objevili zajímavou anomálii v hlavní součást, která je odpovědná za jeho obchodní logiky a Payload DLL. Chtěli bychom se podělit o své poznatky a požádat o pomoc identifikační kód.

    Kód rozvržení

    Na první pohled vypadá jako Payload DLL pravidelně Windows PE souboru DLL kompilován s Microsoft Visual Studio 2008 (linker verze 9.0). Vstupní bod kód je naprosto standardní, a tam je jedna funkce vyváží pořadové číslo 1, která také vypadá jako MSVC + +. Tato funkce je volána z DLL PNF a to je vlastně "hlavní" funkce, která provádí veškeré logiky kontaktu s C & C serverů, obdrží další užitečné zatížení modulů a spuštění je. Nejzajímavější je, jak byla tato logika naprogramován a jaké nástroje byly používány.
    Kód část Payload DLL je společné pro binární, která byla provedena z několika kusů kódu. Skládá se z "řezy" kódu, které mohou být zpočátku sestavených v samostatném objektu soubory předtím, než byly spojeny v jediném DLL. Většina z nich lze nalézt v jakémkoli jazyce C + + programu, jako Standard Template Library (STL) funkce, run-time knihovna funkcí a uživatelsky literou zákona, s výjimkou Největší část, která obsahuje většinu z C & C interakce kód.

    Uspořádání kódu části Payload DLL souboru
    Tento řez se liší od ostatních, protože nebyl sestaven z C + + zdrojů. Neobsahuje žádné odkazy na jakékoliv úrovni, nebo uživatelsky napsaných C + + funkce, ale je rozhodně objektově orientovaný.Říkáme, že rámcová Duqu.

    Rámcová

    Funkce

    Kód, který implementuje rámec Duqu má několik charakteristické vlastnosti:
    • Vše je zabaleno do objektů
    • Funkce stůl je umístěn přímo do instance třídy a může být změněno po výstavbě
    • Neexistuje žádný rozdíl mezi užitkových tříd (spojené seznamy, hashe) a uživatelsky písemného kód
    • Objekty komunikují pomocí metody hovory, odložené spuštění fronty a událostmi řízené zpětných volání
    • Neexistují žádné odkazy na run-time knihovny funkcí, je nativní Windows API používá místo

    Objekty

    Všechny objekty jsou instance nějaké třídy, jsme identifikovali 60 tříd. Každý objekt je konstruován s "konstruktor" funkci, která alokuje paměť, vyplní v tabulce a inicializuje funkce členů.

    Funkce konstruktoru pro propojeného seznamu třídy.
    Uspořádání jednotlivých objektů závisí na jeho třídě. Některé třídy Zdá se, že binárně kompatibilní funkce tabulek, ale nic nenasvědčuje tomu, že mají nějaké společné nadřazené třídy (stejně jako v jiných jazycích OO). Kromě toho je umístění stolu funkce není pevně stanovena: některé třídy mají to na posunu 0 instance, ale některé ne.

    Uspořádání propojeného seznamu objektu. Prvních 10 pole jsou odkazy na členské funkce.
    Objekty jsou zničeny příslušných funkcí "destruktor". Tyto funkce obvykle zničí všechny objekty, které odkazuje členských polí a bez jakékoliv použité paměti.
    Členské funkce lze odkazovat pomocí objektu funkce stolu (stejně jako "virtuální" funkcí v C + +), nebo mohou volat přímo. Ve většině objektově orientovaných jazycích, členské funkce obdrží "to" parametr, který odkazuje na instanci objektu, a tam je volání konvence, která definuje umístění parametru - buď v registru nebo v zásobníku. To není případ rámcových tříd Duqu - mohou přijímat "to" parametr v každém rejstříku nebo v zásobníku.

    Člen funkce propojeného seznamu, dostane parametr "to" na zásobníku

    Událostmi řízené rámec

    Uspořádání a realizace objektů v rámci Duqu rozhodně není nativní C + +, který byl použit k naprogramování zbytek Trojana. Tam je ještě zajímavější vlastnost rámce, který je používán značně v průběhu celého kódu: je řízené událostmi.
    Existují speciální objekty, které implementují událost-řízený model:
    • Objekty událostí, založené na nativní Windows API rukojetí
    • Objekty závit souvislosti, které drží seznamy událostí a odložené exekučního fronty
    • Callback objekty, které jsou spojené s akcí
    • Událost monitory, vytvořené každým závitem kontextu pro monitorování událostí výkonných zpětné volání objekty
    • Závit souvislosti skladování spravuje seznam aktivních vláken a poskytuje přístup k za-závit kontext objektů
    Tato událost-řízený model se podobá Cíl C a jeho poselství procházející funkce, ale kód nemá žádné přímé odkazy na jazyk, ani to vypadá sestavují se známými cíle kompilátory C.

    Událostmi řízený model Duqu rámce
    Každý závit daný objekt může začít "hlavní smyčku", který hledá a zpracovává nové položky v seznamu.Většina kódu Duqu podle stejného principu: vytvořit objekt, svázat několik zpětná volání na vnitřní nebo vnější události a zpět. Zpětné volání rutiny jsou pak prováděny objektu události monitoru, který je vytvořen v rámci každé vlákno kontextu.
    Zde je příklad pseudokód pro socket objektu:
    SocketObjectConstructor {
        NativeSocket = socket ();
        SocketEvent = new MonitoredEvent (NativeSocket)
        SocketObjectCallback = new ObjectCallback (to, SocketEvent, OnCallbackFunc),
        connect (NativeSocket, ...);
    }
    {OnCallbackFunc
        switch (GetType (událost)) {
        případ Připojeno : ...
        případ ReadData: ...
    ...}
    }

    Závěry

    • Rámcová Duqu Zdá se, že byl napsán v neznámém programovacím jazyce.
    • Na rozdíl od zbytku těla Duqu, že to není C + + a to není zkompilován s Microsoft Visual C + + 2008.
    • Velmi událostmi architekturu body kódu, který byl navržen pro použití v docela hodně jakékoli podmínky, včetně asynchronních commutations.
    • Vzhledem k velikosti projektu Duqu, je možné, že jiný tým byl zodpovědný za rámec, než tým, který vytvořil ovladače a napsal systému infekci a využívá.
    • Tajemný programovací jazyk není rozhodně C + +, Objective C, Java, Python, Ada, Lua a mnoho dalších jazyků jsme zkontrolovali.
    • Ve srovnání s Stuxnet odst. celý napsán v MSVC + +), to je jeden z určujících zvláštnosti rámci Duqu.

    Duqu Framework: Co to bylo?

    Po provedení analýzy bezpočet hodin, jsme 100% přesvědčeni, že Duqu rámec nebyl naprogramován s Visual C + +. Je možné, že autoři používají in-house rámec pro generování kódu C zprostředkovatele, nebo použít jiný úplně jiný programovací jazyk.
    Chtěli bychom podat odvolání do programovacího komunity a zeptejte se někoho, kdo uznává rámec, toolkit nebo programovací jazyk, který může generovat kód podobné stavby, aby nás kontaktovat a napište nám komentář v tomto blogpost. Jsme přesvědčeni, že s Vaší pomocí můžeme vyřešit tuto záhadu hluboko v příběhu Duqu.