RE: Code Cracking in Java

["Don Tuer" <don.tuer () cgi com>]

Your work has exposed one of many important items in web security, never
trust user input! Validate must also be done on the server...

Thanks
Don 
-----Original Message-----
From: Chitresh Sen [mailto:chitresh_sen () yahoo com] 
Sent: Wednesday, May 12, 2004 2:35 AM
To: webappsec () securityfocus com
Subject: Code Cracking in Java





Code Cracking in Java



Scope 



This is not a pure technical paper but I would like to share one of my
discovery in Java Security which I had done during one of my assignments
and it was greatly appreciated by the client because my finding help
them to develop a strong business case to convince top management for
discarding the product. The following document provides some loopholes
in Java and how they can be rectified. It also provides a guideline to
the software designers while developing an application especially in
Java.



Who can read this paper? 



Software developers, designers, security professional, auditors,
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 firm but I am very much happy with my
profile, basically I am an ethical hacker currently working in Wipro and
previously in PwC.  



Let me tell you about my experience in Java. During my third year of
engineering I learnt Java. When I was about to join a fast track course
at Concourse for Java my senior told me that socket programming in Java
is hard to understand, that time I don't know anything about Java so its
OK for me. After the completion of course within one month I wrote a
chat software in Java consisting of Socket programming and
multithreading without reading any book. The teacher who taught me
asked, could you share your code with me? Later on I had written some
more applications for which I was rewarded. 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
Bhosle, Director of Try Catch Solutions, Pune 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 in 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 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 authorised 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. 



The IBA was vulnerable 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 its 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
again tried 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 I have achieved a lot and 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 understood the class file structure, its
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 serous. 



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 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 helps
us 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 kind of bipush 6 instruction, and its
equivalent opcode in hexadecimal format. The understanding of Java class
file format helps to search the hex value in a specific part of class
file. Now open a class file using a HEX Editor and search for the
opcode, which we had found above. Once we had found the hex value change
it and save the modified file.



The following snapshot reflects the above activities in technical form.



Following is an assembly language instructions 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. 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 0 character since there were no
server side validation checks were implemented hence 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
overcomed and similar process can be used to manipulate any checks
implemented at client side. Now I have the key with me only thing I have
to investigate the proper class files and understand its logic and
manipulate it. Later on I had overcomed the special character checks
which makes application vulnerable for SQL injection, further
exploitation of which leads to the compromisation of database. 



I hope you have understood that what I had done more with the
application.



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.



The solution for byte code manipulation can be taken care by
implementing hashing for a package and before starting an application
the hash should be calculated and compared with the server side
precalculated hash, if both of them match then only allow further
execution. Other way to solve the problem is to implement server side
checks no doubt it will affect the performance of server.



Suggestions and Comments are Welcome!



Thanks!



Chitresh Sen

Email: chitesh_sen () yahoo com