Good morning everyone!
Today we will talk about one of the most used and powerful tools within Burp Suite itself to carry out Web audits.
Burp Suite is a tool for testing the security of web applications. Intercepts, examines and modifies requests. It allows you to visualize how a request is formed, in addition to detecting common vulnerabilities such as SQL injections and Cross-Site Scripting. Provides capabilities that allow you to automate common tasks and customize workflows. It is a versatile and powerful tool.
The Intruder is an internal module of Burp Suite, it allows us to automate requests, which is very useful when performing fuzzing or brute force tasks.
It allows us to take one request (usually captured in the Proxy before passing it to Intruder) and use it as a template to send many more requests with slightly altered values automatically. For example, when capturing a request containing a login attempt, we could configure Intruder to swap the username and password fields for values from a list of words, effectively allowing us to force the login form. Similarly, we could pass a list of words to fuzz subdirectories, endpoints, or virtual hosts. This functionality is very similar to that offered by tools such as Wfuzz or Ffuf.
The most common uses given to the intruder are:
- Fuzzing directories or parameters: Searching Identify vulnerabilities based on input.
- List subdomains: Discover or increase an additional attack surface.
- Brute-forcing logins: Automate username and password combinations.
Now knowing its main functions, we will see how it works with an example.
The first step will be to intercept a request through the proxy offered by Burp Suite. To do this, we will open the browser offered by Burp Suite and activate the interception.
For the test we will use a portswigger lab that would allow us to practice attacks with the Intruder. In this case we will go to the login page where we can perform a brute force attack on the login.
With the proxy activated, we will click on log in to intercept the request for the test page that we have used.
Once the request is captured, we send it to the Intruder where we will carry out the attack.
From the Intruder we can choose what type of attack we want, being able to differentiate 4 different ones:
1. Sniper:
Intruder will take each payload we pass to it (from a list of payloads) and place it at each defined position in turn. That is, it will pass each payload in the list into each parameter in turn.
Example: if we have a request that has 2 parameters username and password and we have a list of words that would be: burp, suite and intruder. The requests would be like this:
2. Battering Ram:
Take a set of payloads (e.g. a list of words). Where the same payload is placed at each position (parameter).
Example: if we have a request that has 2 parameters username and password and we have a list of words that would be: burp, suite and intruder. The requests would be like this:
3. Pitchfork:
Pitchfork uses a set of payloads per position and cycles through them all at once. Ideally, our sets of payloads should be the same length when working on Pitchfork, as Intruder will stop testing as soon as one of the lists is complete. For example, if we have two lists, one with 100 lines and one with 90 lines, Intruder will only make 90 requests and the final ten elements of the first list will not be tested.
Example: if we have a request that has 2 parameters username and password and we have two lists of words, what would be the first list of names:
And the second list of passwords:
The requests would be like this:
4. Cluster Bomb:
Cluster bomb allows us to choose multiple sets of payloads: one per position, however, while Pitchfork iterates through each set of payloads simultaneously, Cluster bomb iterates through each set of payloads individually, ensuring that all combinations are tested. possible payloads.
Example: if we have a request that has 2 parameters username and password and we have two lists of words, what would be the first list of names:
And the second list of passwords:
The requests would be like this:
Once we know the types of attacks available, we continue with the practical example. In our specific case we will choose the Sniper type since we will get the username and password separately. Next, we will add the position of the payload in the “username” field
Once the position is selected we are going to add the payload that we will use in the attack. In this case we have used a list of common names as a dictionary.
With everything ready we can start the attack, which will make requests to the website with all the usernames provided.
We can see how with the payload alerts the size of the response changes, this is because the error message is different, where it tells us that the password is incorrect. From here we obtain that there is a user called alerts.
Now we will use the same method, but in the password field to find the password of the identified user
Once the user with whom we are trying to log in has changed, we repeat the same attack with the password, changing the list to one with typical values for weak passwords.
In this case we can detect the change in the response since it is a redirect, which tells us that it has possibly been validated.
We test to see if we are correct on the test page:
And with the credentials obtained we can enter, also leaving the laboratory resolved.
In the same way that I have carried out this test with a portswinger laboratory, there are many pages and machines that can be used to practice with the Intruder. Some of them are:
So far this introduction to the intruder, as you can imagine, has a multitude of uses and can be applied in very different ways depending on the needs of the audit.
We hope you liked it and we'll see you in the next installment of FluProject.
