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

Difference between revisions of "Testing for LDAP Injection (OTG-INPVAL-006)"

From OWASP
Jump to: navigation, search
(References)
 
(33 intermediate revisions by 10 users not shown)
Line 1: Line 1:
[[http://www.owasp.org/index.php/Web_Application_Penetration_Testing_AoC Up]]<br>
+
{{Template:OWASP Testing Guide v4}}
{{Template:OWASP Testing Guide v2}}
 
  
==  Brief Summary ==
+
==  Summary ==
LDAP is an acronym for Lightweight Directory Access Protocol. It is a paradigm to store informations about users, hosts and many other objects.
+
The Lightweight Directory Access Protocol (LDAP) is used to store information about users, hosts, and many other objects. [[LDAP injection]] is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.
LDAP Injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified or inserted.<br>
 
This is done by manipulating input parameters afterwards passed to internal search,add and modify functions.
 
  
== Description of the Issue  ==
 
  
A web application could use LDAP in order to let a user to
+
A web application could use LDAP in order to let users authenticate or search other users' information
login with his own credentials or search other users informations
+
inside a corporate structure. The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.
inside a corporate structure.
 
 
 
The primary concept on LDAP Injection is that in occurrence of
 
an LDAP query during execution flow,
 
it is possible to fool a vulnerable web application by using
 
LDAP Search Filters metacharacters.
 
  
 
[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
 
[[http://www.ietf.org/rfc/rfc2254.txt Rfc2254]]
Line 22: Line 12:
 
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).
 
extends [[http://www.ietf.org/rfc/rfc1960.txt Rfc1960]] (LDAPv2).
  
A LDAP search filter is constructed in Polish notation,  
+
 
 +
An LDAP search filter is constructed in Polish notation,  
 
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].
 
also known as [[http://en.wikipedia.org/wiki/Polish_notation prefix notation]].
 +
  
 
This means that a pseudo code condition on a search filter like this:
 
This means that a pseudo code condition on a search filter like this:
Line 29: Line 21:
 
  find("cn=John & userPassword=mypass")
 
  find("cn=John & userPassword=mypass")
  
will result in:
+
will be represented as:
  
 
  find("(&(cn=John)(userPassword=mypass))")
 
  find("(&(cn=John)(userPassword=mypass))")
 +
  
 
Boolean conditions and group aggregations on an  
 
Boolean conditions and group aggregations on an  
Line 51: Line 44:
 
||  >= || Greater than
 
||  >= || Greater than
 
|-
 
|-
||  <= || Lesser than
+
||  <= || Less than
 
|-
 
|-
 
||  *  || Any character
 
||  *  || Any character
Line 58: Line 51:
 
|-
 
|-
 
|}
 
|}
More complete examples on how to build a search filter could be
 
found in related RFC.
 
  
A successful exploitation of LDAP Injection could allow the tester to:
+
 
 +
More complete examples on how to build a search filter can be
 +
found in the related RFC.
 +
 
 +
 
 +
A successful exploitation of an LDAP injection vulnerability could allow the tester to:
  
 
* Access unauthorized content
 
* Access unauthorized content
* Evade Application restrictions
+
* Evade application restrictions
 
* Gather unauthorized informations
 
* Gather unauthorized informations
 
* Add or modify Objects inside LDAP tree structure.
 
* Add or modify Objects inside LDAP tree structure.
  
== Black Box testing and example ==
+
 
 +
== How to Test ==
  
  
=== Example 1. Search Filters ===
+
=== Example 1: Search Filters ===
  
Let's suppose we have web application using a search
+
Let's suppose we have a web application using a search
 
filter like the following one:
 
filter like the following one:
  
Line 82: Line 79:
 
  <nowiki>http://www.example.com/ldapsearch?user=John</nowiki>
 
  <nowiki>http://www.example.com/ldapsearch?user=John</nowiki>
  
If 'John' value is replaced with a '*',
+
If the value 'John' is replaced with a '*',
 
by sending the request:
 
by sending the request:
  
Line 91: Line 88:
 
  searchfilter="(cn=*)"
 
  searchfilter="(cn=*)"
  
which means every object with a 'cn' attribute equals to anything.
+
which matches every object with a 'cn' attribute equals to anything.
 +
 
 +
 
 +
If the application is vulnerable to LDAP injection, it will display some or all of the users' attributes, depending on the application's execution flow and the permissions of the LDAP connected user.
  
If the application is vulnerable to LDAP injection
 
depending on LDAP connected user permissions and application execution
 
flow it will be displayed some or all of users attributes.
 
  
A tester could use trial and error approach by inserting
+
A tester could use a trial-and-error approach, by inserting in the parameter
'(', '|', '&', '*' and the other characters in order to check  
+
'(', '|', '&', '*' and the other characters, in order to check  
 
the application for errors.
 
the application for errors.
  
=== Example 2. Login ===
 
  
If a web application uses a vulnerable login page with LDAP query for
+
=== Example 2: Login ===
user credentials, it is possible to bypass the check for user/password
+
 
presence by injecting an always true LDAP query (in a similar way to SQL
+
If a web application uses LDAP to check user credentials during the login process and it is vulnerable to LDAP injection, it is possible to bypass the authentication check by injecting an always true LDAP query (in a similar way to SQL
 
and XPATH injection ).
 
and XPATH injection ).
 +
  
 
Let's suppose a web application uses a filter to match LDAP user/password pair.
 
Let's suppose a web application uses a filter to match LDAP user/password pair.
  
 
searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";
 
searchlogin= "(&(uid="+user+")(userPassword={MD5}"+base64(pack("H*",md5(pass)))+"))";
 +
  
 
By using the following values:
 
By using the following values:
Line 121: Line 119:
 
  searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";
 
  searchlogin="(&(uid=*)(uid=*))(|(uid=*)(userPassword={MD5}X03MO1qnZdYdgyfeuILPmQ==))";
  
which is correct and always true.  
+
which is correct and always true. This way, the tester will gain logged-in status as the first user in LDAP tree.
This way the tester will gain logged-in status as the first user in LDAP three.
+
 
 +
 
 +
==Tools==
 +
Softerra LDAP Browser - http://www.ldapadministrator.com/
  
 
== References ==
 
== References ==
 +
'''OWASP References'''<br>
 +
[[LDAP Injection Prevention Cheat Sheet]]
 +
 
'''Whitepapers'''<br>
 
'''Whitepapers'''<br>
Sacha Faust: "LDAP Injection" - http://www.spidynamics.com/whitepapers/LDAPinjection.pdf<br>
+
Sacha Faust: "LDAP Injection: Are Your Applications Vulnerable?" - http://www.networkdls.com/articles/ldapinjection.pdf<br>
<nowiki>RFC 1960</nowiki>: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt<br>
 
 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm<br>
 
Bruce Greenblatt: "LDAP Overview" - http://www.directory-applications.com/ldap3_files/frame.htm<br>
 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html <br>
 
IBM paper: "Understanding LDAP" - http://www.redbooks.ibm.com/redbooks/SG244986.html <br>
<br>
+
RFC 1960: "A String Representation of LDAP Search Filters" - http://www.ietf.org/rfc/rfc1960.txt<br>
'''Tools'''<br>
+
"LDAP injection" - http://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/bh-eu-08-alonso-parada-WP.pdf<br>
Softerra LDAP Browser - http://www.ldapadministrator.com/download/index.php <br>
 
 
 
 
 
{{Category:OWASP Testing Project AoC}}
 

Latest revision as of 03:31, 8 February 2017

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

Summary

The Lightweight Directory Access Protocol (LDAP) is used to store information about users, hosts, and many other objects. LDAP injection is a server side attack, which could allow sensitive information about users and hosts represented in an LDAP structure to be disclosed, modified, or inserted. This is done by manipulating input parameters afterwards passed to internal search, add, and modify functions.


A web application could use LDAP in order to let users authenticate or search other users' information inside a corporate structure. The goal of LDAP injection attacks is to inject LDAP search filters metacharacters in a query which will be executed by the application.

[Rfc2254] defines a grammar on how to build a search filter on LDAPv3 and extends [Rfc1960] (LDAPv2).


An LDAP search filter is constructed in Polish notation, also known as [prefix notation].


This means that a pseudo code condition on a search filter like this:

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

will be represented as:

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


Boolean conditions and group aggregations on an LDAP search filter could be applied by using the following metacharacters:

Metachar Meaning
& Boolean AND
| Boolean OR
 ! Boolean NOT
= Equals
~= Approx
>= Greater than
<= Less than
* Any character
() Grouping parenthesis


More complete examples on how to build a search filter can be found in the related RFC.


A successful exploitation of an LDAP injection vulnerability could allow the tester to:

  • Access unauthorized content
  • Evade application restrictions
  • Gather unauthorized informations
  • Add or modify Objects inside LDAP tree structure.


How to Test

Example 1: Search Filters

Let's suppose we have a web application using a search filter like the following one:

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

which is instantiated by an HTTP request like this:

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

If the value 'John' is replaced with a '*', by sending the request:

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

the filter will look like:

searchfilter="(cn=*)"

which matches every object with a 'cn' attribute equals to anything.


If the application is vulnerable to LDAP injection, it will display some or all of the users' attributes, depending on the application's execution flow and the permissions of the LDAP connected user.


A tester could use a trial-and-error approach, by inserting in the parameter '(', '|', '&', '*' and the other characters, in order to check the application for errors.


Example 2: Login

If a web application uses LDAP to check user credentials during the login process and it is vulnerable to LDAP injection, it is possible to bypass the authentication check by injecting an always true LDAP query (in a similar way to SQL and XPATH injection ).


Let's suppose a web application uses a filter to match LDAP user/password pair.

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


By using the following values:

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

the search filter will results in:

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

which is correct and always true. This way, the tester will gain logged-in status as the first user in LDAP tree.


Tools

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

References

OWASP References
LDAP Injection Prevention Cheat Sheet

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
"LDAP injection" - http://www.blackhat.com/presentations/bh-europe-08/Alonso-Parada/Whitepaper/bh-eu-08-alonso-parada-WP.pdf