Exploiting Insecure JDBC Driver Configurations for RCE and SSRF

TLDR: This research exposes how misconfigured or vulnerable JDBC drivers in Java applications can be weaponized to achieve Remote Code Execution (RCE) and Server-Side Request Forgery (SSRF). By manipulating driver properties like logger paths or class initialization parameters, attackers can bypass standard security controls. Pentesters should audit database connection strings for these properties, while developers must implement strict allow-lists for driver configurations.

Database drivers are often treated as trusted black boxes, but they are essentially complex, feature-rich libraries that handle untrusted input. When an application allows user-controlled input to influence JDBC connection properties, the security boundary between the application and the database driver collapses. This research highlights how common drivers for IBM Informix, IBM DB2, Google Cloud Spanner, and Apache Calcite Avatica can be coerced into performing unintended actions, including arbitrary file writes and remote code execution.

The Mechanics of Driver-Level Exploitation

The core issue is that many JDBC drivers expose configuration properties that were intended for debugging or advanced integration but function as powerful primitives for an attacker. When these properties are exposed via a connection string, they become an attack surface.

One of the most dangerous vectors identified is logger injection. For example, the IBM DB2 JDBC driver allows users to specify a traceFile property. If an attacker can inject this property into a connection string, they can force the driver to write its debug logs to an arbitrary location on the filesystem. By setting this path to a web-accessible directory and crafting a malicious log entry, an attacker can drop a JSP webshell.

jdbc:db2://127.0.0.1:5001/test;traceFile=/var/www/html/shell.jsp;traceLevel=-1;traceFileAppend=true

This technique is not limited to file writing. The research also demonstrates how to trigger JNDI injection by manipulating properties that control how a driver connects to a naming service. By pointing the driver to a malicious LDAP or RMI server, an attacker can force the application to deserialize a remote object, leading to full RCE.

Bypassing Security Restrictions with Gadgets

Modern Java environments have increasingly restricted dangerous operations like reflection and deserialization. However, these restrictions often rely on the assumption that the application code itself is the only source of risk. When an attacker can influence the driver's initialization, they can use "gadgets" found within the driver's own dependencies or the JDK to bypass these protections.

The researchers utilized tools like gadget-inspector to identify these paths. In the case of the Apache Calcite Avatica driver, they discovered that the driver would instantiate arbitrary classes based on user-provided properties. By combining this with a known gadget chain, they successfully bypassed Java 17’s reflection restrictions, which are documented under OWASP's Deserialization of Untrusted Data guidance. This specific vulnerability was assigned CVE-2022-36364.

Real-World Engagement Strategy

During a penetration test, the most common place to find these vulnerabilities is in application configuration files, environment variables, or administrative interfaces that allow users to define database connections. If you encounter an application that accepts a full JDBC connection string as input, you have a high-probability target.

Start by fuzzing the connection string with common debugging properties. If the application returns an error, check if the error message reveals the driver type. Once the driver is identified, consult the vendor's documentation for properties related to logging, tracing, or external authentication. For instance, if you are testing a system using the Teradata driver, look for properties that enable browser-based SSO, as these can often be abused to trigger command injection by forcing the driver to execute local binaries.

Defensive Hardening

Defending against these attacks requires a shift in how we view database connectivity. First, never allow user input to directly modify a JDBC connection string. If dynamic connections are required, use a strictly defined allow-list of properties and validate all values against a known-good pattern.

Second, ensure that the application process runs with the least privilege necessary. If the application does not need to write to the filesystem, the service account should not have write permissions to the web root. Finally, keep your JDBC drivers updated. Many of these vulnerabilities are fixed by vendors who have started to sanitize or disable dangerous configuration properties by default. If you are maintaining a custom driver or a fork, ensure you are tracking upstream security advisories and applying patches immediately.

The era of assuming that database drivers are inherently safe is over. As these findings demonstrate, the configuration of the connection is just as critical as the query itself. When you are auditing an application, look past the SQL injection points and start examining the plumbing that connects the application to its data. You will likely find that the most interesting vulnerabilities are hiding in the properties you were told to ignore.