How to remediate – Jolokia Arbitrary File Read

1. Introduction

Jolokia Arbitrary File Read is a vulnerability affecting the Jolokia JMX-HTTP bridge, allowing unauthenticated attackers to read arbitrary files on the server. This poses a high risk to confidentiality as sensitive data can be exposed. Systems running an accessible Jolokia endpoint are usually affected. Impact: Confidentiality – High, Integrity – Low, Availability – Low.

2. Technical Explanation

Jolokia is used as an alternative to JSR-160 connectors for managing Java applications via HTTP. The vulnerability lies in the compilerDirectivesAdd action which lacks proper authentication and authorization checks, permitting file reading. An attacker can send a crafted request to read any file accessible by the application user account.

• Root cause: Missing authentication on the compilerDirectivesAdd action allows arbitrary file access.
• Exploit mechanism: An attacker sends an HTTP request with malicious parameters to the Jolokia endpoint, specifying a target file path for reading.
• Scope: Systems running vulnerable versions of Jolokia are affected.

3. Detection and Assessment

Confirming vulnerability involves checking if the Jolokia endpoint is accessible and whether it allows unauthenticated access to read files.

• Quick checks: Check for the presence of a /jolokia or similar endpoint in your web application’s URL space.
• Scanning: Nessus plugin ID 16839 can detect exposed Jolokia endpoints. This is an example only, and may require tuning.
• Logs and evidence: Examine web server access logs for requests to the Jolokia endpoint (e.g., /jolokia).

curl -I http://your-server:8778/jolokia   # Check if the endpoint is accessible

4. Solution / Remediation Steps

The primary solution is to disable the Jolokia endpoint if it’s not required, or secure it with Spring Security if needed.

4.1 Preparation

• Ensure you have access to the application’s deployment files and a rollback plan in case of issues. A change window may be needed depending on service criticality.

4.2 Implementation

1. Step 1: If not required, remove or disable the Jolokia endpoint from your application configuration. This usually involves removing dependencies or modifying deployment settings.
2. Step 2: If required, configure Spring Security to protect the Jolokia endpoint with appropriate authentication and authorization rules.

4.3 Config or Code Example

Before

# No security configuration for Jolokia endpoint in spring-security.xml or similar file

After

<http pattern="/jolokia/**" security="true">
    <intercept-url pattern="/jolokia/**" access="hasRole('ROLE_ADMIN')" />
    <form-login/>
</http>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue and similar vulnerabilities.

• Least privilege: Restrict access to sensitive resources like Jolokia endpoints to only authorized users or services.
• Secure defaults: Ensure that new deployments have secure configurations by default, disabling unnecessary features like Jolokia unless explicitly required.

4.5 Automation (Optional)

If using infrastructure-as-code tools, you can automate the removal or configuration of the Jolokia endpoint.

# Example Ansible task to remove a Jolokia dependency
- name: Remove Jolokia dependency from Maven project
  file:
    path: /path/to/pom.xml
    state: absent
    regexp: '<dependency>.+?jolokia.+?</dependency>'

5. Verification / Validation

Confirm the fix by verifying that unauthorized access to the Jolokia endpoint is blocked, or that it has been removed entirely.

• Post-fix check: Attempt to access the /jolokia endpoint without authentication. You should receive an HTTP 403 Forbidden error if Spring Security is configured correctly.
• Re-test: Re-run the quick check from Section 3 and confirm that the Jolokia endpoint is no longer accessible or requires authentication.
• Monitoring: Monitor web server logs for unauthorized access attempts to the /jolokia endpoint.

curl -I http://your-server:8778/jolokia   # Should return a 403 Forbidden error if secured

6. Preventive Measures and Monitoring

Update security baselines to include secure configurations for Jolokia, and add checks in CI pipelines to prevent vulnerable deployments.

• Baselines: Update your application’s security baseline or policy to require authentication for all JMX endpoints, including Jolokia.
• Pipelines: Integrate SAST tools into your CI pipeline to scan for vulnerabilities like missing authentication checks in configuration files.
• Asset and patch process: Establish a regular review cycle for application configurations to identify and address potential security issues.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Disabling Jolokia could disrupt application monitoring if it’s the sole method for collecting metrics.
• Risk or side effect 2: Incorrect Spring Security configuration may lock out legitimate users.
• Roll back: If disabling Jolokia causes issues, restore the original configuration files and redeploy the application. If using Spring Security, revert to the previous security settings.

8. References and Resources

• Vendor advisory or bulletin: https://thinkloveshare.com/en/hacking/ssrf_to_rce_with_jolokia_and_mbeans/
• NVD or CVE entry: Not applicable (no specific CVE assigned)
• Product or platform documentation relevant to the fix: https://jolokia.org/