Posts tagged Java

CVE-2013-2423 – Java 7u17 Applet Reflection Type Confusion RCE Metasploit Demo

Timeline :

Vulnerability discovered and reported to vendor by Jeroen Frijters
Vulnerability corrected in April CPU the 2013-04-16
Vulnerability publicly disclosed by Jeroen Frijters the 2013-04-17
Metasploit PoC provided the 2013-04-20

PoC provided by :

Jeroen Frijters
juan vazquez

Reference(s) :

Oracle Java April 2013 CPU

Affected version(s) :

JDK and JRE 7 Update 17 and earlier

Tested on Windows XP Pro SP3 with :

JDK and JRE 7 Update 17

Description :

This module abuses Java Reflection to generate a Type Confusion, due to a weak access control when setting final fields on static classes, and run code outside of the Java Sandbox. The vulnerability affects Java version 7u17 and earlier. This exploit doesn’t bypass click-to-play, so the user must accept the java warning in order to run the malicious applet.

Commands :

use exploit/multi/browser/java_jre17_reflection_types
set TARGET 1
set PAYLOAD windows/meterpreter/reverse_tcp


Oracle Java Critical Patch Update April 2013 Review

Oracle has provide his Java Critical Patch Update (CPU) for April 2013 who has been released on Tuesday, April 16. On the 42 security vulnerabilities fixed in this CPU, 39 of them may be remotely exploitable. The highest CVSS Base Score for vulnerabilities in this CPU is 10.0.

This update fix the vulnerabilities exploited by James Forshaw (tyranid), Joshua J. Drake and VUPEN Security during Pwn20wn 2013. But this update is also fixing vulnerabilities reported by Adam Gowdiak of Security Explorations and other security researchers.

As you may know Oracle is using CVSS 2.0 (Common Vulnerability Scoring System) in order to score the reported vulnerabilities. But as you also may know security researchers disagree with the usage of CVSS by Oracle. Oracle play with CVSS score by creating a “Partial+” impact rating how don’t exist in CVSS 2.0, and by interpreting the “Complete” rating in a different way than defined in CVSS 2.0.

Affected products are:

  • JDK and JRE 7 Update 17 and earlier
  • JDK and JRE 6 Update 43 and earlier
  • JDK and JRE 5.0 Update 41 and earlier
  • JavaFX 2.2.7 and earlier

Proposed updates are:

  • JDK and JRE 7 Update 21
  • JDK and JRE 6 Update 45
  • JDK and JRE 5.0 Update 43
  • JavaFX 2.2.21

19 (45,24%) of the vulnerabilities have a CVSS base score of 10.0, 28 (66,67%) of the vulnerabilities have a high CVSS base score (CVSS => 7.0), 13 (30,95%) of the vulnerabilities have a medium CVSS base score (CVSS >= 4.0 < 7.0) and 1 (2,38%) of the vulnerabilities has a low CVSS base score (CVSS < 4.0). Also 25 (59,52%) of the vulnerabilities affects Java SE 6 and 42 (100%) of the vulnerabilities are affecting Java SE 7.

Also some modifications have been done in the Security Levels provided by Oracle. Previously five levels were existing (Very-High, High, Medium, Low and Custom), in the new provided version only three levels are still existing (Very-High, High and Medium).


But, there is always a but with Oracle, they don’t seem to have enable, by default, the check for revocation using Certificate Revocation Lists (CRLs) despite that some bad guys are using valid stollen and revoked certificates to sign malware’s.


So we advise you to update asap, enable the CRL check, if you still have Oracle Java plug-in installed !

Gong Da Exploit Kit Add Java CVE-2013-1493 & IE CVE-2012-4792 & IE CVE-2012-4969 Support

Like other Exploit Kits, Gong Da has add support for Oracle Java CVE-2013-1493 vulnerability, fixed in Oracle Java 6 Update 17, has also add support for Microsoft Internet Explorer CVE-2012-4969 and CVE-2012-4792 vulnerabilities, fixed in an emergency patch in September 2012 and January 2013.

Here is the new code for CVE-2013-1493.

Capture d’écran 2013-04-14 à 23.39.38

And here the new code for CVE-2012-4792 (aka 4792.html) and CVE-2012-4969 (aka payload.html).

Capture d’écran 2013-04-14 à 23.39.48

Also a new variant of CVE-2012-1889 (xml.html) has been introduced, reducing the detection rate by anti-viruses.

Capture d’écran 2013-04-14 à 23.40.15

As always this new version of Gong Da Exploit Kit has been discovered on a Korean web site.

Gong Da Pack has involve to the following diagram.

Gong Da EK 1.5

Here under some information s regarding the different files:

Normally Gong Da was used against gamers, but this time the loaded malware seem to be different (analysis on ThreatExpert)

When a Signed Java JAR file is not Proof of Trust

Today, Malware Domain List, reported strange behaviours regarding a Java app executed with the latest version of Java 6.

As you can observe, VirusTotal didn’t find something wrong (0/46) regarding the Java app, but after few hours, some analysis and some discussions on Twitter, it appear that this file is a malicious file (3/46) dropping malwares and that Oracle still need to enhance the security level of Java.

This “innocent” Java app was found on “hxxp://“, a german online dictionary infected by g01pack Exploit Kit.

Call to the Java app was done through:

ClearWeb Security Update" code="app.applet.class" archive="">

As you can see, the Java app try to make the end-user believe that this is a “ClearWeb Security Update” with a URL also trying to imitate a pseudo like Oracle Java JRE8 (lol) update.


Also you can see that the publisher is “CLEARESULT CONSULTING INC.“, a real firm located in Texas USA. It also seem that this applet is a “trusted” signed applet. If the applet were signed by an “non-trusted” or “self-signed” certificate the dialog box would have been like the following one.


If you click on the “More Information” link of the dialog box, you will have another messages confirming you that you can trust this Java applet (The digital signature was generated with a trusted certificate).


And by clicking on “Certificate Details“, you will have associated information’s.


You maybe remember that Oracle has introduce “Security Levels” since Java SE 7 Update 10 in December 2012. Five levels of security are supported, plus a custom security level settings. This feature can be set in the Java Control Panel or (on Microsoft Windows platform only) using a command-line install argument.

The five levels are:

  • Custom: You can customize all the security settings based on you’re needs.
  • Low: Most unsigned Java apps in the browser will run without prompting unless they request access to a specific old version or to protected resources on the system.
  • Medium: Unsigned Java apps in the browser will run without prompting only if the Java version is considered secure. You will be prompted if an unsigned app requests to run on an old version of Java.
  • High: Default Security Level. You will be prompted before any unsigned Java app runs in the browser.
  • Very High: You will be prompted before any Java app runs in the browser. If your version of Java is insecure, unsigned apps will not run.

As you can see only unsigned Java app are considered as non-secure, and signed Java app are blocked only with the “Very High” security level. So with the default security level, aka “High” a signed Java app is executed additional advises.

If you read Oracle documentation “Understanding Signing and Verification“, you will find nice definitions, like:

You digitally sign a file for the same reason you might sign a paper document with pen and ink — to let readers know that you wrote the document, or at least that the document has your approval. When you sign a letter, for example, everyone who recognizes your signature can confirm that you wrote the letter. Similarly when you digitally sign a file, anyone who “recognizes” your digital signature knows that the file came from you. The process of “recognizing” electronic signatures is called verification.


 The ability to sign and verify files is an important part of the Java platform’s security architecture. Security is controlled by the security policy that’s in force at runtime. You can configure the policy to grant security privileges to applets and to applications. For example, you could grant permission to an applet to perform normally forbidden operations such as reading and writing local files or running local executable programs. If you have downloaded some code that’s signed by a trusted entity, you can use that fact as a criterion in deciding which security permissions to assign to the code.

So you have understood, if a Java app is signed with your name, it is the proof that you have sign this Java app, and this Java app will run on your system with special privileges… But, but, if somebody has steal your private key that allow you to sign you’re Java app, can the users still trust the Java app ?

The Java app discovered by Malware Domain List was signed with a stollen private key… Worst, the certificate associated to the applet was revoked by GoDaddy the Dec 7 17:46:22 2012 GMT (thanks to @Jindroush). But signing and verifying files is so an important part of the Java platform’s security architecture that Jarsigner validates the file despite the certificate is revoked since a while…

The cause to this nightmare are very simple and I agree with Jindroush #WTF #Java !

By default, certificate revocation list check is set to “OFF” and signed Java app are authorized to have privileged accesses…

So conclusion, signed Java app are not a proof of trust if you don’t check revocation lists ….

Go to Top