“Performing penetration testing needs not only proper skills but also an efficiently effective approach that leads to results in the realm of our responsibilities. Fuzzing is one of the most important techniques by which a pen-tester can surface the web application vulnerabilities with less effort.”
In my consulting experience, it happened so many times I have come across a situation where I had limited time slot to perform a penetration testing of an application and that time I realizes that performing penetration testing needs not only proper knowledge and skills but also an efficiently effective approach that leads to results in the realm of our responsibilities. Fuzzing is one of those techniques by which a pen-tester can surface the web application vulnerabilities with less effort. In this article I have tried to cover below important aspects of fuzzing:
- Fuzzing basics
- How fuzzer works
- Factors influencing the fuzzing results
- Points to remember while selecting or developing an open source fuzzer
Fuzzing Basic
In software testing fuzzing is basically called as technique to send a combination of random values to the server and observe how server respond to those random inputs. In application penetration testing there are two types of fuzzing prevalent today one is black box fuzzing and other is white box fuzzing. In former technique one throws random data to the server without having consideration of protocol specifications and data structure but this technique cover least amount of code and discover less vulnerability. While in white box fuzzing a pentester considers the data structure and protocol specifications, the fuzz data is only the variations of these data structure so it is very important to understand the selection of input elements while using white box testing. There are two main points one has to keep in mind while throwing the random data to the server through fuzzer; first, your selection of input elements should have to be valid enough to be processed by the server and second; fuzz data should have to be invalid enough that can make sever respond in an inappropriate way. In general before using any fuzzer for white box fuzzing one has to understand the framework of the protocol to make sure fuzz template does not breaching the protocol specifications and one can use RFC for this purpose.
How a fuzzer works
To understand the high level structure of a fuzzer we need to list out our basic requirement of a fuzzer. At first we require a template generator that can generate a fuzz template to be used for fuzzing a particular protocol then we need a base request that will be used by the template generator to generate our fuzz template and finally we need a random inputs i.e. fuzz data to create a fuzz request. Now we are in position to sketch a primary structure of a fuzzer by establishing a logical relationship between our requirements and the same has been shown in the Figure 1.
Figure 1
While doing the penetration testing of an application the simple way of getting a base request if to use web proxy tool. If you have good understanding of the protocol then you can construct the fuzz template for a particular request and then you can use fuzz inputs or attack patterns one by one to create a fuzz request but this is a tedious task and prone to error so the better way is to use the available framework that can do this task for you in a much easier way.
In the traditional approach, one can use web proxy to intercept the requests and manually edit the capture request to create a fuzz template. An attack pattern is supplied to the Input parameter(s) to create a fuzz request that is sent to sever and the received response is analyzed manually for possible vulnerability. If first attack pattern fails and does not gives any vulnerability then we again change the attack pattern and the same process continues till the issue is detected or all attack patterns is used. Let’s imagine a scenario where request has lots of input parameters and application itself is large then one would end up spending lot of time to detect only most obvious vulnerabilities.
To overcome with all such issues I would suggest using a framework or tool that supports not only capturing the base request and generating the fuzz template but also automate the attack pattern feeding in the input parameters one by one from the source of inputs supplied to it. OWASP WebScarab is one of such framework widely used by the pentesters that fulfills all such requirements; it can collect the base request and in few clicks one can generate a fuzz template; Just select the conversation having the parameters from the summary section and then right click on that conversation and select “use as Fuzz template”. Then one can provide the fuzz source that is basically the list of alternative inputs i.e. attack patterns to be used as value of selected input elements.
Similarly OWASP ZAP is another open source alternative for application security professionals. It has all fuzzing capabilities which a pentester requires during the application penetration testing.
Factors influencing the fuzzing results
There are open source fuzzers available in the internet and in next part I’ll explain what one should keep in mind while selecting a fuzzer but as of now let’s suppose we have selected one general purpose fuzzer to perform a penetration testing but is that enough to get our desired results? Answer is no, apart from selection of good fuzzer; a right approach is also necessary to get maximum advantage of fuzzing technique.
Once you select the target elements to be fuzzed then the probability of finding vulnerabilities is influenced by various factors and fuzz input selection is one of the most important factors of it. One good approach to select your fuzz data is to use the attack patterns already discovered in conjunction with attack pattern you have written after your initial understanding of the application. For example, if you want to use fuzzer for Cross Site Scripting then XSS cheat sheet is a good resource to prepare a list of already discovered attack pattern but it is important to remember that it can increase the probability of finding vulnerability but does not gives you guarantee, so it’s better to have initial understanding of target application and then customize your fuzz list with already discovered attack patterns.
Secondly, lack of effective response analysis also makes a big difference in final results. In the list of hundreds of response there are possibilities that one can miss the valuable information that may be lead to vulnerability. If you know the probable response of fuzz value that can lead to vulnerability then it’s better to make a database and use the match case logic to analyze the response, it won’t only help you to find the issues effectively but also it will save your time of analyzing the most obvious vulnerabilities and essentially you will put your actual effort on finding out less obvious vulnerabilities.
Figure 2 shows an example to find out most obvious reflected cross site scripting issues using a fuzzer. In this picture source of inputs is being integrated with the fuzzer to create a fuzz request and application response is matched with the same input source to detect the cross site scripting issues.
Figure 2
One can automate the response analysis using Webscarab script manager plugin.
In next part I'll cover the "Points to remember while selecting open source fuzzer".
