🥇Wapiti - check the site for vulnerabilities on your own

In the past article we talked about Nemesida WAF Free — a free tool for protecting websites and APIs from hacker attacks, and in this one we decided to review the popular vulnerability scanner Wapiti.

Scanning a site for vulnerabilities is a necessary measure, which, together with the analysis of the source code, allows you to assess the level of its protection from threats of compromise. You can scan a web resource using specialized tools.

Nikto, W3af (written in Python 2.7, support for which has ended) or Arachni (no longer supported since February) are the most popular solutions presented in the free segment. Of course, there are others, for example, Wapiti, which we decided to focus on.

Wapiti works with the following types of vulnerabilities:

file expansion (local and remote, fopen, readfile);
injections (PHP/JSP/ASP/SQL injections and XPath injections);
XSS (cross-site scripting) (reflected and persistent);
detection and execution of commands (eval(), system(), passtru());
CRLF injections (HTTP response splitting, session fixation);
XXE (XML External Entity) injection;
SSRF (Server Side Request Forgery);
use of known potentially dangerous files (thanks to the Nikto database);
weak .htaccess configurations that can be bypassed;
availability of backup files that reveal confidential information (source code disclosure);
shellshock;
open redirects;
non-standard HTTP methods that may be allowed (PUT).

Features:

support for HTTP, HTTPS and SOCKS5 proxies;
authentication using several methods: Basic, Digest, Kerberos or NTLM;
the ability to limit the scanning area (domain, folder, page, URL);
automatic removal of one of the parameters in the URL;
multiple precautions against infinite scan cycles (example: ifor, limiting values for a parameter);
the ability to set a priority for exploring URLs (even if they are not in the crawl area);
the ability to exclude some URLs from scanning and attacks (for example: URL logout);
importing cookies (getting them using the wapiti-getcookie tool);
the ability to activate / deactivate the verification of SSL certificates;
the ability to extract the URL from JavaScript (a very simple JS interpreter);
interaction with HTML5;
several options for controlling the crawler's behavior and limitations;
setting the maximum time for the scanning process;
adding some custom HTTP headers or setting up a custom User-Agent.

Additional features:

creation of reports on vulnerabilities in various formats (HTML, XML, JSON, TXT);
pausing and resuming a scan or attack (session mechanism using SQLite3 databases);
highlighting in the terminal to highlight the vulnerability;
different levels of logging;
quick and easy way to activate/deactivate attack modules.

Installation

The current version of Wapiti can be installed in 2 ways:

download source from official Site and run the installation script, after installing Python3;
using the pip3 install wapiti3 command.

After that, Wapiti will be ready to go.

Working with the tool

To demonstrate the work of Wapiti, we will use a specially prepared stand sites.vulns.pentestit.ru (internal resource) containing various vulnerabilities (Injection, XSS, LFI / RFI) and other flaws in web applications.

The information is provided for informational purposes only. Don't break the law!

Basic command to run the scanner:

# wapiti -u <target> <options>

At the same time, there is a fairly detailed help with a huge number of launch options, for example:

--scope - application area
If you specify the scope parameter along with the crawl URL, you can control the site crawl scope by specifying both a single page and all pages that can be found on the site.

-s и -x - options to add or remove specific URLs. These options are useful when you need to add or remove a specific URL in the crawl process.

--skip — the specified parameter with this key will be scanned, but will not be attacked. Useful if there are some dangerous parameters that should be excluded from scanning.

--verify-ssl - Enable or disable certificate verification.
The Wapiti scanner is modular. However, to launch specific modules, from among those that are automatically connected while the scanner is running, you need to use the -m switch and list the necessary ones separated by commas. If the key is not used, then all modules will work by default. At its simplest, it would look like this:

# wapiti -u http://sites.vulns.pentestit.ru/ -m sql,xss,xxe

This use case means that we will only use the SQL, XSS, and XXE modules when scanning a target. In addition, you can filter the operation of modules depending on the desired method. For example -m "xss: get, blindsql: post, xxe: post". In this case, the module XSS will apply to requests passed by the GET method, and the module blibdsql - to POST requests, etc. By the way, if some module that was included in the list was not required during the scan or works for a very long time, then by pressing the Ctrl + C combination you can skip using the current module by selecting the appropriate item in the interactive menu.

Wapiti supports passing requests through a proxy using a key -p and authentication on the target site through the parameter -a. You can also specify the type of authentication: Basic, Digest, Kerberos и NTLM. The latter two may require additional modules to be installed. In addition, you can insert any headers into requests (including arbitrary User Agent) and much more.

To use authentication, you can use the tool wapiti-getcookie. With its help, we create cookie, which Wapiti will use when scanning. Formation cookie is done with the command:

# wapiti-getcookie -u http://sites.vulns.pentestit.ru/login.php -c cookie.json

In the process of working in an interactive mode, we answer questions and indicate the necessary information such as: login, password, etc.:

The output is a JSON file. Another option is to add all the necessary information via the parameter -d:

# wapiti-getcookie - http://sites.vulns.pentestit.ru/login.php -c cookie.json -d "username=admin&password=admin&enter=submit"

The result will be similar:

When considering the main functionality of the scanner, the final request for testing a web application in our case was:

# wapiti --level 1 -u http://sites.vulns.pentestit.ru/ -f html -o /tmp/vulns.html -m all --color -с cookie.json --scope folder --flush-session -A 'Pentestit Scans' -p http://proxy.office.pentestit.ru:3128

where, among other parameters:

-f и -o — format and path for saving the report;

-m - connection of all modules - not recommended, because will affect the time of testing and the size of the report;

--color — highlight found vulnerabilities depending on their criticality according to Wapiti itself;

-c - using a file with cookiegenerated using wapiti-getcookie;

--scope - Selecting a target to attack. Choosing an option folder every URL will be crawled and attacked, starting with the base one. The base URL must have a slash (no filename);

--flush-session - allows you to rescan, which will not take into account previous results;

-A - own User Agent;

-p — proxy server address, if necessary.

A little about the report

The scan result is presented as a detailed report on all vulnerabilities found in HTML-page format, in a clear and easy-to-read form. The report will indicate the categories and number of vulnerabilities found, their description, queries, commands for curl and tips on how to close them. For ease of navigation, a link will be added to the category names, by clicking on which you can go to it:

A significant disadvantage of the report is the absence of a web application map as such, without which it will not be clear whether all addresses and parameters have been analyzed. There is also the possibility of false positives. In our case, the report includes “backup files” and “potentially dangerous files”. Their number is not true, since there were no such files on the server:

Perhaps incorrectly working modules will be fixed over time. Another drawback of the report is the lack of coloring of the found vulnerabilities (depending on their criticality), or at least their division into categories. The only way we can indirectly understand the criticality of the found vulnerability is to apply the parameter --color during scanning, and then the found vulnerabilities will be painted in different colors:

But in the report itself, such a coloring is not provided.

Vulnerabilities

SQLi

The scanner partially coped with the SQLi search. When searching for SQL vulnerabilities on pages where authentication is not required, no problems arise:

It was not possible to find a vulnerability on pages accessible only after authentication, even using valid cookie, since most likely after successful authentication, "their session will be logged out" and cookie will become invalid. If the deauthorization function were implemented as a separate script responsible for processing this procedure, then it would be possible to completely exclude it through the -x parameter, and thereby prevent it from working. Otherwise, it will not be possible to exclude its processing. This is not a problem of a specific module, but of the tool as a whole, but because of this nuance, it was not possible to detect several injections in a closed resource area.

XSS

The scanner did an excellent job with the task and found all prepared vulnerabilities:

LFI/RFI

The scanner found all embedded vulnerabilities:

In general, despite false positives and missing vulnerabilities, Wapiti, as a free tool, shows pretty good results. In any case, it is worth recognizing that the scanner is quite powerful, flexible and multifunctional, and most importantly, it is free, therefore it has the right to use it, helping administrators and developers to obtain basic information about the security status of a web application.

Stay healthy and protected!

Source: habr.com

Wapiti - checking the site for vulnerabilities on your own