RabidSQrL is an SQL injection attack tool. 
------------------------------------------

It requires python3 and the python YAML package. (On Ubuntu you can 
install these via "sudo apt-get install python3 python3-yaml".)

Degrees of freedom in RabidSQrl are:
- Types of SQL Injection attacks to perform.
- Injection interval function.
- Injection URL length (for file transfer attack)

Currently supported attacks:
- Direct injection.
- Stacked Queries (postgres, not supported on MySQL)
- Move file from attacker path to victim path via database manipulation
- Read file on server to stdout on client
- DOS attack on mysql
- Show database users on server
- discover MySQL version
- Generic, user-defined SQL statements executed directly on the server.

Note that these are attacks are targeted at specific datbase/application 
platforms: mysql/wordpress and postgres/smf. The code base includes
vulnerabilities that the user should install on the victim platforms. If
the user does not have access to the victim machine, he or she can use
sqlmap or other sql injection mapping tool to discover existing vulnerable
URL attributes and customize the rabidsqrl configuration to support attacks
using these discovered attacks. Rabidsqrl itself does not scan a victim
for vulnerabilities. 

Installation:
-------------
Rabidsqrl is installed via standard python distutils methods.

> sudo python3 setup.py install

See README.wpvuln and README.smf-server for details on how to install
the vulnerabilies on these machines.

Running:
--------
rabidsqrl is invoked via loading it as a python3 module.

The usage string of rabdsqrl is:

usage: rabidsqrl [-h] [-c CONFIG] [-g]
                 [-l {none,all,debug,info,warning,error,critical}]

rabidsqlr - an SQL Injection tool

optional arguments:
  -h, --help            show this help message and exit
  -c CONFIG, --config CONFIG
                        Path to the configuration file.
  -r, --results         Show results of attack on stdout.
  -b, --blind           If given, do not embed attack results in the
                        responses. Makes the attack more stealthy at the cost
                        of attack confirmation.
  -l {none,all,debug,info,warning,error,critical}, --loglevel {none,all,debug,info,warning,error,critical}
                        The level at which to log. Must be one of none, debug,
                        info, warning, error, or critical. Default is none.
                        (This is mostly used for debugging.)

examples:
> python3 -m rabidsqrl --help
> python3 -m rabidsqrl -c /tmp/my-attack.conf -l info
> python3 -m rabidsqrl -c examples/wpvuln-readfile.conf -r 

Seeing the results of the attack. If -r (or --results) is given on the command
line, rabidsqrl will parse the results of the attack and display them on the 
command line. This functionality requires the rabidsqrl provided vulnerabilities
to be installed on the victims. Note that if -b (--blind) is given, the results
cannot be shown as they are not inserted into the results on the server-side.

If -b (or --blind) is given, the pages that the server returns will not be altered
in any way. This makes the attack stealthier at the expense of being unable to 
tell directly if the attack was successful. 

Configuration File 
------------------------------------------
Rabidsqrl is driven by its configuration file. This
section describes the defined configuration parameters.

The configuration file format is YAML. 

The basic file format is a list of dictionaries. Each dictionary
describes a single attack. For example, here is a configuration file
with two attacks:

[
    {
        attack one details
    },
    {
        attack two details
    }
]


Configuration Entries:
---------------------
This section gives deatils on the allowed entries in the attack dictionary
section of a configuration files. Examples will follow.

Standard/base entries. These entries are applicable to any attack.

1. "base_url". Required. The portion of the attack URL which does
    not change. The path to the file on the server which contains
    the vulnerability. 
2. "attack". Required. The type of attack to launch. There are two attacks
    supported: "sql_inline" and "filewrite". The sql_inline attack
    will append the user supplied SQL to the URL for injection.
    The filewrite attack will generate its own custom SQL based 
    on the database of the attacked application and write a file
    from the client unto the server. 
3. "attribute". Required. The attribute of the url which is vulnerable to attack.
4. "stealth_interval". Optional. A function which returns a floating point 
    number when called. This function will be called between SQL injection 
    invocations. The function is python code and can assume that the python 
    random module has been imported.
    Examples:
        "10" - always wait 10 seconds
        "random.normalvariate(5, 1.8)+3" - normal distribution centered on 5 w/a 
            standard deviation of 1.8 seconds - then add 3 to that.
        "random.choice([1,2,5,6])" - one of 1, 2, 5, or 6 seconds chosen randomly
        "random.uniform(4, 8)" - some random floating point number between 4 and 8.
    See the documentation for python's Random module for more details.

Attack specific entries. These are required for the specific attacks listed.

sql_injection attack configuration. 

1. "statements". Required. The SQL statements to inject. This is a list of
    SQL statements that will be executed on the server via sql injection. 
    Example:
        "statements": [
            "create table olive(data text) --",
            "insert into olive(data) values('hello')--"
            "insert into olive(data) values('world')--"
            ]

filewrite attack configuration.

1. "file_write". Required. The path, on localhost, to a file to copy to the server. 
2. "file_dest". Required. The full path (including file name) to write the file to. 
3.  "database". Required. The type of database used on the server. One of "mysql" or 
    "postgres" and others may be added if desired. Database detection
    may be added in the future if needed although the user can just use
    sqlmap for database detection now.
4. "stealth_size". Optional. If given a function in the same form as the
    "stealth_interval" configuration which describes the size of each specific amount
    of data transfered with each URL request. Rabidsqrl does not check for valid sizes,
    so be careful when setting this parameter. Example: "random.uniform(256,1024)" will
    vary the portion of the file transfered with each URL to a random integer between
    256 and 1024 bytes for each URL. 

Example Configuration Files:
----------------------------
See the ./examples directory for working example configurations.