Is fuzzing your favorite attack type, but you didn’t enjoy it due to the low speed and high memory usage when you work over with some big dictionaries?
So, today over with this article, we’ll explore one of
the fastest and the most reliable fuzzer “Turbo Intruder” - a burp suite
extension that will dump the output within a few minutes without worrying about
the number of payloads embedded within the dictionary, keeping the memory usage
in its mind
·
Introduction to Turbo Intruder
o What
is Turbo Intruder
o Burp
Intruder v/s Turbo Intruder
o Turbo
Intruder’s Installation
·
Brute Forcing the application’s Passwords
o Via
Burp Intruder
o Via
Turbo Intruder
·
Customizing the Python Scripts
·
Fuzz for Multiple parameters
Introduction
to Turbo Intruder
What is Turbo
Intruder
Turbo Intruder one of the greatest burp suite extensions
scripted by “James Kettle” in order to send a large number of HTTP
requests and analyzing the results. However, the functionality of this
extension is as similar as of the Burp’s Intruder carries. Yes, it is a
fuzzer. But as it uses the HTTP-stack thereby some features make it
a bit different and faster –
·
High speed with least latency during fuzzing
·
Low memory usage with a million payloads
·
Customizable python scripts for different attack
scenarios
·
Reliable for Multi-day attacks
Burp Intruder v/s
Turbo Intruder
No doubt, the intruder tab is the most powerful
part of the burp suite. Whether it’s about to fuzz an application over at a
single injection point or multiple, it does it work seamlessly. However, this
tool provides whatever we wish to, whether it’s about payloads or the error
detections, it is good-to-go. But when
it comes to the fuzzing speed or the memory usage it drops it out. If the
dictionary exceeds about a lakh payload, the latency and the memory consumption
will be at their peak. But why this all happens?
In order to analyze this, we need to understand the mechanism
it carries while fuzzing.
All the major brute forcers, create a TCP
handshake for a single request and send the request to the server,
thereby the server waits and shares the response back, as soon as the tool gets
the response, it then reads out and the same happens again. However, the
handshake consumes a lot of time and the sending & reading phases contain a
much latency too, thereby giving a high load on the CPU and consuming a lot of
memory reducing the speed to fuzz that.
But the turbo intruder is different and
as its speed is. It works on an old technology i.e., HTTP pipelining
which establishes the connection first and shares as many possible requests in
one go without worrying about the received responses in order to minimize the
latency and server processing time.
Turbo Intruder’s
Installation
It’s not difficult to find this plugin neither to install
it, simply navigate to the Extender tab and then further select the bApp
Store option within it and once you scroll your mouse down, you’ll find it
right in front with a rating reaching to almost 5 stars.
Now simply hit the install button over in the
description and there we’re ready to go.
But where it is, it’s not aligned in any of the tabs?
Let’s check out within the Action section, a
simple right-click can give us the Send to Turbo Intruder option.
Brute
Forcing the application’s Passwords
You might be wondering like, all of these concepts are
documented either at the portswigger’s web-page or at the extension’s GitHub
repository, so what’s new. And what about the practical exposure, how we could
confirm that, yes turbo intruder fuzz the application in a much faster way than
the basic burp’s intruder does.
Thereby in order to confirm and check that all, let’s
tune into our vulnerable application bWAPP and we’ll capture the login portal’s
HTTP Request by setting the username to bee and a random password as 12345.
Once the Login button got fired up, we got the
Request intercepted at our Burp monitor, so let’s first share it with “Intruder”.
However, the Intruder steps are on our tips, so let’s
recall them once again. As soon as the Intruder receives the request, our first
work is to set the clear out the things and set the injection points
over at the position tab.
Now, time to inject our fuzzing lists. Switch to the Payloads
tab, right next to Position one, and click the Load button in order to select
the desired list. For this section, we’ve modified the 10-million-password-list of Daniel Miessler SecLists Github's repository and
have injected bee & bug within it.
From the below image, you can see that the number of
requests is more than 100,000, which is not large but still it could
help us to determine the speed.
Now as soon as we hit the Attack button, the fuzzer
starts up and it took about 60+ seconds to fuzz about 1700 requests
which makes it about 23 requests per second (RPS).
Via Turbo Intruder
Let’s first pause the intruder here and will
check what Turbo Intruder dumps out as its speed.
Back into the intercept tab, we’ll select the payload
position and will then hit right-click in order to share the request to the
Turbo Intruder.
As soon as the “Send to turbo intruder” option got
fired up, we got a new window popped in-front of us. Let’s explore what it contains.
The window was segregated into two sections the upper
part where our “shared request” is embedded into and just below that in
the other part we got a “snippet of python code” aligned.
However, over into the Request section, we can see
that our injection point was converted into “%s”, representing where the
payload will be going to hit.
And at the other section, there is a drop-down list
with a python code displayed, which thus could be modified as per the
attack scenario.
The drop-down list contains a number of attacking python
scripts, that we could use accordingly whenever we need.
So, for the time being, let’s use the most common script
of the Turbo Intruder i.e. examples/basic.py
Once we select that, the python code within it got
displayed on the screen. Let’s see what it says –
1.
The script within the first
highlighted box is responsible for the fuzzing speed and the number
of connections made by the turbo intruder. However, it even carries up the requests
made per connection.
2.
Over in the second box we need
to add the dictionary manually by specifying its location.
3.
The third code snippet is the
most highlighted section as it defines which request should be displayed
in the output table. Here the code “if req.status != 404:” defines that
all the requests will get added to the table leaving the once that are having status
code = 404
Now, let’s inject our dictionary by defining its
path while manipulating the code.
Further, we’ll hit the Attack button in order to
initiate our fuzzer. As we do so, within 73 seconds it's just 1029
requests shared, creating the RPS (Request per Second)
count to 14.
You might be wondering like, this needs to be faster
than the basic intruder, however, the RPS rate for the Burp Intruder was 23,
and it's just 14.
This is all due to the default configuration in the
python script as the concurrentConnections was just 5 and the Request
per Connection was 100. Let’s modify it all and start the attack
again, in order to do so hit the halt button and configure the same with
concurrentConnections=20,
requestperConnetction=200,
And as the attack executes up, the RPS rate jumps
directly to 94 and within just 3 seconds the fuzzer hit about 280
requests.
Thereby for this attack, we can say it’s about 4 times
faster than the Basic Intruder.
However, during the
attack, you could find that the retries value is going up, as the fuzzer
was initiating. So, is the requests are not hitting?
No, it is an indication that the connection per request
value might be too high for the server to handle, making the attack is less optimal,
thus we need to cut it down and reduce it to half.
Do you remember, we halted the Intruder’s fuzzing? Let’s
resume it and restart our attack over the turbo intruder, and we’ll then wait
for a few minutes in order to analyze the output.
From the below image, we can see that Turbo Intruder
is ahead with 3000+ hits, displaying the speed it carries within.
Customizing
the Python Scripts
Over in the above section, we’ve discussed that we can
manipulate the python script as we wish so. However, manipulating it doesn’t
require any advanced scripting skills, it's just that we know what the code
wants to say. So, for example –
We want the table to dump only the 302 Redirection,
we don’t want any 200 OK, neither 404 Error, thereby in order to
do so we just need to manipulate the 3rd code snippet.
Now over here, we’ll change not-equal to (!=) with
equal-equal (==) and will modify 404 with 302, Such that the output will
only have the redirection requests listed.
From the below image, we can see that within 3 seconds we
got our output listed over at the table segmented.
Fuzz for
Multiple parameters
You might have used Cluster Bomb over in the basic intruder which helps us to fuzz the application with multiple parameters. However, in the same way, we’re having a python script listed in the drop-down menu too which will thereby provide us the option to fuzz as similar to the cluster bomb payload-type. Let’s check that out.
Back into the Proxy tab let’s select any parameter
and hit a right-click in order to navigate to turbo intruder
There, over in the request portion, let’s set “%s” in
order to select the injection points.
Time to choose the script, click on the bar to check the
drop-down menu, and then select examples/multipleParameters.py
Once clicked-on, the script is there for us to get
manipulated.
Let’s boot the speed by manipulating the concurrentConnections=20
and requestperConnetction=200, further we’ll set the dictionaries for
the first word and the second word.
And there we go, as soon as we hit the Attack button
the screen got shuffled and we got the output table in-front of us. Within a
few minutes, as we double-clicked the Length section, we got the 302
Redirection with bee/bug.
0 comments:
Post a Comment