-
Notifications
You must be signed in to change notification settings - Fork 3
/
README
160 lines (130 loc) · 6.66 KB
/
README
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
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.