W poprzednim tygodniu na łamach naszego portalu ukazał się artkuł, w którym opisywaliśmy, jak zarządzać kontami usług (MSA i gMSA) w Active Directory. W skrócie: Managed Service Account (MSA) to specjalny typ konta Active Directory, którego można używać do uruchamiania usług, aplikacji i zaplanowanych zadań. Samo konto jest o tyle bezpieczne, że hasłem zarządza samo AD a nie użytkownik, przez co pozostaje nieznane nawet dla samych administratorów.
Jednak, jak podaje Sean Metcalf na portalu Adsecurity.org, bezpieczeństwo tego konta nie jest tak mocne jak mogłoby się nam wydawać. Kluczową korzyścią jest automatyczna zmiana haseł poprzez Active Directory, a nie fakt, że dane uwierzytelniające są lepiej chronione.
W dzisiejszym poście postaramy się pokazać co może zrobić atakujący, jeśli konta gMSA nie są odpowiednio chronione.
Ważne atrybuty kont gMSA
Musimy zacząć od wymienienia ważnych dla nas atrybutów kont gMSA są to z pewnością:
- atrybut msDS-GroupMSAMembership – odpowiada za to, kto może uzyskać dostęp do hasła gMSA.
- atrybut msds-ManagedPassword zawiera BLOB z informacjami o hasłach dla kont usługowych zarządzanych grupowo.
Dodatkowo, aby uzyskać identyfikator klucza posłużymy się atrybutem msDS-ManagedPasswordId i na koniec msDS-ManagedPasswordInterval, który służy pobierania liczby dni przed automatyczną zmianą hasła
PS C:\> Get-ADServiceAccount -filter {name -eq ‘KAPITANHACK_SVC’} -prop * | Select Name,DNSHostName,MemberOf,Created,LastLogonDate,PasswordLastSet,msDS-ManagedPasswordInterval,PrincipalsAllowedToDelegateToAccount,PrincipalsAllowedToRetrieveManagedPassword,msDS-ManagedPassword,ServicePrincipalNames
Powyższe informacje możemy pozyskać z Active Directory uruchamiając cmdlet PowerShell Get-ADServiceAccount. Przykład powyżej, gMSA jest członkiem grupy Administratorzy w domenie „Kapitan.hack”. Na zrzucie ekranu widać, że hasło zostało ostatnio zmienione i nie zmieni się przez 30 dni. Oznacza to, że jeśli uda się zdobyć hasło do tego konta, pozostanie miesiąc na wykorzystanie jego danych uwierzytelniających.
Atakujący wykona najprawdopodobniej dwa scenariusze, pierwszy, gdzie uzyskujemy dostęp do serwera z uprawnieniami administratora, aby za pomocą narzędzia Mimikatz wyciągnąć hash hasła NT. Drugi w przypadku braku dostępu do serwera wylistuje listę osób (i komputerów) z uprawnieniami do pozyskania hash’a aby użyć ich poświadczeń do wyciągnięcia hasła. Oba scenariusze mają taki sam cel, którym jest kompromitacja środowiska Active Directory.
W celu pokazania tych możliwości posłużyliśmy się scenariuszami opisanymi przez Sean Metcalf.
Scenariusz 1 – Pozyskiwanie dostępu do serwera z uruchomioną usługą gMSA
Po wejściu na serwer, na których działają usługi GMSA, mamy kilka opcji.
Jak widać serwer LCNSQL01 jest zarejestrowany jako Service Principal Name (SPN) w gMSA, widać też, że serwer znajduje się w Servers OU.
Wystarczy skompromitowanie konta z prawami do Servers OU lub delegowanymi prawami administratora poprzez GPO. Mając możliwość modyfikacji GPO, które łączy się z tym OU, uzyskujemy prawa administratora na serwerze LCN.
Po uzyskaniu praw administratora możemy zobaczyć, że w usługa gMSA została skonfigurowana tak aby uruchomić Windows License Manager.
Za pomocą Mimikatz i komendy sekurlsa::logonpasswords, możemy zobaczyć hash hasła natomiast nie jest to jeszcze forma, której możemy użyć do kompromitacji środowiska AD.
Nie jest to standardowe hasło (i nie jest to hasło przypisane do konta). Co więcej, ten hash hasła nie jest poprawny. Microsoft wczytuje dane uwierzytelniające GMSA do LSASS, ale nie wygląda, aby ich używał.
Aby uzyskać prawidłowy hash hasła NT, musimy użyć polecenia Mimikatz które jest używane do uzyskania biletów Kerberosa:
sekurlsa::ekeys
Scenariusz 2 – Brak dostępu do serwera
Mając informacje o tym, że istnieje grupa skonfigurowana z uprawnieniami do uzyskania hasła i wykorzystując to, że atrybut konta gMSA msDS-GroupMSAMembership zawiera grupę o nazwie “SVC-LAB-GMSA1 Group” możemy się dowiedzieć kto może żądać i otrzymywać hasło w postaci czystego tekstu.
Używając cmdlet Get-ADGroupMember jesteśmy w stanie określić członków danej grupy, widzimy, że występuję w niej komputery, użytkownicy i jeszcze jedna grupa “Server Admins”.
Teraz mamy listę wszystkich kont, które mogą uzyskać hasło gMSA w postaci czystego tekstu. Jest 11 kont użytkowników z taką możliwością, z czego 9 z nich wygląda jak zwykłe konta użytkowników.
Następnie kompromitujemy konto użytkownika lub komputera, który ma możliwość pozyskania hasła w postaci czystego tekstu. W tym celu możemy użyć cmdleta
Get-ADServiceAccount
Dane dotyczące hasła w postaci czystego tekstu które zawiera atrybut msds-ManagedPassword możemy uzyskać korzystając z modułu DSInternals który przekonwertuje blok haseł w postaci tekstu na hash NT.
Uwaga: Jeśli konto, które jesteśmy w stanie przejąć, jest kontem komputera, musimy uruchomić te polecenia jako SYSTEM na komputerze. Możemy do tego zastosować PSEXEC.
Załóżmy, że jesteśmy w stanie uzyskać prawa administratora/SYSTEM na serwerze z uprawnieniami do pozyskania hasła gMSA, ale usługa nie pracuje na tym hoście. W tym przypadku uruchomienie Mimikatz nie pomoże, ponieważ poświadczenia gMSA nie są przechowywane w pamięci.Używając PSEXEC, jesteśmy w stanie wywołać polecenia jako lokalne konto SYSTEM. Po tym możemy wykonać te same czynności, które opisaliśmy powyżej.
Potwierdzenie hashy
Ostatnim krokiem jest potwierdzenie, że hash hasła NT uzyskany przez DSInternals odpowiada hasłu w Active Directory. Do tego możemy zastosować polecenie
DSInternals Get-ADReplAccount
Po potwierdzeniu, że hash konta gMSA zgadza się z hashem pobranym z AD możemy skompromitować środowisko AD.
Podsumowanie
Nieodpowiednio zabezpieczane konta gMSA szczególnie z wysokimi uprawnieniami potrafią w prosty sposób doprowadzić do kompromitacji całej domeny. Szczególnie ważne jest, aby weryfikować jakich uprawnień wymaga pracujące konto usługowe w naszym środowisku. Bądź czy istnieje możliwość nadania niższych uprawnień do prawidłowej pracy. Warto też zweryfikować ilość użytkowników którzy posiadają uprawnienia do pozyskania hasła z kont gMSA. W tym artykule między innymi opisywaliśmy, jak ograniczyć dostęp kont usługowych do poszczególnych serwerów, na których odpowiadają za obsługę. Nie ma potrzebny, aby były wystawione tam, gdzie nie wykonują żadnego zadania.