Dbanie o bezpieczeństwo przetwarzanych danych to nie tylko stosowanie środków prawnych ale też technicznych. Dotyczy to także bezpieczeństwa systemów IT w organizacji. Utwardzanie konfiguracji (tzw. hardening) jest jedną z prostszych metod poprawiających bezpieczeństwo poprzez zmniejszenie powierzchni ataku konfigurowanego komponentu.
Konfigurowalne są elementy systemów operacyjnych takie jak:
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.
Różnica między hasłami 8- a 12-znakowymi jest w tym przypadku zasadnicza – kilka dodatkowych znaków przesądza o braku możliwości odzyskania w rozsądnym czasie praktycznie wszystkich haseł np. z wykradzionej bazy domenowej NTDS.
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:
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ł.
Ostatecznie można wypracować swego rodzaju kompromis, wymuszając zmianę haseł raz na rok – nie jest to okres tak krótki, by skłonić użytkowników do pójścia na skróty w kwestii zabezpieczania ich kont, a jednocześnie poświadczenia tracą ostatecznie swoją ważność.
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).
Hasła nie powinny być przechowywane w formie umożliwiającej ich odzyskanie (np. poprzez deszyfrowanie znanym kluczem). Dlatego do takich celów powszechnie używa się algorytmów haszujących. Jednak czasami występuje konieczność zapewnienia możliwości odzyskania hasła w formie jawnej z postaci przechowywanej w bazie danych.
Przykładem takiej sytuacji jest wykorzystanie usługi Internet Authentication Service wraz z uwierzytelnianiem protokołem CHAP (Challenge Handshake Authentication Protocol). Innym przykładem jest uwierzytelnianie za pomocą HTTP Digest dla serwera Microsoft IIS.
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.
Przed analizą poszczególnych dostępnych opcji warto zrozumieć, jak działa mechanizm blokady kont – zasady są takie same dla kont lokalnych i domenowych. Oczywiście całe rozliczanie (odnotowywanie nieudanych prób uwierzytelnienia, badanie odstępów czasowych itp.) odbywa się na samej maszynie w przypadku kont lokalnych, natomiast w przypadku kont domenowych na podstawowym kontrolerze domeny (kontrolerze z przypisaną rolą „PDC emulator”).
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.
Warto dodać, że w przypadku próby zalogowania z użyciem ostatniego lub przedostatniego hasła (w przypadku gdy włączona jest historia haseł) nie zwiększają licznika nieudanych prób logowania.
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.
Nie da się ustawić czasu blokady krótszego niż okno blokady (i odwrotnie – nie jest możliwe skonfigurowanie okna blokady dłuższego niż czas blokady). Ma to na celu zapobiegnięcie sytuacji, w której po zdjętej blokadzie użytkownik, podając złe hasło natychmiast blokuje konto (mimo że próg blokady wynosi np. 5 nieudanych prób).
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).
Przywileje są nadawane poszczególnym kontom za pomocą konfiguracji polityki bezpieczeństwa (przystawka „secpol.msc” konsoli zarządzania – MMC) lub za pomocą funkcji „LsaAddAccountRights” i LsaRemoveAccountRights”.
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.
Niektóre usługi wymagają możliwości uzyskania dostępu do komputera z sieci. Przykładem są choćby kontrolery domeny, zasoby sieciowe czy serwery IIS. Niemniej maszyny niepełniące szczególnej roli w sieci powinny zostać skonfigurowane tak, aby zezwalały na dostęp sieciowy jedynie wąskiej grupie użytkowników.
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).
Domyślnie w Active Directory przywilej „SeMachineAccountPrivilege” posiadają wszyscy użytkownicy domenowi. Warto rozważyć odebranie tego przywileju użytkownikom – pomoże to zapobiec opisanym atakom.
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.
Warto rozważyć przydzielenie przywileju jedynie wąskiej grupie użytkowników, np. w przypadku serwerów – administratorom. W przypadku kontrolera domeny przywilej powinien być przydzielony wyłącznie administratorom. Jednocześnie należy pamiętać, że niektóre aplikacje mogą wymagać tego przywileju, np. niezbędne jest przydzielenie „SeInteractiveLogonRight” kontom technicznym („IUSR_”) serwerów IIS w celu umożliwienia anonimowego dostępu do serwera HTTP.
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.
Warto rozważyć przydzielenie przywileju jedynie wąskiej grupie użytkowników, np. w przypadku serwerów – administratorom. W przypadku kontrolera domeny przywilej powinien być przydzielony wyłącznie administratorom. Dokładne określenie użytkowników uprawnionych do logowania przez Zdalny Pulpit jest możliwe poprzez dodanie ich do grupy „Użytkownicy pulpitu zdalnego”. Grupa ta ma domyślnie przypisany przywilej „SeRemoteInteractiveLogonRight”.
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”).
W związku z obszernymi możliwościami nadużyć związanymi z przywilejami „SeBackupPrivilege” i „SeRestorePrivilege”, należy zwrócić szczególną uwagę na ich przypisanie użytkownikom. Trzeba jednak pamiętać o użytkownikach i dedykowanych kontach wykorzystywanych przez aplikacje do okresowego tworzenia kopii zapasowych i zapewnić im możliwość poprawnej operacji.
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.
Przywilej jest niezbędny do wywołania funkcji „CreateFileMapping”, „CreateFileMappingNuma” i „CreateFileMappingFromApp”, zakładając, że celem jest utworzenie obiektu w globalnej przestrzeni nazw.
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).
W wydaniu nr 14972 systemu Windows 10 pojawiła się istotna zmiana w kontekście bezpieczeństwa linków symbolicznych – mogą one być tworzone przez normalnych użytkowników – nie są potrzebne już uprawnienia administracyjne (co jest krokiem w stronę systemów uniksowych, które zawsze działały w taki sposób w kontekście linków symbolicznych). Funkcja „CreateSymbolicLink” umożliwia użycie flagi „SYMBOLIC_LINK_FLAG_ALLOW_UNPRIVILEGED_CREATE”. Warunkiem jest uruchomienie trybu dewelopera w systemie. Nie jest wtedy wymagane posiadanie przywileju „SeCreateSymbolicLinkPrivilege”.
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ą:
O innych przywilejach użytkowników oraz pozostałych ustawieniach bezpieczeństwa systemów Windows przeczytasz w magazynie "Cyberbezpieczeństwo"
Autor: Patryk Czeczko
Przechowywanie danych w chmurze polega na zapisywaniu i zarządzaniu danymi na zdalnych serwerach, które są dostępne przez internet. Zamiast przechowywać pliki na lokalnych dyskach twardych lub serwerach, użytkownicy mogą korzystać z infrastruktury dostarczanej przez dostawców usług chmurowych. Jest to wygodne i efektywne rozwiązanie, które zapewnia dostęp do danych z dowolnego miejsca, elastyczność, skalowalność oraz wysoki poziom bezpieczeństwa i niezawodności.
© Portal Poradyodo.pl
