Mamy złą informację dla administratorów Microsoft Exchange oraz Active Directory, a przede wszystkim dla Działów Bezpieczeństwa IT. Otóż w aplikacji Microsoft Exchange Server od wersji 2010 i nowszej odkryto lukę umożliwiającą podniesienie poziomu uprawnień zwykłego użytkownika do uprawnień administracyjnych w domenie Active Directory! Osoba atakująca, której uda się wykorzystać tę podatność, może próbować podszyć się pod dowolnego, innego użytkownika serwera Exchange. Biorąc pod uwagę fakt, że większość dużych firm w Polsce i na Świecie używa Active Directory oraz Exchange skala problemu może nieść za sobą poważne skutki, ponieważ Microsoft nie wydał jeszcze poprawki.
Podatność została upubliczniona przez badacza bezpieczeństwa Dirk-jan Mollema wraz z narzędziem do jej weryfikacji i proof-of-concept (link do GitHub) o nazwie „PrivExchange”.
Aby wykorzystać tą słabość, osoba atakująca musi przeprowadzić atak pośredni (tzw. Man-in-the-middle), w celu przekazania żądania uwierzytelnienia do serwera Microsoft Exchange Server, umożliwiając w ten sposób podszycie się pod innego użytkownika Exchange.
Postanowiliśmy przetestować powyższą podatność na naszym serwerze Exchange 2016 CU11 zgodnie ze wskazówkami Dirk-jana i przedstawić ją Wam w bardzo skróconej formie. Na końcu zamieściliśmy porady jak się przed nią zabezpieczyć.
Gdzie leżą podstawy problemu?
Do przeprowadzenia ataku, zgodnie z sugestią autora, należy wykorzystać poniższe trzy techniki i problemy systemowe. Postaraliśmy się je jednak nieco bardziej wyjaśnić z perspektywy całej metodyki ataku i wykorzystanych słabości mechanizmu uwierzytelniania NTLM.
1. Zbyt wysokie (domyślnie) uprawnienia przydzielone serwerom Exchange w Active Directory
Jak się bliżej zagłębimy w uprawnienia Exchange w Active Directory, to się przekonamy, że architektura implementacji uprawnień Microsoft Exchange w środowisku Active Directory umożliwia administratorom Exchange eskalację ich uprawnień do Administratora domeny. Nasuwa się tutaj pytanie, jak to możliwe? Dzieję się tak dlatego, ponieważ domyślne uprawnienia Exchange przydzielone do obiektu domeny w Active Directory umożliwiają użytkownikom i komputerom będącym w grupie Exchange Windows Permissions zarządzanie uprawnieniami w domenie. Konsekwencją posiadanych uprawnień jest możliwość przydzielenia dla dowolnego konta użytkownika uprawnień potrzebnych do przeprowadzenia ataku DCSync opisywanego w jednym z naszych artykułów z kampanii CYBER KILL CHAIN. O tym jakie obiekty należą do grupy Exchange Windows Permissions w Twoim Active Directory przekonasz się sam sprawdzając jej zawartość 🙂 Poniżej listujemy najciekawsze w tym przypadku uprawnienie.
Przejęcie tych uprawnień (Exchange Windows Permissions) przez atakującego pozwala przydzielić dowolnemu (zwykłemu) użytkownikowi wymaganych dwóch uprawnień do domeny, które pozwalają mu na pobranie wszystkich hashy haseł użytkowników, w tym najważniejszego hasha użytkownika krbtgt, za pomocą którego możemy przeprowadzić atak Golden Ticket – całkowita kompromitacja domeny AD.
2. Podatność mechanizmu uwierzytelniania NTLM na ataki typu relay (przetransmitowanie poświadczeń)
Mechanizm uwierzytelniania NTLM jest wspierany przez kilka protokołów, między innymi przez SMB, HTTP(S), LDAP, IMAP, SMTP, POP3 oraz MSSQL. O jego słabościach wiemy nie od dziś, jednak nadal funkcjonuje (od 15 lat) w wielu implementacjach Active Directory. Jedną z największych słabości NTLM jest możliwość podszycia się pod innego użytkownika podczas uwierzytelniania w ataku „relay”. Atakować w ten sposób możemy na przykład protokół SMB (jeśli komunikacja nie jest podpisana) oraz LDAP. W przypadku ataku na LDAP oznacza to tyle, że jeśli możemy przejąć uwierzytelnianie przekazywane do LDAP, to zdobywając uprawnienie Exchange Windows Permissions będziemy w stanie modyfikować obiekt domeny w katalogu, a tym samym atakujący będzie mógł zdobyć uprawnienia wymagane do ataku DCSync.
Jedyne co potrzebujemy wykonać, to przejąć konto serwera Exchange, aby uwierzytelnił nas po NTLM. Należy zauważyć, że atak na LDAP w tym przypadku będzie możliwy tyko wtedy, gdy ofiara uwierzytelni się do Exchange przez protokół HTTP.
3. Funkcja w MS Exchange pozwalająca uwierzytelnić atakującego przy użyciu konta komputera serwera Exchange
Ostatni element do całej układanki ataku, czyli przejęcie konta serwera Exchange zostało przedstawione przez nieznanego badacza ZDI, który odkrył, że możliwe jest aby Exchange uwierzytelnił się na dowolnym adresie URL poprzez HTTP za pomocą funkcji subskrypcji Exchange PushSubscription (wykorzystywana przez usługę EWS na Exchange dla aplikacji klienckich. W swoim blogu wykorzystał tę lukę, aby przekazać uwierzytelnianie NTLM z powrotem do Exchange i dzięki temu mógł się podszyć pod innych użytkowników.
Dopiero połączenie tej metody ataku z możliwością przeprowadzenia przejęcia uwierzytelniania po LDAP (opisywany wyżej krok 2) i uprawnień Exchange Windows Permissions jakie posiada konto serwera Exchange (krok 1) daje nam możliwość zdobycia wymaganych uprawnień do przeprowadzenia ataku DCSync. Po tym dokonaniu będzie można doprowadzić do całkowitej kompromitacji domeny Active Directory.
Przeprowadzenie ataku
W celu przeprowadzenia ataku potrzebne nam będą dwa narzędzia (skrypty napisane w języku Python) privexchange.py oraz ntlmrelayx.py. Oba znajdują się w repozytorium autora na stronie GitHub pod nazwą PrivExchange. Wymagane jest pobranie i zainstalowanie narzędzia impacket, bez którego powyższe skrypty nie będą w stanie poprawnie funkcjonować. Atak privExchange może być przeprowadzony w dwóch scenariuszach:
- Wykorzystując login i hasło istniejącego użytkownika w sieci (skrypty privexchange.py oraz ntlmrelayx.py)
- Bez jakichkolwiek poświadczeń użytkownika (skrypt httpattack.py)
Pierwsze co musimy zrobić to uruchomić skrypt napisany w python o nazwie „ntlmrelayx.py” w celu przetransmitowania i eskalacji uprawnień użytkownika „ofiara” za pomocą LDAP na kontrolerze domeny:
Następnie musimy odpalić skrypt w pythonie „privexchange.py”, który po prostu zaloguje się po NTLM w usłudze EWS (Exchange Web Services), w celu zasubskrybowania powiadomienia push (funkcja PushSubscription). Spowoduje to, że Exchange powróci do nas i uwierzytelni się jako użytkownik systemowy.
Dopiero od teraz narzędzie będzie mogło podnieść uprawnienia w AD dla użytkownika użytkownik “ofiara”(bo używa konta systemowego Exchange). Dzięki temu będziemy mogli pobrać hashe kont użytkowników z AD, w tym konto użytkownika krbtgt przy wykorzystaniu narzędzia secretsdump.py
secretsdump.py appeal/[email protected] -just-dc
Od tej pory możemy przeprowadzać atak Golden Ticket lub Pass-the-Hash na Active Directory.
Jak poradzić sobie z problemem?
Przede wszystkim luka PrivExchange wpływa tylko na wdrożenia OnPrem (lokalne) i nie dotyczy usługi Exchange Online.
Po drugie, w systemach, w których wyłączono protokół uwierzytelniania Windows Challenge / Response (NTLM) opisywana podatność nie zadziała, ponieważ jest to jedna z trzech luk wykorzystywanych do wykonania opisywanej eskalacji uprawnień.
Po trzecie, jeśli firma podczas wdrożenia Exchange stosowała się do najlepszych praktyk Microsoft i używa separacji w modelu uprawnień Exchange i AD tzw. „Split Directory Active Directory permissions”, wdrożenia OnPrem będą również odporne na próby wykorzystania PrivExchange.
Firma Microsoft opublikowała poradnik bezpieczeństwa ADV190007 dotyczący środków łagodzących i obejść dla luk w zakresie podniesienia uprawnień, które mają wpływ na wersje Microsoft Exchange 2010 i nowsze. Widzimy w nim, że łatki są planowane w następnych aktualizacjach Exchange odpowiednio w wersjach:
- Microsoft Exchange Server 2010 Service Pack 3 Update Rollup 26
- Microsoft Exchange Server 2013 Cumulative Update 22
- Microsoft Exchange Server 2016 Cumulative Update 12
- Microsoft Exchange Server 2019 Cumulative Update 1
Co z podatnymi środowiskami Exchange?
W celu rozwiązania problemu w podatnych środowiskach Exchange, można zdefiniować i zastosować w odniesieniu do organizacji zasady ograniczania przepustowości w parasmetrze EWSMaxSubscriptions modyfikując jego wartość na zero.
Jednym ze sposobów zapobiegania wyciekowi przez serwer EWS poświadczeń NTLM serwera Exchange jest blokowanie tworzenia subskrypcji EWS. Ale UWAGA – zapobiegnie to wysyłaniu przez serwer Exchange powiadomień EWS i uniemożliwi normalne działanie aplikacji klienckich, które polegają na powiadomieniach EWS. Przykłady wpływowych aplikacji to: Outlook dla komputerów Mac, Skype dla firm, aplikacje LOB oparte na powiadomieniach oraz niektórzy natywni klienci poczty e-mail iOS.
Zmiana również zmniejszy liczbę połączeń EWS obsługiwanych przez serwer. Ponieważ zasady ograniczania przepustowości mogą być stosowane na jednego użytkownika, możliwe jest dodawanie do białej listy zaufanych użytkowników, którzy wymagają funkcjonalności EWS.
Najlepiej przetestować te zmiany w lab zanim wprowadzicie je na produkcję.
W celu uniknięcia tworzenia subskrypcji EWS, wykonać należy następujące kroki:
-
Stworzyć politykę dla organizacji Exchange blokującą wszystkie subskrypcje EWS:
`New-ThrottlingPolicy -Name NoEwsSubscriptions -ThrottlingPolicyScope Organization -EwsMaxSubscriptions 0`
-
Odfiltrować zaufanych użytkowników, dla których musi funkcjonować subskrypcja EWS:
`New-ThrottlingPolicy -Name AllowEwsSubscriptions -ThrottlingPolicyScope Regular -EwsMaxSubscriptions 5000`
-
Przypisać polityki do tych użytkowników:
`Set-Mailbox User1 -ThrottlingPolicy AllowEwsSubscriptions`
Ponadto warto rozważyć następujące kroki w celu zabezpieczenia środowiska i podobnych sytuacji na przyszłość:
- Usunąć niepotrzebne wysokie uprawnienia Exchange, które posiada na domenie AD
- Przeprowadzić i monitorować audyt zmian w uprawnieniach na obiekcie domeny
- Zablokować możliwość pobierania hashy z komputerów w sieci niż tylko te dozwolone
- Zablokować serwery Exchange przed nawiązywaniem połączeń ze stacjami roboczymi na dowolnych portach
- Włączyć rozszerzoną ochronę uwierzytelniania dla aplikacji klienckich na Exchange w IIS
- Usunąć klucz rejestru, który umożliwia przekazywanie poświadczeń z powrotem do serwera Exchange CVE-2018-8518
- Wymusić podpisywanie SMB na serwerach Exchange (a najlepiej na wszystkich innych serwerach i stacjach roboczych w domenie), aby zapobiec atakom, które nawzajem mogą przekazywać poświadczenia przez do SMB
- Zabezpieczyć środowisko wprowadzając restrykcje uwierzytelniania NTLM opisane w tych trzech artykułach:
Pozdrawiamy,
Zespół Kapitan hack