Od pewnego czasu dużo mówi się na temat DLL Hijacking. Nie robi to na mnie większego wrażenia, bo nie jest to wcale nowa podatność, na potwierdzenie można podać ten wpis: DLL Preloading Attacks. Mam nawet wątpliwość, czy można nazwać podatnością coś, co jest udokumentowanym zachowaniem systemu: Dynamic-Link Library Search Order. Co więcej w Windows już od dłuższego czasu istnieje klucz SafeDllSearchMode, który zmienia kolejność wyszukiwania bibliotek. Domyślnie to (nie do końca) bezpieczne wyszukiwanie bibliotek DLL jest aktywne od Windows XP SP2. Nie sposób również nie wspomnieć o poprawce do systemu, która opisana jest w artykule A new CWDIllegalInDllSearch registry entry is available to control the DLL search path algorithm.
DLL Hijacking i CWDIllegalInDllSearch
Muszę przyznać się, że wykorzystywałem "podkładanie bibliotek" dawno, dawno temu, przy czym głównie w celu eskalacji uprawnień w systemie, więc scenariusz wykorzystania był nieco inny. Atak sprowadzał się do znalezienia takiego przypadku, w którym proces o wyższych od moich uprawnieniach ładował biblioteki DLL z miejsca, do którego ja, jako zwykły użytkownik, miałem prawo zapisu. Oczywiście możliwy był również wariant, w którym taką bombę podkładało się użytkownikowi o większych uprawnieniach w systemie. Wszystkie te scenariusze miały jedną cechę - były atakami lokalnymi. To, co w tym przypadku jest nowe, to możliwość wykorzystania specyfiki ładowania bibliotek w systemie Windows zdalnie.
Na temat DLL Preloading Bug sporo napisane jest na Niebezpieczniku, warto również przeczytać komentarze. Nie zgadzam się z tezą, że błąd nie zostanie poprawiony. Błąd JUŻ został poprawiony przez wprowadzenie CWDIllegalInDllSearch. Faktycznie, poprawka nie instaluje się automatycznie, zmianę do rejestru trzeba wprowadzić ręcznie. Nie zmienia to faktu, że istnieje skuteczny sposób zabezpieczenia się przed tym problemem.
Zadałem sobie nawet trud, by skuteczność poprawki zweryfikować. Rezultat można obejrzeć na poniższym krótkim filmiku (mój pierwszy):
Do demonstracji wykorzystałem Firefoxa oraz bibliotekę dwmapi.dll, którą przygotowałem z wykorzystaniem Metasploit. Jedynym zadaniem tej biblioteki jest uruchomienie cmd.exe.
W pierwszym przypadku wartość CWDIllegalInDllSearch jest ustawiona na 0. Zgodnie z oczekiwaniami kliknięcie na plik test.html powoduje poza uruchomieniem(!) Firefoxa uruchomienie cmd.exe. Podkreślam tu fakt uruchomienia Firefoxa dlatego, że gdy aplikacja ta już jest aktywna, exploit nie działa. Po prostu biblioteka ta jest już załadowana, Firefox nie musi więc ładować jej podstawionej kopii.
W drugiej części przykładu zmieniam wartość CWDIllegalInDllSearch na 0xFFFFFFFF co zgodnie z opisem powoduje usunięcie z listy przeszukiwanych katalogów bieżącego katalogu roboczego. W tym wypadku Firefox uruchamia się prawidłowo, a podłożona biblioteka nie jest ładowana, nie jest więc uruchamiany podłożony w niej kod. Proste i skuteczne.
Oczywiście takie ustawienie ma również swoje skutki uboczne. Pierwszy, na który trafiłem to problem z Chrome. Program nie może załadować biblioteki avutil-50.dll. Ciekawe kiedy pojawi się stosowna poprawka. Ciekawe też ile innych aplikacji znajdę, które takie problemy będą miały. Właśnie przez tak napisane aplikacje usunięcie części "błędów", zwłaszcza tych z bardzo długa brodą, bywa trudne.
