One of the recent threat in java is founded , with which attacker can spread malware and various other infected files which effect users system without users having to open any files. The hackers called this new exploit as a
“New Year’s gift”. The
exploit code looks like java code with no trace of any exotic bytecode.
After searching different website on this vulnerability,,,,,,i have obtained following output which is not covered in single website.
The exploit takes advantage of two security flaws:
- The first flaw
stems from the fact that it is possible to obtain references to
restricted classes.
- The second one allows it to invoke class constructors by using the reflection API included in Java 1.7.
Following is the exploit code..
private void SetField(Class paramClass, String paramString, Object paramObject1, Object paramObject2)
throws Throwable
{
Object arrayOfObject[] = new Object[2];
arrayOfObject[0] = paramClass;
arrayOfObject[1] = paramString;
Expression localExpression = new Expression(GetClass("sun.awt.SunToolkit"), "getField", arrayOfObject);
localExpression.execute();
((Field)localExpression.getValue()).set(paramObject1, paramObject2);
}
The sun.awt.SunToolkit class gives public (public) access to a method called getField()
that provides access to the private attributes of other classes.
Technically speaking, untrusted code such as the exploit that is being
executed in the browser shouldn't be able to access this method at all.
But Java 7 introduced a new method to the Expression class, .execute(),
which allowed expressions created at runtime to be executed. Bugs in
the implementation of the new method allows the code to gain access to
the getField() method.
The exploit first creates a Statement object that would call the System.setSecurityManager(null)
object and effectively disable the sandbox. However, if the exploit
called that method directly it would be rejected because it was
untrusted.
So the code first creates a custom AccessControlContext object that represents
a class which was started from the local hard disk and has, therefore, a complete set of rights.
Then the code uses its privilege breaking setField to
swap this custom set of rights with the "acc" attribute of the
setSecurityManager statement. This attribute would normally state that
the object is part of a class that belongs to an applet such as http://attack.evil-page.tld/exploit.jar,
and that it should therefore run in the sandbox with no system
privileges. Once swapped in, the Statement object now claims to have
come from the local hard disk and is trusted code. It can then be
executed without complaint and disables the SecurityManager completely.
After that, the exploit can do as it pleases on a system. To
demonstrate, the analysed exploit uses the same method that a legitimate
Java application would use to start the calc.exe Windows calculator. In
theory, an attacker could have built a statement that erases the hard
disk or downloads and executes a native payload.
