NTLM jest jednym z popularnych protokołów używanych przez komputery z systemem Windows do uwierzytelniania się w sieci. Jego wersja druga stworzona została przez Microsoft i wypuszczona na świat razem z premierą Windows 2000. Skrót NTLM tłumaczy się jako „New Technology Lan Manager”, jednak obecnie nazwa ta nie jest zbyt aktualna i używa się po prostu skrótu NTLMv2.

Jako że działanie protokołu opracowano 20 lat temu, zawiera on wiele podatności i może być w stosunkowo prosty sposób wykorzystany przez atakujących do przejęcia poświadczeń. Aktualnie zaleca się stosowanie nowszego i bezpieczniejszego protokołu Kerberos, jednak nie wszędzie jest to możliwe. O protokole Kerberos i jego działaniu pisaliśmy między innymi tutaj.


Zasada działania NTLM

NTLMv2 jest protokołem typu challenge-response. Znaczy to tyle, że komputerowi, który chce uwierzytelnić się do jakiejś usługi na innym serwerze, wysyłany jest losowy ciąg znaków, który musi zostać prawidłowo zaszyfrowany własnym hasłem (LM hash) i odesłany w celu weryfikacji do serwera hostującego usługę. Dla komputerów niebędących w domenie wygląda to następująco:

Cały proces uwierzytelniania NTLM można rozbić na kroki:

  1. Komputer kliencki wysyła zapytanie zawierające parametry połączenia w celu uzyskania dostępu.
  2. Serwer przesyła „challenge”, który jest losowym 16-bajtowym ciągiem znaków wygenerowanym i znanym przez serwer.
  3. Klient szyfruje ciąg znaków swoim hash’em i przesyła go z powrotem.
  4. Serwer posiada hash klienta, dlatego może zdeszyfrować odpowiedź i sprawdzić, czy jest zgodna z oryginałem. Jeśli tak, to przyznaje dostęp do zasobu.

W uwierzytelnianiu domenowym różnica polega na tym, że pytany serwer nie przetrzymuje hash’y użytkowników oraz komputerów i to nie on weryfikuje poprawność autoryzacji. Rolę tę przejmuje kontroler domeny, natomiast serwer hostujący usługę jest tylko pośrednikiem w uwierzytelnianiu, który przesyła nazwę konta, losowy ciąg znaków oraz zaszyfrowany challenge do kontrolera domeny w celu weryfikacji.

Jak łatwo można zauważyć, zaletą uwierzytelniania NTLMv2 jest to, że klienci mogą uwierzytelniać się do serwera bez konieczności wysyłania swojego hasła czystym tekstem ani nawet skrótu tego hasła (hash). W 2000 roku była to prawdziwa innowacja, teraz to standard. Wadą oraz ryzykiem stosowania tej metody jest to, że każdy kto przechwyci wysyłany 16-bajtowy ciąg znaków oraz odpowiadający mu zaszyfrowany ciąg znaków, może próbować złamać szyfrowanie offline, zgadując hasło i sprawdzając, czy deszyfrowanie działa poprawnie. O łamaniu hash’y pisaliśmy tutaj.


Atak przekaźnikowy (relay)

Opiszemy teraz bardziej wyrafinowany rodzaj ataków na NTLM niż crackowanie hash’y offline. Chodzi o technikę o nazwie NTLM relay, co w wolnym tłumaczeniu oznacza „przekaźnik NTLM”.
Do przeprowadzenia tego ataku cyberprzestępca musi znajdować się w odpowiedniej pozycji w sieci. Musi być w stanie połączyć się z serwerem, do którego zwykle uwierzytelnia się klient. Atak przebiega następująco. Kiedy klient wykona próbę uwierzytelniania się do komputera atakującego, ten spróbuje uwierzytelnić się do serwera docelowego w imieniu klienta. Otrzymany ciąg znaków do zaszyfrowania również przekazywany jest przez atakującego do klienta. Klient wykonuje robotę, wysyła zaszyfrowany ciąg do atakującego, ten przekazuje go do serwera i otrzymuje informacje zwrotną, że dostęp został przyznany, jednak do samego klienta przesyłana jest informacja o odrzuceniu dostępu. Poniżej obrazek przedstawiający opisywaną komunikacje.


Przykład wykorzystania tej metody ataku opisaliśmy w naszym artykule o przejęciu hashy NTLM z poziomu złośliwego dokumentu PDF wykorzystując podatność w uwierzytelnieniu do usługi SMB.

Cała koncepcja ataku przekaźnikowego jest prawie tak stara, jak sama technologia NTLM. Dlatego Microsoft wprowadził kilka zabezpieczeń, które, jeśli są poprawnie wdrożone i używane przez wszystkie stacje klienckie i usługi, to wykonanie tego ataku staje się niemożliwe. Chodzi przede wszystkim o dwa zabezpieczenia: MIC (Message Integrity Code) oraz EPA (Extended Protection for Authentication). Pierwsze z nich dodaje podpis cyfrowy do przekazywanej przez serwer wiadomości NTLM, przez co nie może być wysłana z innego serwera pośredniczącego w komunikacji. Drugie zabezpiecza serwery webowe, takie jak OWA czy ADFS, aby akceptowały tylko zapytania o dostęp ze znanych urządzeń, a dokładniej ze znanych kanałów komunikacyjnych.

Jak się okazuje i te zabezpieczenia zostały złamane pod koniec września 2019r., a Microsoft musiał wypuścić aktualizacje, które zawierają poprawki do opisywanych mechanizmów zabezpieczeń. Szczegóły podatności poniżej.


Podatność CVE 2019-1166 – Drop The MIC 2

MIC to opcjonalne pole w wiadomości NTLM, które zapobiega ingerowaniu przez atakujących w wiadomość oraz przesyłanie jej dalej jako pośrednik. Jest czymś w rodzaju podpisu cyfrowego, którego używają klienci w celu zabezpieczenia się przed przechwytywaniem komunikacji NTLM. Pierwsza wersja tego exploita pokazała prostotę zabezpieczenia i polegała tylko na usunięciu pola MIC wraz z flagą „msvAvFlag”, co powodowało, że wiadomość nie była sprawdzana pod kątem integralności.
Podatność ta została szybko załatana w czerwcu 2019 roku, jednak teraz opracowano jej ulepszoną wersję – Drop The MIC 2. Techniczna strona podatności jest dość skomplikowana i należy wcześniej wyjaśnić szczegółowo, jak wygląda ciało wiadomość NTLM_AUTHENTICATE. Nie będziemy tego robić. O samej podatności można przeczytać tutaj, na stronie autorów.
Dodamy tylko, że najnowsze poprawki MS z początku października 2019 łatają tę podatność. Bez aktualizacji, jesteśmy wrażliwi na przykład na atak przekaźnikowy na sesję SMB.


Podatność CVE-2019-1338 – Exploiting LMv2 Clients

Większość komputerów chcących uwierzytelnić się poprzez NTLM nie wysyła dziś odpowiedzi LM czy LMv2 podczas sesji, gdyż uważane jest to za zbyt mało bezpieczne. Istnieje jednak wiele aplikacji, które używane są powszechnie i stosują tę przestarzałą metodę, np. Firefox na maszynach z systemami MacOS oraz Linux. Nie jest żadną tajemnicą, że przeprowadzenie ataku brute-force na odpowiedzi LMv2 jest rzeczą trywialną, jednak ostatnio badacze podatności odkryli, że wysyłanie przez klientów jednocześnie odpowiedzi LMv2 jak i NTLMv2 może doprowadzić nawet do kompromitacji domeny! Atakujący znaleźli sposób, że przy domyślnej konfiguracji domeny obchodzone są mechanizmy mitygacji takie jak MIC, EPA czy walidacja SPN. Wszystko dlatego, że domyślnie kontroler domeny nie weryfikuje odpowiedzi NTLMv2, jeśli obecna jest także LMv2. Techniczne szczegóły tego exploitu tutaj.
Podatność również została załatana w najnowszej aktualizacji Microsoftu.


Co możemy zrobić?

Aby zminimalizować ryzyko i chronić swoją sieć przed atakami dotykającymi uwierzytelniania NTLM powinniśmy:

  • Wgrać najnowsze poprawki Microsoft łatające nowo wykryte podatności!
  • Niektóre aplikacje czy klienci, używają nadal niezabezpieczonego NTLM (np. nie wysyłają MIC). Należy szczególnie monitorować ruch NTLM między tymi urządzeniami.
  • 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.
  • Spróbować zredukować używanie NTLM ogólnie w naszym środowisku sieciowym, zastępując go protokołem Kerberos.

Podsumowanie

Chociaż ataki typu relay na protokół NTLM są znane od dawna i Microsoft wprowadził wiele zabezpieczeń, aby je uniemożliwić, to jak widzimy, hackerzy oraz badacze security znajdują coraz to nowe sposoby ich obejścia. Poza tym, opcje rekomendowane przez Microsoft nie zawsze mogą być użyte we wszystkich aplikacjach i systemach, ponieważ zwyczajnie nie są wspierane. Pozostawia to w naszej sieci zasoby wrażliwe na opisywane ataki.

Podziel się z innymi tym artykułem!