Welcome to part three of this module
this module is going to be looking at brute forcing Web site Loggins using burp sweet.
It should hopefully be a bit more engaging them a theory heavy module on spider ring that preceded it.
However if you are just starting out I recommend watching these videos covering burp suite in order
starting from Module 1 for instructions on how to set up the proxy and to see the nature of the target.
I am testing against which is still going to be met a split able to for those of you wondering why I'm
not using a later version such as met a split Table 3.
The reason is that at the time of this recording met a split able to has the widest range of vulnerable
Web applications installed on it.
In the last video I conducted a spider against multiple a day.
So in this video our target will be the down vulnerable web application that comes pre installed with
metal split able to I will mention that if you are following along with these videos but you are using
virtual box at all.
You can install down vulnerable web app in Cali and host it right from within the operating system in
order to conduct your tests.
However I don't really recommend this running met a split able to on a virtual machine is much simpler
and you can run virtual box within an installed version of.
If you have it running on a partition.
Alrighty so I already have -- vulnerable Web application open as you can see it is running on the
IP address of the Met a split able to machine which in my case is 10 0 0 on 8 and yours may vary for
instructions on how to get this IP.
Please see the prior modules.
The point of this tutorial will be to demonstrate how to hack into this web site using burps sweet although
this will of course be a simulation.
It will be very close to the real thing.
In the course of this series will be going over brute forcing techniques command execution CSR f file
inclusion Eskew l injection and cross site scripting all of which is listed here but to start out for
the purposes of this tutorial.
We're going to click on -- vulnerable Web application security and because I want to keep things simple
we're going to toggle this down to low and hit submit the attack you are about to see performed while
simple has a shockingly high success rate in the real world.
Many Web sites especially older Web sites tend to have mis configured elements or weaker security.
And this is represented by the low setting within -- vulnerable web app.
As you become more proficient you may wish to toggle the setting to medium or high.
However for right now we'll just stick with low and this will simulate a Web site with inadequate brute
force protections something I failed to mention in prior modules but will bring up now if you are testing
any sort of tool against dam vulnerable web app you can click on The View ideas log to get an idea of
what an administrator would be able to actually see on their end.
So this is just a little aside I wanted to add while we're right here.
So now we're going to bring it burp sweet
and while this is loading
we need to once again make sure that we have our proxy enabled.
So we're gonna come over to preferences click settings under the connection tab and manual proxy and
you want to make sure that it says 127 0 0 0 1 port 80 80.
I believe in a prior video I accidentally said 880 I apologize for that.
It is 80 80 and make sure that use this proxy server for all protocols is checked.
Then click OK
so I'm just going to use temporary project again and we're going to use burp defaults.
Since this is the community edition
already now back in brb sweet we go to the proxy tab.
And we're gonna start off by setting intercept off.
This is because I want to demonstrate something intercept off just means as such.
Essentially that we are not intercepting the requests to and from the web applications that we are targeting
so I'm actually going to back out of this back to the log and prompt
so now if we just put in a random user name and password let's say ninja for the user name and secret
for the password click log in
and we get the exact the result that we expected log and failed.
So now we flip back over to burp sweet we're going to turn intercept back on.
Just wanted to show you what this looks like and we'll try this again.
Ninja secret click log in.
Now we're not actually going to the request is not actually going to go through until we click the forward
button.
We don't want to do that just yet.
We're gonna go back to burp sweet and here we go right away under the proxy tab and intercept tab we
can see the raw catch and this is what I wanted to draw your attention to because the failed log in
message before gave us what we needed to know as far as the expected fields.
We know that it's expecting user name and password
and that is verified right here in the raw catch.
Now there's a lot of data contained here in the raw catch and we could speak at length about what all
of it really means but just for the moment just to keep things on point let's concentrate on the information
that we need here.
The most important thing right now for our purposes of hacking this Web site through brute forcing is
this Get request
again the get request has two values username and password.
We also see the failed username and password that we entered a few moments ago.
The failed values themselves are not what is important but the fields are.
We're going to be using intruder located under the intruder tab.
Intruder allows us to edit the parameters within the request to manipulate them so that we can get the
desired result.
Intruder is the functionality within burp that allows us to perform attacks like brute forcing the raw
catch data so we're going to click on the raw catch and select send two intruder
afterwards we can just click forward because we don't need that particular request anymore
from here we go to intruder and we select the position sub tab we can see that the raw data we sent
from the catch is displayed within certain fields already highlighted these highlights indicate different
possible payloads these are different fields that we can brute force for right away we can see the raw
data we sent from the catch is displayed here with certain fields already highlighted these fields indicate
different possible payloads they are different fields that we can brute force for.
In this particular case we have the user name value the password value the log in value the security
value and the P H P SS s I.D. but we don't actually need all of these for the simple brute forcing operation
that we are going to be performing all we need to hack this low security target is the user name and
password.
Start by clicking the clear button with the symbol next to it and be careful not to confuse it with
the clear button in the lower right hand corner of the screen
This will remove all of the pre highlighted payload markers no values are currently selected to brute
force against meaning that we'll have to select the manually before that we need to change our attack
type to cluster bomb
well I had hoped to keep the theory to a minimum and this module is important to quickly go over these
different attack types burp intruder supports various attack types views determine the way in which
payloads are assigned to payload positions the attack type can be selected by using this drop down menu
and the request template editor the following attack types are available sniper this uses a single set
of payloads it targets each payload position and turn and places each payload into that position intern
positions that are not targeted for a given request are not affected the position markers are removed
and any enclosed text that appears between them in the template remains unchanged this attack is useful
for fuzzing a number of request parameters individually for common variables the total number of requests
generated in the attack is the product of the number of positions and the number of payloads in the
payload set was a bit of a mouthful battering ram.
This uses a single set of payloads it iterate through the payloads and places the same payload into
all of the defined payload positions at once this attack type is useful when an attack requires the
same input to be inserted in multiple places within the request for example a user name within a cookie
and a body parameter the total number of requests generated in this attack is the number of payloads
in the payload set and that should hopefully make more sense from the get to the next step Pitchfork
this uses multiple payload sets there are different payloads set for each defined position up to I believe
a maximum of 20 the attack iterate through all payloads set simultaneously and place places one payload
into each defined position.
In other words the first request will place the first payload from payload set one into position 1 and
the first payload from payload set 2 in the position to the second request will place the second payload
from payload set one into position 1 and the second payload from payload set 2 into position 2 and so
on.
This attack type is useful where an attack requires different but related input to be inserted in multiple
places within the request again for example a user name and one parameter and a known I.D. number corresponding
to that username and another parameter the total number of requests generated in the attack is the number
of payloads in the smallest payload set however the one that we're going to be using cluster bomb this
uses multiple payload sets there is a different payload set for each defined position again up to a
maximum 20 the attack iterate through each payload set in turn so that all permutations of payload combinations
are tested for.
In other words if there are two payload positions the attack will place the first payload for payloads
set two into position 2 and iterate through all of the payloads and payloads set one in position one
it will then place the second payload set to in position to and iterate through all of the payloads
and payloads set one in position one in this attack type is useful where an attack requires different
and unrelated or unknown inputs to be inserted multiple places within the request.
For example one guessing credentials a user name and one parameter and a password and another parameter
the total number of requests generated in the attack is the product of the number of payloads in all
defined payload sets and this may be extremely large so if that seemed a bit over complicated to you
at this stage the game I do apologize.
Essentially what we're saying here is that we're selecting the cluster bomb attack type because it targets
usernames and passwords which are the two fields that we are attempting to brute force.
Now we need to select the values themselves.
It doesn't matter that the user name and password we submitted are wrong.
Just highlight them and click the Add button like this.
First we highlight ninja.
It's wrong but that's OK and we click Add then we highlight secret being careful not to get anything
else into the highlight such as the equal sign or the ampersand and we click the Add button.
As you can see both fields are now encompassed in the little symbols shown next to the ADD button.
This is telling burp sweet to substitute those values with the characters that it will be using in the
attack for this attack.
Make extra sure that no other values are selected once that is done we are almost there.
The last thing to do is go into payloads for payload type.
We want to select simple list this indicates to burp sweet that we want to use a word list to brute
force the target values.
In other words burp sweet is now going to swap out the values we just selected ninja and secret for
words and characters contained within a list that we will supply it.
Payload options just below that is where you select your word list.
In this demonstration I'm not going to use an actual word list but if you were going up against a real
site you would simply click the load button and select the word list file which is typically a document
file Kelly Linux comes with several excellent word lists already on it for programs like this that call
for them and word lists can actually be created and even tailored for your target using applications
like cool and cup and these will be looked at further down the line when we get to them but this is
not a target in the real world.
So there is no need to go to extremes and use a fancy list.
Therefore I'm going to add words manually.
This is something you might try before resorting to a word list if you already know a lot about the
target 3 reconnaissance and your open source intelligence gathering.
Perhaps you already have some idea of what the user name and password might be based on usernames and
passwords that a target is known to use.
A common mistake in security practice is to reuse the same usernames and passwords over and over and
even professionals sometimes fall into this trap.
We'll go ahead and use the add button to put in some words.
These are going to be common user names
admin as we added it adds to our temporary
administrator
route.
Test super user and that should be enough you get the idea.
There we go that covers the first payload for cluster bomb which is the user name.
Now we're gonna go and we're gonna change two payloads set to
which right away gives us a blank canvas for more usernames and passwords.
Now if he did want to use one of the default word lists that came with Cally
just click load
and we'll go over to and user
share
and now I have to find word lists word lists and the ones that I recommend using are found in the Met
a split folder.
There are quite a few.
They're all quite good.
Though default user pass for user names and default pass for services or in my opinion Excellent.
But you could use any of these that you wish.
You can also use your own that you download off the Internet from trustworthy sources or ones that you
regenerate.
As I said but I'm not going to be doing that so I will cancel out of this and now I'm going to add some
common passwords pass
password
admin
route
God because it's used more often than think can Cordy.
That should be good enough.
So just to reiterate payload 1 is the set for usernames and payload 2 is the set for passwords so everything
is ready.
Now we go up to intruder and it's as easy as clicking start attack and this is basically just telling
us that the community addition is slow and the addition that you pay for is awesome.
So we click Okay.
And now the attack has begun.
As you can see it's performing the brute forcing
we'll have to give it a minute to finish.
It shouldn't take very long since we're not using a wide combination of usernames and passwords.
That's another reason that I didn't want to use a word list.
It might it might make this process drag a bit going to maximize it.
And as you can see it's going through all the combinations for the words that we provided it so if you
did provide it with a word list this would be a lot of different combinations.
OK.
So as much as I wish this had gone smoothly and easily it didn't.
However it's a good example of what can happen.
So in a perfect world you will get results that look like this.
And what you would look for are differences in status and length.
Notice that all of these numbers are the same in this case 3 0 2 and 354.
These indicate that with all of these log and requests the same length of a response was returned.
Status is a little more complicated to get into what that means but if either of these were different
it would be a strong indicator that you found the user name and or the password.
But as you can see none of them are different.
And this actually means that -- vulnerable web app has slightly better security even at the lowest
setting than it really probably should.
In fact in prior tests I didn't run into this problem.
However there are still things you can do.
Now the user name and password are here.
I know that for a fact because I know what they are.
So we're actually going to have to dig a little deeper into these results to find them.
And the reason this is bad news is if you're doing this against a a real Web site with real security
and you're using real word lists you're going to have a lot more than 30 requests to look through
so we'll look through these what we're looking for in these get requests.
Is anything different so I clicked this one it's the same.
I'm actually going to scroll down and in all these cases they're the same until we get here to add Ben
and password.
Now I know that this is the correct answer.
And if we go down and we look at the location the location is index P HP for all of these other results
we get log in P HP meaning that we didn't get through the log in page but here we get index CHP which
means that we did in fact get through and that means that the user name is admin and the password is
password so that can be a real pain when you don't get an immediate result what you're normally looking
through looking for like I said is you're looking for the length the one that is different or the status
the one that is different.
But if they're all the same you're going to have to go through them one by one.
And here we found it.
We found that it did log in and get to the index page.
So that's a bit of a pain.
But this is how the tool works.
And when you go up against better security that's the kind of examination you're going to have to give
it.
You'll have to eyeball your results very carefully.
With luck you won't have that problem and it will be immediately obvious from this number being different
or this number being different in any case.
That's about it.
That's how we get the username and password for a Web site through brute forcing techniques.
Now this technique will tend to fail if the Web site is well programmed and limits the number of number
of logging attempts you can make to a certain number before locking you out.
Most high end Web sites do that not all of them.
And this technique can be used against other applications as well.
So that's worth keeping in mind.
And it really was about this straightforward like I said if we used a word list the number of combinations
that would have tried would have been much greater meaning it would take a lot more time to look through
all of these requests.
So just keep that in mind.
And the attack method is extremely effective against low security sites.
And I'm actually surprised that -- vulnerable web app had as good a security as it did.
It must have been upgraded from the last time I used it because last time I had no problem the length
was very obviously different.
Oh well it can happen so as always.
Never use these techniques against any Web site or target that you did not personally own or have written
permission to conduct a penetration test against.
Otherwise you could be breaking the law.
Also keep in mind that these methods are not stealthy and will be brilliantly visible to an administrator
as well as your Internet service provider.
For more information on anonymity please see the module covering those techniques.
I hope you found this tutorial helpful even though the final result was a bit difficult to pin down
and I hope that you have a good idea of how to use burp suite to test your own systems using brute force.
Thank you.