A week and a half after Oracle's out-of-band Java SE 7 Update 7 and three weeks after Atif Mushtaq at FireEye first published the CVE-2012-4681 analysis. The substantive question now is not the vulnerability itself, which has been patched, but what the Java-zero-day-becomes-exploit-kit-payload speed tells us about the operational supply chain that turns a freshly-discovered zero-day into a tool used at scale against ordinary internet users.
The proximate timeline. CVE-2012-4681 is a sandbox escape through Java's Reflection API — specifically, the exploit chains together calls that allow code running in the Java applet sandbox to obtain references to security-sensitive classes that should not be accessible from the sandbox, and uses those references to disable the sandbox and execute arbitrary Java code with full local privileges. The technical chain has been written up in detail by both FireEye and Immunity. What is operationally interesting is the speed: the vulnerability was being exploited in the wild by 26 August through what appears to have been a relatively obscure exploit kit, was rapidly integrated into the BlackHole exploit kit (the dominant commercial exploit-kit-as-a-service product) by 28 or 29 August, and was being delivered to ordinary internet users through compromised websites and malvertising by the time Oracle's patch shipped on 30 August. The window between zero-day disclosure to the operator community and zero-day deployed at scale was, in this case, less than a week.
The supply chain matters because it tells us where the practical defensive priority is. Most of the engagements I run still have substantial Java browser-plugin deployment — financial-services clients particularly, because the Java applet model has been the standard delivery mechanism for browser-based banking applications for fifteen years. The clients run various endpoint-protection products, all of which advertise Java-exploit detection. The empirical reality of the past three weeks is that the endpoint-protection products were still updating their Java-exploit signatures while the BlackHole-exploit-kit operators were already shipping CVE-2012-4681 payloads. The browser-plugin Java install base was therefore unprotected in practice for several days after the Oracle patch shipped, because the patch deployment lag at most clients is more than several days.
The operational answer that I have been pushing for the past two weeks is the same one the US-CERT advisory made in their unusually direct language: disable the Java browser plugin entirely if you can, and apply rigorous justification before allowing it to be re-enabled for those applications that genuinely require it. This is, on the face of it, a reasonable position; it is also a position that several of my clients cannot adopt cleanly because of the legacy Java-applet banking infrastructure and various other in-house applications that still depend on the plugin. The practical conversations have therefore been about partial disablement — enable Java in a separate browser used only for the legacy banking application, disable it in the general-purpose browser used for everything else — and about rolling out the Oracle patch faster than the standard quarterly patch cycle allows.
For the Hedgehog SOC detection content I have been writing, CVE-2012-4681 has reframed how I think about the browser-plugin attack surface. The previous detection content treated plugin-based exploitation as a single category; the past three weeks have shown that the operational shape of plugin exploitation is a multi-stage flow with distinct detection points. The malvertising or compromised-website stage is detectable in the proxy or DNS logs (the BlackHole exploit kit has a small number of distinctive URL patterns, and the ad networks that the malvertising came through have known signatures). The exploit-delivery stage is detectable in the browser process itself if endpoint instrumentation is sufficient. The post-exploitation stage is detectable in the standard ways — outbound C2 connections, unusual process spawning, persistence-mechanism creation. The detection content for the SOC has been reorganised this week to separate these three stages so the analysts can see the kill-chain phase rather than just the named-CVE indicator.
The wider point about Java specifically is one I have been making to clients for some years and have been making more loudly since CVE-2012-4681. The Java browser plugin is in 2012 a legacy technology being supported for legacy applications; it is in active use across roughly three-quarters of the engagement client base; it produces a disproportionate share of the browser-based attack surface; and the patching cycle for Oracle Java is not aligned with the operational tempo at which exploit kits weaponise new disclosures. The structural answer is to remove the Java plugin from browser deployments and replace the legacy applications that depend on it with native-application or modern-web equivalents. The cost of this is non-trivial — the bank-applet replacement programmes I have seen estimated are typically £200k–£500k for a medium-sized financial-services client — and the strategic case has been hard to make against the "Java has worked for fifteen years, the cost is large, the threat is tolerable" defence. CVE-2012-4681 is going to make the strategic case easier; the next zero-day in the same shape will make it easier still.
The next post will probably be the Hedgehog SOC operational update — the first monitoring engagement has been running for nearly six weeks and is producing useful operational data — or the November Adobe/Microsoft patch cycle if anything substantial drops there. The South Carolina Department of Revenue breach that has been quietly developing through the past month is also moving towards public disclosure, and I will write that up when it lands.