Was ist LDAP Injection? Wie funktioniert sie und wie lässt sie sich verhindern?

Was ist LDAP Injection?

LDAP Injection ist ein serverseitiger Angriff auf Webanwendungen, die Abfragen des Lightweight Directory Access Protocol aus ungeprüften Benutzereingaben erstellen. Wenn Ihre Anwendung Sonderzeichen nicht korrekt neutralisiert, bevor sie diese in LDAP-Abfragen einfügt, können Angreifer die Abfragen manipulieren. So umgehen sie die Authentifizierung, lesen vertrauliche Verzeichnisdaten aus oder ändern Einträge im LDAP-Verzeichnisbaum.

LDAP-Verzeichnisse bilden das Herzstück der Identitätsinfrastruktur von Unternehmen. Sie speichern Benutzeranmeldedaten, Gruppenzugehörigkeiten, Zugriffskontrolllisten, Organisationsstrukturen und Angaben zu Dienstkonten. Ein einziger erfolgreicher LDAP-Injection-Angriff kann dieses Verzeichnis offenlegen und Angreifern Zugriff auf Ihre Authentifizierungsinfrastruktur verschaffen.

MITRE klassifiziert diese Schwachstelle als MITRE CWE-90: Improper Neutralization of Special Elements used in an LDAP Query. OWASP führt sie unter OWASP Injection und der aktualisierten Kategorie OWASP Injection auf. Die Schwachstelle hat dieselbe Ursache wie SQL Injection, zielt aber auf ein grundlegend anderes und oft folgenreicheres System: den Verzeichnisdienst, der unternehmensweit regelt, wer worauf zugreifen darf.

Um LDAP Injection zu verstehen, müssen Sie die Abfragesyntax kennen, die Angreifer ausnutzen.

Wie funktioniert LDAP Injection?

LDAP-Suchfilter folgen einer festgelegten Grammatik, die in der LDAP-Syntax definiert ist. Filter verwenden die polnische Notation (Präfixnotation). Eine einfache Authentifizierungsabfrage sieht so aus:

Der Operator & führt eine boolesche UND-Verknüpfung aus. Klammern gruppieren Bedingungen. Das Platzhalterzeichen * steht für einen beliebigen Wert. Diese Metazeichen bilden zusammen mit | (ODER), ! (NICHT), =, ~=, >=, <=, und () als Gruppierungsoperatoren die Angriffsfläche für Injections.

Wenn Entwickler einen Filter erstellen, indem sie Benutzereingaben direkt an die Abfragezeichenfolge anhängen, werden diese Metazeichen zu Angriffswerkzeugen. Fügt ein Anmeldeformular den Benutzernamen direkt in einen Filter wie (&(uid=INPUT)(userPassword=HASH)), ein, können Angreifer mit gezielt eingesetzten Metazeichen die Logik des Filters vollständig verändern: die Authentifizierung umgehen, alle Verzeichniseinträge abrufen oder Daten Zeichen für Zeichen auslesen.

Welche Technik Angreifer einsetzen, hängt von der Art der LDAP Injection ab.

Arten von LDAP Injection

LDAP Injection tritt in mehreren Formen auf. Jede nutzt einen anderen Aspekt der Interaktion zwischen Anwendung und Verzeichnis aus. Welche Art Angreifer einsetzen, hängt vom Verhalten der Anwendung, vom Kontext der Abfrage und von den Informationen ab, die sie in der Antwort erkennen können.

Suchfilter-Injection

Betrachten Sie diesen anfälligen Java-Code:

Wenn ein Angreifer user=* eingibt, lautet der resultierende Filter (cn=*). Er findet jedes Objekt im Verzeichnis mit einem cn-Attribut. Ihre Anwendung gibt statt eines einzelnen Eintrags das gesamte Benutzerverzeichnis zurück.

Umgehung der Authentifizierung

LDAP-Authentifizierungsabläufe sind ein besonders folgenschweres Ziel für Injections. Ein anfälliger Anmeldefilter sieht beispielsweise so aus:

Dieser Filter lässt sich umgehen, indem )(uid=))(|(uid=* als Benutzername eingegeben wird. Der resultierende Filter ist immer wahr. Dadurch erhält der Angreifer den Status eines authentifizierten Benutzers als erster Benutzer im LDAP-Verzeichnisbaum, häufig ein Administratorkonto. Der Testleitfaden beschreibt dies als direktes Gegenstück zu Techniken, die per SQL-Injection die Authentifizierung umgehen.

Blinde LDAP-Injection

Wenn Anwendungen Abfrageergebnisse nicht direkt anzeigen, nutzen Angreifer unterschiedliche Antworten, um Daten auszulesen. Sie fügen Filterbedingungen ein wie (attribute=a*), (attribute=b*) und beobachten, ob die Anwendung ein Ergebnis oder eine leere Seite zurückgibt. So lesen sie Attributwerte Zeichen für Zeichen aus. Eine in der Black-Hat-Veröffentlichung vorgestellte Untersuchung zeigte, dass clientseitige Filter, die angezeigte Informationen begrenzen, blinde Injection-Techniken nicht verhindern.

Manipulation von Distinguished Names

LDAP unterscheidet mehrere Kontexte für das Escaping. Werden sie verwechselt, entstehen Angriffsvektoren. Suchfilter erfordern Escaping gemäß RFC 4515 (*→\2a, (→\28, )→\29). Distinguished Names (DNs) erfordern Escaping gemäß RFC 2253 (\, #, +, <, >, ,, ;, ", =). Wird für ein Feld der falsche Escaping-Kontext verwendet, bleibt Ihre Anwendung angreifbar, selbst wenn Sie das Problem für behoben halten.

Diesen Angriffsarten liegen gemeinsame Ursachen zugrunde, die über die Syntax hinausgehen.

Ursachen von LDAP-Injection

LDAP-Injection-Schwachstellen entstehen durch das Zusammenspiel von Programmierpraktiken, Einschränkungen von Bibliotheken und Fehlkonfigurationen der Infrastruktur. Jede Ursache eröffnet einen eigenständigen Weg für Angriffe.

• Direkte Verkettung von Zeichenfolgen. Die unmittelbare Ursache fast jeder LDAP-Injection-Schwachstelle ist die direkte Verkettung nutzergesteuerter Daten mit LDAP-Filterzeichenfolgen auf Anwendungsebene. LDAP-Bibliotheken boten lange keine integrierte Unterstützung für parametrisierte Abfragen. Entwickler mussten daher manuelle Vorgaben zur sicheren Erstellung von Abfragen befolgen. Parametrisierte Schnittstellen sind verfügbar, müssen aber bewusst eingesetzt werden.
• Fehlerhafter Umgang mit Sonderzeichen. Anwendungen mit Eingabevalidierung verwenden häufig unvollständige Sperrlisten, die gefährliche Zeichen übersehen. Eine Sperrliste, die * und ( blockiert, aber ) oder NUL-Bytes nicht erfasst, lässt weiterhin eine ausnutzbare Lücke. MITRE CWE-90 ordnet LDAP-Injection als Folge dieses Fehlers ein. Die Injection-Schwachstelle entsteht somit direkt aus dem fehlerhaften Umgang mit Sonderzeichen.
• Verwechslung von Escaping-Kontexten. Das LDAP-Cheat-Sheet beschreibt, wie der falsche Escaping-Kontext Angriffsvektoren schafft: etwa wenn Escaping für Suchfilter auf DN-Felder oder DN-Escaping auf Suchfilterfelder angewendet wird. Wenn Ihre Entwickler wissen, dass Escaping nötig ist, aber die falsche Funktion wählen, bleibt Ihre Anwendung angreifbar.
• Konfigurationen mit anonymem und nicht authentifiziertem Bind. LDAP-Server, die anonymes Bind zulassen, lassen Angreifer die Bind-Authentifizierung vollständig umgehen.
• Weitverbreitete Nutzung von LDAP zur Authentifizierung. LDAP bildet das Rückgrat der Authentifizierung in Unternehmensumgebungen. Deshalb haben Injection-Angriffe auf Anmeldeprozesse besonders schwerwiegende Folgen: authentifizierten Zugriff auf unternehmensweite Ressourcen. Die Angriffsfläche erstreckt sich aufgrund der Architektur über das gesamte Unternehmen.

Zusammen schaffen diese Ursachen Risiken, die weit über eine einzelne kompromittierte Abfrage hinausgehen.

Auswirkungen und Risiken von LDAP-Injection

LDAP-Injection-Angriffe können verschiedene geschäftliche Auswirkungen haben, deren Schweregrad jeweils zunimmt.

Umgehung der Authentifizierung

Die Einschleusung eines Filters, der immer wahr ist, gewährt sofort authentifizierten Zugriff. CVE-2023-4501 in OpenText Enterprise Server ließ die Authentifizierung mit jedem gültigen Benutzernamen gelingen, unabhängig davon, ob das Passwort korrekt war. Möglicherweise gelang sie auch mit einem ungültigen Benutzernamen und einem beliebigen Passwort. Betroffen waren Entwicklungs- und Laufzeitumgebungen für COBOL in Unternehmen des Finanz- und Versicherungssektors sowie in Behörden.

Exfiltration sensibler Daten

LDAP-Verzeichnisse enthalten Benutzeranmeldedaten, Passwort-Hashes, E-Mail-Adressen, Organisationshierarchien, Gruppenmitgliedschaften, ACLs, Computerkonten und Sicherheitskennungen. Ein CISA-Hinweis dokumentierte, wie eine einzige LDAP-Abfrage Informationen über Benutzer, Computer, Gruppen, ACLs, OUs und GPOs aus einem Unternehmensverzeichnis abrief.

Ausweitung von Berechtigungen

Eine erfolgreiche Injection kann unautorisierten Abfragen Berechtigungen verschaffen und Änderungen an Inhalten innerhalb des LDAP-Baums ermöglichen. CVE-2026-31828 in Parse Server erlaubte authentifizierten Benutzern mit geringen Berechtigungen, durch LDAP-Filter-Injection Zugriff auf jede eingeschränkte Gruppe zu erlangen.

Dienstverweigerung

CVE-2025-12764 (pgAdmin) zeigte, wie LDAP-Injection gezielt eingesetzt wurde, um den DC/LDAP-Server und -Client zur Verarbeitung ungewöhnlich großer Datenmengen zu zwingen. Dies führte zu einem Denial-of-Service-Angriff auf die Verzeichnisinfrastruktur mit kaskadierenden Authentifizierungsfehlern.

Laterale Bewegungen ermöglichen

LDAP-Enumeration liefert Daten für die Aufklärung von Active Directory. Eine CISA-Empfehlung zu einer Red-Team-Übung dokumentierte, dass LDAP-Daten die Zuordnung von Benutzern, Computern, Gruppen, ACLs, OUs und GPOs ermöglichten. All diese Informationen dienen als Grundlage, um laterale Bewegungen zu planen. Das untersuchte Unternehmen hatte keinerlei Einblick in diese Aktivitäten.

OWASP bewertet die Ausnutzbarkeit von Injection mit 3 (Einfach) und die technischen Auswirkungen mit 3 (Schwerwiegend) in seinem OWASP-Framework. LDAP-Injection hat auch direkte Folgen für die Compliance: PCI DSS 6.5.1 nennt LDAP-Injection neben SQL- und XPath-Injection ausdrücklich als erforderlichen Prüfgegenstand.

Wenn Sie die Auswirkungen kennen, können Sie Abwehrmaßnahmen priorisieren. Sie müssen aber auch genau wissen, wie Angreifer diese Schwachstellen finden und ausnutzen.

Wie Angreifer LDAP-Injection ausnutzen

Angreifer gehen systematisch vor, um LDAP-Injection-Schwachstellen zu finden und auszunutzen: von der Aufklärung bis zur vollständigen Extraktion von Zugangsdaten.

Schritt 1: LDAP-integrierte Einstiegspunkte identifizieren

Der Angreifer identifiziert Anwendungsfunktionen, die wahrscheinlich ein LDAP-Backend abfragen. Laut SANS-Blog zu LDAP kann LDAP zur Verwaltung, Authentifizierung und Abfrage von Objekten aus einer Verzeichnisdatenbank verwendet werden. Anmeldeformulare, Seiten für die Benutzersuche, Abläufe zum Zurücksetzen von Passwörtern, Abfragen von Unternehmensverzeichnissen und VPN-Gateway-Portale kommen als Angriffsflächen infrage.

Schritt 2: Auf Injection-Punkte prüfen

Der OWASP-Leitfaden für LDAP-Tests weist Tester an, die Zeichen (, |, &, * einzufügen und auf unterschiedliche Reaktionen zu prüfen. Fehlermeldungen, leere Ergebnismengen oder ein verändertes Anwendungsverhalten bestätigen, dass ein Parameter anfällig ist.

Schritt 3: Filterstruktur erschließen

Ohne Quellcode erschließen Angreifer die Struktur von LDAP-Filtern durch Fuzzing. SANS stellt fest: "Bei einem Penetrationstest ist es unwahrscheinlich, dass Ihnen der Quellcode vorliegt, um diese Anweisungen einzusehen. In solchen Fällen können Fuzzing und Aufklärung erforderlich sein."

Schritt 4: Injection-Payloads erstellen

Zu den gängigen Payloads gehören:

• Wildcard-Injection (*) zum Abrufen aller Verzeichniseinträge
• Stets zutreffende Filter ()(uid=))(|(uid=*) zur Umgehung der Authentifizierung
• OR-basierte Attribut-Injection ()(department=it)(|(cn=) zum Extrahieren von Zugangsdaten über mehrere Attribute hinweg
• Terminierung mit einer Null-Objektklasse (*)(objectClass=*))(& (objectClass=void) zum Einrichten eines zuverlässigen booleschen Orakels für die blinde Extraktion

Die konkrete Payload hängt von der Filterstruktur ab, die der Angreifer während der Aufklärung erschlossen hat.

Schritt 5: Angriffe über Angriffsketten ausweiten

Eine typische Angriffskette, die in Quellen von OWASP und MITRE ATT&CK dokumentiert ist, verläuft wie folgt:

1. Anmeldung mit einem stets zutreffenden Filter umgehen
2. Domänenzugangsdaten mittels OR-basierter Injection extrahieren
3. Domänenkonten mittels ldapmodify erstellen (ATT&CK T1136.002)
4. NTDS.dit für das Offline-Knacken von Zugangsdaten auslesen (ATT&CK T1003.003)

Blind LDAP Injection eröffnet einen parallelen Angriffsweg: Angreifer ermitteln Schemaattribute mit (attribute=*)-Abfragen und extrahieren Werte anschließend Zeichen für Zeichen, darunter Passwort-Hashes, Gruppenzugehörigkeiten und Sicherheitskennungen.

Diese Angriffsmuster betreffen zahlreiche Organisationen und Anwendungstypen.

Wer ist von LDAP Injection betroffen?

Jede Organisation, die auf LDAP-basierte Authentifizierung setzt, ist dieser Schwachstelle grundsätzlich ausgesetzt. OWASP weist darauf hin, dass Injection-Schwachstellen "besonders häufig in Legacy-Code."

Zu den besonders betroffenen Anwendungstypen gehören:

• Webanwendungen mit LDAP-basierter Authentifizierung (Anmeldeportale, SSO-Systeme)
• Ältere Unternehmensanwendungen mit LDAP-Abfragen, die per String-Verkettung erstellt werden
• Self-Service-Portale zum Zurücksetzen von Passwörtern und Mitarbeiterverzeichnisse
• VPN-Gateways und Fernzugriffsportale
• Managementplattformen für industrielle Steuerungssysteme
• Desktop-Anwendungen (die OWASP Desktop App Security Top 10 führen LDAP Injection unter DA1 Injections)

Branchen mit erhöhtem Risiko sind:

• Gesundheitswesen: Bei LDAP-basierten elektronischen Patientenakten und klinischen Systemen drohen wegen nicht behobener Schwachstellen Maßnahmen zur Durchsetzung des HIPAA. HHS dokumentiert Daten zu Sicherheitsverletzungen bei großen Vorfällen zwischen 2018 und 2022.
• Finanzdienstleistungen: Injection bleibt eine relevante Angriffsfläche für identitätsbezogene Unternehmenssysteme in dieser Branche.
• Behörden und kritische Infrastruktur: CISA hat aktive Angriffe auf Behördenumgebungen und Plattformen des Energiesektors für industrielle Steuerungssysteme dokumentiert.
• Software und Technologie: Für Open-Source-Backends, Datenbanktools und Entwicklungsplattformen werden weiterhin neue CVEs zu LDAP Injection veröffentlicht.

LDAP Injection betrifft zahlreiche Softwaretypen, von COBOL-Umgebungen in Unternehmen über Datenbankverwaltungstools und Plattformen des Energiesektors bis zu Open-Source-Backends. Die Risiken sind nicht hypothetisch. Jüngste Vorfälle bestätigen sie.

Praxisbeispiele für LDAP Injection

Die folgenden Fälle zeigen, wie sich LDAP Injection in Behördennetzwerken, Unternehmensplattformen und Open-Source-Tools auswirkt.

CISA Red Team: Unternehmen ohne Einblick in den LDAP-Verkehr (2024)

Eine CISA-Untersuchung ergab, dass das untersuchte Unternehmen "keine Überwachung auf anomalen LDAP-Verkehr hatte." Das Team fragte über LDAPS Informationen zu Benutzern, Computern, Gruppen, ACLs, OUs und GPOs ab. CISA stellte ausdrücklich fest, dass LDAP-Abfragen eines nicht privilegierten Benutzers von einem Linux-Domänenhost aus "die Sicherheitsteams hätten alarmieren müssen."

OpenText Enterprise Server: Vollständige Umgehung der Authentifizierung (CVE-2023-4501)

Durch diese Schwachstelle konnte die Authentifizierung mit jedem gültigen Benutzernamen unabhängig vom Passwort gelingen. Auch mit einem ungültigen Benutzernamen war sie möglich. Betroffen waren COBOL-Entwicklungs- und Laufzeitumgebungen in Unternehmen, die bei Finanzdienstleistern, Versicherungen und zur Integration von Behörden-Mainframes eingesetzt werden.

Ivanti EPMM: Angreifer lesen LDAP-Zugangsdaten aus (2025)

Nach der Veröffentlichung eines Proof of Concept im Mai 2025 verschafften sich Angreifer Zugriff auf einen Ivanti EPMM-Server und lasen LDAP-Zugangsdaten aus. CISA nahm die zugrunde liegenden 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 bei der LDAP-Authentifizierung von Redash eine LDAP-Filterabfrage ohne Escaping zusammensetzte. So konnte ein nicht authentifizierter Angreifer mit einer einzigen Anfrage die Passwörter aller Benutzer per Brute Force angreifen.

Diese Vorfälle verdeutlichen, dass LDAP-Sicherheitsprobleme seit Jahrzehnten bestehen.

Zeitleiste und Geschichte von LDAP Injection

LDAP Injection ist seit über zwei Jahrzehnten als Schwachstellenklasse bekannt. Ihre formale Klassifizierung und die Veröffentlichung weiterer CVEs reichen von den späten 1990er-Jahren bis heute.

• Ursprünge des Protokolls. Das X.500 Directory Access Protocol (DAP) wurde von ITU-T entwickelt. LDAP v1 erschien in RFC 1487, v2 in RFC 1777 und v3 in RFC 2251. Letztere Version wird bis heute in Unternehmen eingesetzt.
• Erstes dokumentiertes Sicherheitsproblem. CVE-1999-0895 dokumentierte ein frühes LDAP-Authentifizierungsproblem in Checkpoint FireWall-1 V4.0.
• Formale Klassifizierung. OWASP dokumentierte LDAP-Injection offiziell als eigenständige Angriffsklasse. In den OWASP Top 10 von 2007 wurde sie unter A2, Injection Flaws, eingeordnet.
• Forschung zu Blind Injection. Alonso et al. präsentierten systematische Forschung zu Blind LDAP Injection auf der Black Hat Europe und demonstrierten die zeichenweise Extraktion von Daten.
• Höchste OWASP-Priorität. Die OWASP Top 10 von 2017 stuften Injection als A1 ein, das größte Risiko für Webanwendungen, und nannten LDAP-Injection ausdrücklich.
• Angriffe auf ICS. Mit CVE-2018-14805 (ABB eSOMS) erreichte LDAP-Injection ICS im Energiesektor.
• Angriffe auf Unternehmensplattformen. ForgeRock OpenAM, OpenLDAP und OpenText Enterprise Server zeigten die anhaltenden Auswirkungen auf Unternehmen.
• Jüngste Offenlegungen. Neue CVEs der vergangenen Jahre betreffen Apache Druid, WatchGuard Fireware, WeKan, Parse Server, Dell PowerMax und pgAdmin.

Es werden weiterhin neue CVEs veröffentlicht. Kontinuierliche Überwachung ist daher unerlässlich.

LDAP-Injection erkennen

Überwachen Sie Anwendung, Verzeichnisdienst und Netzwerk auf mehreren Ebenen.

Indikatoren auf Anwendungsebene

Überwachen Sie Benutzereingaben in Authentifizierungs- und Suchparametern auf LDAP-Metazeichen: *, (, ), \, sowie auf NUL-Bytes. Achten Sie auf ungewöhnlich große LDAP-Ergebnismengen. Sie können darauf hinweisen, dass eine Wildcard-Injection alle Verzeichniseinträge zurückgibt. Eine erfolgreiche Authentifizierung unmittelbar nach einer fehlerhaften Abfrage deutet auf eine Umgehung der Authentifizierung hin.

Indikatoren auf LDAP-Serverebene

Achten Sie auf Filterstrukturen mit den Zeichenfolgen )( oder |(. Sie deuten auf eine Manipulation von Filtergruppen hin. Abfragen, die über (objectClass=*) oder (cn=*) alle Einträge zurückgeben, deuten auf eine Aufzählung per Wildcard hin. Einem anonymen Bind folgende breit angelegte Suchvorgänge weisen auf unautorisierte Ausspähversuche hin.

SIEM- und Ereignisprotokollüberwachung

In Active Directory-Umgebungen sind zwei Windows-Ereignis-IDs entscheidend:

• Ereignis-ID 4662: Vorgänge an AD-Objekten. Überwachen Sie die Aktionen Write Property, Control Access, DELETE, WRITE_DAC und WRITE_OWNER.
• Ereignis-ID 1644: Aufwendige oder ineffiziente LDAP-Abfragen, wie sie bei Injection-Versuchen häufig entstehen.

Laut dem Leitfaden der NCC Group: "Achten Sie in den Protokollen auf ungewöhnliche Suchfilter. Angreifer verwenden häufig bestimmte Filter, um Benutzer, Gruppen und Computer aufzuzählen."

Verhaltensmuster durch Korrelation erkennen

Korrelieren Sie verschiedene Datenquellen, um Injection-Kampagnen zu erkennen:

• Hohes LDAP-Abfragevolumen von einer einzelnen Quell-IP (Injection-Tools)
• Sequenzielle Aufzählung von Attributen: uid=a*, uid=b* (Datenextraktion per Blind Injection)
• Auf ein fehlgeschlagenes Passwort folgt unmittelbar eine erfolgreiche Anmeldung (Bestätigung einer Umgehung der Authentifizierung)
• Ein nicht privilegierter Linux-Domänenhost führt massenhaft LDAP-Abfragen aus (genau das von CISA als unentdeckt dokumentierte Muster)

Die Korrelation dieser Signale über verschiedene Quellen hinweg zeigt aktive Injection-Kampagnen deutlicher als jeder einzelne Indikator.

Überwachung auf WAF-Ebene

Das OWASP ModSecurity Core Rule Set enthält die Regel-ID 921200 in REQUEST-921-PROTOCOL-ATTACK.conf, die auf LDAP-Injection mit Schweregrad CRITICAL und Paranoia Level 1 (standardmäßig aktiviert) abzielt. Die Regel prüft Anfrage-Cookies, Parameternamen, Parameterwerte und XML-Bodys auf Muster von LDAP-Filter-Metazeichen.

Verdächtige Aktivitäten zu erkennen, reicht ohne geeignete Schutzmaßnahmen nicht aus.

So verhindern Sie LDAP-Injection

Wirksame Prävention erfordert mehrschichtige Schutzmaßnahmen auf Code-, Konfigurations- und Infrastrukturebene.

Schutzmaßnahmen auf Code-Ebene

• Verwenden Sie parametrisierte LDAP-Abfragen. Am wirksamsten ist es, Benutzereingaben als Parameter zu übergeben, statt sie mit Filterzeichenfolgen zu verketten:

• Wenden Sie kontextgerechtes Escaping an. Verwenden Sie die passende Escaping-Funktion für den jeweiligen LDAP-Kontext. Maskieren Sie für Suchfilter (RFC 4515) *→\2a, (→\28, )→\29, \→\5c, NUL→\00. Maskieren Sie für Distinguished Names (RFC 2253) \, #, +, <, >, ,, ;, ", = sowie Leerzeichen am Anfang und Ende.

Sprachspezifische Implementierungen sind:

• Implementieren Sie eine Validierung anhand einer Positivliste. Prüfen Sie Eingaben vor jeder LDAP-Operation auf erwartete Muster. Lehnen Sie Eingaben mit Metazeichen ab, die im jeweiligen Feld nicht erwartet werden. Normalisieren Sie Eingaben (Unicode-Kanonisierung) vor der Validierung gemäß dem OWASP Cheat Sheet.

Absicherung der Infrastruktur

• Deaktivieren Sie anonyme und nicht authentifizierte Binds. Diese einzelne 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 ACLs nach dem Prinzip der geringsten Berechtigung auf Dienstkonten für LDAP-Binds an. Beschränken Sie deren Berechtigungen auf die erforderlichen Operationen und Teilbäume des Verzeichnisses.
• Schotten Sie die LDAP-Infrastruktur gemäß NIST SP 1800-18B.

Diese Kontrollen verringern die Angriffsfläche für Angreifer, die Zugang zu Ihrer LDAP-Infrastruktur erlangen.

Integration in die CI/CD-Pipeline

Integrieren Sie statische Analyse (SAST) und dynamische Analyse (DAST) in Ihre Entwicklungspipeline. Die OWASP Top 10 empfehlen SAST-, DAST- und IAST-Tools, um Injection-Schwachstellen vor dem Produktiveinsatz zu erkennen. Der Taint-Analysemodus von Semgrep verfolgt nicht vertrauenswürdige Eingaben von Quellen bis zu Senken, wenn sie nicht bereinigt werden. Dazu nutzt er benutzerdefinierte Regeln für die Erstellung von LDAP-Abfragen.

Diese Präventionsmaßnahmen wirken am besten mit den richtigen Tools.

Tools zur Erkennung und Prävention

Eine wirksame Abwehr von LDAP-Injection erfordert Tools für Scans, Überwachung und Laufzeitschutz.

• OWASP ZAP bietet aktive Scans auf LDAP-Injection über ZAP Alert 40015 (CWE-90, WASC-29). Installieren Sie die Alpha-Scanregeln über den ZAP Marketplace und konfigurieren Sie die Technologieauswahl für Anwendungen mit LDAP-Integration so, dass Protocol / LDAP eingeschlossen ist.
• OWASP ModSecurity CRS bietet WAF-Schutz durch CRS Rule 921200, die standardmäßig auf Paranoia Level 1 ausgeführt wird. Die Regel prüft Cookies, Argumente und XML-Payloads auf Anzeichen für die Manipulation von LDAP-Filtern. Die CRS-Regressionstest-Payloads aus CRS Issue 276 liefern eine fertige Fuzzing-Wortliste zur Validierung der WAF.
• Semgrep unterstützt statische Taint-Analyse mit Regeln im Modus mode: taint, die nicht vertrauenswürdige Daten von Eingabequellen bis zu Senken für LDAP-Abfragen verfolgen und Injection-Pfade erkennen, bevor der Code produktiv eingesetzt wird.
• SIEM-Plattformen mit benutzerdefinierten Erkennungsregeln können die Windows-Ereignis-IDs 4662 und 1644 überwachen, auffällige LDAP-Abfragemuster korrelieren und bei Verhaltensindikatoren wie der sequenziellen Auflistung von Attributen oder Massenabfragen von Hosts ohne erhöhte Berechtigungen Alarm auslösen.

Diese Tools decken einzelne Ebenen des Problems ab. Ein Plattformansatz verbindet sie.

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 anfordern

Verwandte Schwachstellen

Mehrere Schwachstellenklassen weisen dasselbe Muster wie LDAP-Injection auf:

• SQL-Injection (CWE-89): Das ähnlichste Gegenstück. Beide nutzen nicht bereinigte Eingaben in Abfragesprachen aus. Mit ähnlichen Techniken lässt sich die Authentifizierung umgehen. Syntax und Zielsysteme unterscheiden sich jedoch erheblich.
• OS-Command-Injection (CWE-78): Teilt laut MITRE dasselbe Software Fault Pattern (SFP24, "Tainted input to command") mit CWE-90. Das Ziel ist das Betriebssystem des Hosts statt eines Verzeichnisdienstes.
• XPath-Injection (CWE-643): Die OWASP-LDAP-Tests ordnen XPath-Injection und LDAP-Injection ausdrücklich als vergleichbare Techniken zur Umgehung der Authentifizierung bei XML-basierten Datenspeichern ein.
• Unzureichende Neutralisierung spezieller Elemente (CWE-77): Die übergeordnete Schwachstelle von CWE-90 in der MITRE-Hierarchie. Alle Injection-Typen gehen auf diese grundlegende fehlende Neutralisierung von Zeichen zurück, die für Interpreter eine besondere Bedeutung haben.
• Fehlerhafte Kodierung oder Maskierung von Ausgaben (CWE-116): Beschreibt den direkten Zusammenhang zwischen fehlerhafter Maskierung und Injection. CVE-2021-41232 zeigt die Kette CWE-116 → CWE-90: Ein Maskierungsfehler in einer Go-Anwendung ermöglichte unmittelbar LDAP-Injection.
• Unzureichende Eingabevalidierung (CWE-20): Die Ursache, wenn Anwendungen das Eingabeformat nicht validieren, bevor sie LDAP-Abfragen erstellen.

Wenn Sie diese verwandten Schwachstellentypen prüfen, können Sie dieselben Schutzprinzipien auf Ihre gesamte Codebasis anwenden, nicht nur auf LDAP-spezifische Codepfade.

Verwandte CVEs

Fazit

Durch LDAP-Injektionen können Angreifer nicht vertrauenswürdige Eingaben nutzen, um die Verzeichnissysteme zu kontrollieren, auf die Ihre Umgebung für Authentifizierung und Zugriff angewiesen ist. Für Sie bedeutet das: Das Risiko beschränkt sich selten auf eine einzelne Abfrage oder Anwendung. 

Wenn Sie Abfragen sicher erstellen, Werte im richtigen Kontext maskieren, Bind-Berechtigungen einschränken und LDAP-Aktivitäten genau überwachen, verringern Sie Ihre Angriffsfläche und den Handlungsspielraum der Angreifer.