LDAP Vulnerabilities

Note** The following examples utilize Web for Penetration Testers which I do not own any rights to. These examples provide solutions to the live image of Web for Pentester 1 which can be downloaded at https://pentesterlab.com/exercises/web_for_pentester/course. Please attempt these exercises on your own before reviewing my solutions to gain maximum benefit.

 

Web for Penetration Testers Example 1

Lightweight Directory Access Protocol (LDAP) can be thought of as a hierarchical directory structure. Using the live iso of Web for Pentester 1 lab we can find that Open LDAP service is running by running performing a nmap scan from our kali box (attacking machine):


Figure 1

Using the ldapsearch command with the -b (base dn [top of hierarchy in this case]) -LLL (print responses in LDIF format without comments or version) and -x (simple authentication) flags (-h specifies the host) from our kali box (see Figure 2), we see that there are three common names (cn) entries: admin, admin2, and hacker.   

Let us look at /var/www/ldap/example1.php file:

if(isset($_GET[“username”])) {$user = “uid”.$_GET[“username”].”ou=people,dc=pentesterlab,dc=com”;}

$lb = @ldap_bind($ld,$user,$_GET[“password”]);

if ($lb) { echo “AUTHENTICATED”; }

else { echo “NOT AUTHENTICATED”; }

The organization unit (ou) is set to people and the domain components (dc) are pentesterlab and com. Our Directory Information Tree (DIT) looks like this:



Figure 2

From the code, we see that the user variable is set with a search for a matching uid within the ou people. The ldap bind that is subsequently performed appears to be secure with no possible points of injection. However, this does not stop us from attempting a null bind.

From the nmap scan we can see that our target is using an older version of LDAP; we could search the national vulnerability database (nvd) to see if these versions of OpenLDAP are vulnerable to a null bind; but it is a very easy and simple test to perform. Removing the username and password parameters we find that our target is susceptible to a null bind:

Figure 3

Web for Penetration Testers Example 2

Attempting a null bind for example 2 is ineffective so let us explore other options.

Let us look at /var/www/ldap/example2.php file:

if($ld) {$lb=@ldap_bind($ld,”cn=admin,dc=pentesterlab,dc=com”,”pentesterlab”);

if($lb) {$pass=”{MD5}”.base64_encode(pack(“H*”,md5($_GET[‘password’])));

$filter=”(&(cn=”.$_GET[‘name’].”)(userPassword=”.$pass.”))”;

if(!($search=@ldap_search($ld,”ou=people,dc=pentesterlab,dc=com”,$filter))){

            echo(“Unable to search ldap server<br>”);

            echo(“msg:’”.ldap_error($ls).”’</br>”);

} else {

            $number_returned=ldap_count_entries($ld,$search);

            $info=ldap_get_entries($ld,$search);

            if($info[“count”]<1){ echo “UNATHENTICATED”; }

            else {echo “AUTHENTICATED as”; echo(“ ”.htmlentities($info[0][‘uid’][0]));}

We can see from the code snippet that the password is md5 hashed. This makes it difficult to inject a payload into the password field. However, the filter variable uses a Boolean “and” to get both the username and hashed password. If the password can be commented out or got rid of, we may be able to inject a payload. This can be done using a null byte (%00). Setting the second part of the filter to an always true condition (cn=*), we could log in as anyone. Our payload looks like the image below:


Figure 4

In Figure 4, we see we could use the name or cn parameter to enumerate through some users. Any password will be accepted because it is nulled out; if both of the inputs is always true (e.g. has a wild card ‘*’) and neither parameter is hashed, it’s possible to login with any user.  

Conclusion

Open LDAP is a great tool for organizing objects such as user credentials. However, as we saw with example 1; developers must be aware of null binds and assure their version of LDAP is not susceptible to such attacks. LDAP injections are also possible which is why all input should be sanitized. In Example 2, if the developer hashed both username and password or blacklist the wildcard character (or better yet, whitelist the username parameter to only accept alphabetic characters) the above injection could have been avoided. Check out the references for further reading.

References

OWASP. (2020). LDAP Injection Prevention Cheat Sheet. Retrieved from

https://cheatsheetseries.owasp.org/cheatsheets/LDAP_Injection_Prevention_Cheat_Sheet.html

 

OWASP. (2020). Testing for LDAP Injection. Retrieved from https://owasp.org/www-

project-web-security-testing-guide/stable/4-Web_Application_Security_Testing/07-Input_Validation_Testing/06-Testing_for_LDAP_Injection.html

 

Ellingwood, J. (2015, May 29). Understanding the LDAP Protocol, Data Hierarchy, and

Entry Components. Retrieved from https://www.digitalocean.com/community/tutorials/understanding-the-ldap-protocol-data-hierarchy-and-entry-components



Comments

Post a Comment

Popular posts from this blog

Covering Your Tracks

The ability to remain stealth during a penetration exercise is what separates a sophisticated hacker from a script kitty. The phrase “The Quieter You Become, The More You Are Able to Hear” holds true, especially in the field of hacking. Being able to perform Ani-forensics and avoid detection is critical to the success of hacking and penetration testing and understanding these methods is beneficial, even for white hat hackers, as there will be times in a penetration where the system is already compromised. In such cases, understanding what the attacker is doing in order to cover their tracks can help determine the sophistication of the attack or bring prosecution to the attacker. All hacks begin with system enumeration and nmap is one of the best tools to use during this discovery phase. However, as I explained in Scanning With nmap blog, port scanning a bunch of IP Addresses or every port on a target system is noisy and can cause denial of service conditions (very bad if you are
Read more

Covering Your Tracks - Anti-forensics for the Cloud - Introduction

Image
Before delving into cloud forensics there are some concepts that need to be explained. The cloud consisted of two entities, provider (companies that host cloud technologies) and tenants (companies that use cloud technologies from the providers). The cloud generally consists of three service models:  Infrastructure-as-a-Service (IaaS) where the provider provides the hardware and network. Platform-as-a-Service (PaaS) where the provider provides all the components to a tenant's application. Software-as-a-Service (SaaS) where the provider supplies the software and the components to run it and the tenant uses and at most configures the application. Chris Brenton gives a great overview of the cloud and the challenges it poses in the link below: https://www.sans.org/blog/pen-testing-in-the-cloud/ Surprisingly there is not a lot of coverage out on the web for cloud forensics and this makes sense. Cloud forensics analysts, especially for tenants, may be somewhat limited on acc
Read more

Cross-Site Scripting (XSS) Introduction

Image
  Cross-Site Scripting (XSS) Introduction Note** The following examples utilize Web for Penetration Testers which I do not own any rights to. These examples provide solutions to the live image of Web for Pentester 1 which can be downloaded at https://pentesterlab.com/exercises/web_for_pentester/course . Please attempt these exercises on your own before reviewing my solutions to gain maximum benefit.   Introduction XSS is an often-overlooked vulnerability. The generic “Hello World” example of XSS (e.g. <script>alert(“XSS”);</script>) is an overly benign example. Once an XSS vulnerability is discovered it becomes possible for attackers to modify the webpage to re-direct users to malicious site, steal a user’s session or cookie, or bypass a log in. Because XSS is such a huge topic, a series will be developed with exploitations to follow. For this blog article, XSS detection will be focused on. Eventually this series will cover JSON, XML, XPath, JQuery, and other typ
Read more