WEBVTT

0:00:03.620000 --> 0:00:06.880000
 Testing for weak password policies.

0:00:06.880000 --> 0:00:10.900000
 So welcome everyone to the next section
 of this course where we will actually

0:00:10.900000 --> 0:00:17.840000
 be taking a look at how to test authentication
 mechanisms on web applications.

0:00:17.840000 --> 0:00:22.540000
 And as I've mentioned previously in
 this course, our guide throughout

0:00:22.540000 --> 0:00:30.640000
 this course as well as the guide.

0:00:30.640000 --> 0:00:36.420000
 Just as a general guideline or reference
 to ensure that again we follow

0:00:36.420000 --> 0:00:43.640000
 a structured methodology and this will
 also provide you with a reference

0:00:43.640000 --> 0:00:47.280000
 point that again will mirror
 exactly what mine is.

0:00:47.280000 --> 0:00:53.520000
 So it's one of the reasons for using
 methodologies like the WSTG.

0:00:53.520000 --> 0:00:57.580000
 In any case, we're kicking off the authentication
 testing section of this

0:00:57.580000 --> 0:01:04.820000
 course by taking a the most well-known
 form of authentication testing

0:01:04.820000 --> 0:01:07.940000
 and that is of course testing
 for a weak password policy.

0:01:07.940000 --> 0:01:14.240000
 Now, before I put any words in my mouth
 or I get ahead of myself, I would

0:01:14.240000 --> 0:01:21.460000
 like to introduce you to what exactly
 testing for a weak password policy

0:01:21.460000 --> 0:01:25.920000
 is, especially in the WSTG nomenclature.

0:01:25.920000 --> 0:01:35.600000
 So, I've referenced the WSTG ID for this
 particular test, but diving into

0:01:35.600000 --> 0:01:41.380000
 it, this test focuses on evaluating if
 a web application enforces a strong

0:01:41.380000 --> 0:01:44.680000
 password policy to protect user accounts.


0:01:44.680000 --> 0:01:49.180000
 It's a critical part of authentication
 testing, essentially ensuring that

0:01:49.180000 --> 0:01:54.900000
 the web application doesn't allow weak
 or easily guessable passwords.

0:01:54.900000 --> 0:02:00.360000
 Now, I'll explain exactly how this is
 done and when we use something like

0:02:00.360000 --> 0:02:04.320000
 a brute force attack or when we perform
 a dictionary attack because they

0:02:04.320000 --> 0:02:07.320000
 are different and you're really testing
 for different things, which is

0:02:07.320000 --> 0:02:09.240000
 what I want you to get.

0:02:09.240000 --> 0:02:15.920000
 So the underlying point that I'm trying
 to make here is that many users

0:02:15.920000 --> 0:02:21.980000
 are likely to set simple or common passwords,
 easily-rememable passwords,

0:02:21.980000 --> 0:02:24.460000
 stuff that they can recall.

0:02:24.460000 --> 0:02:28.060000
 Now, of course, password security or
 password hygiene has improved over

0:02:28.060000 --> 0:02:32.220000
 the years and a lot of people are using
 password managers that generate

0:02:32.220000 --> 0:02:34.880000
 secure passwords for them.

0:02:34.880000 --> 0:02:39.940000
 But the bottom line is that weak password
 policy, both on the client side

0:02:39.940000 --> 0:02:46.040000
 or on the user side, as well as on the
 server side or from the perspective

0:02:46.040000 --> 0:02:50.420000
 of the web application ultimately makes
 it easier for attackers to gain

0:02:50.420000 --> 0:02:52.080000
 unauthorized access.

0:02:52.080000 --> 0:02:53.480000
 What do I mean by this?

0:02:53.480000 --> 0:02:59.580000
 You as a user on a website, if you generate
 a weak password, that's your

0:02:59.580000 --> 0:03:00.880000
 responsibility, right?

0:03:00.880000 --> 0:03:04.580000
 However, it should also be the responsibility
 of the web application to

0:03:04.580000 --> 0:03:10.120000
 enforce password security policies that
 essentially tell you, hey, your

0:03:10.120000 --> 0:03:16.420000
 password needs to be, you know, more
 than or equal to eight characters.

0:03:16.420000 --> 0:03:21.440000
 You need to include both uppercase and
 lowercase characters, as well as,

0:03:21.440000 --> 0:03:23.400000
 you know, specific symbols.

0:03:23.400000 --> 0:03:27.020000
 Whenever you see that in a web application,
 whether you're registering

0:03:27.020000 --> 0:03:33.160000
 for an account or changing your password,
 that is a defined policy that

0:03:33.160000 --> 0:03:37.100000
 the web application or the company
 that developed the web application

0:03:37.100000 --> 0:03:42.660000
 has enforced to essentially save
 you from yourself, if you will.

0:03:42.660000 --> 0:03:48.860000
 So they have to force users to generate
 or to create and use secure passwords.

0:03:48.860000 --> 0:03:54.560000
 The reason why they, the reason why,
 you know, a secure password consists

0:03:54.560000 --> 0:03:59.800000
 of, you know, generally speaking, a
 random string of text numbers, both

0:03:59.800000 --> 0:04:04.780000
 uppercase and lowercase, as well as
 symbols, is because those are not

0:04:04.780000 --> 0:04:11.380000
 easily guessed. And in most, in most
 situations, I'm not going to be found

0:04:11.380000 --> 0:04:15.660000
 in any word list or dictionary, you
 know, either through a leak database

0:04:15.660000 --> 0:04:20.720000
 out there, which is why, again, another
 good password security tip is

0:04:20.720000 --> 0:04:25.000000
 to have different passwords randomly
 generated for different websites

0:04:25.000000 --> 0:04:29.060000
 that you visit so that if one is breached
 and your password is somehow

0:04:29.060000 --> 0:04:33.980000
 made public, then it doesn't give the
 attackers, you know, or, you know,

0:04:33.980000 --> 0:04:37.180000
 any malicious actor the
 keys to the kingdom.

0:04:37.180000 --> 0:04:40.660000
 So weak password policies can expose
 accounts and sensitive information,

0:04:40.660000 --> 0:04:45.560000
 obviously, which ultimately lead to data
 breaches and unauthorized access

0:04:45.560000 --> 0:04:47.800000
 to private user data.

0:04:47.800000 --> 0:04:53.040000
 So let's explore this a little bit more.

0:04:53.040000 --> 0:04:57.300000
 And when I say a little bit more, I
 mean, you know, what types of attack

0:04:57.300000 --> 0:05:01.080000
 techniques are typically employed
 and when do attackers use them?

0:05:01.080000 --> 0:05:03.920000
 Or let's actually gear it
 towards you as a web app.

0:05:03.920000 --> 0:05:08.420000
 Pen tester whenever we get into this
 particular test, or, you know, the

0:05:08.420000 --> 0:05:14.060000
 process of testing for weak passwords,
 you know, pen testers will usually

0:05:14.060000 --> 0:05:17.380000
 conflate a dictionary attack
 and a brute force attack.

0:05:17.380000 --> 0:05:20.980000
 And I myself am guilty
 of that very mistake.

0:05:20.980000 --> 0:05:25.360000
 I wouldn't call it a mistake, but it's
 sort of a misnomer in that, especially

0:05:25.360000 --> 0:05:28.940000
 when you're performing a professional,
 you know, in this case, a web app

0:05:28.940000 --> 0:05:32.440000
 pen test, you need to distinguish
 between the two.

0:05:32.440000 --> 0:05:36.680000
 So for example, let's say, and we'll
 see this during the practical session

0:05:36.680000 --> 0:05:42.640000
 or section of this video, you know,
 if we have a login form and let's

0:05:42.640000 --> 0:05:46.900000
 say we were able to identify a user
 or an email that we would like to

0:05:46.900000 --> 0:05:52.920000
 now, you know, perform or test, you know,
 either brute force a dictionary

0:05:52.920000 --> 0:05:59.020000
 attack with then when do we use
 either of these two attacks?

0:05:59.020000 --> 0:06:04.260000
 Well, in the case of a dictionary attack,
 this is where you use a predefined

0:06:04.260000 --> 0:06:06.920000
 list of common passwords
 to see if any match.

0:06:06.920000 --> 0:06:08.820000
 So you're using a word list.

0:06:08.820000 --> 0:06:13.500000
 So think of the word list included in
 sec list in the sec list word list

0:06:13.500000 --> 0:06:17.460000
 collection, all the ones that come
 pre-packaged with, let's say, Kali

0:06:17.460000 --> 0:06:22.500000
 Linux, a word list or a password dictionary
 is essentially a collection

0:06:22.500000 --> 0:06:29.480000
 of passwords that have been a generated
 to meet specific criteria.

0:06:29.480000 --> 0:06:31.860000
 And we'll talk a little bit about that.

0:06:31.860000 --> 0:06:36.300000
 So, you know, let's say a word list
 that contains passwords that are,

0:06:36.300000 --> 0:06:41.980000
 you know, that range from four
 to six characters long.

0:06:41.980000 --> 0:06:44.860000
 I'm not saying that that's the case
 or that's something that you should

0:06:44.860000 --> 0:06:49.700000
 use. I'm just using an example or, you
 know, the rock you word list, you

0:06:49.700000 --> 0:06:54.920000
 know, which essentially comprises of
 passwords that have been that were

0:06:54.920000 --> 0:06:56.740000
 made publicly through data breaches.

0:06:56.740000 --> 0:07:00.460000
 So what you're doing is you're testing,
 generally speaking, you're testing

0:07:00.460000 --> 0:07:04.600000
 to see whether there is indeed
 any password policy in place.

0:07:04.600000 --> 0:07:08.420000
 And more importantly, as we'll see in
 the next video, you're also testing

0:07:08.420000 --> 0:07:13.840000
 for any rate limiting or lockout mechanisms
 that have been put in place

0:07:13.840000 --> 0:07:16.100000
 to prevent brute force attacks.

0:07:16.100000 --> 0:07:20.400000
 So, you know, think of a duration based
 lockout where if you enter failed

0:07:20.400000 --> 0:07:25.620000
 password for an account three or five
 times, you get locked out from that

0:07:25.620000 --> 0:07:28.840000
 account for, let's say, an
 hour or a day or whatever.

0:07:28.840000 --> 0:07:33.020000
 And we'll actually be exploring how that
 can be bypassed in the next video.

0:07:33.020000 --> 0:07:36.020000
 But the bottom line is you're trying
 to see whether there's any policy

0:07:36.020000 --> 0:07:41.360000
 in place. So is there a minimum
 password length, a maximum, etc.

0:07:41.360000 --> 0:07:46.200000
 And of course, this in certain cases may
 require you to perform registration.

0:07:46.200000 --> 0:07:51.540000
 But a dictionary attack, again,
 you're using common passwords.

0:07:51.540000 --> 0:07:55.520000
 A brute force attack is when you have
 identified that, yes, there is a

0:07:55.520000 --> 0:08:00.560000
 password policy in place that, let's
 say, requires the password to have

0:08:00.560000 --> 0:08:07.560000
 both uppercase and lowercase letters
 or, you know, and maybe numbers,

0:08:07.560000 --> 0:08:08.540000
 but not symbols.

0:08:08.540000 --> 0:08:13.840000
 In that case, you generate your own
 word list with that or with those

0:08:13.840000 --> 0:08:14.840000
 parameters in mind.

0:08:14.840000 --> 0:08:17.360000
 And there's many tools that
 you can use to do that.

0:08:17.360000 --> 0:08:22.060000
 And then you perform a brute force attack,
 which is where you now go through

0:08:22.060000 --> 0:08:25.740000
 each permutation, let's say, from,
 you know, the beginning.

0:08:25.740000 --> 0:08:31.460000
 So a, a, a, a, a, a,
 one exclamation mark.

0:08:31.460000 --> 0:08:37.680000
 And then, you know, the next one can be
 a, a, a, a, b, two or one exclamation.

0:08:37.680000 --> 0:08:40.420000
 So that can take quite a bit of time.

0:08:40.420000 --> 0:08:43.520000
 Um, and I think you're getting the
 idea, but, you know, a brute force

0:08:43.520000 --> 0:08:48.760000
 attack, there's many, um, word lists
 that have been generated for, for

0:08:48.760000 --> 0:08:50.200000
 these parameters.

0:08:50.200000 --> 0:08:55.000000
 So, you know, brute force attack is you're
 not using any, let's say, common

0:08:55.000000 --> 0:08:59.500000
 passwords or passwords from data breaches
 or default, you know, credentials.

0:08:59.500000 --> 0:09:04.940000
 You're now actually brute forcing for
 the correct password, which again

0:09:04.940000 --> 0:09:08.880000
 will take time. So the objective is to,
 um, to see if the web application

0:09:08.880000 --> 0:09:15.780000
 accepts weak passwords or if it has, or
 I should say, and if it has protections

0:09:15.780000 --> 0:09:19.900000
 like account lockouts or let's say a
 capture, which will also be exploring

0:09:19.900000 --> 0:09:23.740000
 how to bypass, uh, in this
 course or in this section.

0:09:23.740000 --> 0:09:27.740000
 So there's quite a bit going on here,
 which is why I wanted to cover this.

0:09:27.740000 --> 0:09:31.660000
 Uh, you know, even though, you know, you
 may think this is a basic technique

0:09:31.660000 --> 0:09:34.700000
 and you've explored how to do it, but
 there's a lot of stuff that you're

0:09:34.700000 --> 0:09:37.980000
 looking for as a web app pen tester
 while you're doing this.

0:09:37.980000 --> 0:09:42.500000
 Um, so the focus areas are, you know,
 I've already gone over them, but

0:09:42.500000 --> 0:09:43.840000
 password complexity.

0:09:43.840000 --> 0:09:47.600000
 So does the web application enforce
 minimum standards like the length,

0:09:47.600000 --> 0:09:49.800000
 character types, et cetera?

0:09:49.800000 --> 0:09:53.360000
 Secondly, account lockouts or rate limits,
 which I said is very important,

0:09:53.360000 --> 0:09:55.580000
 especially in modern web applications.

0:09:55.580000 --> 0:10:00.180000
 So does the application implement protections
 that limit log in attempts?

0:10:00.180000 --> 0:10:01.540000
 And of course error messages.

0:10:01.540000 --> 0:10:07.420000
 So are they, um, are the error messages,
 if any generic or are they verbose?

0:10:07.420000 --> 0:10:11.800000
 Do they reveal a little bit of info,
 none at all or too much info?

0:10:11.800000 --> 0:10:15.700000
 Um, and this is specific to
 password validity, right?

0:10:15.700000 --> 0:10:20.740000
 So for example, if I had an, let's
 add a username or an email that was

0:10:20.740000 --> 0:10:26.480000
 verified or does exist and I, you
 know, I type in a random password.

0:10:26.480000 --> 0:10:29.940000
 Um, are there any, uh, you know, a
 random password that is incorrect.

0:10:29.940000 --> 0:10:35.980000
 Let's say five, um, five characters along
 in, you know, in terms of length.

0:10:35.980000 --> 0:10:40.100000
 Uh, does the log inform tell you
 that, hey, that's too short.

0:10:40.100000 --> 0:10:41.660000
 So it's probably incorrect.

0:10:41.660000 --> 0:10:47.860000
 If that's the case, you know, you can
 start to identify or to, um, to

0:10:47.860000 --> 0:10:52.300000
 find what these policies are, but that's,
 you know, a very black box,

0:10:52.300000 --> 0:10:54.160000
 um, testing strategy.

0:10:54.160000 --> 0:10:57.560000
 If you're performing a bug bounty,
 typically you will register for an

0:10:57.560000 --> 0:11:00.580000
 account and see whether any of
 those policies are in place.

0:11:00.580000 --> 0:11:04.440000
 So again, when you register for an account,
 you know, nowadays with any

0:11:04.440000 --> 0:11:09.120000
 website, there is a password policy when,
 you know, creating your password

0:11:09.120000 --> 0:11:13.920000
 and some websites also have password
 generators, uh, therefore you, or

0:11:13.920000 --> 0:11:18.200000
 if you're using a password manager or
 even a browser like Firefox, it'll

0:11:18.200000 --> 0:11:22.880000
 automatically generate a secure password
 for you and it'll save it for

0:11:22.880000 --> 0:11:25.540000
 you within your password
 keychain in your browser.

0:11:25.540000 --> 0:11:27.740000
 But I'm getting out of myself.

0:11:27.740000 --> 0:11:29.880000
 So what are the primary objectives?

0:11:29.880000 --> 0:11:32.460000
 Uh, firstly identify weak
 password policies.

0:11:32.460000 --> 0:11:37.060000
 So determine if the application accepts
 weak passwords without restrictions.

0:11:37.060000 --> 0:11:39.460000
 Secondly, test account lockouts
 and rate limiting.

0:11:39.460000 --> 0:11:42.760000
 So check if multiple failed attempts
 are limited to mitigate brute force

0:11:42.760000 --> 0:11:46.720000
 or dictionary attacks, uh, assess
 password complexity requirements.

0:11:46.720000 --> 0:11:50.920000
 So verify the application enforces secure
 password rules like a minimum

0:11:50.920000 --> 0:11:56.100000
 length, mixed character requirements,
 et cetera, and check for consistent

0:11:56.100000 --> 0:11:59.780000
 error messages. So confirm that error
 messages do don't disclose unnecessary

0:11:59.780000 --> 0:12:01.980000
 details, which could help attackers.

0:12:01.980000 --> 0:12:05.520000
 And as you can see, I've sort of geared
 these slides to be from the perspective

0:12:05.520000 --> 0:12:08.340000
 of a web app and test
 or bug bounty hunter.

0:12:08.340000 --> 0:12:12.940000
 And the reason this is important and why
 I'm using this nomenclature that's

0:12:12.940000 --> 0:12:18.200000
 associated with the WSDG and ORASP
 is because when generating your web

0:12:18.200000 --> 0:12:23.160000
 app and testing report or a bug bounty
 disclosure, uh, if you use a, you

0:12:23.160000 --> 0:12:27.520000
 know, framework like WSDG, you're better
 able to communicate what exactly

0:12:27.520000 --> 0:12:32.880000
 you've found. And, uh, you're able to
 communicate the risk or the potential

0:12:32.880000 --> 0:12:41.040000
 impact, let's say, you would normally
 it can be very hard, uh, for you

0:12:41.040000 --> 0:12:44.100000
 to accurately communicate what
 you've found, et cetera.

0:12:44.100000 --> 0:12:48.880000
 So hopefully I'm, I'm, um, I'm sort of
 covering that to a certain extent.

0:12:48.880000 --> 0:12:54.660000
 Now, in order to demonstrate this,
 I'm going to, uh, where we're going

0:12:54.660000 --> 0:12:56.060000
 to be going through a lab demo.

0:12:56.060000 --> 0:12:58.760000
 So this video has a lab
 associated with it.

0:12:58.760000 --> 0:13:00.980000
 It's just going to be below this video.

0:13:00.980000 --> 0:13:05.500000
 Uh, and, uh, we, you know, pretty much
 will be presented with a log in

0:13:05.500000 --> 0:13:09.380000
 form. And we're going to do a dictionary
 attack and see whether we can,

0:13:09.380000 --> 0:13:11.560000
 uh, we can actually log in.

0:13:11.560000 --> 0:13:15.580000
 Um, and as I said, a lot of what's
 going on in the background, what I

0:13:15.580000 --> 0:13:19.860000
 mentioned, you know, the objectives
 around rate limiting, uh, et cetera,

0:13:19.860000 --> 0:13:24.300000
 we'll be covering, uh, in the next
 video, uh, or next set of videos so

0:13:24.300000 --> 0:13:26.560000
 that it all starts to make sense.

0:13:26.560000 --> 0:13:29.760000
 Uh, with that being said, I'm going
 to fire up my lab and I'll see you

0:13:29.760000 --> 0:13:34.440000
 in the lab environment
 in a couple of seconds.

0:13:34.440000 --> 0:13:38.640000
 All right. So I'm currently within the
 lab environment and I'm just going

0:13:38.640000 --> 0:13:42.020000
 to switch into full screen so
 you can see what I'm seeing.

0:13:42.020000 --> 0:13:46.500000
 And, uh, this particular lab will provide
 you with a pre-configured Kali

0:13:46.500000 --> 0:13:51.400000
 Linux system so you can actually run the
 attack from it within your browser.

0:13:51.400000 --> 0:13:55.240000
 And the great thing is the web application
 will be targeting is already

0:13:55.240000 --> 0:13:59.200000
 going to be opened up for you when
 you start the lab, uh, in Firefox.

0:13:59.200000 --> 0:14:04.740000
 So the name of the, uh, or the actual
 domain is securebank.com port 5000

0:14:04.740000 --> 0:14:09.700000
 and log in. So we have a web
 app called secure bank.

0:14:09.700000 --> 0:14:15.200000
 And, uh, of course we need to log in
 obviously we can't just access, uh,

0:14:15.200000 --> 0:14:17.640000
 a bank an online bank without logging in.


0:14:17.640000 --> 0:14:23.000000
 Uh, we can't enter a room without knocking
 or if we're, you know, without

0:14:23.000000 --> 0:14:29.200000
 any authorization, but we can see that it
 uses an email and password combination.

0:14:29.200000 --> 0:14:31.860000
 For the credentials or for
 authentication, right?

0:14:31.860000 --> 0:14:34.100000
 So this is the authentication mechanism.

0:14:34.100000 --> 0:14:39.400000
 We also have the forgot password, um,
 form right over here, which actually

0:14:39.400000 --> 0:14:42.820000
 asks for a customer ID, which
 is actually pretty cool.

0:14:42.820000 --> 0:14:47.680000
 Um, but for example, uh, you know, as
 we were discussing previously within

0:14:47.680000 --> 0:14:52.100000
 the slides and previous videos, uh,
 what happens if we were to test this

0:14:52.100000 --> 0:14:56.760000
 again? I'm deviating, but let's say
 I entered the custom ID of one or

0:14:56.760000 --> 0:15:00.020000
 zero, which would typically be associated
 with the admin or the first

0:15:00.020000 --> 0:15:02.040000
 user to register an account.

0:15:02.040000 --> 0:15:06.720000
 It'll say, uh, you can see that it's
 not too verbose in that the message,

0:15:06.720000 --> 0:15:11.540000
 uh, that's displayed here essentially
 says that the password reset link

0:15:11.540000 --> 0:15:15.900000
 will be sent to your, um, to your registration
 email or the email used

0:15:15.900000 --> 0:15:18.140000
 to register for an account shortly.

0:15:18.140000 --> 0:15:22.500000
 So it doesn't even tell you whether that,
 uh, custom ID exists or it doesn't,

0:15:22.500000 --> 0:15:24.120000
 or at least we haven't tested yet.

0:15:24.120000 --> 0:15:27.440000
 So let's try something random here.

0:15:27.440000 --> 0:15:32.160000
 And, uh, yeah, that looks like it's, uh,
 it still gives us the same message,

0:15:32.160000 --> 0:15:35.640000
 which is great because it doesn't tell
 the attacker or you, the pen tester,

0:15:35.640000 --> 0:15:37.980000
 whether this ID actually exists.

0:15:37.980000 --> 0:15:40.500000
 So this is part of that
 user enumeration, right?

0:15:40.500000 --> 0:15:46.000000
 But let's try to hear still the same,
 maybe one 34, still the same message.

0:15:46.000000 --> 0:15:48.220000
 And we can actually try and refresh this.


0:15:48.220000 --> 0:15:51.740000
 Let's try, uh, in case I was
 making a mistake there.

0:15:51.740000 --> 0:15:54.980000
 Yeah. So still the same thing doesn't
 really tell you whether that custom

0:15:54.980000 --> 0:16:00.040000
 ID exists. But we have the registration
 for, sorry, the login form I should

0:16:00.040000 --> 0:16:03.500000
 say here. That asks for
 an email and password.

0:16:03.500000 --> 0:16:07.700000
 Now within this lab, you have already
 been provided with the email that

0:16:07.700000 --> 0:16:11.900000
 we're going to be targeting or the email
 that belongs to the account we're

0:16:11.900000 --> 0:16:16.020000
 targeting. The email is
 admin at secbank.com.

0:16:16.020000 --> 0:16:18.900000
 It is within the lab documentation.

0:16:18.900000 --> 0:16:23.340000
 Um, and we're really trying to see whether
 we can, you know, uh, get the,

0:16:23.340000 --> 0:16:28.660000
 the password for this particular
 user who is the admin, right?

0:16:28.660000 --> 0:16:32.840000
 So within Firefox, I'm going to go
 into Foxy proxy and we're going to,

0:16:32.840000 --> 0:16:35.320000
 you know, proxy, all
 traffic to burbsweet.

0:16:35.320000 --> 0:16:40.540000
 And I'm going to open up my menu here web
 application analysis and burbsweet.

0:16:40.540000 --> 0:16:44.040000
 Uh, again, this is a quite an old version
 of burbsweet, but it'll work

0:16:44.040000 --> 0:16:48.740000
 just as fine. So, or just as well,
 I should say, so there we are.

0:16:48.740000 --> 0:16:52.980000
 We can see it's starting up burbsweet
 and we'll give it a few seconds.

0:16:52.980000 --> 0:16:56.320000
 I'm not going to intercept anything yet.

0:16:56.320000 --> 0:16:57.920000
 So I'll just hit okay.

0:16:57.920000 --> 0:17:02.540000
 And I believe this version, let's
 see, does it have the browser?

0:17:02.540000 --> 0:17:03.860000
 Uh, no, it doesn't.

0:17:03.860000 --> 0:17:08.120000
 So, uh, we can actually just disable
 intercept for a second.

0:17:08.120000 --> 0:17:12.400000
 I'm just going to refresh this
 and now we'll enable it again.

0:17:12.400000 --> 0:17:16.900000
 And, uh, we will just enter in the email.


0:17:16.900000 --> 0:17:19.400000
 So this email is legitimate.

0:17:19.400000 --> 0:17:24.060000
 So secbank.com where we're going under
 the assumption that we were able

0:17:24.060000 --> 0:17:28.080000
 to enumerate this information, either
 through OSINT techniques or something

0:17:28.080000 --> 0:17:31.900000
 like that, or username and enumeration
 techniques that I outlined in the

0:17:31.900000 --> 0:17:36.360000
 previous video. So for the password,
 I'll just use password as a test

0:17:36.360000 --> 0:17:39.320000
 or placeholder and it log in.

0:17:39.320000 --> 0:17:40.040000
 And there we are.

0:17:40.040000 --> 0:17:42.860000
 We can now see the request in burbsweet.

0:17:42.860000 --> 0:17:49.720000
 And what I'm going to do here is, uh,
 let's see, on the display, I'm going

0:17:49.720000 --> 0:17:55.640000
 to increase this to maybe 18 and there
 will actually change this to 18

0:17:55.640000 --> 0:18:01.720000
 as well, just so that you can see, um,
 everything now will need to restart

0:18:01.720000 --> 0:18:05.400000
 burbs. Um, but if we're going to
 intercept, uh, there we are.

0:18:05.400000 --> 0:18:07.820000
 Let's see if I can, uh, zoom in.

0:18:07.820000 --> 0:18:10.360000
 Um, okay. So there we are.

0:18:10.360000 --> 0:18:14.440000
 We can see that we have an options request
 or request with the options,

0:18:14.440000 --> 0:18:19.640000
 um, head asset. So, uh, we don't, this
 is not really relevant to logging

0:18:19.640000 --> 0:18:23.100000
 in, but, um, let's go ahead and for this.


0:18:23.100000 --> 0:18:24.040000
 It actually looks here.

0:18:24.040000 --> 0:18:26.740000
 The host is port 8,000 for this.

0:18:26.740000 --> 0:18:30.500000
 And then we have the post here that's
 now being sent to what appears to

0:18:30.500000 --> 0:18:32.100000
 be an API end point.

0:18:32.100000 --> 0:18:37.480000
 So authentication is being, uh, performed
 via an API to this, you know,

0:18:37.480000 --> 0:18:42.600000
 to, to, to this server on this
 particular port, which is fine.

0:18:42.600000 --> 0:18:45.280000
 Uh, but we're going to send this to the
 intruder and we're going to perform

0:18:45.280000 --> 0:18:47.320000
 a dictionary attack, right?

0:18:47.320000 --> 0:18:50.200000
 So we're going to use a word list.

0:18:50.200000 --> 0:18:54.580000
 Um, so we'll send it to the intruder
 and we'll go ahead and say positions,

0:18:54.580000 --> 0:18:58.280000
 sniper. And we don't want to test.

0:18:58.280000 --> 0:19:03.140000
 Um, I'm going to clear, um, just
 going to clear this here.

0:19:03.140000 --> 0:19:06.660000
 So clear all positions and I'm going
 to add the password position there.

0:19:06.660000 --> 0:19:10.640000
 Cause that's the one we want to attack
 or we want, we are targeting for

0:19:10.640000 --> 0:19:14.740000
 the payloads, simple list and we're
 just going to load the word list.

0:19:14.740000 --> 0:19:20.500000
 So there is a word list that has been,
 um, placed under, in the desktop,

0:19:20.500000 --> 0:19:25.060000
 uh, in the word list folder, it's
 called a hundred common passwords.

0:19:25.060000 --> 0:19:27.300000
 Again, just for the sake
 of this demonstration.

0:19:27.300000 --> 0:19:31.920000
 So this has a, you know, what you'd
 consider to be very weak passwords

0:19:31.920000 --> 0:19:36.100000
 that, again, most likely come
 from a data breach of sorts.

0:19:36.100000 --> 0:19:40.240000
 So it looks like some twiddling on the
 numeric keypad here with two, four,

0:19:40.240000 --> 0:19:43.500000
 two, four, two, four, zero,
 nine, eight, seven.

0:19:43.500000 --> 0:19:47.680000
 Yeah. Again, quite, uh, no stall,
 I'm getting quite nostalgic here.

0:19:47.680000 --> 0:19:51.100000
 So we can just stop the attack and
 let's see whether we're successful,

0:19:51.100000 --> 0:19:53.880000
 um, with this dictionary attack.

0:19:53.880000 --> 0:19:58.080000
 So we'll pay attention to the length
 here and we'll take a look at one

0:19:58.080000 --> 0:19:59.680000
 of these and let's see.

0:19:59.680000 --> 0:20:05.460000
 So invalid credentials, that's what we get
 when we specify invalid credentials.

0:20:05.460000 --> 0:20:09.600000
 And it looks like for Christmas, the
 password Christmas, we actually get

0:20:09.600000 --> 0:20:11.840000
 a length of 511.

0:20:11.840000 --> 0:20:15.260000
 And we can see there we are admin true.

0:20:15.260000 --> 0:20:18.240000
 And then it gives us a
 token here with a flag.

0:20:18.240000 --> 0:20:21.180000
 And that is in essence what
 we were supposed to get.

0:20:21.180000 --> 0:20:25.700000
 So we can actually try and log in and
 I'm going to pause this attack here.

0:20:25.700000 --> 0:20:29.100000
 And I'm going to close.

0:20:29.100000 --> 0:20:33.980000
 We'll go into the proxy and I'm just
 going to say disable intercept and

0:20:33.980000 --> 0:20:36.300000
 the password we saw was Christmas.

0:20:36.300000 --> 0:20:41.020000
 So Christmas and we log
 in and there we are.

0:20:41.020000 --> 0:20:45.160000
 So we get the flag and that's pretty much
 all that I wanted to demonstrate.

0:20:45.160000 --> 0:20:48.340000
 I know you're already familiar with,
 you know, how to attack login forms

0:20:48.340000 --> 0:20:49.200000
 with burp suite.

0:20:49.200000 --> 0:20:53.900000
 So that was not the goal, but this will
 become very important, especially

0:20:53.900000 --> 0:20:54.800000
 in the next video.

0:20:54.800000 --> 0:20:58.620000
 So what have we learned from this particular
 lab or this demonstration

0:20:58.620000 --> 0:21:04.740000
 that this particular site does not have
 any password policy it looks like?

0:21:04.740000 --> 0:21:10.980000
 So, you know, if a user can specify
 their banking password as Christmas

0:21:10.980000 --> 0:21:14.320000
 and the admin no less, then
 that's a huge issue.

0:21:14.320000 --> 0:21:18.040000
 They didn't appear to be any rate limiting,
 although we weren't able to

0:21:18.040000 --> 0:21:22.020000
 test it fully, but you know, more than
 three or five attempts and I should

0:21:22.020000 --> 0:21:26.800000
 be locked out. And that's exactly what
 we're going to be exploring in

0:21:26.800000 --> 0:21:30.040000
 the next video. But for now, that brings
 us to the end of the practical

0:21:30.040000 --> 0:21:32.560000
 demonstration section of this video.

0:21:32.560000 --> 0:21:34.960000
 And I'll see you in the slides.

0:21:34.960000 --> 0:21:39.900000
 All right. So that was sort of a recap
 of, you know, brute force slash

0:21:39.900000 --> 0:21:41.280000
 dictionary attack.

0:21:41.280000 --> 0:21:46.560000
 And I just wanted to use this demonstration
 or this video as, you know,

0:21:46.560000 --> 0:21:52.180000
 for a or a recap into, you know, authentication
 or attacks against authentication

0:21:52.180000 --> 0:21:57.480000
 mechanisms. But now we're going to
 get into the real meat and potatoes

0:21:57.480000 --> 0:22:03.340000
 of this section in the next video by
 exploring again how to bypass weak

0:22:03.340000 --> 0:22:08.000000
 lockout mechanisms or to identify weak
 lockout mechanisms that are in

0:22:08.000000 --> 0:22:11.000000
 place to prevent a brute
 force attack like this.

0:22:11.000000 --> 0:22:14.720000
 Regardless of whether there is a password
 policy or not, you generally

0:22:14.720000 --> 0:22:18.880000
 speaking want to have something that
 prevents a brute force attack from

0:22:18.880000 --> 0:22:21.260000
 happening or happening too often.

0:22:21.260000 --> 0:22:24.100000
 So with that being said, that's
 going to be it for this video.

0:22:24.100000 --> 0:22:26.860000
 And I will be seeing you
 in the next video.