Obejście zabezpieczenia oszukując sygnalizację trybu test mode jest stosunkowo proste, przy czym użytkownik systemu Windows niekoniecznie musi odkryć, że jego system pracuje w tym trybie. Odczuwalną różnicą jest istotne spowolnienie pracy wideo w wysokiej rozdzielczości. Niemniej gdy atakowanym komputerem jest serwer, takie spowolnienie może przejść niezauważone. Niektóre pakiety badające spójność systemu Windows sygnalizują tryb test mode, ale przy kontroli sprawdzany jest jedynie ten sam mechanizm, który odpowiada za sygnalizację tego trybu na pulpicie - a został wyłączony przez malware.

Podstawienie podpisanego kodu

Najprostszym sposobem na przełamanie zabezpieczeń chroniących kernel mode, jest jednak przygotowanie oprogramowania, które będzie miało wbudowane opcje umożliwiające załadowanie obcego, niezaakceptowanego sterownika. Teoretycznie takie oprogramowanie nie powinno przejść procesu certyfikacji (takiego, jak przechodzą wszystkie sterowniki urządzeń), ale przy odpowiednim zagmatwaniu kodu, często udaje się przemycić stosowne opcje. Sama procedura związana z nadawaniem i odwoływaniem uprawnień i cyfrowych podpisów jest niestety nieszczelna.

Od SQL Injection do keyloggera w kernel mode

Na prezentacji zademonstrowano zdalny atak, który spowodował przejęcie kontroli nad systemem operacyjnym Windows Server 2008R2 w pełni zaktualizowanym, zainstalowanym jednak z typową niedbałością, polegającą na uruchomieniu bazy danych SQL Server na koncie z uprawnieniami administratora i otwarciu pewnych połączeń sieciowych. Do uzyskania dostępu do serwera bazodanowego posłużono się trywialnym błędem SQL Injection, obecnym w wielu aplikacjach webowych. SQL Injection otwiera swoisty kanał komunikacji między atakującym a serwerem bazodanowym. Tym kanałem nie można przesłać plików, ale z powodzeniem można utworzyć plik w systemie operacyjnym serwera bazodanowego i przesłać kod źródłowy aplikacji, która pobierze i zainstaluje eksploita.

Potem wystarczy skompilować i uruchomić powstałe narzędzia. Proces włamania przebiegał następująco:

1. Odnaleziono podatność SQL Injection w aplikacji webowej

2. Za pomocą SQL Injection włączono zaawansowane opcje SQL Servera (poleceniem configure show advanced options), by móc włączyć obsługę poleceń (xp_cmdshell).

3. Następnie przygotowano skrypt, który przekazano w tym kanale komunikacji i zapisano go do pliku

4. Ponieważ w systemie Windows Server 2008 pakiet .NET framework jest zainstalowany domyślnie, a serwer bazodanowy nie podlegał procedurom hardeningu (bardzo częsty błąd, polegający na utwardzaniu jedynie serwera WWW), w domyślnej ścieżce frameworku znajdował się kompilator csc. Ten kompilator został użyty do skompilowania kodu wykonywalnego, który pobrał plik atsiv z obcego serwera.

5. W założeniach polityki bezpieczeństwa zazwyczaj blokuje się połączenia FTP, poza tym klient FTP nie zawsze jest instalowany, nie zawsze będzie też działać połączenie wychodzące. To ograniczenie nie dotyczy połączeń HTTP i HTTPS, używanych na przykład przez aktualizację systemu Windows. Ten poważny błąd w założeniach polityki zezwalał na połączenia wychodzące z serwera bazodanowego na zewnątrz, co z kolei umożliwiło pobranie narzędzia atsiv, oraz biblioteki znanego keyloggera o nazwie striker.

6. Narzędzie atsiv zostało ono uruchomione (także przez polecenie przekazane w kanale utworzonym przez błąd SQL Injection), ładując przy tym strikera. Z nieznanych do dziś powodów, certyfikat dla pliku atsiv został odwołany jedynie dla systemów Windows Vista. W chwili demonstracji ataku, plik ten mógł być załadowany do kernel mode w systemach Windows Server 2008R2 i Windows 7.

7. Do uruchomienia niezbędne były uprawnienia administratora, ale instalacja motoru bazy danych była przeprowadzana nieuważnie i ten warunek był spełniony.

8. Po zainstalowaniu strikera, wyłączono obsługę poleceń systemu operacyjnego. Maszyna odtąd posiada zainstalowany niewidoczny keylogger pracujący w trybie kernel mode.

Skompromitowana w ten sposób maszyna znajduje się wewnątrz sieci korporacyjnej, zazwyczaj jest dołączona do domeny, przy każdych działaniach administrator loguje się na konto z uprawnieniami systemowymi do całej domeny Active Directory. W ten sposób przejęto kontrolę nad całą domeną, wykorzystując od strony Internetu jedynie jeden błąd aplikacji webowej oraz cały szereg błędów konfiguracji serwera bazodanowego Microsoft SQL Server. Należy przy tym pamiętać, że napastnik nie musiał kompromitować serwera WWW.

Więcej o Windows 7 na specjalnym serwisie Computerworld.