Security Testing with Burp Suite
Burp Suite is a GUI-based integrated platform
for web application security testing.
It provides several different tools via the same user interface.
We can find Burp Suite Community Edition in the Kali menu.
After our initial launch, we may notice a warning
that Burp Suite has not been tested on our Java Runtime Environment.
Since the Kali team always tests Burp Suite on the Java version
shipped with the OS, we can safely ignore this warning.
Once it launches, we’ll choose Temporary project and click Next.
We’ll leave Use Burp defaults selected and click Start Burp.
After a few moments, the UI will load.
Let’s start with the Proxy tool.
In general terms, a web proxy is any dedicated hardware or software
meant to intercept requests and/or responses
between the web client and the web server.
This allows administrators and testers alike
to modify any requests that are intercepted by the proxy,
both manually and automatically.
With the Burp Proxy tool, we can intercept any request
sent from the browser before it is passed on to the server.
We can change almost anything about the request at this point,
such as parameter names or form values.
We can even add new headers.
This lets us test how an application handles unexpected arbitrary input.
For example, an input field might have a size limit of 20 characters,
but we could use Burp Suite to modify a request to submit 30 characters.
In order to set up a proxy, we will first click the Proxy tab
to reveal several sub-tabs.
We’ll also disable the Intercept tool, found under the Intercept tab.
Next, we’ll review the proxy listener settings.
The Options sub-tab shows what ports are listening for proxy requests.
By default, Burp Suite enables a proxy listener on localhost:8080.
This is the host and port that our browser must connect to
in order to proxy traffic through Burp Suite.
Let’s demonstrate how to configure our local Kali machine
with the Firefox browser to use Burp Suite as a proxy.
In Firefox, we can do this under Network Settings.
Let’s choose the Manual option,
setting the appropriate IP address and listening port.
Finally, we also want to enable this proxy server for all protocol options
to ensure that we can intercept every request
while testing the target application.
With Burp configured as a proxy on our browser,
we can close any extra open Firefox tabs and browse to http://www.megacorpone.com.
We should find the intercepted traffic in Burp Suite
under Proxy by clicking on the HTTP History tab.
We can now review the various requests
our browser performed towards our target website.
By clicking on one of the requests,
the entire dump of client requests and server responses
is shown in the lower half of the Burp UI.
On the left pane we can visualize the client request details,
with the server response on the right pane.
With this powerful Burp feature,
we can inspect every detail of each request performed,
along with the response.
Beside the Proxy feature, the Repeater is another fundamental Burp tool.
With the Repeater, we can craft new requests
or easily modify the ones in History, resend them, and review the responses.
To observe this in action,
we can right-click a request and select Send to Repeater.
If we click on Repeater,
we will observe one sub-tab with the request on the left side of the window.
We can send multiple requests to Repeater
and it will display them using separate tabs.
Let’s send the request to the server.
Burp Suite will display the raw server response on the right side of the window,
which includes the response headers and un-rendered response content.
The last feature we will cover is Intruder,
but first, we’ll need to configure our local Kali’s hosts file
to statically assign the IP to the offsecwp website we are going to test.
The Intruder Burp feature, as its name suggests,
is designed to automate a variety of attack angles,
from the simplest to more complex web application attacks.
To learn more about this feature,
let’s simulate a password brute forcing attack.
Once the we arrive at the login page we’ll enter “admin”
and “test” as the username and password.
Returning to Burp,
we’ll right-click on our POST request and select Send to Intruder.
We can now select the Intruder tab in the upper bar,
choose the POST request we want to modify, and move to the Positions sub-tab.
Knowing that the user admin is correct,
we only need to brute force the password field.
First, we’ll press Clear on the right bar so that all fields are cleared.
We can then select the value of the pwd key
and press the Add button on the right.
We have now instructed the Intruder
to modify only the password value on each new request.
Before starting our attack, let’s provide Intruder with a wordlist.
Knowing that the correct password is “password”,
we can grab the first 10 values from the rockyou wordlist on Kali.
Moving to the Payloads sub-tab,
we can paste the wordlist into the Payload Options area.
With everything ready, let’s click Start Attack.
We can move past the Burp warning about restricted Intruder features,
as this won’t impact our attack.
After we let the attack complete,
we can observe that apart from the initial probing request,
it performed 10 requests,
one for each entry in the provided wordlist.
We’ll notice that the WordPress application
replied with a different Status code on the 4th request,
hinting that this might be the correct password value.
Our hypothesis is confirmed once we try to log in
to the WordPress administrative console with the discovered password.
Now that we’ve built a solid foundational knowledge
about how Burp and other assessment tools work,
let’s take the next step and learn how to enumerate a target web application.