In this article, we are going to see another powerful framework that is used widely in pen-testing. Burp suite is an integration of various tools put together to work in an effective manner to help the pen-tester in the entire testing process, from the mapping phase to identifying vulnerabilities and exploiting the same.
In the figure above, we see the various features of this tool, like proxy, spider, intruder, repeater, sequencer, decoder and comparer. As we move ahead in the tutorial, we shall learn how to make use of them seamlessly.
This lets you intercept the traffic between the browser and target application. This option works like the man-in-the-middle attack vector. Below I shall show you one of my favorite examples in demonstrating this feature.
Here, we are seeing a Wikipedia login form (dummyuser:dummypassword) and we shall see how the intercept is put. Initially we need to switch the intercept mode ON, in the suite. The FORWARD option allows you to send the packets coming from the source IP to the destination IP. The DROP option allows you to drop the packet if you feel it’s not a potential packet that needs analysis.
In this figure, we see that the login credentials of en.wikipedia.org are being captured. The point here to note is that Wikipedia uses HTTP instead of HTTPs and thus, the login credentials are captured in clear text.
The burp proxy listener is enabled on Port 8080 of the local host. There are various options for intercept set-up, like request methods, matching file extensions, and URL scope for the client requests. Other options like request type, content types, and URL scope in the server responses are available to be set-up based on the attack scenario.
I have used Mozilla Firefox here. The same holds for any other browser.
The following steps can be many from this phase. The capture can be dropped, or sent to spider, sequencer, comparer etc. There is an option of changing the request methods from GET to POST and so on.
Burp-site Map and Site Scope
In this section, we are seeing the Burp site maps and site scopes. This section shows us the various sections of a particular domain. Here, we can choose the scope of our security testing. We see a huge number of sub domains when we hit on www.google.com. The figure shows the site-map and site scope. We can also see the pages visited which are darkened, and unvisited pages are grayed.
This particular instance in the screenshot shows the searches that are done by the user. I have searched for “Security research”, and using the key word finder, I have highlighted the word “security”.
The figure to the left shows the site-map of Google. Google is just used here for a demo. The target web application can be anything under analysis.
The spider tool is used to get a complete list of URLs and parameters for each site. The tool looks into each page that was manually visited and goes through every link it finds in the testing scope. Make sure when using spider tool that your proxy and interceptors are switched off. The more links you manually visit, the better spider you are going to get. It simply gives the spider a larger coverage area.
Setting up the spider is done using the options menu. The two main things we need to set are the authentication and the thread count. The authentication field can be set with a username and password combination. The reason we set up this is because when the spider comes across a login page, it can go through the authentication process in an automated manner, giving more scope to spider the target.
Thread count is the number of concurrent threads that are being used. For a local testing, this count can be high. A higher thread count would imply faster processing but also a larger load. Occasional pop-ups occur asking for changing the scope. Depending on the set up we can choose either a yes or a no.
Once we are done spidering the target, we use the scanner. I am using a free edition of the Burp suite, so the scanner is disabled in this. The professional edition has fully functional scanners. The scanner is used to make tests. There are two types of tests: active and passive. Active tests send data and analyze the possibilities. Passive tests examine all traffic and determine the vulnerabilities present in the application. It’s left to the user’s discretion to choose the type of tests that need to be done on the target.
The intruder has 4 panels as seen in the figure, namely target, positions, payloads and options.
Target: This panel is used to specify the target host (the URL), the port to use for the connection, and also it gives options for using SSL encryption depending on our scenario. The figure below shows the target panel.
Positions: This panel is very important in automating attack strings on the target. There are various kinds of attack vectors, such as sniper attack, battering ram attack, pitchfork attack and cluster bomb.
On observing the figure, we see that the payload positions are automatically highlighted with a “§” character. This happens when you click on the auto button to the right. You can add markers and customize too. A clear option is used to clear all the markers on the page.
A sniper attack is used as a single set of payload. Here, only one value is replaced in the entire payload positions, one after the other. Battering ram is also another form of single payload attack. This is used when a single value is needed in the payload position. The Battering ram works fine when the password quality rules, the policies set are allegedly weak in nature. A lot of enumeration has to be gone through before using this form of attack, since it works in a scenario where, for example, the username and password both would have the same values.
A pitchfork attack, as we are going to see, is used when we need a multiple payload-set. A cluster bomb is another form of a multiple payload attack vector. In a cluster bomb attack, there are two lists; every word in the first list runs against every word in the second list. It is effectively used when the target has a login form which has to be breached.
In this section, I am going to demonstrate a SQLi attack on the demo page of etopshop at the following URL: http://www.etopshop.com/demo/pcstore/admin.asp
SQL injection testing using Burp-intruder
After capturing the page as described, I custom chose my payload markers as Username fields and Password fields. From here, I deduced that since the attack requires two parameters, I need a multiple payload attack. I chose pitchfork attack vector from the dropdown menu. The figure shows the options being set for the attack. I chose the preset list for adding my SQL attack strings to be tried out at the target.
In the figure, we see that we can add, save the preset list of payloads, etc. We have lot of options under the payload set. To mention a few, we have character based, number based, random characters based, brute force, dates, etc. As you can see, I have used the preset list.
The figure shows the process of SQL injection, once you click on start-attack. The results tab shows the payloads being sent to the target. The request tab shows the HTML source and how the payloads are placed at our chosen markers.
Another tab of interest is the response tab. Here, we see that the injection succeeded and we have been welcomed as the store manager when we analyze the HTML source. To see the web page, we can even click on render.
In the figure, we see the successful penetration of the web application, using the famous SQL injection vulnerability. Similarly, XSS attack vulnerabilities can be checked, which I shall leave it to the intuition of the reader, on how to go about it.
In this section, we shall see the Burp-repeater. This tool is generally used to manually modify the HTTP requests and test the responses given by the page. This can even lead to probing for vulnerabilities on the web-page. Basically, this is used to play back requests to the server.
Understanding XSS with Burp-Repeater
We shall use a vulnerable web application at: http://www.steve.org.uk/Security/XSS/Tutorial/simple.html for understanding and analyzing XSS (Cross site scripting) Vulnerability in a webpage.
We see that the iframe code is injected into the source of the web page. When checked on the browser to confirm, if there is a XSS bug present in the application, we see that there is a reflected XSS vulnerability on the target as shown in the figure.
If we want to check for the extent of randomness in the session tokens generated by the web application, this is a tailor made tool to carry out such tests. Brute force attacks enumerate every possible combination for gaining authentication to the web application. This makes it a serious concern to have the high degree of randomness in the session token IDs. Let’s start with sending a request which contains a session token.
In this figure you can see the token request to the site Google.com. The right side of the screen shot has the token start and token end expressions. We can either specify an expression like “Google” or even set the offset from where the token has to start. The same thing holds at the token end panel, where we can set the delimiter, or a fixed length for the capture to start. After fixing these parameters, we can click START CAPTURE.
The start capture action panel looks like the screenshot above. It sends requests to the target and gives a detailed analysis of the randomness in the cookie tokens. We can pause/stop the analysis when we wish to. I stopped the scan mid-way to see the results of the analysis until the paused values. The screenshot below explains the results better.
The scan components are as follows:
- Overall result
- Effective Entropy
- Sample size considered
Burp automatically analyses this aspect and generates this report in this sequencer tool. Other analysis types are character level analysis, which tells us the degree of confidence in the randomness of the sample through a graphical display. Similarly, the bit-level analysis is the analysis done at the bit level. You have the choice to pad characters in the options panel and also to decode in base64 if needed.
This tool enables you to send a request to the decoder. Within the decoder, we have multiple options to encode the request into various formats like base64, URL, etc. There are also options to convert the same to hashes like MD5, SHA-1, etc.
The above screenshot shows the Burp decoder for a request. If we have an encoded request like the one in the following screenshot, then the upper part is a request encoded in the base64 format. The lower part is the request decoded in the clear text. I have encoded the entire request. We can also selectively choose a portion of the request to be decoded/encoded here.
This aspect mainly comes in to use when there is a client side encryption of username and password in commonly used hashes or encoders. The username/password field can be selectively decoded and the contents can be viewed in clear text form.
Burp comparer is used when we have to compare between two sets of data. The two sets can be a comparison of responses received for two different requests. We can compare on the word scale or a byte scale. The comparison shown here is of two different requests to a website. The screen shot below shows the comparison.
The comparison can be done in two ways – Bit-by-Bit comparison and word-by-word comparison. Burp automates this process for the user and compares the two requests or responses accordingly.
This ends the tutorial on Burp-suite. The extent to which Burp-suite can be used can only be left to the imagination of the user. The scanner is not covered in this series because it’s not available in the free edition of Burp. In the commercial edition, the scanner module is fully functional, though with some false positives like any other application.