How to remediate – Jolokia XML External Entity

1. Introduction

Jolokia XML External Entity is a vulnerability affecting the Jolokia JMX-HTTP bridge, which provides an alternative to standard JSR-160 connectors. This flaw allows attackers to reload logging configurations from external URLs, leading to XXE injection. Systems using Jolokia without appropriate security measures are at risk. Successful exploitation can lead to information disclosure and potentially remote code execution.

2. Technical Explanation

The vulnerability stems from the reloadByURL action within Jolokia, provided by the Logback library. This action allows an attacker to specify a URL containing a malicious XML file. When this file is processed, it can trigger an XXE attack, enabling retrieval of sensitive data or interaction with local filesystems. The vulnerability is exploitable remotely if the Jolokia endpoint is exposed and accessible.

• Root cause: The reloadByURL action does not properly validate XML input from external sources.
• Exploit mechanism: An attacker sends a crafted HTTP request to the Jolokia endpoint, specifying a URL pointing to an XML file containing malicious entities. For example, an attacker could use an entity referencing a local file to read its contents.
• Scope: Affected systems are those running Jolokia with the vulnerable Logback library enabled and exposed via HTTP/HTTPS.

3. Detection and Assessment

To confirm vulnerability, first check if the Jolokia endpoint is accessible. Then verify the version of the Logback library used by Jolokia. Scanning tools can also help identify this issue. Review logs for suspicious activity related to reloading logging configurations from external URLs.

• Quick checks: Check if the Jolokia endpoint is reachable via a web browser or curl command.
• Scanning: Nessus, OpenVAS and other vulnerability scanners may have signatures for detecting vulnerable Jolokia instances. These are examples only.
• Logs and evidence: Examine application logs for entries related to reloading logging configurations from external URLs. Look for patterns indicating XML processing or file access attempts.

curl http://your-jolokia-endpoint/version

4. Solution / Remediation Steps

The primary solution is to disable the Jolokia endpoint if it’s not required. If Jolokia is necessary, secure it using Spring Security or another appropriate authentication and authorization mechanism.

4.1 Preparation

• Ensure you have a rollback plan in case of issues. A simple revert to the previous configuration should suffice.
• Change windows may be required for production systems, and approval from security or IT management is recommended.

4.2 Implementation

1. Step 1: If Jolokia is not needed, remove it from your application deployment.
2. Step 2: If Jolokia is required, configure Spring Security to protect the endpoint with authentication and authorization rules.
3. Step 3: Restart the application server or service to apply the changes.

4.3 Config or Code Example

Before

# No security configuration for Jolokia endpoint

After

spring:
  security:
    user:
      name: jolokia_user
      password: jolokia_password
      roles: ROLE_ADMIN
http:
  paths:
    /jolokia/**:
      - hasRole('ROLE_ADMIN')

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege limits the impact of exploitation, while input validation prevents malicious data from being processed. Safe defaults reduce the attack surface and patch cadence ensures timely updates.

• Practice 1: Implement least privilege to restrict access to sensitive resources like Jolokia endpoints.

4.5 Automation (Optional)

Infrastructure as Code tools can automate the configuration of Spring Security for Jolokia endpoints. This ensures consistent and repeatable security measures across environments.

# Example Ansible task to configure Spring Security
- name: Configure Spring Security for Jolokia
  copy:
    src: spring_security.yml
    dest: /path/to/application.yml
  notify: Restart application server

5. Verification / Validation

• Post-fix check: Access the Jolokia endpoint via a web browser or curl command. You should be prompted for authentication credentials.
• Monitoring: Monitor application logs for failed authentication attempts or unauthorized access attempts to the Jolokia endpoint.

curl -u jolokia_user:jolokia_password http://your-jolokia-endpoint/version

6. Preventive Measures and Monitoring

Update security baselines to include requirements for securing Jolokia endpoints. Incorporate SAST or DAST tools into CI pipelines to detect vulnerabilities early in the development lifecycle. Implement a regular patch review cycle to ensure timely updates of all components, including Logback.

• Baselines: Update your security baseline to require authentication and authorization for all Jolokia endpoints.
• Pipelines: Add SAST or DAST checks to your CI pipeline to scan for XXE vulnerabilities in XML files.
• Asset and patch process: Establish a regular patch review cycle (e.g., weekly or monthly) to ensure timely updates of all components, including Logback.

7. Risks, Side Effects, and Roll Back

Configuring Spring Security may introduce complexity and require additional maintenance. Incorrect configuration could lead to service disruptions. To roll back the changes, remove the Spring Security configuration and restart the application server.

• Risk or side effect 1: Incorrect Spring Security configuration can block legitimate access to Jolokia endpoints.
• Risk or side effect 2: Adding authentication may impact performance slightly.
• Roll back: Remove the Spring Security configuration from your application and restart the application server.

8. References and Resources

• Vendor advisory or bulletin: https://www.veracode.com/blog/research/exploiting-spring-boot-actuators
• NVD or CVE entry: Not applicable for this specific vulnerability, but related XXE vulnerabilities can be found on the NVD website.
• Product or platform documentation relevant to the fix: Spring Security Documentation