MetaSploit 101: Finding and Exploiting a MySQL User Account

(view full size, opens in a new tab)

Welcome everyone to a great edition of MetaSploit 101 where today I will be talking about how you can use MetaSploit to identify a host who has an open instance of MySQL. We will then brute force the host looking for the credentials we can use to login, and lastly we'll close by examining the database and taking some credit card credentials. Before we get started though, I gotta share a disclaimer:

This will take advantage of Rapid7's MetaSploitable 2 virtual machine as our target in an isolated test environment. Metasploitable is an intentionally vulnerable Linux virtual machine. This VM can be used to conduct security training, test security tools, and practice common penetration testing techniques. This type of activity should NOT be attempted against a host or hosts which you do not own or have written permission to perform a security audit against. I cannot and will not be held responsible for unauthorized or unlawful use of the information provided in this article. It is the sole responsibility of the user to ensure that they have the express permission of the owner of the target host to perform this or any other security audit, penetration test, or similar activity.

So with that out of the way, let's get started! For the purpose of this, we'll assume we already have our target host identified.

So first things first, let's boot up MetaSploit in Kali Linux. We can do this by first starting the necessary services and then by opening the MetaSploit-Framework Console:

service postgresql start  
service metasploit start  
msfconsole  

(view full size, opens in a new tab)

Now that we have MetaSploit started, let's identify what possible vectors we may have at our disposal. To do this, we'll load the TCP port scanner. And set

use auxiliary/scanner/portscan/tcp  

Now we need to set a few variables so that MetaSploit does what we want. Specifically, we're going to set the host we would like to run the port scan against and we will raise the number of concurrent threads. To view what variables can be set, simply run show options.

To set our victim machine, we'll set the RHOSTS variable and we'll set the number of threads with the THREADS. Once those are set, we'll begin the scan with run:

set RHOSTS 172.16.173.128  
set THREADS 256  
run  

Some things to remember when setting THREADS on your personal machine though are:

• Keep the THREADS value under 16 on native Win32 systems
• Keep THREADS under 200 when running MSF under Cygwin
• On Unix-like operating systems, THREADS can be set to 256.

Once this finishes, we'll be presented with a list of open ports:

(view full size, opens in a new tab)

From experiece, we know that port 3306 is used for MySQL, but let's verify this by checking what that port is with the services command using the -c flag to limit our information to the name of the service, port number and protocol (note that there are no spaces between name, port and proto below):

services -p 3306 -c name,port,proto  

(view full size, opens in a new tab)

If we didn't know this though, we could also search for our service of interest like so:

services -s mysql  

(view full size, opens in a new tab)

Now that we know that we our target has mysql open, let's try to find the credentials to get in. To do this, we'll switch over to the mysql_login scanner:

use auxiliary/scanner/mysql/mysql_login  

To use this module, we need to set a few things similar to what we did with the tcp scanner. You can view the available variables with show options. We set the following options:

• BLANK_PASSWORDS which tells MetaSploit to try blank passwords for our user list
• USERPASS_FILE, which is a file containing username and password combinations on a single line
• RHOSTS to `172.16.173.128
• THREADS to speed up execution
• STOP_ON_SUCCESS which as the name implies, stops our scan once we get a hit.

We'll set the following values:

set BLANK_PASSWORDS true
set USERPASS_FILE /usr/share/wordlists/metasploit/root_userpass.txt
set RHOSTS 172.16.173.128
set THREADS 256
set STOP_ON_SUCCESS true

Once that completes, we can run the creds command to see what we found:

(view full size, opens in a new tab)

OK, so we found that the remote MySQL instance has a root user with what would appear to be a blank password. Because MySQL stores it's users in it's database, now that we have the root user, we can find out who else exists in that service without the inefficiency of this type of brute force attack. We'll do this using the MySQL Enumerator module:

use auxiliary/admin/mysql/mysql_enum

As you would guess, we have to set a few options (note that this time we use the option RHOST not RHOSTS):

set RHOST 172.16.173.128
set USERNAME root

With those two items set (leaving the PASSWORD option blank since the credentials list didn't provide us with a password as it would if there was one set) we can start our enumeration scan.

run

(view full size, opens in a new tab)

We see we got a lot of information from this. We can do another check of our creds command to see what we got from this:

(view full size, opens in a new tab)

Great! We have the information we need to connect to the database. Let's exit MetaSploit and connect to the remote host's MySQL instance:

exit # to exit MetaSploit
mysql -u root -h 172.16.173.128

We're in! Now let's see what databases we have at our disposal:

show databases;

(view full size, opens in a new tab)

It's worth noting that our mysql_enum scanner was using the mysql database to collect the user and password information for us. We can work through these to see what each database contains using the following command (the example will use the owasp10 database):

show tables from owasp10;  

We quickly see some stuff of interest in this database:
(view full size, opens in a new tab)

Congratulations! You've just found credit card information on your victim machine! We saw here an example of how a malicious user could gain access to a MySQL database by taking advantage of weak credentials on the victim's machine.

Weak credentials and forgotten default database accounts are one of the most common security problems in large organizations where it can be difficult for the administrators to manage the large variety of systems and keep all accounts safe and secure.

Penetration testers should often (not always as your situation may vary) check if the remote target is using default or weak accounts for their systems, especially while assessing a database system. This is the easiest way to gain access and in complex and big environments it's always a possibility that this technique will be successful.

That's it for this post, in the future we'll go over covering your tracks so that system administrators or security engineers won't know that you had been in their database. I hope you learned something useful to prevent your systems from being compromised. Leave me your thoughts in the comments below!

Tag