WEBVTT

0:00:04.100000 --> 0:00:08.620000
 Attacking login forms with OTP security.

0:00:08.620000 --> 0:00:16.000000
 So in this video, we're going to be taking
 a look at how to attack websites

0:00:16.000000 --> 0:00:21.960000
 or web applications with authentication
 mechanisms like login forms that

0:00:21.960000 --> 0:00:28.020000
 are protected by a form or a type
 of two factor authentication.

0:00:28.020000 --> 0:00:31.500000
 In this case, that's going to be OTP.

0:00:31.500000 --> 0:00:38.440000
 All right, so I believe I introduced
 you to OTP earlier on in this course

0:00:38.440000 --> 0:00:45.960000
 when we were exploring various forms
 of various forms of authentication,

0:00:45.960000 --> 0:00:57.500000
 but more specifically when we briefly
 touched on two factor in order for

0:00:57.500000 --> 0:00:58.960000
 you to understand it.

0:00:58.960000 --> 0:01:01.360000
 All right, so what is OTP?

0:01:01.360000 --> 0:01:05.000000
 OTP stands for a one time password.

0:01:05.000000 --> 0:01:11.280000
 Okay. And when we refer to OTP security, this
 is really a two factor authentication

0:01:11.280000 --> 0:01:16.400000
 method or mechanism that's used to enhance
 the security of user accounts

0:01:16.400000 --> 0:01:22.700000
 and systems. The key thing to note is
 that OTPs are temporary single use

0:01:22.700000 --> 0:01:27.500000
 codes that are typically generated and
 sent to the user's registered device,

0:01:27.500000 --> 0:01:33.800000
 such as a mobile phone or to your inbox,
 your email inbox in order to

0:01:33.800000 --> 0:01:38.420000
 verify, you know, their identity during
 login or, you know, transaction

0:01:38.420000 --> 0:01:43.660000
 processes. So it's sort of a way for
 the web application to say, yeah,

0:01:43.660000 --> 0:01:48.640000
 I know you've signed in and you
 know, you are authenticated.

0:01:48.640000 --> 0:01:56.140000
 However, because what you're trying to
 perform is so, let's say, is quite

0:01:56.140000 --> 0:01:59.760000
 critical, you know, in many ways, whether
 it be a financial application

0:01:59.760000 --> 0:02:02.640000
 or, you know, a transaction of that sort.


0:02:02.640000 --> 0:02:05.600000
 The bottom line is that when you're
 performing actions that let's say

0:02:05.600000 --> 0:02:10.500000
 are quite important or are deemed important,
 this is where you generally

0:02:10.500000 --> 0:02:17.480000
 speaking want to have OTP in order
 to verify the identity of the, you

0:02:17.480000 --> 0:02:20.060000
 know, of the individual
 performing the action.

0:02:20.060000 --> 0:02:24.700000
 So they sort of want to verify whether,
 you know, because this action,

0:02:24.700000 --> 0:02:29.380000
 you know, can potentially have an impact
 on you, let's say you own an

0:02:29.380000 --> 0:02:33.640000
 account, you know, let's say
 something like PayPal, right?

0:02:33.640000 --> 0:02:40.200000
 Or any other payment processor out
 there, you know, being logged in is

0:02:40.200000 --> 0:02:43.000000
 one thing and, you know, viewing
 your account details.

0:02:43.000000 --> 0:02:47.180000
 But let's say, you know, you wanted transfer
 money, well, the web application

0:02:47.180000 --> 0:02:50.100000
 understands that, yes,
 you are authenticated.

0:02:50.100000 --> 0:02:56.720000
 However, because, you know, the transfer
 of funds as an example is so

0:02:56.720000 --> 0:03:02.100000
 important to you, given that, you
 know, it'll obviously affect you.

0:03:02.100000 --> 0:03:04.640000
 And, you know, at the end of the
 day, we're talking about money.

0:03:04.640000 --> 0:03:13.500000
 At, you know, at that point, the web
 application, or I'm will typically

0:03:13.500000 --> 0:03:19.400000
 have that additional form of, you know,
 identity verification, just to

0:03:19.400000 --> 0:03:23.220000
 ensure that while the person who is
 logged into your account has your

0:03:23.220000 --> 0:03:29.340000
 credentials, they don't have additional
 stuff, you know, that only you

0:03:29.340000 --> 0:03:33.580000
 would have. And so it just, you know,
 it just ensures that the person

0:03:33.580000 --> 0:03:38.300000
 performing the action is indeed
 the owner of the account.

0:03:38.300000 --> 0:03:43.780000
 And so that's the, you know, the key concept
 behind two-factor authentication.

0:03:43.780000 --> 0:03:49.000000
 But more specifically, OTP being
 one of the more popular variants.

0:03:49.000000 --> 0:03:53.780000
 Now, obviously, the primary advantage of
 OTPs is that they are time sensitive

0:03:53.780000 --> 0:03:58.560000
 and expire quickly, essentially making
 them very difficult for attackers

0:03:58.560000 --> 0:04:02.960000
 to reuse. But, you know, there's some
 very, I wouldn't say very, but there

0:04:02.960000 --> 0:04:09.500000
 are some weak implementations of OTP that,
 you know, really haven't integrated

0:04:09.500000 --> 0:04:20.460000
 or they really haven't taken to heart
 the element of the OTP codes being

0:04:20.460000 --> 0:04:24.680000
 temporary. And in certain cases, you
 may find web applications that have

0:04:24.680000 --> 0:04:28.720000
 OTPs that, you know, last for, let's
 say, a day or something like that,

0:04:28.720000 --> 0:04:31.320000
 or even the one sent by emails.

0:04:31.320000 --> 0:04:36.800000
 I'm not speaking specifically of the
 one sent via SMS, but the ones via

0:04:36.800000 --> 0:04:41.840000
 email are notorious for this because,
 again, you know, there's various

0:04:41.840000 --> 0:04:43.120000
 reasons for that.

0:04:43.120000 --> 0:04:47.060000
 But they generally have, you know, as an example
 of vulnerability or misconfiguration,

0:04:47.060000 --> 0:04:51.500000
 very long validity periods, you know,
 up to hours, which, you know, is

0:04:51.500000 --> 0:04:54.000000
 not, is not that secure.

0:04:54.000000 --> 0:04:59.380000
 Anyway, based on what I've said, you
 might be asking, so, well, you've

0:04:59.380000 --> 0:05:05.000000
 mentioned the SMS variant and the email
 variant, are there, is there some

0:05:05.000000 --> 0:05:07.000000
 additional form of categorization?

0:05:07.000000 --> 0:05:08.560000
 We're talking about OTPs.

0:05:08.560000 --> 0:05:13.740000
 And the answer to that is, yes, and
 they're categorized by means of, you

0:05:13.740000 --> 0:05:17.980000
 know, the security or the differences
 as it were, you know, in the way

0:05:17.980000 --> 0:05:19.960000
 the messages are sent.

0:05:19.960000 --> 0:05:25.700000
 Or I should say, the validity of the OTP.


0:05:25.700000 --> 0:05:31.100000
 So firstly, we have the time based OTPs,
 which are abbreviated as T OTPs.

0:05:31.100000 --> 0:05:35.180000
 Now, this is a widely used OTP method
 that generates codes based on a

0:05:35.180000 --> 0:05:37.680000
 shared secret key and the current time.

0:05:37.680000 --> 0:05:42.660000
 So these codes are typically valid
 for a short duration, typically 30

0:05:42.660000 --> 0:05:46.980000
 seconds. So you might have seen them,
 you might be a little bit confused

0:05:46.980000 --> 0:05:50.060000
 as to, you know, what exactly T OTPs are.


0:05:50.060000 --> 0:05:56.020000
 But it's a great way of thinking about
 it is, you know, your two-factor

0:05:56.020000 --> 0:05:59.600000
 authentication keys with, or, you know,
 Google Authenticate or something

0:05:59.600000 --> 0:06:02.040000
 like that, that are time-based.

0:06:02.040000 --> 0:06:03.660000
 That's a good example.

0:06:03.660000 --> 0:06:08.180000
 Another good example is, you know, this
 is really just an implementation

0:06:08.180000 --> 0:06:13.700000
 thing. But for example, they could,
 you know, you could have an email

0:06:13.700000 --> 0:06:17.980000
 based OTP where the code is sent to
 you via email, but there's still a

0:06:17.980000 --> 0:06:23.120000
 timer on the actual web page, you know,
 where you are performing the action.

0:06:23.120000 --> 0:06:28.180000
 And the bottom line is that it's not
 really about the validity of the

0:06:28.180000 --> 0:06:32.020000
 token per se or the, you
 know, the OTP code.

0:06:32.020000 --> 0:06:37.560000
 It's more so the validity of the timer
 on the web application that accepts

0:06:37.560000 --> 0:06:40.040000
 input of an OTP code.

0:06:40.040000 --> 0:06:48.700000
 Otherwise, as you know, you have to
 in this case, OTPs can be sent to

0:06:48.700000 --> 0:06:51.160000
 users via SMS messages.

0:06:51.160000 --> 0:06:55.660000
 And when users log in, they receive
 an OTP on their mobile phone, which

0:06:55.660000 --> 0:06:58.320000
 they must enter to verify their identity.


0:06:58.320000 --> 0:07:06.860000
 So these are also, you know, most well
-designed ones typically also have

0:07:06.860000 --> 0:07:11.500000
 an expiry. And then of course, finally,
 we have the rate limiting and

0:07:11.500000 --> 0:07:17.400000
 lockout where, you know, you can essentially
 utilize OTPs as a way to

0:07:17.400000 --> 0:07:22.380000
 implement rate limiting and account lockout
 mechanisms in this particular

0:07:22.380000 --> 0:07:25.000000
 case against OTPs.

0:07:25.000000 --> 0:07:30.100000
 So that's really more so an
 OTP protection mechanism.

0:07:30.100000 --> 0:07:33.320000
 So this is something, again,
 that's quite common.

0:07:33.320000 --> 0:07:39.040000
 If you put in the wrong OTP code, again,
 in an ideal sense or in an ideal

0:07:39.040000 --> 0:07:43.280000
 world about three times, then
 the account should be locked.

0:07:43.280000 --> 0:07:47.700000
 And that's, you know, another reason
 for the OTPs or, you know, this form

0:07:47.700000 --> 0:07:51.000000
 of protection. It sort of goes back.

0:07:51.000000 --> 0:07:54.940000
 The very same concept goes back to,
 you know, the authentication section

0:07:54.940000 --> 0:08:01.240000
 of this course when we're discussing
 the lockout mechanisms.

0:08:01.240000 --> 0:08:05.380000
 And, you know, the various ways that
 can be achieved OTP, of course, is

0:08:05.380000 --> 0:08:07.380000
 one of them. All right.

0:08:07.380000 --> 0:08:13.800000
 So, you know, speaking a little bit about
 OTP rate limiting, what exactly

0:08:13.800000 --> 0:08:17.440000
 is that? Because you've heard of rate
 limiting, but OTP rate limiting?

0:08:17.440000 --> 0:08:21.460000
 Well, OTP rate limiting is a security
 mechanism that's used to prevent

0:08:21.460000 --> 0:08:26.000000
 brute force attacks or abuse of OTP
 systems, such as the one used in two

0:08:26.000000 --> 0:08:27.200000
-fact authentication.

0:08:27.200000 --> 0:08:32.440000
 Now, rate limiting restricts the the
 number of OTP verification attempts

0:08:32.440000 --> 0:08:38.220000
 that can be made within a specified time
 period by enforcing rate limits.

0:08:38.220000 --> 0:08:42.120000
 Organizations can reduce the risk of
 attackers guessing or trying out

0:08:42.120000 --> 0:08:46.780000
 multiple OTPs in quick succession,
 which brings me to another point or

0:08:46.780000 --> 0:08:47.640000
 another example.

0:08:47.640000 --> 0:08:52.880000
 One of the weaknesses with OTPs apart
 from, you know, the validity period

0:08:52.880000 --> 0:08:59.760000
 of an OTP code is the fact that OTP
 codes possibly could be sequential

0:08:59.760000 --> 0:09:08.500000
 or the OTP generation mechanism could
 reveal some patterns to attackers

0:09:08.500000 --> 0:09:13.360000
 that essentially would allow them to
 either determine, you know, exactly

0:09:13.360000 --> 0:09:15.820000
 how OTP codes are being generated.

0:09:15.820000 --> 0:09:19.620000
 By that, I mean whether they're random
 or whether they, you know, they're

0:09:19.620000 --> 0:09:22.860000
 following a sequence very similar
 to session IDs, right?

0:09:22.860000 --> 0:09:27.960000
 And in the case of those implementations,
 not that they are bad or there's

0:09:27.960000 --> 0:09:32.840000
 anything wrong with them, this can easily
 be counted by, again, enforcing

0:09:32.840000 --> 0:09:35.960000
 rate limits, which, again, is something
 we'll look at in the practical

0:09:35.960000 --> 0:09:39.600000
 demonstration section, which
 we're getting to now.

0:09:39.600000 --> 0:09:46.660000
 So, in order to show you what this looks
 like, that has OTP security and

0:09:46.660000 --> 0:09:53.120000
 of course how to sort of circumvent the
 rate limiting that has been configured.

0:09:53.120000 --> 0:09:57.280000
 And so, this video has a lab environment
 associated with it.

0:09:57.280000 --> 0:10:02.620000
 It's just going to be below this particular
 video and you'll be provided

0:10:02.620000 --> 0:10:07.940000
 with access to a, you know, a pre-configured
 system, the target web application.

0:10:07.940000 --> 0:10:14.640000
 And yeah, so I'm going to fire up my lab
 and I'll see you in the lab environment.

0:10:14.640000 --> 0:10:20.660000
 All right, so I am back within the
 lab environment and when you start

0:10:20.660000 --> 0:10:25.480000
 up the lab environment, you'll be provided
 with a URL that will take you

0:10:25.480000 --> 0:10:28.320000
 to the web application that
 we will be testing.

0:10:28.320000 --> 0:10:30.480000
 So as you can see here, it's very simple.


0:10:30.480000 --> 0:10:34.920000
 I've just opened it up in Firefox and
 it says, welcome to attack defense

0:10:34.920000 --> 0:10:39.180000
 labs. Please enter a phone number
 or your phone number here.

0:10:39.180000 --> 0:10:43.500000
 So, in this case, just based on how
 this was designed, we can just enter

0:10:43.500000 --> 0:10:46.780000
 a random phone number like, you know,
 one, two, three, four, five, six,

0:10:46.780000 --> 0:10:50.840000
 seven, eight. And then we click on send
 verification code and it's going

0:10:50.840000 --> 0:10:54.940000
 to say, please enter the four digit
 OTP received on your mobile.

0:10:54.940000 --> 0:10:57.720000
 And you know, we can say one, two, three,
 four, for example, just to test

0:10:57.720000 --> 0:11:02.860000
 things out. We click on verify OTP right
 over here and it's going to say

0:11:02.860000 --> 0:11:07.120000
 incorrect OTP. So we're supposed
 to find the correct OTP.

0:11:07.120000 --> 0:11:12.260000
 And in this particular case, we'll start
 off by intercepting the request

0:11:12.260000 --> 0:11:17.120000
 with burps. I'm going to navigate to
 Foxy proxy here and click on the

0:11:17.120000 --> 0:11:21.660000
 preconfigured burpsweet and
 zap and or zap profile.

0:11:21.660000 --> 0:11:26.980000
 And this will automatically proxy our
 traffic from Firefox into burpsweet.

0:11:26.980000 --> 0:11:32.820000
 So I'll navigate into menu here and
 into web application analysis and

0:11:32.820000 --> 0:11:36.900000
 into burpsweet, because we need to understand
 what exactly is happening

0:11:36.900000 --> 0:11:39.060000
 when we enter a phone number.

0:11:39.060000 --> 0:11:42.700000
 So I'm going to create a temporary
 project and start that up.

0:11:42.700000 --> 0:11:45.600000
 And I will give this a couple
 of seconds to load up.

0:11:45.600000 --> 0:11:50.460000
 Once it's up, which it is, I'm now going
 to go into the user options and

0:11:50.460000 --> 0:11:53.700000
 into display. And I'm just going to
 change the phone size to something

0:11:53.700000 --> 0:11:57.260000
 a little bit more readable, like 24.

0:11:57.260000 --> 0:12:00.260000
 And now if we're going to proxy, I'm
 just going to make sure intercept

0:12:00.260000 --> 0:12:04.800000
 is set to on. And we'll submit
 this phone number again.

0:12:04.800000 --> 0:12:08.560000
 And then we can see the first
 request that is made.

0:12:08.560000 --> 0:12:11.220000
 So let's pay attention to
 what's going on here.

0:12:11.220000 --> 0:12:16.280000
 So you can see that it's a get request
 that's being sent to dev and send.

0:12:16.280000 --> 0:12:20.480000
 So that's the end point
 or rather the URL.

0:12:20.480000 --> 0:12:23.360000
 And you can see the host
 is this host here.

0:12:23.360000 --> 0:12:26.100000
 So that's API AP, etc.

0:12:26.100000 --> 0:12:29.360000
 In your case, it might be different
 depending on your region.

0:12:29.360000 --> 0:12:34.940000
 And in this case, it's not using it's
 added something here, which is send.

0:12:34.940000 --> 0:12:38.080000
 So that's the end point
 specification there.

0:12:38.080000 --> 0:12:41.660000
 And we can see the referral is
 of course coming from dev.

0:12:41.660000 --> 0:12:43.540000
 And then we have a cookie here.

0:12:43.540000 --> 0:12:46.620000
 So we can see cookie session
 ID equals the following.

0:12:46.620000 --> 0:12:48.860000
 So we have a cookie.

0:12:48.860000 --> 0:12:51.580000
 And again, we're not really
 sure what it is used for.

0:12:51.580000 --> 0:12:53.700000
 So we will just for this request.

0:12:53.700000 --> 0:12:58.380000
 And now you can see there's a get request
 made to the API right over here.

0:12:58.380000 --> 0:13:01.100000
 And this is actually Mozilla.

0:13:01.100000 --> 0:13:02.880000
 So my bad for that.

0:13:02.880000 --> 0:13:05.860000
 This is just the Mozilla
 get requests here.

0:13:05.860000 --> 0:13:08.200000
 So I'll just for that there.

0:13:08.200000 --> 0:13:15.500000
 And now it's going to verify the OTP.

0:13:15.500000 --> 0:13:18.520000
 And now there's a post request
 made to dev verify.

0:13:18.520000 --> 0:13:22.480000
 So the end point for verification
 is verify right over here.

0:13:22.480000 --> 0:13:24.800000
 And you can see that we have the cookie.

0:13:24.800000 --> 0:13:30.600000
 And that sets the session ID, which
 matches what is included in the body

0:13:30.600000 --> 0:13:31.960000
 of the post here.

0:13:31.960000 --> 0:13:33.800000
 So you can see session ID.

0:13:33.800000 --> 0:13:37.020000
 And then the OTP code is specified here.

0:13:37.020000 --> 0:13:42.200000
 So from this point on, we can send this
 to the repeater for a little time.

0:13:42.200000 --> 0:13:45.220000
 And so the bottom line is once we hit
 forward, if we go back into the

0:13:45.220000 --> 0:13:50.480000
 browser, it should give us an indication
 as to whether this is correct

0:13:50.480000 --> 0:13:55.100000
 or not. And in this case, we're not
 got a response yet, which is very

0:13:55.100000 --> 0:13:56.620000
 interesting indeed.

0:13:56.620000 --> 0:13:58.300000
 So let's see if it loads up anything.

0:13:58.300000 --> 0:13:59.860000
 So yep, nothing yet.

0:13:59.860000 --> 0:14:01.960000
 We'll go into the repeater.

0:14:01.960000 --> 0:14:05.320000
 And we'll try and play around
 with this value here.

0:14:05.320000 --> 0:14:09.280000
 So I'm going to send that for for for
 for and you can see the response

0:14:09.280000 --> 0:14:12.700000
 says failed. So pay attention
 to the response messages.

0:14:12.700000 --> 0:14:17.560000
 If I change it to something like 9 8
 9 8, just something totally random

0:14:17.560000 --> 0:14:22.580000
 hit send. Let's see whether
 we get a response here.

0:14:22.580000 --> 0:14:26.960000
 I'm just going to give it a couple
 of seconds right over here.

0:14:26.960000 --> 0:14:33.840000
 I think this may be because we we did
 not hold that particular request.

0:14:33.840000 --> 0:14:37.440000
 So I'm just going to cancel this and
 I'm going to close this repeater

0:14:37.440000 --> 0:14:41.980000
 session. If we're going to the proxy
 now and make sure intercept is set

0:14:41.980000 --> 0:14:46.160000
 to on, I'm just going to
 verify the OTP again.

0:14:46.160000 --> 0:14:48.540000
 And we're going to send this to
 the repeater one more time.

0:14:48.540000 --> 0:14:50.000000
 I just want to test something.

0:14:50.000000 --> 0:14:53.440000
 So we'll say 1212 and send that.

0:14:53.440000 --> 0:14:58.560000
 Okay, so that works if we now say 1213.

0:14:58.560000 --> 0:15:02.040000
 Let's see what that looks
 like looks like.

0:15:02.040000 --> 0:15:07.160000
 Yeah, for every new request, there
 is a there's a new session ID.

0:15:07.160000 --> 0:15:09.960000
 It looks like it appears to be the case.

0:15:09.960000 --> 0:15:14.760000
 We can obviously test this by,
 you know, just saying forward.

0:15:14.760000 --> 0:15:19.960000
 And now if we go back in here,
 you can see incorrect OTP.

0:15:19.960000 --> 0:15:24.840000
 And we go into repeater again based on
 what we're seeing here, it doesn't

0:15:24.840000 --> 0:15:29.440000
 look like there are any there
 is an expiry of the OTP.

0:15:29.440000 --> 0:15:30.880000
 But of course, I could be wrong.

0:15:30.880000 --> 0:15:33.500000
 Let's test it with the,
 you know, few more here.

0:15:33.500000 --> 0:15:35.700000
 So I'll send this again.

0:15:35.700000 --> 0:15:39.200000
 And let's see. Okay, nothing there.

0:15:39.200000 --> 0:15:45.180000
 We go to proxy. And what I'm going to
 do now is, okay, this is just Mozilla.

0:15:45.180000 --> 0:15:51.080000
 If we go back in here, let's take a step
 back, send the verification code.

0:15:51.080000 --> 0:15:53.240000
 We'll send that one.

0:15:53.240000 --> 0:15:55.440000
 And then now we enter the code here.

0:15:55.440000 --> 0:16:00.240000
 So I'm just going to enter
 1111, verify the OTP again.

0:16:00.240000 --> 0:16:04.440000
 And now I'm going to leave that in the,
 I'm not going to afford that particular

0:16:04.440000 --> 0:16:08.600000
 post there. If we just send this one.

0:16:08.600000 --> 0:16:12.020000
 Okay, we don't get a response.

0:16:12.020000 --> 0:16:16.240000
 We change this to something like to do
 we get a response here still sending

0:16:16.240000 --> 0:16:18.120000
 where we send this here.

0:16:18.120000 --> 0:16:19.960000
 Okay, so that failed.

0:16:19.960000 --> 0:16:26.920000
 If we say send this one here,
 so 11113, nothing there.

0:16:26.920000 --> 0:16:30.880000
 So yeah, okay, I'm starting to
 understand how this is working.

0:16:30.880000 --> 0:16:37.040000
 So what we can do now is because we need
 to test and we need to test this

0:16:37.040000 --> 0:16:41.020000
 endpoint to see whether
 there is verification.

0:16:41.020000 --> 0:16:45.340000
 We need to test this particular endpoint
 to see whether there's any rate

0:16:45.340000 --> 0:16:48.700000
 limiting. We need to utilize OASP ZAP.

0:16:48.700000 --> 0:16:51.320000
 And the reason for that is fairly simple.


0:16:51.320000 --> 0:16:55.760000
 OASP ZAP does not have any rate limiting
 features with regards to the

0:16:55.760000 --> 0:16:59.320000
 intruder or rather its fuzzer,
 as they call it.

0:16:59.320000 --> 0:17:02.980000
 Whereas burp suite community edition
 has those limits, so we'll not be

0:17:02.980000 --> 0:17:06.800000
 able to tell whether we are successful
 or not, because it's too slow anyway.

0:17:06.800000 --> 0:17:10.600000
 So I'm just going to close
 up burp suite here.

0:17:10.600000 --> 0:17:15.900000
 And I'm still proxying traffic through
 the actual profile in in five Fox

0:17:15.900000 --> 0:17:20.160000
 in Foxy proxy. So I'll go into
 web application analysis.

0:17:20.160000 --> 0:17:22.460000
 I'll actually take a step back here.

0:17:22.460000 --> 0:17:26.180000
 We'll go to web application analysis
 and we'll go into ZAP.

0:17:26.180000 --> 0:17:31.080000
 And from this point on, we're just
 going to wait for ZAP to load up.

0:17:31.080000 --> 0:17:33.380000
 All right, so ZAP is loaded up.

0:17:33.380000 --> 0:17:41.280000
 I'm just going to and now if I go into
 ZAP, I'm just going to expand that

0:17:41.280000 --> 0:17:43.580000
 and click on manual explore.

0:17:43.580000 --> 0:17:48.880000
 I'll just post that in there and I'll
 launch the ZAP browser here, just

0:17:48.880000 --> 0:17:51.720000
 so that it's all internalized anyway.

0:17:51.720000 --> 0:17:55.600000
 And now within the ZAP browser, we're
 just going to follow through.

0:17:55.600000 --> 0:18:00.360000
 So one, two, three, four, five, six,
 seven, eight, nine, as an example.

0:18:00.360000 --> 0:18:04.840000
 And then the verification code will say
 six, seven, six, seven, something

0:18:04.840000 --> 0:18:06.400000
 very basic like that.

0:18:06.400000 --> 0:18:08.060000
 And you can see incorrect.

0:18:08.060000 --> 0:18:13.300000
 Now in ZAP, right over here, you can
 see that we have the actual endpoint

0:18:13.300000 --> 0:18:17.960000
 there. And under dev, you can
 see we have the post here.

0:18:17.960000 --> 0:18:19.640000
 So we can now fuzz this.

0:18:19.640000 --> 0:18:23.220000
 So we'll right click attack
 and we'll go into fuzz.

0:18:23.220000 --> 0:18:28.400000
 And just like burp suites in Truda,
 we just specify the position that

0:18:28.400000 --> 0:18:32.960000
 we would like to add or the fuzz location
 in the context of ZAP now.

0:18:32.960000 --> 0:18:36.900000
 And what we'll do is I'll just
 expand this a little bit.

0:18:36.900000 --> 0:18:39.800000
 And remember, we want
 to fuzz the API here.

0:18:39.800000 --> 0:18:41.980000
 So I'm going to add that as a position.

0:18:41.980000 --> 0:18:44.240000
 It's now going to ask me for the payload.


0:18:44.240000 --> 0:18:48.660000
 So in this case, because it's numbered,
 we want to use the numbers type.

0:18:48.660000 --> 0:18:56.300000
 And we want to start from, let's
 say 1000, all the way to 9,999.

0:18:56.300000 --> 0:19:02.560000
 So this is the range of pins, or OTP
 codes that we want to essentially

0:19:02.560000 --> 0:19:06.240000
 fuzz for or, you know, perform
 a brute force attack on.

0:19:06.240000 --> 0:19:11.340000
 So we're hoping that the correct OTP
 code is somewhere between 1000 and

0:19:11.340000 --> 0:19:15.200000
 9,999 and will increment by one.

0:19:15.200000 --> 0:19:17.700000
 And you might be saying, well, that's
 going to take a long time.

0:19:17.700000 --> 0:19:20.120000
 Well, firstly, we're testing
 against an API.

0:19:20.120000 --> 0:19:22.920000
 And this will tell us whether
 we have any rate limiting.

0:19:22.920000 --> 0:19:29.240000
 And secondly, OASP ZAP's fuzzer
 is incredibly fast.

0:19:29.240000 --> 0:19:33.540000
 So we'll only increment by one and
 I'll add, I'll add that here.

0:19:33.540000 --> 0:19:36.820000
 So I'll hit OK. So that position
 has been added now.

0:19:36.820000 --> 0:19:41.780000
 And what I'll do now is I'll also go
 into the message processes and we'll

0:19:41.780000 --> 0:19:48.800000
 add a tag creator here that will essentially
 allow us to filter or categorize

0:19:48.800000 --> 0:19:54.620000
 results from the fuzzing as to, you
 know, essentially sort them to to

0:19:54.620000 --> 0:19:59.100000
 be able to tell whether a request
 failed or was successful.

0:19:59.100000 --> 0:20:03.020000
 So in this case, we will filter
 for failed requests.

0:20:03.020000 --> 0:20:06.980000
 So we'll use a rejects and we'll just
 say failed based on the response

0:20:06.980000 --> 0:20:08.320000
 we analyzed in burp.

0:20:08.320000 --> 0:20:10.300000
 We know that that is the case here.

0:20:10.300000 --> 0:20:13.740000
 So we will just use that there.

0:20:13.740000 --> 0:20:18.120000
 And from this point on the tag name
 will just be called failed.

0:20:18.120000 --> 0:20:22.240000
 Like so and I'll hit add
 and hit start fuzzer.

0:20:22.240000 --> 0:20:26.320000
 And almost immediately you can see how
 many attempts are being made here.

0:20:26.320000 --> 0:20:30.620000
 So firstly, you have the task ID, the
 message type, the code, the response

0:20:30.620000 --> 0:20:35.980000
 code, the reason the RTT, and then the
 state here based on the tag that

0:20:35.980000 --> 0:20:39.880000
 we had created. So in essence, we're
 looking for a change in the size

0:20:39.880000 --> 0:20:41.380000
 of the response header.

0:20:41.380000 --> 0:20:45.240000
 And right over here, the top, you can
 see the completion and the number

0:20:45.240000 --> 0:20:46.660000
 of messages sent.

0:20:46.660000 --> 0:20:50.620000
 So based on what I'm seeing here and
 the status code here, the response

0:20:50.620000 --> 0:20:56.000000
 code, it doesn't look like this particular
 OTP endpoint has rate limiting.

0:20:56.000000 --> 0:21:00.040000
 So now it's just a matter of playing
 around with the range to see whether

0:21:00.040000 --> 0:21:03.720000
 we can identify a valid OTP code.

0:21:03.720000 --> 0:21:10.220000
 So I can go into this column here on
 the state and try and filter for

0:21:10.220000 --> 0:21:15.620000
 try and filter for tasks or, you know,
 fuzzing attempts that do not have

0:21:15.620000 --> 0:21:17.840000
 the failed state set.

0:21:17.840000 --> 0:21:24.200000
 And again, remember, we did we set the
 tag here to essentially show the

0:21:24.200000 --> 0:21:28.860000
 failed attempts and anything that does
 not have that tag means that is

0:21:28.860000 --> 0:21:30.220000
 probably successful.

0:21:30.220000 --> 0:21:32.180000
 So we're just going to look out for this.


0:21:32.180000 --> 0:21:34.880000
 I'm not sure when we'll
 get a positive result.

0:21:34.880000 --> 0:21:40.660000
 So I'm going to let it
 run to which is 9,999.

0:21:40.660000 --> 0:21:45.260000
 And we're just going to try and filter
 this as much as we can here using

0:21:45.260000 --> 0:21:49.560000
 the columns. And we can also do that using
 the size of the response header.

0:21:49.560000 --> 0:21:52.560000
 So just, you know, trying
 to filter that way.

0:21:52.560000 --> 0:21:56.380000
 The original one is the only one here
 that is not failed, because we can

0:21:56.380000 --> 0:22:00.160000
 see the request here was, you
 know, six, seven, six, seven.

0:22:00.160000 --> 0:22:03.640000
 And the response was probably
 that it failed as well.

0:22:03.640000 --> 0:22:07.160000
 So we'll click on that here,
 you can see status is failed.

0:22:07.160000 --> 0:22:09.580000
 So I'm just going to let this run.

0:22:09.580000 --> 0:22:12.920000
 And I'll let you know when
 I have a positive result.

0:22:12.920000 --> 0:22:17.040000
 All right, so I didn't have
 to let it run for too long.

0:22:17.040000 --> 0:22:25.700000
 Pretty much the 1,999 fuzzing request
 here, pretty much gave us a success.

0:22:25.700000 --> 0:22:29.920000
 And pay attention to the actual
 response here in the response.

0:22:29.920000 --> 0:22:34.820000
 You can see that a new head is set
 called set cookie right over here.

0:22:34.820000 --> 0:22:36.800000
 And it has the session ID.

0:22:36.800000 --> 0:22:41.500000
 And in terms of what the code was,
 we can see right over here that the

0:22:41.500000 --> 0:22:45.880000
 OTP code was 2998, which
 is absolutely fantastic.

0:22:45.880000 --> 0:22:50.220000
 So I'm going to stop the the
 current fuzzing attempt here.

0:22:50.220000 --> 0:22:54.820000
 And what we can do now is pretty much
 just try and make a request even

0:22:54.820000 --> 0:22:59.740000
 with burp suite and then copy this,
 copy this particular session ID that

0:22:59.740000 --> 0:23:01.500000
 was sent in the response.

0:23:01.500000 --> 0:23:03.700000
 So this one right over here.

0:23:03.700000 --> 0:23:06.460000
 And we pretty much just need to copy it.

0:23:06.460000 --> 0:23:10.780000
 And we'll then replace it when
 when we make a new request.

0:23:10.780000 --> 0:23:14.320000
 Now, the one thing that I would like
 to point out is please do not use

0:23:14.320000 --> 0:23:19.080000
 my code that I've obtained in the video
 because in your case, your code

0:23:19.080000 --> 0:23:20.320000
 will be different.

0:23:20.320000 --> 0:23:22.480000
 So please keep that in mind.

0:23:22.480000 --> 0:23:28.360000
 And also, you know, if we right click
 here, we can we can open this up

0:23:28.360000 --> 0:23:29.680000
 in the browser here.

0:23:29.680000 --> 0:23:32.080000
 So we'll say Firefox.

0:23:32.080000 --> 0:23:39.320000
 And in here, you know, if we then halt
 this, so under not under verify,

0:23:39.320000 --> 0:23:42.300000
 but more so under the original request.

0:23:42.300000 --> 0:23:44.940000
 So for example, we'll go to dev here.

0:23:44.940000 --> 0:23:50.600000
 And I'll just hold the, I'll just add
 a set, I'll just set a break there.

0:23:50.600000 --> 0:23:54.880000
 My apologies. We have quite a few Firefox
 windows, but I'll just set a

0:23:54.880000 --> 0:24:01.760000
 break there. And in this particular
 case, if I now say, verify, if I go

0:24:01.760000 --> 0:24:07.720000
 back to dev, you can see, yeah,
 we'll just say, okay.

0:24:07.720000 --> 0:24:12.180000
 And here we can just set
 the session ID that.

0:24:12.180000 --> 0:24:15.740000
 So this is the break point.

0:24:15.740000 --> 0:24:21.440000
 So yeah, we'll just replace it with the
 one I, I copied from the successful

0:24:21.440000 --> 0:24:22.940000
 OTP brute force.

0:24:22.940000 --> 0:24:26.880000
 So right over here, just
 paste that in there.

0:24:26.880000 --> 0:24:34.620000
 And by now just play that again, we'll
 go to one of our sessions here.

0:24:34.620000 --> 0:24:38.380000
 I'm not sure which browser session it is.


0:24:38.380000 --> 0:24:40.480000
 It's most likely session two.

0:24:40.480000 --> 0:24:44.840000
 There we are. We're successfully able
 to authenticate and log in and we

0:24:44.840000 --> 0:24:50.100000
 get the flag. So just to recap what has
 happened here, we found the successful

0:24:50.100000 --> 0:24:52.660000
 or we found the correct OTP code.

0:24:52.660000 --> 0:24:54.160000
 Why was that the case?

0:24:54.160000 --> 0:24:58.700000
 It was the case because these OTP codes
 do not look like they had any

0:24:58.700000 --> 0:25:02.160000
 expiry, at least in the,
 in the short term.

0:25:02.160000 --> 0:25:09.060000
 And secondly, as you can see here, we
 performed, it looks like 3886 brute

0:25:09.060000 --> 0:25:13.440000
 force attempts. And there was
 no rate limiting whatsoever.

0:25:13.440000 --> 0:25:17.440000
 And just based on the fact that those
 two security mechanisms did not

0:25:17.440000 --> 0:25:21.100000
 exist, we were successfully
 able to get an OTP.

0:25:21.100000 --> 0:25:24.580000
 Now the key thing to note is that in
 this case, the OTP code was just

0:25:24.580000 --> 0:25:27.960000
 four characters, which
 made it even easier.

0:25:27.960000 --> 0:25:36.520000
 And the actual range was quite small
 1000 to 919, sorry 1000 to 9999 was

0:25:36.520000 --> 0:25:39.800000
 not that large, especially when
 you utilizing a tool like zap.

0:25:39.800000 --> 0:25:43.800000
 But we were, you know, we were successfully
 able to get the code.

0:25:43.800000 --> 0:25:46.680000
 And in your case, the code will be different
 because that's how the web

0:25:46.680000 --> 0:25:47.800000
 application works.

0:25:47.800000 --> 0:25:52.640000
 It's supposed to work like a real OTP,
 you know, like a real OTP endpoint.

0:25:52.640000 --> 0:25:56.280000
 So hopefully you'll actually have
 a lot of fun with this one.

0:25:56.280000 --> 0:26:00.340000
 But that brings me to the end of the
 practical demonstration side of this

0:26:00.340000 --> 0:26:07.660000
 video. All right, so that was how to attack
 a login form with OTP security.

0:26:07.660000 --> 0:26:12.420000
 Hopefully that, you know, sort of give
 you a practical feel for what,

0:26:12.420000 --> 0:26:17.320000
 you know, OTPs look like in the world,
 which I'm sure you already are

0:26:17.320000 --> 0:26:20.720000
 aware of, but also how the, you know,
 what happens in the background.

0:26:20.720000 --> 0:26:25.040000
 And of course, how to identify some
 of the security mechanisms that are

0:26:25.040000 --> 0:26:29.020000
 layered on top of OTP like rate limiting,
 and of course, how to circumvent

0:26:29.020000 --> 0:26:31.580000
 that or how to bypass it.

0:26:31.580000 --> 0:26:35.100000
 But with that being said, that brings
 us to the end of this section of

0:26:35.100000 --> 0:26:38.280000
 the course, or the final
 section of the course.

0:26:38.280000 --> 0:26:42.640000
 And with that being said, there's nothing
 more to add, but to see you

0:26:42.640000 --> 0:26:45.560000
 in the course summary video.

0:26:45.560000 --> 0:26:49.180000
 So thank you very much for completing
 this section and the course.

0:26:49.180000 --> 0:26:53.200000
 And I'll see you in the summary video
 where we'll be going over everything

0:26:53.200000 --> 0:26:57.020000
 that we've learned and we'll be revisiting
 the learning outcomes or learning

0:26:57.020000 --> 0:26:59.340000
 objectives to see whether
 we covered everything.

0:26:59.340000 --> 0:27:02.560000
 So that being said, that's
 going to be a mind.

0:27:02.560000 --> 0:27:07.160000
 And I'll be seeing you in the next video
 and hopefully the next course.