W dzisiejszym artykule opiszemy nasze ciekawe spostrzeżenie co do rzadko używanej funkcjonalności w Active Directory, która może przyczynić cię do utworzenia backdoor’a. Artykuł podzieliliśmy na 2 części, w których opisujemy sposoby na utworzenie przyczółku (część 1) oraz przeprowadzenie ataku (część 2).
Na temat tworzenia backdoor’ów w AD oraz mechanizmów zabezpieczenia się pisaliśmy niedawno w poświęconej temu kampanii – Active Directory Persistence Pokazywaliśmy w niej, w jednym z artykułów tutaj, jak stworzyć i ukryć użytkownika (backdoor) w AD posiadającego jednocześnie wysokie uprawnienia i umożliwiającego nam stały dostęp do środowiska. Lecz czy kiedykolwiek pomyślałeś Drogi Czytelniku, co mogłoby się stać gdybyśmy mieli utworzone takie podobne konto, ale dla komputera?
Konto komputera do uwierzytelniania w AD?
Osoby zaznajomione z Active Directory doskonale wiedzą, że oprócz kont użytkowników (z ang. user accounts) uwierzytelniają się w nim także konta komputerów (z ang. computer accounts). Tak, one również posiadają hasła, które są zarządzane przez mechanizm AD i zazwyczaj monitorowanie ich traktowane jest po macoszemu przez firmy.
W monitowaniu bezpieczeństwa zwykło się przyjąć, że to właśnie konta użytkowników są największym zagrożeniem, natomiast konta komputerów są często pomijane w analizie.
Pewnie nie ma nic złego w tym stwierdzeniu i na ogół jest to poprawne myślenie, ponieważ konta komputerów i ich bezpieczeństwo jest zarządzane przez AD, więc dlaczego mielibyśmy się nimi przejmować (z reguły hasła tych obiektów oraz ich użycie nie powinno interesować nikogo w AD poza samymi komputerami)? Jak się okazuje nie do końca tak może być i pamiętać należy również, żeby w polityce monitorowania i audytu ująć również konta komputerów. Dlaczego? O tym piszemy i pokażemy w dalszej części artykułu.
Opcja „Reset Account” i problem?
Podczas przeglądania dostępnych opcji do zarządzania kontem komputera w konsoli Active Directory Users and Computers zaciekawiła nas jedna możliwość, dostępna już od Windows 2000 – Reset Account (resetowanie konta).
Jak się domyślacie oraz zgodnie z informacją jaką podaje Microsoft w swojej bazie wiedzy, opcja ta służy administratorom do resetu bezpiecznego kanału zabezpieczeń na obiekcie konta komputera. Tak naprawdę jest to reset hasła kanału zabezpieczeń, które jest przechowywane wraz z kontem komputera na wszystkich kontrolerach domeny.
Każdy komputer, będący członkiem domeny, w celu uwierzytelnienia do kontrolerów Active Directory używa hasła jego obiektu konta komputera w AD. Co jakiś czas (domyślnie 30 dni) zmienia je sobie automatycznie. W sytuacji, kiedy administrator np. wycofa maszynę wirtualną, przywróci ją z kopii zapasowej lub sklonuje dwie maszyny, hasło komputera i tajny klucz LSA (LSA secret) w AD rozsynchronizowują się powodując brak możliwość zalogowania się. Właśnie po to jest opcja Reset Account, aby zresetować pomyślnie ustanowiony wcześniej kanał bezpieczeństwa. Jeśli z jakiegoś powodu hasło konta komputera i klucz tajny LSA nie są zsynchronizowane możemy się o tym dowiedzieć z usługi Netlogon, ponieważ rejestruje ona błędy.
Konsola AD Users and Computers (Użytkownicy i Komputery usługi Active Directory) to nie jedyny sposób na przeprowadzenie operacji resetu konta komputera. Można ją wykonać również przy użyciu następujących narzędzi Windows:
- Narzędzia wiersza poleceń „Netdom.exe”
- Narzędzia wiersza poleceń „Nltest.exe”
- Korzystając ze skryptu Microsoft Visual Basic
UWAGA! Narzędzia „Netdom.exe” i „Nltest.exe” są dostępne w instalce systemu Windows Server w folderze „Support\Tools”
Niestety nigdzie w bazie wiedzy Microsoft nie dowiedzieliśmy się, co dzieje się technicznie (od środka) w trakcie procesu resetu oraz jakie nowe hasło ustawiane jest na takim obiekcie komputera. Pewnie, gdyby nie wyciek kodu źródłowego z Windows 2003 nigdy byśmy się o tym nie dowiedzieli.
Postanowiliśmy zatem zerknąć do źródeł i ku naszemu zdziwieniu:
podczas wykonywania funkcji Reset Account, hasło obiektu komputera w AD zmieniane jest na uwaga:
NAZWĘ KOMPUTERA PISANĄ MAŁYMI LITERAMI!
Przy czym hasło jest obcinane do pierwszych 14 znaków nazwy komputera (jeśli jego nazwa jest dłuższa) i ucinany jest znak $ na końcu. Celowo napisaliśmy to z dużych liter, aby uświadomić Wam źródło problemu jakim może się stać ta funkcja dla atakujących!Czyli od Windows 2000 (od tej wersji jest rozwijane Active Directory), aż do dziś Microsoft nic w tym obszarze nie zrobił! Nie napawa optymizmem, że możemy to wykorzystać do utworzenia backdoor’a w AD – fikcyjnego konta komputera, do którego znalibyśmy hasło i moglibyśmy się uwierzytelniać.
Pisząc o loginach kont komputerów w AD i znaku „$” na końcu loginu przypomina nam się błąd w sprawdzaniu go przez Microsoft skutkujący możliwością przejęcia domeny – podatność CVE-2021-42278 – Podszywanie się pod sAMAccountName, którą opisaliśmy w grudniu zeszłego roku.
Utworzenie Backdoor w AD
Nasz scenariusz zakłada, że posiadamy odpowiednie uprawnienia w Active Directory do utworzenia obiektu typu komputer. Może to być oddelegowane uprawnienie „Create Computer Objects” lub posiadające członkostwo we wbudowanej grupie „Account Operators”. Przypominamy również, że domyślnie w AD konto komputera (do 10 sztuk) może utworzyć normalny użytkownik w AD (poprzez możliwość dodania komputera do domeny)! – pisaliśmy o tym tutaj.
KROK 1. Utworzenie konta nieistniejącego fizycznie komputera
Tworzymy w AD konto komputera o nazwie HACK. Możemy tez wykorzystać inne konto (istniejące) pod warunkiem, że nie jest wykorzystywane – to częsty scenariusz w firmach, kiedy konta komputerów są tworzone, natomiast nie są blokowane/usuwane po czasie nieużywania. Najczęściej tworzą się wtedy tzw. osierocone konta.
KROK 2. Resetujemy konto komputera
Teraz klikamy prawym przyciskiem myszy na obiekcie komputera „HACK” i wybieramy opcję „Reset Account”
Operacja się udała. Otrzymaliśmy komunikat o poprawnym resecie.
KROK 3. Test zalogowania się
Po wykonaj udanej próbie Resetu konta w konsoli ADUC przeprowadzimy test możliwości jego zalogowania się. W tym celu użyjemy naszej stacji Windows 10 podpiętej do domeny.
Wiemy już, że hasło powinno być tożsame z nazwą komputera (pisane małymi literami, pierwsze 14 znaków z nazwy). W naszym przypadku to będzie hasło „hack”. Spróbujmy zatem uwierzytelnić się kontem naszego utworzonego komputera. Nawa konta komputera (samaccountname) to „HACK$” ponieważ komputery podczas logowania używają takiej składni:
Informacyjnie warto dodać, że to między innymi znak „$” na końcu loginu, pozwala w logach Security odróżnić konta zwykłych użytkowników od kont komputerów.
W celu zalogowania się na nasze konto komputera użyjemy wiersza poleceń w Windows i specjalnej komendy „runas”, którą uruchomimy nowy wiersz poleceń w kontekście naszego konta komputera „HACK$”
runas /user:KAPITAN\HACK$ cmd.exe
Na podstawie powyższego ekranu, widzimy, że próba uwierzytelnienia się powiodła, lecz polityki bezpieczeństwa Windows zabraniają logowania kont komputerów lokalnie do naszego profilu (zblokowały je). Bardzo dobrze Microsoft, ale jest na to obejście – zastosowanie magicznego przełącznika „/netonly”. Dzięki temu będziemy mogli użyć poświadczeń w trybie sieciowym.
Teraz poszło nam znacznie lepiej, ponieważ dostaliśmy nowy wiersz poleceń działający na użytkowniku KAPITAN\HACK$ – czyli naszym koncie komputera.
Od teraz możemy się cieszyć stałym dostępem do katalogu AD – ponieważ mamy w nim utworzone konto. Na koniec zadajmy sobie pytanie, czy taki przypadek jest monitorowany u Ciebie w infrastrukturze?
Jak sobie radzić z problemem?
Przede wszystkim powinniśmy przeprowadzić audyt kont komputerów w AD (i nie tylko) i sprawdzić, czy są one w stałym użyciu przez odpowiadające tym obiektom fizyczne komputery w firmie. Jeśli nie, to istnieje wysokie prawdopodobieństwo, że część z nich może być „backdoorem” dostępowym do Twojego AD lub wykorzystana w przyszłości.
Jeśli nie są używane najlepiej takie konta skasować lub zastosować proces bezpiecznego wyłączania ich (disable account).
Z punktu monitorowania bezpieczeństwa powinniśmy zwrócić uwagę na próby resetu hasła na kontach komputerów, które w szczególności są przeprowadzane przez użytkowników posiadających do tego odpowiednie uprawienia oraz próby uwierzytelnienia się na nie z innych maszyn. Pamiętać należy, że takie zapominane konto może stanowić zagrożenie dla naszego AD.
To chyba tyle na ten moment odnośnie co do pierwszej części. Zainteresowanych tematyką zapraszamy do kontaktu i prosimy o chwilę wytchnienia, aż do czasu opublikowania drugiej. Pokażemy w niej, jak przeprowadzić atak w wykorzystaniem podobnego jak tutaj konta komputera i doprowadzimy do kompromitacji AD.