This site is the archived OWASP Foundation Wiki and is no longer accepting Account Requests.
To view the new OWASP Foundation website, please visit https://owasp.org

4.8.6 Tester les injections LDAP (OTG-INPVAL-006)

From OWASP
Jump to: navigation, search
This article is part of the new OWASP Testing Guide v4.
Back to the OWASP Testing Guide v4 ToC: https://www.owasp.org/index.php/OWASP_Testing_Guide_v4_Table_of_Contents Back to the OWASP Testing Guide Project: https://www.owasp.org/index.php/OWASP_Testing_Project

Sommaire

LDAP (Lightweight Directory Access Protocol) est utilisé pour stocker des informations sur les utilisateurs, hôtes, et bien d'autres objets. Une injection LDAP (LDAP injection) est une attaque côté serveur qui permet que des informations sensibles à propos des utilisateurs et des hôtes représentées dans une structure LDAP soient divulguées, modifiées ou ajoutées. Cela se fait en manipulant des paramètres d'entrée passés ensuite à des fonctions internes de recherche, ajout et modification.


Une application web peut utiliser LDAP pour permettre à ses utilisateurs de s'authentifier ou de rechercher des informations sur d'autres utilisateurs, tout ceci à l'intérieur d'une entreprise. Le but des attaques par injection LDAP est d'injecter des metacaractères de filtres de recherches dans une requête qui sera exécutée par l'application.

La [Rfc2254] définie une grammaire permettant de construire des filtres de recherches sur LDAPv3. Elle étend la [Rfc1960] (LDAPv2).


Un filtre de recherche LDAP est construit en notation polonaise, aussi connue sous le nom [prefix notation].


Cela signifie que le pseudo code d'une condition sur un filtre de recherche ressemblera à ceci :

find("cn=John & userPassword=mypass")

et sera représenté :

find("(&(cn=John)(userPassword=mypass))")


Les conditions booléennes et les agrégats de groupes sur un filtre de recherche LDAP peuvent être effectués en utilisant les méta-caractères :

Metacaractère Signification
& ET boolean
| OU boolean
 ! NON boolean
= Egal
~= Approximation
>= Plus grand que
<= Plus petit que
* caractère quelconque
() parenthèses groupantes


Les RFC concernées contiennent des exemples plus complets de filtres de recherches


Une exploitation réussie d'une vulnérabilité d'injection LDAP va permettre au testeur de :

  • Accéder à du contenu non autorisé
  • Contourner les restrictions de l'application
  • Récolter des information non autorisées
  • Ajouter ou modifier des objets dans l'arborescence LDAP


Comment tester

Exemple 1: Filtres de recherche

Supposons une application web utilisant un filtre de recherche comme celui-ci :

searchfilter="(cn="+user+")"

qui est instancié par une requête HTTP telle que :

http://www.example.com/ldapsearch?user=John

Si la valeur 'John' est remplacée par '*', dans la requête :

http://www.example.com/ldapsearch?user=*

le filtre va ressembler à :

searchfilter="(cn=*)"

qui va sélectionner tous les objets, quelque soit la valeur de leur attribut 'cn'.


Si l'application est vulnérable aux injections LDAP, les attributs de quelques utilisateurs, ou de tous, seront affichés, selon le flux d'exécution de l'application et les permissions de l'utilisateur LDAP connecté.


Un testeur pourra utiliser une approche pas à pas, en insérant dans les paramètres '(', '|', '&', '*' et d'autres caractères, afin de causer des erreurs dans l'application.


Exemple 2: Authentification

Si une application utilise LDAP dans son processus d'authentification des utilisateurs, et qu'elle est vulnérable aux injections LDAP, il est possible de contourner cette authentification en injectant une requête LDAP qui sera toujours vraie (de manière similaire aux injections SQL et XPATH).


Suposons qu'une application web utilise un filtre pour faire la correspondance utilisateur LDAP / mot de passe.

searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";


En utilisant les valeurs suivantes :

user=*)(uid=*))(|(uid=*
 pass=password

le filtre de recherche devient :

searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";

qui est correct et toujours vrai. De cette manière, le testeur va obtenir un statut authentifié, avec les droits du premier utilisateur de l'arborescence LDAP.


Outils

Softerra LDAP Browser - http://www.ldapadministrator.com/

Références

Whitepapers
Sacha Faust: "LDAP Injection: Are Your Applications Vulnerable?" - http://www.networkdls.com/articles/ldapinjection.pdf
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html


RFC 1960: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt