1. Disclaimer
2. Introduction
3. The Vulnerability
4. Methodology
   1. Shodan
   2. Ldapsearch
   3. Bash
   4. Python
5. Ethical Dilemmas
6. Case Study – The College
7. Conclusion

Disclaimer

All activities presented within this post have been conducted for research purposes. All efforts were made to disclose the findings responsibly to the owners. Where more intrusive tests were conducted, I made sure to contact the owners beforehand.

Introduction

Recently, I embarked on a journey to scout the internet for one specific vulnerability. On the journey, I encountered ethical dilemmas, discovered critical vulnerabilities, and gained valuable insights through my experiences. The project started from a rather simple question, but ended revealing a lot more than I expected. You can find a simple, less technical description here: https://youtu.be/WcFZd_68HVg?si=er-D3lgZ0CtRI8nq.

The Vulnerability

During the past year, I found myself fascinated with LDAP Anonymous Binding. In itself, it is not necessarily a misconfiguration or vulnerability, but rather a feature of LDAP, allowing clients to connect and search the directory (bind and search) without logging in. For instance, if the directory contains publicly accessible information that does not require authentication, such as a company’s contact directory or public phone book, one may allow anonymous binds for read-only access to this information. Also, some older applications and devices may not support authentication when querying LDAP directories. In such cases, one may need to allow anonymous binds temporarily to ensure compatibility.

However, there is a possibility that LDAP Anonymous Binding is allowed even when the directory contains sensitive information. This can be a serious breach of confidentiality, as anyone can access the sensitive information behind the unprotected service.

Methodology

This project’s core questions were “How many servers allow LDAP Anonymous Binding?” and “What sort of information do they expose?”. In order to answer these questions, I used the following tools/utilities:

• Shodan
• Ldapsearch
• Bash
• Python

Shodan

Shodan is a search engine designed to locate and gather information about devices and services connected to the internet. For me, it was the perfect tool for this project, as I could simply search for “LDAP Anonymous” and it would give me a fairly reliable list of results. Could I have used masscan or any other scanner? Probably so, but Shodan allows me to be more quiet, as I am not the one doing the active scanning. So after Shodan displayed over 3000 results, I downloaded the data as JSON.

Ldapsearch

Ldapsearch is a command-line utility used to query and retrieve information from LDAP directories. For this project I ran ldapsearch in two steps:

1. ldapsearch -H ldap://$target -x -s base namingcontexts
2. lapsearch -x -H ldap://$target -b “‘”$namingcontext “‘”

Bash

The usage of bash was pretty simple for this project.

1. Extract the IP addresses from the JSON output from Shodan
   • cat shodan_output.json | jq | grep “ip_str” | awk ‘{print $2}’ | tr -d ‘”‘ | sort -u > targets.txt
2. Run ldapsearch to extract the namingContexts for each IP address
   • for target in $(cat targets.txt); do echo “Naming Context for $target”;timeout 5 ldapsearch -H ldap://$target -x -s base namingcontexts;echo “##########################################”;done > ldap_search.output

Let me break-down the second command:

• for target in $(cat targets.txt): We take each IP extracted from the Shodan output one by one
• echo “Naming Context for $target”: We display “Naming Context for” followed by the IP address
• timeout 5 ldapsearch -H ldap://$target -x -s base namingcontexts: We run ldapsearch with a timeout of 5 seconds
• echo “##########################################”: We display a bunch of “#” (the reason for this will become clear in the next section)
• > ldap_search.output: We redirect the output to ldap_search.output

And that is it. From here I moved to Python, not because what I needed could not be done in bash, but because I feel more comfortable in Python.

Python

I decided to use Python to parse ldap_search.output, extract the namingContexts, generate ldapsearch commands in the correct format (lapsearch -x -H ldap://$target -b “‘”$namingcontext “‘”), run them in parallel to save time, and save the output individually in a folder. At the moment, I am not 100% comfortable with sharing the script, because I am afraid script kiddies may use it. However, describing what the script does is in my comfort zone, as more advanced users could do this without my help anyway. So here it is:

1. Split the contents of ldap_search.output by “##########################################”
2. Grab the IP addresses for each item by searching for “Naming Context for”
3. Find each appearance of “namingContexts:” and create a list of all naming contexts displayed
4. Use the IP and namingContexts to create the ldapsearch commands
5. Use your preferred parallel execution method to execute the ldapsearch commands

It is fairly simple, it took me less than 60 lines of code. I may publish the script as well, but I am still waiting for a few disclosures to be resolved.

Ethical Dilemmas

Before I move further and display some juicy findings, I would like to touch upon the ethical issues which I faced during this project.

Generally, I consider myself an Ethical Hacker. However, I also believe that ethics are inherently subjective and that each individual possesses their own moral compass. Often, hackers are split into three categories: White Hat, Grey Hat and Black Hat. I would argue that there are too many shades of grey to fit in one category. The following continuum reflects my personal assessment of certain activities on a simplified ethics scale:

During this project, I have not exfiltrated data and have not launched Denial of Service attacks. However, all other activities were fair game. The reason for this was that my underlying objective was making the internet safer. Everything that I found was reported responsibly – and to be fair, it was not easy. I was ignored completely by some organizations and had a hard time finding contacts for others. Nevertheless, I still decided to go out of my way and practice my due diligence in notifying organizations that their security posture needs improvements.

Case Study – The College

One of the notable organizations which I found allowed LDAP Anonymous Binding was a college. It exposed data of all students and members of staff. Here you can see the data for one user:

At the moment we have the following pieces of information:

• Username
• Full name
• Password hash in SSHA format (managed to crack for 1711 accounts)
• Email address
• Security question
• Security answer

So not only was I able to crack the password for 1711 accounts, but I have the answer to the security question (as well as the questions themselves) for ALL accounts… Well, it cannot be this simple, can it?

Let’s try the Forgot Password flow!

I am in! So, the data exposed via LDAP allowed me to change a user’s password and enter their account. And you know what is beautiful? Single Sign-On (SSO) gave me access to Google (Mail, Drive, Photos), Moodle, as well as the college web site which exposed sensitive data such as the mailing address and payment and card details.

Conclusion

So, I started from a LDAP Anonymous Bind and ended with account takeover of all members of the institution exposing highly sensitive data. At the moment, the institution fixed the Anonymous Bind, but have yet to change all passwords and security questions/answers. This was quite a ride – an experience of mass discovery of one misconfiguration leading to the exploitation and full takeover of one organization. There were a few challenges that I faced on this journey:

• The huge amount of data resulted from the LDAP directories
  • I saved tens of Gigabytes of data in text format. I have yet to analyze it all, but grep has been my best friend during this project.
• Owners not responding to my emails
  • Several organizations ignored me altogether. Often, LDAP disclosed the phone numbers or personal email addresses of the high-ranking employees (CEO, CTO, etc.). Yet, I still decided to use the official channels despite being ignored because I wanted to avoid any perception of arm-twisting.
• Proving the impact
  • A few organizations responded saying that “this is by design”. For instance, disclosing the contact details (names, emails, phone numbers and addresses) of over 9000 employees or affiliates seems to be “by design” for certain organizations.
  • For the case study presented in this article, it was important to access an account to prove the impact. For instance, even with access to the security question, if MFA was set up or if a confirmation email was sent to approve the password change, the exploit chain would have stopped there. So actually going in and checking out the SSO and all the integrations which are compromised via this vector was a clear-cut way to prove impact.