FuzzingTool v3.14 releases: web penetration testing tool
FuzzingTool
FuzzingTool is a web penetration testing tool, that handles with fuzzing. After the test is completed, all possible vulnerable entries (and the response data) are saved on a report file.
Changelog v3.14
New features
- Added a replay proxy option
--replay-proxy PROXY
; - Added a
Matcher
option to match responses by regex-Mr REGEX
; - Added
Filter
:- Exclude responses by status codes
-Fc STATUS
; - Exclude responses by regex
-Fr REGEX
;
- Exclude responses by status codes
- Added recursion jobs feature:
- Plugin scanners now can enqueue payloads for the next job when needed;
- Added directory recursion feature (
--recursion
) on path fuzzing; - The user can set the maximum recursion level from jobs (
--max-rlevel RLEVEL
);
- Added option to set multiple plugin scanners (when use multiple
--scanner
argument); - Added plugin scanners:
Backups
;Wappalyzer
;
Removed features
- Removed the use of multiple http methods;
- Removed
Find
plugin (replaced by match by regex);
Bugfix
- Fixed a bug with match logic on
Matcher
, when set multiple match options and only one is considered; - Fixed a bug with
DnsZone
plugin when set an invalid hostname; - Fixed a split string error on function
split_str_to_list
;
CLI output changes
- When do a subdomain fuzzing, the ip address will no longer be shown on cli output. It’ll only be stored in the report file;
- Added a progress bar (credits to Dirsearch for the idea)
Other changes
- Changed the program binary name from
FuzzingTool
tofuzzingtool
; - Now the
Dictionary
object will enqueuePayload
objects into the payloads queue; - Each
Payload
has his own recursion level attribute (Payload.rlevel
) to tell about the job recursion level; - Now the wordlist creation and build are threaded;
Code refactored
- Added
HttpHistory
object to store the information about the request and response into the result object, including the ip address when do a subdomain fuzzing; - Moved some functions from
http_utils
module toUrlParse
class; - Removed
inspect_result
method from scanners. Now they will append results in the_process
method; - Removed decorator
append_args
, no longer needed; - Updated fuzz types and created a class to store the plugin categories on
utils/consts
; - Moved both
logger
andreports
topersistence
directory; - Updated the order of the parameters on
PluginFactory
methods; - Moved the
api
to outside of a specific folder; - Moved the argument build functions to
utils/argument_utils
;
Install
$ pip install FuzzingTool
Use
List of Execution Parameters
Argument | Required | Description | Default |
---|---|---|---|
-h, --help |
Misc | Show the help menu and exit | |
-v, --version |
Misc | Show the current version and exit | |
-r |
Yes/No | Define the file with the request data (including target) | |
--scheme |
No | Define the scheme used in the URL | http |
-u |
Yes/No | Define the target URL | |
--data |
Yes/No | Define the POST data | |
--proxy |
No | Define the proxy | |
--proxies |
No | Define the file with a list of proxies | |
--cookie |
No | Define the HTTP Cookie header value | |
--timeout |
No | Define the request timeout | None |
-f |
Yes | Define the wordlist file with the payloads | |
--prefix |
No | Define the prefix used with payload | |
--suffix |
No | Define the suffix used with payload | |
--upper |
No | Set the uppercase flag for the payloads | |
--lower |
No | Set the lowercase flag for the payloads | |
--capitalize |
No | Set the capitalize flag for the payloads | |
-V, --verbose |
No | Enable the verbose mode | |
--delay |
No | Define the delay between each request | 0 |
-t |
No | Define the number of threads used in the tests | 1 |
--allowed-status |
No | Define the allowed status codes for responses to be saved on report | 200 |
-o |
No | Define the report format | txt |
Example
Data Fuzzing
GET Request
In this example, you set the GET variable ‘id’ as an entry for the fuzzing test. The parameter values are read from the file ‘sqli.txt’.
$ ./FuzzingTool.py -u http://mydomainexample.com/post.php?id= -f /home/profile/wordlists/sqli.txt -o blind_sqli.csv
If you want to test more than one parameter, you can just do something like that on url:
http://mydomainexample.com/post.php?id=$&user=$
POST Request
In this example, you set the POST variables ‘login’ and ‘passw’ as entries for the fuzzing test; and also sets the fixed value ‘login’ for ‘user’ variable.
$ ./FuzzingTool.py -f /home/profile/wordlists/sqli.txt -u http://mydomainexample.com/controller/user.php –data ‘login&passw&user=login’
Keep in mind: FuzzingTool will ask you for a data comparator, to be used for exclude responses based on length or time. But the app looks first for the response status code before look at these elements. So, if you are testing Blind SQLi Time-Based, make sure to allow status code 500 if the server raises internal server error responses.
URL Fuzzing
You can set the payload mode on the URL for the fuzzing test. It’s based on the variable ‘$’ position too.
Path Scanning
Example for path scanning (added suffixes to the payload):
$ ./FuzzingTool.py -f /home/profile/wordlists/paths.txt -u http://mydomainexample.com/$ –suffix .php,.html
If your file paths.txt looks like this:
wp-admin administration admin-page
Your payloads will be:
wp-admin.php wp-admin.html administration.php administration.html admin-page.php admin-page.html
You can also make subpath scanning, see these urls:
http://mydomainexample.com/scripts/$ # <– subpath inside ‘scripts’ directory
http://mydomainexample.com/$/admin.php # <– enumerate paths
More…
Copyright (c) 2021 Vitor Oriel