In dieser Folge geht es um eine weitere Möglichkeit der LDAP-Injection-Angriffe: Manchmal wird die Benutzereingabe nicht direkt als Suchfilter übernommen, sondern als Teil eines komplexeren Filters verwendet. Ein Angreifer kann dann versuchen, durch eine entsprechend formulierte Suchanfrage die vorhandene Anwendungslogik zu manipulieren, um auf eigentlich nicht zugängliche Daten zuzugreifen.

Ein Beispiel

Im Beispiel aus About Security #194 soll der Suchfilter der LDAP-Abfrage nun auf Mitarbeiter aus Deutschland beschränkt sein:

<LDAP://ldap.furchtbar.example>;(&(givenName=Ratlos)(c=DE));cn,abteilung,email,c

Mit dem Operator & werden die beiden Bedingungen miteinander verknüpft und nur Einträge zurückgeliefert, in denen der Name Ratlos und das Land Deutschland ist. Bei Eingabe von * als Name werden alle Mitarbeiter aus Deutschland ausgegeben:

Es ist aber auch möglich, die vorgegebene Logik der Anwendung so zu manipulieren, das die vorhandene Bedingung (c=DE) aus dem Suchfilter verdrängt wird. Das ist z.B. mit der Eingabe

*));cn,cn;

möglich, die zu folgender LDAP-Abfrage führt:

<LDAP://ldap.furchtbar.example>;(&(givenName=*));cn,cn;)(c=DE));cn,abteilung,email,c

Der Suchfilter ist nur noch
(&(givenName=*))
und die auszugebenden Attribute sind
cn,cn;)(c=DE));cn,abteilung,email,c
Damit ergibt sich folgendes Ergebnis:

LDAP-Injection-Schwachstellen finden

Zuerst stellt sich wieder die Frage, welche Parameter für die Verwendung in einer LDAP-Abfrage in Frage kommen. Interessant sind alle Parameter, die Daten aus einem Verzeichnis auswählen könnten. Diese Parameter wurden bereits beim Sammeln der Informationen über die Webanwendung notiert und müssen nun auf eine mögliche LDAP-Injection-Schwachstelle überprüft werden.

Oft erzeugt eine falsche Eingabe für eine LDAP-Abfrage keine aussagekräftige Fehlermeldung, sondern führt nur zu einer allgemeinen Fehlermeldung der Suchfunktion oder zur Ausgabe des HTTP-Statuscodes 500, "Internal Server Error". Trotzdem gibt es einige Testeingaben, die auf eine mögliche LDAP-Injection-Schwachstelle hinweisen können:

• Zuerst wird nur ein * als Suchparameter eingegeben. Da ein * zwar in LDAP als Wildcard dient, nicht aber in SQL, ist eine große Anzahl an Ergebnissen ein Hinweis auf eine LDAP-Abfrage.
• Als nächstes wird eine Reihe schließender Klammern eingegeben: ))))))))))
  Damit werden sowohl die die Eingabe umgebenden Klammern als auch die um den Suchfilter selbst geschlossen. Einige schließende Klammern aus der Eingabe und der vorgegebenen Abfrage bleiben übrig und zerstören die Syntax der Abfrage. Tritt bei dieser Eingabe ein Fehler auf, kann das ein Hinweis auf eine mögliche LDAP-Injection-Schwachstelle sein. Da die Eingabe auch in vielen anderen Fällen die Anwendungslogik stören kann, reicht das allein aber nicht aus.
• Die verdächtigen Parameter werden danach solange mit Eingaben nach dem folgenden Muster getestet, bis kein Fehler mehr auftritt:

  *);cn;
  *));cn;
  *)));cn;
  *))));cn;

  usw., bis die richtige Anzahl schließender Klammern gefunden wurde, um die Klammern um die Eingabe korrekt zu schließen und danach den Rest der Abfrage zu manipulieren.
• Es können auch weitere Attribute, durch Komma getrennt, an das Ende der Eingabe angefügt werden. Evtl. werden dann zusätzliche Daten ausgegeben oder es erscheint eine Fehlermeldung, dass das Attribut im aktuellen Kontext nicht zulässig ist. Einige übliche LDAP-Attribute sind z.B. c, cn, dn, givenname, l, o, ou und uid.

LDAP-Injection verhindern

Wie immer müssen die Benutzereingaben geprüft werden. Am besten werden für LDAP-Abfragen nur Eingaben akzeptiert, deren Aufbau bekannt ist und die sich mit Hilfe regulärer Ausdrücke auf ihre Zulässigkeit prüfen lassen. Wenn die Eingaben mit einer Whitelist zulässiger, am besten nur alphanumerischer, Zeichen, verglichen werden kann, können keine unerwünschten Zeichen eingeschleust werden.

Ist die Verwendung einer Whitelist nicht möglich, muss die Eingabe nach potentiell gefährlichen Zeichen, mit denen sich die LDAP-Abfrage manipulieren lässt, durchsucht werden. Gefährlich sind u.a. ( ) ; , * ¦ & und =. Jede Eingabe, die nicht der Whitelist entspricht oder die ein unerwünschtes Zeichen enthält, sollte verworfen werden. Werden die Eingaben gefiltert, besteht die Gefahr, dass der Filter sich umgehen lässt.

In der nächsten Woche gibt es wie üblich einen Bericht von der CeBIT. Und in der nächsten regulären Folge wird die Suche nach Pufferüberlauf-Schwachstellen beschrieben.

Carsten Eilers

About Security - Übersicht zum aktuellen Thema:

• About Security #194: Schwachstellen-Suche: LDAP-Injection
• About Security #195: Schwachstellen-Suche: LDAP-Injection verhindern