You could've applied all 1,449 Oracle patches and still been hit by this attack

In late July, Oracle released a mammoth security patch dump with 1,449 patches, in a perhaps unprecedented bad day for database admins. None of them, it turns out, would have prevented the credential theft on an Oracle database server described by security platform Huntress. Even if it had been fully patched, everything working, it still would have happened," said Craig Savage, cybersecurity lead at Oracle third-party support vendor Spinnaker Support, referring to the attack. In July, Huntress was alerted to credential theft activity, according to a post from the security company. The attack involved a "simple" SQL injection exploiting an unnamed organization's public-facing web app. Although SQL injections have a long history and are easy to avoid with good info-sec housekeeping, what happened next was more unusual. After gaining initial access, the threat actor dropped a post-exploitation toolkit (called khunt) via a Java Source within an Oracle database, which is a novel aspect of this attack," Huntress said. Because a code-object can be loaded directly in Oracle's database engine, the malicious actors were able to upload their toolkit directly into the database. This is a technique that's previously been discussed and described over the years, including via a technique described as oraexec - however, the use of the technique in the wild has rarely been documented," Huntress said. Oracle's database has an embedded Java Virtual Machine (JVM), and users can take Java source code and store it as a database object. This is what attackers did during this incident: they fed CREATE JAVA SOURCE commands to the Oracle database from [Java implementation] Tomcat, through the [database] connection, and the Java source code contained within was then compiled directly inside the database as a stored schema object," the vendor said. Speaking to The Register, Savage said: Oracle has its own JDK. You are able to build and run Oracle Java programs within the database. It should never be something a web server can do. In fact, in a production Oracle environment, it should be locked down. It should only be re-enabled during a development or maintenance window, for example. It was poorly configured, poorly secured, but it wasn't an Oracle breach." The ability to run Java in the database should be limited to only the DBA user, Savage argued, and users should disable the ability to compile code on a production server. If they'd done that, it would have downloaded that Java code, and JDK would not have been configured to compile it," he said. Savage said cybercriminals were seeking to exploit this kind of functionality more commonly, rather than simply looking to find and use vulnerabilities. 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, and that's what we saw here. That's the wake-up call. Oracle published something like 1450-ish patches. Organizations are totally focused on patch, patch, patch, but you still need to do the basics," he said. (R)