LDAP Security: LdapEnforceChannelBinding

Gegen Fälschen von LDAP-Aktionen helfen digitale Signaturen und Verschlüsselung. Seit 2017 hat Microsoft dazu über ein Update der Clients und Server die Funktion dafür bereit gestellt aber noch nicht erzwungen. Mit dem Windows Update im März 2020 werden Domain Controller nun zumindest LDAP-Signierung erzwingen. Prüfen Sie ihre Umgebung, ehe etwas nicht mehr geht.

Update
Am 17.Dez hat Microsoft ein Update gepostet, dass die Änderung erst im März 2020 verteilt wird
ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

Keine Panik aber Kontrolle

Per LDAP fragen nicht nur Exchange Server den Domain Controller nach der Mailadresse von Empfänger ab, sondern LDAP ist das Protokoll zu Verwaltung eines Active Directory. Administratoren und Domänen-Administratoren legen damit Benutzer an, setzten Kennworte zurück, verwalten Gruppenmitgliedschaften und vieles mehr.

Damit sind LDAP-Verbindungen ein interessantes Ziel diese zu kapern. Es ist im gleichen LAN durch "ARP-Spoofing" u..a Techniken gar nicht mal so schwer die Verbindungen eines Clients zu einem Server  über eine Relay-Station umzuleiten. Wenn dann Daten nicht verschlüsselt sind, können sie mitgelesen werden. Wenn eine Signierung fehlt, können die Pakete sogar in beide Richtungen verändert werden. Für einen Angreifer ist hier der schreibende Zugriff auf ein Active Directory sehr interessant, um sich eigenen Konten anzulegen oder Gruppenmitgliedschaften zu ändern. Diese Möglichkeit hat Microsoft im Jahr 2017 dazu veranlasst, eigenes ein Security Advisory zu veröffentlichen.

In dem Advisory steht auch, dass Microsoft keine "Workarounds" vorgesehen hat.

Aber es sind auch keine Workarounds erforderlich, denn die Windows Komponenten enthalten schon alle Funktionen. Es ist nur eine Frage der Konfiguration, das die Clients und Server eben verschlüsselt oder zumindest signiert miteinander kommunizieren.

Bis zum Jan 2020 waren die Default-Einstellungen aber so, dass Clients und Server die Signierungen nutzen konnten aber nicht mussten. Durch das Update im Jan 2020 wird nun auf den Domain Controllern diese Standardeinstellung geändert.

Sie könnten natürlich einfach per Gruppenrichtlinie oder REGEDIT den neuen Default wieder auf das alte Verhalten umstellen. Davon rate ich aber ab, denn eigentlich hätten sie schon vor Jahren die sicherere Variante umsetzen können und haben es einfach nicht getan.

Betroffene Systeme und Risiken

Auf den ersten Blick könnten Sie sich entspannt zurücklehnen, denn alle halbwegs aktualisierten Windows Clients und Server sollten damit gar kein Problem sein. Aber so ganz sicher können Sie dann aber nicht sein, denn in fast jeder heterogenen Umgebung gibt es den ein oder anderen Service, der per LDAP sich an die Domain-Controller wendet und ggfls. dann ein Problem bekommt. Mir fallen allein in meinem eigenen Netzwerk ein paar Dinge ein.

  • AntiSpam-Produkte
    Eigentlich hat jede Firma den ein oder anderen Spamfilter zwischen Internet und Mailserver gestellt, der natürlich eine Liste der gültigen Mailadressen benötigt. Nur so kann er ungültige Adressen umgehend ablehnen und erspart sich NDRs an möglicherweise gefälschte Absender. Die meisten Produkte lesen dazu natürlich per LDAP die Mailadressen ihres Exchange Services ein und nutzen dazu LDAP gegen die Domain Controller.
  • VoIP Session Border Controller
    Nutzen Sie VoIP-Gateways oder Session Border Controller, die z.B. per LDAP vom Domain Controller die Rufnummer suchen und basierend den Anruf zu Skype for Business, Teams Trunk oder der alten TK-Technik routen?. Dann sollten Sie sicherstellen, dass dies auch nach dem Januar 2020 weiter wie erwartet funktioniert
  • Scan2Mail
    Jeder Kopierer/Drucker, der was auf sich hält, kann auch Dokumente einscannen und per Mail als PDF/TIFF weiterleiten. Und natürlich kann der Anwender im Firmenadressbuch nach Personen suchen. Die meisten Drucker nutzen dazu ein konfiguriertes Dienstkonto mit Lese-Rechte und LDAP. Ohne Verschlüsselung oder Signierung wird zumindest das Adressbuch nicht mehr funktionieren.
  • Reverse Proxy PreAuth/WebApp Auth
    Es ist gar nicht mal so unüblich, dass Dienste vom Anwender die Anmeldedaten über ein Formular oder Basic Authentication im Klartext erfragen und dann mit den Zugangsdaten einen "LDAP-Login" gegen einen DC versuchen. Wenn die Anmeldung funktioniert, dann geht die Anwendung von der Gültigkeit aus und gewährt den Zugriff. Solche Techniken habe ich bei Proxy-Servern (Apache), aber auch Firewall (z.B. Sophos. Siehe auch Azure ATP) schon gefunden und es gibt sicher noch viele andere Einsatzfälle
  • Provisioning, 3rd Party Apps, ...
    LDAP ist ein einfach und universell nutzbares Protokoll und so ist anzunehmen, dass es noch viele andere Dienste in ihrem Netzwerk geben könnte.

Meine Liste kann gar nicht vollständig sein, sonst müsste ich alle Kunden der letzten abklopfen und das sind eine Menge.

Microsoft selbst hat eine umfangreiche Beschreibung auf folgender Seite publiziert

Aktuell sollte der Default auf "Signing offered" stehen, d.h. der Domain Controller bietet Signing an und akzeptiert auch solche Verbindungen. Er akzeptiert aber auch noch nicht signierte Verbindungen. Das wird sich zum Januar 2020 geändert haben, es sei denn wie überschreiben dies manuell.

Auswerten

Die Zeit läuft, denn das Update am Januar 2020 für längere Zeit anzuhalten ist keine Option. Ich rate auch davon ab, das alte Verhalten per Konfiguration wieder zu aktivieren und damit das Thema zu verschieben und letztlich zu vergessen. Um das Risiko aber zu minimieren, müssen wie wissen, welche Clients per LDAP mit den Domain Controllern kommunizieren und welche dieser Clients noch die schwache Authentifizierung nutzen. Diese Daten landen nämlich seit Windows 2008 im Eventlog.

Damit bekommen Sie einen ersten Eindruck, ob es solche Endgeräte gibt.

Die Meldung sollte einmal in 24h kommen, wenn sich ein Client "unsicher" angemeldet hat. Schon an diesem Beispiel sehen sie aber die Problematik, dass hier zwischen zwei Meldungen auch einige Tage, Wochen oder Monate liegen können. Sie finden So also nur Client, die regelmäßig den "schwachen Weg" nutzen. Hier ein Event im Detail:

Log Name:      Directory Service
Source:        Microsoft-Windows-ActiveDirectory_DomainService
Date:          19.09.2019 00:08:11
Event ID:      2886
Task Category: LDAP Interface
Level:         Warning
Keywords:      Classic
User:          ANONYMOUS LOGON
Computer:      DC1.msxfaq.de
Description:
The security of this directory server can be significantly enhanced by configuring the server 
to reject SASL (Negotiate, Kerberos, NTLM, or Digest) LDAP binds that do not request signing 
(integrity verification) and LDAP simple binds that are performed on a clear text 
(non-SSL/TLS-encrypted) connection.  Even if no clients are using such binds, configuring the 
server to reject them will improve the security of this server. 
 
Some clients may currently be relying on unsigned SASL binds or LDAP simple binds over a 
non-SSL/TLS connection, and will stop working if this configuration change is made.  
To assist in identifying these clients, if such binds occur this directory server will 
log a summary event once every 24 hours indicating how many such binds occurred.  You are 
encouraged to configure those clients to not use such binds.  Once no such events are observed 
for an extended period, it is recommended that you configure the server to reject such binds. 
 
For more details and information on how to make this configuration change to the server, 
please see http://go.microsoft.com/fwlink/?LinkID=87923. 
 
You can enable additional logging to log an event each time a client makes such a bind, 
including information on which client made the bind.  To do so, please raise the setting 
for the "LDAP Interface Events" event logging category to level 2 or higher.

Der Link in der Beschreibung geht auf:

Sie wissen aber noch nicht, welche Endgeräte es sind. Um diese Information zu erhalten, müssen Sie die Diagnose-Funktion auf den DCs etwas anheben. Per Regedit, per Kommandozeile oder REG-Datei

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 2
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
"16 LDAP Interface Events"=dword:00000002

Die Änderungen werden ohne Neustart aktiv!

Nun warten Sie einfach auf Events mit der Nummer 2888 und 2889.

Dieses Logging kann den Server etwas mehr beanspruchen und sie sollten überlegen, wie sie diese gewonnene Information möglichst schnell auswerten. Sie können an Eventslogs einfach einen "geplanten Task" anbinden, der gestartet wird und ihnen z.B. eine Mail sendet. Wer bisher schon eine Auswertung von Eventlogs vornimmt, kann in seinen historischen Logs rückwirkend suchen oder leistungsfähigere Möglichkeiten nutzen.

Theoretisch könnten Sie auch per NetFlow/sFlow/IPFix/cFlow erkennen, wer sich mit Port 389 verbindet, was per se schon mal unerwünscht sein kann. Mit WireShark (vormals Ethereal) könnten Sie sogar die so in Klartext ausgehandelten Pakete analysieren. Das ist aber alles nicht zielführend.

Vergessen Sie aber nach der Analyse das Debugging nicht wieder abzuschalten, indem Sie den Wert auf "0" setzen

Reg Add HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics /v "16 LDAP Interface Events" /t REG_DWORD /d 0
Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics]
"16 LDAP Interface Events"=dword:00000000

Auch über den "Global Catalog" ist ein Zugriff per LDAP möglich. Allerdings ist ein GC nur "Read Only" erreichbar und so ein weniger lohnendes Ziel. Dennoch sollten sie auch hier den Wechsel auf SSL fordert, denn in Klartext übertragene Kennworte könnten auch hier mitgelesen werden-

Umsetzen

Wir können nur hoffen, dass Sie das Logging möglichst schnell einschalten und sie in den wenigen Wochen bis zum Release des Updates zumindest die kritischen Dienste im Protokoll erscheinen, die sie unbedingt noch umstellen müssen. Meist reicht es ja auf LDAPS zu wechseln. Aufgrund der Vielzahl an Client und Produkte kann ich hier leider keine allgemeingültige Beschreibung liefern. Produkte, die auf der ADSI-Schnittstelle aufsetzen, sind in der Regel unkritisch und sollten von alleine arbeiten. Hier kann es eher zu Problemen kommen, wenn sie per Gruppenrichtlinien das LDAP-Signing verboten haben.

Über Gruppenrichtlinien können Sie das Verhalten der Clients als auch der Server kontrollieren. Wenn hier nichts konfiguriert ist, dann kommen die Defaults zu tragen.

Bis Januar bedeutet dies, dass jeder kann aber niemand muss. Ab Januar 2020 interpretiert ein Domain Controller die "rote Zeile" nicht mehr als "kann" sondern "muss". Sie können die Einstellung natürlich überscheiben. Zur Wahl steht aber nur "None" oder "Require Signing" aber nicht das "kann aber muss nicht". Das Bild ist von einem DC im Dezember 2019 und es könnte sein, dass das Update hier die Vorlage noch um ein "optional" erweitert.

Ansonsten können Sie den Wert ganz ohne Gruppenrichtlinie natürlich auch mit REGEDIT setzen. So setzen Sie für den Server als auch den Client ein "muss signieren"

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"LDAPServerIntegrity"=dword:00000002
"LdapEnforceChannelBinding"=dword:00000002

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\ldap\Parameters]
"LdapClientIntegrity"=dword:00000002

Die Werte für einen ADLDS-Server, früher ADAM genannt, sind unter "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\\Parameters" zu finden.

Alternative Werte sind 0=Keine Signierung oder 1=Optional (Default)

LDAP Signing Group Policy - No Downtime After installing ADV190023 both settings (even None and Not Defined) will enforce Require Signature Only 0 (OFF) will not enforce Require Signatu

LdapEnforceChannelBindings

Im Titel und einigen Webseiten wird aber auch der Parameter "LdapEnforceChannelBindings" genannt, der meines Wissens (Stand Dez 2019) noch nicht per Gruppenrichtlinie zu setzen ist. Der Wert kann aber per Regedit auf den Domain Controllern eingetragen werden. Er bestimmt, wie der LDAP Server eines Domain Controllers oder ADAM-Service mit dem Thema Signierung bei der Anmeldung umgeht. Die wesentlichen Informationen stehen auf:

Er kann drei Werte annehmen oder nicht vorhanden sein.

Wert Bedeutung

Nicht gesetzt (Default)

Normalerweise ist der Wert nicht vorhanden und der LDAP-Server setzt die im Code hinterlegten Defaults ein. Bis zum Januar 2020 entsprach das der "0" und mit dem Update wurde ein "2" draus

0 (Disabled, Default)

Funktion ist deaktiviert, dass der Server aktiviert kein "Channel binding" und ist der Default bei allen Servern, die nicht aktiviert wurden.

1 (Enabled)

Channel binding Tokens (CBT) sind für alle Clients erforderlich, die diese Funktion unterstützen. Normal verbindet sich ein Client per LDAP und meldet mit, welche Funktionen er unterstützt. Das ist natürlich kein echter Schutz, da ein Angreifer auch diesen ersten Handshake unterbinden kann.

2 (Enforced)

In dieser Einstellung werden alle Clients gezwungen, Channel binding Tokens (CBT) zu nutzen.

Damit ist klar, dass Sie mit einem Setzen des Werts auf "0" das alte aber unsichere Verhalten wieder aktivieren.

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\NTDS\Parameters]
"LdapEnforceChannelBinding"=dword:00000000

Ich würde diese Einstellung im Hinterkopf haben, um Sie im Notfall, und wirklich nur dann, auf den DCs nach dem Januar 2020 Update temporär wieder zu aktivieren.

Weitere Links