W ostatnich tygodniach szeroko dyskutowana jest nowa luka w zabezpieczeniach systemu Windows. Podatność zwana „Windows Binary Planting” lub „DLL Preloading Bug” pozwala na przeprowadzenie ataku na podatne aplikacje i w konsekwencji wykonanie spreparowanego kodu.
Omawiana luka w rzeczywistości nie jest luką w kontekście exploitacji oprogramowania, a raczej błędem projektowym, który można w zasadzie uznać za część funkcjonalności systemów Windows. Jest ona konsekwencją podejścia do ładowania bibliotek dołączanych dynamicznie (DLL) i, jako taka, jest znana już od dość dawna. Metoda nazywana Windows Binary Planting to po prostu nowy, pomysłowy sposób jej wykorzystania. Jest to metoda o olbrzymim potencjale dla potencjalnych napastników, przede wszystkim ze względu na duży zbiór podatnych aplikacji, których wersja jest w zasadzie bez znaczenia. O Windows Binary Planting pisał już w lutym pracownik Uniwersytetu Kalifornijskiego, Taeho Kwon, natomiast o innych metodach korzystania z luk w systemie ładowania bibliotek DLL (DLL spoofing) – m.in. polski specjalista ds bezpieczeństwa informacji Gynvael Coldwind (http://vexillium.org/?sec-dllsp).
Jak to działa?
Działanie metody Windows Binary Planting można przedstawić następująco. Kiedy działająca pod kontrolą systemu Windows aplikacja żąda załadowania biblioteki ładowanej dynamicznie (DLL), nie precyzując przy tym dokładnego jej położenia, rozpocznie się poszukiwanie jej (pliku DLL) w systemie plików. W Windowsie istnieje kilka miejsc, w których kolejno biblioteka będzie szukana: m.in. katalogi systemowe („C:Windowssystem32”, „C:Windowssystem”), elementy zmiennej środowiskowej PATH oraz, co najważniejsze, katalog który jest częścią kontekstu uruchomionej aplikacji. W przypadku wielu nowoczesnych aplikacji wspomniany katalog oznacza po prostu miejsce, w którym znajduje się przetwarzany przez aplikację plik, np. ładowany przez użytkownika film lub plik mp3. Jeśli dodatkowo aplikacja do swojego działania wymaga załadowania bibliotek, które nie znajdują się w katalogach systemowych (na przykład pluginów, bibliotek kodeków), można przewidywać, że uruchomiona aplikacja będzie szukać żądanej biblioteki w katalogu z ładowanym plikiem.
Aby przeprowadzić atak, napastnik umieści spreparowaną przez siebie bibliotekę zawierającą jego kod (spreparowany plik DLL) w katalogu z plikiem, np. na pendrive’ie, dysku DVD lub odległym dysku udostępnionym przez sieć. Użytkownik, który chcąc uruchomić plik, kliknie jego ikonę, tym samym uruchomi aplikację (np. odtwarzacza multimediów) w kontekście zawierającym lokalizację, w ktorej ten plik się znajduje.
Jeśli aplikacja zażąda załadowania biblioteki (np: niezbędnej do wyświetlenia otwieranego pliku), bardzo prawdopodobne, że w toku jej ładowania przeszukiwana będzie ta lokalizacja. W konsekwencji załadowana zostanie biblioteka spreparowana przez napastnika – tym samym przejmie on kontrolę nad wykonywanym przez aplikację kodem.
Lista podatnych aplikacji jest bardzo długa. Zajmująca się kwestiami bezpieczeństwa informacji firma Acros ujawniła, że w trakcie prowadzonego śledztwa utworzono listę ponad 200 podatnych aplikacji (http://www.computerworld.com/s/article/9180978/Zero_day_Windows_bug_problem_worse_than_first_thought_says_expert). Hdm na swoim blogu (http://blog.metasploit.com) opublikował narzędzie automatycznego audytu, która przeszukuje system w poszukiwaniu podatnych aplikacji i tworzy zestaw działających eksploitów. W trakcie badań prowadzonych w CERT Polska utorzone zostały działające eksploity m.in. na aplikacje: Wireshark, Language Pack Installer, Remote Desktop Conenction, MS Address Book, Windows Program Group Converter, program mstsc.exe, Media Player Classic – Home Cinema, DAEMON Tools Lite.
Co dalej?
Tak duża lista podatnych aplikacji jest konsekwencją błędów projektowych twórców systemu Windows, obecnie najpopularniejszego desktopowego systemu. Fakt, że podatność nie jest zwyczajnym błędem implementacji, a błędem w jej założeniach, powoduje że specjaliści z firmy Microsoft nie są w stanie go poprawić w drodze zwykłego patchowania systemu bez narażania na utratę kompatybilności jądra z resztą oprogramowania oraz inne niebezpieczeństwa. Bardzo podobnym przypadkiem była luka w projekcie protokołu TLS, którą opisano pod koniec 2009 roku. W tamtym przypadku lista podatnych aplikacji również zawierała dziesiątki, jeśli nie setki, podatnych aplikacji, a jej załatanie nie było możliwe przez opublikowanie zwyczajnego patch’a. Podkreślić należy, że za podatności poszczególnych aplikacji nie są odpowiedzialni jej twórcy, którzy nie mają wpływu na działanie wewnętrznych mechanizmów systemu Windows.
Jakie kroki należy podjąć, aby naprawić lukę? W zasadzie nie wiadomo do końca. Najbardziej prawdopodobnym rozwiązaniem będzie patchowanie każdej podatnej aplikacji oddzielnie, przez jej producenta. Firma Microsoft opublikowała informacje nt. luki wraz z narzędziem, którego można użyć, aby zmodyfikować sposób przeszukiwania systemu plików przy ładowaniu bibliotek.
