SQLbrute

Description

SQLBrute is a tool for brute forcing data out of databases using blind SQL injection vulnerabilities. It supports time based and error based exploit types on Microsoft SQL Server, and error based exploit on Oracle. It is written in Python, uses multi-threading, and doesn’t require non-standard libraries (there is some code in there for pycurl, but it is disabled because it isn’t finished).

 
Usage: ./sqlbrute.py options url
            [--help|-h]                        
            [--verbose|-v]                    
            [--server|-d oracle|sqlserver]     
            [--error|-e regex]                 
            [--threads|-s number]             
            [--cookie|-k string]              
            [--time|-n]                       
            [--data|-p string]                
            [--database|-f database]          
            [--table|-t table]                 
            [--column|-c column]               
            [--where|-w column=data]           
            [--header|-x header::val]      



--data allows you to specify POST data for a form post. Takes a string containing all the data as an argument

--cookie allows you to specify the cookies to be supplied. Takes a string containing all the cookies as an argument

--header allows you to specify arbitrary HTTP headers to include in the request (e.g. Accepts headers or similar).
 The header name and value need to be supplied as a single argument of the form header::value
Other options modify the default behaviour of the tool:

--server forces the tool to use Oracle or SQL Server exploit techniques. This is needed because the tool 
defaults to SQL Server, and won't intelligently detect that Oracle is in use

--threads specifies how many worker threads the tool will use to send requests. This defaults to 5, however 
this should be reduced if you are getting unreliable results (especially when doing time based testing). 
Setting this too high has a tendency to max the CPU on your machine, and have bad effects on the machine you're testing

--time forces the tool to use time based testing instead of error based testing

--verbose turns on verbose output. By default the tool doesn't output anything until it has completely 
enumerated an entry, which can lead to wondering whether it is actually doing anything. Using verbose
 once will output preliminary results - allowing you to see that its working. Using verbose twice will output 
requests and responses to allow debug issues with the tool

--output allows us to specify an output file for the results. Otherwise the only results we will get will be to stdout
The remainder of the options specify the data to be brute forced from the database:

--error specifies a regular expression to look for that appears in one of the AND or OR cases noted above. 
Usually this will be something identifiable such as an error message, or a message noting that no results were found

--database (SQL Server only) specifies what database to use for enumerating data
--table specifies what table to use for enumerating data

--column specifies what column to use for enumerating data

--where allows us to filter what data to brute force out by specifying a WHERE clause when enumerating a column.
 The where data must be in the form column_name=data (i.e. WHERE foo=bar)
The tool is designed to be used in a logical progression:
Running the tool without specifying a database, table, or column parameter will enumerate the list of databases for 
SQL Server, and the list of user tables for Oracle
Running the tool with the name of a database (SQL Server only) will enumerate the list of tables
Running the tool with a table parameter (plus database parameter for SQL Server) will enumerate the columns in that table
Running the tool with a column parameter (with table and database parameters if applicable) will enumerate the data 
in that column of that parameter. You can then find matching values in other columns of the table through 
using a --where command line option