CVE-2023-41580: GitHub - ehtec/phpipam-exploit

phpipam-exploit

Affected versions: <1.5.2

LDAP injection in /app/admin/users/ad-search-result.php

LDAP injection is similar to SQL injection, but a lot less well known. Because the user can fully control the POST[‘dname’] variable, the query can be altered in $adldap->user()->info() as the adLDAP library itself does not take care of sanitization. This can be used by an authenticated attacker to enumerate arbitrary fields in the LDAP server (which may contain sensitive data like passwords, social security numbers, etc inserted by other applications). Even the phpipam admin should not have access to this information, only to the fields that need to be shown when searching for LDAP users at new user creation. LDAP injection can also be leveraged to Denial of Service.

Stored Cross-Site Scripting in /app/admin/users/ad-search-result.php

The LDAP server may return strings containing special HTML characters, which means that if a user can edit one of the LDAP fields that is printed by phpipam using another application interacting with the same LDAP server (which is a realistic scenario, there is no reason to store escaped characters in a database, the good practice approach is to escape them when printing, not when inserting), a javascript payload can be placed such that it is executed with administrator privileges as soon as the user appears in the search results of a search an administrator executes. I created a PoC to add another administrator user with known credentials, the payload is injected in the email field of the LDAP server (other fields are possible too)