CVE-2012-4681: bypassing built
Vulnerabilities mentionedAll →
| CVE | Vulnerability | CVSS | EPSS | Flags | Affected | Exposure | Published |
|---|---|---|---|---|---|---|---|
| CVE-2012-4681 | Remote Code Execution in Oracle Java SE Runtime Environment (JRE) A vulnerability in the Java Runtime Environment (JRE) component of Oracle Java SE allows arbitrary code execution remotely. It is triggered when the JRE processes attacker-controlled input, letting the attacker run arbitrary code in the context of the affected Java process. Any system running an affected Oracle Java SE build is exposed, including desktops and servers where Java is installed or used. Exploitation is confirmed in the wild: the flaw was weaponized by exploit kits in 2012 (e.g., the Whitehole Exploit Kit, whose use in the wild coincided with this CVE's coverage), was added to CISA's KEV on 2022-03-03 with known ransomware use, and EPSS currently assigns a 98.5% probability of exploitation within 30 days (100th percentile). No public proof-of-concept is catalogued in this data, but the flaw should be treated as actively exploited and urgent to patch. Do: Inventory all systems running Oracle Java SE and apply updates per vendor instructions, as CISA's required action specifies. Where immediate patching is not possible, disable or restrict the Java browser plug-in and limit Java execution to trusted sites, since the flaw was historically exploited via drive-by exploit kits. Given the KEV listing and 98.5% EPSS score, prioritize patching internet-exposed and ransomware-relevant systems. | — | 99% | KEV ransomware |
| massOrder of hundreds of millions of installations/endpoints (well above 1M); precise current count unknown from this data |
Full article519 words · extracted from blog.talosintelligence.com · click to collapse
Tuesday, August 28, 2012 15:52
A new Java 0-day is running rampant around the internet this week. With a code paste Sunday night and a Metasploit module coming in early yesterday morning, along with myriad research and blog posts, this Java vuln is sure to be the topic of the week. Based on information in the pastie link and the usage of the Gondzz and Gondvv class files in the alienvault blog post, plus analysis we've done on the samples we've seen in the wild, we've deduced that the exploit runs as follows:
-Use the Statement() method to set up a new SecurityManager.
-Create an object with the following attributes:
a. Permissions object with AllPermissions() set.
b. A ProtectionDomain for the url, using local file "file:///"
c. Set up an AccessControlContext for that ProtectionDomain
-Call to the user defined function SetField with string "acc", passing along localStatement to complete the object.
-Inside that function we set an Expression with getField and use the variables passed in. Additionally we make a call to another user defined function, GetClass.
-In GetClass we finish setting up the object with a last Expression passed in with string forName (for acc, an AccessControlContext field) in the class sun.awt.SunToolkit. What this does is replaces the default value for the AccessControlContext object with the one for acc.
-Once the function has returned we run .execute() on the Expression objects.
-At the top level we execute the now fully populated Statement and presumably have full local execution access.
In each case of Statement or Expression, there is a call to var.execute() which takes the statement that has been created as a string and executes it as code. There are two specific access violations that occur during the execution of the code:
-Accessing the "acc" field using Class.forName.
-Using getField on sun.awt.SunToolit, a restricted package.
By using Statement and Expression methods to make these calls, they bypass access violation checks. Once the code has created a file with admin rights on the system, it can call calc.exe like in the POC or download a trojan like the exploit in the wild does.
The scariest part about all of this is that the next scheduled Oracle patch release is October 16. As Oracle has a policy of not issuing out-of-band updates, this means nearly two months of time where attackers can exploit this without root mitigation by the vendor. In the interim, security researcher Michael Schierl has released an unofficial patch, which is for now only available by request.
In the interim, we've released SIDs 24020 to 24028 and 24036 to 24038 to cover this in Snort, and JAVA.Exploit.Agent JAVA.Exploit.Agent-1JAVA.Exploit.Agent-2 WIN.Trojan.Agent-131 on the ClamAV side. We'd urge you to add these to your setup as soon as possible (especially since the authors of the Blackhole exploit kit are incorporating this vulnerability already), and to consider disabling Java in whatever browsers you can.
[Ed.: Oracle released a patch to address this issue on August 30. While done without much explanation or fanfare, well-done to the security folks at Oracle for getting on top of this issue so quickly.]
Text extracted automatically; images, tables and formatting may be missing. Original: https://blog.talosintelligence.com/cve-2012-4681-bypassing-built-in-java/