All right, so in the last lecture, we used a sequel injection vulnerability to bypass authentication
and sign in as an admin, as you can see here.
All right.
And we were able to inject a single tick and completely avoid the weird clause with the combination
of the four keyboard and a comment.
So we go back to the Developer Tools Network, and if we lock out, try to log back in
with that single ticket, find the post request, go to the response and you can see the query here.
Now, the reason we were able to log in as an admin by inserting that single tick and the other one
equals one is because the first record in the user's table probably has an idea of one and it corresponds
to the administrator.
You know, it's not uncommon at the first record is the administrator.
And so what we did, I'll show you what we did, actually.
Let's grab this query, flip over to Obsidian Control and call the sequel.
I tap original Sky SQL query and I'll just paste it in here.
Contrary, Tony, let's just do something here
controlled to get out of preview mode.
Let's just copy this injected SQL query when we did for the injected as we put tick or one equals one
Tuktoyaktuk.
It's what I want you guys to see is that this tag or one equals one does a couple of things.
First of all, this comment comments out everything after here.
So basically all that stuff gets deleted.
So actually, make this again, another query looks like this, right?
Well, now it's just saying select all columns from the user's table where the email is equal to nothing
or one equals one.
Well, this idea the condition is true.
One is always equal to one.
And therefore, this entire weird clause disappears.
So let's reflect that.
So now the query is just selecting all columns from the user's table and all records.
But if the first records and admin and the code is just checking for a match for the first match, then
all the columns for that particular user, the user name, the password, the deleted add column is
going to be returned by the database and it's going to be used by the Web to access the restricted page.
So that's just I just want to kind of clean that up so you guys see, you know, how that works.
All right.
But today we're going to get into the broken authentication piece.
So we've already demonstrated that authentication is broken by signing in as the admin user without
even knowing his password.
Right.
But when Oos uses the term broken authentication, they're referring to using username and password
lists to force valid accounts and gain unauthorized entry into a Web app.
So, you know, perhaps we can use a dictionary attack to sign into the Web app as another user, right?
At least that's what I'm thinking, because if this this website is relying on password based logins,
right.
As the only method of authenticating users, then there's a high probability that, you know, it's
vulnerable to brute force and dictionary based attacks.
Now, it is true that some Web apps will actually implement brute force defenses by blocking the attackers
IP after a failed login threshold is reached.
But this can sometimes be bypassed by logging in with valid credentials at regular intervals.
What'll happen is you'll try a sequence of failed attempts and then the Web app will reset the failed
attempt counter at the first successful attempt.
Also, you know, if the account gets locked out, we may be able to completely bypass it with a credential
stuffing attack.
And that's what Oos mentions here.
And attackers have access to hundreds of millions of valid username and password combinations for credential
stuffing.
Right.
Is the application vulnerable?
Well, if the application permits automated attacks such as credential stuffing, then it may be.
So what is this credential stuffing?
Well, you know, instead of issuing a bunch of failed logins against a single user name, we can use
a massive dictionary of unique username password pairs leaked from a data breach.
And since most people we use credentials, legal credentials used against one website might also be
valid against another.
In addition, account walkout wouldn't work in this case because each username is only attempted once,
right.
And the other thing is the attacker might actually get lucky and compromised multiple accounts in a
single automated session.
So there's a lot of benefit to this credential stuffing attack vector.
So let's see if we can execute this.
So we're logged into this app as an administrator.
Let's click on one of these options here, Free Press.
All right.
So there's a review.
No to review this one.
All right.
What about green smoothie?
I'm just looking for like an account or, you know, I'm just looking for like a user reviews.
All right.
So we've got this user, Jim, at Juice.
Let's see if we can get into this user's account through broken authentication.
So we're going to log out of the admin.
Let's go back to the login form and let's see what happens if we if we go to forgot your password.
So we'll pop his email address in here, tab down to the next box.
An interesting number one, Firefox are telling me this connection is not secure because it's not using
apps.
So obviously you wouldn't want to enter sensitive information over this connection because it could
be captured and replayed.
But you also notice it says your eldest sibling's middle name, it's giving us a clue to the security
question.
So if we knew that, you know, if we do the answer to this question, if we knew the middle name of
Jim's eldest sibling, then we could probably recreate you know, we could possibly break into this
account by setting a new password and then plugging in, as Jim was just put like Jim in here and said,
the password, something we change.
All right, so telling us wrong answer to a security question, if we could automate this process.
And then look for, you know, this response inside the EDP request that we might be able to sort of
script up a brute force, especially if there's no mitigations in place here.
So let's go ahead and send this to intruder and see what we can do over to berp.
Interceptors on.
We'll put in test test.
And all she's tested the password, so there is some security in place.
All right, so we've got this request.
Control our control, shift our go to repeater.
Controlled space descended.
So if we just change this answer from test to something like Mike, control your bass, wrong answer.
Right.
And I can keep changing this James control space.
And you can see every time the bites are sent, James, one control space, the bite to the same control
space and the delay is pretty similar to.
So let's send this to intruder control.
I control shift I.
We go to positions, we want to clear all the positions and we only care about this answer right here,
so we'll select it.
We'll say ad and then we need a list of payloads, right?
We need a list of names, so we're going to get that good old Google common list of names.
Let's see, what do we have?
And so we've got something here.
Yeah, so this is going to be really cool, guys, I'm going to show you how we can scrape this list
because, you know, there's a lot of information in here that we don't need.
You know, all we really want other names.
We don't care about the rank and the numbers.
So let's go ahead and get this list into a format that Berp would like, just the list of names.
All right.
So first, let's do a curl on this URL just to pull everything down.
Control should be.
All right, so we've got everything here, we can see the names are listed here, right?
So.
If we could just grep out lines that end in this closing table and table, Rohtak, and we should just
get the lines that include the names we want, right.
Not this other stuff.
So let's do that.
Let's say grep and we need to do a Taqi because that allows us to do regex.
And then we can say
something like this.
And now we've got the lines that show us what we need.
And it was a couple of things that we don't need.
We don't need this output from Kearl.
We can make Kerl silent.
That looks better.
And now what do we want?
Well, we also want the names of between a TD and a closing TD right here.
We've got a T and a closing TD so we can use some projects to get that out of there again.
We can send it to grep.
And what can we do here?
We can say t that space closing, Tedy.
And between those, we have some words, so we have word characters, one or more words, word, characters.
That's what this backslash means.
Now, we've got a lot of stuff, but we're getting still things we don't need.
We only want to include the matches and so we can do the tech option to just include the matches.
All right, cool.
We're getting better now when we need to step off the TVs we can use set for that.
So the first we'll get rid of that and saying substitute this.
With whatever comes next, which will be nothing to a global match and make a case insensitive, inter
good, then we'll just get off the last part.
We'll strip off the trailing -- and let's say it didn't work because we need to escape that slash
with a backslash.
There we go.
Looking good.
So pipe this into a foul called middle names.
All right.
So we've got this file.
It's one point for K.
Let's put that into berp.
There we go.
All right, looking good, know what we can do is in the options, we can basically tell it to extract
useful information from the response and we want this so we know what the wrong answers look like.
So we'll just selected.
Looks good.
OK.
Back to payloads and we start the attack, let's go.
So it took about 10 minutes to go through this list, mainly because we're using Berp Community, which
is the free version of Berp, which basically has a rate limiting, artificially introduced to encourage
people to buy the full product, which, by the way, I strongly suggest.
So we can actually flip through the output by sorting by length.
And when you do that, you can see this payload.
Samuel has a different response.
It doesn't actually contain the wrong answer to a security question.
Instead, it contains a TDP 200 status code.
And you can see we've got a password that's been hashed.
And we have a few other things, so we now know we are effectively able to brute force the answer to
the victims security question, right?
We know it's Samuel.
So let's go ahead and use this to log in.
So put Samuel here.
Go to change.
Password was successfully changed.
Now we should be able to log in.
We'll paste his e-mail address in and we'll put in the password we just created.
And bam, we're logged in as Jim.
Right.
So this attack could have been mitigated by banning, you know, my source IP after a certain number
of failed login attempts or by not reflecting the user's security question in the Web apps forgot my
password page.
Also, I'm using two factor authentication would have helped because even if I as the attacker had Jim's
password, I still couldn't log in without Jim Smartphone's or security.
Right.
So that's the way to go.
And in the next lecture, we're going to continue our own journey by looking at sensitive data exposure.
So I'll see you guys in the next lecture by.