Attackers Exploit Oracle Database Java VM for Post-Exploitation Toolkit Deployment
A novel attack bypassed Oracle's July patch release by using SQL injection to deploy a post-exploitation toolkit directly into an Oracle database via its embedded Java Virtual Machine.
Security researchers have detailed a sophisticated attack that circumvented Oracle's extensive July patch release, successfully deploying a post-exploitation toolkit directly into an Oracle database. The incident, identified by the security firm Huntress, highlights a critical vulnerability not in the patching process itself, but in the misconfiguration of production environments.
The attack began with a seemingly straightforward SQL injection vulnerability in an organization's public-facing web application. While SQL injection flaws are a well-known and preventable class of vulnerability, the subsequent actions taken by the threat actors were particularly noteworthy. After gaining initial access through the web application, the attackers leveraged the Oracle database's embedded Java Virtual Machine (JVM) to introduce their malicious toolkit.
This technique involved using CREATE JAVA SOURCE commands to compile malicious Java code directly within the database as a stored schema object. This allowed the threat actors to bypass traditional security measures that might have prevented the execution of external code. The toolkit, dubbed 'khunt' by Huntress, was effectively hidden and executable within the database engine itself.
Craig Savage, cybersecurity lead at Oracle third-party support vendor Spinnaker Support, explained that Oracle databases include a built-in Java Development Kit (JDK) that allows Java code to be compiled and run within the database. This legitimate functionality, when improperly secured, becomes a potent weapon for attackers. "It should never be something a web server can do. In fact, in a production Oracle environment, it should be locked down," Savage stated.
The attack vector was particularly effective because it exploited a feature that should have been disabled or severely restricted in a production setting. Savage emphasized that the ability to compile Java code within the database should ideally be limited to the DBA user and only enabled during specific development or maintenance windows. "If they’d done that, it would have downloaded that Java code, and JDK would not have been configured to compile it," he added.
This incident underscores a growing trend where cybercriminals are moving beyond simply exploiting known vulnerabilities. Instead, they are actively seeking out and weaponizing legitimate, albeit misconfigured, functionalities within software products. "We're starting to see more and more of this: these cybercrime gangs now know about these products. They don't just know how to break them. They also know what legitimate functionality they could potentially use if it's been turned on," Savage observed.
While Oracle's July patch release addressed a massive number of vulnerabilities, this attack serves as a stark reminder that patching alone is insufficient. Robust security requires a multi-layered approach, including diligent configuration management, disabling unnecessary features, and adhering to fundamental security best practices. The incident highlights that even systems with the latest patches can remain vulnerable if core security hygiene is neglected.