The Mole - Automatic SQL Injection Exploitation Tool

The Mole - Automatic SQL Injection Exploitation Tool

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 vulnerability and exploit it, either by using the union technique or a boolean query based technique.

It uses a command based interface, allowing the user to indicate the action he wants to perform easily. The CLI also provides auto-completion on both commands and command arguments, making the user type as less as possible.

Note: It requires Python 3 and python3-lxml. 

Features:

  • Support for Mysql, Postgres, SQL Server and Oracle.
  • Automatic SQL injection exploitation using union technique.
  • Automatic blind SQL injection exploitation.
  • Exploits SQL Injections in GET/POST/Cookie parameters.
  • Support for filters, in order to bypass certain IPS/IDS rules using generic filters, and the possibility of creating new ones easily.
  • Exploits SQL Injections that return binary data.
  • Powerful command interpreter to simplify its usage.

How To Use The Mole

Execute The Mole using the parameter "-u" to indicate which URL we will be using, and "-n" to indicate the needle/string. The 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 show a prompt:


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.

For 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.

Now, 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.


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.


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.


We can also indicate a "where condition", in order to only dump rows which match it.



Here is a list of all supported commands:
  • - url [URL [PARAM]]: Gets/sets the URL. If PARAM is given then the injection will be performed on that argument. This can also be provided as an argument to the application, using the "-u" parameter.
  • - needle [NEEDLE]: Gets/sets the NEEDLE. This can also be provided as an argument to the application, using the "-n" parameter.
  • - method (GET|POST <param_post> ) [vulnerable_param]: Sets the method of the request to GET or POST. In case POST is given the param_post string will be used as the POST parameters. If vulnerable_param is given then the mole will use this parameter to inject.
  • - vulnerable_param [<GET|POST|Cookie> VULNERABLE_PARAM]: Sets/gets the type and name of the vulnerable parameter to be exploited by The Mole.
  • - injectable_field [<FIELD_NUM>]: Sets/gets the field of the query which will be used to print the information retrieved when using a union technique.
  • - auth [<basic> <USERNAME:PASSWORD>]: Sets/gets the authentication information used by The Mole in each request.
  • - follow_redirects [<on|off>]: Sets/gets the follow redirect flag. If enabled, The Mole will follow http redirects received from the server.    
  • - dbinfo: Fetch current username, database name and DBMS version.
  • - usercreds: Fetches the credentials for the dbms. Usually requires administrator privileges on the database.
  • - schemas: Fetches the schemas(databases) from the server. The results obtained will be cached, so further calls to this command will return the cached entries. See "fetch" command.
  • - tables <SCHEMA>: Fetches the tables for the schema SCHEMA. The results obtained will be cached, so further calls to this command will return the cached entries. See "fetch" command. e.g: "tables mysql"
  • - columns <SCHEMA> <TABLE>: Fetches the columns for the table TABLE, in the schema SCHEMA. The results obtained will be cached, so further calls to this command will return the cached entries. See "fetch" command. e.g: "columns mysql user"
  • - recursive (schemas|tables <SCHEMA>): Recursively fetches the structure of all schemas or just of the SCHEMA if used with tables.
  • - query <SCHEMA> <TABLE> COLUMN1[,COLUMN2[,COLUMN3[...]]] [where COND]: Perform a query to fetch every column given, using the table TABLE located in the schema SCHEMA. A "where condition" can be given. Note that The Mole will take care of any string conversions required on the condition. Therefore, you can use string literals(using single quotes) even if the server escapes them. Note that no caching is performed when executing this command. e.g: query mysql user User,Password where User = 'root'
  • - fetch <schemas|tables|columns> [args]: This command calls schemas, tables or columns commands depending on the arguments given, forcing them to refetch entries, even if they have already been dumped. This is useful when, after having stopped a query in the middle of it, you want to fetch all of the results and not just those that you were able to dump before stopping it. e.g: "fetch columns mysql user"
  • - readfile <FILE>: Read the FILE from the remote server (if possible) and print it.
  • - find_tables <SCHEMA> <TABLE1> [<TABLE2>, ...]: Bruteforce to find if the TABLES given as parameters are part of the SCHEMA. Useful for MySQL version 4 where no information_schema available.
  • - find_tables_like <SCHEMA> <FILTER>: Perform a query to extract all tables from SCHEMA that match the LIKE filter given as param FILTER.
  • - find_users_table <SCHEMA>: Bruteforce to find tables in SCHEMA that match common names for tables where usernames are stored.
  • - cookie [COOKIE]: Gets/sets a cookie to be sent in each HTTP request's headers.
  • - mode <union|blind>: Sets the SQL Injection exploitation method. By default, union mode is used. If the injection cannot be exploited using this mode, change it to blind using "mode blind" and try again. Nothing else has to be configured to go from union to blind mode, as long as you have already set the URL and needle.
  • - prefix [PREFIX]: Gets/sets the prefix for each request. The prefix will be appended to the URL's vulnerable parameter on each request.
  • - suffix [SUFFIX]: Gets/sets the suffix for each request. The suffix will be appended after the injection code on the URL's vulnerable parameter.
  • - verbose <on|off>: Sets the verbose mode on and off. When this mode is on, each request's parameters will be printed out.
  • - output <pretty|plain>: Sets the output style. When pretty output mode is enabled(this is the default), queries result will be printed on a tidy box, using column names and each row will be aligned. The drawback is that this method requires the whole query to finish before printing results, so you might want to use "plain" output if you seek immediate results. In contrast, plain mode prints each result as soon as it is recovered. 
Pretty output might print results like this:
+-----------------------------------------------------+
| User | Password |
+-----------------------------------------------------+
| blabla | *2B0DDEE3597240B595689260B53D411F515B806D |
| foobar | *641B2485F1789F7A6BEE986648B83A899D96793B |
+-----------------------------------------------------+
While plain output will print them like this:
User, Password:
blabla, *2B0DDEE3597240B595689260B53D411F515B806D
foobar, *641B2485F1789F7A6BEE986648B83A899D96793B

  • - delay [DELAY]: Gets/Sets the delay between requests. Use this if the server contains some kind of IPS system that returns HTTP error when executing lots of requests in a short amount of time. Note that DELAY can be a floating point number, so you can set "0.5" as the delay.
  • - headers <set|del> <HEADER> [VALUE]: Sets/removes the given HTTP header. Use this to set the User-Agent, cookie, or whatever additional header you want to send.
  • - encoding [ENCODING]: Gets/sets the encoding use to decode the response received.
  • - requestsender [<httpsender|headsender>]: Gets/sets the request sending mechanism. httpsender is the default mechanism, it makes the request and returns the full body of the response. headsender makes a HEAD request and retrieves the headers of the response as the HTML of the response. 
  • - qfilter <add|del|config> <FILTER> [ARGS]: Add/configure/remove query filters. Query filters are applied to each query before appending it to the vulnerable parameter. So far, these can be used to either bypass an IPS/IDS or to apply a filter when SQL Server requires you to change the collation of the retrieved fields.
  • - responsefilter <add|del|config> <FILTER> [ARGS]: Adds/removes/configs a response filter. Response filters are applied to the response retrieved from the server. In some cases, invalid HTML can make The Mole miss the injection, so you might want to use a regular expression in order to fix it.
  • - requestfilter <add|del|config> <FILTER> [ARGS]: Add/configure/remove a request filter. Request filters are applied once the request is generated but before it is sent to the server.
  • - export <TYPE> [<ARG1>, ...]: Exports the current mole configuration and the dumped schema's structures for later usage. Currently supported types and params:
    • xml <FILE>: exports the configuration to an xml file.
  • - import <TYPE> [<ARG1>, ...]: Imports a previously exported mole configuration and dumped schema's structures. Currently supported types and params:
    • xml <FILE>: imports the configuration from an XML file.
  • - usage <COMMAND>: Print the usage for the command COMMAND.
  • - exit: Exit The Mole.

Source: www.effecthacking.com
The Mole - Automatic SQL Injection Exploitation Tool The Mole - Automatic SQL Injection Exploitation Tool Reviewed by Anonymous on 4:06 AM Rating: 5