LDAP Injection wird in Penetrationstests häufig übersehen — dabei ist es genauso gefährlich wie SQL Injection.
LDAP-Injection-Grundlagen — der vergessene Injection-Vektor
LDAP (Lightweight Directory Access Protocol, RFC 4511) verwendet eine eigene Filter-Syntax, um Objekte im Verzeichnis zu suchen. Ein typischer Authentifizierungs-Query sieht so aus: (&(uid=BENUTZERNAME)(userPassword=PASSWORT)). Wenn eine Webanwendung den Benutzernamen direkt in den LDAP-Filter einfügt, ohne ihn zu sanitisieren, kann ein Angreifer die Filter-Logik manipulieren. Das einfachste Beispiel: Eingabe von * als Benutzername erzeugt den Filter (&(uid=*)(userPassword=test)) — das Wildcard * matcht jeden Benutzernamen. Wenn die Anwendung nur prüft, ob das LDAP-Query ein Ergebnis liefert (statt das Ergebnis zu validieren), ist der Angreifer als beliebiger Benutzer eingeloggt.
Die LDAP-Filter-Syntax bietet weit mächtigere Möglichkeiten als nur Wildcards. Durch das Einschleusen von Klammern und logischen Operatoren kann ein Angreifer die gesamte Query-Struktur verändern. Die Eingabe admin)(&) als Benutzername transformiert den Filter zu (&(uid=admin)(&))(userPassword=anything)). Da (&) immer TRUE ergibt und der Passwort-Teil nun außerhalb der Hauptbedingung liegt, wird die Authentifizierung umgangen. Diese Technik wird als LDAP Filter Truncation bezeichnet und funktioniert in überraschend vielen produktiven Anwendungen — insbesondere in älteren Java-basierten Portalen, die javax.naming.directory direkt verwenden.
- Blind LDAP Injection: Ähnlich wie Blind SQL Injection kann ein Angreifer Informationen zeichenweise extrahieren, auch wenn keine Fehlermeldungen oder Daten zurückgegeben werden. Technik: Boolsche Abfragen wie
admin)(uid=a*→ TRUE/FALSE → nächster Buchstabeadmin)(uid=ab*. Durch Timing-Unterschiede oder unterschiedliche HTTP-Antworten (Login erfolgreich/fehlgeschlagen) kann der gesamte Verzeichnisbaum Zeichen für Zeichen ausgelesen werden. Automatisierung mit Tools wie LDAP-Bruter oder benutzerdefinierten Python-Skripten. - OR-basierte Enumeration: Die Eingabe
*)(|(objectClass=*erzeugt den Filter(&(uid=*)(|(objectClass=*)(userPassword=anything))). Das OR-Konstrukt(|(objectClass=*))matcht jedes Objekt im Verzeichnis. Je nach Anwendungsverhalten kann dies zur Auflistung aller Benutzer, Gruppen, Computer und organisatorischen Einheiten führen. Besonders gefährlich in Kombination mit LDAP-Paging (Simple Paged Results Control, RFC 2696). - Attribut-Exfiltration: LDAP-Queries können gezielt nach Attributen filtern:
*)(telephoneNumber=*oder*)(mail=*@example.comextrahieren Telefonnummern und E-Mail-Adressen aller Benutzer. In Active Directory sind standardmäßig über 200 Attribute pro Benutzerobjekt verfügbar, darunterstreetAddress,manager,memberOf— ein Goldmine für Social Engineering. - LDAP-Injection in Active Directory: AD-spezifische Attribute ermöglichen besonders wertvolle Abfragen:
(adminCount=1)listet alle privilegierten Accounts,(servicePrincipalName=*)alle SPN-registrierten Accounts (Kerberoasting-Ziele),(userAccountControl:1.2.840.113556.1.4.803:=4194304)alle Accounts mit „Do not require Kerberos preauthentication“ (AS-REP-Roasting-Ziele). Ein LDAP-Injection-Vektor in einer AD-integrierten Anwendung ist daher oft der erste Schritt zur vollständigen Domänenübernahme.
Fortgeschrittene Techniken — LDAP-Angriffe jenseits der Injection
Neben der klassischen LDAP Injection existieren weitere, kaum bekannte Angriffsvektoren gegen Verzeichnisdienste. LDAP Pass-Back ist eine Technik, bei der ein Angreifer ein Gerät (typischerweise einen Netzwerkdrucker oder Scanner) dazu bringt, seine LDAP-Zugangsdaten an einen vom Angreifer kontrollierten Server zu senden. Viele Drucker speichern LDAP-Bind-Credentials für die Adressbuch-Synchronisation — oft als Domain-Admin-Account. Der Angriff funktioniert so: Der Angreifer ändert über die Web-Oberfläche des Druckers die LDAP-Server-Adresse auf seine eigene IP und startet einen LDAP-Listener (nc -lvp 389 oder besser slapd im Debug-Modus). Beim nächsten LDAP-Sync sendet der Drucker die gespeicherten Credentials im Klartext — da viele Drucker LDAPS (Port 636) nicht erzwingen.
LDAP Relay ist das LDAP-Äquivalent eines NTLM-Relay-Angriffs: Ein Angreifer fängt eine LDAP-Authentifizierung ab und leitet sie in Echtzeit an den echten Domain Controller weiter. Seit der Entdeckung der Schwachstellen CVE-2022-26923 (Certifried) und den damit verbundenen ESC-Angriffen (AD CS Escalation) hat LDAP Relay massive Bedeutung gewonnen: Ein relayed LDAP-Bind kann für die Anforderung eines Maschinen-Zertifikats über AD Certificate Services missbraucht werden, mit dem sich der Angreifer dann als beliebiger Benutzer authentifizieren kann. Die Verteidigung: LDAP Channel Binding und LDAP Signing (siehe Härtungsmaßnahmen).
- LDAP Enumeration ohne Injection: Selbst ohne Injection-Schwachstelle erlaubt Active Directory standardmäßig jedem authentifizierten Benutzer umfangreiche LDAP-Abfragen.
ldapsearch -x -H ldap://dc01 -D "[email protected]" -W -b "DC=corp,DC=local" "(objectClass=user)" sAMAccountName mail memberOflistet alle Benutzer mit Gruppenzugehörigkeiten. BloodHound nutzt genau diese Eigenschaft: Der SharpHound-Collector führt Hunderte LDAP-Queries aus, um den gesamten AD-Graphen zu kartieren — als normaler Benutzer, ohne erhöhte Rechte. - LDAP Referral Injection: LDAP Referrals (RFC 4511 Abschnitt 4.1.10) ermöglichen es einem LDAP-Server, den Client an einen anderen Server zu verweisen. Ein Angreifer, der einen Rogue LDAP Server kontrolliert, kann Referrals verwenden, um den Client zu einem dritten Server umzuleiten — mit modifizierten Daten. In Java ist dies besonders gefährlich durch die JNDI (Java Naming and Directory Interface): Die Log4Shell-Schwachstelle (CVE-2021-44228) nutzte genau diesen Mechanismus — ein bösartiger LDAP-Server liefert über Referrals eine Java-Klasse, die auf dem Client ausgeführt wird.
- Unsigned LDAP — das stille Risiko: Standardmäßig ist LDAP-Signing in Active Directory nicht erzwungen — der Domain Controller akzeptiert sowohl signierte als auch unsignierte Binds. Dies ermöglicht Man-in-the-Middle-Angriffe auf LDAP-Verbindungen: Ein Angreifer auf dem Netzwerkpfad kann Abfragen und Antworten modifizieren, Passwortänderungen abfangen oder gefälschte Verzeichnisdaten einschleusen. Microsoft hat angekündigt, LDAP Signing ab Windows Server 2025 standardmäßig zu erzwingen.
- Golden SAML via ADFS: Wenn Active Directory Federation Services (ADFS) für SSO verwendet werden, kann ein Angreifer mit dem Token-Signing-Zertifikat des ADFS-Servers beliebige SAML-Assertions fälschen — für jeden Benutzer, für jeden Cloud-Dienst (Microsoft 365, AWS, Salesforce). Dieses Zertifikat ist in der ADFS-Konfigurationsdatenbank gespeichert und kann mit
ADFSDumpextrahiert werden. Der SolarWinds-Angriff (2020) nutzte genau diese Technik für laterale Bewegung in Cloud-Umgebungen.
Härtung & Verteidigung — LDAP sicher konfigurieren
Die wichtigste Maßnahme gegen LDAP-basierte Angriffe ist die Erzwingung von LDAP Signing und Channel Binding. LDAP Signing stellt sicher, dass jede LDAP-Nachricht kryptographisch signiert ist — ein Man-in-the-Middle kann den Inhalt nicht verändern, ohne die Signatur zu brechen. Channel Binding (RFC 5929) bindet die LDAP-Authentifizierung an den zugrundeliegenden TLS-Kanal — ein Relay-Angriff scheitert, weil der Angreifer keinen gültigen Channel Binding Token für seine eigene TLS-Session erstellen kann. Die Konfiguration erfolgt über Group Policy: Computer Configuration → Policies → Windows Settings → Security Settings → Local Policies → Security Options → „Domain controller: LDAP server signing requirements“ = „Require signing“. Zusätzlich: Registry-Schlüssel HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Parameters\LDAPServerIntegrity = 2.
Für Anwendungsentwickler ist die Parametrisierung von LDAP-Queries die fundamentale Verteidigung gegen Injection. Im Gegensatz zu SQL gibt es in LDAP keinen universellen „Prepared Statement“-Mechanismus, aber Frameworks bieten äquivalente Funktionen: In .NET verwenden Sie DirectorySearcher mit escapeten Filterstrings via System.DirectoryServices.SearchFilter.EscapeFilterValue(). In Java: javax.naming.ldap.Rdn.escapeValue(). In Python: ldap.filter.escape_filter_chars(). Die Escape-Funktion muss mindestens die Zeichen * ( ) \ NUL behandeln — diese Zeichen haben in LDAP-Filtern eine besondere Bedeutung.
- LDAPS erzwingen (Port 636): Deaktivieren Sie unverschlüsseltes LDAP (Port 389) auf allen Domain Controllern. In AD: Installieren Sie ein TLS-Zertifikat auf dem DC (über AD CS oder eine externe CA), und konfigurieren Sie Clients für LDAPS. Prüfen Sie mit
openssl s_client -connect dc01:636 -showcerts. Für StartTLS (LDAP über Port 389 mit TLS-Upgrade):ldapsearch -ZZ -H ldap://dc01— das-ZZ-Flag erzwingt TLS und bricht bei Fehler ab. - LDAP Query Rate Limiting: Active Directory hat ein eingebautes, aber kaum bekanntes Feature: LDAP Query Policies. Über
ntdsutil:ntdsutil > LDAP policies > connections > connect to server DC01 > quit > show values. Reduzieren SieMaxPageSize(Standard: 1000) auf 500,MaxValRangeauf 1500 undMaxResultSetSizeauf 131072. Diese Einstellungen begrenzen die Datenexfiltration bei Enumeration-Angriffen. - Read-Only Domain Controller (RODC): Für Standorte mit geringerer physischer Sicherheit (Außenbüros, Filialen): Ein RODC enthält nur eine Teilmenge der AD-Datenbank und speichert keine sensiblen Passwörter. Die Password Replication Policy (PRP) definiert, welche Accounts auf dem RODC gecacht werden dürfen. Selbst bei physischer Kompromittierung des RODC bleibt der Schaden begrenzt.
- AD DS Audit-Konfiguration: Aktivieren Sie „Audit Directory Service Access“ (Event ID 4662) in der Advanced Audit Policy. Konfigurieren Sie eine SACL (System Access Control List) auf dem AD-Container
CN=Users,DC=corp,DC=local, die Read Property-Zugriffe auf sensible Attribute (userPassword,unicodePwd,msDS-ManagedPassword) protokolliert. Korrelieren Sie mit Event ID 1644 (LDAP Search Audit — erfordert Aktivierung über Registry:HKLM\SYSTEM\CurrentControlSet\Services\NTDS\Diagnostics\15 Field Engineering = 5). - Segmentierung — LDAP nur für berechtigte Systeme: Beschränken Sie den Zugriff auf die LDAP-Ports (389/636) auf Domain Controllern per Windows Defender Firewall with Advanced Security oder Netzwerk-Firewall. Nur autorisierte Server (Exchange, ADFS, Management-Workstations) sollten LDAP-Zugriff haben — normale Workstations benötigen keinen direkten LDAP-Zugang (sie verwenden RPC/LSASS für die Authentifizierung). Diese einfache Maßnahme verhindert, dass ein kompromittierter Client direkt LDAP-Queries gegen den DC ausführen kann.
Sie benötigen Unterstützung?
LDAP-Sicherheit ist ein oft übersehener, aber kritischer Bestandteil jeder AD-Umgebung. Wir prüfen Ihre LDAP-Konfiguration auf Injection-Schwachstellen, implementieren LDAP Signing und Channel Binding und härten Ihre Verzeichnisdienste gegen Enumeration und Relay-Angriffe.
Active Directory ansehen →
