Walkthrough of the Burp Suite Intruder Web Application pentesting room focusing on the practical sections.

Intruder

We have already gone through the general features and Repeater function of Burp Suite. This piece will cover the Intruder primary module which is basically its fuzzing tool. The Intruder module can be used to apply the previously captured request as a template to send many more requests with slightly altered values automatically. There are four attack types, Sniper, Battering Ram, Pitch Fork and Cluster Bomb. When conducting a sniper attack, we provide one set of payload for each payload position (e.g. username + password) one after the other. With this we could bruteforce into a known account. The Battering Ram attack uses also one payload and puts it into all the positions, but not one after the other but all at the same time. The Pitchfork attack uses one payload set per position (up to a maximum of 20) and iterates through them all at once, simultaneously. The last attack type of Burp Suite is called Cluster Bomb which iterates through each different payload sets individually to ensure all possible combinations of payloads are tested.

Practical Example

Let’s navigate to [/support/login] page and start capturing the traffic with some test data entered into the fields. Then let’s send it to the Intruder module from the Proxy and also switch the attack type to “Pitchfork” from the dropdown menu.

After this let us load the downloaded credentials into the Payload Sets, No.1 being the username list and No.2 would be the password list.

After starting the attack a new window will open with all the requests made. There are two options to figure out which one is successful. Login request would give us 200 response codes, and failed login requests would provide us with 401s. Due to the fact that now we are only given 302 redirects for all requests, a second option would be workable which is identifying differences in the length of responses. All we need to do is find the length which stands-out and utilize the credentials that belong to it and we are in.

Practical Challenge

Checking out the rows with clicking on them we can see that the corresponding URLs are simply assigned an integer identifier.

This would allow us to easily fuzz to numbers with using one of the attack types. The target should only allow us to view tickets that are assigned to our current user. If all the existing tickets can be read by any user logged in then a vulnerability called IDOR (Insecure Direct Object References) is present. Now, let’s find an appropriate position and payload and with this we could also answer the first question of this section.

Which attack type is best suited for this task?

After this, the responses only with the status code of 200 should be examined to reveal our flag.

What is the flag?

Extra Mile CSRF Token Bypass

Let’s make another but a bit more sophisticated credential stuffing attack now starting by catching a request against the login page. There is a session cookie set in the response and a CSRF (Cross-Site Request Forgery) token included in the form as a hidden field. Both the session cookie and the token change every time when the page is refreshed which means unique values are required upon every login attempt.

Now, let’s pass the captured login request to Intruder again and set only the username and password fields for the positions with the attack type Pitchfork. After this let’s load the same username and password lists as we did for the previous Pitchfork attack above.

Now, a macro needs to be applied  to send a GET request to [/admin/login/], because the loginToken and session cookie change with each page refresh. Let’s navigate “Project options” -> Sessions and at the bottom of the page click “Add” a macro.

After this let’s find our target URL in the “Macro Recorder” and then we could change the description of it in the “Macro Editor” as well.

Now that macro is defined “Session Handling” rules should be specified about the usage of it. On the top of the exact same Burp Suite page in the “Session Handling Rules” let’s add a new rule in the “Sessions” subtab then update the “Rule Description”.

After this  switch over to the Scope tab and for the “Tools Scope” only keep the “Intruder” and for the “URL scope” switch on the “Use suite scope [defined in Target tab]” if it is defined there earlier. If it’s not there we could add the same here as “Custom scope”.

Now, the macro needs to be added (we receive a “lack of action” warning anyway if closing the “Session handling rule editor” window without adding any). If it is closed hit “Edit” and in the “Rule Actions” section chose “Run a macro” from the dropdown menu.

Then in the editor “loginToken” parameters and “session” cookies should be set to be updated.

Now, let’s switch back to the Intruder and we can initiate our attack. We got back 302 redirect errors but one of the responses should stand out as before being a lot shorter than the others.

Yes. We are in as admin..

Thanks for reading and as always, any feedback is most welcome.