Burp Suite is one of my favorite tools for web application testing. The feature set is rich, and anything that it does not do by default can usually be added with an extension. There are a few things, however, that while they exist in Burp Suite, are not completely intuitive. Below are a few pro tips to help you get the most out of your web application tests.
Password Brute Forcing
Often, penetration testers will want to brute force passwords to gain access or to test password lockout policy in an application. While tools like Hydra exist for this purpose, I find it is much easier to tune in Burp. All you need to do is start by sending the POST request associated with the logon to Burp Intruder.
Clear out all the auto-selected parameters, highlight the password field and click the “add” button. Keep the Attack Type as “Sniper.” Switch to the payload tab and keep the payload type set to “simple list.” Either paste in your wordlist from the clipboard or click the “load…” button and select a wordlist file. Click the “Start attack” button. When you get the results, you are going to want to look for differences in the responses. Typically, I will sort by length to find differences in responses. Another method is to click the “Options” tab and use “Grep – Match” or “Grep – Extract” to flag items with keywords or strip out certain strings from within the responses.
This is going to be similar; however, in this case we are assuming we have a list of usernames. While it’s unlikely a single user has a weak password, it’s much more likely that one of many users has a weak password. We will go through the same steps, except in the positions tab, we will need to highlight both the username and password fields. Also take note that we switched the attack type to “Cluster bomb.”
When you go to the payloads tab it will be slightly different. You will have two options under payload set. The #1 refers to the username (first highlighted parameter) and the #2 is the second highlighted parameter, the password. Both can be set as “Simple list.” For Payload #1, load in your username list. For Payload set #2, add in a couple of simple, common passwords such as “Summer17!” or “$Comapanyname1.” I would recommend only using 3 to 5 passwords, as the targeted application may lock out user accounts. When you run the attack, it will try every username with every password specified. This means if you had 10 users, and 3 passwords each, it would send 30 requests. As before, look at the responses. Compare response lengths and consider using grep under the “Options” tab to extract data from the responses or identify keywords.
Some applications will use CSRF tokens on login pages to stop this exact type of attack. This can be really annoying for an attacker. Luckily, Burp has an answer, using Burp Macros. In the following example, I will add a user in WordPress since it requires a CSRF token each time. You can use this same methodology against anything else, such as a login form that requires it. The first step is to go to “Project Options” and click “Add” under “Macros.” You will need to include two requests: one where the CSRF token is defined, and the POST request you want to submit. In the case of WordPress, this is on the user-new.php page.
Click “Configure Item” on the first request with the CSRF token. Click “add” under the “Custom parameter locations in response.” Find the CSRF token and highlight it. Burp will automatically add the start and end values needed for extraction. Go into the other request and configure it as well.
Set all the items to the preset except for the CSRF token, which needs to say, “Derive from prior response.”
Add a new Session Handling Rule. Click add and select “run macro.” Add the macro you created earlier and click the radio button that says, “Update only the following parameters” and put in the value of the parameter that contains the CSRF token.
Take the login page or, in this case, the add user POST request and send it to intruder. Set up the Intruder and attack as if you were doing a password brute force. When you run the attack, the macro will run automatically, as it is defined as a session handling rule, and the CSRF token will be automatically retrieved and placed in that parameter. For a good article discussing this, check out the SecureState blog.
Sometimes when scanning a web application, the application will automatically invalidate your session if it identifies something suspicious. After your session gets invalidated, Burp continues to scan. This is not good, as we will miss findings because all the responses to Burp Scanner’s payloads won’t contain an actual response, but instead will likely provide a generic redirect to the login form.
To fix this problem, we can add a Session Handling Rule; but first, we need to make a simple macro. Go to the Project Options -> “Sessions” and under “Macros” click “Add.” For the macro item, we just want a copy of the POST request performed when logging in. It will usually look something like this:
Next, we want to add a New Session Handling Rule. Click “Add” Under “Session Handling Rules.”
Under “Rule Actions” click “Add” and select “Check session is valid.”
You will need to identify some condition present when you become logged out. This will vary for each web application. You can look for a string in the response body, such as “logged out,” or you can check for a redirect to the sign-out/sign-in pages.
You need to make sure the “If session is invalid, perform the action below” box is checked. Put “Run a macro” from the drop-down box and select the macro created earlier in the sign-in process.
Lastly, ensure the checkbox “Update current request with cookies from session handling cookie jar” is selected, near the bottom.
Now whenever you become logged out, Burp will see this, re-authenticate, and add the new valid cookies on all subsequent responses.
For a lengthier description of this process, check out the blog from SecureLayer7.
While simple in nature, this trick is super helpful. Most of the time I scan in Burp, I will select items in the site map and just click “Actively Scan this Host” or “Actively Scan this Branch.” While this is great, I don’t always know exactly what is being scanned and if something is being scanned unnecessarily. To scan parameters that I specifically want to target, we can send the request to Burp Intruder. Once in Intruder, we can select the parameter we are interested in and highlight it. If we right click anywhere in the box, we have the option “Actively Scan defined insertion points.”
Now the scanner will focus solely on the parameter we chose. This is a fast way to target the parameters that would be likely candidates to contain a vulnerability.
Finding Hidden Pages
If you have used Burp, you have probably used it to spider a page. Additionally, you can use “Discover Content” by right clicking on something and clicking “Engagement Tools.” Both of these will find content you may not have discovered through manual browsing. Once you have browsed the website thoroughly, click in the contents pane in the center of the page and select everything. Right click and go to “Highlight.” Select any color. Now run either Spider or “Discover Content.” You will see new items added to the Contents pane, though they will not be highlighted. These are items that were newly discovered by either the spider or by “Discover Content.”
If the client is missing the Strict-Transport Security header, a demo of an SSL stripping attack may help them understand the risk. Without needing to download SSLstrip, you can simulate this attack in Burp Suite.
You will need to go to the Proxy tab and then click on the Options tab. From there, edit your Proxy listener and click the box that says, “Force use of SSL.”
Down below on the Options page there will be two check boxes that you will need to click, “Covert HTTPS to HTTP” and “Remove secure flag from cookies.”
Now next time you visit the page without specifying the protocol, your browser will display the content over HTTP, and Burp will relay the content over HTTPS.