Zmiany w obsłudze komunikacji LDAP - część 1/5

W opublikowanym 13 sierpnia 2019 roku biuletynie informacyjnym ADV190023[1], Microsoft wskazał najnowsze rekomendacje zabezpieczeń dla połączeń protokołu LDAP, które mają podnieść bezpieczeństwo komunikacji pomiędzy kontrolerami domeny Active Directory oraz klientami usługi. Obok rekomendacji zapowiedziana została również poprawka zabezpieczeń dla systemów Windows Server, której zastosowanie będzie skutkować zmianą domyślny ustawień na zgodne z wytycznymi.

Microsoft zaleca administratorom jak najszybsze wprowadzenie zmian podnoszących poziom zabezpieczeń opisanych w powyższym biuletynie manualnie, ponieważ podczas korzystania z ustawień domyślnych w systemie Windows istnieje luka zabezpieczeń dotycząca podnoszenia uprawnień, która może pozwolić na atak typu „man-in-the-middle”[2] i pomyślne przesłanie dalej żądania uwierzytelnienia do serwera LDAP systemu Windows (takiego jak system z uruchomioną usługą AD DS lub AD LDS), którego nie skonfigurowano do wymagania podpisywania lub pieczętowania połączeń przychodzących. 

Zabezpieczenia serwera katalogowego można znacznie poprawić, konfigurując serwer do odrzucenia powiązań LDAP w ramach mechanizmu Simple Authentication and Security Layer (SASL)[3], które nie żądają podpisywania (weryfikacji integralności) lub do odrzucania prostych powiązania LDAP[4] wykonywanych na połączeniach, w których dane są przesyłane w postaci zwykłego tekstu (bez szyfrowania SSL/TLS). Mechanizmy SASL mogą zawierać protokoły, takie jak Negotiate, Kerberos, NTLM czy Digest. Niepodpisany ruch sieciowy jest podatny na powtórne ataki[5], w których intruz przechwytuje próbę uwierzytelnienia i wystawienie biletu. Intruz może ponownie wykorzystać bilet do podszycia się pod uprawnionego użytkownika. Ponadto niepodpisany ruch sieciowy jest podatny na ataki „man-in-the-middle”, w których intruz przechwytuje pakiety między klientem a serwerem, zmienia pakiety, a następnie przesyła je do serwera. Jeśli taka sytuacji zdarzy się na serwerze LDAP, osoba atakująca może spowodować, że serwer będzie podejmować decyzje oparte na sfałszowanych żądaniach pochodzących od klienta LDAP.

W następnych częściach serii pokażę jak wsadowo zweryfikować bieżące ustawienia na kontrolerach domeny, a także metody monitorowania i wsadowej obróbki logów dotyczących (wkrótce niewspieranych) połączeń LDAP. 

Źródła:

• [1] Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing –  https://portal.msrc.microsoft.com/en-US/security-guidance/advisory/ADV190023
• [2] Man in the Middle – https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-sstp/4a6778bc-a4a9-46c6-9120-7493c61f95e5
• [3] SASL Authentication – https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/989e0748-0953-455d-9d37-d08dfbf3998b
• [4] LDAP simple bind – https://docs.microsoft.com/en-us/openspecs/windows_protocols/ms-adts/b645c125-a7da-4097-84a1-2fa7cea07714#gt_49986978-abd0-4f77-b04c-c221098e3fef
• [5] Kerberos replay attack – https://docs.microsoft.com/pl-pl/windows/security/threat-protection/auditing/event-4649