Jak niepoprawna konfiguracja AD CS może doprowadzić do kompromitacji całej domeny

AD CS, czyli Active Directory Certificate Services, to usługa pozwalająca na wydawanie certyfikatów w środowisku Active Directory, zarządzanie nimi i ich unieważnianie. Ten najważniejszy element infrastruktury bywa pomijany pod kątem bezpieczeństwa, tymczasem znane metody związanych z nim ataków oraz ich skutki mogą doprowadzić do kompromitacji całej domeny. Wystarczy jedna nieodpowiednia konfiguracja.

Active Directory Certificate Services

Active Directory Certificate Services (AD CS) to usługa systemu Windows Server pozwalająca na centralne i automatyczne zarządzanie certyfikatami w domenie. Pełni ona funkcje wewnętrznego urzędu certyfikacji (CA), który potwierdza tożsamości użytkowników, komputerów i usług.

Oprócz standardowych dla certyfikatów informacji te wystawione przez AD CS zawierają dodatkowe pola, które zapewniają dodatkową funkcjonalność. Właśnie te dodatkowe informacje zawarte w certyfikatach wystawionych przez usługę AD CS mogą być furtką do potencjalnego ataku.

Szablony certyfikatów

Tworzenie każdego certyfikatu od zera byłoby bardzo uciążliwe, dlatego w usłudze AD CS za standaryzację odpowiadają szablony, które definiują zasady wystawiania certyfikatów. Określają one m.in. kto może zawnioskować o certyfikat, w jaki sposób może on być użyty czy jaki będzie jego okres ważności.

Niepoprawne konfiguracje szablonów mogą jednak stanowić poważny wektor ataku. Jednym z przykładów takiej konfiguracji jest możliwość ustawienia dowolnej wartości w polu Subject Alternative Name (SAN) i jednoczesne zezwolenie na używanie certyfikatu do uwierzytelnienia. W przypadku takiej konfiguracji atakujący może zażądać certyfikatu dla innej tożsamości i wykorzystać go w scenariuszu ataku ESC1, umożliwiając podszycie się pod innego użytkownika lub komputer w domenie.

Wykrycie podatnych na atak szablonów

Może się wydawać, iż szukanie szablonów certyfikatów pozwalających na atak będzie długie i żmudne. Istnieją jednak gotowe narzędzia pozwalające w łatwy sposób znaleźć podatne konfiguracje – Certify i Certipy. Przydają się przy zabezpieczeniu środowiska, ale jednocześnie są idealnym narzędziem dla atakującego.

Skupmy się na Certify, które natywnie działa w środowisku Windows, oraz scenariuszu ataku ESC1. dzięki jednej komendy możemy wylistować wszystkie włączone szablony certyfikatów, które są skonfigurowane w sposób pozwalający na potencjalny atak.

Certify.exe enum-templates --filter-enabled --filter-vulnerable --hide-admins

W przedstawionym na powyższym zrzucie ekranu szablonie widzimy kilka konfiguracji, które razem tworzą idealną furtkę dla atakującego. Przyjrzyjmy się, co oznaczają poszczególne ustawienia:

• Certificate Name Flag
  Definiuje, czy wnioskujący może wskazać nazwę certyfikatu (Subject lub SAN).
• Manager Approval Required
  Określa, czy żądanie certyfikatu musi zostać zatwierdzone manualnie przez administratora.
• Authorized Signatures Required
  Definiuje liczbę wymaganych autoryzacji do wystawienia certyfikatu.
• Extended Key Usage
  Określa, do czego certyfikat może by używany.
• Enrollment Rights
  Wskazuje, kto może zażądać certyfikatu na podstawie szablonu.

Podsumowując, nasz szablon certyfikatu pozwala w żądaniu wystawienia certyfikatu wskazać dowolną tożsamość w polu SAN, nie wymaga manualnego zatwierdzenia ani żadnych dodatkowych autoryzacji. Można go używać do uwierzytelnienia klienta, a wnioskować może każdy członek grupy Domain Users.

Przeprowadzenie ataku ESC1

Skoro ustaliliśmy już, iż w środowisku istnieje podatny szablon certyfikatów, który możemy wykorzystać, pora przystąpić do sekwencji pozwalającej na przejęcie uprzywilejowanego konta w domenie.

Będziemy działać na koncie haker01 – zwykłego użytkownika, członka grupy Domain Users.

Za cel obierzemy najbardziej uprzywilejowane konto w domenie, czyli Administrator. Konto to jest zawsze tworzone automatycznie wraz z utworzeniem domeny i bardzo często pozostaje włączone.

Pierwszym krokiem po zidentyfikowaniu szablonu, którego chcemy użyć, będzie zawnioskowanie o nowy certyfikat z jego wykorzystaniem. Z pomocą ponownie przyjdzie nam Certify. Skorzystamy z komendy request i uzupełnimy niezbędne parametry. W odpowiedzi otrzymamy certyfikat zapisany w formacie base64, który posłuży nam w następnym kroku do uzyskania biletu Kerberos konta Administrator.

Certify.exe request --ca host_ca\nazwa_ca --template nazwa_szablonu --upn user@domain --sid user_sid

Naszym celem będzie dzięki otrzymanego certyfikatu wstrzyknąć do listy biletów Kerberos bilet potwierdzający naszą tożsamość jako konto Administratora domeny. Wykorzystamy do tego znane narzędzie Rubeus.

Rubeus.exe asktgt /user:administrator /certificate:Certyfikat_w_base64 /ptt

Jeżeli wszystko do tej pory zostało wykonane poprawnie, to rezultat powinien być następujący:

Potwierdzenie z poziomu kontrolera domeny, iż jesteśmy rozpoznawani jako konto Administrator:

Przedstawiony scenariusz ESC1 jest tylko jednym z kilku znanych wektorów ataku na AD CS. Znane jest co najmniej osiem różnych technik (ESC1-ESC8), które pokazują, jak błędna konfiguracja usługi AD CS może prowadzić do przejęcia tożsamości, a następnie eskalacji uprawnień i przejęcia kontroli w całej domenie.

Choć Active Directory Certificate Services może być często postrzegane jako usługa pomocnicza, rzeczywiste scenariusze ataku jasno pokazują, iż jej kompromitacja daje poziom dostępu porównywalny do przejęcia kontrolera domeny. Z tego względu AD CS powinno być regularne audytowane i monitorowane, a przede wszystkim traktowane jako zasób Tier 0, objęty najwyższymi standardami bezpieczeństwa.