W3af walkthrough and tutorial

PART 1

w3af (Web Application audit and attack framework) is a framework for auditing and exploitation of web applications. In this series of articles we will be looking at almost all the features that w3af has to offer and discuss how to use them for Web application Penetration testing. In the first part of this series we will be working with w3af console and getting ourselves familiar with the commands. We will also be looking at the different types of plugins that w3af has to offer and discuss how to use them for optimal performance.

Some of the major features of w3af are:

1. It has plugins that communicate with each other. For eg. the discovery plugin in w3af looks for different url’s to test for vulnerabilities and passes it on to the audit plugin which then uses these URL’s to search for vulnerabilities.
2. It removes some of the headaches involved in Manual web application testing through its Fuzzy and Manual request generator feature. It can also be configured to run as a MITM proxy. The requests intercepted can be sent to the request generator and then manual web application testing can be performed using variable parameters.
3. It also has features to exploit the vulnerabilities that it finds.

It is important to understand that no automated web application scanner is perfect and false positives will always occur. With w3af the first and the foremost step is to make sure that we have the latest version. This is very important because w3af developers (Andres Riancho and the w3af team) are constantly fixing bugs and hence it is very important to make sure that we have the most bug free version. To open up w3af console, type in the command as shown in the figure below.

w3af may ask you to update the version. It is advisable to keep updated with the latest version. Ok, so now that we are in the console, type in help to look at the list of available commands.

We can see the list of available options available to us. Type the keys command to look at the various shortcuts keys available to us. I recommend you get familiar with them.

Let’s have a look at the plugins which are available in w3af. Type plugins. You can see the console output change to w3af/plugins. Type back to go back or type help to display the list of available plugins.

To know information about a specific plugins, just type help pluginName. For e.g if i want to know about the discovery plugin, i would type help discovery.

We can see that there are about 9 types of different plugins.

1)Discovery- The discovery plugin helps in finding more Url’s, forms etc to be used for vulnerability scanning. This information is then passed over to the audit plugin. There are a number of different discovery plugins like webSpider, spiderMan, hmap etc. All these plugins have a different function. A user can enable one or more plugins at the same time.

To see the discovery plugins, just type discovery.

To find specific information about a particular plugin, just type pluginType desc pluginname. For e.g if i want to know more information about the spiderMan indexplugin i would write the command discovery desc spiderMan.

One of the important things to note here is that the spiderMan plugin has 2 configurable parameters. To set the configurable parameters, type in the following commands as shown in the figure below. As you can see from the figure below, i have set the listenPort to 55555.

Here are some other commands that could be used.

1) discovery pluginType1, pluginType2 – Selects two plugins.

2) discovery all- Enables all the plugins (not advisable as it may take a long time to finish).

3) discovery !all – Removes all the enabled plugins.

4) list discovery enabled – Lists all the plugins currently enabled.

Here is a screenshot below showing some of these commands in action.

Let’s now run one of the discovery plugins. I will be using the hmap plugin in discovery to know the version of the server running on a remote host. As you can see from the figure below, i have enabled the hmap plugin.

Once this is done, it is now time to give the location of the target server. Type back to navigate back. Then type the following commands as shown in the figure below to set the target. As we can see, the target is set by theset target target-address command.

Once this is done, type back to navigate back and the type start to start the plugin. As we can see, w3af has figured out the version of Apache and php running on my server. We will discuss more features of the discovery plugin later.

2)Audit-Audit plugins are used to detect vulnerabilities in the URL’s or forms provided by the discovery plugins. This is where the interaction between plugins in w3af comes to use. The audit plugin has options for testing different types of vulnerabilities like xss, sqli, csrf etc. It does this by injecting different strings in its request and then looking for a specific value (corresponding to the input string) in the response. False positives may occur during this process. If i want to know how the sqli plugin works, i could type in the commands as shown in the figure below.

Again, i can set the different configuration parameters while selecting a particular plugin. For e.g in the figure below i am increasing the number of checks while performing a XSS audit.

3)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. As you can see in the figure below i have set grep to use the getMails plugin.

4)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. Some of the important things to know about the brute force are the configuration parameters.

It is advisable that you use your own configuration file for the list of usernames and passwords. Also be sure to take a look at some other options. As you can see in the figure below, i have set the option passEqUser to false simply because i don’t think users wouldn’t have their passwords as the same as their username.

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 could make the job much more effective.

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 as i want a very detailed report about the application that i am testing.

6)Mangle – The mangle plugin is used to mangle with request and responses on the fly. It has only one plugin named sed (Stream editor) which is used to modify requests and responses using different regular expressions. The expressions should have a specific format. The usage is quite evident from the description.

As you can see from the figure below, i have set the plugin to look for the string Yahoo and replace it with Google in the request header.

7)Evasion- The evasion plugins uses various techniques to bypass WAF (Web application firewalls). For e.g one of the options rndHexEncode randomly encodes the url in hex format to avoid detection while the plugin fullWidthEncode does a full width encode of the Url to bypass Http content scanning systems using the vulnerability described here.

8)Auth – Last but not the least, auth plugin is one of the most important plugins in w3af. It has only one type called generic. This is because while crawling on a target web application, if w3af hits a login form, then it needs 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 when it hits a login form. We need to specify all the parameters for generic 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://10.0.1.24/dvwa

Conclusion

In this article we discussed about the plugins available in w3af and learnt how to work with the w3af console. In the upcoming articles in this series, we are going to discuss the following topics.

1. Using different profiles
2. Exploiting a vulnerability found by the audit plugin
3. Using the Manual Request and Fuzzy request feature
4. Using the Mitm proxy and the encoder/decoder features
5. w3af scripting
6. Optimizing w3af scans

Please drop a comment if you liked the article or if there is something about w3af that you want to see in the upcoming articles.

References:

• w3af User Guidehttp://w3af.sourceforge.net/documentation/user/w3afUsersGuide.pdf

part 2 

w3af walkthrough and tutorial Discovery and Audit plugins

In the previous article w3af walkthrough and tutorial Part 1 we looked at how to use the w3af console. We also learnt about the different plugins in w3af and how they interact with each other to perform various tasks. In this article we will look at how to use the discovery and audit plugins in w3af to perform a vulnerability scan of the web applications and consequently exploit the vulnerabilities present. We will also look at the various techniques used by w3af to identify these vulnerabilities. In this article we will be working with the w3af GUI version.

Web Security Dojo

One of the first and foremost things while testing w3af is to have a test environment where we can test all the features of w3af. 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. Among the vulnerable web applications is the “w3af Test Environment”. This is the environment used by w3af to perform unit tests. Web Security Dojo also has both w3af console and w3af gui installed on it by default. You can get a copy of Web Security Dojo from here.

Once you have downloaded Web Security Dojo, go to Applications–>Targets–>w3af Test Environment. You will be greeted with a message as shown below.

Please note that even though Web Security Dojo is very useful for performing w3af tests, i would always recommend to use Backtrack 5 for the same purpose. One of the major problems with Web Sec Dojo is that it may not have the latest version of w3af. For e.g in the version of Web Sec Dojo which i have, the auth plugin is not there. You can just copy the w3af test environment folder (present in /var/www/w3af) from Web Sec dojo to your Backtrack machine and you are all set and ready to go. Also, please keep your w3af updated as major bug fixes are done with every new revision.

Audit Plugins

So Let’s go to the Audit section in the w3af test environment. As we can see, the page has different links categorized on the basis of the vulnerabilities.

If we go on the page Cross Site Scripting we see that there are a number of url’s that are vulnerable to Cross Site Scripting.

Hence the next step is to give the url to w3af and scan it for XSS vulnerabilities. Open up w3af GUI. Once it is open, on the left hand side, we can see an option to choose from various profiles.

We can choose any profile from the list depending on our need, as well as the time availability. These profiles already has configurations to use some specific plugins for a particular task. For e.g if we if look the profile OWASP_TOP10, we will see that it uses several of the Audit, Grep and Discovery plugins to perform its tasks.

For the time being, we are going to use an Empty profile as we just want to check a single url for an XSS vulnerability. Note that this is usually not the way in which we will use the w3af framework. In a real world environment, we will choose some specific discovery plugins to find different url’s to check for injections, auth plugins to automatically log in to forms and crawl ahead, grep plugins to look for interesting information in the response, and audit plugins to scan for vulnerabilities in the found injection points.

Type in the url in the target field and choose the xss plugin from the audit plugins.

Once this is done, click on Start. This will start the scan on the given url. As we can see from the output, it found a XSS vulnerability.

If you are interested in knowing what actually happened, go to the Results Tab. Click on xss on the left side. On the right side, you can see a description of how the vulnerability was found. On the bottom right, you can also see the request and response which led to the identification of the vulnerability. It is a very good practice to look at the requests and responses sent through by w3af as this lets us know what’s going on under the hood.

So basically what happened was that w3af sent javascript strings to every parameter in the url, and then checked for those strings in the response. In case of stored XSS, w3af takes a note of the injected string and makes a request again to the url looking for that string. If it finds that string, then a stored XSS has been identified.

Let’s now use an OS commanding vulnerability to obtain a shell on the system. From the OS commanding section in the w3af test environment, choose a url and give it as target to w3af. Under the audit plugins section, check the OS commanding plugin.

Once this is done, click on start to launch the vulnerability scan. As we can see from the output, w3af identified an OS commanding vulnerability.

w3af supports detection of both simple and blind OS commanding vulnerability. In simple OS commanding, it sends a simple command to every parameter and then looks for a response to that command in the output. In case of blind OS commanding in which the response is not present in the output, it uses time delays to identify if a vulnerability is present. For e.g if it sends a command which delays the response for some seconds, and if we note a delay in the output, we can say that a blind OS commanding vulnerability is present.

Again, in the results section, we can see the request and the response which led to identification of the vulnerability.

w3af also allows us to exploit vulnerabilities. If we go under the Exploit section, we can see the identified vulnerability in the Vulnerabilities section. If we click on it, we can see that osCommandignShell in the Exploits section turns black. This is an indication that the vulnerability can be exploited using the osCommandingShell plugin in w3af. Right click on osCommandingShell and click on Exploit ALL vulns.

Once this is done, if the vulnerability is exploited successfully, we will get a shell on the target machine. We can see the list of shells on the right side. Note that it is not possible to get a shell in case of every vulnerability.

Just double click on the shell and you are all set and ready to go.

Similarly, let’s use a file upload vulnerability to get a shell. Give the vulnerable url as a target to w3af. Make sure, the fileUpload plugin is checked in the audit plugins list.

Also make sure to check the extensions option in the fileUpload plugin. Since in some cases, the web application allows only some specific extensions, it would be favorable to add those extensions to the list as well.

Click on Start. As we can see from the output, w3af identified a file Upload vulnerability.

Click on the Results Tab. You can see that w3af tried to upload a file named w3af_dt4LqT.html. It did this by sending the file object in the uploadedfile parameter. It then looked for these files in common directories like uploads etc. If the file is found, then it can be said that a Insecure File Upload vulnerability exists. However, this is not always the case as most of the web application filter files based on their extension. To bypass this w3af has templates for some of the most common file extensions. These templates have valid extensions but have a section that can be replaced with scripting code. The figure below shows the files with different extensions present in w3af.

If we open up any of these files with Kate, we can see the content inside it. As we can see from the figure below, the file template.png has a string of A’s in its comment section. This string can actually be replaced by scripting code like php.

With all of these basics out of the way, let’s exploit this vulnerability using the fileUploadShell plugin. You can also set the configuration of these plugins by right clicking on them and clicking on Configure the plugin.

As we can see from the figure below, the vulnerability was successfully exploited and we got a shell on the target machine.

Similarly you can perform tests for many other exploits like Local File Inclusion, Remote File Inclusion, SQL Injection etc.

The Need of Discovery Plugins

In our previous tests, all we have been doing is giving the specific vulnerable url’s to w3af. However, this is not how real world Web application Vulnerability scanning works. The web application should itself be capable of identifying different url’s in the web application. These url’s will then serve as different injection points for the audit plugin. This is a good example of how the discovery and audit plugins work together with each other, passing along information.

Two of the most popular Discovery plugins are webSpider and SpiderMan. Basically webSpider uses the given input URL, makes a request and extracts any links or forms obtained in the response. Using these links, it crawls on looking for more links (possibly injection points). The other plugin named SpiderMan is also a very useful plugin for sites which uses Flash or Javascript. Basically it is difficult for web crawlers to look for information if the website uses Javascript etc. In actual, most of the web crawlers just ignore Javascript completely. This is because it is not able to figure out what the Javascript code is supposed to do. Most of the web crawlers just look for static information like links, forms etc. In case the webSpider crawler hits a login form, it will enter the credentials automatically if the auth plugin is enabled (and all the options on it are filled correctly) and keep crawling ahead.

In cases where the web application uses Javascript or Flash, the spiderMan plugin should be used. The spiderman plugin starts a proxy, and the user has to navigate through that proxy. Based on the results from the user’s navigation, spiderMan plugin is able to identify different injection points which could be then sent to the different audit plugins for vulnerability scanning. Another important feature of the spiderMan plugin is the ability to save cookies and reuse them. Let’s say we use the spiderMan proxy and login to a form using the browser and receive a cookie. The spiderMan plugin will then send the cookie to the rest of the plugins which can use it to crawl the rest of the application.

Let’s run the webSpider plugin on the w3af test environment. Give the url of the test environment as the target url, make sure only the webSpider plugin is checked inside discovery plugins and click on Start.

We can see from the Log that the webSpider plugin has been able to identify some new url’s. The graph below gives a good idea of the information obtained with time.

As the scan is progressing, go to the Results Tab, click on URLs. As we can see from the figure below, w3af has made a graphical diagram which defines the web application structure. On the left hand side, you can click on the + sign to see detailed information about a particular branch.

Let’s do another example of webSpider plugin. Give the target as the dvwa login page, make sure the WebSpider plugin is checked and click start. In the result, we obtain a graphical structure of the application as shown below.

This, however is not correct. This is because DVWA has a whole list of url’s inside the vulnerabilities folder. However webSpider plugin was not able to crawl to that directory because it required us to enter a login form as shown below.

This is where the spiderMan plugin comes into use. A good idea is to use the SpiderMan and WebSpider plugin in conjunction with each other. This is because the SpiderMan plugin will help us in reaching places where the webSpider crawler cannot go, and the webSpider crawler can them carry on from those places to crawl the rest of the web application.

Let’s do the same test again using the SpiderMan plugin as well. Make sure both SpiderMan and WebSpider plugin are enabled and click on start. Also make sure to check the listen Address and listen port as well.

Once this is done, we need to configure our browser to use the SpiderMan proxy for navigation. If we have to terminate the SpiderMan plugin, we have to browse to a specific url as clearly indicated in the figure below.

Now we need to configure our browser to use the SpiderMan proxy for navigation. In my case, i changed the port number to 44448. It is usually 44444 by default in w3af.

Once this is done, log in to the dvwa application (default credentials: admin/password) and start navigating to different url’s. You can see these requests are noted by the spiderMan plugin as shown in the figure below.

To terminate the spiderMan plugin, browse over to the following url as shown below.

Once this is done, the SpiderMan plugin will terminate and the information will be passed over to the different plugins. As we can see from the figure below, the webSpider plugin has found some new url’s (for e.g http://localhost/dvwa/vulnerabilities/csrf/) to which it was able to crawl to using the information from the spiderMan plugin.

If we look at the structure of the application, we see that it is actually correct as even the vulnerabilities section was identified.

Conclusion

In this article, we looked at the various discovery and audit plugins in w3af, how they communicate with each other and looked at some of the ways of exploiting these vulnerabilities by using the exploit plugins available in w3af.

In the upcoming articles in this series, we are going to look at the following features in w3af.

1. Using different profiles
2. Using the Manual Request and Fuzzy request feature
3. Using the Mitm proxy and the encoder/decoder features
4. w3af scripting
5. Optimizing w3af scans

Please drop a comment if you liked the article or if there is something about w3af that you want to see in the upcoming articles.

References:

• w3af User Guidehttp://w3af.sourceforge.net/documentation/user/w3afUsersGuide.pdf
• w3af-Plugins and descriptionshttp://w3af.sourceforge.net/plugin-descriptions.php

Part 3 w3af walkthrough and tutorial  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 applications 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. Applications 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 example, 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 an 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 onStart 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 parameter 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. There 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/

   part 4 w3af walkthrough and tutorial w3af tools, profiles and scripting

  This is part 4 in a series.
  Part 1 w3af Tutorial Part 1
  Part 2 Discovery and Audit plugins
  Part 3 : Remaining plugins

  In the previous articles in this series, we looked at all the plugins available in w3af and looked at their applications in different scenarios. In this article, we will look at some of the other tools present in w3af which allow us to send Manual Requests, perform Fuzzing, Encode and Decode requests and responses, use a Proxy to intercept and modify requests and responses, and allow us to perform a comparison between different HTTP requests and responses. We will also look at how we can write our own w3af scripts to automate the task of Web Application Penetration Testing. We will then look at the various profiles present in w3af.

  1) Manual Request -The Manual Request feature in w3af allows us to send specially crafted requests and then analyze the response. This technique could be used in various cases which include testing for SQL Injection, Cross Site Scripting, etc. The tools present in w3af can be found by clicking on the Tools menu as shown in the figure below. Click on Manual Request to open up the Manual Request editor tool.

  
  

  Once this is done, you can write your own manual request and send it to analyze the response. As you can see from the figure below, I am making a simple GET request to http://google.com . Also, you might want to change the User-Agent field, as this gives away the fact that the request is coming from w3af.

  
  

  Click on Send Request to send the request. Once this is done, the response will be displayed. You can then simply analyze the response or send it to other w3af tools.

  
  

  It is also possible to send requests to the Manual Request Editor from the results of scans by clicking on its corresponding button below the request/response as shown in the figure below. Same applies to all of the other tools like Encoder/Decoder, Fuzzy Request editor, Export Requests etc.

  
  

  2) Fuzzy Request - The Fuzzy Request feature present in w3af allows us to send different requests with varying data and analyze the responses.

  
  

  The fuzzy request editor is shown in the figure above. The varying text is added between the dollar sign ($). It is clear from the figure above that the varying data is determined by the syntax “$xrange(10)$” which includes numbers from 0 to 9. In case two such text generators are present, then the requests will be combined. For example, if one of the generators generates 5 values; whereas, the other generator generates 6 values, then the total number of requests that will be sent will be 30. Some of the common syntax used to generate variable text is shown in the figure below from w3af GUI.

  
  

  Once we have written the generators, we can simply click on Analyze to analyze the requests that will be generated during the fuzzing test. This is useful because it allows you to actually see these requests before sending them.

  
  

  Click on the play button in the bottom left to send the requests. Once the requests have been sent, you can analyze the responses by clicking on the Response tab.

  
  

  Once the responses are received, you can separate these responses into different clusters. There are different clustering methods present in w3af which have different ways of determining the distance between these HTTP responses. Using these responses, different clusters are created and the responses with the minimum difference between them are added to the same cluster. This is a quick way to determine which response stands out as different from the other responses which is an important step in Fuzzing.

  The figure below shows the cluster created by using the method Levenshtein distance of the HTTP bodies. w3af also allows you to write a customized clustering method to perform the task. It is also possible to send requests to the Fuzzy Request generator from the results of scans.

  
  

  3) Encode/Decode - The Encode/Decode tool in w3af is used to encode or decode strings, urls etc. You can choose from a variety of encoding and decoding options. The figure below shows a base64 encoded string being decoded by the w3af decode tool.

  
  

  4) Export Requests - The Export Requests tools allow us to generate code in different languages which when ran will regenerate the request. In the figure below, I am generating some code in Python, which when ran will regenerate the original request. The Export Requests tool allows you to generate code in HTML, Ajax, Python and Ruby.

  
  

  5) Compare - The Compare tool is used to perform comparison between 2 requests/responses. As shown in the figure below, I have sent the comparer tool 2 responses for 2 different requests. The difference between these responses is highlighted by the comparer tool.

  
  

  6) Proxy - w3af also comes with an intercepting proxy that allows us to intercept requests, and modify them on the fly. To use this proxy, we have to configure our browser to use this proxy. In case of real world web application testing, it is important that we intercept only those requests that we want. The figure below shows the configuration for the proxy. We can see that it is running on port 8080. We have also configured the proxy to not trap requests for certain images, css, swf files etc.

  
  

  Let’s configure our browse to route traffic through this proxy.

  
  

  
  

  
  

  Once this is done, start browsing through your browser. You will see the requests and the responses appearing in the History tab as shown in the figure below. Right now the requests and responses are being passed through the proxy without interception.

  
  

  
  

  
  

  As discussed before in this article, you can send the requests/responses to the other tools like Manual Request editor, Fuzzy Request editor etc present in w3af. Click on the arrow pointing downwards on the top left to start intercepting the requests. If you browse through the proxy now, you will notice that the requests are being intercepted by the proxy as shown in the figure below.

  
  

  You can simply Drop the request so that it doesn’t reach its destination, forward it as it was or modify the request and then forward it. For example, in the intercepted request shown in the figure below, we can see that the search query was w3af. We can easily change it to whatever search query we want it to be. Some of the other uses of w3af proxy could be finding out the parameter names through which the authentication credentials are sent in a login submission.

  
  

  
  

  
  

  w3af scripting

  Many times we have to perform scans on different websites with the same set of plugins and the same configurations. However, for every new scan (or every new profile), we have to select the plugins and configure the options each time. This process could be time consuming. w3af scripting makes this very easy for us. We can write our own w3af scripts to automate the task of selecting the plugins, and performing the scan on different websites. w3af scripts end with the extension “.w3af”. We write a set of w3af console commands in the file. Once the script is run, each w3af console command will get executed in each line in the same order as they were written in the file. This is just the same way we would be using the w3af console. If we want to perform the scan on a different website with the same set of plugins, we can just change the target in the script. One other thing about running w3af scripts is that you can add your own commands once the script has run and made its changes. For example, if I want to perform a scan with the same set of plugins and options on different websites I can just write a script which sets the plugins and the configurations without setting the target. Once the script has run, we can enter the target ourselves and then run the scan.

  Let’s start by writing a simple script to demonstrate the use of w3af scripts. In the figure below, I am writing a script that sets some plugins for a vulnerability scan. As it is clear from the figure below, I am using the webSpider discovery plugin, the xss and sqli audit plugins and the getMails grep plugin.

  
  

  
  

  
  

  Once this is done, we save the file as simple-config.w3af. To run the script we just have to use the command “./w3af_console -s simple-config.w3af”.

  
  

  We can see the output in the figure below. Once this is done, we can simply set the target ourselves and start the scan. Hence, having prewritten w3af scripts for different kinds of scans can save us a lot of time.

  
  

  The following figure below shows another example of a w3af script which when run enables some plugins and starts the scan against the specified target.

  
  

  
  

  
  

  w3af profiles

  A w3af profile can be defined as a profile with preconfigured plugins made for a specific scenario keeping the resources and time availability in mind. We can also create our own w3af profile. However, w3af offers some of its own set of profiles which we can use in our scan as shown in the figure below.

  
  

  
  

  Let’s discuss all these profiles in brief.

  1) OWASP_TOP10- This profile searches the target web application for the ten most common security vulnerabilities defined by OWASP.

  2) audit_high_risk- This profile searches the target web application for high risk vulnerabilities like OS commanding, etc., which can later be used to fully compromise the web application.

  3) bruteforce- This profile can be used to perfom a bruteforce attack on the web application.

  4) fast_scan- This profile is used to perform a fast scan of the target web application. It uses only the webSpider plugin for discovery, as enabling a large number of discovery plugins can take a long time.

  5) full_audit- This profile performs a full audit of the web application. It has almost all the audit, bruteforce and grep plugins enabled. Like the fast_scan profile, this also uses the webSpider plugin for discovery.

  6) full_audit_manual_disc - This profile is very similar to the full_audit profile, except that it also uses the SpiderMan plugin to perform manual discovery on the target web application. The SpiderMan and the webSpider plugins communicate with each other to find as much information as possible about the web application.

  7) sitemap- This profile uses different discovery plugins like robotsReader, yahooSiteExplorer etc to create a sitemap of the target application.

  8) web_infrastructure- This profile uses some of the discovery plugins like fingerprint_os, hmap, serverHeader etc to fingerprint the web application.

  
  

  Conclusion

  In this article we looked at the various tools like Proxy, Manual Request editor, etc. that w3af has to offer to help us perform web application vulnerability assessment and penetration testing. We then looked at how we can write our own w3af scripts to help automate the task of web application testing. Finally, we then looked at all the different preconfigured profiles that w3af has to offer and discussed their applications in different scenarios.

  This article is the final article in the “w3af walkthrough and tutorial” series. Please drop a comment if you liked this series or if you have any questions regarding this series.

  
  

  References

  • w3af User Guide
    http://w3af.sourceforge.net/documentation/user/w3afUsersGuide.pdf
  • w3af-Plugins and descriptions
    http://w3af.sourceforge.net/plugin-descriptions.php