
The time has come to summarize the results of the
automatic scan , which was announced 3 weeks ago. Several applications for automatic auditing were sent, most of the sites were from the commercial sector - online stores and corporate sites.
Tool selection
For automatic testing, one of the most popular opensource vulnerability scanners was chosen - w3af.
')
w3af or Web Application Attack and Audit Framework is a flexible platform for searching and exploiting vulnerabilities in web applications, it works on most modern systems written in Python. This framework is sometimes referred to as “Metasploit for the Web.”
To simplify the automated testing process, the console version of
w3af_console was taken. As in the GUI version, where everything is managed by profiles (consisting of plug-ins), in the console version all the controls and settings also depend on the connected plug-ins in the so-called script file.
How it works
The startup format of a customized script file is fairly simple:
./w3af_console -s MyScript.w3af
A script file consists of a sequence of plug-in plug-in types and their parameters:
plugins output console,text_file output output config text_file set output_file report.txt set verbose True back output config console set verbose False back crawl all crawl grep all grep audit all audit bruteforce all bruteforce back target set target http://targethost back start
In the presented example, all links from the targethost site will be collected, requests and responses, comments, error output will be analyzed, the knowledge / attributes will be checked for common web vulnerabilities, the input forms will be subjected to a bruteforce attack (password matching) and the result will be saved in the report.txt file with full output of the plugins.
output of plug-ins in manual mode in the w3af_console consoleWhat it consists of
Depending on the type of impact, there are several types of plug-ins:
- attack - to implement an attack, exploit. In the automatic audit are not used.
- audit - detection of web application vulnerabilities, contains plugins for searching XSS, SQLi, CSRF, LFI, RFI, open redirects and many others. Part of the plug-ins used in the automatic audit.
- auth - plugins for setting authorization parameters on the resource under study. In the automatic audit are not used.
- bruteforce - plug-ins for conducting a dictionary-picking attack (bruteforce). In the automatic audit are not used.
- crawl - plugins for searching and collecting information, sorting out file names and directories, using search engines, determining the type of CMS, analyzing forms for transfer to audit / bruteforce / attack departments. Part of the plug-ins used in the automatic audit.
- evasion - plugins for bypassing IDS , security policies and WAF . In the automatic audit are not used.
- grep - plugins for analyzing web server requests / responses, searching for critical information, displaying errors, comments in source code, etc. Part of the plug-ins used in the automatic audit.
- infrastructure - plugins for analyzing server settings, misconfigurations, virtual hosts, etc. Part of the plug-ins used in the automatic audit.
- mangle plugins for modifying queries on the fly. In the automatic audit are not used.
- output - plugins for outputting and saving work results. Part of the plug-ins used in the automatic audit.
You can find ready examples of script files for different attack vectors and type of impact
here . Their performance can be tested in a specialized vulnerable
moth environment.
Statistics
To conduct an automatic audit, a script file was arranged to search for and identify a complete site map, such as a CMS, a web server and an
OWASP TOP-10 vulnerability scan, a system for checking legitimacy and reporting layouts was configured (summarizing recommendations for found vulnerabilities were added manually by our employees cannot analyze attack vectors and create an accurate attack scenario).
screenshot of the system for adding a task to the autoscanOf the total number of top 5 sites in the total volume of identified vulnerabilities, it looks like this:- Sensitive data leakage - OWASP A6 (sensitive data exposure) - incorrect certificate configurations, incorrectly configured HSTS policies are also included here.
- Insecure configuration - OWASP A5 (security misconfiguration) - directory listing, default settings, outdated software versions.
- Using components with known vulnerabilities - OWASP A9 (using components with known vulnerabilities) - several unpatched vulnerabilities were found, with publicly available exploits.
- OWASP A3 XSS (cross-site scripting) crossite scripting - several passive XSS were found.
- Code injection - OWASP A1 (injection) - SQL-injection vulnerabilities are still quite common.
Resource scanning time took from 10 minutes to 2 days. Several sites could not withstand the load and
automatic testing was stopped until the recovery. For all the identified vulnerabilities, reports were prepared containing an enumeration of the identified vulnerabilities, the probability of a web application being compromised and a possible attack scenario.