Jest jeszcze oczywiście klucz podstawowy - HKEY_CLASSES_ROOT, ale tak naprawdę jest on tworzony dynamicznie na podstawie wcześniej wskazanych kluczy. Jego obecność w rejestrze tłumaczy chęć zachowania przez Microsoft kompatybilności z aplikacjami 16-bitowymi. Zasada jest taka, że w HKLM są przechowywane wartości domyślne, klucz HKCU zawiera natomiast ustawienia specyficzne dla danego użytkownika. HKCU ma pierwszeństwo przed HKLM. Użytkownik może pisać sobie do HKCU co chce, byle nie miał praw zapisu do HKLM. No bo co się stanie, jeśli wirus zmodyfikuje w HKLM wpis dotyczący pliku exe? Próbkę takiej sytuacji dał słynny wirus Sircam. Jeżeli wirus nie będzie w stanie zmodyfikować kluczy HKLM, zmodyfikuje co najwyżej ustawienia HKCU. W najgorszym przypadku uniemożliwi pracę użytkownikowi, nie spowoduje jednak uszkodzenia całego systemu.

Tej ścieżce nie ufamy

Jedną z gorszych zmor systemów Windows jest fakt, że nie można w nich ustawić domyślnych praw na tworzone przez użytkownika pliki i katalogi. Zwykle prawa są dziedziczone z obiektów nadrzędnych lub też jest przyznawana pełna kontrola. W konsekwencji nowo tworzony plik może otrzymać przywilej Execute. Zdejmowanie uprawnień Execute dla wszystkich niepotrzebnych plików to działanie skazane na porażkę. Można to jednak zrobić dla kilku kluczowych ścieżek, w szczególności %temp% i ścieżki, w której przetrzymywane są tymczasowe pliki internetowe.

Zdjęcie prawa Execute z tych ścieżek przeciwdziała atakom polegającym na automatycznym uruchomieniu kodu, np. załącznika wiadomości e-mail czy pliku pobranego z Internetu. To one właśnie trafiają do katalogu tymczasowych plików internetowych, a czasem nawet do systemowego katalogu %temp%. Jeżeli dla nich obu wyłączymy prawa Execute, plik (potencjalny wirus) po prostu nie będzie mógł się uruchomić. Do zmiany statusu przywilejów Execute w systemach Windows XP i Windows Server 2003 można się posłużyć narzędziem Software Restriction Policy, które pozwala na kontrolę uruchamianych programów, na podstawie ścieżki, skrótu hash lub certyfikatu.

To wymyślone przeze mnie proste rozwiązanie jest nadzwyczaj skuteczne. Będę nieskromny i powiem, że zostało ono docenione m.in. na listach dyskusyjnych BugTraq, a nawet trafiło do biuletynu SANS Institiute. O gratulacjach nie zapomnieli spamerzy, zalewając mnie zaraz później ofertami powiększenia mi tego i owego we wszystkich chyba językach świata.

Zasada ograniczonego zaufania

Ciekawość to pierwszy stopień do piekła. Coś jest w tym powiedzeniu, bo czym innym wytłumaczyć fakt, że użytkownicy niejednokrotnie uruchamiają programy, którym, jak sami później przyznają, nie do końca ufali. W przypadku wykrycia u siebie natręctwa w postaci dwukrotnego klikania na wszystko, co nowe, należy zastosować kurację polegającą na włączeniu wspomnianej wyżej funkcji RunAs z opcją Restricted Token. W skrócie oznacza to, że na uruchamiany program będą nałożone dodatkowe ograniczenia. Dotychczas nie udało mi się co prawda znaleźć informacji, co tak naprawdę jest w takiej sytuacji wyłączane, ale z opisu w MSDN wynika, że możliwe jest:

• usunięcie szczególnych przywilejów użytkownika, co jest szczególnie ważne dla kont z dużą liczbą przypisanych przywilejów systemowych;

• oznaczenie danego procesu (SID) jako SE_GROUP_USE_FOR_DENY_ONLY, co oznacza, że przy sprawdzaniu uprawnień SID ten jest uwzględniany tylko przy odmowie dostępu, a nie jest brany pod uwagę przy przyznawaniu dostępu;

• stworzenie listy SID z ograniczeniami.

Mam nieodparte wrażenie, że Microsoft, myśląc o umiejscowieniu swoich systemów w sieci, lokuje je w sieciach dobrze zabezpieczonych, w których istnieje małe ryzyko pojawienia się kogoś złośliwego. Jak inaczej wytłumaczyć niezliczoną liczbę portów otwieranych bezpośrednio po instalacji systemu? NetBIOS, NetBT, RPC, UPnP - wszystkie te usługi i protokoły niosą potencjalne zagrożenie. Warto pamiętać, że UPnP może się poszczycić posiadaniem pierwszej krytycznej dziury w Windows XP. Ponieważ nie udało mi się dotąd wykorzystać tej usługi, wyłączam ją natychmiast po zakończeniu instalacji systemu.

Podobny los czeka NetBIOS, choć z powodów nieco innych. Mam to szczęście, że pracuję w sieciach wykorzystujących systemy Windows 2000 i nowsze, w związku z czym mogę oprzeć się na NetBT, które jest mniej "gadatliwe" niż stary NetBIOS, a przy okazji cechuje się lepszą wydajnością. Co prawda traci się wówczas ładne ikonki komputerów w otoczeniu sieciowym, na których można klikać, ale czego to nie poświęca się dla bezpieczeństwa...

Pod usługami NetBIOS i NetBT kryje się głównie udostępnianie plików i drukarek. Osoba niepowołana może próbować z jego wykorzystaniem uzyskać dostęp do zasobów systemu lub odgadnąć hasła poszczególnych użytkowników. Możliwe jest również zdalne zbieranie informacji na temat systemu, co ma znaczenie we wstępnych fazach ataków hakerskich. Ale nie tylko to. Część wirusów w celu rozpowszechniania swojego kodu stara się wykorzystać udostępnione w sieci zasoby.

Niejednokrotnie przy tej okazji są nawet wykonywane próby łamania haseł, a ponieważ wielu użytkowników używa haseł dziecinnie prostych, bywa że próby te kończą się powodzeniem.

Jeśli dodać do tego fakt, że systemy Windows domyślnie tworzą tzw. udziały administracyjne, udostępniając administratorom sieci wszystkie dyski i zawartość katalogu Windows (WINNT), to zagrożenie bezpieczeństwa systemu ze strony tej usługi staje się oczywiste. Na szczęście, usługę udostępniania plików i drukarek można wyłączyć na poszczególnych interfejsach. Można również wyłączyć funkcje automatycznego tworzenia udziałów administracyjnych.

Stosunkowo najwięcej problemów dotyczy RPC, ponieważ jest to usługa systemowa, bez której system nie chce działać prawidłowo. Oczywiście, problemem nie jest samo RPC, lecz to, że nie można usunąć obsługi RPC na tych interfejsach, na których jest nam niepotrzebna. Po drugie, usługa RPC działa w kontekście najbardziej uprzywilejowanego konta w systemie, jakakolwiek usterka w module RPC może więc zagrozić całemu systemowi, i to pomimo istnienia w nim dowolnych dodatkowych mechanizmów bezpieczeństwa.

Bez dodatkowych narzędzi system Windows zawsze ma otwarty port 135 i kilka portów o numerach powyżej 1024. Dopiero w nadchodzącym Service Pack 2 dla Windows XP Microsoft zawrze kilka poprawek, dzięki którym RPC staje się nieco bardziej bezpieczne. Przykładowo, możliwe będzie ograniczenie usług RPC do lokalnej podsieci. Do tego czasu warto wyłączyć interfejs DCOM wszędzie tam, gdzie nie jest on absolutnie niezbędny.

A zatem spójrzmy prawdzie w oczy. Bez dodatkowych zabiegów i narzędzi system Windows jest bezpieczny w sieci dopóty, dopóki nikt go nie atakuje. Gdyby jakość zabezpieczeń Windows oceniać na podstawie standardowych ustawień instalacyjnych, trzeba by dojść do wniosku, że jest to system, który nie może obejść się bez zewnętrznego wsparcia. Dostępu do sieci muszą więc strzec zapory firewall, poczty musi pilnować skaner antywirusowy, a nad tym wszystkim muszą czuwać wiecznie czujni, wykwalifikowani administratorzy. Niestety, mniejsze firmy o takim komforcie mogą tylko pomarzyć.

Paweł Goleń jest konsultantem ds. bezpieczeństwa w firmie CryptoTech w Krakowie.