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 18. Aug 19 hat Microsoft erstmalig über eine anstehende verschärfte Sicherheitseinstellung informiert. Am 28.2 gab es Update, das die Umsetzung nicht schon im Jan 2020 oder März 2020 sondern erst im 2.HJ 2020 aktiv wird
ADV190023 | Microsoft Guidance for Enabling LDAP Channel Binding and LDAP Signing
https://portal.msrc.microsoft.com/en-us/security-guidance/advisory/ADV190023

Was funktioniert nach der Änderung?

Es gibt verschiedene Artikel und viele sind nicht ganz klar oder irreführend. Microsoft möchte eigentlich nur sicherstellen, dass "Man in the Middle"-Angriffe nicht mehr möglich sind. Wenn sich heute ein Client per LDAP einfach so mit dem DC verbindet und sich anmeldet, kann er per LDAP auch Einstellungen im Rahmen seiner Berechtigungen ändern. Wenn diese Kommunikation nun nicht verschlüsselt oder signiert ist, dann kann ein "böser Teil" sich in die Verbindung einklinken und die Befehle anpassen. Sie wollen als Admin z.B. einen Benutzer in eine Gruppe addieren und der Angreifer schreibt das Paket einfach um, damit sein User in die Gruppe der Domänen Administratoren aufgenommen wird. Das wollen Sie nicht. Am besten verhindern Sie dies durch einen durchgängig verschlüsselt und signierte Verbindung per LDAP over SSL. Aber das muss nicht sein, denn auch bei einer LDAP-Verbindung ohne Verschlüsselung kann "signiert" werden. Das machen auch schon alle Windows Clients aber eben nicht alle LDAP-Clients. Ein Multi-IO-Gerät, welches Dokumente scannt und per Mail sendet und dazu per LDAP ein Adressbuch liest, macht das nicht.

Anmeldeverfahren Port LDAP/GC Bisher Ab Herbst 2020
LdapServerIntegrity aktiv

Simple Bind

389/3268

Ja

Nein

Simple Bind mit TLS

636/3269

Ja

Ja

Unsigned SASL

389/3268

Ja

Nein

SASL over TLS

636/3269

Ja

Ja

SASL + LDAP Encryption

389/3268

Ja

Ja

Von den fünf hier gelisteten Anmeldeverfahren fallen also die beiden Zugänge weg, die weder TLS noch LDAP-Signierung nutzen.

Leider ist genau das erste Verfahren das am meisten von 3rd Party Programmen genutzte Verfahren, wenn Sie irgendwo einen LDAP-Server einfach so mal eingetragen haben

Jeder Weg über einen TLS-Verschlüsselung funktioniert problemlos- Allerdings bedeutet dies auch "Arbeit" mit Zertifikaten auf den Domain Controllern.

..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

LdapEnforceChannelBinding

Im Titel und einigen Webseiten wird aber auch der Parameter "LdapEnforceChannelBinding" genannt. Der Wert kann per Regedit oder Gruppenrichtlinie 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.

Verifikation mit LDP.EXE

Ein möglicher Weg die verschiedenen Anmeldungen an einem LDAP-Server zu testen ist das Programm LDP.EXE. Dieses recht rudimentäre Programm erlaubt doch allerlei Einstellmöglichkeiten bei LDAP-Verbindungen.

  • TCP oder SSL beim Connect
    Zuerst müssen Sie eine Verbindung mit dem Server herstellen. Neben dem Port können Sie hier auch manuelle SSL akivieren

    Wir können also gezielt uns per 389/TCP oder 636/TLS verbinden
  • Authentifizierung
    Nach der anonymen Verbindung kommt dann die Anmeldung. Auch hier gibt es unterschiedliche Verfahren und eine optionale Verschlüsselung.

Mit diesen verschiedenen Optionen kann man spielen und am Ende folgende Tabelle erstellen. Die erster Anmeldung erfolgt Anonym als 'NT-AUTORITÄT\ANONYMOUS-ANMELDUNG', die zweite Anmeldung nutzt explizit "Simple Bind" und die dritte Anmeldung dann die "integrierte" Anmeldung.

LdapEnforceChannelBinding Connection Anonym Simple Bind Unsigned SASL Integriert Beschreibung

0 (Kein Signing)

389

OK

OK

OK

OK

Ohne Zwang und ohne Verschlüsselung ging bislang alles. Kritisch sind die beiden gelben Felder, da hier Zugangsdaten abgegriffen oder Aktionen verändert werden könnten

636

OK

OK

OK

OK

Mit LDAPS lösen sich die beiden kritischen Fälle, da die Verbindung nun verschlüsselt und signiert ist.

1 (Signing optional)

389

OK

OK

OK

OK

Wenn der Server ein Signing anbietet, dann erzwingt er es nicht. Die Clients sollten es nutzen

636

OK

OK

OK

OK

Über LDAPS sorgt die Verschlüsselung dafür, dass Inhalte nicht verändert werden können.

2 (Signing erforderlich)

389

OK

Error 0x2028

Error 0x2028

OK

Sobald der Server eine Signierung erfordert, sind die einfachen Anmeldeverfahren aus dem Rennen. Nur die besseren Anmeldeverfahren, die auch eine LDAP-Signierung unterstützen funktionieren weiter

636

OK

OK

OK

OK

Erst durch den Wechsel zu LDAPS sind auch wieder die einfahren Verfahren möglich.

Die graue "anonyme Anmeldung" geht immer. Hier ist aber auch keine Gefahr, da keine Anmeldedaten oder Aktionen übertragen werden. Interessanter sind die gelben Zugriffe, die heute schon ein Risiko darstellen. Solche unsicheren Zugriffe sind bislang möglich. Nachdem der Wert für "LdapEnforceChannelBinding" auf 2 gesetzt wurde, werden diese Zugriffe mit dem folgenden Fehler verweigert:

Error 0x2028 Eine sicherere Authentifizierungsmethode wird für diesen Server benötigt.

Sie sehen aber auch, dass mit einer entsprechend "sicheren" Anmeldung und LDAP Signierung der Pakete auch weiterhin ein Zugriff über Port 389 möglich ist. Nur schwache Anmeldeverfahren sind ausgesperrt.

Am Besten fahren sie also mit einer LDAPS-Verschlüsselung. Allerdings müssen dann nicht nur die Clients LDAPS unterstützen. Als Admin müssen Sie auf den Domain Controllern entsprechende Zertifikate vorhalten und regelmäßig aktualisieren.

Zertifikate für Domaincontroller

Ich bin sicher, dass bei den meisten Firmen irgendwelche Client mit "Simple Bind" arbeiten. Auf der anderen Seite wird die IT Security die höhere Sicherheit anfordern. Dann bleibt ihnen nur die Option diese Geräte auf LDAPS umzustellen. Sollten die wenigen Clients das aber nicht unterstützen, dann können Sie diese nur abschalten, ersetzen oder sie lassen weiterhin einen LDAP-Server mit schwacher Absicherung laufen, der dann aber nur noch von diesen Geräten erreicht werden kann. Dazu eignen sich Firewalls und VPNs. Ziel muss aber der Wechsel auf LDAPS sein.

Dafür brauchen Sie aber Zertifikate auf dem Domain Controller. Natürlich könnten Sie nun öffentliche Zertifikate für jeden DC kaufen oder sogar ein "Wildcard" für die Domain. Das geht aber nur, wenn ihr DNS-Name der Domäne auch öffentlich ist. Sie müssen ja den Besitz nachweisen. Das ist aber mit Zeit und Kosten verbunden aber hat den Vorteil, dass fast alle Clients der ausstellenden PKI vertrauen.

Eine Alternative ist die Nutzung einer eigenen PKI für die Ausstellung von Computerzertifikaten. Da ist einfacher und nicht unsicherer, wenn Sie ein paar Dinge beachten. In Kurzfassung:

  • AD integrierte RootCA installieren
    Sie suchen sich einen Member-Server oder wegen mir auch einen Domain Controller, auf dem Sie die Windows Zertifikatsdienste installieren.
  • Sie passen die CA so an, dass sie NUR DomainController-Zertifikate ausstellt
    Sie entfernen dazu einfach alle anderen Templates. Aufgabenstellungen wie Key-Archiv, Key Recovery etc. umgehen Sie elegant. Später können Sie die PKI noch erweitern, dass Sie auch noch allgemeine Computerzertifikate ausstellt. So können Sie dann später ihr VPN oder 802.1x noch auf Zertifikate umstellen und die Sicherheit erhöhen
  • Autoenrollment
    Über das Template und eine Gruppenrichtlinie können Sie steuern, dass die Domain Controller automatisch ein Zertifikat anfordern und nach einem Jahr auch wieder verlängern

Damit sollten die Domain-Controller ein gültiges Zertifikat für ihren Namen haben und der LDAP-Dienst dieses auch nutzen. Eine umfangreichere Beschreibung finden Sie auf den weiteren Links

Weitere Links