w3af is a Web Application Attack and Audit Framework is an amazing tool that is written in Python and has the capability to find more than 200 defined vulnerabilities. Not only does it look for the usual suspects such as SQL injection, it also handles crawling, bruteforce, authentication, and so much more. There are a number of vulnerability scanners both commercial and open source, but it all comes down to what you prefer. I tend to lean toward the open source community because of transparency, community involvement, and the fact there is zero cost.
Unfortunately web applications pose one of the greatest risks to organizations because often these applications are either public facing, open to business partners and of course employees (the insider threat). The fact is web applications are a rich target because there are so many different attack vectors. For example, the following five examples a very often used and very easy to exploit once vulnerabilities have been identified.
- Cross-site scripting (XSS): Is the act of injecting lines of code into web pages in some shape or fashion. If not defended against, malicious code will eventually lead to a breach.
- Session Hijacking: Each unique user is assigned a “session” when they interact with a website. Session hijackers will intercept a session of someone else, intercepting information as it passes between the user and the server.
- Parameter Manipulation: Websites often pass information from one web page to the next through URL parameters. Sometimes someone may take advantage of this fact to rewrite these parameters in harmful ways.
- Buffer Overflow: A buffer is a small amount of space allotted to store data. If a buffer is overloaded, the extra data will overwrite data in other areas.
- SQL Injection: SQL injection works similarly to cross-site scripting. It is malicious SQL statements that are inserted in a variety of ways in order to attack the site. These statements are intended to manipulate the database.
Should you be an individual who prefers a GUI then w3af has you covered. The interface is straightforward and easy to hit the ground running. For this article I am going to work from the Terminal as well as the GUI. Working for the terminal may not always be the best solution and you will need to determine which path to take. The Terminal, at least for myself, makes sense because learning the commands makes you more skilled long term in my humble opinion.
Diving into the w3af console
The first thing to keep in mind is that I am working from Kali Linux and w3af comes preinstalled. Should you be working from another operating system then be sure to consult the w3af documentation.
Open your terminal and run the following:
w3af_console
Likely the first thing you should do is review the help, to do so simply type help at the Terminal.
|--------------------------------------------------------------------------| | start | Start the scan. | plugins | Enable and configure plugins. | exploit | Exploit the vulnerability. | profiles | List and use scan profiles. | cleanup | Cleanup before starting a new scan. |--------------------------------------------------------------------------| | help | Display help. Issuing: help [command] | version | Show w3af version information. | keys | Display key shortcuts. |--------------------------------------------------------------------------| | http-settings | Configure the HTTP settings of the framework. | misc-settings | Configure w3af misc settings. | target | Configure the target URL. |--------------------------------------------------------------------------| | back | Go to the previous menu. | exit | Exit w3af. |--------------------------------------------------------------------------| | kb | Browse the vulnerabilities stored in the Knowledge Base. |--------------------------------------------------------------------------|
At this stage I need to set my target. At the console simply type “target” and should you need help then simply type “help”. Here I am going ACU Blog which is a vulnerable website that is provided by Acunetix. Since I know the blog is running Microsoft .NET I need to set the target framework.
set target_framework asp.net
Next it is time to define the operating system and because the web application framework is .NET; it is fairly same to assume the operating system is Windows.
set target_os windows
Finally set the URL to the bog.
set target http://testaspnet.vulnweb.com/
At this point, it is time to enable the plugins you wish to use. To interact with the plugins simply type “plugins” at the terminal and then type “help”. At this point you are presented a list of eight different plugin types.
auth | View, configure and enable auth plugins evasion | View, configure and enable evasion plugins bruteforce | View, configure and enable bruteforce plugins infrastructure | View, configure and enable infrastructure plugins output | View, configure and enable output plugins grep | View, configure and enable grep plugins crawl | View, configure and enable crawl plugins mangle | View, configure and enable mangle plugins audit | View, configure and enable audit plugins
For the purpose of my demonstration, I will focus of the audit plugin. In order to see what options are available with the audit plugin type the following command.
list audit all
For simplicity reasons, I am going to enable all audit plugins.
audit all
Also I want to crawl the target. Type “crawl” and look for “web_spider”.
crawl web_spider
At this point we are just about ready to test our website, but before we do I want to save the output of this scan to both to the Terminal and a HTML file. Go ahead and type “output” and you will notice by default the output to the console is enabled so all that is needed is configure the HTML output.
output html_file
To configure this HTML file type the following.
output config htmlFile
If you wish to make changes then this is the time and place to do so. I will not make any changes here. Now work your way to the w3af main console by entering the appropriate “back” commands. Once there, go ahead and execute the scan.
start
Once the scan has completed its run, go ahead and open the report file. In my case there was a number of vulnerabilities and information blocks returned that provides information that I did not have previously.
Another great use case is the fact that you can script a scan. This is beneficial if you have a development team or responsible group that is tackling the security aspect of your application. This way each individual is running the exact scan in a uniform manner. For example, the following script is based upon the configuration and execution of the commands we covered earlier in this article.
# -------------------------------------- # w3af audit script example # -------------------------------------- plugins #Configure entry point (CRAWLING) scanner crawl web_spider back #Configure vulnerability scanners ##Specify list of AUDIT plugins type to use audit all back #Configure reporting in order to generate an HTML report output console, html_file back #Set target, perform cleanup, run the scan, and exit target set target http://testaspnet.vulnweb.com/ set target_os windows set target_framework asp.net back cleanup start
Diving into the w3af GUI
If the command line is not your thing, then you will most definitely like the GUI.
The GUI is very straight forward and extremely user friendly. Before I get into the GUI, I want to cover the target system that I will scan. What I find is using XAMPP is the quickest way to deploy a web server and database server. Once you have downloaded and installed XAMPP, go ahead and start both Apache and MySQL.
The next step is to grab the Damn Vulnerable Web Application (DVWA) or whatever web application you wish to work with. I selected DVWA because it is very easy and quick to deploy on XAMPP. Unzip the DVWA file to the htdocs folder under the XAMPP folder. Note when you unzip the file you will see DVWA-1.0.8 and for simplicity, I removed the version from my folder under htdocs.
At this point go ahead and enter http://localhost/DVWA into your web browser and follow the installation instructions. Should you encounter an error when creating the database, go to the config folder under DVWA and open config.inc.php and look for the db password as set it to nothing.
$_DVWA[ 'db_password' ] = '';
At this point you are ready to perform your first scan, but before you do you will need to know what the IP address is of your target since you are testing within your own network. Remember, performing a scan on anything not owned by you can land you in legal troubles. My target is the Windows box running XAMPP:
http://192.168.1.130/DWVA/
Since most web applications contain one or more of the vulnerabilities as defined by OWASP, it makes sense to use this profile as my scan criteria. So one you have your profile and target set, go ahead and click the start button. It likely will take so time for the scan to complete so please be patient. Once the scan has completed, go ahead and move over to the Exploit tab, which will list both the exploits and vulnerabilities that were found.
To carry out an exploit all you need to do is either click the desired exploit and any associated vulnerabilities will be shown in bold text. Now all you do is drag and drop the exploit onto one of the vulnerabilities shown in bold. Of course you may also do this in a reverse fashion by first selecting a vulnerability then looking for the exploit indicated in bold.
Conclusion
It is my experience that true application security very often takes a back seat or is forgotten entirely for whatever reason. This of course is bad and very likely will lead to a breach that you may or may not be aware of. It is incumbent upon organizations to bake security into their product and services and I submit to you that we the consumer have much more power than one believes. Use the power of choice and purchase from organizations that take security seriously. Once a company’s bottom line is impact they often then will change their ways.
Getting back to the subject of application security and the need for an attack and audit framework, it becomes very clear why this is important once you look at the numbers. For example, Privacy Rights Clearinghouse reports that 7,366,884 breaches occurred in 2014 and what I found even more disturbing is the fact that 153 breaches were made public. Using w3af may or may not find or detect everything, but it does nonetheless provide capability to harden your application, which in itself is a great thing.
