V poslední době nic nerozčeřilo hladiny bezpečnosti tak, jako „chyba“ s názvem DLL hijacking. Slovo chyba jsem záměrně umístil do uvozovek, protože se z mého pohledu o chybu nejedná (na rozdíl od různých světově uznávaných expertů v čele s H.D. Moorem, kteří tento problém považují za system flaw).

Obsah:
——————————————
1. Obecné seznámení
2. Popis problému
3. Obecný příklad chyby a použitého kódu
4. Několik dalších scénářů
5. Odkazy
——————————————

1.Obecné seznámení
O co se tedy jedná? Někdo by čekal, že o něco převratného. Skutečnost je však jiná. Tato chyba je známá nejméně 18 let (prvně byla popsána na systému Solaris). O něco více se o chybě mluvilo v souvislosti s iTunes. Ten nahrával některé DLL knihovny se sdílených zdrojů. Možná již chápete, čeho přesně se problém týká. Ostatním problém osvětlím v zápětí. Hned na začátek zdůrazňuji : Tímto neduhem trpí absolutní většina současného softwaru na Windows (minimálně od Win 95). Avšak útočník bývá omezen právy daného systému, jež mu neumožňuje plnohodnotně pracovat s adresáři, do nichž byl daný program nainstalován. Ale ruku na srdce: Kolik lidí pracuje na systému s jiným účtem než administrátorským, a kolik lidí si všímá co skutečně povoluje/zakazuje? Aby toho nebylo málo, Microsoft vydal prohlášení, že nehodlá tento problém řešit. Vydal však rovněž obecná doporučení, jak těmto problémům předcházet.

2.Popis problému
DLL knihovny primárně slouží jako centrální zdroj funkcí, globálních proměnných, konstant atd., které bývají používány opakovaně s cílem vyhnout se nesmyslnému opisování stejného kódu pro každý program a z toho plynoucí jeho neúměrné zvětšování. Pokud tedy nějakou funkci/proměnnou/konstantu budeme opakovaně používat v různých programech, vložíme ji do DLL knihovny a v případě potřeby si tuto funkci zavoláme právě z této knihovny. Microsoft přišel s nápadem, aby se tyto knihovny, využité v programu, hledaly podle specifického pořadí:

1. Adresář, ze kterého je aplikace spouštěna.
2. Systémový adresář (klasicky C:\WINDOWS\system32\)
3. 16-bitová verze systémového adresáře (klasicky C:\WINDOWS\system\)
4. Adresář Windows (klasicky C:\WINDOWS\)
5. Aktuální adresář
6. Adresáře, které jsou umístěné v proměnné prostředí PATH

Problém však hledejme i jinde: I v hlavičkách PE souboru se absolutní cesty k těmto DLL knihovnám neuvádí. Nyní by již mělo být naprosto jasné, kde je kámen úrazu. Pokud totiž útočník použije svou vlastní knihovnu s názvem odpovídající skutečné knihovně a uloží ji co možná nejvýše v procházeném pořadí, tato knihovna bude nahrána do adresního prostoru místo té skutečné.

3. Obecný příklad chyby a použitého kódu
Máme program uložený v absolutní cestě C:\Program files\CleanApplication\cleanapplication.exe. Víme, že si tato aplikace během instalace kopíruje některé DLL knihovny do systémového adresáře (předpokládejme umístění jedné z knihoven v C:\WINDOWS\system32\CAfunc.dll). Pokud by nyní útočník vytvořil knihovnu se stejným názvem a uložil ji k binárce (C:\Program files\CleanApplication\CAfunc.dll), bude tato DLL knihovna načtena do adresního prostoru aplikace místo originálu. Jako testovací knihovnu jsem využil následující kód:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
#include <windows.h>
 
BOOL APIENTRY DllMain( HMODULE hModule,
                       DWORD  ul_reason_for_call,
                       LPVOID lpReserved
					 )
{
	switch (ul_reason_for_call)
	{
	case DLL_PROCESS_ATTACH:
		MessageBox(NULL, TEXT("This application is vulnerable!!"), TEXT("DLL hijacking"), MB_OK);
		break;
	case DLL_THREAD_ATTACH:
	case DLL_THREAD_DETACH:
	case DLL_PROCESS_DETACH:
		break;
	}
	return TRUE;
}

Jakmile je knihovna načtena do jmenného prostoru aplikace, vyskočí MessageBox s textem „This application is vulnerable!!“.

4. Několik dalších scénářů
Útočník upraví originální knihovnu a rozšíří ji o svůj vlastní kód. Tím předejde nechtěnému pádu aplikace a navíc dojde k vykonání jeho kódu (např. keylogging nebo otevření a naslouchání na daném portu).

Útočník vytvoří červa, který bude fungovat jako dropper. Dostane se do systému, zkopíruje knihovnu, rozešle se dál a svou lokální kopii odstraní. Uživatel pak vykoná kód sám tím, že spustí náchylnou aplikaci, aniž by tušil, kde se mu v systému daná knihovna vzala.

Potenciální hrozbou jsou hlavně soubory, využívající specifickou koncovku napadnutelného programu. Asi málokdo z nás si při každém otevírání RAR/ZIP/TAR archívů pomocí WinRARu/WinZIPu kontroluje, odkud jsou DLL knihovny, které využívají tyto aplikace, nahrávány (kde jsou uloženy).

5. Odkazy
https://www.microsoft.com/technet/security/advisory/2269637.mspx
http://msdn.microsoft.com/en-us/library/ms682586%28v=VS.85%29.aspx