LDAP Security

Über das Protokoll LDAP werden sehr viel auch für Angreifer interessante Informationen übertragen oder zugänglich gemacht. Diese Seite thematisiert die "Sicherheit" zu LDAP.

LDAP Security

Risiken

Über LDAP können nicht nur Spamfilter, Drucker u.a. Geräte z.B. die Mailadressen von Anwendern im Active Directory lesen. Auch Administratoren "verwalten" über LDAP die Objekte und es es einem Angreifer gelänge, hier seine Aktionen einzuschmuggeln oder sogar Zugriffsdaten zu erlangen, dann wäre das Active Directory kompromittiert. Es gibt zwar noch andere Wege wie Kerberos (88/TCP),  RPC (135,137-139/TCP) ADWS (9389/TCP) etc. aber betrachten wir erst einmal LDAP über Port 389/TP, 636/TLS und den Global Catalog über 3268/TCP und 3269/TLS). Folgende Risiken sehe ich in erster Betrachtung:

Vektor Beschreibung Lösung

"Mitlesen"

 Eine einfache Verbindung per LDAP über Port 389 ist erst einmal "unverschlüsselt" und wer z.B. mit WireShark die Verbindung mitlesen kann, sieht nicht nur die Anfragen und Antworten, sondern auch den Anmeldeprozess. Kommen hier dann unsichere Anmeldeverfahren zum Einsatz, dann hat der Angreifer alle Informationen für einen Angriff oder Missbrauch.

Es gibt mehrere Optionen dies abzusichern, die auch kombiniert werden können:

  • Absicherung ist eine Verschlüsselung mittels TLS auf dem Transport
  • Verschlüsselung in der Applikation, z.B. mit LDAP Channel Binding
  • Beschränkung auf "sichere" Anmeldeverfahren bei unverschlüsselten Verbindungen.

Verändern/Replay

Wenn sich der Angreifer "zwischen" den Client und den Server einfügen kann, dann kann er vielleicht die sichere Anmeldung nicht mitschneiden aber z.B. die Nutzdaten dennoch verändern. Der Admin möchte einen Benutzer in einer Abteilungsgruppe addieren aber der Angreifer macht daraus ein "Mein Benutzer in die DomainAdmin-Gruppe addieren.

Solche Veränderungen können durch eine Signierung der Übertragung gesichert werden, z.B. mit:

  • TLS auf dem Transport, welches neben der Verschlüsselung auch eine Signierung sicherstellt.
  • LDAP Signing
    Verhindert die Veränderung auf Applikationslevel

DoS

Zuletzt kann ein Angreifer natürlich einfach den erreichbaren TCP-Port mit Paketen, Verbindungsversuchen und Anmeldeversuchen belasten.  Zu viele Fehlerversuche bei der Anmeldung können z.B. das Konto sperren.

Der Schutz hiergegen ist Aufgabe einer zwischen Angreifer und LDAP-Service agierenden Firewall z.B. mit einer PreAuth-Prüfung. Auf dieses Risiko gehe ich auf dieser Seite nicht weiter ein.

LDAP-Lücke

Software ist nie fehlerfrei und daher ist davon auszugehen, dass in jedem LDAP-Server, sei es ein Windows Active Directory aber auch ein OpenLDAP-Server o.a. noch unterkannte Lücken schlummern, die irgendwann auffallen oder erst durch ein Updates sogar Einzug erhalten.

Halten Sie ihre Server möglichst aktuell und abonnieren Sie die Nachrichtenkanäle der jeweiligen Hersteller. Auf dieses Risiko gehe ich auf dieser Seite nicht weiter ein.

Client

Eine "Integrierte" Anmeldung ist immer bevorzugt, weil der Anwender dann nicht nur einfacher und schneller auf den Service zugreifen kann, sondern jede Kennworteingabe könnte auch ein Phishing-Versuch sein und sollte reduziert werden. Wenn hier dann ein Angreifer natürlich den Client übernommen hat, dann kann er auch "als dieser User" arbeiten.

Für den Schutz der Clients sind die gängigen Endpoint Protection Lösungen, z.B. Antivirenprogramme etc. zuständig. Über Richtlinien können Administratoren z.B. eine "Allow-List" von Programmen vorgebeben die gestartet werden können etc.

Damit sollten die meisten Vektoren beschrieben sein.

Transport oder Applikation

Wenn wir uns rein auf die Verbindung über das Netzwerk konzentrieren, dann spricht ein Client per LDAP mit einem Server. Ich verzichte nun auf das komplette 7-Schicht OSI-Modell und übergehe dinge wie Namensauflösung, ARP-Resolution, IP-Routing, TCP-Handshake etc. und beschränkt mich auf die beiden großen Blöcke:

  • Applikation (Client/Server)
    Der LDAP-Client möchte eine Aktion auslösen und verbindet sich mit dem LDAP-Server auf der anderen Seite, der einfach das Protokoll "LDAP" versteht. Hier ist auch eine Authentifizierung möglich und natürlich kann auch die Anwender selbst die Daten signieren und verschlüsseln, wenn Sie nicht auf den Transport vertraut
  • Transport
    Die Kommunikation zwischen Client und Server erfolgt fast immer über ein Netzwerk und TCP oder UDP over IP. Andere Protokolle vernachlässige ich hier weiter. TCP ist gegenüber UDP gegen Paketverluste und der Reihenfolge abgesichert, d.h. das darauf aufbauende Protokoll kann davon ausgehen, dass der Datenstrom komplett und in der korrekten Abfolge ist aber nicht, dass er unverändert und unlesbar übertragen wurde. Diese Funktion erhalten Sie mit dem Einsatz von TLS, damit Pakete auf dem Kabel verschlüsselt und signiert werden.

Auf beiden Ebenen können Sie aber hinsichtlich einer Absicherung entsprechende Vorkehrungen treffen, um Angreifer auszusperren. Der "Worst Case" ist sicherlich eine Anmeldung per LDAP ober TCP ohne Transportverschlüsselung und ohne Applikationsabsicherung mit einfachen Anmeldedaten. Die präsentieren so die Anmeldedaten auf dem Tablett und sollten sich nicht über Missbrauch wundern.

Unverschlüsselte Verbindungen würde ich nur nutzen, wenn der Client sich gar nicht anmelden muss und der LDAP-Server nur eine ganz beschränkte Menge an Informationen an anonyme Anfragen ausliefert. Die meisten LDAP-Server erlauben eine unverschlüsselte Verbindung ohne Anmeldung, um zumindest die unterstützten Protokolle und Partitionen zu melden. So liefert mein Windows 2022 DC in der MSXFAQDEV-Domain bei der Verbindung per LDP.EXE allein folgende Daten:

Ein interner Angreifer kann so schon einmal erkennen, dass es vermutlich ein DC ist und Informationen über die Zeit, Partitionen, Features, Policies und LDAP-Versionen erhalten. Security by obscurity hat aber noch nie funktioniert und auch ein Mailserver oder Webserver nehmen immer erst einmal Verbindungen an und melden entsprechende Fehler. Schließlich muss ein Client ja wissen, welche Funktionen er aufrufen kann. Bei der Anmeldung kann ich in LDP sehr umfangreich Optionen steuern und sie sehen, dass mein Windows 2022 DC in der Standardkonfiguration über unverschlüsselte Verbindungen keine "Einfache Anmeldung", d.h. "BasicAuth" erlaubt und bei der "besseren" Anmeldung auch eine Verschlüsselung nutzen kann.

Natürlich habe ich mir das auch per Wireshark angeschaut und obwohl der DC die "einfache Anmeldung" ablehnt, kann er nicht den Versuch des Clients verhindern.

Sie sollten als auf jeden Fall die "Simple Bind"-Methode über 389 ohne TLS-Verschlüsselung unterbinden.

Übrigens können Sie natürlich auch auf dem IP-Stack selbst per IPSEC einzelne oder im Extremfall alle Verbindungen verschlüsselt. Das wäre eine dritte Schutzmöglichkeit, die LDAP-Verbindung abzusichern.

LDAP Auditing

Der Domain Controller protokolliert solche Versuche allerdings nicht per Default im "Directory Service"-Eventlog. Es obliegt also dem Client, wie schlecht er seine Kennworte absichert. Als Administrator sollten Sie daher prüfen, ob sie dieses Logging aktivieren und im Eventlog solche Zugriffe auswerten.

Mit dem aktuellen Service Pack ist diese Aktion nicht mehr erforderlich. Es reicht das LDAP-Signing anzubieten, um die Events zu finden

Nur wenn sie noch ganz alte Server haben, lass ich den Key hier noch stehen.

New-ItemProperty `
   -Path 'HKLM:\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics' `
   -Name "16 LDAP Interface Events" `
   -PropertyType DWORD `
   -Value 2 `
   -Force

Oder sie importieren folgende REG-Datei:

Windows Registry Editor Version 5.00

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

Die Änderungen wurden ohne Neustart aktiv. Danach suchen Sie nach den EventID 2889 im Eventlog.

LDAP Absicherung

Wenn Sie schon im Eventlog sind und die aktuellen Updates installiert haben, dann sollten Sie auch die folgenden "Warnungen" sehen, wenn Sie noch die schwächeren Sicherheitseinstellungen haben:

Ein zweiter Eintrag ist: 

Spätestens jetzt sollte es jedem Administrator bewusst sein, dass er LDAP Signing und LDAP Channel Bindung bitte direkt aktiviert oder über einen Prozess einführt. Sie sollten:

  1. Auf allen Client und Servern per Gruppen Richtlinien LDAP Signing/Channel Binding aktivieren
    Das sollte niemand stören aber sicherstellen, dass es jeder Client und jeder Server anbietet und nutzt, wenn es die andere Seite auch kann. Das allein ist aber noch kein Schutz, denn ein Angreifer könnte ja gezielt die Pakete so verändern, dass die andere Seite glaubt, der Andere könnte dies nicht.
  2. Zugriffe kontrollieren
    Daher müssen wir dann auf allen DCs kontrolliere, welche LDAP-Zugriff noch mit den alten unsicheren Verfahren erfolgen. Gibt es noch Clients, die wirklich ein "Simple Bind" machen oder die vielleicht schon mit einer starken Anmeldung ankommen aber die LDAP Signing und Channel Binding nicht umsetzen. Unser Ziel ist es, dass alle Clients die neuen sicheren Wege auch über unverschlüsseltes LDAP über Port 389/TCP nutzen.
  3. LDAP Signing und Channel Bindung erzwingen
    Wenn alle Systeme entsprechend angepasst wurden und es keine inkompatiblen Anmeldungen mehr gibt, dann können und sollten wir die beiden Funktion LDAP Signing und Channel Bindung erzwingen. Diese Funktion gibt es seit Windows 2008R2, also ist auch schon viele Jahre verfügbar aber auch 2024 immer noch nicht als "Default" aktiv.

Mit dem letzten Schritt ist das System auch ohne TLS-Verschlüsselung und Signierung sehr sicher. Microsoft beschreibt dies sehr deutlich.

You can significantly improve the security of a directory server by configuring the server to reject Simple Authentication and Security Layer (SASL) LDAP binds that do not request signing (integrity verification), or to reject LDAP simple binds that are performed on a clear text (non-SSL/TLS-encrypted) connection. SASL binds may include protocols such as Negotiate, Kerberos, NTLM, and Digest.
Unsigned network traffic is susceptible to replay attacks. In such attacks, an intruder intercepts the authentication attempt and the issuance of a ticket. The intruder can reuse the ticket to impersonate the legitimate user. Additionally, unsigned network traffic is susceptible to man-in-the-middle (MIM) attacks in which an intruder captures packets between the client and the server, changes the packets, and then forwards them to the server. If this occurs on an LDAP server, an attacker can cause a server to make decisions that are based on forged requests from the LDAP client.
Quelle: How to enable LDAP signing in Windows Server  https://learn.microsoft.com/en-us/troubleshoot/windows-server/active-directory/enable-ldap-signing-in-windows-server

Die Replay-Attacken können Sie mit LDAP Signing verhindern. Die Konfiguration erfolgt idealerweise per Gruppenrichtlinie.

Stellen Sie in der ersten Stufe ein, dass die Funktion angeboten wird und nach der Kontrolle nicht kompatibler Anmeldungen und deren Konfiguration können Sie dann auf "muss" umstellen.

Domaincontroller und TLS

Auch wenn LDAP Channel Binding und LDAP Signing als sicher gelten, kann TLS eine zusätzliche Sicherheit bieten oder einen sicheren Zugang für Clients bereitstellen, die kein LDAP Signing und Channel Bindung unterstützen. Sie können beide Optionen kombinieren, z.B. den Transport per TLS verschlüsseln und zusätzlich LDAP Signing und Channel Binding verwenden, was die Sicherheit natürlich erhöht.

Voraussetzung ist dazu natürlich ein geeignetes Zertifikat auf den Domain Controllern. In der Standardinstallation stellt sich ein DC nämlich kein "SelfSigned"-Zertifikat aus und damit schlägt die Verbindung zum Domain Controller per LDAPS auf Port 636 erwartungsgemäß fehlt:

Damit stellt sich die Frage, woher sie die Zertifikate nehmen sollen. Es gibt, wie so oft, mehrere Möglichkeiten:

  • Self Signed
    Das ist sicher nicht ratsam aber für ein Testfeld oder erste Versuche durchaus möglich. Mit "New-SelfSignedCertificate" können Sie ein passendes Zertifikat auf dem DC selbst erstellen und der LDAP-Service wird dieses automatisch nutzen. Allerdings können die Client beim Verbinden nicht prüfen, ob das Zertifikat korrekt ist. Selbst wenn der Name und das Datum passen, ist der Aussteller nicht vertrauenswürdig und sie sollte nicht damit anfangen, so ein SelfSigned-Zertifikat auch noch bei allen Clients in den "Trusted Root Store" zu lesen. Das skaliert nicht und ist nicht sicher und je mehr DCs sie haben, desto mehr Zertifikate werden regelmäßig zu tauschen sein. Für ein Testfeld mit einem Single-DC können Sie damit aber experimentieren.
  • Eigene PKI
    Wenn der LDAP-Dienst nur von ihren eigenen Clients erreicht werden soll, dann können Sie über eine kleine "Firmen-PKI" nachdenken, die sie nur für interne Zertifikate nutzen. Wenn Sie auf SMIME, EFS etc. verzichten und z.B. nur Zertifikate für Transportverschlüsselung (LDAP, HTTP, POP, IMAP, SMTP, RDP) oder die Anmeldung (Smartcard, Computerzertifikate) ausstellen, und auf der Zertifizierungsstelle kein "Key Recovery" brauchen, dann kann eine AD-Integrierte RootCA mit diesen wenigen Templates die beste Lösung sein. Siehe auch Die Zertifikatsstelle in der eigenen Firma. Das "Vertrauen" in diese CA wird durch das AD zumindest für alle Domainmitglieder sichergestellt.
  • Öffentliche Zertifikate
    Der Betrieb einer eigenen PKI ist natürlich auch nicht "kostenfrei". Sie müssen etwas Wissen und Administration einrechnen und eine VM für einen Member-Server. Es kann daher auch sinnvoll sein, Zertifikate von einer öffentlichen PKI für den LDAP-Dienst zu kaufen. Das hat den Charme, dass diese Zertifikate auch von Systemen als gültig angesehen werden, die nicht AD-Mitglied sind.

Ein SelfSigned-Zertifikat können Sie direkt per PowerShell generieren. Hier habe ich ein Beispiel, welches ein SAN-Zertifikate für zwei DCs (DC01 und DC02) und dem Alias "ldap" als Subject Alternate Name" generiert.

# Zertifikat anlegen
$Certificate = New-SelfSignedCertificate `
                  -Subject ldap.msxfaqdev.de `
                  -DNSName "ldap.msxfaqdev.de","dc01.msxfaqdev.de","dc01","dc02.msxfaqdev.de","dc02" `
                  -CertStoreLocation Cert:\LocalMachine\My `
                  -KeyExportPolicy Exportable

Welches Zertifikat der LDAP-Service gebunden hat, können Sie einfach mit einer TLS-Verbindung auf Port 636 oder 3269 prüfen. Programme wie LDP zeigen leider das Zertifikat nicht an

Dafür gibt es dann aber andere Werkzeuge wie OpenSSL oder Get-TCPCert. Natürlich können Sie bis TLS 1.2 auch mittels WireShark den TLS Handshake anschauen. Sollte ich das Zertifikat nicht binden, dann können Sie z.B. über CAPI2-Debugging ggfls. den Fehler im Eventlog finden.

Auch wenn TLS gerne als Allzweckwaffe zur Absicherung per Signierung und Verschlüsselung gepriesen wird, ist auch TLS nicht 100% sicher", denn es gibt sehr wohl Deep Inspection Proxy-Systeme, über die Eine Firma auch TLS-Kommunikation aufbrechen kann. Dies kann über ExtendedProtection, Zertifikats-Pinning etc. erschwert werden.
Das machen mittlerweile einige Smartphone-Apps (Homebanking), um solche Angriffe zu erkennen. Allerdings muss ein Zertifikatstausch dann auch immer mit einem App-Update einhergehen, was nicht immer einfach ist.

Windows Clients?

Wenn Sie auf dem Server nun alle Prüfungen durchlaufen und zumindest LDAP Signing und LDAP Challenge Binding erzwungen und optional auch noch TLS aktiviert haben, dann steht die Frage aus, wie man den Client härtet. Als Client kann ich aber nur machen, was der Server zulässt. Wenn dieser LDAP Signing und LDAP Challenge Binding erzwingt, dann kann ich gar keine schwache Anmeldung mehr durchführen. Das verhindert aber nicht, dass der Client es nicht doch versucht oder auf 389/TCP statt 636/TLS eine Verbindung aufbaut

Ich habe bisher noch keinen Weg gefunden, wie ich einen Windows Client dazu bringen kann, nur noch LDAPS über 636/TLS zu sprechen. Bislang haben alle meine Client auch immer eine Verbindung per LDAP (389/TCP, 3268/TCP) versucht und sich "sicher" angemeldet.

Das "Sicher Anmelden" kann ich aber auf dem Client sehr wohl fordern und damit verhindern, dass sich zumindest Windows und alle Programe, die ADSI nutzen, mi einer schwachen Anmeldung authentifiziere. Das kann natürlich dazu führen, dass ich mich dann nicht per per LDAP zu Servern verbinden kann, die LDAP-Signing und LDAP Channel Binding nicht unterstützen. Das sollte mir die Sicherheit aber wert sein. Die Konfiguration ist wie bei den Domain Controllern per RegEdit oder besser noch per Gruppenrichtlinie steuerbar.

Beachten Sie du den jeweiligen Einstellungen auch die Hinweise, auf die Sie die GPO auch verweist

Weitere Links