Code Cracking

{LANG_NAVORIGIN} Exploits
Chitresh Sen 11/03/2004

Scope

The paper is technical related to byte code manipulation of Java using Hex Editor and it requires knowledge of Java programming and Byte Code format. I had done a code breaking in Java and bypassed the whole client side security of an Internet Banking Application, which may further result into a disaster. On the basis of that discovery I have written a following document related to the loopholes in Java and poor design of application architecture. It also provides a guideline to the software designers while developing web-based application.

Who can read this

This document can be helpful for software developers, software designers, security professionals, IT auditors and IT managers responsible for evaluating products.

About Me

Hi! I love programming in Java but unfortunately I didn’t get a chance to work in software development but I am very much happy with my profile, basically I am an Ethical Hacker currently working in Wipro and previously in PwC. I learned Java during early 2000 and my interest was in Network programming. During my PG I was awarded for a project at national level, the project title was “Managing Network using Mobile Phone”. I had designed and developed the application in J2ME (Java 2 Micro Edition), the application allows system administrator to manage his network using mobile phone to some extent. Mr. Ashutosh Bhonsle, Director of TryCatch Solutions Pvt. Ltd. gave the idea for the above project.

After my PG I was keen to join a software development firm but unfortunately or fortunately I had been selected in PwC in IT security and there were no software development. Initially I was frustrated because my core interest was programming and here I will never get a chance to work in Java. After some time I got a chance to work on cryptanalysis project in which I had written compromising code for checking encryption strength. Also I had done some research work on Java Security and consulted security features of Java, it was a great experience and this project gave me a new vision to work in Java security other then development. Now I start looking it in different manner that is how to exploit it loopholes. But for long time I didn’t get much chance to work in Java Security.

Code Cracking

After a year I got a chance to work in Java Security meanwhile I was doing assignments on Penetration Testing (PT), Vulnerability Assessment (VA), formulation of Information System Security Policy and some few small assignments. The Assignment, which we got, was basically a PT/VA but the client also wants a PT for their Internet Banking Application (IBA). Note: For security reasons I will not mention client name, application vendor and detail about the application architecture. Also a person having basic knowledge of Java can best understand the following text.

The client IBA was developed in Java and it is downloadable from Internet. The real code cracking starts from here. Client has provided us some test user ids for testing the application. Our objective was to find the loopholes in IBA and try to explore that how an authorized user can misuse the application.

As we commonly know that the basic loophole in Java is that it can be reengineered from class file to source code, the class file consist of byte codes which is interpreted by Java Virtual Machine (JVM) to make Java platform independent. Hence class files are vulnerable to attack due to their platform independent nature and open architecture.

The IBA was vulnerable (i.e. not obfuscated) and I can convert any class file of application into source code and view its logic, but the application consists of almost 1400-1500 class files and it is required to understand the logical flow of application and find out how it behaves. I find out the first class file, which start the application and decompiled it and tried to understand its flow. Frankly speaking it’s very hard to understand others code and it requires lot of patience and dedication. Anyway while browsing through a bunch of class files I found some interesting class files where input validation checks for password min/max length, special characters etc were implemented. Only thing I have to change the reengineered class file as per my requirement and recompiled and repackaged it so that the application works as per my requirement. I did the same but the application didn’t start normally, I tried again but it didn’t work. Later on I found that they had implemented Secure Class Loader, which doesn’t allow repackaging a modified class file.

Now what to do, initially I was thinking that I can screw the application very easily. Later on I got an idea from my previous experience, during one of my assignment I had changed the FTP banner by modifying its .dll file using HEX Editor⁵. The idea was vague to change the class file directly into HEX Editor but what to change in class file because I don’t know anything about class file. Anyway I accept the challenge because I don’t have any option. First of all to change class file I have to understand the class file structure¹, it’s very much logical if you want to play with low-level language you have to understand its format, somehow I manage to understand it. Also I had gone through the JVM specification². It was interesting and I was enjoying it but I had a time constraint so I have to be serious.

After having an understanding of Java class format, the next challenge is to find out which byte to change. The byte codes are nothing but the assembly language instructions, which are interpreted by JVM at run time. In order to find the exact byte it is required to know the opcodes³ of JVM instructions. Then I found a list of JVM Instructions opcodes with their mnemonics. Now the next challenge was to search for exact byte in the class file for manipulation.

Let me explain with an example. Let’s say a programmer had written a following if condition for checking minimum length of password in one of the source file.


If (pwdTextField.length() <= 6 ) 

{ 

  Then 

           Error – Password Length should be greater then 6 Characters

  Else  

Proceed 

}

Our aim is to change 6 to our requirement so that we can bypass the minimum password length check. For this we required to see the byte code in readable assembly language form. Byte Code Engineering Library (BCEL)⁴ helps to see the byte code into the assembly language instructions i.e. functions in stack form. I used this library to see the skeleton of class file in assembly language instructions and I can easily see the stack of functions and their calls. I found the instruction for the above if statement which is a bipush 6 instruction, and its equivalent opcode in hexadecimal format. The understanding of Java class file format helped me to search the hex value in a specific part of class file. Now I opened the class file using a HEX Editor and searched for the above opcode and changed it and save the modified file. The following snapshot reflects the above activities in technical form.

Following is an assembly language instruction of class file generated using BCEL.


……….. 

…….. 

… 

protected boolean checkPwd(String arg1) 

Code(max_stack = 2, max_locals = 2, code_length = 57) 

0:    aload_1 

1:    invokevirtual  java.lang.String.length ()I (113) 

4:    bipush    6 

6:    if_icmplt    #18 

9:    aload_1

…………… 

………… 

……..

The opcode of bipush mnemonic is 0x10 and 6 is represented as 0x06 in hex format. Now open the class file using Hex editor and search for 0x1006 in a specific part of class file and change it to 0x1000 (i.e. bipush 0). Now the if condition will change to;


If (pwdTextField.length() <= 0 ) 

{ 

  Then 

           Error – Password Length should be greater then 6 Characters 

  Else  

Proceed 

}

After modification I started the application and it was running fine. I changed my test user ids password as 2 characters and it was accepted by the server because there were no server side validation checks implemented, after the client side security check was manipulated the application allows me to keep password of any length. This way the minimum password length check is bypassed and similar process can be used to manipulate any other security checks implemented at client side. Now I have the key, only thing I have to investigate the proper class file and understand its logic and manipulate it. Later on I had bypassed the special character checks, which makes application vulnerable for SQL injection, further exploitation of which leads to the compromisation of database.

Solution

In the above section I mentioned the vulnerabilities related to Java but these vulnerabilities can be taken care. Obfuscation can be used to scramble class files so that it becomes hard to understand the decompiled source code; there are tools⁶ available for obfuscation. But obfuscation is not a perfect solution to the above problem; these tools can only make the process of reengineering more difficult.

The only solution to the above problem is to implement server side checks, because the main problem is that the application design was faulty since it relied on the client side to perform security critical checks, which is very bad in any client/server environment.

Conclusion

Whatever I have described is not a particular problem of the Java language. There are people who can convert compiled code back to C/C++ as fast as they can write. There are also plenty of tools for debugging/patching code written in just about any language. My work has just exposed one of many important items in web security that never trusts client side input validation and it should be done only on server side. Additionally, input check on server side might affect performance but security have higher priority and performance can be easily taken care by upgrading resources and better design.

Chitresh Sen
CISM, CEH

The author has expertise in Penetration Testing (PT), Vulnerability Assessment (VA), formulation of Information System Security Policy

Please send your feedback to chitresh.sen@wipro.com

References

Class File Format (http://java.sun.com/d ocs/books/vmspec/2nd-edition/html/ClassFile.doc.html)
JVM Specifications (http://java.sun.com/d ocs/books/vmspec/2nd-edition/html/VMSpecTOC.doc.html)
Opcode Mnemonics (http://java.sun.com/d ocs/books/vmspec/2nd-edition/html/Mnemonics.doc.html)
BCEL (http://jakarta.apache.org/bcel/index.html)
Hex Editor, I personally prefer Hex workshop (http://www.bpsoft.com/)
Java Obfuscators (http://directory.google.com/Top/Computers/Programming/Languages/Java/Development_Tools/Obfuscators )

E-Mail Link

Your IP address will be sent with this e-mail

From e-mail to e-mail