Penetration testing is more than just running automated tools and redoing the same manual testing workflow. It is about analyzing the target, understanding how it is built and coming up with unique attack scenarios.
When you are testing a web application of even moderate size then the amount of pages, parameters and values travelling between the browser and the server can become overwhelming even for seasoned testers. Finding patterns or mapping connections in a maze of data is not a trivial task.
Another problem arises when you have to do a technically simple check repeatedly for a large number of times. For example, chec-king for CSRF vulne-rabilities across the site is a very simple but time consuming and I must say also a very boring process. The same is true for privilege escalation checks, hidden parameter guessing etc. When a part of the test is boring and time consuming then testers usually tend to skip it or not do proper justice to it. Needless to say this can turn out to be very dangerous for the site’s security.
HAWAS is a tool designed to help testers in these areas. It will help perform automatic analysis of the site and provide data in an easily consumable form so that you can identify patterns and map connections. It also helps automate tests for CSRF, Privilege Escalation, Access Control and Hidden Parameter Guessing, these tests would otherwise take up a lot of manual effort and time.
HAWAS is built as a Module for IronWASP and is bundled along with it. To use HAWAS you must first start IronWASP, configure your browser to use IronWASP as the proxy and then browse through the target site. This way IronWASP will collect all the site information in its proxy logs. Once the entire site is covered you can launch HAWAS from the ‘Modules’ menu, it will be available under the ‘Analysis’ category.
Figure 1 – Launching HAWAS from the Modules menu
Once HAWAS is started up, just click on the ‘Start Analysis’ button, this will start the analysis of the data collected in the Proxy Logs. Depending on the size of the log this analysis could take anywhere from a minute to a significantly longer time. Once the analysis is complete click on the ‘Show Results’ button.
Figure 2 – HAWAS has been launched, click ‘Start Analysis’ to begin
Figure 3 – HAWAS is analyzing the Proxy logs
Figure 4 – Analysis is done, click on ‘Show Results’ to view the results
The results section has multiple tabs, let’s look at them one by one.
Parameter Names and Values
The first tab lists information about all the parameter names and values discovered in the logs. This information is categorized by hostname. The list of hostnames found in the log are shown on the left-side of this tab. When you click on a hostname you can see the list of all parameter names found in the logs related to that hostname. When you click on any of the parameter names you can see the sections in which this parameter was found, E.g. Query, Cookie etc. When you click on a particular section you can see the list of all the values this parameter had when it occurred in the selected section.
This section is of great important as it lists all the information about the site in one single location, in an easily analyzable way.
Let’s look at some scenarios where this can come in handy.
In the list of parameters if you see a parameter named ‘is_admin’ then you will immediately agree that this is worth exploring. Maybe this parameter is used to decide if you must be shown the admin page or not, you could try manipulating this parameter manually and probe further. If this parameter appeared only once in the entire site then without HAWAS it is very likely that you could have missed this.
Let’s say there is a parameter named ‘SessionId’ and this parameter contains the session id for the application. When you click on this parameter name HAWAS will tell you which sections this parameter occurred in. If it only occurs in Cookie then its fine but if it occurs in Query as well then you have a problem because passing Session id over Urls is not safe. Out of a 1000 pages the application might have sent the session id over url in just one page but HAWAS still picks it up and makes this very obvious to you. Without HAWAS this could have most likely been lost in the noise.
When you look at the list of all parameter values you might pick up some interesting leads. For example if there is a parameter value that looks like “http://example.org/info.php” then you know that this parameter needs to be tested for Open Redirect and Remote File Include vulnerabilities. Similarly if you see a parameter value like “./lib/report.php” then this is a candidate for Local File Include testing. Sometimes you might miss noticing these items when you are crawling through the site but with HAWAS you would always notice these interesting patterns.
Figure 5 – Click on Hostname to view Parameters, click on a Parameter to view Sections, click on a Section to view Values, click on a Value to view details about the Value
Encoded Parameter Values
Sometimes web applications transmit values in encoded form. The encoded value might look harmless or might look like junk but when decoded could actually be holding something sensitive. Hex and Base64 are the most commonly used encoding schemes in web applications. When there are thousands of parameters in an application it is practically impossible for a tester to determine which ones look like encoded values. HAWAS performs this task automatically. It tries to Hex and Base64 decode every single parameter value, if the result of decoding is a proper ASCII string then this is added to this section.
The left-side of this tab contains the list of all hostnames that contain encoded parameter values. If you click on any of the hostnames then the encoded value, the type of encoding and the decoded values are displayed. HAWAS makes it almost impossible to miss these types of encoding in the application (Fig. 6).
Figure 6 – Click on Hostname to view list of Encoded values, click on an Encoded Value to view details
Hashed Parameter Values
Like the use of encoding sometimes applications might transmit hashed values. What could be even more interesting is often these hashed values are created from some other parameter values within the same application. For example when a user logs in with a username and password then the password might be hashed and this hashed value might be passed around in other sections of the application in some other parameter. Identifying this manually is a very difficult task but HAWAS automates this entire process.
First it identifies all parameter values that look like MD5, SHA1, SHA256, SHA384 or SHA512 hashes. Then it uses the list of all parameter values belonging to that host as a dictionary list and tries to crack these hashes. The results are shown to the user in this section. The left-side of this tab lists all the hostnames where parameters containing hashed values were discovered. When you click on the hostname then the hashed value and the type of hash are displayed. If HAWAS was able to crack this hash then the cracked value is also displayed (Fig. 7).
Figure 7 – Click on Hostname to view list of Hashed values, click on a Hashed Value to view details
Stored XSS Candidates:
Stored XSS are difficult to detect because in a big application it is very hard to find out which parameter values are stored on the server-side and reflected back at a later stage. Manually finding out this pattern is an uphill task however HAWAS makes this task easy for you.
HAWAS stores every single request parameter value found in the log in memory and then checks if any of the responses have this same value embedded in them. Let’s say Response B was found to have a parameter value that originally found in Request A then HAWAS checks if Request B also had the same parameter value. If Request B did not have this value then it is very likely that this value was sent by Request A, saved on the server-side and then reflected back in Response B. This would make it an ideal candidate for Stored XSS testing. HAWAS identifies all such instances and shows them in this section (Fig. 8)
Figure 8 – Click on Hostname to view list of Stored Reflections, click on a Stored Reflection to view details
This section was originally supposed to be implemented within the HAWAS UI itself but to provide a better experience this was instead added as a core component of IronWASP.
This section provides a single area from which you can automate the testing for CSRF, Privilege Escalation, Access Control and Hidden Parameter Guessing vulnerabilities.
Though these four vulnerabilities are very different the testing methodology for them is more or less similar. For the sake of those unfamiliar let me briefly explain these vulnerabilities and how to test for them. For detailed explanation on these issues please refer to the OWASP portal.
If an application does not send a CSRF token or if it does not properly validate a CSRF token when performing an important action then it is vulnerable to CSRF.
You test for this issue by picking a request that already has this token then you resend this request after deleting this token or editing it with some junk value. You compare this response with the response of the original request. If both are same then it means the application is not properly validating the token. If the responses are different then it indicates that the application had rejected this request due to an invalid CSRF token, you can confirm this by analysis exactly which section of the two responses are different.
If an application allows a low privileged user to access sections of the site and perform actions that are only meant for high privileged users then it is vulnerable to Privilege Escalation attack.
To test for it you first browser through the site as a high privileged user and then you resend the same requests but this time you set the session id as the session id of the low privileged user. If the response is similar then it means the low privileged user is able to access the same section and the application is vulnerable. If the responses are different then probably the application rejected the request of low privilege user, you can confirm this by analyzing the differences between both the responses.
Some sections of the site are only meant to be accessed after the user is logged in. But if the application allows even unauthenticated users to access some of these pages then it has Access Control issues.
To test for it you first browser through the site as an authenticated user and then you resend the same requests but this time you either remove the session id or replace it with an unauthenticated session id. If the response is similar then it means the unauthenticated user is able to access the authenticated section and the application is vulnerable. If the responses are different then probably the application rejected the request of unauthenticated user, you can confirm this by analyzing the differences between both the responses.
Hidden Parameter Guessing:
Sometimes applications have hidden backdoors because of which you might be able to access hidden functionality by adding a special parameter and value. For example if you add a new parameter ‘admin=1’ to the url then you might be able to access administrative functions of the site.
To test for it you first browser through the site normally and then you resend the same requests but this time you add a new parameter name and value, like ‘admin=true’. If the response is similar then it means the added parameter did not have any effect on the application. If the responses are different then probably the application exposed some new functionality based on this parameter, you can confirm this by analyzing the differences between both the responses.
Automating these Tests:
By now you would have seen the common pattern in these tests. In all of them we edit, delete or add a parameter in the request, send it to the server and compare the new response with the old response. And based on the results of this comparison we determine if there is vulnerability or not.
To automate these steps you must go to the Logs section of IronWASP. At the top-right corner of this section you can see a button named ‘Search and Analyze Logs’, clicking this button would launch the Log Analyzer. Here you can set a filter and search the logs. When the search results are displayed you can either select all the logs from the results or select only the logs you are interested in testing. After selecting, click on the ‘Test Selected Sessions’ button, this will launch the Log Tester.
Figure 9 – Click on ‘Search and Analyze Logs’ to launch the Log Analysis utility
Figure 10 – Specify a log filter (File Extensions to ignore and Response Codes to include are selected here) and click on ‘Search with this Filter’
Figure 11 – Select the logs to test from the search results and click on ‘Test Selected Session’. To individually select a log entry first set the ‘Click Action’ value to ‘Select Log’ from the default value of ‘Display Log’
The Log Tester will show a wizard where you are given three test options:
- New Parameter Addition Test
- Edit Existing Parameter Test
- Delete Existing Parameter Test
The names of the test are self-explanatory, once you select one these tests and click ‘Next’ you will asked to enter the details of the parameter. You must mention if it is a Query, Body, Cookie or Header parameter. After mention the type of the parameter you must mention the name of the parameter. If you selected ‘New Parameter Addition’ or ‘Edit Existing Parameter’ options then you would be asked to enter the value of the parameter also.
Figure 12 – Test Options shown, select one and click ‘Next Step ->’
Figure 13 – Enter the details of the Parameter that must be manipulated and click on ‘Start Test’
Once this is done you can click ‘Start Test’. Now IronWASP will send each of the selected requests once without making any changes, this is called as Resent Request. After this the parameter manipulation you selected will be made, be it adding a new parameter, editing an existing parameter or deleting a parameter. The edited request will be sent to the server, this is called as the Test Request.
After sending these requests and getting the responses, the response details are shown to you. The results UI shows the response status code and length of the original response from the log, the status code and length of the resent response, the status code and length of the test response.
Apart from these values IronWASP also does a diff of all the three responses and shows the percentage of difference between them. 0% means that the responses are the same and 100% means the responses are completely different. By looking at this information you can immediately determine if the parameter manipulation had any effect. If it looks like there was some effect you can explore it more by clicking on one of the entries, this will display the original request/response, resent request/response, test request/response and the detailed diff of these requests and responses. From one single place you can analyze and find out what where the exact differences between the responses and based on that determine if the vulnerability actually exists.
Figure 14 – Test Results are displayed. Click on any of the result item to view more details about it
This feature can help reduce your testing time for these tests from days to mere minutes! It can also handle complex scenarios where while testing for CSRF you would have to maintain the session. For example during the test you want to constantly check if the user is logged in to the application and perform a login if user is logged out. To handle this you can make use of the Session Plugin support built-in. When you are creating a test you will asked if you want to make use of this feature, if you choose to use it then a GUI based assistant will get the details from you and create a Session Plugin and then handle authentication or any other customization.
By making use of these features you can hugely increase your test coverage while simultaneously reducing your testing time, so don’t forget to reap the benefits of HAWAS in your next pentest.