w3af walkthrough and tutorial part 3 - Remaining plugins
In the previous article w3af walkthrough and tutorial part 2 - Discovery and Audit plugins we looked at the various discovery and audit plugins used by w3af to identify vulnerabilities in a web application. We also looked at how we can exploit these vulnerabilities by using the exploit plugins present in w3af. In this article, we will look at the remaining plugins present in w3af which are bruteforce, grep, mangle, output, auth and evasion plugins and look at their applications in web application penetration testing.
We will still be using the same test environment which we used in part 2, which is the “w3af test environment” present in Web Security Dojo. Web Security Dojo is a vulnerable VM which has some vulnerable web applications as well as the tools needed to break into these web applications. It has both the console and the GUI versions of w3af. You can get a copy of Web Security Dojo from here.
1)Brute force - Brute force plugins can be used to brute force login forms as well as http-auth logins. Once the discovery plugin finds any form with form based input or an http-auth input it will automatically launch the brute force attack against it if the corresponding brute force plugin is enabled. However, brute force plugins can be run as a seperate plugin themselves and can be used to carry out targeted attacks against a particular url with login forms. Some of the important things to set while running the brute force plugins are the configuration parameters. Brute force attacks take a long time and hence it is important to configure the options to maximize the efficiency with the minimum time.
It is advisable that you use your own list of files for the list of usernames and passwords. However w3af has its own set of files containing usernames and passwords. Also be sure to take a look at some of the other options. The useProfiling options uses the list of passwords generated by the passwordProfiling plugin. The passwordProfiling plugin is one of the grep plugins which generates a list of possible passwords by reading the responses and counting the most common words. The profilingNumber option indicates the number of passwords from the result of the passwordProfiling plugin to use for the bruteforce attack. The useLeetPasswd option uses leet passwords also for the attack. An example of a Leet password would be l33t (for the password leet).One of the other good configurable parameter is the useMails option. This options uses the email addresses that w3af finds (maybe through the grep plugin) to be one of the inputs for the username field. For e.g if one of the usernames is example@infosecinstitute.com, then the username tried would be example. This is another example of how the interaction between the different plugins in w3af could make the job much more effective.
In this case, we will be going ahead and carrying out a bruteforce attack on the login form as shown in the figure below.
Let’s go ahead and give the url of the login form as a target to w3af. Also make sure that the formAuthBrute plugin is selected and configure the parameters according to your need. Once this is done, click on start to launch the attack
. 
As you can clearly see from the output, w3af found the username and password as admin/1234.
However, this is not always the case with every brute force attack. w3af and many other tools gives false positives on brute force attacks. Different tools have different ways to determine whether an attack has been successful or not. Some of the tools look for particular strings like “successful” or “logged in” etc to determine whether the attack has been successful or not. While some tools look for the response codes to determine whether the response was successful or not. This often leads to false positives because some application return the HTTP Status Code 200 with successful as well as unsuccessful login requests. Some tools identify the status code 200 as a metric for successful authentication and hence return false positives. Application which have the minimal difference in response between a successful or an unsuccessful login are likely to give away false positives when a tool is run against them. For e.g when the application DVWA (Damm Vulnerable web application) is configured on Security Level “High”, it just returns the response with a different length value for a successful login than for an unsuccessful login as shown in the figure below. (test perfomed by using BurpSuite)
Even the response codes are same in this case for both successful or unsuccessful logins. Hence it is often not advisable to look at what the tool says about a successful attack. Rather we should look at the response for different scenarios and see how they differ from each other. We will discuss these things in more detail later in this series.
2)Grep-The grep plugin is used to find interesting information in the requests and responses going through like email accounts, forms with file upload capabilities, hashes, credit card numbers, email addresses etc. You can set the type of information you want to look for by setting the appropriate plugin. Since the grep plugin only analyzes the request and response, it is important to have some kind of discovery plugin enabled for it to work. Otherwise grep plugins are of no use. The information obtained by the grep plugins can be used by other plugins, for e.g the information obtained by the passwordProfiling plugin is used by the bruteForce plugin.
Let’s run a simple test for the grep plugin. From the test environment, we give a url to w3af which has a credit card number in it as shown in the figure below. From the grep plugins list, make sure that the creditCards plugin is selected. Once this is done, click on Start to start the scan.
As we can see from the figure below, w3af found the credit card number present in the page. Let’s discuss some of the most important grep plugins.
a)Code Disclosure- This plugins checks the page for code disclosure vulnerabilities. It does this by looking for the expressions and <%.*%> which could reveal server side code like php etc. The test result from the figure below shows a code disclosure vulnerability found.
However, it is important to check whether the result is a false positive or not. As recommended in the previous articles in this series, it is always good to analyze the requests and responses which actually lead to the identification of that particular vulnerability. As we can see from the figure below, there is indeed a code disclosure vulnerability.
b)DOM Based XSS-The DOM based XSS plugin helps find XSS vulnerabilities. This occurs when a user input is used to output the data in the DOM. As we can see from the code of the page below, it looks for a parameter name, and then outputs that value in the DOM. However, from the code we can see that the paramter value is not being validated. Hence this is vulnerable to DOM Based XSS.
When we select this plugin and run a test against it, we see that w3af is able to find the DOM based XSS vulnerability.
Again, it is important to check the request and response for the corresponding vulnerability and figure out if it was a false positive or not.
c)findComments- The findComments plugin is used to check the response for interesting comments. For e.g a string containing the word “password” would be tagged as interesting and would be reported.
d)getMails-This is one of the most important grep plugins. It looks for email addresses in every page. This information could then be used by the brute force plugins. Collecting emails form an important part of the information gathering stage during a penetration test.
e)fileUpload-This plugin checks every page for file upload capabilities so that it can be further checked for fileUpload vulnerabilities. The figure below shows the result of running the fileUpload plugin against a page which contains a file upload capability.
3)Evasion- Evasion plugins are used to modify requests in order to bypass any WAF or IPS etc. It does this by modifying requests in unique ways so that the signature is not detected by Intrusion Prevention Systems. I contacted Andres Riancho (the original author of w3af), and he had this to say about Evasion plugins.
“In evasion plugins I would also recommend only enabling one at the time and only doing so if you really know what you’re doing as it may break the scan and make it unstable”
Let’s see some of the Evasion plugins and see how they work.
a)backSpaceBetweenDots - This plugin is used to bypass the filters for the character ”..”. It does this by adding a character after a dot (.) and then adding a backspace character (%08) after it. Hence he character after the dot and the backspace character cancel each other thereby leaving only ”..” . This plugin could be used while performing Local File Inclusion or Remote file Inclusion attacks.
b)ShiftOutShiftInBetweenDots - This plugin works similar to the backSpaceBetweenDots plugin and is used to bypass filters for ”..”. It just uses shift-in (%0E) and shift-out (%0F) characters which cancel each other out.
c)rndHexEncode - This plugin adds random hex encoding in the url thereby making it difficult for different WAF or IPS.
4)Mangle - This plugin is used to modify request and responses on the fly using regular expressions. There are 3 configurable parameters, Expressions, fixContentLen and priority. In the expression option, we specify the expression which determines the rules by which the request or response will be changed. The figure below from w3af gui shows 2 examples of using Stream editing expression.
As shown in the figure below, i have configured w3af to look for the expression Google in the response body and replace it with the string Poogle.
5)Output-The output plugin helps us decide the format in which we want the output. w3af supports many formats like console, emailReport, html, xml, text etc. Again you can set various parameters here like the filename, verbosity etc. In the figure below, i have set verbose to True in the htmlFile plugin as i want a very detailed report about the application that i am testing.
6)Auth -Last but not the least, the auth plugin is one of the most important plugins in w3af. It is present only in newer versions of w3af. Hence, it is important to keep updated with the latest versions of w3af as a lot of bug fixes and performance enhancements are done with each release. Their is only one plugin named generic in auth plugins list. The main use of auth plugin comes in when w3af hits a login form while crawling a web application. Being a good scanner, it should be able to submit the credentials automatically in order to continue looking for information. By using this plugin, we can specify a predefined username/password that w3af should enter itself whenever it hits a login form. We need to specify all the parameters for the generic plugin in order for it to work successfully.
In the figure below i am setting options for w3af to successfully log in to DVWA (Damn vulnerable web application) which is located on the address http://127.0.0.1/dvwa
Conclusion
In this article, we looked at some of the plugins in w3af like bruteForce, Mangle, Grep, Evasion and Auth and looked at how they aid us in the process of Web Application Penetration Testing. In the fourth and final part of this series, we will look at the various tools in w3af like Manual Request editor, Encoder, Decoder, Mitm-Proxy etc. We will also look at a topic called w3af scripting through which it is possible to write w3af scripts which can perform the scans for us.
Please drop a comment if you liked the article or if there is something about w3af that you want to see in the upcoming article.
References:
-
w3af User Guide
http://w3af.sourceforge.net/documentation/user/w3afUsersGuide.pdf -
w3af-Plugins and descriptions
http://w3af.sourceforge.net/plugin-descriptions.php -
w3af Walkthrough and Tutorial Part 1
http://resources.infosecinstitute.com/w3af-tutorial/
This article was originally published on the resources page at Infosec Institute. For more information, please visit my author page.