The Lightweight Directory Access Protocol is a protocol for querying and modifying directory services running over TCP/IP LDAP is a protocol for accessing a directory. A directory contains objects; generally those related to users, groups, computers, printers and so on; company structure information (although frankly you can extend it and store anything in there).
LDAP gives you query methods to add, update and remove objects within a directory (and a bunch more, but those are the central ones).
LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.
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.
Examples
Example 1
In a page with a user search form, the following code is responsible to catch input value and generate a LDAP query that will be used in LDAP database. <input type="text" size=20 name="userName">Insert the username</input>
The LDAP query is narrowed down for performance and the underlying code for this function might be the following: String ldapSearchQuery = "(cn=" + $userName + ")";
System.out.println(ldapSearchQuery);
If the variable $userName is not validated, it could be possible accomplish LDAP injection, as follows:
If a user puts “*” on box search, the system may return all the usernames on the LDAP base
If a user puts “jonys) (| (password = * ) )”, it will generate the code bellow revealing jonys’ password ( cn = jonys ) ( | (password = * ) )
How to Test LDAP Injection
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.
Prevention of LDAP Injection
Mechanisms used to prevent code injection techniques include defensive programming, sophisticated input validation, dynamic checks and static source code analysis. The work on mitigating LDAP injections must involve similar techniques.
The attacks presented in the previous sections are performed on the application layer, therefore firewalls and intrusion detection mechanisms on the network layer have no effect on preventing any of these LDAP injections. However, general security recommendations for LDAP directory services can mitigate these vulnerabilities or minimize their impact by applying minimum exposure point and minimum privileges principles
LDAP gives you query methods to add, update and remove objects within a directory (and a bunch more, but those are the central ones).
LDAP Injection is an attack used to exploit web based applications that construct LDAP statements based on user input. When an application fails to properly sanitize user input, it’s possible to modify LDAP statements using a local proxy. This could result in the execution of arbitrary commands such as granting permissions to unauthorized queries, and content modification inside the LDAP tree. The same advanced exploitation techniques available in SQL Injection can be similarly applied in LDAP Injection.
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.
Examples
Example 1
In a page with a user search form, the following code is responsible to catch input value and generate a LDAP query that will be used in LDAP database. <input type="text" size=20 name="userName">Insert the username</input>
The LDAP query is narrowed down for performance and the underlying code for this function might be the following: String ldapSearchQuery = "(cn=" + $userName + ")";
System.out.println(ldapSearchQuery);
If the variable $userName is not validated, it could be possible accomplish LDAP injection, as follows:
If a user puts “*” on box search, the system may return all the usernames on the LDAP base
If a user puts “jonys) (| (password = * ) )”, it will generate the code bellow revealing jonys’ password ( cn = jonys ) ( | (password = * ) )
How to Test LDAP Injection
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.
Prevention of LDAP Injection
Mechanisms used to prevent code injection techniques include defensive programming, sophisticated input validation, dynamic checks and static source code analysis. The work on mitigating LDAP injections must involve similar techniques.
The attacks presented in the previous sections are performed on the application layer, therefore firewalls and intrusion detection mechanisms on the network layer have no effect on preventing any of these LDAP injections. However, general security recommendations for LDAP directory services can mitigate these vulnerabilities or minimize their impact by applying minimum exposure point and minimum privileges principles
No comments:
Post a Comment