The Mole Automatic SQLi Tool Tutorial.

Posted by : Anonymous Sunday, December 18, 2011

The Mole is an automatic SQL Injection exploitation tool. Only by providing a vulnerable URL and a valid string on the site it can detect the injection and exploit it, either by using the union technique or a boolean query based technique.

Features

Support for injections using Mysql, SQL Server, Postgres and Oracle databases.
Command line interface. Different commands trigger different actions.
Auto-completion for commands, command arguments and database, table and columns names.
Support for query filters, in order to bypass certain IPS/IDS rules using generic filters, and the possibility of creating new ones easily.
Exploits SQL Injections through GET and POST methods.
Developed in python 3.

Tutorial

In this tutorial, you will learn how to use The Mole to exploit SQL Injections, extracting data from the database and reading files from the vulnerable server.

In order to read a complete reference of The Mole's commands and how to use them, please visit http://www.aldeid.com/wiki/TheMole (btw, thanks to Sébastien Damaye for writing such a complete guide!).

Before we start, you must know what is required in order to exploit a SQL Injection using The Mole. Once you have found a vulnerable script, you have to find a string which normally appears in the web page, but does not appear when you negate the query which is being executed on the database(by modifying the vulnerable parameter).

Identifying the injection

This example will be shown using this test site:

Okay, assuming we don't know there's a SQL Injection, we will ensure there is one on the parameter "id". We negate the query which will be executed in the database, and try to find the string above mentioned.

Fine, we see the string "admin" has disappeared. We will provide this string to The Mole and exploit the injection.

Exploiting the injection

First of all, we execute The Mole using the parameter "-u" to indicate which URL we will be using, and "-n" to indicate the needle/string. Our command should look like this:

./mole.py -u 'http://192.168.0.142/vulnerable/sqli.php?id=1' -n 'admin'

The mole will start and give us a prompt:

Notice that by default, the last parameter on the URL is used as the vulnerable parameter. If you want to specify another parameter as the vulnerable one, you can use the "-p" command line argument, or use the "injectable_field" command.

Windows users

Windows users shoud be aware that when using the "-u" command line argument, the "&" characters have to be escaped manually using the "^" character. Therefore, if the URL has two parameters, it should look like this:

mole.exe -u http://192.168.0.142/vulnerable/sqli.php?param=1^&id=1 -n 'admin'

You can also set the URL by using the "url" command, so you can paste the URL without quoting it. The needle can also be set using the "needle" command.

Okay, we are ready to go. First of all, we want to know which databases are available on the system. The command "schemas" will dump their names.

The Mole has done two things here:

Find exploitation parameters, such as number of columns, the comment to be used, the back-end database, the number of parenthesis, etc.
Once it has been initialized, it dumps the database names, using back-end database specific queries.

Note that the initialization phase is done only once. Moving on, we will dump the tables in the "test" database. The "tables" command does that, and requires the database name as its argument:

Great! There's a "users" table! Now we need to find the columns of that table. The "columns" command requires the name of the database and table name as its arguments.

We see 3 columns, id, username and password. Now it's time to dump those hashes :D. The "query" command requires the database name, the table name, and a list of comma-separated columns to dump. Alternatively, you could use '*' in the columns field, but we don't want to dump the "id" column right now, so we will do it manually. Remember that The Mole provides nice autocompletion features, so the database, table and column names will be autocompleted whenever you press the TAB key.

Nice! We've got the administrator's credentials. However, when we dumped the database names, we could see "mysql", so we probably have mysql root privileges. Let's find out by using the "dbinfo" command, which will dump the database user, name and version.

Ha, thought so, we have root privileges. Okay, lets try reading a file by using the "readfile" command, which expects the filename to be read as its argument. We will read /etc/passwd as an example.

Okay, now we move on to the handy commands which will make things faster. Imagine we don't know which tables exist on the "mysql" table. In this case, the injection goes quite fast, since it can be exploited through the union technique, however, Blind SQL Injections are pretty common. In the latter case, dumping the name of every table in a certain database can be quite slow. In this case, we will use the "find_users_table" command, which tries to find a table name in a certain database which "looks like" it might contain usernames and passwords(based on its name). Note that this command does not use any metadata database/table, such as information_schema.tables, so it can be used in scenarios where the back-end database is a Mysql < 5, which does not contain the information_schema databse.

This command contains a small list of names, you can artenatively use "find_tables" which tries to find tables using a list provided by you.

As expected, mysql.user exists :D. Now we will use another command which will be more useful, but requires information_schema(or any other DBMS database which serves the same purpose) to exist. The "find_tables_like" command requires a database as its first argument and a string which will be used to search for database names. You can use the '%' wildcard, or any other database specific. As an example, we will find all tables that contain the substring "ABLE".

Going back to the "query" command, we can use some extra parameters which will be useful under certain situations. We can limit the number of rows to be dumped and/or indicate the first index from which to start the dump(0-index based). This prints only one row, starting from the second index.