Was ist LDAP Injection?
LDAP Injection ist ein serverseitiger Angriff, der Webanwendungen ausnutzt, die Lightweight Directory Access Protocol-Abfragen aus nicht bereinigten Benutzereingaben konstruieren. Wenn Ihre Anwendung spezielle Zeichen nicht korrekt neutralisiert, bevor sie in LDAP-Abfragen eingefügt werden, können Angreifer diese Abfragen manipulieren, um Authentifizierungen zu umgehen, sensible Verzeichnisdaten auszulesen oder Einträge im LDAP-Baum zu verändern.
LDAP-Verzeichnisse stehen im Zentrum der Identitätsinfrastruktur von Unternehmen. Sie speichern Benutzeranmeldeinformationen, Gruppenmitgliedschaften, Zugriffskontrolllisten, Organisationsstrukturen und Servicekontodetails. Ein einziger erfolgreicher LDAP-Injection-Angriff kann dieses Repository offenlegen und einem Angreifer die Schlüssel zu Ihrer Authentifizierungsinfrastruktur verschaffen.
MITRE klassifiziert diese Schwachstelle als MITRE CWE-90: Unzureichende Neutralisierung spezieller Elemente in einer LDAP-Abfrage. OWASP führt sie unter OWASP Injection und der aktualisierten OWASP Injection-Kategorie. Die Schwachstelle hat die gleiche Ursache wie SQL Injection, zielt jedoch auf ein grundlegend anderes und oft folgenschwereres System ab: den Verzeichnisdienst, der steuert, wer in Ihrer gesamten Organisation auf was zugreifen kann.
Um zu verstehen, wie LDAP Injection funktioniert, muss man die Abfragesyntax kennen, die Angreifer ausnutzen.
Wie funktioniert LDAP Injection?
LDAP-Suchfilter folgen einer spezifischen Grammatik, definiert in LDAP-Syntax. Filter verwenden polnische Notation (Präfixnotation), wobei eine einfache Authentifizierungsabfrage so aussieht:
Der &-Operator führt eine boolesche UND-Verknüpfung aus. Klammern gruppieren Bedingungen. Das *-Wildcard steht für beliebige Werte. Diese Metazeichen sowie | (ODER), ! (NICHT), =, ~=, >=, <=, und () als Gruppierungsoperatoren bilden die Angriffsfläche.
Wenn ein Entwickler einen Filter erstellt, indem er Benutzereingaben direkt an den Abfrage-String anhängt, werden diese Metazeichen zu Angriffsvektoren. Wenn ein Login-Formular den Benutzernamen direkt in einen Filter wie (&(uid=INPUT)(userPassword=HASH)), einfügt, kann ein Angreifer durch gezielt eingesetzte Metazeichen die Logik des Filters vollständig verändern: Authentifizierung umgehen, alle Verzeichniseinträge zurückgeben oder Daten zeichenweise extrahieren.
Die konkrete Technik, die ein Angreifer verwendet, hängt vom Typ der LDAP Injection ab.
Arten von LDAP Injection
LDAP Injection tritt in mehreren unterschiedlichen Formen auf, die jeweils einen anderen Aspekt der Interaktion von Anwendungen mit dem Verzeichnis angreifen. Die gewählte Technik hängt vom Verhalten der Anwendung, dem Abfragekontext und den beobachtbaren Rückmeldungen ab.
| Typ | Technik | Konsequenz |
| Suchfilter-Injection | Wildcard- oder ODER-basierte Filtermanipulation | Komplette Verzeichnis-Aufzählung |
| Authentifizierungs-Bypass | Immer-wahr-Filter-Injection | Unbefugte Anmeldung als beliebiger Benutzer |
| Blind LDAP Injection | Zeichenweise Differenzanalyse | Lautlose Datenextraktion |
| DN-Manipulation | Falscher Escaping-Kontext für DN-Felder | Injection in nicht-Filter-Abfragekomponenten |
Suchfilter-Injection
Betrachten Sie diesen verwundbaren Java-Code:
Wenn ein Angreifer user=* eingibt, wird der resultierende Filter zu (cn=*), was auf jedes Objekt im Verzeichnis mit einem cn-Attribut zutrifft. Ihre Anwendung gibt das gesamte Benutzerverzeichnis statt eines einzelnen Eintrags zurück.
Authentifizierungs-Bypass
LDAP-Authentifizierungsflüsse sind das Angriffsziel mit den schwerwiegendsten Folgen. Ein verwundbarer Login-Filter wie dieser:
Dieser Filter kann umgangen werden, indem )(uid=))(|(uid=* als Benutzername injiziert wird. Der resultierende Filter ist immer wahr und verschafft dem Angreifer authentifizierten Status als erster Benutzer im LDAP-Baum, oft ein Administratorkonto. Der Testing Guide dokumentiert dies als direktes Analogon zu SQL Injection-Authentifizierungs-Bypass-Techniken.
Blind LDAP Injection
Wenn Anwendungen keine Abfrageergebnisse direkt anzeigen, nutzen Angreifer differenzielle Antworten zur Datenauslese. Durch das Injizieren von Filterbedingungen wie (attribute=a*), (attribute=b*) und Beobachtung, ob die Anwendung ein Ergebnis oder eine leere Seite zurückgibt, extrahieren sie Attributwerte Zeichen für Zeichen. Forschung, präsentiert im Black Hat Paper, zeigte, dass clientseitige Filter, die angezeigte Informationen begrenzen, Blind-Injection-Techniken nicht verhindern.
Distinguished Name Manipulation
LDAP hat unterschiedliche Escaping-Kontexte, und deren Verwechslung schafft Angriffsvektoren. Suchfilter erfordern Escaping gemäß RFC 4515 (*→\2a, (→\28, )→\29). Distinguished Names (DNs) erfordern Escaping gemäß RFC 2253 (\, #, +, <, >, ,, ;, ", =). Wird der falsche Escaping-Kontext auf das falsche Feld angewendet, bleibt Ihre Anwendung verwundbar, selbst wenn Sie glauben, das Problem gelöst zu haben.
Diese Angriffstypen haben gemeinsame Ursachen, die tiefer als die Syntax reichen.
Ursachen von LDAP Injection
LDAP-Injection-Schwachstellen entstehen durch eine Kombination aus Programmierpraktiken, Bibliotheksbeschränkungen und Infrastruktur-Fehlkonfigurationen. Jede Ursache eröffnet einen eigenen Angriffsweg.
- Direkte String-Konkatenation. Die unmittelbare Ursache fast jeder LDAP-Injection-Schwachstelle ist die direkte Verkettung benutzerkontrollierter Daten in LDAP-Filter-Strings auf Anwendungsebene. LDAP-Bibliotheken boten historisch keine integrierte Unterstützung für parametrisierte Abfragen, sodass Entwickler manuelle Anleitungen für sichere Abfragekonstruktion befolgen mussten. Parametrisierte Schnittstellen existieren, erfordern aber bewusste Nutzung.
- Fehlbehandlung spezieller Zeichen. Anwendungen, die Eingabevalidierung versuchen, implementieren oft unvollständige Denylists, die gefährliche Zeichen übersehen. Eine Denylist, die * und ( blockiert, aber ) oder NUL-Bytes übersieht, lässt eine ausnutzbare Lücke. MITRE CWE-90 identifiziert LDAP Injection als Folge dieses Versagens, d. h. die Schwachstelle entsteht direkt durch die Fehlbehandlung spezieller Zeichen.
- Verwechslung des Escaping-Kontexts. Das LDAP Cheat Sheet dokumentiert, dass das Anwenden von Suchfilter-Escaping auf DN-Felder oder DN-Escaping auf Suchfilterfelder Angriffsvektoren durch falsche Kontextauswahl schafft. Wenn Ihre Entwickler wissen, dass sie escapen müssen, aber die falsche Funktion wählen, bleibt Ihre Anwendung verwundbar.
- Konfigurationen mit anonymem und nicht authentifiziertem Bind. LDAP-Server, die anonymen Bind erlauben, ermöglichen es Angreifern, die Bind-Authentifizierung vollständig zu umgehen.
- Weitverbreitete Nutzung von LDAP für Authentifizierung. LDAPs Rolle als Authentifizierungs-Backbone in Unternehmensumgebungen bedeutet, dass Injection gegen Login-Flows das folgenschwerste Ergebnis liefert: Authentifizierter Zugriff auf unternehmensweite Ressourcen. Die Angriffsfläche ist architekturbedingt unternehmensweit.
Diese Ursachen führen zu Risiken, die weit über eine einzelne kompromittierte Abfrage hinausgehen.
Auswirkungen und Risiken von LDAP Injection
LDAP-Injection-Angriffe können verschiedene Kategorien von Geschäftsauswirkungen haben, die jeweils an Schwere zunehmen.
Authentifizierungs-Bypass
Eine immer-wahr-Filter-Injection verschafft sofort authentifizierten Zugriff. CVE-2023-4501 in OpenText Enterprise Server ermöglichte erfolgreiche Authentifizierung mit jedem gültigen Benutzernamen, unabhängig davon, ob das Passwort korrekt war, und möglicherweise auch mit ungültigem Benutzernamen und beliebigem Passwort. Dies betraf unternehmensweite COBOL-Entwicklungs- und Laufzeitumgebungen im Finanzwesen, in der Versicherungsbranche und im öffentlichen Sektor.
Sensible Datenexfiltration
LDAP-Verzeichnisse enthalten Benutzeranmeldeinformationen, Passwort-Hashes, E-Mail-Adressen, Organisationshierarchien, Gruppenmitgliedschaften, ACLs, Computerkonten und Security Identifier. Eine CISA-Warnung dokumentierte eine einzelne LDAP-Abfrage, die Informationen über Benutzer, Computer, Gruppen, ACLs, OUs und GPOs aus einem Unternehmensverzeichnis abrief.
Privilegieneskalation
Erfolgreiche Injection kann Berechtigungen für unbefugte Abfragen gewähren und Inhaltsänderungen im LDAP-Baum ermöglichen. CVE-2026-31828 in Parse Server erlaubte authentifizierten Benutzern mit niedrigen Rechten, durch LDAP-Filter-Injection in jede eingeschränkte Gruppe aufzusteigen.
Denial of Service
CVE-2025-12764 (pgAdmin) zeigte, dass LDAP Injection genutzt werden kann, um den DC/LDAP-Server und -Client zur Verarbeitung ungewöhnlich großer Datenmengen zu zwingen, was zu einem Denial of Service gegen die Verzeichnisinfrastruktur mit nachfolgenden Authentifizierungsfehlern führt.
Ermöglichung lateraler Bewegung
LDAP-Aufzählung unterstützt die Active Directory-Aufklärung. Die CISA-Red-Team-Warnung dokumentierte, dass LDAP-Daten das Mapping von Benutzern, Computern, Gruppen, ACLs, OUs und GPOs ermöglichten, die alle als Eingaben für laterale Bewegungsplanung dienen. Das bewertete Unternehmen hatte für diese Aktivität keinerlei Sichtbarkeit.
OWASP bewertet die Ausnutzbarkeit von Injection mit 3 (Einfach) und die technische Auswirkung mit 3 (Schwerwiegend) im OWASP-Framework. LDAP Injection hat zudem direkte Compliance-Folgen: PCI DSS 6.5.1 nennt LDAP Injection explizit neben SQL und XPath Injection als verpflichtendes Prüfziel.
Das Verständnis der Auswirkungen hilft Ihnen, Verteidigungsmaßnahmen zu priorisieren, aber Sie müssen auch wissen, wie Angreifer diese Schwachstellen finden und ausnutzen.
Wie Angreifer LDAP Injection ausnutzen
Angreifer folgen einer strukturierten Methodik, um LDAP-Injection-Schwachstellen zu finden und auszunutzen, von der Aufklärung bis zur vollständigen Anmeldeinformations-Extraktion.
Schritt 1: LDAP-integrierte Einstiegspunkte identifizieren
Der Angreifer identifiziert Anwendungsfunktionen, die wahrscheinlich ein LDAP-Backend abfragen. Laut SANS LDAP Blog kann LDAP für Verwaltung, Authentifizierung und Abfrage von Objekten aus einer Verzeichnisdatenbank verwendet werden. Login-Formulare, Benutzersuchseiten, Passwort-Reset-Flows, Firmenverzeichnisabfragen und VPN-Gateway-Portale sind alles potenzielle Angriffsflächen.
Schritt 2: Auf Injection-Punkte testen
Die OWASP LDAP-Tests empfehlen, Zeichen wie (, |, &, * einzufügen, um auf differenzielle Antworten zu prüfen. Fehlermeldungen, leere Ergebnismengen oder verändertes Anwendungsverhalten bestätigen einen verwundbaren Parameter.
Schritt 3: Filterstruktur ableiten
Ohne Quellcode leiten Angreifer die LDAP-Filterstruktur durch Fuzzing ab. SANS merkt an: "Es ist unwahrscheinlich, dass Sie während eines Penetrationstests den Quellcode sehen. In solchen Situationen müssen Fuzzing und Aufklärung eingesetzt werden."
Schritt 4: Injection-Payloads erstellen
Gängige Payloads sind:
- Wildcard-Injection
(*)zur Rückgabe aller Verzeichniseinträge - Immer-wahr-Filter
()(uid=))(|(uid=*)zur Umgehung der Authentifizierung - ODER-basierte Attribut-Injection ()(department=it)(|(cn=) zur Erfassung von Anmeldeinformationen über mehrere Attribute hinweg
- Null-Objektklassen-Terminierung
(*)(objectClass=*))(& (objectClass=void)zur Etablierung eines zuverlässigen booleschen Orakels für Blind-Extraktion
Die konkrete Payload hängt von der während der Aufklärung abgeleiteten Filterstruktur ab.
Schritt 5: Eskalation durch Angriffsketten
Eine typische Angriffskette, dokumentiert in OWASP- und MITRE ATT&CK-Quellen, folgt diesem Ablauf:
- Login-Bypass mit immer-wahr-Filter
- Extraktion von Domänenanmeldeinformationen durch ODER-basierte Injection
- Erstellung von Domänenkonten via ldapmodify (ATT&CK T1136.002)
- Dump von NTDS.dit für Offline-Credential-Cracking (ATT&CK T1003.003)
Blind LDAP Injection ermöglicht eine parallele Kette, bei der Angreifer Schemaattribute mit (attribute=*)-Abfragen auflisten und Werte Zeichen für Zeichen extrahieren, einschließlich Passwort-Hashes, Gruppenmitgliedschaften und Security Identifier.
Diese Angriffsmuster betreffen eine Vielzahl von Organisationen und Anwendungstypen.
Wer ist von LDAP Injection betroffen?
Jede Organisation, die auf LDAP-basierte Authentifizierung setzt, ist strukturell dieser Schwachstelle ausgesetzt. OWASP merkt an, dass Injection-Schwachstellen "sehr verbreitet sind, insbesondere in Legacy-Code."
Anwendungstypen mit höchster Exposition sind:
- Webanwendungen mit LDAP-basierter Authentifizierung (Login-Portale, SSO-Systeme)
- Legacy-Unternehmensanwendungen mit String-konkatenierten LDAP-Abfragen
- Self-Service-Passwort-Reset- und Mitarbeiterverzeichnis-Portale
- VPN-Gateways und Remote-Access-Portale
- Management-Plattformen für industrielle Steuerungssysteme
- Desktop-Anwendungen (OWASP Desktop App Security Top 10 listet LDAP Injection unter DA1 Injections)
Branchen mit erhöhtem Risiko sind:
- Gesundheitswesen: LDAP-basierte EHR- und klinische Systeme unterliegen HIPAA-Vorgaben für ungepatchte Schwachstellen, das HHS dokumentiert HHS-Breach-Daten zu großen Vorfällen zwischen 2018 und 2022.
- Finanzdienstleistungen: Injection bleibt eine relevante Angriffsfläche für identitätsgebundene Unternehmenssysteme in diesem Sektor.
- Behörden und Kritische Infrastruktur: CISA hat aktive Ausnutzung in Behördenumgebungen und ICS-Energieplattformen dokumentiert.
- Software und Technologie: Open-Source-Backends, Datenbanktools und Entwicklungsplattformen produzieren weiterhin neue LDAP-Injection-CVEs.
LDAP Injection betrifft eine breite Palette von Software, von COBOL-Umgebungen über Datenbank-Administrationswerkzeuge bis zu Energieplattformen und Open-Source-Backends. Dies sind keine hypothetischen Risiken; aktuelle Vorfälle bestätigen sie.
LDAP Injection: Beispiele aus der Praxis
Die folgenden Fälle zeigen, wie LDAP Injection in Regierungsnetzwerken, Unternehmensplattformen und Open-Source-Tools auftritt.
CISA Red Team: Unternehmen ohne LDAP-Sichtbarkeit (2024)
Eine CISA-Bewertung ergab, dass das bewertete Unternehmen "kein Monitoring für anomalen LDAP-Verkehr" hatte. Das Team fragte LDAPS ab, um Informationen über Benutzer, Computer, Gruppen, ACLs, OUs und GPOs zu sammeln. CISA stellte explizit fest, dass ein nicht privilegierter Benutzer, der von einem Linux-Domänenhost LDAP abfragt, "Netzwerkverteidiger hätte alarmieren sollen".
OpenText Enterprise Server: Kompletter Authentifizierungs-Bypass (CVE-2023-4501)
Diese Schwachstelle ermöglichte erfolgreiche Authentifizierung mit jedem gültigen Benutzernamen, unabhängig vom Passwort, und möglicherweise auch mit ungültigem Benutzernamen. Betroffen waren COBOL-Entwicklungs- und Laufzeitumgebungen im Finanzwesen, in der Versicherungsbranche und bei der Integration von Mainframes im öffentlichen Sektor.
Ivanti EPMM: Angreifer dumpen LDAP-Anmeldedaten (2025)
Nach Veröffentlichung eines Proof of Concept im Mai 2025 verschafften sich Angreifer Zugriff auf einen Ivanti EPMM-Server und dumpen LDAP-Anmeldedaten. CISA nahm die zugrundeliegenden Schwachstellen am 19. Mai 2025 in den KEV-Katalog auf.
Redash: LDAP Injection ermöglicht Password Spraying (CVE-2020-36144)
GitHub Security Lab dokumentierte, dass das E-Mail-Feld in Redash LDAP-Authentifizierung einen LDAP-Filter-Query-String ohne Escaping formatierte, sodass ein nicht authentifizierter Angreifer mit einer einzigen Anfrage alle Benutzerpasswörter per Brute-Force testen konnte.
Diese Vorfälle spiegeln Jahrzehnte von LDAP-Sicherheitsherausforderungen wider.
LDAP Injection: Zeitstrahl und Historie
LDAP Injection ist seit über zwei Jahrzehnten als Schwachstellenklasse bekannt, mit formaler Klassifizierung und kontinuierlichen CVE-Meldungen von den späten 1990ern bis heute.
- Protokoll-Ursprünge. X.500 Directory Access Protocol (DAP) wurde von der ITU-T entwickelt. LDAP v1 erschien in RFC 1487, v2 in RFC 1777 und v3 in RFC 2251, das bis heute in Unternehmen genutzt wird.
- Erstes dokumentiertes Problem. CVE-1999-0895 dokumentierte ein frühes LDAP-Authentifizierungsproblem in Checkpoint FireWall-1 V4.0.
- Formale Klassifizierung. OWASP dokumentierte LDAP Injection als eigene Angriffsklasse. Die OWASP Top 10 von 2007 ordnete sie unter A2, Injection Flaws, ein.
- Blind Injection-Forschung. Alonso et al. präsentierten systematische Blind LDAP-Forschung auf der Black Hat Europe und zeigten zeichenweise Datenextraktion.
- OWASP-Prioritätsspitze. OWASP Top 10 2017 bewertete Injection als A1, das größte Webanwendungsrisiko, und nannte LDAP Injection explizit.
- ICS-Zielsetzung. CVE-2018-14805 (ABB eSOMS) brachte LDAP Injection in den ICS-Bereich des Energiesektors.
- Angriffe auf Unternehmensplattformen. ForgeRock OpenAM, OpenLDAP und OpenText Enterprise Server zeigten anhaltende Auswirkungen auf Unternehmen.
- Aktuelle Meldungen. Neue CVEs der letzten Jahre betreffen Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax und pgAdmin.
Neue CVEs erscheinen weiterhin, was kontinuierliches Monitoring zur praktischen Notwendigkeit macht.
Wie erkennt man LDAP Injection?
Sie benötigen gestaffeltes Monitoring auf Anwendungs-, Verzeichnis- und Netzwerkebene.
Indikatoren auf Anwendungsebene
Überwachen Sie Benutzereingabefelder auf LDAP-Metazeichen: *, (, ), \ und NUL-Bytes in Authentifizierungs- und Suchparametern. Achten Sie auf ungewöhnlich große LDAP-Ergebnismengen, die auf Wildcard-Injection und Rückgabe aller Verzeichniseinträge hindeuten. Authentifizierungserfolg unmittelbar nach einer fehlerhaften Abfrage signalisiert ein Authentifizierungs-Bypass-Muster.
Indikatoren auf LDAP-Server-Ebene
Suchen Sie nach Filterstrukturen mit )( oder |( Sequenzen, die auf Filtergruppenmanipulation hindeuten. Abfragen, die alle Einträge über (objectClass=*) oder (cn=*) zurückgeben, deuten auf Wildcard-Aufzählung hin. Anonymer Bind gefolgt von breiten Suchoperationen weist auf nicht authentifizierte Aufklärungsversuche hin.
SIEM- und Event-Log-Monitoring
Für Active Directory-Umgebungen sind zwei Windows-Event-IDs entscheidend:
- Event ID 4662: Vorgänge an AD-Objekten. Überwachen Sie Write Property, Control Access, DELETE, WRITE_DAC und WRITE_OWNER-Aktionen.
- Event ID 1644: Aufwendige oder ineffiziente LDAP-Abfragen, wie sie bei Injection-Versuchen häufig auftreten.
Laut NCC Group Guide: "Suchen Sie in den Logs nach ungewöhnlichen Suchfiltern. Angreifer verwenden oft spezifische Filter, um Benutzer, Gruppen und Computer aufzulisten."
Verhaltensbasierte Korrelation
Kombinieren Sie Datenquellen, um Injection-Kampagnen zu erkennen:
- Hohes LDAP-Abfragevolumen von einer einzelnen Quell-IP (Injection-Tooling)
- Sequenzielle Attribut-Aufzählung:
uid=a*, uid=b*(Blind-Injection-Extraktion) - Fehlgeschlagenes Passwort gefolgt von sofortigem Login-Erfolg (Bestätigung Authentifizierungs-Bypass)
- Nicht privilegierter Linux-Domänenhost führt Massen-LDAP-Abfragen aus (genau das von CISA dokumentierte Muster)
Die Korrelation dieser Signale über mehrere Quellen liefert ein klareres Bild aktiver Injection-Kampagnen als einzelne Indikatoren.
WAF-Level-Monitoring
Das OWASP ModSecurity Core Rule Set enthält die Regel-ID 921200 in REQUEST-921-PROTOCOL-ATTACK.conf, die LDAP Injection mit Schweregrad CRITICAL und Paranoia Level 1 (standardmäßig aktiviert) adressiert. Die Regel prüft Request-Cookies, Argumentnamen, Argumentwerte und XML-Bodies auf LDAP-Filter-Metazeichenmuster.
Das Erkennen verdächtiger Aktivitäten reicht ohne geeignete Präventionsmaßnahmen nicht aus.
Wie verhindert man LDAP Injection?
Prävention erfordert einen Defense-in-Depth-Ansatz über Code-, Konfigurations- und Infrastrukturebenen hinweg.
Schutzmaßnahmen auf Code-Ebene
- Verwenden Sie parametrisierte LDAP-Abfragen. Die wirksamste Maßnahme ist, Benutzereingaben als Parameter zu übergeben, statt sie in Filter-Strings zu konkatenieren:
- Kontextgerechtes Escaping anwenden. Verwenden Sie die korrekte Escaping-Funktion für den jeweiligen LDAP-Kontext. Für Suchfilter (RFC 4515): *→
\2a, (→\28, )→\29, \→\5c, NUL→\00. Für Distinguished Names (RFC 2253):\, #, +, <, >, ,, ;, ", =sowie führende/abschließende Leerzeichen escapen.
Sprachspezifische Implementierungen sind:
| Sprache | Suchfilter-Escaping | DN-Escaping |
| Java | OWASP ESAPI encodeForLDAP() | OWASP ESAPI encodeForDN() |
| .NET | Encoder.LdapFilterEncode() | Encoder.LdapDistinguishedNameEncode() |
| Perl | Net::LDAP::Util::escape_filter_value() | Manuell gemäß RFC 2253 |
- Implementieren Sie Allowlist-Validierung. Validieren Sie Eingaben anhand erwarteter Muster vor jeder LDAP-Operation. Lehnen Sie Eingaben mit nicht erwarteten Metazeichen ab. Normalisieren Sie Eingaben (Unicode-Kanonsierung) vor der Validierung gemäß dem OWASP Cheat Sheet.
Härtung der Infrastruktur
- Deaktivieren Sie anonymen und nicht authentifizierten Bind. Diese Maßnahme beseitigt die Ursache mehrerer kritischer Schwachstellen.
- Verwenden Sie LDAPS (Port 636). Deaktivieren Sie unverschlüsseltes LDAP (Port 389) gemäß NIST SP 1800-16.
- Wenden Sie Least-Privilege-ACLs auf LDAP-Bind-Servicekonten an. Beschränken Sie diese auf die erforderlichen Operationen und Verzeichnisbereiche.
- Segmentieren Sie die LDAP-Infrastruktur vom allgemeinen Netzwerkzugriff gemäß NIST SP 1800-18B.
Diese Maßnahmen reduzieren die Angriffsfläche für Angreifer, die Ihre LDAP-Infrastruktur erreichen.
Integration in CI/CD-Pipelines
Integrieren Sie statische Analyse (SAST) und dynamische Analyse (DAST) in Ihre Entwicklungspipeline. Die OWASP Top 10 empfiehlt SAST-, DAST- und IAST-Tools, um Injection-Schwachstellen vor dem Produktivbetrieb zu erkennen. Semgreps Taint-Analysis-Modus kann nicht vertrauenswürdige Eingaben von Quellen bis zu Senken ohne Bereinigung mit eigenen Regeln für LDAP-Abfragen verfolgen.
Diese Präventionsmaßnahmen wirken am besten mit der passenden Tool-Unterstützung.
Tools zur Erkennung und Prävention
Wirksamer LDAP-Injection-Schutz erfordert eine Kombination aus Scanning-, Monitoring- und Laufzeitschutz-Tools.
- OWASP ZAP bietet aktives Scanning auf LDAP Injection durch ZAP Alert 40015 (CWE-90, WASC-29). Installation über den ZAP Marketplace (Alpha Scan Rules) und gezieltes Scannen von Anwendungen mit LDAP-Integration.
- OWASP ModSecurity CRS bietet WAF-Schutz durch CRS-Regel 921200, die standardmäßig auf Paranoia Level 1 läuft. Die Regel prüft Cookies, Argumente und XML-Payloads auf LDAP-Filter-Manipulationssignaturen. CRS-Regressionstest-Payloads aus CRS Issue 276 bieten eine fertige Fuzzing-Wordlist für WAF-Validierung.
- Semgrep unterstützt statische Taint-Analyse mit mode: taint-Regeln, die nicht vertrauenswürdige Daten von Eingabequellen bis zu LDAP-Abfrage-Senken verfolgen und Injection-Pfade vor Produktionseinsatz markieren.
- SIEM-Plattformen mit eigenen Erkennungsregeln können Windows-Event-IDs 4662 und 1644 überwachen, anomale LDAP-Abfragemuster korrelieren und auf Verhaltensindikatoren wie sequenzielle Attribut-Aufzählung oder Massenabfragen von nicht privilegierten Hosts alarmieren.
Diese Tools adressieren einzelne Ebenen des Problems. Ein Plattformansatz verbindet sie miteinander.
Verringern Sie das Identitätsrisiko in Ihrer gesamten Organisation
Erkennen und reagieren Sie auf Angriffe in Echtzeit mit ganzheitlichen Lösungen für Active Directory und Entra ID.
Demo anfordernVerwandte Schwachstellen
Mehrere Schwachstellenklassen weisen das gleiche Muster wie LDAP Injection auf:
- SQL Injection (CWE-89): Das nächste Analogon. Beide nutzen nicht bereinigte Eingaben in Abfragesprachen aus, und Authentifizierungs-Bypass ist mit ähnlichen Techniken möglich. Syntax und Zielsysteme unterscheiden sich jedoch deutlich.
- OS Command Injection (CWE-78): Teilt das gleiche Software Fault Pattern (SFP24, "Tainted input to command") mit CWE-90 laut MITRE. Ziel ist das Host-Betriebssystem statt Verzeichnisdienste.
- XPath Injection (CWE-643): Die OWASP LDAP-Tests gruppieren XPath Injection explizit mit LDAP Injection als analoge Authentifizierungs-Bypass-Techniken für XML-basierte Datenspeicher.
- Unzureichende Neutralisierung spezieller Elemente (CWE-77): Die übergeordnete Schwäche von CWE-90 in der MITRE-Hierarchie. Alle Injection-Typen leiten sich von diesem allgemeinen Versagen ab, interpreterrelevante Zeichen zu neutralisieren.
- Unzureichendes Kodieren oder Escapen von Ausgaben (CWE-116): Dokumentiert die direkte Kette vom Escaping-Versagen zur Injection. CVE-2021-41232 zeigt die CWE-116 → CWE-90-Kette, bei der ein Escaping-Fehler in einer Go-Anwendung direkt LDAP Injection ermöglichte.
- Unzureichende Eingabevalidierung (CWE-20): Die Ursache, wenn Anwendungen das Eingabeformat vor der Konstruktion von LDAP-Abfragen nicht validieren.
Die Betrachtung dieser verwandten Schwachstellentypen hilft, die gleichen Abwehrprinzipien im gesamten Code anzuwenden, nicht nur in LDAP-spezifischen Pfaden.
Verwandte CVEs
| CVE-ID | Beschreibung | Schweregrad | Betroffenes Produkt | Jahr |
| LDAP Injection in SuiteCRM ermöglicht es nicht authentifizierten Angreifern, Suchfilter zu manipulieren und so Authentifizierungs-Bypass oder Informationsoffenlegung zu erreichen | Kritisch (9.8) | SalesAgility SuiteCRM <7.15.1 / 8.0.0–8.9.2 | 2026 | |
| WeKan übernimmt nicht bereinigte Benutzernamen in LDAP-Suchfilter und DN-Werte, sodass nicht authentifizierte entfernte Angreifer LDAP-Abfragen während der Authentifizierung manipulieren können | Kritisch (9.8) | WeKan Project WeKan <8.19 | 2026 | |
| Parse Server interpoliert vom Benutzer bereitgestellte authData.id direkt in LDAP Distinguished Names und Gruppensuchfilter, was Privilegieneskalation ermöglicht | Hoch (8.8) | Parse Platform parse-server <8.6.26 | 2026 | |
| LDAP Injection in WatchGuard Fireware OS ermöglicht es nicht authentifizierten entfernten Angreifern, sensible Informationen von einem verbundenen LDAP-Server abzurufen | Hoch (7.0) | WatchGuard Technologies Fireware OS 12.0–12.11.6 / 12.5–12.5.15 | 2026 | |
| Kanboard setzt nicht bereinigte Benutzereingaben direkt in LDAP-Suchfilter ein, sodass nicht authentifizierte Angreifer LDAP-Benutzer auflisten und sensible Attribute entdecken können | Mittel (5.3) | Kanboard Kanboard ≤1.2.48 | 2026 | |
| Teedys LDAP-fähiges Login-Formular ermöglicht nicht authentifizierte LDAP Injection über das Benutzernamenfeld, was beliebige Kontoerstellung und Password Spraying erlaubt | Kritisch (9.8) | Sismics Teedy 1.9–1.12 | 2025 | |
| LDAP Injection in Apache HertzBeat ermöglicht es einem authentifizierten Angreifer, Befehle zu erstellen, die zur Ausführung beliebiger Skripte führen | Hoch (8.8) | Apache Software Foundation Apache HertzBeat ≤1.7.2 | 2025 | |
| Das Injizieren spezieller LDAP-Zeichen in das Benutzernamenfeld von pgAdmin 4 führt dazu, dass der LDAP-Server und -Client übermäßig viele Daten verarbeiten, was zu einem Denial of Service führt | Hoch (7.5) | PostgreSQL Global Development Group pgAdmin 4 <9.10 | 2025 | |
| Das LDAP-Authentifizierungsformular von GLPI kann von nicht authentifizierten Angreifern für LDAP Injection genutzt werden, behoben in Version 10.0.12 | Hoch (8.1) | GLPI Project GLPI 0.70–<10.0.12 | 2024 | |
| Privilegierte Benutzer können LDAP-Filter-Strings in den optionalen LDAP-Kontaktanbieter der OX App Suite injizieren und so auf Verzeichnisinhalte außerhalb der vorgesehenen Hierarchie zugreifen | Hoch (~8.0) | Open-Xchange OX App Suite <7.10.6 | 2024 | |
| NVIDIA DGX A100 BMC enthält eine LDAP-Benutzer-Injection-Schwachstelle, die von nicht authentifizierten Angreifern im angrenzenden Netzwerk ausgenutzt werden kann und zur Informationsoffenlegung führt | Mittel (~6.5) | NVIDIA DGX A100 BMC | 2024 | |
| Mastodons LDAP-Login-Abfrage ist unsicher und ermöglicht authentifizierten Angreifern das Auslesen beliebiger Attribute aus dem LDAP-Verzeichnis | Hoch (7.7) | Mastodon Mastodon 2.5.0–4.1.1 | 2023 | |
| Ein manipulierter Benutzername umgeht die LDAP-Authentifizierung in Apache Derby, was zu Plattenerschöpfung, Malware-Ausführung und unbefugtem Datenbankzugriff führen kann | Kritisch (9.8) | Apache Software Foundation Apache Derby ≤10.16.1.1 | 2022 | |
| SSSDs libsss_certmap bereinigt Zertifikatsdaten, die in LDAP-Filtern verwendet werden, nicht, sodass ein authentifizierter Angreifer LDAP-Abfrageelemente injizieren und unbefugten Zugriff erhalten kann | Hoch (8.8) | Red Hat / SSSD Project SSSD | 2022 | |
| Apache ManifoldCF übergibt Benutzernamen und Domänenstrings ohne Validierung an LDAP-Suchabfragen in seinen ActiveDirectory-Authority-Connectors | Mittel (5.3) | Apache Software Foundation Apache ManifoldCF 0–2.23 | 2022 | |
| Thunderdome Planning Poker escaped Benutzernamen vor LDAP-Abfragen nicht, wenn LDAP-Authentifizierung aktiviert ist, was nicht authentifizierte LDAP Injection ermöglicht | Kritisch (9.8) | Thunderdome Planning Poker <1.16.3 | 2021 | |
| IBM Open Liberty's ldapRegistry-3.0-Feature enthält eine LDAP-Injection-Schwachstelle | Hoch (7.5) | IBM Open Liberty ldapRegistry-3.0 (v17.0.0.3–22.0.0.1) | 2021 | |
| ForgeRock OpenAM erlaubt LDAP Injection über das Webfinger-Protokoll, was nicht authentifizierte zeichenweise Auslese von Passwort-Hashes oder Session-Tokens ermöglicht | Hoch (geschätzt) | ForgeRock OpenAM <13.5.1 | 2021 |
Fazit
LDAP Injection gibt Angreifern die Möglichkeit, nicht vertrauenswürdige Eingaben in Kontrolle über die Verzeichnissysteme zu verwandeln, auf die Ihre Umgebung für Authentifizierung und Zugriff angewiesen ist. Für Sie bedeutet das, dass das Risiko selten auf eine einzelne Abfrage oder Anwendung beschränkt ist.
Wenn Sie Abfragen sicher erstellen, Werte im richtigen Kontext escapen, Bind-Berechtigungen einschränken und LDAP-Aktivitäten genau überwachen, reduzieren Sie sowohl die Angriffsfläche als auch den Bewegungsspielraum für Angreifer.
FAQs
LDAP Injection ist ein Fehler in der Eingabeverarbeitung von Software, die LDAP-Abfragen aus nicht vertrauenswürdigen Daten erstellt. Ein Angreifer kann beeinflussen, wie das Verzeichnis eine Abfrage interpretiert, eine Login-Prüfung in eine immer wahre Bedingung umwandeln, eine gezielte Suche in eine vollständige Verzeichnisaufzählung erweitern oder Add- und Modify-Operationen im LDAP-Baum missbrauchen.
Ja. LDAP Injection fällt unter die übergeordnete Kategorie Injection von OWASP und steht nicht als eigener Top 10-Eintrag. In der Praxis bedeutet das, dass Sie LDAP-basierte Codes mit derselben Sorgfalt prüfen sollten wie bei SQL Injection, da beide Schwachstellen durch nicht vertrauenswürdige Eingaben entstehen, die einen Interpreter erreichen.
Ja. Wenn Ihr öffentlich zugängliches Login-Formular, Ihre Suchseite, Ihr Portal oder Ihre Verwaltungsoberfläche Benutzereingaben an ein LDAP-Backend weiterleitet, kann ein Angreifer die Ausnutzung über das Netzwerk starten.
In vielen Fällen benötigen sie keine gültigen Zugangsdaten, um mit der Manipulation von Filtern zu beginnen.
Das höchste Risiko besteht bei Anwendungen, die LDAP für Identitätsentscheidungen nutzen: Login-Portale und SSO-Systeme, Tools zum Zurücksetzen von Passwörtern und zur Verzeichnissuche, VPN-Gateways und Remote-Access-Portale sowie Legacy-Enterprise-Anwendungen, die LDAP-Abfragen durch Zeichenkettenverkettung erstellen.
Angreifer beginnen meist mit einfachen Tests. Sie geben LDAP-Metazeichen wie (, |, & und * ein und beobachten veränderte Antworten, Fehler oder ungewöhnliche Ergebnismengen.
Sobald sie die Filterstruktur erkannt haben, setzen sie Wildcard-, OR-basierte oder Blind-Extraktions-Payloads ein.
Frühe Anzeichen sind oft Metazeichen in Authentifizierungs- oder Suchfeldern, ungewöhnlich breite LDAP-Ergebnismengen, )( oder |( Muster in Filtern, ein fehlgeschlagener Login unmittelbar gefolgt von Erfolg sowie Massen-LDAP-Abfragen von einem nicht privilegierten Host.
Sie ist schwerwiegend, da LDAP häufig Authentifizierung und Autorisierung über eine einzelne Anwendung hinaus steuert. Eine erfolgreiche Injection kann Verzeichnisdaten offenlegen, Login-Kontrollen umgehen oder die Lateral Movement-Planung im gesamten Umfeld unterstützen.
Diese Reichweite macht die geschäftlichen Auswirkungen größer als bei vielen rein anwendungsbezogenen Schwachstellen.
Ja, insbesondere als erster Schritt in einer größeren Identitätsangriffskette. Ein Angreifer kann vom Login-Bypass oder der Verzeichnisaufzählung zur Erfassung von Zugangsdaten, Kontoerstellung, NTDS.dit-Extraktion und dauerhaftem Zugriff mit gültigen Konten übergehen.
Die Injection ist oft der Einstiegspunkt, nicht das Endziel.
Tools helfen, lösen das Problem aber nicht allein. Scanner und WAF-Regeln können offensichtliche Fälle erkennen, während Blind Injection und schwaches LDAP-Logging schwerer zu entdecken sind.
Wenn Sie keine Sichtbarkeit in den LDAP-Verkehr und das Abfrageverhalten haben, können Sie Aktivitäten übersehen, selbst wenn die Ausnutzung bereits läuft.
Branchen mit zentralisierter Identitätsabhängigkeit tragen das höchste Risiko. Der Artikel hebt Gesundheitswesen, Finanzdienstleistungen, Behörden, kritische Infrastrukturen und Softwareplattformen hervor.
Gemeinsam ist ihnen die Abhängigkeit von LDAP-basierter Authentifizierung für besonders schützenswerte Nutzer, Systeme und administrative Abläufe.
