In the previous article we talked about Nemesida WAF Free – a free web application firewall for protecting web sites and API against hacker attacks, and in this article we decided to review the popular web application vulnerability scanner – Wapiti.
Scanning a site for vulnerabilities is a necessary measure, which, together with an analysis of the source code, allows you to assess the level of its protection against threats of compromise. You can scan a web resource using specialized tools.
Nikto, W3af (written in Python 2.7, whose support has ended) or Arachni (no longer supported since Feb. 2020) are the most popular solutions presented in the free segment. Of course, there are others, for example, Wapiti.
Wapiti works with the following types of vulnerabilities:
- file expansion (local and remote, fopen, readfile);
- injection (PHP / JSP / ASP / SQL injection and XPath injection);
- XSS (Cross Site Scripting) (reflected and persistent);
- detection and execution of commands (eval(), system(), passtru());
- CRLF injection (split HTTP responses, session fixation);
- XXE (XML External Entity) embedding;
- SSRF (Server Side Request Forgery);
- use of known potentially dangerous files (thanks to the Nikto database);
- weak .htaccess configurations that can be bypassed;
- the presence of backup files that reveal confidential information (disclosure of the source code);
- open redirects;
- non-standard HTTP methods that can be allowed (PUT).
- support for proxies HTTP, HTTPS and SOCKS5;
- authentication using several methods: Basic, Digest, Kerberos or NTLM;
- limiting the scan area (domain, folder, page, URL);
- automatic removal of one of the parameters in the URL;
- multiple precautions against infinite scan cycles (e.g.: ifor, limiting values for a parameter);
- setting a priority for learning URLs (even if they are not in the crawl area);
- excluding some URLs from crawling and attacks (e.g.: URL logout);
- importing cookies (getting them using the wapiti-getcookie tool);
- activating / deactivating the verification of SSL certificates;
- interaction with HTML5;
- several options for managing the behavior and restrictions of the crawler;
- setting the maximum time for the scanning process;
- adding some custom HTTP headers or setting up a custom User-Agent.
- Creation of reports on vulnerabilities in various formats (HTML, XML, JSON, TXT);
- suspend and resume a scan or attack (session mechanism using SQLite3 databases);
- highlighting in the terminal to highlight vulnerabilities;
different levels of logging;
- a quick and easy way to activate / deactivate attack modules.
The current version of Wapiti can be installed in 2 ways:
- download the source from the official site and run the installation script with Python3;
- using pip3 install wapiti3 command.
After that, Wapiti will be ready to go.
Working with the tool
To demonstrate how Wapiti works, we will use a specially prepared stand sites.vulns.pentestit.ru (an internal resource) containing various vulnerabilities (Injection, XSS, LFI / RFI) and other shortcomings of web applications.
The information is provided for educational purposes only. Do not break the law!
Basic command to start 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 – for specifying the scope parameter along with the URL for crawling, you can adjust the site’s crawl area by specifying both a separate page and all pages that can be found on the site.
- -s / -x are options to add or remove specific URLs. These parameters are useful when you need to add or remove a specific URL during the scan process.
- - skip – the specified parameter with this key will be scanned, but will not be attacked. Useful if there are any dangerous parameters that should be excluded during scanning.
- - verify-ssl – enable or disable certificate verification.
The Wapiti scanner is modular. However, to launch specific modules, among those that are automatically connected during the scanner’s operation, 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. In its simplest form, it will look like this:
# wapiti -u http://sites.vulns.pentestit.ru/ -m sql,xss,xxe
This usage example means that we will only use the SQL, XSS and XXE modules when scanning the 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 xss module will apply to requests submitted by the GET method, the blibdsql module will apply to POST requests, etc. By the way, if some module that was included in the list was not required during scanning or works for a very long time, then pressing the Ctrl + C combination you can skip using the current module by selecting the corresponding item in the interactive menu.
Wapiti supports passing requests through a proxy server using the -p switch and authenticating to the target site using the -a parameter. You can also specify the type of authentication: Basic, Digest, Kerberos and NTLM. The latter two may require the installation of additional modules. In addition, you can insert any headers into requests (including an arbitrary User-Agent) and much more.
The wapiti-getcookie tool can be used to use authentication. We use it to generate a cookie that Wapiti will use when scanning. The cookie is formed using 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.
At the output, we get a file in JSON format. Another option is to add all the required information via the -d parameter:
# 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://myproxy:3128
where, among other parameters:
- -f and -o – format and path for saving the report;
- -m – connect all modules – not recommended, because will affect testing time and report size;
- -color – highlight found vulnerabilities depending on their criticality according to the version of Wapiti itself;
- -c – use the cookie file generated by wapiti-getcookie;
- -scope – selection of a target for an attack. Selecting the folder option will scan and attack every URL starting from the base one. The base URL must have a forward slash (no filename);
- -flush-session – allows you to re-scan, which will not take into account previous results;
- -A – own User-Agent;
- -p – proxy server address, if needed.
The scan result is presented in the form of a detailed report on all detected vulnerabilities in HTML-page format, in an understandable and easy-to-read form. The report will indicate the categories and number of vulnerabilities found, their descriptions, requests, curl commands and advice on how to close them. For the convenience of navigation, a link will be added to the names of the categories, by clicking on which you can go to it:
A significant drawback 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 a possibility of false positives. In our case, the report includes “backup files” and “potentially dangerous files”. Their number does not correspond to reality, since there were no such files on the server:
Possibly, incorrectly working modules will be fixed over time. Another drawback of the report is the lack of coloring of the vulnerabilities found (depending on their severity), or at least their division into categories. The only way we can indirectly understand about the criticality of the found vulnerability is to use the – color parameter during scanning, and then the found vulnerabilities will be colored in different colors:
But in the report itself, such a coloring is not provided.
Vulnerabilities The crawler 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 with the use of valid cookies, since most likely, after successful authentication, their session will be “logged out” and the cookie will become invalid. If the deauthorization function were executed 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 being triggered. Otherwise, it will not work 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 the closed area of the web resource.
The scanner did an excellent job with the task and found all the prepared vulnerabilities:
LFI / RFI
The scanner found all inherent vulnerabilities:
In general, despite false positives and omitted 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 get basic information about the security state of a web application.
For protecting web sites, online stores, web portals, API and another web applications against hacker attacks and scanning we recommended use the Nemesida WAF.
Stay healthy and protected!