Home page logo

webappsec logo WebApp Sec mailing list archives

Gray Box Testing
From: Robert.L.Grill () wellsfargo com
Date: Wed, 12 May 2004 16:36:14 -0700

Can anyone share some security steps associated with Gray Box testing.

My definition of gray box testing would be the practice of reviewing Web
Server, App Servers (Jrun, Webshphere) for security settings or housekeeping
issues, that my make a security breach such as "least privilege" exploitable
from the Internet.



-----Original Message-----
From: Don Tuer [mailto:don.tuer () cgi com] 
Sent: Wednesday, May 12, 2004 2:49 PM
To: 'Chitresh Sen'; webappsec () securityfocus com
Subject: RE: Code Cracking in Java

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

-----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


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

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

 If (pwdTextField.length() <= 6 )



       Error - Password Length should be greater then 6 Characters




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




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 )



           Error - Password Length should be greater then 6 Characters




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

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!


Chitresh Sen

Email: chitesh_sen () yahoo com


  By Date           By Thread  

Current thread:
  • Gray Box Testing Robert . L . Grill (May 12)
[ Nmap | Sec Tools | Mailing Lists | Site News | About/Contact | Advertising | Privacy ]