Newsfeed
Nachrichtenbote
Last week Kahu Security blogged about Escalating Java Attacks. Kahu's post dissects two Java exploits.
The first exploit targets CVE-2012-0507, the latest Java vulnerability that's been seen being exploited in the wild. This vulnerability was patched (for Windows) by Oracle in February 2012. I found the second exploit to be more interesting. It clearly appeared to be related to some Java CORBA vulnerability, possibly CVE-2012-0506, a Java vulnerability not yet known to be exploited in the wild. Last Friday I decided to take a closer look at this mysterious exploit.
First, I decompiled and analyzed the applet. However, I did not recognize anything in particular as there have not been any exploits or Proof-Of-Concepts made publicly available for CVE-2012-0506. So I decided to test the exploit with different versions of Java Runtime Environment to narrow down the list of potential vulnerabilities. I started by trying the latest version (JRE6 update 31) and, as expected; the exploit did not work because it was already patched. Then I tested with an older Java version (JRE6u25) just to make sure that the exploit would work in my test environment, and it did. I was a bit surprised when I tested JRE update 30 and the exploit did not work. This was a clear indication that the sample was not exploiting CVE-2012-0506 (as I was expecting) because JRE6u30 still had this vulnerability.
I continued testing different JREs and determined that JRE6 update 29 is the version that patches this mysterious vulnerability. The Update Release Notes link to an Oracle Java SE Critical Patch Update Advisory – October 2011 that lists all the vulnerabilities patched in the update. Based on my initial analysis it was clear that the sample exploits some deserialization problem and the only vulnerability in the Risk Matrix related to deserialization is CVE-2011-3521. The ZDI advisory reveals two interesting facts. Firstly, the vulnerability was discovered by fellow Finn Sami Koivu who recently joined Oracle. Secondly, the problem is in IIOP deserialization which is exactly the piece of CORBA code that the exploit calls. This confirms that the mysterious vulnerability is… CVE-2011-3521.
On Saturday, Contagiodump wrote about the same sample. Michael Schierl e-mailed Contagiodump and also commented on the original Kahu Security blog post that the vulnerability was most likely not CVE-2012-0506, but rather, CVE-2011-3521.
I can confirm that Michael is right. His article has more details about the vulnerability.
It is strongly recommended to update your Java client to the latest version, disable it when not needed, or better yet, remove it completely if you don't really need it.
Java versions can be determined from: java.com/en/download/installed.jsp.
The SHA1 hash of the exploit that I analyzed is: 83a04bd183ecb9e2598da9b67417cd57bc9f14fa
F-Secure Anti-Virus detects the exploit as Exploit:Java/CVE-2011-3521.A.
—————
Regards,
Timo
On 03/04/12 At 10:27 AM
Weiterlesen...
The first exploit targets CVE-2012-0507, the latest Java vulnerability that's been seen being exploited in the wild. This vulnerability was patched (for Windows) by Oracle in February 2012. I found the second exploit to be more interesting. It clearly appeared to be related to some Java CORBA vulnerability, possibly CVE-2012-0506, a Java vulnerability not yet known to be exploited in the wild. Last Friday I decided to take a closer look at this mysterious exploit.
First, I decompiled and analyzed the applet. However, I did not recognize anything in particular as there have not been any exploits or Proof-Of-Concepts made publicly available for CVE-2012-0506. So I decided to test the exploit with different versions of Java Runtime Environment to narrow down the list of potential vulnerabilities. I started by trying the latest version (JRE6 update 31) and, as expected; the exploit did not work because it was already patched. Then I tested with an older Java version (JRE6u25) just to make sure that the exploit would work in my test environment, and it did. I was a bit surprised when I tested JRE update 30 and the exploit did not work. This was a clear indication that the sample was not exploiting CVE-2012-0506 (as I was expecting) because JRE6u30 still had this vulnerability.
I continued testing different JREs and determined that JRE6 update 29 is the version that patches this mysterious vulnerability. The Update Release Notes link to an Oracle Java SE Critical Patch Update Advisory – October 2011 that lists all the vulnerabilities patched in the update. Based on my initial analysis it was clear that the sample exploits some deserialization problem and the only vulnerability in the Risk Matrix related to deserialization is CVE-2011-3521. The ZDI advisory reveals two interesting facts. Firstly, the vulnerability was discovered by fellow Finn Sami Koivu who recently joined Oracle. Secondly, the problem is in IIOP deserialization which is exactly the piece of CORBA code that the exploit calls. This confirms that the mysterious vulnerability is… CVE-2011-3521.
On Saturday, Contagiodump wrote about the same sample. Michael Schierl e-mailed Contagiodump and also commented on the original Kahu Security blog post that the vulnerability was most likely not CVE-2012-0506, but rather, CVE-2011-3521.
I can confirm that Michael is right. His article has more details about the vulnerability.
It is strongly recommended to update your Java client to the latest version, disable it when not needed, or better yet, remove it completely if you don't really need it.
Java versions can be determined from: java.com/en/download/installed.jsp.
The SHA1 hash of the exploit that I analyzed is: 83a04bd183ecb9e2598da9b67417cd57bc9f14fa
F-Secure Anti-Virus detects the exploit as Exploit:Java/CVE-2011-3521.A.
—————
Regards,
Timo
On 03/04/12 At 10:27 AM
Weiterlesen...