WEBVTT

0:00:03.640000 --> 0:00:06.340000
 Use the name enumeration.

0:00:06.340000 --> 0:00:13.440000
 So welcome to the next section of this
 course that will be focused on

0:00:13.440000 --> 0:00:16.100000
 authentication testing specifically.

0:00:16.100000 --> 0:00:21.820000
 So before we actually dive into session
 management testing or session

0:00:21.820000 --> 0:00:28.080000
 management as a whole, I wanted to go
 over what we covered to a certain

0:00:28.080000 --> 0:00:32.740000
 extent in the previous video when we
 were going over the methodology for

0:00:32.740000 --> 0:00:36.280000
 authentication testing.

0:00:36.280000 --> 0:00:41.520000
 And one of the techniques that really
 doesn't fall under authentication

0:00:41.520000 --> 0:00:49.620000
 testing, especially in alignment with the
 OSWSDG, is use the name enumeration.

0:00:49.620000 --> 0:00:53.640000
 So you may be asking yourself,
 well, why am I covering this?

0:00:53.640000 --> 0:00:58.500000
 Well, the reason I'm covering this
 is, you know, while this particular

0:00:58.500000 --> 0:01:03.340000
 technique falls under identity management
 or, you know, identity testing,

0:01:03.340000 --> 0:01:08.540000
 I really believe that, you know, because
 of how closely it ties in into

0:01:08.540000 --> 0:01:12.720000
 authentication, that it's probably
 something we should go over.

0:01:12.720000 --> 0:01:17.240000
 And you'll sort of get an understanding
 of what I'm referring to here.

0:01:17.240000 --> 0:01:20.920000
 So let's get started again,
 revisiting this.

0:01:20.920000 --> 0:01:23.800000
 So again, if you're already familiar
 with this, don't worry.

0:01:23.800000 --> 0:01:28.100000
 The objective here is to revisit it and
 sort of build it into our methodology

0:01:28.100000 --> 0:01:32.900000
 as a whole. And you'll actually
 find a lot of use.

0:01:32.900000 --> 0:01:34.960000
 I think you'll find a
 lot of value in this.

0:01:34.960000 --> 0:01:40.720000
 So the big question is, what is username
 enumeration, especially in the

0:01:40.720000 --> 0:01:42.700000
 context of authentication testing?

0:01:42.700000 --> 0:01:47.420000
 Well, username enumeration is a technique
 that involves testing whether

0:01:47.420000 --> 0:01:53.040000
 an attacker can determine if specific
 user names or a specific username

0:01:53.040000 --> 0:01:54.660000
 exists on a system.

0:01:54.660000 --> 0:01:57.340000
 In this case, the system would
 be a web application.

0:01:57.340000 --> 0:02:03.560000
 So while you keep that in mind, it's
 very important to understand the

0:02:03.560000 --> 0:02:07.420000
 distinction here because there is a
 distinction that needs to be made.

0:02:07.420000 --> 0:02:12.220000
 So whenever I speak about username enumeration,
 it pretty much goes without

0:02:12.220000 --> 0:02:17.460000
 saying that you'll only be performing
 this test if the website or the

0:02:17.460000 --> 0:02:24.980000
 web application you are testing has
 an authentication mechanism, most

0:02:24.980000 --> 0:02:30.520000
 likely interacting with a backend database
 regardless of the type in order

0:02:30.520000 --> 0:02:31.540000
 for this to be valid.

0:02:31.540000 --> 0:02:37.860000
 What that means is there's no point
 in trying to enumerate users if the

0:02:37.860000 --> 0:02:45.580000
 website or the web application has
 no provision for authentication or

0:02:45.580000 --> 0:02:51.180000
 user accounts as a whole, meaning
 it may just be a static website.

0:02:51.180000 --> 0:02:54.340000
 So that's something that I assume you
 know, but I think it's very important

0:02:54.340000 --> 0:02:59.500000
 to understand that these tests do not
 apply to every web app and tests

0:02:59.500000 --> 0:03:01.300000
 that you'll be performing.

0:03:01.300000 --> 0:03:05.640000
 They sort of become activated when
 you discover that a web application

0:03:05.640000 --> 0:03:13.220000
 does have a login functionality,
 for example, password reset, etc.

0:03:13.220000 --> 0:03:16.700000
 So where is this test performed?

0:03:16.700000 --> 0:03:18.580000
 That's what I was alluding
 to or getting to.

0:03:18.580000 --> 0:03:22.380000
 Well, this test is usually performed
 on login registration in password

0:03:22.380000 --> 0:03:24.320000
 recovery forms, obviously.

0:03:24.320000 --> 0:03:31.520000
 And this is done as a way of identifying
 whether specific accounts would

0:03:31.520000 --> 0:03:36.080000
 be identified by either emails
 or usernames exist.

0:03:36.080000 --> 0:03:41.480000
 So you're trying to identify whether
 a username or an email associated

0:03:41.480000 --> 0:03:47.920000
 with an account exists or that particular
 email address or username exists

0:03:47.920000 --> 0:03:51.860000
 within the web application
 backend or database.

0:03:51.860000 --> 0:03:56.160000
 So again, just think of a
 very simple login form.

0:03:56.160000 --> 0:04:03.220000
 If we are performing username enumeration,
 what I'm trying to do is sort

0:04:03.220000 --> 0:04:07.680000
 of assess whether a specific email
 or username exists or is associated

0:04:07.680000 --> 0:04:08.700000
 with an account.

0:04:08.700000 --> 0:04:10.940000
 Now, why is that important?

0:04:10.940000 --> 0:04:12.720000
 Well, we'll get into it.

0:04:12.720000 --> 0:04:16.720000
 But the primary idea is just trying to see
 whether the login form, registration

0:04:16.720000 --> 0:04:22.180000
 form, or forgot password form actually
 reveals information that could

0:04:22.180000 --> 0:04:27.920000
 be potentially useful in other attacks
 or could tell you more about the

0:04:27.920000 --> 0:04:29.440000
 web application you're testing.

0:04:29.440000 --> 0:04:32.220000
 So that brings us to the scope.

0:04:32.220000 --> 0:04:36.340000
 And a few of these excerpts have been
 taken or quoted directly from the

0:04:36.340000 --> 0:04:41.040000
 OSWSDG. I think it's important I state
 that this particular paragraph

0:04:41.040000 --> 0:04:44.940000
 is one of them. So the scope of this
 test is to verify if it is possible

0:04:44.940000 --> 0:04:49.100000
 to collect a set of valid usernames,
 typically usernames, because that's

0:04:49.100000 --> 0:04:53.140000
 what we're looking for here, by interacting
 with the authentication mechanism

0:04:53.140000 --> 0:04:55.180000
 of the application.

0:04:55.180000 --> 0:04:59.060000
 This test will be useful for brute force
 testing, obviously, because if

0:04:59.060000 --> 0:05:03.920000
 you're able to verify or validate that
 usernames exist, then that makes

0:05:03.920000 --> 0:05:09.120000
 your brute force attack much more efficient
 because you're not targeting

0:05:09.120000 --> 0:05:11.980000
 or trying to find both usernames
 and passwords.

0:05:11.980000 --> 0:05:17.060000
 You can use an identified list of usernames
 and then narrow down your

0:05:17.060000 --> 0:05:19.700000
 brute force attack to maybe
 target an admin account.

0:05:19.700000 --> 0:05:23.800000
 Let's say if you discover an admin
 account exists or an account called

0:05:23.800000 --> 0:05:30.700000
 admin. So in terms of the brute force
 attack, you're essentially verifying

0:05:30.700000 --> 0:05:38.700000
 if a valid username that we enumerated
 can actually or is using a weak

0:05:38.700000 --> 0:05:43.240000
 password, for example, or whether we
 can actually authenticate or find

0:05:43.240000 --> 0:05:46.100000
 the password for that account.

0:05:46.100000 --> 0:05:49.540000
 This can also come in the form of a dictionary
 attack where you're testing

0:05:49.540000 --> 0:05:51.060000
 for weak passwords.

0:05:51.060000 --> 0:05:55.160000
 Again, going back to the methodology
 video, when performing a structured

0:05:55.160000 --> 0:06:01.140000
 test or a thorough web app and test,
 you sort of need to fragment what

0:06:01.140000 --> 0:06:07.140000
 you would classify or what I would classify
 generally as brute force attacks.

0:06:07.140000 --> 0:06:12.020000
 There's multiple tests that can be
 done on authentication mechanisms.

0:06:12.020000 --> 0:06:16.560000
 In this case, if we take the example
 of a login form, username enumeration

0:06:16.560000 --> 0:06:22.580000
 is just one. When performing a dictionary
 attack and the distinction between

0:06:22.580000 --> 0:06:26.080000
 that and let's say a brute force attack,
 with the dictionary attack, you're

0:06:26.080000 --> 0:06:31.280000
 using the credentials, the usernames
 that you're able to find or validate

0:06:31.280000 --> 0:06:34.240000
 in terms of the existence.

0:06:34.240000 --> 0:06:40.660000
 And you're using, let's say passwords
 from data breaches or word lists

0:06:40.660000 --> 0:06:45.080000
 that have, let's say, popular passwords,
 you're essentially testing for

0:06:45.080000 --> 0:06:47.960000
 weak passwords. That's the
 whole objective there.

0:06:47.960000 --> 0:06:50.780000
 When you're talking about a brute force
 attack, you're really testing

0:06:50.780000 --> 0:06:56.400000
 the security of passwords based
 on various types of parameters.

0:06:56.400000 --> 0:07:00.360000
 So for example, if there is a password
 policy for account registration

0:07:00.360000 --> 0:07:05.180000
 that specifies the users, must have a
 password larger or longer than five

0:07:05.180000 --> 0:07:11.880000
 characters, then you generate a word
 list that meets those parameters

0:07:11.880000 --> 0:07:16.420000
 or criterion. Anyway, I'm getting on
 to a different tangent that will

0:07:16.420000 --> 0:07:18.880000
 probably explore in the
 next set of videos.

0:07:18.880000 --> 0:07:25.060000
 But proceeding on what causes this or
 how are we able to enumerate users?

0:07:25.060000 --> 0:07:27.180000
 And is this a common issue?

0:07:27.180000 --> 0:07:32.000000
 Well, this occurs or is caused when the
 web application responds differently

0:07:32.000000 --> 0:07:36.460000
 based on whether the username is valid,
 essentially allowing attackers

0:07:36.460000 --> 0:07:41.600000
 to infer the presence or absence
 of specific usernames.

0:07:41.600000 --> 0:07:46.940000
 Quite often, web applications reveal
 when a username exists on a system,

0:07:46.940000 --> 0:07:51.420000
 either as a consequence of misconfiguration
 or as a design decision, which

0:07:51.420000 --> 0:07:52.740000
 will not get into.

0:07:52.740000 --> 0:07:58.980000
 There's many reasons, really, especially
 on the design front, whether

0:07:58.980000 --> 0:08:08.520000
 in terms of whether a particular authentication
 mechanism should be, let's

0:08:08.520000 --> 0:08:13.480000
 say verbose or should be limited in
 terms of the information it returns.

0:08:13.480000 --> 0:08:18.260000
 So if we use an example here, sometimes
 when, let's say, you submit incorrect

0:08:18.260000 --> 0:08:24.000000
 credentials, you may receive a message
 that states that either the username

0:08:24.000000 --> 0:08:28.180000
 is present on the system or the
 provided password is wrong.

0:08:28.180000 --> 0:08:33.340000
 So a typical variation of this is, again,
 let's say we have a login form,

0:08:33.340000 --> 0:08:35.900000
 it's a username and password.

0:08:35.900000 --> 0:08:44.360000
 In my opinion, a properly configured login
 form or authentication mechanism

0:08:44.360000 --> 0:08:49.660000
 would essentially state that if incorrect
 credentials are provided, it'll

0:08:49.660000 --> 0:08:54.720000
 not tell you which one is incorrect
 or just say incorrect or the account

0:08:54.720000 --> 0:09:01.380000
 doesn't exist. So this is not something
 that I'll really speak on from

0:09:01.380000 --> 0:09:08.840000
 a design perspective, but let's say
 a misconfigured one would say, let's

0:09:08.840000 --> 0:09:14.460000
 say we entered a username and a password
 and the username actually exists.

0:09:14.460000 --> 0:09:16.300000
 So it's linked to an account that exists.


0:09:16.300000 --> 0:09:20.500000
 The login form would return and say, your
 password is incorrect, essentially

0:09:20.500000 --> 0:09:26.260000
 telling you that the username is correct,
 therefore validating that it

0:09:26.260000 --> 0:09:30.780000
 exists. Anyway, we'll take a look at
 a proper attack flow or a logical

0:09:30.780000 --> 0:09:34.980000
 flow that explains how this works
 from an attacker's perspective.

0:09:34.980000 --> 0:09:39.220000
 So this information obtained or the
 usernames that you obtained can then

0:09:39.220000 --> 0:09:43.800000
 be used by an attacker or by yourself
 to gain a list of users on the system,

0:09:43.800000 --> 0:09:47.780000
 valid users, and this information can
 be used to attack the web application

0:09:47.780000 --> 0:09:53.700000
 through a brute force attack or you can
 also test for default credentials.

0:09:53.700000 --> 0:10:01.640000
 I know that I'm going into quite a
 bit of detail, especially given how

0:10:01.640000 --> 0:10:06.380000
 simplistic this type of attack is,
 but let's use one final example and

0:10:06.380000 --> 0:10:08.780000
 then we'll go into a lab demo.

0:10:08.780000 --> 0:10:13.640000
 If we take a very basic example of
 a login page returns distinct error

0:10:13.640000 --> 0:10:17.960000
 messages, an example of this would
 be invalid username versus invalid

0:10:17.960000 --> 0:10:23.640000
 password. An attacker could use this information
 to confirm valid usernames,

0:10:23.640000 --> 0:10:25.160000
 right? That makes sense.

0:10:25.160000 --> 0:10:28.360000
 The attacker can then use these credentials
 as I said for a brute force

0:10:28.360000 --> 0:10:31.160000
 attack or to test for weak credentials.

0:10:31.160000 --> 0:10:34.380000
 This vulnerability can also appear, it's
 very important to note, can also

0:10:34.380000 --> 0:10:38.520000
 appear in other forms such as different
 HTTP status codes, page load times

0:10:38.520000 --> 0:10:41.780000
 or error messages, and that's some
 of the stuff that I'll be trying to

0:10:41.780000 --> 0:10:44.640000
 explain in the practical
 lab demonstration here.

0:10:44.640000 --> 0:10:49.340000
 But this flow chart pretty much explains
 what the attack looks like from

0:10:49.340000 --> 0:10:54.160000
 a, you know, from a logical perspective.

0:10:54.160000 --> 0:10:59.520000
 So we can see that the user submits information
 or submits the login form.

0:10:59.520000 --> 0:11:02.020000
 If the, is the username valid?

0:11:02.020000 --> 0:11:08.300000
 If it is, then the web application
 returns a success message, right?

0:11:08.300000 --> 0:11:11.960000
 And I've already explained what that is.

0:11:11.960000 --> 0:11:16.820000
 You know, you'll be able to log in as one
 example, but let's say the username

0:11:16.820000 --> 0:11:22.180000
 is not valid. Well, then, and again,
 this is an example of how it works

0:11:22.180000 --> 0:11:25.680000
 in a misconfigured, you
 know, web application.

0:11:25.680000 --> 0:11:27.500000
 So the system returns an error message.

0:11:27.500000 --> 0:11:32.260000
 Now, is the error, is the error
 message specific to a username?

0:11:32.260000 --> 0:11:37.860000
 So does it say, you know, using your
 vendor in an incorrect password or

0:11:37.860000 --> 0:11:40.340000
 the username is incorrect?

0:11:40.340000 --> 0:11:46.900000
 So in this case, if, you know, the error
 message is specific to the username,

0:11:46.900000 --> 0:11:50.100000
 then that means the username is valid
 and enumerated and the attacker

0:11:50.100000 --> 0:11:55.040000
 pretty much continues it or repeats
 through this cycle with a different

0:11:55.040000 --> 0:11:59.780000
 username. If no error message is returned
 or it's, let's say, vague, then

0:11:59.780000 --> 0:12:01.660000
 no username information is gathered.

0:12:01.660000 --> 0:12:05.500000
 So what that, what this is referring
 to is this example here.

0:12:05.500000 --> 0:12:09.120000
 So let's say you, you know, you put in
 a username and password combination

0:12:09.120000 --> 0:12:16.700000
 and the web application returns and says,
 hey, that's an incorrect username.

0:12:16.700000 --> 0:12:21.600000
 In that case, you know, that's essentially
 telling you that that username

0:12:21.600000 --> 0:12:27.580000
 doesn't exist. Now, let's say a username
 exists and the password is incorrect,

0:12:27.580000 --> 0:12:29.460000
 obviously, because you wouldn't know it.

0:12:29.460000 --> 0:12:32.700000
 Then in that case, you would be looking
 for a message like invalid password

0:12:32.700000 --> 0:12:37.260000
 that tells you, yes, that you say exists,
 but the password is incorrect.

0:12:37.260000 --> 0:12:39.180000
 So just keep that in mind.

0:12:39.180000 --> 0:12:42.540000
 Now, to sort of show you how this works
 or the, you know, the various

0:12:42.540000 --> 0:12:46.860000
 ways of testing this, I'm going to
 be using a deliberately vulnerable

0:12:46.860000 --> 0:12:48.960000
 web application to demonstrate this.

0:12:48.960000 --> 0:12:53.380000
 Now, you know, I know probably you'll
 have some reservations about that

0:12:53.380000 --> 0:12:57.780000
 and how realistic it is, but I'm really
 focused on the techniques behind

0:12:57.780000 --> 0:13:02.640000
 this because that's really the most important,
 especially in this context,

0:13:02.640000 --> 0:13:06.680000
 as we progress with other videos and
 demonstrations will be, you know,

0:13:06.680000 --> 0:13:10.140000
 will actually be exploiting or identifying
 and exploiting vulnerabilities

0:13:10.140000 --> 0:13:13.060000
 in real world web applications.

0:13:13.060000 --> 0:13:19.000000
 But for this one, I feel that the, we'll
 be using a web goat, you know,

0:13:19.000000 --> 0:13:24.500000
 it really does a great job at explaining
 just how diverse username and

0:13:24.500000 --> 0:13:29.000000
 enumeration can be in terms of the
 authentication mechanism, etc.

0:13:29.000000 --> 0:13:32.460000
 So this lab will be directly
 under this video.

0:13:32.460000 --> 0:13:36.080000
 And one key thing to note is that this
 lab will not provide you, will

0:13:36.080000 --> 0:13:40.840000
 not provide you with a Kali Linux system
 or a system through which you

0:13:40.840000 --> 0:13:51.600000
 can use your host operating system
 and not use a virtual machine.

0:13:51.600000 --> 0:13:55.520000
 The only tool you need or that
 we will be using is burp suite.

0:13:55.520000 --> 0:13:59.340000
 So if you have burp suite on your host
 operating system, then you're pretty

0:13:59.340000 --> 0:14:00.160000
 much good to go.

0:14:00.160000 --> 0:14:03.160000
 So when you stop the lab, it'll take
 out, you know, a couple of seconds

0:14:03.160000 --> 0:14:08.520000
 and it'll bring up web goat in
 a URL or within your browser.

0:14:08.520000 --> 0:14:10.620000
 And you can pretty much
 test it from there.

0:14:10.620000 --> 0:14:13.480000
 So with that being said, let's
 not waste too much time.

0:14:13.480000 --> 0:14:17.440000
 I'm going to switch over
 into my virtual machine.

0:14:17.440000 --> 0:14:19.100000
 You know, I have started the lab.

0:14:19.100000 --> 0:14:22.240000
 So just need to open up the URL
 and we should be good to go.

0:14:22.240000 --> 0:14:23.920000
 So I'll see you there.

0:14:23.920000 --> 0:14:29.680000
 All right. So I'm currently within
 my Kali Linux virtual machine.

0:14:29.680000 --> 0:14:33.340000
 And when you start the lab, you'll
 get a URL similar to this.

0:14:33.340000 --> 0:14:37.760000
 Or I should say, when you click on the
 lab link, you'll get a web application

0:14:37.760000 --> 0:14:38.680000
 called web goat.

0:14:38.680000 --> 0:14:40.280000
 Some of you may be familiar with it.

0:14:40.280000 --> 0:14:44.340000
 It is a deliberately vulnerable web
 application that again is used to

0:14:44.340000 --> 0:14:47.360000
 demonstrate or to teach these techniques.


0:14:47.360000 --> 0:14:52.900000
 Now, the login page will be provided
 or you'll be prompted with when you,

0:14:52.900000 --> 0:14:58.240000
 you know, you open up the link is going
 to be the actual login form to

0:14:58.240000 --> 0:15:00.080000
 access web goat.

0:15:00.080000 --> 0:15:03.220000
 So we're not testing this per se, although
 that would be quite interesting

0:15:03.220000 --> 0:15:09.420000
 to do. You can see that we can use any of
 these accounts to perform essentially

0:15:09.420000 --> 0:15:15.480000
 to log in. So we'll just use the default
 admin ones, which is just a web

0:15:15.480000 --> 0:15:20.180000
 goat. And for the username and
 web goat for the password.

0:15:20.180000 --> 0:15:23.200000
 So this is not related to the technique
 here, the, you know, username

0:15:23.200000 --> 0:15:24.780000
 and enumeration.

0:15:24.780000 --> 0:15:29.560000
 But we'll just log in here
 and give it a few seconds.

0:15:29.560000 --> 0:15:31.520000
 Let's see, it's loading up.

0:15:31.520000 --> 0:15:35.880000
 So the key area to focus
 on is the sidebar here.

0:15:35.880000 --> 0:15:39.440000
 And you know, it has a list of various
 web application vulnerabilities

0:15:39.440000 --> 0:15:43.760000
 where you can learn how to
 identify and exploit them.

0:15:43.760000 --> 0:15:45.900000
 So it's a great, you know,
 web application.

0:15:45.900000 --> 0:15:50.960000
 And I really like this, especially,
 really like web goat, especially,

0:15:50.960000 --> 0:15:53.540000
 you know, when explaining
 authentication attacks.

0:15:53.540000 --> 0:15:57.680000
 So you want to go under authentication
 flaws, just click on the dropdown

0:15:57.680000 --> 0:16:01.120000
 here. And you're going to see
 forgot password, right?

0:16:01.120000 --> 0:16:02.580000
 That's the one we want.

0:16:02.580000 --> 0:16:05.740000
 So if you remember in the slides, I mentioned
 that this is not just restricted

0:16:05.740000 --> 0:16:12.700000
 to login forms. Pretty much any authentication
 mechanism will work.

0:16:12.700000 --> 0:16:17.700000
 And the reason why I'm sort of highlighting
 the forgotten password functionality

0:16:17.700000 --> 0:16:22.180000
 is because in modern web applications,
 this is where username and enumeration

0:16:22.180000 --> 0:16:24.240000
 is quite prevalent.

0:16:24.240000 --> 0:16:29.720000
 So if you review various bug bounty
 reports, you know, pretty much any

0:16:29.720000 --> 0:16:34.720000
 disclosure of vulnerabilities that are
 public, especially related to username

0:16:34.720000 --> 0:16:38.720000
 and enumeration, you'll typically see
 that a majority of them will be

0:16:38.720000 --> 0:16:44.280000
 with regards to or will be referencing
 the forgot password page or form.

0:16:44.280000 --> 0:16:48.100000
 And that actually makes sense if you
 think about it, because in order

0:16:48.100000 --> 0:16:52.400000
 to reset your password, again, let's
 say if you had an account within,

0:16:52.400000 --> 0:16:57.140000
 you know, on a web application, what's
 the piece of information that's

0:16:57.140000 --> 0:17:01.240000
 important? It's either going to be the
 username or the password, right?

0:17:01.240000 --> 0:17:07.620000
 And generally speaking, one mechanism
 or one way that, you know, modern

0:17:07.620000 --> 0:17:11.920000
 web applications are built to counter
 this type of attack is that they

0:17:11.920000 --> 0:17:16.460000
 do not, you know, they do not return
 any message that indicates whether

0:17:16.460000 --> 0:17:18.860000
 the username exists or doesn't exist.

0:17:18.860000 --> 0:17:22.640000
 So what we're testing for here is to
 see whether this webgoed password

0:17:22.640000 --> 0:17:29.300000
 recovery form actually, actually returns
 any info that can tell us, you

0:17:29.300000 --> 0:17:30.600000
 know, whether they use exist.

0:17:30.600000 --> 0:17:33.720000
 So we'll not go with webgo to
 admin or anything like that.

0:17:33.720000 --> 0:17:38.380000
 We'll just go with again, I'll use my
 name Alexis right over here, I hit

0:17:38.380000 --> 0:17:41.680000
 submit. And this is exactly
 what we're looking for.

0:17:41.680000 --> 0:17:43.800000
 So it says not a valid username.

0:17:43.800000 --> 0:17:47.920000
 Now again, in real world web applications,
 it's typically going to be

0:17:47.920000 --> 0:17:49.420000
 your email, right?

0:17:49.420000 --> 0:17:53.360000
 And then after that, again, if the
 account does exist, you'll receive

0:17:53.360000 --> 0:17:57.680000
 an email with a password reset link
 or code really doesn't matter.

0:17:57.680000 --> 0:18:01.960000
 But in properly configured web applications,
 it'll not tell you anything.

0:18:01.960000 --> 0:18:05.480000
 It'll just say that if your account
 exists, it's going to send you an

0:18:05.480000 --> 0:18:09.620000
 email. So this is generally speaking what
 you're looking for or a variation

0:18:09.620000 --> 0:18:11.240000
 of what you're looking for.

0:18:11.240000 --> 0:18:16.900000
 So you can see that it tells us
 that that's not a doesn't exist.

0:18:16.900000 --> 0:18:20.720000
 Now, if I go for something like, you
 know, let's say goat, let's submit

0:18:20.720000 --> 0:18:22.580000
 that, doesn't exist.

0:18:22.580000 --> 0:18:28.140000
 If I go for admin, let's see where that
 exists, looks like it does exist.

0:18:28.140000 --> 0:18:30.980000
 And then it says secret question,
 what is your favorite color?

0:18:30.980000 --> 0:18:35.620000
 So these are sort of the security
 questions, right?

0:18:35.620000 --> 0:18:40.740000
 So based on that, we're able to determine
 that yes, you know, the admin

0:18:40.740000 --> 0:18:46.000000
 account or the admin user exists, which
 means we can now brute force the

0:18:46.000000 --> 0:18:52.520000
 the web goat login form and try and
 find a password for the admin user.

0:18:52.520000 --> 0:18:57.660000
 So in essence, that's what
 this is all about now.

0:18:57.660000 --> 0:19:03.740000
 What we can do to automate this, which
 is sort of sort of the crux of

0:19:03.740000 --> 0:19:10.760000
 what I wanted to go over, is to, you
 know, essentially intercept this

0:19:10.760000 --> 0:19:16.420000
 request, which I believe should be a
 post request and then utilize, let's

0:19:16.420000 --> 0:19:24.680000
 say burp suite, intruder module, and
 try and brute force the user names.

0:19:24.680000 --> 0:19:27.200000
 And I'll sort of explain
 how this is done.

0:19:27.200000 --> 0:19:32.740000
 Now, one thing to keep in mind is,
 let me restart this session here.

0:19:32.740000 --> 0:19:36.880000
 One thing that's very important when automating
 this process of identifying

0:19:36.880000 --> 0:19:42.000000
 legitimate of identifying legitimate
 usernames is to pay attention to

0:19:42.000000 --> 0:19:44.200000
 the error message displayed.

0:19:44.200000 --> 0:19:48.100000
 So again, if I type in Alexis, in this
 case, the web application or the

0:19:48.100000 --> 0:19:51.920000
 error message looks fairly, it's pretty
 much the same for any incorrect

0:19:51.920000 --> 0:19:56.960000
 username. So we want to keep this in
 mind because this is what we'll be

0:19:56.960000 --> 0:20:02.100000
 looking to filter out, you know,
 when using burp suites in trudus.

0:20:02.100000 --> 0:20:06.000000
 I'm just going to paste
 this in mousepad here.

0:20:06.000000 --> 0:20:11.520000
 But regardless, I'm going to open
 up burp suite right over here.

0:20:11.520000 --> 0:20:15.340000
 And again, as I said, you don't need
 to go through this demo in your own

0:20:15.340000 --> 0:20:16.300000
 virtual machine.

0:20:16.300000 --> 0:20:19.280000
 If you have burp suite installed, again,
 the community edition will do

0:20:19.280000 --> 0:20:21.720000
 just fine. You should be good to go.

0:20:21.720000 --> 0:20:28.160000
 If you're more comfortable using zap,
 that's entirely up to you as well.

0:20:28.160000 --> 0:20:32.980000
 So based on what I just showed you,
 the key thing to understand is that

0:20:32.980000 --> 0:20:36.280000
 the response is going to
 be different, right?

0:20:36.280000 --> 0:20:39.800000
 If the username is correct or incorrect.

0:20:39.800000 --> 0:20:45.220000
 So I'm just going to open up the
 default burp suite browser.

0:20:45.220000 --> 0:20:49.620000
 So you know, I don't have to do any
 proxy modifications on Firefox.

0:20:49.620000 --> 0:20:54.320000
 So there we go. One thing I'll also
 do to make it easier for you guys

0:20:54.320000 --> 0:21:00.260000
 to see is I'll increase the font size
 ever so slightly so you can actually

0:21:00.260000 --> 0:21:02.060000
 see things a little bit better.

0:21:02.060000 --> 0:21:07.360000
 Anyway, I'll go, I'll just
 copy this URL here.

0:21:07.360000 --> 0:21:15.180000
 I'll just copy this URL here and I'll
 open it up in chromium here or burp's

0:21:15.180000 --> 0:21:20.840000
 web browser. So paste and go, we'll
 have to log in again, which is fine.

0:21:20.840000 --> 0:21:25.460000
 So we'll just log in with the web good
 admin, which is just web good and

0:21:25.460000 --> 0:21:29.760000
 web good, like so, right over here.

0:21:29.760000 --> 0:21:34.640000
 And we don't have intercept on,
 which is actually what we want.

0:21:34.640000 --> 0:21:39.360000
 We're going to go into authentication
 floors for God password.

0:21:39.360000 --> 0:21:41.400000
 And now we're going to intercept.

0:21:41.400000 --> 0:21:44.440000
 So I'm just going to click
 on intercept on.

0:21:44.440000 --> 0:21:47.260000
 There we go. And now we'll
 just test Alexis.

0:21:47.260000 --> 0:21:50.240000
 Right. So something that's incorrect.

0:21:50.240000 --> 0:21:53.640000
 Hit submit, I'll go back into burp here.

0:21:53.640000 --> 0:21:56.420000
 Let's see, did we submit this here?

0:21:56.420000 --> 0:21:57.920000
 There we are. Okay, excellent.

0:21:57.920000 --> 0:22:01.600000
 So we can see that request here.

0:22:01.600000 --> 0:22:08.660000
 And we can see that the request is,
 let me increase the font size.

0:22:08.660000 --> 0:22:13.820000
 So display, we're going
 to say right over here.

0:22:13.820000 --> 0:22:20.620000
 If we go into the user interface, message
 editor, let's change that to

0:22:20.620000 --> 0:22:25.100000
 maybe 14. Actually, let's make
 that a little bit bigger.

0:22:25.100000 --> 0:22:29.000000
 So there we go. Okay, so you
 can see the request now.

0:22:29.000000 --> 0:22:32.220000
 So we have a cookie, we'll not
 touch on that right now.

0:22:32.220000 --> 0:22:37.320000
 We then have the post request with
 some parameters and values there.

0:22:37.320000 --> 0:22:40.940000
 But the primary, what we're looking
 for is the body here, where we have

0:22:40.940000 --> 0:22:45.280000
 the username parameter, which is just
 the value we specified, and then

0:22:45.280000 --> 0:22:49.460000
 submit action. So we can actually
 send this to the intruder.

0:22:49.460000 --> 0:22:55.200000
 And in the intruder, we are going to
 use, in this case, we'll use the

0:22:55.200000 --> 0:22:57.720000
 sniper attack module here.

0:22:57.720000 --> 0:23:02.660000
 We want to add the username
 value as a position, right?

0:23:02.660000 --> 0:23:05.360000
 Or the insertion position, I should say.

0:23:05.360000 --> 0:23:07.120000
 So I'll add that there.

0:23:07.120000 --> 0:23:13.660000
 And now in here, what we're going to
 do is, and again, you can use any

0:23:13.660000 --> 0:23:19.640000
 word list, sorry, I should say word
 list, any list of usernames to test

0:23:19.640000 --> 0:23:26.500000
 for, you know, to actually perform
 the automated username enumeration.

0:23:26.500000 --> 0:23:32.300000
 So what I'm going to do is, I'm going to
 load, I'm going to use the Metasploit

0:23:32.300000 --> 0:23:41.140000
 word list. So user share, I'm going
 to look for Metasploit over here.

0:23:41.140000 --> 0:23:45.560000
 And this can either be, actually, we
 can actually going to use a share

0:23:45.560000 --> 0:23:57.400000
 word lists. So let's see, where do
 we have the one that has usernames?

0:23:57.400000 --> 0:23:59.700000
 Again, this, I'm just using
 this as a demonstration.

0:23:59.700000 --> 0:24:07.600000
 So I believe we should have default
 users right over here, HTTP default

0:24:07.600000 --> 0:24:12.340000
 users. So again, in this case, it's kind
 of funny, we're testing for default

0:24:12.340000 --> 0:24:17.220000
 credentials. But really, what we're
 doing is trying to see whether any

0:24:17.220000 --> 0:24:20.320000
 of them exist in the, you know, in the
 first place before we do anything

0:24:20.320000 --> 0:24:31.080000
 else. Now, what we want to do is,
 we want to do some matching here.

0:24:31.080000 --> 0:24:45.460000
 So, if we go into, well, we essentially
 want to filter out, or filter

0:24:45.460000 --> 0:24:47.780000
 for, let's say invalid username.

0:24:47.780000 --> 0:24:55.600000
 So we just go in here and say add, sorry,
 let's say add payload processing,

0:24:55.600000 --> 0:25:01.560000
 we're going to look for, let's see,
 do we have grep in here, match and

0:25:01.560000 --> 0:25:06.560000
 replace. Now, we don't want to do any.

0:25:06.560000 --> 0:25:13.700000
 So let's see here, we will do a match.

0:25:13.700000 --> 0:25:16.380000
 So match rejects.

0:25:16.380000 --> 0:25:24.400000
 Actually, do we need to have, we can
 use a sort of, let's instead of using

0:25:24.400000 --> 0:25:29.320000
 rejects, can we use a,
 no, let's use rejects.

0:25:29.320000 --> 0:25:33.060000
 So match replace.

0:25:33.060000 --> 0:25:43.900000
 Yeah, we can just use
 a match replace here.

0:25:43.900000 --> 0:25:52.320000
 So, you know, we can essentially
 match for this over here.

0:25:52.320000 --> 0:25:57.640000
 So we will just say not a valid username,
 and we can keep it very, very

0:25:57.640000 --> 0:26:02.780000
 simple. And then hit OK.

0:26:02.780000 --> 0:26:10.160000
 We don't replace it with anything per
 say, but actually hold on, we might

0:26:10.160000 --> 0:26:17.000000
 want to do something here, replace
 it with, we'll just say invalid.

0:26:17.000000 --> 0:26:21.580000
 So now we can pretty much
 just start the attack.

0:26:21.580000 --> 0:26:28.760000
 And we're going to look for
 variations in the responses.

0:26:28.760000 --> 0:26:33.000000
 So you can see the response column
 here, response received.

0:26:33.000000 --> 0:26:38.340000
 We're looking at the size and variations
 in the response sizes.

0:26:38.340000 --> 0:26:45.060000
 And you can see that for the most part,
 256, we view the response here

0:26:45.060000 --> 0:26:47.440000
 for the username admin.

0:26:47.440000 --> 0:26:53.220000
 If we take a look at this in rendered
 format, that looks like that user

0:26:53.220000 --> 0:27:00.340000
 exists, right? If we take a look
 at manager, that's invalid.

0:27:00.340000 --> 0:27:04.580000
 So 256, but then we have 255 here.

0:27:04.580000 --> 0:27:12.840000
 And that seems to be a slight difference,
 which I guess is fine, but 256,

0:27:12.840000 --> 0:27:19.280000
 257, not valid. And then
 255, that's invalid.

0:27:19.280000 --> 0:27:25.740000
 So it looks like 256, or at least some
 of them, I should say, the response

0:27:25.740000 --> 0:27:29.860000
 received 256. We take a look at the
 length and variations in the length.

0:27:29.860000 --> 0:27:41.100000
 It looks like 1524 seems to be the
 case or the length of the response

0:27:41.100000 --> 0:27:46.780000
 when, you know, the username is invalid
 or that, you know, that username

0:27:46.780000 --> 0:27:52.840000
 doesn't exist. When it does exist, it's
 1434 over here under the actual

0:27:52.840000 --> 0:27:54.460000
 length of the response.

0:27:54.460000 --> 0:27:56.580000
 So we can see that there.

0:27:56.580000 --> 0:28:00.940000
 And then if we look for any other occurrences
 here, we can see any 1434.

0:28:00.940000 --> 0:28:05.220000
 And indeed, if we go to all of the
 rest here that we did test for, you

0:28:05.220000 --> 0:28:07.020000
 can see that they're all invalid.

0:28:07.020000 --> 0:28:10.820000
 So, yeah, fairly interesting.

0:28:10.820000 --> 0:28:14.740000
 The only username we're able
 to identify is admin.

0:28:14.740000 --> 0:28:15.840000
 So we know that that exists.

0:28:15.840000 --> 0:28:22.140000
 And of course, you know, depending on
 what you're using, what word list

0:28:22.140000 --> 0:28:27.480000
 you're using, you know, to test for usernames,
 either, you know, if you're

0:28:27.480000 --> 0:28:34.180000
 using any of the, you know, defaults
 or some common ones, you'll find,

0:28:34.180000 --> 0:28:36.480000
 you know, different results.

0:28:36.480000 --> 0:28:39.940000
 So there's many that we can try here.

0:28:39.940000 --> 0:28:44.800000
 So in that case, let's use
 for another users here.

0:28:44.800000 --> 0:28:47.740000
 So default users for services.

0:28:47.740000 --> 0:28:51.300000
 Now that's probably not
 going to be that useful.

0:28:51.300000 --> 0:28:54.020000
 Default users is what we used.

0:28:54.020000 --> 0:28:56.480000
 Let's look for Mirai.

0:28:56.480000 --> 0:28:59.240000
 Maybe that might be quite large.

0:28:59.240000 --> 0:29:01.220000
 Actually looks perfectly fine.

0:29:01.220000 --> 0:29:03.220000
 So start attack.

0:29:03.220000 --> 0:29:07.600000
 And 15241434. So admin, we
 verified that previously.

0:29:07.600000 --> 0:29:10.980000
 Let's see if we can find any 1434.

0:29:10.980000 --> 0:29:14.640000
 And I'll show you something
 interesting here.

0:29:14.640000 --> 0:29:29.440000
 Or what we can essentially look for
 when, when trying to display or flag

0:29:29.440000 --> 0:29:34.840000
 the usernames or the responses that
 indicate that a username exists.

0:29:34.840000 --> 0:29:40.640000
 So in this case, looks like even with
 this user list, only admin seems

0:29:40.640000 --> 0:29:42.120000
 to be legitimate.

0:29:42.120000 --> 0:29:48.160000
 So okay, let's close this
 up and discard that.

0:29:48.160000 --> 0:30:05.460000
 One thing I want to show you, in fact,
 in fact, let's enable this because

0:30:05.460000 --> 0:30:07.360000
 I hadn't enabled it previously.

0:30:07.360000 --> 0:30:10.340000
 And let's just start this attack.

0:30:10.340000 --> 0:30:16.200000
 And let's see the response here.

0:30:16.200000 --> 0:30:18.680000
 I'm just going to render it here.

0:30:18.680000 --> 0:30:21.320000
 Payload processing.

0:30:21.320000 --> 0:30:28.800000
 Okay, so so response completed.

0:30:28.800000 --> 0:30:30.840000
 We don't need to add any filter there.

0:30:30.840000 --> 0:30:33.020000
 We go and close this up here.

0:30:33.020000 --> 0:30:35.120000
 So I'm going to discard that.

0:30:35.120000 --> 0:30:40.320000
 Let's go into settings
 and let us grep here.

0:30:40.320000 --> 0:30:46.500000
 I'm going to clear grep match here.

0:30:46.500000 --> 0:30:53.620000
 So what we want to do,
 let's clear this out.

0:30:53.620000 --> 0:30:57.880000
 And we want to flag responses
 matching specific expressions.

0:30:57.880000 --> 0:31:02.260000
 And we're going to add
 not a valid username.

0:31:02.260000 --> 0:31:05.020000
 We'll keep it simple string.

0:31:05.020000 --> 0:31:09.080000
 We could go for case sensitive, although
 I don't think that would be useful.

0:31:09.080000 --> 0:31:10.940000
 So we'll add that there.

0:31:10.940000 --> 0:31:18.120000
 And let's go into payloads and let's
 disable that because I wanted to

0:31:18.120000 --> 0:31:29.000000
 essentially check if that modified if that
 essentially modified the responses.

0:31:29.000000 --> 0:31:32.420000
 But yeah, so we can just
 start that again.

0:31:32.420000 --> 0:31:41.940000
 And now you can see right over here.

0:31:41.940000 --> 0:31:50.440000
 Not a valid user where the default option
 is one, which is quite interesting.

0:31:50.440000 --> 0:31:57.020000
 So that means, yeah, this column here
 represents the users that are not

0:31:57.020000 --> 0:32:02.320000
 valid, where there's no misvalid.

0:32:02.320000 --> 0:32:05.240000
 In this case, we can see
 admin is indeed valid.

0:32:05.240000 --> 0:32:10.480000
 So again, apologies for going through
 this quite extensively.

0:32:10.480000 --> 0:32:13.800000
 So we want to flag that response.

0:32:13.800000 --> 0:32:17.760000
 This should be a way to actually flag
 it differently or to turn that into

0:32:17.760000 --> 0:32:32.900000
 a checkbox, but exclude HTTP Heather,
 Heather, and then we can also do

0:32:32.900000 --> 0:32:34.100000
 some extraction.

0:32:34.100000 --> 0:32:41.040000
 But actually, we don't need to do
 much beyond that redirection.

0:32:41.040000 --> 0:32:41.960000
 There's nothing in there.

0:32:41.960000 --> 0:32:47.660000
 So payloads, if we edit this one
 here, not a valid username.

0:32:47.660000 --> 0:32:51.480000
 Actually, that would not make much sense.


0:32:51.480000 --> 0:32:52.660000
 So let's remove that there.

0:32:52.660000 --> 0:32:55.600000
 Start that again.

0:32:55.600000 --> 0:33:02.240000
 Yeah, that seems to work.

0:33:02.240000 --> 0:33:05.780000
 Yeah, and this essentially tells
 us where we have no value.

0:33:05.780000 --> 0:33:10.240000
 You can see that it tells us that that
 is pretty much an account that

0:33:10.240000 --> 0:33:16.800000
 exists. So apologies for the long-winded
 demonstration here, but I just

0:33:16.800000 --> 0:33:19.500000
 want to show you the various
 ways you can do this.

0:33:19.500000 --> 0:33:23.520000
 And of course, from this point on,
 you can then try and attack.

0:33:23.520000 --> 0:33:29.320000
 You can then try and perform a dictionary
 attack or brute force attack

0:33:29.320000 --> 0:33:32.480000
 on this particular username.

0:33:32.480000 --> 0:33:33.900000
 But quite interesting.

0:33:33.900000 --> 0:33:38.280000
 So yeah, that being said, that brings us
 to the end of the practical demonstration

0:33:38.280000 --> 0:33:42.800000
 side of this video, and I'll
 see you back in the slides.

0:33:42.800000 --> 0:33:46.280000
 All right, so that was username
 and enumeration.

0:33:46.280000 --> 0:33:49.200000
 I said the policy is for
 the long demonstration.

0:33:49.200000 --> 0:33:53.940000
 I just wanted to give you a feel for
 how to actually test for this or

0:33:53.940000 --> 0:33:55.800000
 to perform this test.

0:33:55.800000 --> 0:34:01.240000
 With that being said, we're now going to
 turn our attention to the authentication

0:34:01.240000 --> 0:34:08.680000
 tests that were listed out explicitly
 in the OSWSDG and look in a couple

0:34:08.680000 --> 0:34:14.760000
 of variations using real-world web
 applications so that again, you get

0:34:14.760000 --> 0:34:20.020000
 this practical tacit hands-on feel
 for these vulnerabilities or how to

0:34:20.020000 --> 0:34:26.920000
 test for these vulnerabilities.

0:34:26.920000 --> 0:34:27.820000
 So with the next video.