LDAP (Lightweight Directory Access Protocol) is an open, vendor-neutral, industry-standard application protocol for accessing and maintaining distributed directory information services over an Internet Protocol (IP) network. Directories organized via LDAP typically follow a hierarchical model and store information such as user profiles, authentication details, and other attributes necessary for various applications, services, and organizations.
How LDAP Works
LDAP operates by connecting to a directory service which then responds to queries made by client applications. Common use cases include querying user information in a corporate environment, retrieving organizational data, and managing network resources. LDAP directories are structured in a tree-like hierarchy called the Directory Information Tree (DIT).
Key Components:
1. Entries: Fundamental unit containing information in the directory.
2. Attributes: Characteristics of entries, defined by attribute types.
3. Distinguished Name (DN): Unique identifier for each entry in the directory.
4. Schema: Defines the structure of entries and attributes.
Directory Database Structure
A directory database structure refers to the organization and layout of data within a directory service, which is a specialized database used for storing and managing information about users, groups, resources, and other objects within a computer network. One common example of a directory service is the Lightweight Directory Access Protocol (LDAP), which is widely used for authentication, authorization, and information retrieval in networks.
The structure of a directory database typically follows a hierarchical model, similar to the structure of a tree. At the top level of the hierarchy is the root directory, which contains subdirectories, also known as organizational units (OUs). Each OU can further contain sub-OUs or leaf objects, such as users, groups, or resources.
Directories use various attributes to describe the objects they contain. These attributes can include information such as names, addresses, phone numbers, email addresses, group memberships, and access permissions. The schema of a directory defines the attributes and object classes that can be used to describe objects within the directory.
An LDIF (LDAP Data Interchange Format) template is a text-based format used to represent directory data in a human-readable and machine-readable form. LDIF files are commonly used to import or export data to and from directory services. LDIF templates provide a structured format for specifying the attributes and values of directory objects.
Here’s an example of an LDIF template for creating a user object:
dn: cn=John Doe,ou=Users,dc=example,dc=com objectClass: inetOrgPerson cn: John Doe sn: Doe givenName: John mail: john.doe@example.com userPassword: password123
In this LDIF template:
• dn (Distinguished Name) specifies the unique identifier for the user object within the directory hierarchy.
• objectClass specifies the type of object being created. In this case, it’s an inetOrgPerson, which is a standard LDAP object class for representing individuals.
• cn, sn, givenName, mail, and userPassword are attributes of the inetOrgPerson object class, representing common properties such as common name, surname, given name, email address, and password.
LDIF templates can be customized to include additional attributes or object classes as needed to represent different types of directory objects. They provide a flexible and standardized way to manage directory data across different directory services and applications.
Basic LDAP Operations
LDAP supports a variety of operations, including:
• Bind: Authenticates and specifies the LDAP protocol version.
• Search and Compare: Queries the directory and compares attributes.
• Modify: Alters entries.
• Add and Delete: Adds new entries or removes existing ones.
Modify DN: Changes an entry’s DN.
Understanding LDAP Injection: LDAP injection occurs when an attacker manipulates user inputs to control the construction of LDAP queries executed by the application. These queries are responsible for interacting with LDAP directories to authenticate users, retrieve information, or perform administrative tasks. By injecting malicious LDAP filter strings, attackers can subvert the intended functionality of the application and gain unauthorized access to sensitive data or escalate privileges.
Recognizing User Input in LDAP Queries: As users interact with web applications, they often provide inputs through various forms and fields. In the context of LDAP injection, these inputs can be leveraged by attackers to inject LDAP special characters and manipulate the underlying LDAP queries. To identify whether user input is embedded in an LDAP query, users can pay attention to the application’s response to their inputs. Here are some expected responses that may indicate user input is being processed as part of an LDAP query:
1. Immediate Error Messages:
If the application displays error messages immediately after submitting user input, it could indicate that the input is directly incorporated into LDAP queries without proper validation.
LDAP Query Error: The application may generate an error message related to a failed LDAP query execution. For example: “LDAP Query Failed: Invalid search filter.”
Internal Server Error: A generic message indicating that something went wrong on the server side. This might not specifically mention LDAP, but it could indicate a problem related to LDAP query processing.
2. Unusual Application Behavior:
• Users may notice unexpected behavior in the application, such as pages loading slowly or becoming unresponsive, which could suggest that their input is triggering LDAP query execution.
3. Incomplete or Inconsistent Results:
• In some cases, users may receive incomplete or inconsistent search results when querying for specific information. This inconsistency may indicate that the application is vulnerable to LDAP injection and is processing user input in LDAP queries.
4. Abnormal Response Times:
• Significant delays in response times after submitting certain inputs may imply that the application is processing LDAP queries asynchronously or executing multiple queries in the background.
5. Changes in Page Content:
• Users might observe unexpected changes in the content of web pages, such as additional information being displayed or elements disappearing, which could signal successful injection of LDAP filter strings.
Here is a Python script that takes a user’s full name as input to search for their identity in an LDAP directory:
from ldap3 import Server, Connection, ALL
def search_user(full_name): # Establish a connection to the LDAP server server = Server('ldap://example.com', get_info=ALL)
# Create a connection object and bind to the LDAP server using admin credentials conn = Connection(server, user=f'cn=admin,dc=example,dc=com', password='adminpassword') conn.bind()
# Construct an LDAP search filter based on the provided full name search_filter = f'(cn={full_name})'
# Perform an LDAP search with the constructed filter conn.search('ou=users,dc=example,dc=com', search_filter, attributes=['cn', 'mail', 'title'])
# Check if the search returned any entries if conn.entries: for entry in conn.entries: print(f"User: {entry.cn}, Email: {entry.mail}, Title: {entry.title}") else: print("No users found")
# Unbind from the LDAP server conn.unbind()
# Simulate user input search_user('John Doe')
In this code, the application allows searching for users by their full name (cn attribute).
Potential Vulnerabilities
This code is vulnerable to LDAP injection if the full_name parameter is not properly sanitized. An attacker can exploit this vulnerability by injecting LDAP-specific payloads into the full_name input.
Payload Examples
1. Enumerating All Users
• User Input (Full Name): *)(cn=*)
• Resulting Search Filter: (cn=*)(cn=*)
This payload will retrieve all users because the injected filter will match any entry with a cn attribute.
Types of LDAP injection:
1. Authentication Bypass
Description: Attackers modify the LDAP query to bypass authentication checks.
Example Payload:
• User Input: *)(uid=*)
• Original Query: (uid={user_input})
Resulting Query: (uid=*)(uid=*)
Steps:
1. The application constructs an LDAP query using user input to authenticate users.
2. If the user input is not sanitized, an attacker can input *)(uid=*).
3. The resulting LDAP query becomes (uid=*)(uid=*), which always returns true for any uid.
4. The application might treat this as a successful authentication for any user, bypassing the authentication mechanism.
2. Authorization Bypass
Description: Attackers manipulate queries to gain unauthorized access to resources.
Example Payload:
• User Input: *)(memberOf=cn=admin,ou=groups,dc=example,dc=com)
If the username and password aren’t sanitized, an attacker can use special characters to manipulate the query.
Let’s try random user name and password and observe the response. It says only admin account available
Injection Example: let’s use admin account along with * as password, the query becomes:
search_filter = “(&(cn=admin)(sn=*))”
This query will match entry in the LDAP directory, effectively bypassing authentication and logging the attacker in as an Admin user.
Mitigation Strategies
To prevent LDAP injection attacks, consider the following mitigation strategies:
• Input Validation: Validate and sanitize all user inputs to ensure they conform to expected formats and do not contain harmful characters.
• Parameterization: Use parameterized queries to separate user input from the query logic.
• Escaping: Properly escape special characters in user inputs to prevent query manipulation.
• Least Privilege Principle: Limit the privileges of the LDAP account used by the application to reduce the impact of potential injections.
• Regular Audits: Conduct regular security audits and penetration testing to identify and address LDAP injection vulnerabilities.
By understanding and mitigating these types of LDAP injection, organizations can better protect their LDAP directories and applications from malicious exploitation
Conclusion
LDAP injection remains a significant security vulnerability that can have severe implications for applications that rely on LDAP for user authentication and directory services. Understanding the mechanics of LDAP queries and the potential for exploitation is crucial for developers and security professionals alike.
By implementing best practices such as input validation, using prepared statements, and employing robust error handling, organizations can effectively mitigate the risks associated with LDAP injection. Regular security assessments and code reviews are essential to ensure that applications are resilient against such attacks.
