As we discussed in the previous article, Burp Suite offers a complete arsenal of tools for security testing and ethical hacking.

In this article, we’re going to show how are we going to configure Burp Suite to use SSL as well as demonstrating some real-life examples of using Burp Suite.

Configuring Burp Suite to intercept SSL requests

As we mentioned before, Burp Suite has a self-signed Root CA (Certificate Authority). This CA is able to automatically generate and sign a certificate for every website you visit, but if you don’t whitelist this Root CA in your browser, Burp Suite won’t be able to intercept SSL requests properly.

Let’s configure the browser to trust Burp Suite’s Root CA.

• You need to Export Burp’s CA by navigating to “Options” under the “Proxy” tab, click on “Import/export CA certificate”.

• Select “Certificate in DER format” and click on Next.

• Select the path and filename of the certificate to be exported.

• Success message appears:

• The certificate should be now present under /root/burp.cer.

• In your browser (in our case, Firefox under Kali), go to “Preferences” and click on “View Certificates” under the “Advanced” → “Certificates” tab:

• Click on “Import” and select the location of the certificate we just generated, which should be under /root/burp.cer.

• Select “Trust this CA to identify websites”:

• You now should be able to see HTTPS requests in Burp Suite without errors in your browser.

Using Various Burp Suite Tools

We’re going to use a demo banking website created by IBM that could be found at http://demo.testfire.net

Note: A demo account for this website could be found using the following credentials:

Username: jsmith

Password: Demo1234

Using Burp Suite’s Spider

As we mentioned previously, Spider has passive and active crawling. Crawling is useful in the Reconnaissance step, and once the crawling is done, you would be able to map the web application and identify weak spots.

In order to activate Active crawling, we go to the Target tab and right click on the target website and select “Spider this host”. This has to be done after navigating to the website using the browser.

You’ll get a warning about Burp Suite’s scope, as the spider needs the website to be within the scope to avoid unnecessary crawling. After proceeding, you’ll find that the “Spider is running” button is toggled under the “Spider” tab and that the spider has started working.

Note: Spider's output including all crawled URLs will be automatically added under the “Target” tab.

Using Burp Suite’s Repeater

Let’s take the login request for example.

First, go to http://demo.testfire.net and try to manually sign into the website using the browser to record the request in the "Target" tab.

In order to record the request and send it to the repeater, you can do one of two things:

• Normally log in and find the POST request from the "Target" tab.

Go to the “Target” tab and find the POST request that is responsible for logging in. Find the request, right click it and select “Send to Repeater”.

• Intercept the request using the "Proxy" tab. This can be done by doing the following:
1. Navigate to the login page and write your username and password, but don't press "login" yet.
2. Open the "Proxy" tab and toggle on "Intercept is on".
3. Go back to the website and press the login button.
4. Now the request will appear under the Burp Suite Proxy tab.

The “Repeater” tab will be highlighted and upon opening it, you will find the request in there:

You can see all the parameters of the website. You can replay the request with the modifications you desire and the response will be on the right panel. Pressing “Go” will send the request to the server.

You can also change the request method, i.e. from GET to POST and vice versa.

The repeater is very useful when tampering with data sent to the server. For example, in this banking app, there is a "Transfer funds" option, which allows you to transfer virtual money from an account to another.

If we intercept the request that is sent via the "Transfer Money" button, we can see different parameters such as the source account, the target account and the amount.

We could, for example, manipulate the amount of money transferred by editing the transferAmount parameter value.

Using Burp Suite’s Intruder

In the previous example, we had a login request. Let’s use this login request to bruteforce an account.

• Right click on the request from the “Target” tab and select “Send to Intruder”

• An entry will be added under the “Intruder” tab, and since the Tab 1 is added by default by the program, the new entry will be found under Tab 2. Open the Tab 2 and select “Positions”. Use “Clear §” to clear all placeholders, replace the value of “uid” with “jsmith” and select the password value then click on “Add §”. This will make the password field a variable field that will be used to bruteforce the account.

• Placeholders will be used to put the passwords we want to try. As mentioned above, since we already know a username’s ID, we’ll use that username “jsmith” to bruteforce his account.

• Open the “Payloads” tab and select “load” to load a password list from a file. We compiled a list of most common passwords — you can find it here: Common Passwords. Download this file and load it under "Payload Options".

• Intruder works with different types of "Payload Sets" and "Attack Types". These define how the Intruder know what to put in every selected placeholder. In our case, we used "Sniper" as the attack type and by default, this has one payload set and will apply the set for all selected placeholders. You can read more about this from the official documentation: Payload Positions
• Now, everything is set. Hit “Start Attack” and wait for the results to appear. It’s always better to sort the results according to the response’s length. An unusual response length often indicates a successful bruteforce attempt.

• An interesting entry “Demo1234” has an unusual response length. By examining the response, we can see that additional cookie values have been set, such as amUserId and amCreditOffer.

• This is most likely a valid password; why not try it on the login page?

• Aaaaand... SUCCESS! We successfully managed to brute force an existing account using Burp Suite’s Intruder.

Using Burp Suite’s Decoder

You have a website on which you’re conducting security tests, and you wanted to test SQL Injection on the login page. Typical payload would be putting “’or 1=1 –“ in the username field.

But maybe you find that there is some sort of a filtering mechanism that replaces single quotes or escapes them. How would you attempt to bypass this filter?

One of the most common ways is to encode your characters, either using hexadecimal encoding or URL encoding. Some filters fail to validate encoded characters and that’s where we use this to our advantage.

• Open the “Decoder” tab and type in your payload, and then select the desired encoding method. In this example, we used the URL encoding method.

• You can now use the output in your SQL Injection payload in an attempt to bypass the web server filtering mechanism.

• You could also perform multiple encodings, which sometimes works when it comes to bypassing some filters.

• Employing the same logic, you can also decode encoded strings, which comes in handy when trying to decode Base64 strings and responses found on websites and CTF (Capture the Flag) contests.

Using Burp Suite's Scanner

Scanner is only available in the commercial license. It scans for various web application vulnerabilities including the OWASP Top 10. It lists vulnerabilities according to the severity.

By default, Burp Suite passively scans for minor issues like sending passwords as cleartext. However, if you want to actively scan a host, right click on it from the "Target" tab and select "Actively scan this host".

Proceed with default configuration and click on "Next"

After starting the scan, the results can be found in two places:

• Scanner tab

• Target tab

To show the details of any issue, double click it and a window will appear showing information about the vulnerability found