Spouštíme exe soubory z paměti

Článek má za úkol popsat jednu z technik spouštění kódu bez nutnosti mít fyzicky uložený soubor na disku. Nadpis možná vypadá šíleně a čtenář předpokládá, že celý postup bude šílený. Rovnou však říkám: Není to žádná magie a tuto techniku by měl zvládnout po přečtení článku i programátor se základními znalostmi.

Co si má člověk představit pod pojmem spustit binárku bez nutnosti uložení na disk? Předně skutečnost, že nalézt místo uložení takového souboru je minimálně problematické, ne-li přímo nereálné (záleží na okolnostech), a že tady v tomto ohledu může antivirový program dostat silně za uši ;) (opet záleží na okolnostech).

Představme si následující situaci: Máme spuštěný Internet Explorer (zaměňte dle chuti za jakýkoliv váš oblíbený program). Ten se pokouší spustit cmd.exe (že by pokus o vykonání kódu?) nebo radši rundll32.exe (zřejmě potřebuje spustit nějaký kód v dané knihovně). V běžících procesech následně skutečně vidíte běžet aplikaci rundll32.exe, takže všechno je nejspíš v naprostém pořádku. OMYL! S pomocí injekce kódu do procesu Internet Explorer (teď pomiňme otázku, jak k tomu došlo) nás vykutálený podvodník donutil spustit aplikaci rundll32.exe, která ale byla ještě před spuštěním zaměněna za úplně jinou, pravděpodobně škodlivou, aplikaci. Možná někdo z vás bude protestovat: Vždyť mám firewall a proaktivní ochranu, takže si můžu ověřit, zda se skutečně spouští rundll32.exe. Něco podobného bych odhalil. Není tomu tak. Kód v Internet Exploreru v první fázi skutečně spouští aplikaci rundll32.exe z jejího klasického umístění (C:\WINDOWS\system32\rundll32.exe). Nejedná se o žádnou přejmenovanou binárku. Ani hijacking binárky(viz např. DLL hijacking).

A co se tedy vlastně skutečně stalo? Útočníkův kód vytváří nový proces rundll32.exe. Ten ale přímo nespouští, nýbrž ho udržuje v suspendnutém stavu. Teď příjde hlavní myšlenka celé techniky. Dál se totiž chová útočníkův kód jako zjednodušený Windows loader (čti zavaděč PE souborů do paměti). Loader si můžeme zjednodušeně představit jako recepčního v hotelu. Příjde host (binárka), jenž má údajně registraci pokoje. Recepční si ověří, zda skutečně tento člověk má platnou registraci (jedná se skutečně o PE soubor?). Pokud nemá, slušně jej odmítne (chybová hláška, že se nejedná o legitimní PE soubor). Pokud má, zjistí který pokoj má rezervován (umístění binárky v paměti). Dále se zeptá, zda má host zavazadla (případné další potřebné moduly, jako například DLL knihovny). Ověří, zda je pokoj připraven pro hosta (namapování sekcí PE souboru do paměti na příslušná místa) a odevzdá mu klíče od pokoje (spuštění procesu). V reálu probíhá při zavádění PE souboru do paměti daleko více pochodů. Od mapování Import Address Table až po vytvoření tabulky relokací. Pro naše účely ale bude bohatě stačit to, co jsme si popsali výše.

Základní věc, jenž musíme udělat, je načíst do paměti binárku, kterou budeme spouštět. Pro naše účely si vystačíme s klasickou kalkulačkou. Ale není problém binárku odněkud natáhnout (webová stránka, FTP atd.) do paměti. Pro práci se souborem musíme nejdřív tento otevřít. K tomu slouží na Windows funkce CreateFile.

Funkce vrací handle na otevřený soubor. Abychom mohli soubor umístit do paměti, musíme znát jeho velikost. K tomu využijeme funkci GetFileSize:

Za předpokladu, že se nám povedlo jak otevření souboru, tak zjištění jeho velikosti, můžeme přikročit k alokaci potřebného prostoru například pomocí funkce VirtualAlloc:

Na konec soubor zapíšeme do paměti. K těmto účelům se nejlépe hodí funkce ReadFile.

Nyní máme soubor v paměti a musíme zkontrolovat, zda se skutečně jedná o spustitelnou binárku. Portable Executable formát má pevně stanovený tvar. Prvním identifikátorem je tzv. DOS signatura uložená ve struktuře IMAGE_DOS_HEADER, jenž je čirou náhodou zcela na začáku souboru. Tato tzv. DOS hlavička je přežitek z dob operačního systému DOS a kromě prvku e_lfanew, což je offset začátku PE hlavičky, nemá význam se k ní dále vyjadřovat. DOS signatura má velikost 2 bajty (WORD) a musí obsahovat hodnotu 'MZ'(v paměti bude v obráceném pořadí, tedy 0x5A4D). Takže si deklarujeme pointer na strukturu typu IMAGE_DOS_HEADER a přetypujeme adresu na alokovanou paměť na tuto strukturu. Případně si vystačíme pouze s přetypováním (Poznámka: Občas není na škodu se type-castovému peklu vyhnout - člověk si ušetří hodiny hledání chyby). A zkontrolujeme, zda se v souboru nachází DOS signatura. Předpokládejme, že lpFileInMemory je adresa počátku paměti s již načteným souborem:

nebo

Přičteme tedy offset na PE hlavičku k adrese paměti, čímž získáme adresu začátku PE hlavičky. PE hlavička je tvořena stukturou IMAGE_NT_HEADERS a je složena z PE signatury a pointerů na dvě struktury (IMAGE_OPTIONAL_HEADER a IMAGE_FILE_HEADER). PE signatura má velikost 4 bajty (DWORD) a obsahuje hodnotu 'PE\0\0' (v paměti bude v obráceném pořadí, tedy 0x00004550).

nebo

Nyní, když jsme si ověřili, že se skutečně jedná o PE soubor, můžeme vytvořit nový proces v suspendovaném stavu. K tomuto účelu slouží funkce CreateProcess:

Potřebujeme získat kontextové informace (hodnoty registrů) z hlavního vlákna suspendovaného procesu. K tomu slouží funkce GetThreadContext:

Registr EBX ihned po vytvoření procesu ukazuje na strukturu PEB (Process Environment Block). Tato struktura slouží pro uchovávání systémových informací o procesu, ať už se jedná o seznamy naloadovaných modulů (hlavně DLL knihoven a samotné binárky), informace o tom, zda je proces debuggován, informace o heapu a tak podobně. Kromě jiného i informaci o ImageBaseAddress, což je adresa, na které začíná samotná binárka. Nyní máme dvě možnosti. Buď přepočítáme, zda se image obou procesů nekříží (pokud ano, odmapujeme binárku z paměti, pokud ne, necháme ji v paměti, protože nám nijak nevadí) nebo jednoduše vždy původní binárku z procesu odmapujeme. Zde bych volil druhou možnost, protože původní aplikaci nebudeme nijak využívat. K tomuto účelu využijeme funkci NtUnmapViewOfSection (druhé jméno funkce je ZwUnmapViewOfSection) z DLL knihovny ntdll.dll:

Pomocí funkce VirtualAllocEx v suspendovaném procesu alokujeme místo pro celý image, včetně hlaviček. Nevyužijeme k tomu ale velikost získanou pomocí funkce GetFileSize, ale hodnotu uloženou ve struktuře IMAGE_OPTIONAL_HEADER v poli SizeOfImage, protože ta obsahuje již hodnotu zaokrouhlenou na velikost SectionAligment ze struktury IMAGE_FILE_HEADER. Ukazatele na obě tyto struktury najdeme ve struktuře IMAGE_NT_HEADERS. Kompletní hlavičky zapíšeme do suspendovaného procesu. Jejich velikost je uvedena ve struktuře IMAGE_OPTIONAL_HEADER v poli SizeOfHeaders. Tato hodnota je zaokrouhlena na násobek hodnoty daný velikostí pole FileAlignment ve struktuře IMAGE_FILE_HEADER.

Nyní musíme zapsat do procesu to hlavní. Jednotlivé sekce PE souboru. V prvé řadě si musíme uvědomit, kam budeme tyto sekce zapisovat. Sekce následují hned za hlavičkami, takže stačí znát velikost hlaviček a k nim postupně přičítat velikost sekcí. Počet sekcí je uložen ve struktuře IMAGE_FILE_HEADER v poli NumberOfSections.

Na konec nám zbývají poslední tři úkony. První je nastavení hodnoty pole ImageBaseAddress ve struktuře PEB na adresu danou polem ImageBase ve struktuře IMAGE_OPTIONAL_HEADER.

Druhým úkonem je nastavení registru EAX v kontextu na hodnotu startovní adresy (tzv. Entry Pointu) tak, jak to je u nově vytvořeného procesu. Entry Point (EP) získáme součtem ImageBase ze struktury IMAGE_OPTIONAL_HEADER a AddressOfEntryPoint ze stejné struktury.

Nyní můžeme nastavit zpět kontext procesu pomocí funkce SetThreadContext:

Na závěr spustíme hlavní vlákno suspendnutého procesu pomocí funkce ResumeThread, čímž spustíme celý proces:

Pokud vše proběhlo v pořádku, měli bychom nyní vidět v běžících procesech proces rundll32.exe, avšak nahrazen binárkou calc.exe. Jak je z výše popsaného jasně patrné, nejedná se v žádném případě o nějakou černou magii nebo něco těžko pochopitelného. Stačí si jen uvědomit, jak celý proces výměny probíhá a následně jej realizovat. Na závěr přikládám ukázkový kód. Uživatel zadá cesty ke dvěma binárkám a program se postará o jejich spuštění.

Kalkulačka běžící v kontextu rundll32.exe

V některém z pozdějších článků se pokusím popsat pokročilejší techniku hojně využívanou jak malwarem, tak velkým počtem packerů a kompresorů.

Originální článek: http://bflow.security-portal.cz/spousteni-binarky-z-pameti-bez-nutnosti-ulozeni-na-disk/