Last year I posted on java bug-track some security issues about java security engine. Today I’ve found some free time and I’ve seen if some of these security issues have been corrected .
Well I’ve founded again some problems on java byte code caused from bad flags checking. The main problem concerns the poor connection between compiler and linker on java core verifier. Let me try a really easy example. Write A.java and B.java classes in the following manner.
public class A {public int value = 200;}public B{public static void main(String[] s){System.out.println(new A().value);}}
Well, try to compile A and B (javac *.java) and try to run B ( java B). Nothing strange yet. Right now all these stuff work fine but if you try to modify the public field (public int value=200)in private one (private int value=200) compiling only A.java (javac A.java) you’ll observe that java B behavior will not change ! What happened ? The linker has not been upgraded. Yep, but how can we apply this “linker miss upgraded” to normal life ?
Every commercial software has a protection, often the protection is a serial number or a license code. The software has to control about the correctness of inserted number and to do that it often uses a private function “serialNumber(String serial)”. If we don’t know any reverse engineering technique we should change the “serialNumber” private function in a public one afterward forging a brute force code able to exploit the previous function. Let me try with an different but easy example in order to understand the Java Code Violence technique.
This class has a private function named sum. We assume to have only .class code and not the sources. With java decompiler (javap -c -private ) we can understand the name and how many private variable/method the .class got.
Our attack will focused on private static int sum(). The main goal is to change this function from private to public, in order to do that we can use a simple java hash interpreter as DataWorkShop. Open The .class file with JavaInterpreter and search for private static int sum(). The right method is the number 3, it’s easy to understand from previous javap screen, change the private value from “YES” to “NO” and save the poisoned code.
Well, now we should forge two specific java classes, the first must named as the attacked class and it must have a fake public method called as the attacked class’ private method. The second class is the true attacker ‘s class able to use the private method, in these images it has been called Violence.java.
Now compile Violence.java and then remove the fake class named as the attacked class and rename the attacked class with its original name and run the Violence.class !! You have just bypassed the Java Security Engine. With the same principle you can modify private fields, private classes and of course private methods building self made classes that use private field of commercial classes. One of the most useful scenario is to build own brute forcer on a private “serial check” function. The problem is in the verifier engine. The Java verifier has the certifier task, it should control every piece of code before charge it in the right memory location. Also the java manager engine should control that run-time code does not damage JVM and/or machine memory but it seems not working so well. I hope that this easy kind of attack works only in my not-always-upgraded and old machines.
