Thursday, 6 January 2011

Accessing and cracking mysql passwords via vulnerable web applications

In this article we look at extracting passwords and cracking hashes from a MySQL database via a vulnerable web application. These techniques are equally relevant to other databases (MS-SQL, Oracle etc) though db syntax, exact capabilities and hashing algorithms will vary.

I'm not going to go into the details of specific web application attacks here, as there are plenty of examples of LFI, RFI, SQL injection, and other command injection attacks, on the following sites:

These types of attacks are very popular currently, with new vulnerabilities in web applications being discovered every day. Here I will simply talk about a couple of options for extracting MySQL passwords, following-on from initial attack vectors.

Please remember to use these techniques only for legitimate penetration testing, not for malicious purposes. Every action you take has consequences, and you will be heir to the results of your actions.

Direct knowledge of SQL passwords from config files

Typically a web application that needs to access a back-end database will have a configuration file that contains the database details and login credentials. This is essential for the web application to work.

The config file may be called something like "config.php", and would typically be stored in one of the web directories as part of the site.

Important lines in the file might look something like this:

$db_host = 'localhost';
$db_name = 'webdb';
$db_user = 'root';
$db_password = 'p@sswd1';

So it may be possible to get these credentials directly, using an attack which exposes the contents of the configuration file.

This could be via local or remote file inclusion attacks, sql injection etc.

Whatever the method, getting hold of this file is useful. Even if the database is not directly accessible, getting passwords can be an important step as passwords are often reused in multiple places.

Even if this password is found, it may have a low privilege, so may be worth continuing to follow the details below with other users. There may be several accounts in the database where the hashes are accessible.

SQL Injection to view table contents

It may be possible to get at the relevant user and password fields directly from the back-end database using SQL injection, and display the results in web page, either directly as part of the query results, or by creating a file with the details in.

A typical query to do this might looks something like this:

SELECT user,password FROM mysql.user;

...and would produce results in the following format...

| root             | *1DD2A6D6B8D512EBF62D49B75BB598E1E8661A93 |

Single text field limitation

If you are limited to displaying a single text field in the query, then the user-name and password could be joined into a single field as follows:

SELECT CONCAT(user,':',password) FROM mysql.user;

| root:*1DD2A6D6B8D512EBF62D49B75BB598E1E8661A93             |

Outputting password hashes to a file in a SQL query

Another way of extracting password data would be to write it to a file. You may be able to write to a new file in a web directory on the web-server, that you can then get to from a web browser.

This could be done with a SQL query similar to the following

SELECT user,password FROM mysql.user INTO OUTFILE '/var/www/images/hacked.txt';

This creates a new file, "hacked.txt", which could then subsequently be accessed with a web browser, by going to:


Cracking the hashes

So what have we got here? These are password hashes, double SHA1 hashes to be exact (as denoted by the asterisk in front).

If the password is not particularly strong, these hashes can be easily and quickly cracked with John The Ripper, using a dictionary, brute-force or hybrid attack.

There are some large dictionaries of common passwords on Backtrack 4. There are a 40 million passwords in the following directory (though some duplicates between the files):

wc -l /pentest/passwords/wordlists/*

  3385284 /pentest/passwords/wordlists/bt4-password.txt
  1707657 /pentest/passwords/wordlists/darkc0de.lst
 35072354 /pentest/passwords/wordlists/wpa.txt
 40165295 total

Dictionary attacks on password hashes can be very fast. For example on my desktop (fairly new, but a basic spec) I get a hash-cracking rate of around 2 - 4 million characters per second, so this is a pretty rapid process.

I did some simple tests on the wpa.txt dictionary above, and it completes the 35 million hashes in around 13 seconds.

A dictionary attack could be started as follows.

./john hacked.txt --wordlist=/pentest/passwords/wordlists/wpa.txt

Loaded 1 password hash (MySQL 4.1 double-SHA-1 [mysql-sha1 SSE2])
guesses: 0  time: 0:00:00:13 100.00% (ETA: Thu Jan  6 19:34:24 2011)  c/s: 2675K

Note: It is very important to include the asterisk as part of the hash in your file. Don't take this out, otherwise JTR will not know that this is a double SHA1 hash, and will try to crack it as a SHA1 hash (which will fail)

To let JTR do an efficient brute force attack simply use

./john hacked.txt 

So, it's pretty simple, and weak passwords will certainly be cracked.

Your turn to have a go at cracking hashes

OK, so now you know that basics, here is your chance to have a go at cracking some hashes.

Below there is a mixture here of MD5, SHA1 and double SHA1 hashes for you to have a play with:

MD5 hashes

| pass1:cac36191e75ca4ddcbe5800c5cd25f92 |
| pass2:33c5d4954da881814420f3ba39772644 |
| pass3:c25846bdbf27696caa5541a474e9521b |

SHA1 hashes

| pass4:d9d71ab718931a89de1e986bc62f6c988ddc1813 |
| pass5:348162101fc6f7e624681b7400b085eeac6df7bd |
| pass6:36e618512a68721f032470bb0891adef3362cfa9 |

Double SHA1 hashes

| pass7:*1DD2A6D6B8D512EBF62D49B75BB598E1E8661A93 |
| pass8:*EA107160A003D070FE3EFE409813807BBA5ECE03 |
| pass9:*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |

See if you can crack them...

Top marks to anyone who can get all nine.


These threats can be mitigated in the following ways
  • Choosing strong passwords
  • Secure webapplication design and coding
  • Patch management, product updates and configuration management
  • Least privilege (use minimal privileges and a dedicated web application accounts)
  • OS and database hardening
  • Penetration testing to confirm the level of security and identify weaknesses


  1. What I particularly like is that Google will actually decrypt five of your six MD5 and SHA1 hashes :-) Who needs rainbow tables :-p

  2. Hi Dan, I see you were tempted by my geeky challenge :o)

    That's a very good point; that often you don't need to crack common hashes as many are already "cracked" in the public domain.

  3. i got all 10 of them

  4. This comment has been removed by a blog administrator.

  5. s1vn3m,
    I don't offer that service, and I have removed the hash (and your email address) from this public post.

  6. thanks a lot haven see this before