Lithnet AMS czyli prawie jak PAM

Ostatni wpis na moim blogu zamieściłem 22 października ubiegłego roku. Chciałbym więc słowem wstępu krótko wytłumaczyć się skąd wzięła się tak duża przerwa pomiędzy postami. Z reguły jestem zaangażowany jednocześnie w kilka projektów, więc zwyczajnie nie miałem czasu w pisanie. Staram się też dbać o higienę pracy i zdrowie fizyczne, a także utrzymywać na przyzwoitym poziomie życie prywatne. Wszystkie te czynniki składają się na to, iż ciężko jest poświęcić choćby te kilkanaście minut dziennie na Bloga, ponieważ mój „backlog” rzadko kiedy świeci pustkami. Mam nadzieję jednak, iż ten wpis niejako odwróci ten trend i pozwoli na powrót do w miarę regularnego pisania.

Wstęp merytoryczny – czemu piszę o stronie Blue?

W ostatnim wpisie poruszyłem temat programu BloodHound oraz analizy domeny Active Directory. Część druga przez cały czas czeka na napisanie, ponieważ chciałbym przedstawić kilka mniej oczywistych ataków, a także połączyć ten wpis z prezentacją możliwości systemu „Cobalt Strike”. Jest to więc temat dość złożony, na którym w tej chwili pracuję. W „międzyczasie” chciałbym jednak trochę odejść od tematyki „Red Team” oraz szeroko rozumianego Pentestingu, a zwrócić się w kierunku „Blue” i zabezpieczeniu infrastruktury sieciowej. Zawsze uważałem, iż oprócz pewnego ukierunkowania się i specjalizacji w konkretnej dziedzinie, ważne jest holistyczne spojrzenie i zrozumienie pełnego spektrum obszaru IT. Pamiętajmy, iż (prawie) każdy raport z testów bezpieczeństwa pod opisem wykrytej podatności posiada akapit o tym jak poprawić wskazaną lukę. W związku z powyższym zapraszam na wpis o rozwiązaniu Lithnet AMS – czyli ciekawemu rozwiązaniu, które może pomóc w zabezpieczeniu środowiska domenowego.

Privileged Access Management

Zanim zaczniemy o rozwiązaniu grupy Lithnet, (dosłownie) kilka słów o tym czy jest Privileged Access Management. PAM jest to rozwiązanie, które w kompletny, całościowy sposób pozwala nam na zarządzanie dostępem do elementów naszej infrastruktury. Zarządza uprzywilejowanymi kontami, dostępem do usług, serwisów, aplikacji, stacji roboczych czy serwerów. Klasyczne, komercyjne rozwiązania zapewniają szereg środków, które pomagają nam w audycie oraz kontroli nad tym kto oraz kiedy otrzymuje dostęp. PAM zapewniają zaawansowane logowanie zdarzeń, a także analizę zachowania uprzywilejowanego użytkownika na systemie. Każda sesja dopuszczona przez system PAM może być nagrywana i wysyłana na serwer plików. Mamy również cały szereg rozwiązań związanych z randomizacją i rotacją haseł do kluczowych elementów infrastruktury oraz uprzywilejowanych kont. Uniemożliwia to atak w przypadku pozyskania takiego hasła. System potrafi też zarządzać innymi sekretami, takimi jak klucze devopsowe czy deweloperskie. Nowoczesne rozwiązania PAM potrafią być w pełni chmurowe, zintegrowane z hybrydowym modelem infrastruktury lub w formie klasycznej, zabezpieczającej środowiska on-premise.

Privileged Access Strategy https://docs.microsoft.com/en-us/security/compass/privileged-access-strategy

W prawidłowo skonfigurowanej infrastrukturze nie ma czegoś takiego jak konta permanentnie uprzywilejowane. W dużym skrócie – dostęp uprzywilejowany powinien być uzyskiwany tylko i wyłącznie na drodze dopuszczonej, kontrolowanej oraz nadzorowanej. Elewacja uprawnień z kont nieuprzywilejowanych jest realizowana dzięki „Identity Systems” (obrazek powyżej). I właśnie w miejscu gdzie Microsoft umieścił „Identity Systems” pojawiają się nasze narzędzia zarządzania dostępem uprzywilejowanym.

Klasyczne ataki i jak PAM im zapobiega

Zastanówmy się w jaki sposób bardzo często dochodzi do „Lateral Movement” oraz całkowitego przejęcia infrastruktury. Prawie każda „historia” zaczyna się klasycznie, od Client-side attack z wykorzystaniem macra w kampanii phishingowej czy podrzuconego pendrive. Jednak to nie sieć użytkowników jest celem hakerów, ale zony managementowe, sieć serwerów on-premise i uprzywilejowany dostęp do zasobów chmurowych organizacji. W dużym skrócie, po uzyskaniu tzw. initial foothold, podniesieniu sobie uprawnień i zapewnieniu persistance, Threat Actor jest gotowy do dalszego działania – przeniesienia się do innych segmentów sieci. W jaki sposób?

• Net-NTLM hash relay
• Pass-the-Hash
• Pass-the-Ticket
• Wstrzyknięcie kodu w jeden z procesów Administratora

Korzystając z rozwiązań PAM oraz będąc wiernym zasadzie separacji tierów, powyższe ataki nie mają szans na powodzenie. Wprawdzie przejęty został ticket administratora usługi Exchange – ale on przecież w danym momencie nie jest administratorem! On może nim być, ale teraz nie jest. Przejęty hash NTLMowy jest kompletnie bezużyteczny, bo PAM już dawno zrotował i zrandomizował nowe hasło. Kod wstrzyknięty w proces CISO nie może wyrządzić szkody żadnemu z serwerów, ponieważ w danej chwili należy on tylko do grupy „Domain Users”. Dostęp do wielu powyższych elementów można uzyskać tylko i wyłącznie poprzez portal webowy PAM. Portal ten nie przyjmuje hashy NTLM, nie przyjmuje biletów Kerberosa, a ponadto wymaga MFA. Cały wysiłek hakerów na nic.

Rozwiązania Privileged Access Management mają jeden, poważny minus – są piekielnie drogie. I tu Lithnet AMS przychodzi nam z pomocą.

Lithnet AMS – opis możliwości

Szczegółowo o rozwiązaniu Lithnetu może przeczytać tutaj. Program udostępnia prostą w obsłudze i intuicyjną aplikację webową, zawierającą następujące funkcje:

Dostęp do haseł lokalnego administratora

AMS zapewnia prosty, webowy dostęp do haseł lokalnego Administratora. AMS wspiera natywnego agenta Microsoftu, czyli standardowe LAPSowe rozwiązanie, ale można też zainstalować agenta od Lithnetu. Ten drugi również zapewnia on silne, rotowane hasło, ale ponadto umożliwia szyfrowanie atrybutu hasła oraz dostęp do jego historii.

Podgląd hasła lokalnego Administratora na stacji roboczej

Dostęp administracyjny w formie „Just-in-time”

AMS wychodzi na przeciw zasadzie nieposiadania na stałe kont administracyjnych w systemie. W zamian, oferuje nam dostęp do uprzywilejowanej grupy lokalnych administratorów tylko na określony, zdefiniowany w ustawieniach czas. W znaczący sposób utrudnia to potencjalnym adwersarzom powtórne użycie przechwyconego hasha lub ticketu. Proces konfiguracji jest w tym przypadku również ograniczony do minimum, ponieważ AMS korzysta z Time-Based Group Membership, oferowanego przez „Privileged Access Management” feature w Active Directory.

Otrzymany dostęp Just-in-time na serwerze ams.how2hax.pl

Dostęp do Recovery Key Bitlockera

Szyfrowanie dysku jest jednym z kilku podstawowych metod na zabezpieczenie wrażliwych, korporacyjnych danych przed wyciekiem. Zapasowy klucz do Bitlockera może być przechowywany w atrybucie obiektu komputera w Active Directory. Lithnet Access Manager zapewnia nam również możliwość podglądu tego klucza.

Logowanie zdarzeń / powiadomienia email.

Aplikacja od Lithnet poprawnie współpracuje z Windowsowym Event Viewerem. Loguje podstawowe zdarzenia takie jak przyznanie lub odmowa dostępu do zasobu, dostarczając przy tym dość szczegółowe informacje dotyczące danego wydarzenia. Warto jednak wspomnieć o wbudowanym kliencie pocztowym, którzy wysyła nam na pocztę informacje o działaniach programu.

Wiadomość email o przyznaniu dostępu

Lithnet AMS – instalacja i konfiguracja

Instalacja programu Lithnet AMS nie powinna przysporzyć wielu problemów. Manual jest dość dobrze napisany, a sama aplikacja nie pozostawia użytkownikowi miejsca na popełnienie błędu. Lithnet zaleca korzystanie z gMSA – group Managed Service Accounts, o których szerzej możecie przeczytać tu. Z powodzeniem można wykorzystać powershellowy skrypt, który tworzy użytkownika serwisowego „svc-lithnetams”.

Konto serwisowe svc-lithnetams

Warto jednak pamiętać, aby włączyć skrypt odpowiednio wcześniej przed instalacją rozwiązania, jeżeli wcześniej nie używaliśmy gMSA. Jest to spowodowane czasem propagacji klucza KDS (Key Distribution Services) w Domenie, który według Microsoftu wynosi 10 godzin. Aplikacja jest dostarczana w formie pliku Portable Executable, z rozszerzeniem .exe. Warto podkreślić, iż aplikacja sama w sobie ma bardzo małe wymagania odnośnie zależności. Nie musimy mieć zainstalowanego IISa, nie potrzebujemy SQL Servera (pełnej instancji). Z mniej oczywistych spraw – program wymaga .Net Core, który jednak jest ściągany automatycznie przez instalator. To samo tyczy się instacji SQL Servera w wersji LocalDB.

Certyfikat SSL

Kolejną rzeczą którą warto wiedzieć jest fakt, iż Lithnet AMS wprawdzie nasłuchuje na porcie 80, ale robi to tylko po to, aby przekierować użytkownika do bezpiecznego protokołu HTTPS. Instalator nie generuje też certyfikatów self-signed, więc trzeba samodzielnie zadbać o podpisanie certyfikatu dla serwera. Można to zrobić na wiele sposób, ale ja wybrałem lokalny serwer CA dla mojej organizacji. Skorzystałem z gotowego template „Web Server”, sklonowałem go i opublikowałem w Active Directory.

Proces tworzenia szablonu certyfikatu SSL

Udostępniając w domenie szablon certyfikatu pozostaje nam tylko wystąpić o taki certyfikat z poziomu serwera, na którym będzie uruchomiona usługa AMS. Pamiętajmy, iż robimy to z poziomu komputera, a nie użytkownika. O certyfikat występujemy w katalogu „Personal/Certificates” dzięki opcji „Request New Certificate”. Następnie w zakładce „Web Hosting” w programie AMS wybieramy ten certyfikat poprzez opcje „Select from store”.

Proces importu certyfikatu SSL na serwer AMS

Integracja i konfiguracja Lithnet Access Manager z Azure AD

Integracja programu AMS z Azure AD jest bardzo prosta i dość jasno opisana w manualu. Nie będę powtarzać tych kroków, ale chciałbym uwagę zwrócić na coś innego. Po integracji aplikacji z Azure, domyślnie każdy uwierzytelniony użytkownik organizacji ma do niej dostęp. Naturalnie, AMS zapewnia swój system uwierzytelnienia, więc (teoretycznie) do aplikacji zalogować będą się mogli tylko użytkownicy wskazani w zakładce „Authentication”.

Użytkownik zablokowany na poziomie Lithnet Access Manager

Proponuję jednak udostępnić aplikację tylko dla wybranych użytkowników, zgodnie z ustawieniem w polu „Sign-in restriction” w zakładce „Authentication”. Aby to zrobić, należy w pierwszej kolejności włączyć opcję „Assignment required”. Ustawienie to znajduje się w ścieżce „Home” -> [nasza domena w Azure] -> Enterprise Applications -> Lithnet Access Manager.

Ustawienie „Assigment required”

Po zmianie ww. opcji przechodzimy do zakładki „Users and groups” i przypisujemy dostęp do aplikacji dla konkretnych użytkowników lub grup. Po dokonaniu powyższych zmian, Azure AD uwierzytelni tylko wybranych użytkowników do aplikacji.

Użytkownij j.rabbit został „zatrzymany” na poziomie Azure

Oprócz powyższego, zdecydowanie zalecam stworzenie dla aplikacji Lithnet Access Manager oddzielnej polityki „Conditional Access”. Dzięki „Conditional Access” możemy w znaczący sposób zminimalizować ryzyko nieuprawnionego dostępu do naszej aplikacji, np. wymuszając połączenie z aplikacją z „Azure AD joined devices”, włączając inteligentną analizę logowania (link), czy wymuszając wykorzystania MFA.

Ustawienia Conditional Access

Uwierzytelnienie Azure z 2FA

Konfiguracja LAPS

Lithnet AMS może obsługiwać hasła lokalnych administratorów na dwa sposoby:

• z wykorzystaniem agenta LAPS od Microsoft
• z wykorzystaniem własnego agenta.

Jestem zwolennikiem ograniczania, na ile to możliwe, systemu third party w organizacji, więc zrezygnowałem z instalacji agenta od Lithnetu. Dzięki omawianemu programowi możemy już całkowicie zrezygnować z LAPS UI, a zacząć polegać tylko i wyłącznie na interfejsie webowym od Lithnetu. Nie będę omawiał tutaj instalacji systemu LAPS od Microsoftu, ponieważ na ten temat jest bardzo dużo źródeł.

W kontekście AMS – musimy pamiętać o nadaniu uprawnień do atrybutów ms-Mcs-AdmPwd oraz ms-Mcs-AdmPwdExpirationTime dla naszego serwisu. Nie musimy jednak robić tego manualnie – wystarczy wykonać skrypt, który przygotował za nas program Litnet AMS Configuration.

Skrypt do uruchomienia znajduje się pod zaznaczonym przyciskiem

Konfiguracja JIT

Konfiguracja JIT jest troszeczkę dłuższa, ale ani trochę trudniejsza. Działanie Just in Time access polega na możliwości dodawania obiektu do grupy na określony czas – aby włączyć ten feature musimy wykonać następujące polecenie jako Administrator Domeny:

Enable-ADOptionalFeature „Privileged Access Management Feature” -Scope ForestOrConfigurationSet -Target [nazwa domeny]

Następnie uruchamiamy AMS Configuration i z zakładki „Just-in-time access” w menu bocznym wybieramy „Add” przy „Automatic JIT access group creation”

Przykład uzupełnienia pól

Computer OU zawiera komputery, którymi chcemy zarządzać dzięki AMS JIT. dla wszystkich z tych komputerów (serwerów) zostanie stworzona automatycznie oddzielna grupa o nazwie JIT-<nazwa komputera> (ostatnie pole). Wszystkie te grupy zostaną umieszczone natomiast w OU=JIT Groups, OU=ams, DC=how2hax, DC=pl. Grupy te następnie zostaną dopisane do lokalnej grupy „Administrators” na docelowych stacjach dzięki polityki GPO.

Grupy utworzone przez AMS

GPO i jej efekt na jednym z serwerów

Autoryzacja

Przy wstępnie skonfigurowanym dostępie JIT oraz obsłudze LAPS możemy przejść do autoryzacji. Autoryzacja w AMS jest konfigurowana jako zestaw zasad (ang. rules), które definiują uprawnienie danego obiektu do celu (ang. target). Celem może być grupa, kontener OU lub pojedynczy komputer. Istnieją cztery uprawnienia, które możemy przypisać targetowi:

• Dostęp do hasła lokalnego administratora (LAPS)
• Dostęp do historii haseł lokalnego administratora
• Just-in-time access
• Dostęp do kluczy zapasowych bitlockera

Każde z tych uprawnień definiujemy w ten sam sposób, korzystając z dość intuicyjnego menu.

Okno z zdefiniowanymi zasadami

Tworząc nową zasadę jako pierwsze wybieramy target, a następnie definiujemy podmiot i uprawnienia o jakie może wystąpić w aplikacji. Warto podkreślić, iż tworząc zasadę można od razu zdefiniować okres jej obowiązywania, przez co łatwiej jest zarządzać tymczasowymi dostępami.

Przykład dodania zasady

Powyższa zasada umożliwi użytkownikowi p.kowalczyk@how2hax.pl dostęp Just-in-time do serwera CA oraz wgląd w tymczasowe hasło lokalnego administratora. Członkowie grupy Server-Admins też mają zdefiniowane pewne uprawnienia, ale nie możemy ich określić w oparciu o ten zrzut ekranu. Po dodaniu uprawnień możemy jeszcze określić na jak długo ma zostać przydzielony dostęp JIT oraz czy hasło lokalnego administratora ma zostać zrotowane.

Zmiana hasła LAPS po upływie danego czasu

Definicja grupy do jakiej dodać użytkownika oraz czas posiadania podwyższonych uprawnień

Przy prawidłowo przeprowadzonej konfiguracji, wybrani przez nas użytkownicy(grupy) są umieszczani w uprzywilejowanych grupach na określony okres czasu lub posiadają wgląd w hasło lokalnego administratora.

Podsumowanie

Narzędzia Lithnet AMS absolutnie nie należy stawiać obok rozwiązań klasy enterprise takich jak Thycotic, CyberArk czy FUDO. Można wręcz przyjąć, iż Lithnet AMS to tylko webowy interfejs dla LAPSa i Time-Based group membership w Active Directory, z kilkoma dodatkowymi featurami i ładnym frontem. Ale o ile ktoś chce niewielkim nakładem pracy znacząco poprawić bezpieczeństwo swojej infrastruktury, to myślę, iż jest to dobry pomysł.