Command Injection Affecting Apache Directory
Tags: security, hacking, apache, owasp
Published: 2023-11-22 00:46:47



![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/zya9ikkr7lgujd9niesz.png)

Apache Directory Studio is a Desktop application which basically is used as an LDAP tooling platform for the LDAP server which was intentionally designed for Apache DS. The basic purpose of the application is to handle LDAP databases of the Apache HTTPD server


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/8m03zac5kwqbeul9g09z.png)

As i have openly admitted many times that i am guy who research is based totally on logics, this once again was a command injection vulnerability whose misuse was based on logical thought process.

## Main modules of Apache Directory Studio

Basically Apache LDAP studio and Apache Directory studio have several components which include

1. LDAP Editor

2. LDAP browser

3. Schema Editor

## Workflow of Apache Directory Studio

The functions of the modules can be interpreted by their names. Since the main modules of the application is LDAP Editor using which one can actively add LDAP queries to the ApacheDS integration, it was obvious to me that the inputs i give would be passed through the Editor and reflected in the Browser. Upon researching more, i came to know that symbols such =,+,-,, are not filtered in the LDAP Editor queries and once can add attributes like =1+1 etc, which can be observed in LDAP browser module.


![Image description](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/6whp76yxaoqjfyl8aqc9.png)

Researchers who normally test Desktop application are aware of the fact that the malicious input being reflected in a Desktop application has no value unless an active exploit is possible which is contrary to the case in Web applications. So i directed my search to the export features of the LDAP module and came across a CSV export wizard whose function i learned from the link below

https://directory.apache.org/studio/users-guide/ldap_browser/tools_csvexport_wizard.html

Testing Methodology

In my methodology of Business Logic testing. which i am sure would be disagreed by several researchers is that discovering the logical flaw in mere black and white manner is not enough. There should to be two aspects of the flaw that should be worked on which are:

1. Coming up with a concrete exploit
2. Possible ways of remote misuse

## Payload Generation

The first part was not that difficult as there are several sources on the web that can be used to craft payloads which can be used in excel CSV exploits. So i came up with the exploit payload that could be used to execute a calculator using the CSV which would be

-10+33 cmd| /C calc!A0

## Misuse Interpretation

The second part however took sometime, to convert this into a remotely usable exploit it was mandatory to know what users are granted what permissions in the LDAP module which i studied from the link below

http://fideloper.com/user-group-permissions-chmod-apache

I came to know that users with least of the privileges are able to insert comments in the LDAP queries.

## Exploit Flow
So here is the exploit flow i devised in the end.

1. Admin creates an LDAP query using LDAP editor in the Directory studio module
2. Admin allows malicious user to edit comments
3. User enters remote execution payload in the comments or the query itself
4. Admin exports the excel spreadsheet
5. Admins system gets compromised

I sent this complete report along with the CVE details to Apache team and they timely acted on the issue. However the Internet Bug bounty team considered this an issue but an out of scope as the issue is partially related to Apache Directory Studio not Apache HTTPD server.

The Bugtraq CVE link is where you would find the official CVE writeup and the patch details about the flaw. Apache assigned the CVE on my behalf that is CVE: 2015–5349
http://seclists.org/bugtraq/2016/Jan/5

## Credits to Researchers

I believe in giving proper credits to the ones from whom i got bits of knowledge about this flaw.

1. I would like to thank Appsec for coming up with the initial exploits for this issue targeted for web applications which helped out alot in the research. https://hackerone.com/appsec3

2. I would also like to thank James Kettle, the author of contextis.com whose article helped me out in devising the proper payloads http://www.contextis.com/resources/blog/comma-separated-vulnerabilities/

And in the end of course all of you lovely people for taking time to read this post. I will soon be doing another posts of my learning break knowledge applied in Cloud testing.

Follow me for more such content:
LinkedIn: https://www.linkedin.com/in/basimghouri
Github: https://github.com/ghourigeeks