Post reply

Name:
Email:
Subject:
Message icon:

Verification:
Type the letters shown in the picture
Listen to the letters / Request another image

Type the letters shown in the picture:
Second Anti-Bot trap, type or simply copy-paste below (only the red letters):www.scforum.info:

shortcuts: hit alt+s to submit/post or alt+p to preview


Topic Summary

Posted by: bartblaze
« on: 03. April 2013., 11:14:30 »

Good article. Most Java exploits are encounter are for j7, but I still encounter Adobe exploits from 2010.... Makes you wonder if we should redefine how Java & Adobe are used in businesses and systems overall... ;)
Posted by: Pez
« on: 02. April 2013., 09:31:20 »

Multiple Java Exploits Hide in a Jar (File)

Exploits of the Java Runtime Environment (JRE) have been extensively used in drive-by-download toolkits such as Blackhole and Red Kit. New vulnerabilities discovered in 2013, such as CVE-2013-1493 and CVE-2013-0422, are popular, and we still see lots of older exploits such as CVE-2012-1723, CVE-2012-4681, and CVE-2012-0507.  These vulnerabilities are already fixed in the latest JRE. However, not all users have an updated JRE.

Attackers often create malicious .jar (Java class files archive) files to take advantage of the latest exploit. One problem for attackers, however, is that some vulnerabilities do not affect older versions of JRE. For example, CVE-2013-0422 exists only in Java 7, not in Java 6.

This inequality among versions could also happen with other applications, such as Adobe Reader. Typically malicious JavaScripts embedded in PDF-exploit files check the version of Acrobat installed, and exploit an appropriate vulnerability to install Trojans.

The same technique is also used in malicious jar files. The jar file in the following screen capture, for example, exploits multiple JRE vulnerabilities:



This next malicious applet class checks the version of JRE and attacks vulnerabilities as follows:

if version > Java6  Update 32 or  if version > Java7  Update 10, then

       exploit the newest vulnerability CVE-2013-1493.

else if Java 7 (version <= Java 7 Update 10) then

       exploit CVE-2013-0422

else (version < Java 6 Update 32) then

      exploit CVE-2012-1723

 
Note that CVE-2012-1723 occurs in Java 6 Update 32 or earlier and CVE-2013-0422 affects Java 7 Update 10 or earlier, but not in Java 6 or earlier. Here is another example of a malicious Java class:



The applet class first calls sectoff() to exploit CVE-2012-0461. If the target JRE is fixed against the vulnerability, bypassing applet sandbox security fails and an exception is thrown. The exception is caught in the “catch” statement and then calls invgo_rmethod to attack CVE-2012-0507. If that fails, then it calls invgotwo_rmethod to attack CVE-2012-1723. When one of the exploits works, it drops a fake-alert sample to the temp folder:



To protect your systems against these attacks, we strongly recommend that you update to the latest version of Java. Also because these exploits typically (but don’t always) drop executable files to the temp folder, you should restrict running executable files from that folder.

McAfee products detect these JRE exploits as Exploit-CVE(cve number) or Exploit-XXX!CVE-(cve number). For example, CVE-2012-1723 exploits are detected as Exploit-CVE2012-1723, Exploit-FDI!CVE-2012-1723, and Exploit-FDJ!CVE-2012-1723, to name a few.


Orginal article: Monday, April 1, 2013 at 3:45pm by Shinsuke Honjo
Enter your email address to receive daily email with 'SCforum.info - Samker's Computer Forum' newest content:

Terms of Use | Privacy Policy | Advertising