SQL injection on Metasploitable

So I was playing around with the TikiWiki web application on the Metasploitable VM tonight, and I decided that I wanted to try and see if this thing was vulnerable to SQL injection. I did a quick google search and it told me that indeed there were reported SQL injection points for this particular version, but I wanted to try and see if I could find one on my own. So began my manual assault on all the fields and parameters I could see. Finally I found a parameter that is passed on multiple pages but I first got the application to throw an error on the tiki-listpages.php page using the sort_mode= parameter.

Interestingly enough, when I tried to use a tick (') in the sort_mode= parameter, it would just give me an error stating that was an invalid value for that field. I did find that most of this application does sanitize the input from the user, but for some reason this particular parameter did not like integers being put into it and the result is a massive error page yielding all kinds of good info. Here was what I used:

http://192.168.2.109/tikiwiki/tiki-listpages.php?find='&search=find&sort_mode=1

And here is the beautiful error page this throws:

As you can see, this gives us all kinds of good info. One of the big give aways is that fact that this is a mysql database. But if we continue to scroll down, we get even more really interesting info. A quick search for 'password' reveals this:

Wow. It looks like this bad query dumped a configuration file for the entire database including the username and password for the database! And to test it out, I tried logging in through the mysql client on backtrack and sure enough, I was able to view the whole database.

This is a very old version of tikiwiki, 1.9 something I think, and they have long since patched this vulnerability. It is amazing what one small error can produce from the database side of a web application.

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