Posts tagged Java SE 6
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.
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.
As requested by @suffert, here under an interactive timeline of all Oracle Java exploits, 0days and bulletins since 2012.
(Yet) Another Java exploit spreading flip.it/pFw1r < I would like to see a Java 0day timeline..
— Sandro Süffert (@suffert) 2 mars 2013
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.
- VirusTotal analysis of dropped McRAT.
- Malwr analysis of dropped McRAT.
- Anubis analysis of dropped McRAT.
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 188.8.131.52 C&C server. In the Bit9 security incident case, Trojan.Naid was also present and also connecting to 184.108.40.206 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.
Samples are appearing on VirusTotal like “svchost.jar” (a721ca9b2ea1c362bd704b57d4d5a280) with an actual detection ratio of 17/46.
Through a collaboration with (Jindrich Kubec (@Jindroush), Director of Threat Intelligence at avast! / Eric Romang (@eromang), independent security researcher), we can confirm that the watering hole campaigns are still ongoing, targeting multiple web high value web sites, including as example a major Hong Kong political party. We can also confirm that a second major Hong Kong political party is victim of this watering hole campaign.
This website is actually using the new version of the original Internet Explorer (CVE-2012-4792) vulnerability attack, patched in MS13-008, but right now it’s also using the latest Java (CVE-2013-0422) vulnerability, patched in Oracle Java 7 Update 11.
We will provide you further details on the affected web sites after their cleaning.
This website is a legitimate compromised website used for hosting the exploit files, hosted in South Korea.
This include file uses the well-known “deployJava” function, aka “deployJava.js“, and creates a cookie “Somethingeeee” with one day expiration date. This cookie is quite strange and it’s also possible to find it in years old exploits, which suggests this is only a part of greater, long-going operation.
If Internet Explorer 8 is used , an iframe is load from”hxxp://www.[REDACTED].org/board/data/m/mt.html” file. Otherwise and if Oracle Java is detected, an iframe will load “hxxp://www.[REDACTED].org/board/data/m/javamt.html“.
Analysis of “mt.html“
https://www.virustotal.com/file/58588ce6d0a1e042450946b03fa4cd92ac1b4246cb6879a7f50a0aab2a84086a/analysis/ (avast detects this code as JS:Bogidow-A [Expl] through Script Shield component).
Comparing to the original CFR and Capstone Turbine versions, this code is not targeting certain browser supported language, but the code is based on the version used on CFR with “boy” and “girl” patterns.
The executable file can be extracted from the string by cutting of first 13 characters, converting hex chars to binary and xoring the whole binary blob with 0xBF. Resulting file with SHA256 CE6C5D2DCF5E9BDECBF15E95943F4FFA845F8F07ED2D10FD6E544F30A9353AD2 is RAT which is communicating with a domain hosted in Hong Kong by New World Telecom.
Analysis of “javamt.html“
“javamt.html” (b32bf36160c7a3cc5bc765672f7d6f2c) is checking if Oracle Java 7 is present, if yes latest Java vulnerability, CVE-2013-0422, will be executed through “AppletHigh.jar” (521eab796271254793280746dbfd9951). If Oracle Java 6 is present, “AppletLow.jar” (2062203f0ecdaf60df34b5bdfd8eacdc) will exploit CVE-2011-3544. Both these applets contain the very same binary mentioned above (unencrypted).
As you see, the watering hole campaign still continues, but has evolved in form but also by using the latest Oracle Java vulnerability. There is just one advise: patch, patch, patch… and see you soon.