W tym artykule opiszemy jedno z potencjalnych ryzyk związanych ze źle skonfigurowanymi usługami delegowania Kerberos lub użytkownikami w Active Directory oraz pokażemy jak w niezabezpieczonym środowisku możemy przejąć w łatwy sposób nad nim kontrolę. Informacje zawarte w tym artykule przeznaczone są dla administratorów, CISO lub CIO w firmie.


Ataki na Active Directory

Patrząc na statystyki skuteczności złośliwego oprogramowania oraz na ataki przeprowadzane przez Insider’ów w firmach, większość włamań i przejęć domeny AD jest spowodowana nieodpowiednią jej konfiguracją, nieładem związanym z uprawnieniami użytkowników lub nieodpowiednim modelem zarządzania. Firmy zapominają o historycznych „zaszłościach” w konfiguracji wykonanych przez administratorów i nie sprawdzają aktualnej konfiguracji, która może stanowić duży problem dla organizacji, a przede wszystkim dla CISO i CIO.

Spotykamy środowiska, w których w członkach grup administratorów domeny AD oraz innych istotnych z punktu administracji grup zabezpieczeń znajduje się zbyt duża liczba kont. Nieodpowiednio delegowane są uprawnienia użytkowników do zarzadzania obiektami, wykonywane są błędy w konfiguracji GPO i niestosowane są najlepsze praktyki bezpieczeństwa. To wszystko powoduje, że Active Directory może kryć w sobie niezauważalnego gołym okiem „backoor’a” umożliwiającego łatwe przejęcie kontroli nad AD. Można się o tym przekonać i zwizualizować drogi przejść ataków wykorzystując opisywane przez nas narzędzie BloodHound.

Podczas ostatniej konferencji RSA przeprowadzono ankietę, w której spytano pentesterów i zespoły Red Team o stopień trudności w przejmowaniu i kompromitacji domeny AD w firmach. Aż 47% ankieterów stwierdziła, że nie stanowi to dla nich najmniejszego problemu. Wniosek jest jeden – powinniśmy należycie monitorować i chronić AD, a przede wszystkim cyklicznie sprawdzać/audytować jego konfigurację – w przeciwnym wypadku narażamy firmę na ogromne ryzyko związane z atakami. Dlaczego zatem ataki przeprowadzane na domenę AD są tak skuteczne? Ponieważ w większości firm po stronie AD nie ma zaimplementowanego należytego mechanizmu detekcji oraz blokady. Mówiąc kolokwialnie antywirus na kontrolerach domeny nie spełnia swojej funkcji jak w przypadku np. stacji roboczych. Wynika to z tego, że problem leży bardziej w architekturze protokołów i błędnej konfiguracji, a nie w tym, czy złośliwa aplikacja zostanie wykryta bądź nie.
Jak problemy z nieodpowiednim zarządzaniem AD mają się do ataków? – o tym piszemy poniżej w kontekście jednego z ataków na Kerberos.


Krótko o Kerberos

Jeśli jesteś administratorem Active Directory lub zajmujesz się bezpieczeństwem z pewnością pojęcie Kerberos nie jest dla Ciebie obce. Lecz uwierz mi, dla wielu osób wciąż stanowi dużą niewiadomą, w szczególności, jeśli chodzi o zagrożenia z nim związane.

Przytaczając definicję Wikipedii, Kerberos to protokół uwierzytelniania i autoryzacji w sieci komputerowej z zastosowaniem centrum dystrybucji kluczy, zaprojektowany w Instytucie Technicznym Massachusetts (MIT). O Kerberos moglibyśmy pisać bardzo dużo, lecz najważniejsze w nim jest to, że powstał jako „lekarstwo” na niezabezpieczony mechanizm uwierzytelniania NTLM i stosowany jest w firmach jako mechanizm uwierzytelniania w implementacji Microsoft Active Directory. W dobrze zabezpieczonej firmie użytkownicy powinni uwierzytelniać się do systemów przynajmniej po Kerberos (oczywiście najlepiej dodać do tego jakiś mechanizm two-factor authentication).

Ale jak to w świecie informatyki bywa, nic nie trwa wiecznie. Pomimo tego, że Kerberos coraz częściej używany w firmach do uwierzytelniania kont i wypiera stary i niezabezpieczony NTLM v1/v2, także on doczekał się niepochlebnych opinii. Na przełomie kilku ostatnich lat wokół Kerberos powstało kilka ataków wykorzystujących słabości w jego architekturze (o zagrożeniach związanych z nieodpowiednio zabezpieczoną usługą katalogową Microsoft Active Directory, w tym Kerberos możesz przeczytać między innymi w naszej kampanii Cyber Kill Chain).


Co to jest delegowanie Kerberos?

Jedną z ciekawych funkcji Kerberos jest możliwość delegowania. Delegowanie Kerberos używane jest wtedy, gdy usługa w imieniu innego użytkownika wymaga dostępu do innej usługi na innym komputerze (np. serwerze plików, serwerze bazy danych itp.).
Załóżmy, że użytkownik w środowisku Microsoft chce uzyskać dostęp do danych za pośrednictwem serwera WWW, ale potrzebne dane są przechowywane w bazie danych na innym serwerze. Z punktu widzenia bezpieczeństwa możliwe jest, ale nie idealne, przydzielenie kontu serwera WWW bezpośredniego dostępu do bazy danych. Dostęp do danych powinien być kontrolowany, ponieważ różni użytkownicy mają różne uprawnienia. Prawidłowe zarządzanie dostępem do informacji wymaga włączenia funkcji delegowania dla konta serwera lub konta serwisowego w zależności od przeprowadzonej implementacji.

Delegowanie jest jednym z czterech typów personifikacji obsługiwanych w systemie operacyjnym Windows od wersji 2000 i nowszych. Można użyć dwóch poziomów delegowania, aby umożliwić usłudze podszywanie się pod użytkownika:
– nieograniczone delegowanie Kerberos (delegowanie Kerberos)
– ograniczone delegowanie Kerberos – Kerberos Constrained Delegation (KCD).

Microsoft, po wprowadzeniu funkcji nieograniczonego delegowania Kerberos, szybko zdał sobie sprawę, że ujawnia ona uprzywilejowane poświadczenia użytkowników, dlatego w wersji Windows 2003 wprowadził funkcję KCD. Z uwagi na konieczność zapewnienie kompatybilności wstecznej dla starszych systemów Microsoft nie zrezygnował ze wsparcia nieograniczonej funkcji delegowania protokołu Kerberos. Dlatego możemy ją włączyć również dla najnowszych systemów Windows. Jak się okazuje funkcja ta w niekontrolowanym środowisku może spowodować dużą lukę bezpieczeństwa. Jaką? – o tym napiszemy w dalszej części artykułu.


Co to jest delegowanie Kerberos?

Przed przeprowadzeniem scenariusza ataku opiszemy dokładnie jak wygląda taki proces uwierzytelnienia wykorzystującego nieograniczone delegowanie Kerberos.

  • Nieograniczone delegowanie Kerberos to uprawnienie, które można przypisać komputerowi w domenie lub kontu użytkownika
  • Zazwyczaj to uprawnienie przyznawane jest komputerom z uruchomionymi usługami, takimi jak IIS, MSSQL itp.
  • Usługi te zazwyczaj wymagają dostępu do bazy danych działającej na tym samym serwerze lub na innym, aby mogły odczytać/zmodyfikować bazę danych w imieniu uwierzytelnionego użytkownika.
  • Gdy użytkownik uwierzytelnia się na komputerze/serwerze, na którym włączono nieograniczone uprawnienia do delegowania Kerberos, bilet TGT uwierzytelnionego użytkownika zostaje zapisany w pamięci tego komputera/serwera.
  • Powodem buforowania TGT w pamięci jest to, że komputer (z uprawnieniami do delegowania) może personifikować uwierzytelnionego użytkownika w razie potrzeby w celu uzyskania dostępu do innych usług w imieniu tego użytkownika.

Na podstawie powyższej informacji widzimy, że z punktu widzenia atakującego serwery z nieograniczonym przekazywaniem uprawnień są głównym ich celem. W przypadku naruszenia bezpieczeństwa takiego serwera, osoba atakująca będzie miała dostęp do wszystkich TGT użytkowników, którzy korzystali z jego usługi. Korzystając z biletu TGT, osoba atakująca może uzyskać dostęp do wszystkich zasobów dostępnych w sieci, oczywiście w zależności od stopnia uprawnień konta, dla którego zostało wykonane przechwycenie biletu. Należy też zwrócić uwagę, że:

„Każde uwierzytelnienie użytkownika (np. przez CIFS) na komputerze z włączonym uprawnieniem do delegowania spowoduje zapisanie biletu TGT Kerberos tego użytkownika w pamięci podręcznej, którego można następnie wyeksportować i użyć ponownie.”


Jak włączyć lub wyłączyć delegowanie Kerberos w domenie AD?

Uprawnienia delegowania można skonfigurować w domenie dla każdego konta użytkownika lub komputera między innymi przy użyciu konsoli „Active Directory Users and Computers” (dsa.msc). Po uruchomieniu konsoli należy wyszukać wybrany komputer/użytkownika -> kliknąć prawym przyciskiem myszy na jego „Właściwości” -> przejść do zakładki „Delegation” -> wybrać „Ufaj temu komputerowi w kwestii delegowania do dowolnej usługi (tylko Kerberos)”. Jeśli chcemy wyłączyć delegowanie musimy zaznaczyć pierwszą opcję.

Rysunek 1. Skonfigurowana opcja nieograniczonej delegacji na serwerze SA

W celu sprawdzenia, które konta komputerów w domenie mają włączona delegację możemy użyć następującego polecenia w PowerShell:

Get-ADComputer -Filter {TrustedForDelegation -eq $true -and primarygroupid -eq 515} -Properties trustedfordelegation,serviceprincipalname,description

Ciekawostką jest, że powyższe zapytanie może wykonać zwykły użytkownik w Active Directory na swojej stacji roboczej. Uzyska on w ten sposób listę komputerów, na których może występować zagrożenie przeprowadzenia ataku.

Rysunek 2. Wynik polecenia Get-ADComuter sprawdzającego w domenie komputery z włączoną opcją nieograniczonej delegacji Kerberos (TrustedForDelegation =TRUE)

W naszym przypadku serwer Windows 2016 o nazwie „SA” został zidentyfikowany jako komputer z włączona opcją delegowania Kerberos. Przejdźmy zatem do ataku.


Scenariusz ataku

W naszym scenariuszu ataku użyjemy przygotowanego w naszej testowej domenie konta użytkownika „attacker” z poświadczeniami lokalnego administratora na serwerze z włączoną funkcją delegacji, ponieważ tylko z takimi uprawnieniami będziemy mogli sprawdzić wszystkie bilety TGT w pamięci komputera. Użytkownik „attacker” zalogowany jest na serwerze Windows 2016 o nazwie „SA” z usługą IIS oraz z włączoną na jego koncie w Active Directory funkcją delegowania uprawnień. Drugi nasz użytkownik „kapitan” z uprawnieniami Administratora Domeny uwierzytelni się do usługi IIS na serwerze SA z kontrolera domeny DC (Windows 2016). Do przeprowadzenia ataku użyjemy naszej skompilowanej wersji narzędzia Mimikatz – „Kapitan.exe”.


Krok. 1. Sprawdzenie biletów TGT na serwerze atakującego

W pierwszej kolejności sprawdzimy jakie bilety TGT posiadamy na serwerze z IIS wykonując polecenie:

sekurlsa::tickets

Rysunek 3. Lista przydzielonych biletów TGT do serwera SA

Możemy też użyć polecenia „klist tickets” w Windows.

Rysunek 4. Wynik polecenia „klist tickets” w wierszu poleceń

Krok 2. Wykonanie połączenia do IIS na koncie administratora

Teraz musimy wykonać z innego serwera, tym razem DC połączenie do naszego serwera IIS (SA) używając konta kapitan z uprawnieniami Domain Admin (sytuacja z życia, w której użytkownik z uprawnieniami admina loguje się do IIS – Zadajmy sobie tutaj pytanie na jakich kontach pracują w organizacji nasi administratorzy i gdzie się logują?)
W naszym przypadku wykonamy zapytanie PowerShell z komputera DC uwierzytelniając się do IIS na SA:

Invoke-WebRequest http://SA.appeal.lab -UseDefaultCredentials -UseBasicParsing

Rysunek 5. Wykonane uwierzytelnienie w Powershell  z sesji użytkownika kapitan z uprawnieniami Domain Admin na serwerze DC do usługi IIS na serwerze SA

W odpowiedzi na żądanie dostaliśmy status 200, więc uwierzytelnienie do serwera IIS się powiodło. W końcu domain admin może się zalogwać wszędzie 🙂


Krok 3. Skopiowanie biletu TGT admina

Wracamy na nasz serwer SA, gdzie jesteśmy zalogowani jako attacker i wykonujemy ponownie polecenie

mimikatz # sekurlsa::tickets

Rysunek 6. Lista przydzielonych biletów kerberos TGT na serwerze SA

Ku naszym oczom pokazuje się bilet TGT administratora domeny (kapitan). W tym momencie możemy śmiało powiedzieć, że skompromitowaliśmy domenę!

W celu sprawdzenia, czy uda nam się przejąć domenę musimy jeszcze wyeksportować bilety Kerberos poleceniem:

mimikatz::tickets /export

Rysunek 7. Wyeksportowane bilety TGT do plików na dysk

Bilety TGT zostaną zapisane w plikach z rozszerzeniem *.kirbi.


Krok 4. Użycie biletu TGT admina i połączenie się do kontrolera domeny

Następnie użyjemy poświadczeń admina „kapitan”.

mimikatz # kerberos::ptt C:\temp\tools\[0;19d9e0][email protected]

Rysunek 8. Użycie biletu TGT administratora (użytkownik kapitan)

Oraz uruchomimy powłokę cmd.exe na kontrolerze domeny za pomocą narzędzia PSExec.exe.

Rysunek 9. Połączenie się do kontrolera domeny

Na koniec pokażemy, że można przejąć bilet TGT innego użytkownika bez konieczności uwierzytelniania się jego do usługi IIS, czy SQL. Wystarczy, że admin uzyska zdalny dostęp po SMB (cifs), co jest częstą wykonywaną aktywnością w administracji, skanowaniu komputerów itp. W tym przypadku również zobaczymy jego bilet TGT dostępny na liście.

Rysunek 10. Zdalne połączenie do dysku C na serwerze SA z kontrolera domeny
Rysunek 11. Bilet TGT administratora “kapitan”

Inny podobny atak na konta serwisowe opisaliśmy w artykule Kerberoasting.


Jak się zabezpieczyć?

Prawidłowa konfiguracja Active Directory spowoduje, że ograniczymy duże spektrum możliwości dla atakującego i dzięki temu będziemy mogli uniknąć ataku lub w dużym stopniu zniwelować jego skutki.

W celu zabezpieczenia środowiska przed tego typu atakiem warto:

  1. Unikać korzystania z nieograniczonej delegacji, czyli z opcji: “Trust this computer for delegation to any service”. Zamiast tego skonfiguruj delegowanie z ograniczonym delegowaniem, ponieważ serwery zaufane dla ograniczonego delegowania przechowują tylko Service Ticket, a nie TGT. Podszywanie się będzie dozwolone tylko dla określonego zestawu usług.
  2. Opcja “Trust this computer for delegation to any service” powinna być włączona tylko na kontrolerach domeny.
  3. Skonfiguruj wszystkie wrażliwe konta (np. Administratorzy domeny) włączając na nich opcję „Konto jest wrażliwe i nie można go delegować”. Administratorzy domeny są najbardziej uprzywilejowanymi kontami w domenie, więc są również najbardziej interesującymi kontami dla atakującego.
  4. Wprowadź podział uprawnień i logowań na serwery. Administratorzy domeny powinni się logować tylko na kontrolery domeny! Pamiętaj, że im mniej komputerów z biletem TGT administratora domeny lub innego uprzywilejowanego konta, tym mniejszą skalę ma cyberprzestępca do przeprowadzenia ataku.
  5. Użyj grupy zabezpieczeń „Protected users” w domenie. Członkostwo w grupie chronionych użytkowników domyślnie ogranicza i zabezpiecza konta wrażliwe. Jeśli poziom Twojej domeny to Windows Server 2012 R2 lub wyższy, użytkownicy w tej grupie nie będą mogli być delegowani przy użyciu delegowania ograniczonego lub nieograniczonego.
  6. Użyj grupy zabezpieczeń „Protected users” w domenie. Członkostwo w grupie chronionych użytkowników domyślnie ogranicza i zabezpiecza konta wrażliwe. Jeśli poziom Twojej domeny to Windows Server 2012 R2 lub wyższy, użytkownicy w tej grupie nie będą mogli być delegowani przy użyciu delegowania ograniczonego lub nieograniczonego.
  7. Zabezpiecz serwery, na których włączyłeś opcję delegacji. Ustaw reguły zapory sieciowej zgodnie z przeznaczeniem serwera i konfiguracją delegowania. Aktualizuj serwery i ogranicz do nich dostęp uprzywilejowany.
  8. Zachowaj ostrożność, komu dajesz uprawnienie „Enable computer and user accounts to be trusted for delegation” – są to użytkownicy, którzy mogą włączyć nieograniczoną delegację Kerberos.
  9. Sprawdź w Active Directory, kto ma oddelegowane uprawnienia, w szczególności:
    • Czy są to „ukryci” użytkownicy z uprawnieniami Full Control do OU, gdzie są komputery/serwery?
    • Kto jest w grupie “Account Operators”. Członkowie tej grupy mogą zarządzać opcją delegacji. Należy unikać przydzielania użytkowników do tej grupy.
    • Skonfiguruj dla wszystkich wrażliwych kont, np. administratorzy domeny opcję „Account is sensitive and cannot be delegated”
  10. Użyj silnych haseł do kont usług zaufanych do delegowania (minimum 25 znaków).
  11. Zaimplementuj system monitorowania kont uprzywilejowanych
  12. Zaimplementuj zaawansowany system audytujący i blokujący podejrzane aktywności użytkowników w domenie i wykrywający ataki na konta.

Podsumowanie

Funkcja delegowania Kerberos jest złożonym zadaniem i ma znaczący wpływ na bezpieczeństwo infrastruktury sieciowej w firmie. Cyberprzestępcy doskonale zdają sobie z tego sprawę i wiedzą, że może być ono nadużywane w firmach, dlatego konieczne jest ograniczenie ryzyka poprzez prawidłowe skonfigurowanie tej funkcji. W przeciwnym razie Twoja domena będzie narażona na ryzyko.
Wskazane jest unikanie nieograniczonej delegacji w organizacji. Jeśli historycznie korzystałeś z serwerów skonfigurowanych do nieograniczonej delegacji, powinieneś to zmienić jak najszybciej. Zamiast tego należy użyć ograniczonej delegacji, unikając przy tym opcji przejścia protokołu (transition) i ograniczając zaufanie do delegowania usług.

W kolejnym artykule opiszemy inny ciekawy atak wykorzystujący usługę wydruku (Print Spooler) oraz funkcję nieograniczonego delegowania Kerberos.

Przypominamy, że jesteśmy dostępni także w mediach społecznościowych Facebook i LinkedIn.

Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.

Podziel się z innymi tym artykułem!