Utwardzanie konfiguracji systemów Windows

Konfigurowalne są elementy systemów operacyjnych takie jak:

• uwierzytelnianie i autoryzacja użytkowników (zwykłych i administratorów) oraz ich działań,
• systemu plików i uprawnień dostępu do danych,
• mechanizmy systemowe (urządzeń, sterowników, modułów, stos sieciowy, zabezpieczenia pamięci),
• usługi sieciowe (zdalny dostęp, wymiana danych itp.),
• zapora sieciowa,
• logowanie i audytowanie zdarzeń.

Luka w każdym z nich stwarza inne możliwości ataku. Niewłaściwa konfiguracja systemu pod kątem bezpieczeństwa może bardzo ułatwić atakującemu uzyskanie i podtrzymanie dostępu do maszyn i sieci. Analogicznie, w przypadku środowiska o utwardzonej konfiguracji, o wiele trudniej wykonać złośliwy kod, eskalować uprawnienia czy penetrować sieć.

Proces utwardzania konfiguracji systemów operacyjnych i ich komponentów nie wymaga wielkich nakładów pracy, wytyczne są publicznie dostępne i wyjaśnione (publikowane np. przez organizację Center for Internet Security czy Departament Obrony Stanów Zjednoczonych – wytyczne Security Technical Implementation Guide). Wdrożenie rekomendacji można zautomatyzować, wykorzystując np. mechanizm polityk grupy lub PowerShell Desired State Configuration dla systemów Windows i środowisk Active Directory czy narzędzia takie jak Ansible, Puppet, Chef i inne dla systemów z rodziny Linux.

Mimo wszystko spora część administratorów nie podejmuje się tego zadania. Często jest to podyktowane obawą przed zaburzeniem działania i funkcjonalności samych systemów bądź innych komponentów środowiska IT. Należy jednak mieć na uwadze, że różne opcje mają różny wpływ na funkcjonowanie i kompatybilność. Niektóre z nich mogą mieć negatywny wpływ na doświadczenia użytkowników bądź administratorów poprzez zwykłe utrudnienie codziennej pracy. Często wygoda wygrywa z bezpieczeństwem.

W tym artykule skupimy się na systemach Windows i przeanalizujemy wybrane opcje konfiguracji, rozważając ich wpływ na funkcjonalność i bezpieczeństwo. Za punkt odniesienia posłużą wytyczne opublikowane przez wymienioną wcześniej organizację Center for Internet Security – publikacja „CIS Microsoft Windows Server 2012 R2 Benchmark” – wersja 2.2.0 opublikowana 28 kwietnia 2016 r.

Zaczniemy od konfiguracji polityk haseł. W tej grupie znajduje się kilka opcji dotyczących wymagań stawianych przed użytkownikami w kwestii tworzonych i zmienianych przez nich haseł. Przede wszystkim konfigurowalne są wymagania dotyczące skomplikowania haseł oraz okresu ich ważności.

Minimalna długość hasła

Temat jest prosty – im dłuższe hasło, tym trudniej je odgadnąć bądź złamać. Każdy dodatkowy znak zwiększa liczbę możliwych haseł przynajmniej o jeden rząd wielkości (mowa o czystym ataku siłowym, bez wykorzystania słowników itp.). O ile przy atakach online jest sprawdzanych kilka typowych haseł (typu „Jesien2019”), to ataki offline, np. łamanie haszy NTLM czy NetNTLM (uwaga – całkiem różne hasze), nieraz umożliwiają sprawdzenie całej przestrzeni haseł. Pierwsza lepsza karta graficzna potrafi obliczyć ponad miliard haszy NTLM w ciągu sekundy, dedykowane rozwiązania chmurowe bądź klastry GPU zwiększają tę wartość o 2 rzędy wielkości.

Wymagania dot. złożoności haseł

Na nic długie hasła, jeżeli będą składały się np. z samych cyfr. Według systemu Windows złożone hasło to takie, które zawiera przynajmniej 3 znaki spośród 5 wymienionych grup:

• wielkie litery
• małe litery,
• cyfry,
• znaki specjalne,
• pozostałe znaki Unicode będące literami.

Należy zauważyć, że pierwsze dwie grupy zawierają zarówno standardowe litery alfabetu łacińskiego, jak i litery diakrytyzowane (np. polskie „ą”, „ę” itp.), litery greckie oraz litery cyrylicy (odpowiednio wielkie i małe).

Ponadto hasło jest sprawdzane pod kątem zbieżności z nazwą użytkownika. Hasło nie może posiadać ciągów znaków zawartych w nazwie konta („samAccountName”) i pełnej nazwie użytkownika („displayName”).

„Sprytny” użytkownik-pracownik zauważy, że hasło „NazwaFirmy1” albo wymienione wcześniej „Jesien2019” spełnia postawione mu przez system wymagania. Niestety, doskonale zdają sobie z tego sprawę atakujący. Dlatego dodatkowym zabezpieczeniem może być wdrożenie własnego filtra (np. porównującego nowo tworzone hasła ze zdefiniowaną czarną listą) w postaci biblioteki DLL – jest to jednak zaawansowane zadanie wymagające znajomości API systemu Windows (dokładniej: wymagane jest zaimplementowanie funkcji PSAM_PASSWORD_FILTER_ROUTINE” o odpowiedniej sygnaturze). Podobne możliwości oferuje usługa Azure Active Directory – mowa o mechanizmie „Password Protection”.

Naprawdę sprytny użytkownik stworzy hasło zawierające znaki specjalne, których nie ma na klawiaturze – można je wprowadzić np. za pomocą klawisza „ALT” i klawiatury numerycznej. Jednak istnieje ryzyko, że nie w każdym przypadku logowania będzie możliwe wprowadzenie hasła zawierającego takie znaki. Niemniej, takie rozwiązanie może zostać zarekomendowane administratorom systemów jako dodatkowe zabezpieczenie ich uprzywilejowanych kont domenowych.

Maksymalny okres ważności hasła

Zazwyczaj zaleca się, aby użytkownicy zmieniali swoje hasła co 3 miesiące. Uzasadnienie jest proste – w przypadku wycieku hasła bądź uzyskania do niego dostępu w jakikolwiek sposób przez osobę nieupoważnioną będzie ono funkcjonowało jedynie przez pewien czas. Jest to po prostu dodatkowa kontrola bezpieczeństwa w sytuacji kiedy kompromitacja poświadczeń użytkownika pozostanie nieodnotowana przez niego samego czy zespół bezpieczeństwa.

Jednak okres liczony w miesiącach często jest wystarczający dla atakującego do pełnego wykorzystania możliwości, jakie pojawiły się wraz z wejściem w posiadanie sekretu użytkownika. Co jeszcze ciekawsze, użytkownicy postawieni przed wymaganiem częstego zmieniania hasła po prostu idą na łatwiznę i tworzą hasła powtarzalne lub łatwe do zgadnięcia. Po raz kolejny bezpieczeństwo przegrywa z wygodą.

Między innymi z tych powodów niektórzy odchodzą od implementowania tego wymagania. W maju tego roku Microsoft opublikował kolejną wersję wytycznych bezpieczeństwa dla systemów Windows 10 i Windows Server („Security Baseline v1903”), w których oficjalnie porzucono wymagania dotyczące utraty ważności haseł.

Minimalny okres ważności hasła i historia haseł

Te dwie kontrole są ze sobą powiązane – mówiąc dokładniej, pierwsza jest pewnym uzupełnieniem drugiej.

Zakładając, że podjęto decyzję o ograniczeniu okresu ważności hasła, należy zapewnić, że hasło nie zostanie zmienione w najbliższym czasie na takie samo jak poprzednie. W przeciwnym wypadku wspomniane ograniczenie nie miałoby sensu. Dlatego też zaleca się, aby użytkownik nie mógł ponownie wykorzystać poprzednich haseł. Przy zmianie poświadczeń nowe hasło porównywane jest z poprzednimi (dokładniej: porównywane są hasze haseł) i odrzucane w przypadku gdy nie różni się od poprzednich. Zalecane jest pamiętanie przynajmniej 24 ostatnich haseł.

Część użytkowników może wykazać się przebiegłością i w przypadku wygaśnięcia hasła wykonać jego zmianę odpowiednią liczbę razy na dowolne, losowe ciągi znaków, aby ostatecznie ustawić z powrotem stare hasło. Właśnie takim sytuacjom zapobiega wymuszenie minimalnego okresu ważności haseł równego wynoszącego przynajmniej 1 dzień. Uniemożliwia to szybką „rotację” haseł w celu ominięcia wymagań stawianych przez historię haseł.

W sytuacji gdy określono minimalny okres ważności hasła, poświadczenia ustawione przez administratora, np. przy tworzeniu konta, pozostają ważne przez pewien czas. Często w takich sytuacjach hasła są zapisywane na papierze, przez co istnieje ryzyko, że uzyska do nich dostęp osoba nieupoważniona. Na szczęście istnieje możliwość wymuszenia zmiany hasła przy następnym logowaniu danego użytkownika – pozwala to ominąć omawiane wymaganie dotyczące czasu ważności hasła.

Przechowywanie haseł z wykorzystaniem odwracalnego szyfrowania

Przechowywanie haseł zaszyfrowanych znanym kluczem jest z punktu widzenia bezpieczeństwa równoważne przechowywaniu ich w formie jawnej. Idealnym przykładem są hasła przechowywane na kontrolerze domeny w plikach preferencji polityk grupy (GPP). Poświadczenia były tam bezpieczne, dopóki Microsoft nie upublicznił klucza wykorzystywanego do szyfrowania (używany jest algorytm AES).

Zupełnie oddzielnym zagadnieniem jest samo bezpieczeństwo haszy NTLM, w szczególności w kontekście uwierzytelniania za pomocą protokołu NTLM. Technika „pass-the-hash” w wielu przypadkach umożliwia wykorzystanie haszu NTLM hasła użytkownika do uwierzytelnienia się i uzyskania dostępu do zdalnych zasobów czy wykonania kodu.

Konta użytkowników mogą być blokowane po pewnej liczbie nieudanych prób zalogowania, w szczególności, gdy wystąpiły one w krótkim czasie. Taka sytuacja może świadczyć o przeprowadzanym ataku (np. siłowym lub słownikowym) na konta. Dokładna konfiguracja zasad blokowania kont w takich przypadkach ma na celu ułatwienie odróżnienia ataków od zwykłych pomyłek użytkowników przy wpisywaniu hasła.

Najważniejsze parametry związane z procesem blokowania kont to liczba nieudanych prób logowania, po której następuje zablokowanie konta oraz okno czasowe, określające, w jakim czasie takie zdarzenia muszą wystąpić, żeby zostały zakwalifikowane jako potencjalny atak, a nie pomyłka użytkownika. Dla dalszych rozważań przyjmijmy, że okno czasowe obserwacji wynosi 30 minut, a próg blokady to 5 nieudanych prób logowania.

Wiele osób nie rozumie dokładnie sposobu naliczania nieudanych prób logowania i blokowania kont na ich podstawie. Może się wydawać, że jeżeli w ciągu ostatnich 30 minut wystąpiło 5 nieudanych prób uwierzytelnienia (bez żadnego udanego logowania), konto zostanie zablokowane. W rzeczywistości działa to inaczej – dla każdego konta system przechowuje informację o liczbie nieudanych prób zalogowania („badPwdCount”) oraz o czasie ostatniej nieudanej próby („badPasswordTime”). W przypadku podania błędnego hasła system sprawdza, kiedy miała miejsce ostatnia nieudana próba logowania. Jeżeli było to wcześniej niż 30 minut temu, licznik nieudanych prób ustawiany jest na 1. W przeciwnym wypadku licznik jest inkrementowany. Licznik jest resetowany również po wprowadzeniu prawidłowego hasła. Jeżeli więc atakujący będzie podejmował nieudane próby odgadnięcia hasła użytkownika co 10 minut, zablokuje konto. Jeżeli natomiast wykona 4 nieudane próby jedna po drugiej, a następnie odczeka przynajmniej 30 minut, będzie mógł wykonać kolejne 4 próby bez ryzyka zablokowania konta.

W środowiskach posiadających więcej niż 1 kontroler domeny suma nieudanych prób logowania na wszystkich kontrolerach jest przechowywana przez emulator PDC. Emulator PDC posiada również informację o ostatniej nieudanej próbie zalogowania spośród wszystkich kontrolerów domeny i na tej podstawie decyduje, czy konto powinno zostać zablokowane. W związku z tym rozdzielenie prób logowania na kilka kontrolerów domeny nie ułatwia ataku.

Próg blokady

Próg blokady konta to liczba nieudanych prób logowania występujących w określonym okresie, która jest uznawana za próbę ataku i powoduje zablokowanie konta. Zalecane jest ustawienie wartości 10 lub mniejszej (oczywiście pomijając wartość 0, która oznacza, że konta nie są blokowane po nieudanych próbach uwierzytelnienia). Wartość nie może być zbyt mała, ponieważ należy założyć możliwość kilkukrotnej pomyłki użytkownika przy wpisywaniu hasła.

Okno obserwacji

Parametr określa, po jakim czasie licznik nieudanych prób logowania zostanie zresetowany. Im wartość jest większa, tym wolniej musiałby być przeprowadzany atak na konta użytkowników, ponieważ atakujący zachowywałby dłuższe odstępy pomiędzy kolejnymi próbami. Z drugiej strony zbyt długi okres zwiększa ryzyko zablokowania konta podczas normalnej pracy użytkownika. Zalecana wartość to przynajmniej 15 minut.

Czas blokady

Wartość ta określa czas, przez jaki konto pozostaje niedostępne po zablokowaniu na skutek wykonania zbyt dużej liczby nieudanych prób uwierzytelnienia w krótkim czasie. Zalecane jest ustawienie wartości większej bądź równej 15 minut. Zbyt krótki czas blokady ułatwia przeprowadzanie ataków, natomiast zbyt długi okres może utrudnić użytkownikom codzienną pracę. Zależnie od wielkości organizacji i szacowanego ryzyka ataków można rozważyć skonfigurowanie wartości „0”, która oznacza, że konta muszą zostać odblokowane ręcznie przez administratora. Z drugiej strony, zbyt długi okres blokady kont (w szczególności blokowanie kont na stałe z koniecznością interwencji administratora) stwarza ryzyko ataków typu DoS – złośliwa osoba mogłaby celowo blokować konta, aby utrudnić użytkownikom uzyskanie dostępu do zasobów, a także dodać pracy administratorom.

Wytyczne CIS dla systemów Windows zawierają szereg rekomendacji dotyczących przypisywania kontom (zarówno użytkowników, jak i systemowym) poszczególnych przywilejów. W tym miejscu należy wprowadzić rozróżnienie pomiędzy przywilejami a uprawnieniami. Przywileje są cechą poszczególnych kont, dają im uprawnienia do wykonywania różnych operacji systemowych. Uprawnienia są natomiast cechą obiektów (zwanych securable objects) posiadających tzw. deskryptor bezpieczeństwa (np. pliki, katalogi, klucze rejestru, a także procesy, wątki i inne).

Należy pamiętać, że część z przywilejów jest wymagana przez pewne aplikacje/komponenty do poprawnego funkcjonowania, dlatego wdrożenie rekomendacji utwardzających konfigurację systemu w zakresie przywilejów przypisanych poszczególnym użytkownikom powinno zostać wcześniej przeanalizowane bądź odpowiednio przetestowane. W przypadku gdy aplikacja wymagająca wrażliwych przywilejów uruchomiona jest w kontekście dedykowanego konta, któremu nadano odpowiednie przywileje, warto rozważyć możliwość jej uruchomienia w kontekście systemowych kont lokalnych (np. „Local Service” albo „Network Service”).

Poniżej omówione zostaną wybrane przywileje – jakie działania w systemie umożliwią ich posiadanie oraz jak mogą zostać wykorzystane w złośliwych celach. Zasadniczo nadmiarowe przywileje mogą zostać użyte do podniesienia uprawnień z poziomu administratora (high integrity level) do poziomu systemu (system integrity level), co i tak jest możliwe do wykonania innymi sposobami (np. technika named pipe impersonation). Część przywilejów umożliwia jednak eskalowanie z poziomu użytkownika niebędącego administratorem do poziomu systemu. W tym miejscu należy również nadmienić, że token użytkownika związany z kontekstem nieadministracyjnym (medium integrity level) nie posiada wszystkich przywilejów przypisanych do danego konta – są one odbierane przez UAC.

Działanie jako część systemu operacyjnego

Przywilej „SeTcbPrivilege” umożliwia tworzenie nowych tokenów i personifikację dowolnych użytkowników. Posiadanie tego przywileju daje większe możliwości podczas wywoływania funkcji Windows API związanych z logowaniem i operacjami na tokenach, w szczególności pozwala wywołać funkcję „LsaRegisterLogonProcess” i uzyskać uprzywilejowany dostęp do usługi LSA, co następnie daje możliwość szerszej manipulacji tokenami za pomocą funkcji „LsaLogonUser”. Inną możliwością pojawiającą się wraz z uzyskaniem omawianego przywileju jest wykorzystanie funkcji „AcquireCredentialsHandle” do pozyskania poświadczeń dowolnego użytkownika lub funkcji „WTSQueryUserToken” do uzyskania tokenu wskazanego zalogowanego użytkownika. Wykorzystanie przywileju „SeTcbPrivilege” umożliwia podniesienie uprawnień do najwyższego poziomu („system”) lub personifikację dowolnego użytkownika.

Dostęp do komputera z sieci

Przywilej „SeNetworkLogonRight” umożliwia użytkownikom nawiązywanie połączeń sieciowych z daną maszyną. Mowa w szczególności o komunikacji z wykorzystaniem protokołów opartych na SMB, NetBIOS, CIFS, COM+. Posiadanie przywileju umożliwia zatem zdalny dostęp do zasobów na komputerze oraz w szczególnych przypadkach zdalne wykonanie kodu. Odebranie przywileju użytkownikom pozwala utrudnić atakującemu poziomą eskalację i przejmowanie kolejnych maszyn w sieci (technika lateral movement), np. po zdobyciu poświadczeń użytkownika o podwyższonych uprawnieniach.

Dodawanie stacji roboczych do domeny

Przywilej „SeMachineAccountPrivilege” umożliwia użytkownikom dodawanie maszyn (maksymalnie 10) do domeny. Osoba posiadająca taki przywilej mogłaby dodać nowy komputer (do którego ma pełny dostęp) do domeny, a co za tym idzie, ominąć ewentualne restrykcje zabraniające użytkownikom posiadania dostępu administracyjnego do swoich stacji roboczych.

Należy zauważyć, że użytkownicy mogą posiadać uprawnienie dodawania nowych komputerów do jednostek organizacyjnych w domenie – w takim przypadku nie jest wymagany przywilej „SeMachineAccountPrivilege”. Właścicielem komputerów (rozumianych jako obiekty w domenie) utworzonych przez takich użytkowników są oni sami. Natomiast właścicielem kont maszyn utworzonych z wykorzystaniem omawianego przywileju pozostają administratorzy domeny.

W przypadku gdy użytkownik posiada przywileje pozwalające mu na sprawowanie kontroli nad obiektami komputerów w domenie, istnieje możliwość wykonania ataku wykorzystującego ograniczone delegowanie protokołu Kerberos oparte na zasobach (Kerberos resource-based Constrained Delegation). Atak polega na utworzeniu nowego komputera (jako wirtualnego obiektu w domenie), a następnie skonfigurowaniu istniejącej maszyny w taki sposób, aby akceptowała personifikację dowolnego konta domenowego przez nowo utworzony komputer – np. administratora domeny – co pozwala na efektywne przejęcie każdej maszyny, nad którą atakujący posiada kontrolę (w kontekście obiektu domenowego ją reprezentującego).

Logowanie lokalne

Przywilej „SeInteractiveLogonRight” umożliwia użytkownikom logowanie interaktywne (w szczególności lokalne, o którym mówi nazwa kontroli), tzn. utworzenie sesji logowania związanej z interaktywnym dostępem, np. poprzez fizyczne zalogowanie lokalne, dostęp za pomocą zdalnego pulpitu, powłoki itp. Przywilej jest wymagany podczas logowania użytkownika za pomocą funkcji „LogonUserEx” i „LogonUserExEx” – aby uzyskać token związany z logowaniem interaktywnym (flaga „LOGON32_LOGON_INTERACTIVE”).

Posiadanie przywileju umożliwia zatem zdalne wykonanie kodu na maszynie. Odebranie przywileju użytkownikom pozwala utrudnić atakującemu poziomą eskalację i przejmowanie kolejnych maszyn w sieci (technika lateral movement), np. po zdobyciu poświadczeń użytkownika o podwyższonych uprawnieniach. Uwaga: w przypadku gdy użytkownik nie posiada omawianego przywileju, ale posiada przywilej umożliwiający logowanie przy użyciu zdalnego pulpitu (omówiony poniżej), nadal może zalogować się zdalnie do komputera.

Logowanie za pomocą usługi Zdalnego Pulpitu

Przywilej „SeRemoteInteractiveLogonRight” umożliwia użytkownikom zdalne logowanie. Posiadanie przywileju umożliwia zatem zdalne wykonanie kodu na maszynie. Odebranie przywileju użytkownikom pozwala utrudnić atakującemu poziomą eskalację i przejmowanie kolejnych maszyn w sieci (technika lateral movement), np. po zdobyciu poświadczeń użytkownika o podwyższonych uprawnieniach.

Tworzenie kopii zapasowej oraz przywracanie plików i katalogów

Przywileje „SeBackupPrivilege” i „SeRestorePrivilege” umożliwiają użytkownikom tworzenie kopii zapasowych i przywracanie danych z pominięciem istniejących restrykcji dostępu do plików i katalogów. Posiadanie tych przywilejów daje dodatkowe możliwości podczas wywoływania funkcji Windows API służących do uzyskiwania dostępu i zapisywania danych, np. umożliwia tworzenie i odczytywanie danych za pomocą funkcji „CreateFile” z flagą „FILE_FLAG_BACKUP_SEMANTICS” pozwalającą ominąć sprawdzanie uprawnień (list kontroli dostępu – DACL). Przywileje umożliwiają również wykorzystanie funkcji „RegSaveKey”, „RegLoadKey”, „RegRestoreKey” i innych, których wywołanie nie jest możliwe w przeciwnym wypadku.

Przywilej „SeBackupPrivilege” jest równoważny z bezpośrednim dostępem do całego dysku komputera, natomiast przywilej „SeRestorePrivilege” jest równoważny z możliwością zapisu dowolnego pliku i w dowolnym katalogu.

Przywileje mogą zostać wykorzystane do ataków polegających na podmianie chronionych plików, np. plików wykonywalnych przypisanych do poszczególnych usług (umożliwia to prostą eskalację uprawnień) czy konfiguracji zainstalowanych aplikacji. Możliwość odczytania dowolnych chronionych danych pozwala pozyskać hasze haseł kont lokalnych (oraz domenowych – MS-CACHE), co może również pomóc eskalować uprawnienia na maszynie, a czasami nawet zdobyć dostęp do innych komputerów. Modyfikowanie wartości w rejestrze niesie dodatkowe możliwości podniesienia uprawnień bądź pozostawienia tylnej furtki w systemie (np. przekonfigurowanie usług, dodanie aplikacji lub skryptu uruchamiającego się wraz ze startem systemu, wykorzystanie opcji „Image File Execution Options”).

Dokładne określenie użytkowników uprawnionych do tworzenia i przywracania kopii zapasowych jest możliwe poprzez dodanie ich do grupy „Operatorzy kopii zapasowych”. Grupa ta ma domyślnie przypisane omawiane przywileje.

Zmiana czasu systemowego i strefy czasowej

Przywilej „SeSystemtimePrivilege” umożliwia ustawienie daty i godziny w systemie. Jest on wymagany do użycia funkcji „SetSystemTime”, „SetLocalTime”, „SetSystemTimeAdjustmentPrecise”. Natomiast przywilej „SeTimeZonePrivilege” umożliwia zmianę strefy czasowej i jest wymagany przy wywoływaniu funkcji „SetTimeZoneInformation”.

Możliwość zmiany czasu systemowego może zostać wykorzystana przez atakującego np. do manipulacji wpisami w dzienniku zdarzeń, co w rezultacie może uniemożliwić dokładną analizę akcji, które zostały wykonane na maszynie.

Ponadto, ustawienie niewłaściwego czasu na komputerze (różniącego się od skonfigurowanego na kontrolerze domeny) może spowodować problemy z uwierzytelnianiem za pomocą protokołu Kerberos (niezgodność stempli czasowych na biletach) lub z synchronizacją polityki grupy. Maksymalna tolerowalna różnica czasu dla protokołu Kerberos jest konfigurowalna za pomocą polityk grupy (zalecana wartość to 5 minut).

Możliwość zmiany strefy czasowej nie ma wpływu na powyższe, ponieważ nie ma wpływu na czas systemowy. W związku z tym możliwość ta może zostać przydzielona użytkownikom (gdy np. często podróżują i pracują w różnych strefach czasowych).

Tworzenie obiektu tokenu

Przywilej „SeCreateTokenPrivilege” umożliwia użytkownikowi tworzenie dowolnych tokenów za pomocą funkcji „NtCreateToken”. Posiadanie przywileju jest równoważne z dostępem na poziomie „system”. Umożliwia to dokonywanie dowolnych operacji na systemie operacyjnym oraz personifikację dowolnego użytkownika. Funkcja „NtCreateToken” nie została udokumentowana przez Microsoft, niemniej w Internecie można znaleźć informacje o jej wykorzystaniu.

W większości przypadków przywilej nie będzie potrzebny żadnemu użytkownikowi. Jeżeli np. aplikacja czy usługa wymagałaby tego przywileju, należy zdecydowanie rozważyć uruchomienie jej z wykorzystaniem lokalnego konta systemowego. Można wręcz powiedzieć, że aplikacja wymagająca tego przywileju jest podejrzana, ponieważ są inne metody personifikacji użytkowników – bardziej „legalne” niż używanie nieudokumentowanych funkcji systemu. Można zrozumieć, że np. proces „lsass.exe” (będący lokalnym zarządcą bezpieczeństwa systemu) potrzebuje tego przywileju, aby móc wykonywać niskopoziomowe operacje na tokenach. Niemniej, zgodnie z rekomendacjami, przywilej nie powinien zostać przydzielony żadnemu użytkownikowi, nawet kontom systemowym.

Tworzenie obiektów globalnych

Przywilej „SeCreateGlobalPrivilege” umożliwia użytkownikom tworzenie obiektów globalnych, tzn. nieprzypisanych do żadnej sesji użytkownika i dostępnych z poziomu wszystkich sesji, procesów i wątków. Przywilej wykorzystywany jest przede wszystkim przez usługę Zdalnego Pulpitu. W związku z tym, konta będące członkami grupy do grupy „Użytkownicy pulpitu zdalnego” posiadają ten przywilej.

Sama funkcja „CreateFileMapping” (i pokrewne) jest często wykorzystywana przez złośliwe oprogramowanie do uzyskiwania dostępu do danych znajdujących się na dysku oraz uruchamiania plików wykonywalnych (np. poprzez wstrzykiwanie kodu) po uprzedniej modyfikacji nagłówków PE w pamięci (po załadowaniu pliku z dysku). Jednak jest to działanie zazwyczaj niezwiązane z omawianym przywilejem, gdyż odbywa się ono najczęściej w przestrzeni nazw związanej z sesją danego użytkownika.

Tworzenie linków symbolicznych

Przywilej „SeCreateSymbolicLinkPrivilege” umożliwia użytkownikom tworzenie symbolicznym odnośników do plików i katalogów.

Możliwość tworzenia linków symbolicznych w systemie plików NTFS pojawiła się w systemie Windows w wersji Vista. Celem ich implementacji było poszerzenie wsparcia dla migracji z systemów uniksowych oraz zwiększenie kompatybilności aplikacji z systemami z tej rodziny (dla ułatwienia tworzenia aplikacji wieloplatformowych). Jednak w celu tworzenia linków symbolicznych niezbędne jest posiadanie uprawnień administratora. Zabezpieczenie to zostało wprowadzone w celu zmniejszenia ryzyka wykorzystania ewentualnych podatności w mechanizmie odnośników symbolicznych (np. luki naprawione przez aktualizację MS10-021 – CVE-2010-0235, CVE2010-0237).

Podsumowując, zalecanym ustawieniem jest przydzielenie omawianego przywileju administratorom – będzie to zgodne z polityką bezpieczeństwa Microsoftu w tym kontekście (zarówno w starszych, jak i nowszych wersjach systemu Windows). Uwaga: przywilej wymagany jest też do poprawnego działania Hyper-V – powinien być wtedy przydzielony grupie „Maszyny wirtualne”.

Podsumowanie

Poniżej znajduje się podsumowanie omówionych opcji wraz z ich rekomendowaną konfiguracją:

• Minimalna długość hasła – 14 znaków
• Wymagania dotyczące złożoności haseł – włączone
• Maksymalny okres ważności hasła – 60 dni wg CIS, 365 dni wg Microsoft
• Minimalny okres ważności hasła – 1 dzień
• Historia haseł – zapamiętywanie ostatnich 24 haseł
• Przechowywanie haseł z wykorzystaniem odwracalnego szyfrowania – wyłączone
• Próg blokady konta – 10 lub mniej nieudanych prób logowania
• Okno obserwacji dla blokady konta – 15 minut lub dłużej
• Czas blokady konta – 15 minut lub dłużej
• Przywilej „SeTcbPrivilege” (działanie jako część systemu operacyjnego) – nieprzydzielony nikomu
• Przywilej „SeNetworkLogonRight” (dostęp do komputera z sieci) – przydzielony grupom „Administratorzy”
• i „Użytkownicy uwierzytelnieni” (oraz grupie „Kontrolery domeny przedsiębiorstwa" w przypadku kontrolerów domeny)
• Przywilej „SeMachineAccountPrivilege” (dodawanie stacji roboczych do domeny) – przydzielony grupie „Administratorzy” (tylko dla kontrolerów domeny)
• Przywilej „SeInteractiveLogonRight” (logowanie lokalne) – przydzielony grupie „Administratorzy” (oraz grupie „Kontrolery domeny przedsiębiorstwa” w przypadku kontrolerów domeny)
• Przywilej „SeRemoteInteractiveLogonRight (logowanie za pomocą usługi Zdalnego Pulpitu) – przydzielony grupie „Administratorzy” ” (oraz grupie „Użytkownicy pulpitu zdalnego” w przypadku zwykłych serwerów)
• Przywileje „SeBackupPrivilege” i „SeRestorePrivilege” (tworzenie kopii zapasowej oraz przywracanie plików i katalogów) – przydzielone grupie „Administratorzy”
• Przywileje „SeSystemtimePrivilege” i „SeTimeZonePrivilege” (zmiana czasu systemowego i strefy czasowej) – przydzielone grupie „Administratorzy” i kontu „Usługa lokalna”
• Przywilej „SeCreateTokenPrivilege (tworzenie obiektu tokenu) – nieprzydzielony nikomu
• Przywilej „SeCreateGlobalPrivilege (tworzenie obiektów globalnych) – przydzielony grupie „Administratorzy” i kontom „Usługa lokalna”, „Usługa sieciowa” i „Usługi”
• Przywilej „SeCreateSymbolicLinkPrivilege” (tworzenie linków symbolicznych) – przydzielony grupie „Administratorzy” ” (oraz grupie „Maszyny wirtualne" w przypadku serwerów z zainstalowaną rolą „Hyper-V"

Autor: Patryk Czeczko