Dzisiejszy artykuł jest kontynuacją artykułu z kampanii „Microsoft LAPS – atakowanie i ochrona”. Opiszemy w nim zasady bezpieczeństwa w używaniu LAPS.
Mówiąc o architekturze bezpieczeństwa LAPS z pewnością powinniśmy zwrócić uwagę na dwa jej aspekty. Część zabezpieczeń po stronie serwerowej, na którą składają się zabezpieczenia atrybutów przechowywanych w Active Directory (a także bezpieczeństwo samego AD) oraz na część kliencką – dodatek instalowany na komputerach. W pierwszej kolejności skupimy się na części związanej z Active Directory, następnie przejdziemy do części klienckiej. W podsumowaniu zamieściliśmy dodatkowe informacje odnośnie ochrony.
Uprawnienia do LAPS
Żeby wdrożyć LAPS w środowisku IT z działającą infrastrukturą Microsoft Active Directory konieczne jest rozszerzenie jej schematu o dodatkowe 2 atrybuty:
- ms-Mcs-AdmPwd – przechowuje hasło w postaci zwykłego tekstu
- ms-Mcs-AdmPwdExpirationTime – przechowuje czas resetowania hasła
Dlatego jednym z najważniejszych aspektów bezpieczeństwa LAPS jest upewnienie się, że uprawnienia do tych nowych atrybutów są poprawnie stosowane oraz monitorowane pod względem dostępu. W szczególności powinniśmy zwrócić uwagę na dostęp do atrybutu „ms-Mcs-AdmPwd” (atrybut tekstowy), ponieważ możliwość jego odczytu wiąże się ze zdobyciem hasła konta administratora na komputerze.
Powinniśmy posiadać jawnie zdefiniowany dostęp tylko dla tych obiektów w AD, które go potrzebują.
W poprzednim artykule nadawaliśmy uprawnienia (delegowaliśmy je) do atrybutów hasła komputerów w AD za pomocą specjalnej komendy PowerShell: „Set-AdmPwdComputerSelfPermission”. Uprawnienie „SELF” zostało nadane wtedy na OU, w którym znajdują się komputery zarządzane przez LAPS. Robiliśmy to po to, aby konto komputera miało uprawnienie do modyfikacji tego atrybuty na swoim obiekcie w AD.
Nadawaliśmy też uprawnienia odczytu dla specjalnie przygotowanej grupy „LAPS Admins” za pomocą komendy PowerShell: „Set-AdmPwdReadPasswordPermission”. Za pomocą tej grupy inni użytkownicy z AD będą mogli odczytywać hasła.
W celu sprawdzenia, jakie konta/obiekty AD mają przydzielone inne, rozszerzone uprawnienia (domyślnie) w AD do komputerów używaliśmy także komendy Powershell: „Find-AdmPwdExtendedRights”
Nasuwa się w tym momencie pytanie, czy wszystko jest poprawnie skonfigurowane i bezpieczne? Czas to zweryfikować.
Jak zabezpieczyć LAPS?
Microsoft udostępnia wiele skryptów PowerShell do sprawdzania, kto ma obecnie przydzielony dostęp do atrybutu i do stosowania nowych uprawnień do tych atrybutów w razie potrzeby. Ogólnie rzecz biorąc, istnieje kilka kategorii, które warto wziąć pod uwagę, próbując zrozumieć przydzielone uprawnienia w AD.
Uprawnienie Extended Rights
Pierwszym z nich, o którym musimy wiedzieć, jest usunięcie istniejącego uprawnienia „All extended rigts” („Wszystkie rozszerzone prawa”) od użytkowników i grup w obiektach komputerów, które nie powinny mieć dostępu do hasła lokalnych kont Administratorów)
Pamiętajmy, że atrybuty LAPS na obiekcie komputera są oznaczane jako „poufne”, co oznacza, że użytkownicy uwierzytelnieni (Authenticated Users) nie mają dostępu do ich odczytu, jak inne obiekty w usłudze Active Directory. Domyślnie administratorzy domeny mają dostęp do odczytu atrybutów poufnych, więc jeśli nie jest to pożądane to „rozszerzone prawa” (Extended Rights) muszą zostać dla nich usunięte. Instrukcje, jak to zrobić przedstawiamy poniżej. Polecenie:
Find-AdmPwdExtendedrights -identity :’nazwa OU’ | Format-Table
Pozwoli nam wylistować wszystkie obiekty, które posiadają uprawnienia rozszerzone.
Widzimy na listingu w kolumnie ExtendedRightHolders konto SYSTEM oraz grupę Domain Admins. Jeśli znajdzie się na niej konto niepożądane lub grupa, należy ją usunąć z poziomu konsoli ADUC.
Uprawnienie ‘SELF’
Kolejnym uprawnieniem, o którym należy wiedzieć, jest obiekt komputera lub tożsamość „SELF” (NT AUTHORITY\SELF), która wymaga możliwości zapisania atrybutów „ms-Mcs-AdmPwdExpirationTime” i „ms-Mcs-AdmPwd”, aby można było aktualizować hasła i czasy wygaśnięcia. Uprawnienie ACE dla „SELF” jest wymagane we wszystkich komputerach zarządzanych przez LAPS.
Uprawnienia do atrybutów LAPS
Ostatnim uprawnieniem, o którym należy wiedzieć, jest przyznanie dostępu użytkownikom i grupom, które mogą resetować hasła lokalnych kont administratorów i zapisywać je w atrybutach tych obiektów komputerów.
W celu weryfikacji uprawnień najlepiej posłużyć się własnym skryptem lub sprawdzonym narzędziem firmy trzeciej. Można tez skorzystać z narzędzia PowerView
Jeśli mamy zainstalowane wbudowane w Windows narzędzie RSAT (narzędzia administracji zdalnej serwera) istnieje interesujący sposób identyfikacji użytkownika mającego dostęp do atrybutu ms-Mcs-AdmPwd. Aby to wykonać możemy użyć polecenia:
dsacls.exe ‘ścieżka do OU z komputerami’
W wynikach zwróconych przez powyższe polecenie możemy wyszukać uprawnień do atrybutu ms-Mcs-AdmPwd oraz ms-Mcs-AdmPwdExpirationTime.
Bezpieczeństwo klienta LAPS
Ważnym elementem w całej architekturze bezpieczeństwa LAPS oprócz części serwerowej (zabezpieczenie atrybutów przechowywane po stronie kontrolera domeny AD) jest klient LAPS.
Po zainstalowaniu klienta LAPS na komputerze, na którem chcemy zarządzać lokalnym hasłem konta administratora jest konfigurowane rozszerzenie zasad grupy po stronie klienta (CSE). Jest to biblioteka DLL (admpwd.dll) znajdująca się w katalogu “C:\Program Files\LAPS\CSE” i skonfigurowana w rejestrze pod scieżką: HKEY_LOCAL_MACHINE\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\GPExtensions.
Jeśli atakujący zdobędzie dostęp do tej biblioteki (będzie mógł ją podmienić) lub uzyska dostęp do możliwości konfiguracji powyższej gałęzi i wpisów w rejestrze możemy mieć problem.
Za pomocą PowerShell możemy sprawdzić obecność biblioteki DLL:
Get-ChildItem ‘C:\Program Files\LAPS\CSE\Admpwd.dll’
Korzystając z PowerShell v5, możemy sprawdzić sumę kontrolną pliku i algorytm szyfrowania użyty w bibliotece DLL:
Get-FileHash ‘C:\Program Files\LAPS\CSE\Admpwd.dll’
Oraz możemy sprawdzić podpis cyfrowy w bibliotece DLL:
Get-AuthenticodeSignature ‘C:\Program Files\LAPS\CSE\Admpwd.dll’
W szczególności ważne jest sprawdzenie podpisu cyfrowego oraz sumy kontrolnej pliku wraz z algorytmem szyfrowania. Dlaczego? Ponieważ rozwiązanie LAPS nie posiada mechanizmu sprawdzania integralności ani weryfikacji podpisu dla pliku dll. Zatem istnieje możliwość wstrzyknięcia złośliwego kodu do biblioteki i wydobycia haseł. Postaramy się to pokazać w następnym artykule.
Monitorowanie LAPS
Po części zabezpieczającej dostęp i klienta LAPS warto zająć się drugim aspektem bezpieczeństwa, na który powinniśmy zwrócić uwagę, czyli monitorowaniem/audytowaniem/rozliczalnością dostępu do atrybutów LAPS. Microsoft udostępnia możliwość audytowania w postaci specjalnie generowanego wpisu w dzienniku zdarzeń- zdarzeniu o identyfikatorze 4662 (Event ID 4662).
W celu skonfigurowania takiego audytu należy użyć komendy PowerShell: „Set-AdmPwdAuditing”. Jej składnia jest następująca:
Set-AdmPwdAuditing –OrgUnit: ‘nazwa jednostki organizacyjnej, w której chcesz skonfigurować audyt’ -AuditedPrincipals: ‘identyfikacja użytkowników/grup, których dostęp do hasła będzie kontrolowany’
Czyli w naszym przypadku będzie to audyt dla grupy „LAPS Admins” w OU „Workstations”:
Jeśli ktoś uzyskuje dostęp do atrybutu hasła LAPS, zdarzenie o identyfikatorze 4662 jest rejestrowane na kontrolerze domeny, który odpowiedział na żądanie odczytu. Przykład pobrania hasła z narzędzia LAPS UI:
Wpis w logu Microsoft:
Minusem tej metody audytu jest na pewno fakt, że musimy wiedzieć co chcemy audytować lub inaczej mówiąc – zdefiniować audyt dla znanych nam obiektów lub “wszystkich” (należy podać zamiast „LAPS Admins” tożsamość „Everyone”, ale UWAGA – może pojawić się spory szum w logach) Problem może pojawić się wtedy, gdy ktoś zdobędzie taki niepowołany dostęp do atrybutów lub będzie go chciał w jakiś inny sposób uzyskać. Co wtedy? O tym opowiemy w przyszłym artykule.
Nagły reset hasła konta administratora na komputerze
Może się zdarzyć sytuacja, w której podejrzewamy, że hasło lokalnego administratora wyciekło lub chcemy je jak najszybciej zmienić. W tym momencie przyda nam się komenda PowerShell o nazwie „Reset-AdmPwdPassword”
Należy tutaj pamiętać, że LAPS i w tym zakresie nie jest idealny. Podczas resetowania hasła za pomocą Reset-AdmPwdPassword należy poczekać, aż zasady grupy zostaną odświeżone na urządzeniu (90 minut domyślnie dla komputerów), zanim nowe hasło zostanie zmienione na komputerze lokalnym.
Poniżej przedstawiamy przykład jak taki proces można przyspieszyć. Należy użyć konsoli do zarządzania obiektami GPO (GPMC) i skorzystać z opcji „Group Policy Update” na OU w którym chcemy zresetować hasło dla konta administrator na komputerach.
Lub na komputerze skorzystać z polecenia „gpupdate /force”.
Podsumowanie
Zabezpieczając Microsoft LAPS musimy zwrócić uwagę zarówno na zabezpieczenie części serwerowej (atrybutów przechowywanych w AD) oraz części klienckiej. Poniżej zamieszczamy kilka punktów, na które warto również zwrócić uwagę przy ochronie:
- Ponieważ LAPS ma automatyzować zmianę haseł administratora lokalnego, a także zachować prywatność tych informacji, określenie, kto powinien mieć możliwość pobierania haseł administratora lokalnego na zestawie komputerów, musi być dobrze przemyślane.
- Kluczową kwestią jest to, że delegowanie (odczytu) dostępu do atrybutu hasła musi być starannie zaprojektowane i wdrożone. To jest najważniejsza część wdrożenia LAPS: określenie, kto powinien mieć dostęp do odczytu danych hasła komputera.
- Samo hasło powinno mieć około 25 znaków (bo to jest dziś „rozsądne”). Zdecydowanie powinno być więcej niż 15.
- Hasło konta administratora lokalnego powinno również zmieniać się co najmniej tak często, jak hasła do kont AD komputera (co 15-30 dni).
- Konta delegowane do przyłączania komputerów do domeny mogą mieć możliwość przeglądania danych haseł LAPS na obiektach komputerów.
- Nawet jeśli wdrożysz LAPS lub inne rozwiązanie do zarządzania hasłami lokalnego administratora, nadal zaleca się zainstalowanie aktualizacji KB2871997 (jeśli jest to wymagane) i skonfigurowanie zasad grupy, aby blokować uwierzytelnianie kont lokalnych w sieci. KB2871997 dodaje dwa nowe lokalne identyfikatory SID, w tym LOCAL_ACCOUNT_AND_MEMBER_OF_ADMINISTRATORS_GROUP (S-1-5-114) dla dowolnego konta lokalnego, które jest członkiem grupy administratorów. Skonfigurowanie tego identyfikatora SID w zasadach grupy z ustawieniami „Odmów dostępu do tego komputera z sieci” i „Odmów logowania za pośrednictwem usług pulpitu zdalnego” zapobiega łączeniu się kont lokalnych przez sieć (w przypadku stacji roboczych należy dokładnie przetestować przed wdrożeniem na serwerach).
- Należy sprawdzać, czy suma kontrolna pliku dll ( Admpwd.dll)klienta LAPS oraz certyfikat na stacji roboczej zgadza się z oryginałem.
Pamiętajmy także, że zabezpieczenie atrybutów LAPS za pomocą uprawnień nie jest jedynym sposobem na utrzymanie kontroli nad implementacją LAPS. Monitorowanie ruchu LDAP pod kątem tych dwóch atrybutów LAPS to kolejny sposób na uniknięcie wszelkich atakujących wysyłających zapytania o te informacje, gdy zezwalają na to źle skonfigurowane uprawnienia w AD.
W następnym artykule pokażemy, jak wykonać rekonesans, hakować środowisko, w którym jest wdrożony LAPS oraz na co powinniśmy zwracać uwagę.
Zapraszamy do kontaktu z firmą APPEAL, w celu zabezpieczenia i usprawnienia zarządzania LAPS.