WEBVTT

0:00:03.520000 --> 0:00:06.420000
 Hello everyone and welcome to this video.


0:00:06.420000 --> 0:00:10.560000
 In this video we're going to be taking
 a look at how to test the SOAP

0:00:10.560000 --> 0:00:16.160000
 web service for SQL injection vulnerabilities
 which we most likely identified

0:00:16.160000 --> 0:00:18.360000
 in the previous video.

0:00:18.360000 --> 0:00:20.880000
 So we're now going to
 be building on that.

0:00:20.880000 --> 0:00:25.740000
 And the primary objective here is not
 really around SQL injection payloads

0:00:25.740000 --> 0:00:28.680000
 or the logic behind it and the
 techniques we're utilizing.

0:00:28.680000 --> 0:00:33.720000
 It's more so to see whether we can get
 any actionable data or information

0:00:33.720000 --> 0:00:39.240000
 from the web service via
 a SQL injection attack.

0:00:39.240000 --> 0:00:44.780000
 So as I had stated in the previous
 two videos, this lab will all this

0:00:44.780000 --> 0:00:49.220000
 video will also be utilizing the same
 lab environment we've been utilizing

0:00:49.220000 --> 0:00:51.020000
 called web services.

0:00:51.020000 --> 0:00:56.880000
 And you know you can pretty much pick
 up from where you will still have

0:00:56.880000 --> 0:00:57.740000
 the lab running.

0:00:57.740000 --> 0:00:59.560000
 It's not going to affect anything.

0:00:59.560000 --> 0:01:02.220000
 And that's exactly what
 I'm going to be doing.

0:01:02.220000 --> 0:01:07.400000
 So I'm going to be switching over into
 my lab environment now and we can

0:01:07.400000 --> 0:01:10.260000
 kick off. So I'll see you there.

0:01:10.260000 --> 0:01:16.560000
 Alright I am back within
 the lab environment.

0:01:16.560000 --> 0:01:22.500000
 And if you remember in the previous
 video, we identified an inkling of

0:01:22.500000 --> 0:01:30.980000
 the SQL injection vulnerability when we
 were playing around with the delete

0:01:30.980000 --> 0:01:37.240000
 user operation right over here, especially
 when we pretty much appended

0:01:37.240000 --> 0:01:41.520000
 or terminated the string literal by
 including a single quote, which is

0:01:41.520000 --> 0:01:47.620000
 a very good technique for testing for
 error-based SQL injection and indeed

0:01:47.620000 --> 0:01:49.600000
 the output validated that.

0:01:49.600000 --> 0:01:53.560000
 But the primary objective here is obviously
 to see whether we can extract

0:01:53.560000 --> 0:01:56.940000
 data via a SQL injection attack.

0:01:56.940000 --> 0:02:02.800000
 Now in the previous video as well,
 I tried to see whether you know we

0:02:02.800000 --> 0:02:09.200000
 whether this particular input here
 was vulnerable to SQL injection.

0:02:09.200000 --> 0:02:12.560000
 And as I said, we did it by terminating
 the string literal.

0:02:12.560000 --> 0:02:17.800000
 So we know that this parameter
 here is vulnerable.

0:02:17.800000 --> 0:02:20.680000
 But what about the password
 parameter right over here?

0:02:20.680000 --> 0:02:24.040000
 We can also test this to
 see whether it will work.

0:02:24.040000 --> 0:02:29.980000
 So to begin with, I've just gotten
 rid of the value of a password.

0:02:29.980000 --> 0:02:34.820000
 We didn't have one, which will bring
 me to another attack that you can

0:02:34.820000 --> 0:02:37.600000
 launch here if you haven't
 figured it out already.

0:02:37.600000 --> 0:02:40.980000
 But I'll send this and let's
 see what the response is.

0:02:40.980000 --> 0:02:44.300000
 So you can see it could not
 authenticate account.

0:02:44.300000 --> 0:02:47.340000
 Jeremy password is incorrect.

0:02:47.340000 --> 0:02:51.980000
 Okay, so before we take a look at SQL
 injection, we can actually perform

0:02:51.980000 --> 0:02:55.320000
 a brute force on this to try and
 find the password for Jeremy.

0:02:55.320000 --> 0:02:58.320000
 But in this case, let's try the admin.

0:02:58.320000 --> 0:03:01.980000
 Why don't we go for the
 big dog right over here?

0:03:01.980000 --> 0:03:05.980000
 And this is pretty much the position
 of the password is what we want to

0:03:05.980000 --> 0:03:10.520000
 brute force. So we can send
 this to the intruder.

0:03:10.520000 --> 0:03:12.660000
 And there we are.

0:03:12.660000 --> 0:03:15.240000
 There's the attack target
 in terms of the positions.

0:03:15.240000 --> 0:03:18.560000
 We're going to clear all
 predefined positions.

0:03:18.560000 --> 0:03:22.940000
 And in here is where we're going
 to pretty much add our position.

0:03:22.940000 --> 0:03:26.620000
 So I'm just going to add it here.

0:03:26.620000 --> 0:03:29.960000
 And I'll add it right over here.

0:03:29.960000 --> 0:03:40.320000
 That's where we want obviously specify
 the attack type as sniper and then

0:03:40.320000 --> 0:03:46.340000
 payloads, you know, we can pretty much
 go with we can go with the word

0:03:46.340000 --> 0:03:48.420000
 lists on the actual desktop here.

0:03:48.420000 --> 0:03:49.940000
 So 100 common passwords.

0:03:49.940000 --> 0:03:53.420000
 And that's pretty much it in terms
 of payload processing, nothing else

0:03:53.420000 --> 0:03:57.140000
 is required because it's being sent
 as a string, which is the format in

0:03:57.140000 --> 0:04:01.200000
 which the passwords within
 the word list are.

0:04:01.200000 --> 0:04:03.000000
 And we can just hit start.

0:04:03.000000 --> 0:04:04.940000
 And again, I'm just showing you this.

0:04:04.940000 --> 0:04:12.720000
 Okay, the host header in the request
 does not match the let's go back

0:04:12.720000 --> 0:04:17.220000
 here. That's a think one
 of my issues here.

0:04:17.220000 --> 0:04:20.080000
 The host header does not match.

0:04:20.080000 --> 0:04:24.340000
 So I think in this case, you would
 have to say demo.ini.local.

0:04:24.340000 --> 0:04:26.960000
 And we can then start the attack.

0:04:26.960000 --> 0:04:30.900000
 There we are. So we need to
 do that manually this time.

0:04:30.900000 --> 0:04:35.620000
 And we pretty much want to monitor a
 normal anomalies within the response.

0:04:35.620000 --> 0:04:39.140000
 If we take a look at the response, we
 want to make sure that it's sending

0:04:39.140000 --> 0:04:41.460000
 it okay. So there we are.

0:04:41.460000 --> 0:04:43.160000
 These are all incorrect attempts.

0:04:43.160000 --> 0:04:48.440000
 And we're just looking for a very variation
 within the length of the response

0:04:48.440000 --> 0:04:52.080000
 to see whether we find anything anomalous
 that could potentially indicate

0:04:52.080000 --> 0:04:54.500000
 successful authentication.

0:04:54.500000 --> 0:04:58.580000
 And from that point on, you know, it
 we would have just hit the jackpot.

0:04:58.580000 --> 0:05:02.340000
 So this is another attack technique
 that you can leverage.

0:05:02.340000 --> 0:05:06.100000
 And obviously, I'm not sure myself whether
 we'll get the admin password,

0:05:06.100000 --> 0:05:10.680000
 but we'll see. We'll see we can obviously
 do the same for username and

0:05:10.680000 --> 0:05:16.820000
 enumeration. So the point is that we can
 try and see whether we can enumerate

0:05:16.820000 --> 0:05:22.320000
 users using a brute force attack, you
 know, or a word list, if you will.

0:05:22.320000 --> 0:05:26.320000
 But let's see whether we
 get anything successful.

0:05:26.320000 --> 0:05:29.180000
 So, you know, I can just
 filter by length here.

0:05:29.180000 --> 0:05:33.200000
 Let's see. Yeah, so we'll
 go for the longest length.

0:05:33.200000 --> 0:05:40.300000
 And we can then scroll to the final
 requests being made here.

0:05:40.300000 --> 0:05:45.800000
 I'm not sure, as I said, whether we'll
 get any password for this user.

0:05:45.800000 --> 0:05:49.180000
 But yeah, this is how we would do it.

0:05:49.180000 --> 0:05:56.300000
 Now, before we actually haven't got
 any positive results, but if I just

0:05:56.300000 --> 0:06:01.420000
 stop this attack, and we'll discard
 this and go into the repeater.

0:06:01.420000 --> 0:06:06.620000
 Previously, when we were specifying
 Jeremy as the username, we can see

0:06:06.620000 --> 0:06:09.140000
 that there's something interesting
 going on here.

0:06:09.140000 --> 0:06:16.140000
 It looks like usernames specified within
 the request need to have an uppercase.

0:06:16.140000 --> 0:06:18.660000
 They need to start with
 an uppercase letter.

0:06:18.660000 --> 0:06:22.000000
 So we can also try that just to
 see whether this will work.

0:06:22.000000 --> 0:06:24.040000
 So we know we can send
 it to the intruder.

0:06:24.040000 --> 0:06:27.800000
 Again, I'm just showing you the
 various options you can explore.

0:06:27.800000 --> 0:06:32.760000
 So the, the attack target is, we'll
 configure that manually actually.

0:06:32.760000 --> 0:06:35.920000
 So demo.ini.local.

0:06:35.920000 --> 0:06:40.020000
 And we'll clear the previous positions
 right over here, and we'll then

0:06:40.020000 --> 0:06:46.820000
 add our position now for the password
 parameter for the payloads simple

0:06:46.820000 --> 0:06:51.900000
 as going to the 100 common passwords
 dot txt word list.

0:06:51.900000 --> 0:06:54.500000
 And we can then pretty
 much start our attack.

0:06:54.500000 --> 0:06:56.640000
 This will still be throttled.

0:06:56.640000 --> 0:07:01.740000
 You do it if you do this with something
 like oasp zap, you're going to

0:07:01.740000 --> 0:07:05.760000
 get some seriously high speeds, especially
 if there's no rate limiting

0:07:05.760000 --> 0:07:11.780000
 on the web service endpoint, which in
 this case, I don't think they are.

0:07:11.780000 --> 0:07:16.580000
 But pretty much just going through
 the same process here of monitoring

0:07:16.580000 --> 0:07:19.440000
 for variation in the actual length.

0:07:19.440000 --> 0:07:23.580000
 So you know, we can just look
 for any changes here.

0:07:23.580000 --> 0:07:29.160000
 I'm going to get let it reach about 60
 or 80 attempts out of the 100 before

0:07:29.160000 --> 0:07:33.500000
 we sequel injection vulnerability.

0:07:33.500000 --> 0:07:37.720000
 All right, so I've also tried out a
 different word list, and it doesn't

0:07:37.720000 --> 0:07:42.020000
 look like it's giving us anything that
 could be because the admin user

0:07:42.020000 --> 0:07:46.820000
 doesn't have the password set or it
 might be set to something, you know,

0:07:46.820000 --> 0:07:51.860000
 a little bit hard to brute force in
 this particular case or context.

0:07:51.860000 --> 0:07:56.680000
 So one more thing, obviously, I'll just
 show you how to repeat the process

0:07:56.680000 --> 0:08:00.700000
 for for the username.

0:08:00.700000 --> 0:08:06.740000
 So if I go into the positions, we can
 perform, you know, brute force attack

0:08:06.740000 --> 0:08:13.620000
 for both. However, if you remember, when
 we went into the repeater earlier

0:08:13.620000 --> 0:08:19.440000
 on in the first video within this section,
 we can utilize the get user.

0:08:19.440000 --> 0:08:24.680000
 We can utilize the get user operation
 here to essentially list out user

0:08:24.680000 --> 0:08:30.060000
 accounts. And that would essentially
 display, you know, the information

0:08:30.060000 --> 0:08:34.740000
 if they exist, if not, they will
 display an error message.

0:08:34.740000 --> 0:08:37.420000
 So we can pretty much just try this.

0:08:37.420000 --> 0:08:42.940000
 And we can then, you know, perform username
 enumeration to see what usernames

0:08:42.940000 --> 0:08:46.080000
 might exist. And that's another attack.

0:08:46.080000 --> 0:08:49.500000
 And the only reason why I'm doing this
 is because I'm also curious as

0:08:49.500000 --> 0:08:57.840000
 well. So what I'll do now is I'll open
 up a new repeater session here.

0:08:57.840000 --> 0:09:01.100000
 And within the actual request,
 what do I need to modify?

0:09:01.100000 --> 0:09:07.960000
 Firstly, I need to modify this here,
 because the URI in so far as how

0:09:07.960000 --> 0:09:12.860000
 this web application is configured
 does not start from Motilidae.

0:09:12.860000 --> 0:09:18.360000
 As for the actual username specification,
 that's perfectly fine there.

0:09:18.360000 --> 0:09:24.200000
 We now need to obviously send, but
 it'll prompt us to enter the target

0:09:24.200000 --> 0:09:28.360000
 details. So we'll say demo.ini.local.

0:09:28.360000 --> 0:09:32.580000
 And I'm just sending so that I can
 verify that this is indeed working.

0:09:32.580000 --> 0:09:37.380000
 Otherwise, it won't ascend any request
 that's not working to the intruder

0:09:37.380000 --> 0:09:39.960000
 and then waste time with
 that brute force.

0:09:39.960000 --> 0:09:44.200000
 So yeah, we know that the user Jeremy
 exists pretty much we send this

0:09:44.200000 --> 0:09:45.940000
 to the intruder now.

0:09:45.940000 --> 0:09:51.460000
 And we then go into the positions
 and we'll clear the default ones.

0:09:51.460000 --> 0:09:55.180000
 And this is what we want to brute force
 while add that as a position and

0:09:55.180000 --> 0:09:58.800000
 pretty much the same thing repeats
 itself in terms of the process.

0:09:58.800000 --> 0:10:00.280000
 We'll just load.

0:10:00.280000 --> 0:10:04.960000
 And in this case, I'll utilize a Metasploit
 word list that contains users.

0:10:04.960000 --> 0:10:09.680000
 One of my favorites is just Unix
 users and I'll just hit open.

0:10:09.680000 --> 0:10:15.020000
 And this will also tell us that the user
 admin exists, but any other users

0:10:15.020000 --> 0:10:17.100000
 as well will be included here.

0:10:17.100000 --> 0:10:18.700000
 So let's start attack.

0:10:18.700000 --> 0:10:22.580000
 Okay, let me go back here
 for got to set that up.

0:10:22.580000 --> 0:10:36.220000
 So we need to set this to demo.ini
.local with the intruder doesn't do

0:10:36.220000 --> 0:10:40.420000
 length of the response, which you're
 actually getting quite a bit here.

0:10:40.420000 --> 0:10:44.940000
 So if we click on some of these, I'm
 just going to open up the response

0:10:44.940000 --> 0:10:50.680000
 here. We can see the following
 user does not exist.

0:10:50.680000 --> 0:10:55.400000
 So we know we pretty much can we pretty
 much can go through these and

0:10:55.400000 --> 0:10:57.720000
 see which ones do exist.

0:10:57.720000 --> 0:11:00.940000
 So for admin, we can see that's 1097.

0:11:00.940000 --> 0:11:03.060000
 We can see we get the info here.

0:11:03.060000 --> 0:11:04.440000
 So we know that user exists.

0:11:04.440000 --> 0:11:09.140000
 So we could have done this prior to
 even finding or invoking that that

0:11:09.140000 --> 0:11:14.220000
 hidden operation that would get admin
 info and just use this technique.

0:11:14.220000 --> 0:11:18.380000
 In terms of administrator, we can
 see that user doesn't exist.

0:11:18.380000 --> 0:11:22.360000
 And I'm just looking for
 commonality over here.

0:11:22.360000 --> 0:11:24.880000
 We can see these are blank.

0:11:24.880000 --> 0:11:30.580000
 Interesting. This is yeah, so this was
 no no password specified, but it

0:11:30.580000 --> 0:11:34.640000
 looks like the larger the length of
 the response, the more, you know,

0:11:34.640000 --> 0:11:37.260000
 the better the chance that
 it was successful.

0:11:37.260000 --> 0:11:40.700000
 So you know, user draddis does
 not exist, so on and so forth.

0:11:40.700000 --> 0:11:45.540000
 But yeah, this is pretty much
 what we would need to do.

0:11:45.540000 --> 0:11:49.940000
 And you then use this to sort of identify,
 you know, which what the valid

0:11:49.940000 --> 0:11:54.920000
 users are. So in again, also factor
 in the actual payload size itself,

0:11:54.920000 --> 0:11:59.020000
 because that affects the response size,
 because it reflects back the username,

0:11:59.020000 --> 0:12:01.820000
 so GNOME initial setup does not exist.

0:12:01.820000 --> 0:12:04.020000
 Pretty much the same here.

0:12:04.020000 --> 0:12:09.240000
 And from this point on, let's see whether
 we have any change in the length

0:12:09.240000 --> 0:12:11.500000
 here. So we'll go to the highest.

0:12:11.500000 --> 0:12:15.940000
 So admin obviously has the highest,
 and then payloads that are slightly

0:12:15.940000 --> 0:12:18.280000
 longer follow suit.

0:12:18.280000 --> 0:12:23.260000
 And yeah, so this is how you can enumerate
 users or user names if you

0:12:23.260000 --> 0:12:28.420000
 will. In this case, we don't have Jeremy
 in this particular word list.

0:12:28.420000 --> 0:12:33.780000
 So I would be surprised if we did,
 that would be quite hilarious.

0:12:33.780000 --> 0:12:37.520000
 So I'll just sort the length here again.

0:12:37.520000 --> 0:12:40.520000
 And yeah, so it doesn't look like we
 have anything, but that's generally

0:12:40.520000 --> 0:12:47.020000
 how you'd perform fuzzing on web service
 or API endpoint to discover usernames,

0:12:47.020000 --> 0:12:51.520000
 you know, perform username enumeration,
 or perform a brute force attack

0:12:51.520000 --> 0:12:57.480000
 on a, you know, login functionality within
 the actual web service or authentication

0:12:57.480000 --> 0:13:01.900000
 functionality. So now that we've taken
 a look at that, we can return to

0:13:01.900000 --> 0:13:05.620000
 the primary reason why we're
 going through this video.

0:13:05.620000 --> 0:13:07.880000
 And that was for SQL injection, right?

0:13:07.880000 --> 0:13:11.860000
 So I'll go back into the repeater here,
 and we'll go to our first tab

0:13:11.860000 --> 0:13:15.420000
 here. So we know that Jeremy exists.

0:13:15.420000 --> 0:13:17.420000
 So why don't we just
 stick with that user?

0:13:17.420000 --> 0:13:22.040000
 Because that is required for this
 operation to execute successfully.

0:13:22.040000 --> 0:13:26.780000
 And what we need to do now is test
 for SQL injection, specifically the

0:13:26.780000 --> 0:13:27.760000
 password parameter.

0:13:27.760000 --> 0:13:30.780000
 I'm really interested about this
 to see whether that works.

0:13:30.780000 --> 0:13:35.840000
 So I'll utilize the infamous SQL injection,
 I should say error, basically

0:13:35.840000 --> 0:13:42.580000
 injection character that will,
 in most cases, invoke an error.

0:13:42.580000 --> 0:13:46.680000
 So within the backend DBMS being
 used, so I'll hit send.

0:13:46.680000 --> 0:13:48.780000
 So we get a 200, okay.

0:13:48.780000 --> 0:13:51.900000
 And now you can see we do
 get that error, we do.

0:13:51.900000 --> 0:13:54.340000
 So there's an exception here.

0:13:54.340000 --> 0:14:00.740000
 And you can see that right over here
 under the message, it says that in

0:14:00.740000 --> 0:14:06.080000
 the file app classes, my SQL handler
.php, online 194, there's an error

0:14:06.080000 --> 0:14:08.080000
 executing the SQL query.

0:14:08.080000 --> 0:14:12.140000
 So you may be asking us of the question,
 what is the SQL query?

0:14:12.140000 --> 0:14:14.900000
 And pay attention to this error here,
 where it says, check the manual

0:14:14.900000 --> 0:14:18.660000
 that corresponds to your MySQL server
 version for the rights syntax to

0:14:18.660000 --> 0:14:20.440000
 use near the following.

0:14:20.440000 --> 0:14:22.480000
 So we have terminated once.

0:14:22.480000 --> 0:14:28.460000
 Okay. Now that means that if I did
 maybe double quote, let's see what

0:14:28.460000 --> 0:14:32.040000
 happens now. This is very interesting,
 very interesting.

0:14:32.040000 --> 0:14:33.680000
 Okay, all right, so that closes it.

0:14:33.680000 --> 0:14:37.820000
 And then if I put in a third one, again,
 just opening up another one,

0:14:37.820000 --> 0:14:39.600000
 let's just see what happens.

0:14:39.600000 --> 0:14:42.160000
 Okay, so we get an error there.

0:14:42.160000 --> 0:14:47.860000
 So we know that this particular web service
 is specifically this operation

0:14:47.860000 --> 0:14:54.640000
 is vulnerable to input, input injection
 or injection vulnerabilities,

0:14:54.640000 --> 0:14:59.160000
 because there is no validation
 or sanitization of input.

0:14:59.160000 --> 0:15:11.920000
 So again, I'll just use the previous
 example, we terminate the string

0:15:11.920000 --> 0:15:16.840000
 authentication bypass SQL payload or
 SQL injection payload, which is just

0:15:16.840000 --> 0:15:23.440000
 to utilize Boolean based
 SQL injection techniques.

0:15:23.440000 --> 0:15:27.760000
 For example, we can say we terminate
 the string literal, then after this,

0:15:27.760000 --> 0:15:32.940000
 we can execute our our SQL query, in this
 case, because it's Boolean based,

0:15:32.940000 --> 0:15:43.820000
 we'll say the point is that when we
 are doing this, what we are trying

0:15:43.820000 --> 0:15:53.880000
 to do is we are trying to pretty
 much execute whatever we want.

0:15:53.880000 --> 0:16:00.540000
 And if successful, what should happen
 is the user Jeremy will be deleted,

0:16:00.540000 --> 0:16:05.100000
 because if you know, one equals one
 is true, then password equals true,

0:16:05.100000 --> 0:16:07.080000
 and Jeremy will be deleted.

0:16:07.080000 --> 0:16:12.880000
 And that's because we know we are invoking
 the delete user operation.

0:16:12.880000 --> 0:16:16.600000
 So if you remember back in the documentation,
 it said that in order for

0:16:16.600000 --> 0:16:21.000000
 us to delete an account successfully, we
 need to provide their valid password.

0:16:21.000000 --> 0:16:25.340000
 In this case, this SQL injection technique
 will bypass the need for a

0:16:25.340000 --> 0:16:28.380000
 password and delete the
 user Jeremy permanently.

0:16:28.380000 --> 0:16:29.920000
 So how could we do this?

0:16:29.920000 --> 0:16:37.140000
 Well, the easiest way is to pretty
 much take a look at the query here

0:16:37.140000 --> 0:16:44.600000
 where it says, let's see, select, select
 username from accounts where

0:16:44.600000 --> 0:16:49.540000
 username is equal, username
 is equal to Jeremy.

0:16:49.540000 --> 0:16:52.440000
 And this is where we are terminating
 the string literal, specifically

0:16:52.440000 --> 0:16:54.160000
 in the password.

0:16:54.160000 --> 0:16:57.660000
 And that makes sense, because it
 is the final part of the query.

0:16:57.660000 --> 0:17:04.040000
 So if we terminated earlier, it will still
 execute the password, the password

0:17:04.040000 --> 0:17:08.260000
 query here, the password check, which
 means we would not be able to delete

0:17:08.260000 --> 0:17:12.960000
 the account. Actually, we might have
 because that will still work.

0:17:12.960000 --> 0:17:16.740000
 But the bottom line is we can just,
 you know, put in a Boolean operation

0:17:16.740000 --> 0:17:21.180000
 like, you know, one, and this needs
 to be in strings so that we know we

0:17:21.180000 --> 0:17:22.660000
 don't terminate the literal.

0:17:22.660000 --> 0:17:25.300000
 So one equals one.

0:17:25.300000 --> 0:17:30.840000
 Okay. And we don't need to close the
 string literal because of how this

0:17:30.840000 --> 0:17:33.340000
 works. So I'll just hit send.

0:17:33.340000 --> 0:17:40.740000
 And we get a 200 Okay, and it says right
 over here, could not authenticate.

0:17:40.740000 --> 0:17:43.860000
 So yeah, I think we would
 need to close this.

0:17:43.860000 --> 0:17:47.520000
 Actually, yeah, we would
 need to close it.

0:17:47.520000 --> 0:17:49.200000
 That's very interesting.

0:17:49.200000 --> 0:17:52.900000
 So, you know, we can utilize
 operations like this.

0:17:52.900000 --> 0:17:58.140000
 And you know, for example, in this case,
 I'll just say, you know, if we

0:17:58.140000 --> 0:18:00.320000
 tried to close it, actually,
 this should work.

0:18:00.320000 --> 0:18:01.400000
 This very interesting.

0:18:01.400000 --> 0:18:06.740000
 So if we say send, let's send
 and see what happens here.

0:18:06.740000 --> 0:18:09.560000
 So we get the same error.

0:18:09.560000 --> 0:18:18.860000
 Okay. And if successful, the user
 Jeremy should be deleted.

0:18:18.860000 --> 0:18:23.740000
 So I'm just gonna verify that they
 exist here before we proceed.

0:18:23.740000 --> 0:18:27.660000
 So okay, password incorrect.

0:18:27.660000 --> 0:18:29.760000
 Okay, no problem there.

0:18:29.760000 --> 0:18:33.800000
 In fact, what I'm gonna do is I just
 want to verify that this user exists.

0:18:33.800000 --> 0:18:38.160000
 And thank you to the web service for
 providing that functionality because

0:18:38.160000 --> 0:18:43.360000
 I can now just change delete user,
 the operation name here to just get

0:18:43.360000 --> 0:18:50.860000
 user. So I'll say get user and we'll
 change this here as well to get user.

0:18:50.860000 --> 0:18:52.940000
 And we'll get rid of the
 password parameter.

0:18:52.940000 --> 0:18:55.440000
 I'm just testing to see
 if the user exists.

0:18:55.440000 --> 0:18:58.500000
 And if I hit send, it should
 tell us that Jeremy exists.

0:18:58.500000 --> 0:19:01.480000
 So I'll say demo.ini.local.

0:19:01.480000 --> 0:19:03.720000
 And the port here is just 80.

0:19:03.720000 --> 0:19:06.920000
 And I will hit okay.

0:19:06.920000 --> 0:19:08.800000
 And I will then send it.

0:19:08.800000 --> 0:19:13.540000
 And if Jeremy still exists, then yeah,
 okay, so we still need to, we have

0:19:13.540000 --> 0:19:14.300000
 not been successful.

0:19:14.300000 --> 0:19:21.140000
 This is very interesting because if
 we go back into the first one here,

0:19:21.140000 --> 0:19:24.600000
 so delete user Jeremy, then the password.


0:19:24.600000 --> 0:19:26.680000
 Yeah, so this should work actually.

0:19:26.680000 --> 0:19:32.300000
 If we were to put in a valued here, so
 if I say something like test, let's

0:19:32.300000 --> 0:19:34.120000
 just see what happens here.

0:19:34.120000 --> 0:19:36.800000
 So, yeah, okay, that's fine.

0:19:36.800000 --> 0:19:41.200000
 So now I can say test and maybe terminate
 the string literal and say,

0:19:41.200000 --> 0:19:45.480000
 or one equals one, but we would
 need to quote these here.

0:19:45.480000 --> 0:19:49.120000
 So one is going to be equal to one.

0:19:49.120000 --> 0:19:52.640000
 So I'll just say he's going
 to be equal to one.

0:19:52.640000 --> 0:19:53.860000
 We don't need to close that.

0:19:53.860000 --> 0:19:55.380000
 Otherwise, that will not work.

0:19:55.380000 --> 0:19:58.260000
 And I'll just hit send now.

0:19:58.260000 --> 0:20:03.360000
 And there we are, could not authenticate
 password is incorrect.

0:20:03.360000 --> 0:20:06.260000
 So for some reason, it's
 not terminating this.

0:20:06.260000 --> 0:20:09.320000
 What if I add a comment there?

0:20:09.320000 --> 0:20:17.200000
 This is my SQL. So we would then need
 to pretty much specify either a

0:20:17.200000 --> 0:20:20.000000
 pound symbol or something like that.

0:20:20.000000 --> 0:20:21.660000
 Still not working.

0:20:21.660000 --> 0:20:26.760000
 Now, this means that I potentially have
 to analyze that SQL query because

0:20:26.760000 --> 0:20:31.740000
 it was encoded. And I did see the inclusion
 of a third quote here as a

0:20:31.740000 --> 0:20:37.880000
 mistake. So if we go back in here,
 so select username, etc.

0:20:37.880000 --> 0:20:42.680000
 Actually, I want the
 complete encoded one.

0:20:42.680000 --> 0:20:47.040000
 So this one here, right over here.

0:20:47.040000 --> 0:20:56.820000
 And we want to this would roughly translate
 to Yeah, that actually makes

0:20:56.820000 --> 0:21:00.200000
 sense because that would then
 translate that is encoded.

0:21:00.200000 --> 0:21:02.680000
 So you need to decode this.

0:21:02.680000 --> 0:21:06.820000
 And decoding this is fairly simple.

0:21:06.820000 --> 0:21:12.480000
 You can see right over here,
 there's a third one.

0:21:12.480000 --> 0:21:18.860000
 And what that might mean is, okay, we
 terminate the string literal that

0:21:18.860000 --> 0:21:24.400000
 then breaks it or closes
 the the initial tag.

0:21:24.400000 --> 0:21:29.300000
 And then we say or Yeah, that
 might that should work.

0:21:29.300000 --> 0:21:35.120000
 So for example, if I say or one, one,
 one, we can actually just say one

0:21:35.120000 --> 0:21:38.000000
 equals one, let's test this out.

0:21:38.000000 --> 0:21:40.340000
 We don't need to close.

0:21:40.340000 --> 0:21:45.020000
 So I'll just hit send, let's
 see what this brings up.

0:21:45.020000 --> 0:21:47.900000
 Okay, that's not possible.

0:21:47.900000 --> 0:21:51.440000
 So we'll then iterate here a little bit.

0:21:51.440000 --> 0:21:58.000000
 So I will then say, or one equals one.

0:21:58.000000 --> 0:22:04.760000
 Okay, and then what if we included
 a semicolon there to terminate that

0:22:04.760000 --> 0:22:06.540000
 particular point?

0:22:06.540000 --> 0:22:10.840000
 Okay, so that looks like it's working
 in terms of closing it up.

0:22:10.840000 --> 0:22:17.260000
 What if we also try this particular, what
 if we try this particular payload

0:22:17.260000 --> 0:22:18.580000
 for the username?

0:22:18.580000 --> 0:22:21.960000
 So that'll terminate the string
 literal we hit send.

0:22:21.960000 --> 0:22:24.100000
 And there we are.

0:22:24.100000 --> 0:22:28.780000
 So we put it in the username parameter,
 which is my mistake.

0:22:28.780000 --> 0:22:29.600000
 Very, very interesting.

0:22:29.600000 --> 0:22:31.880000
 So that just bypassed it completely.

0:22:31.880000 --> 0:22:34.720000
 I forgot it was still checking
 for the username.

0:22:34.720000 --> 0:22:38.280000
 So there we are deleted
 the account for Jeremy.

0:22:38.280000 --> 0:22:41.780000
 And we earned the flag right over here.

0:22:41.780000 --> 0:22:43.360000
 So that was actually flag one.

0:22:43.360000 --> 0:22:44.360000
 So very interesting.

0:22:44.360000 --> 0:22:49.160000
 If we go back in here and see whether
 we can still query for the user

0:22:49.160000 --> 0:22:54.500000
 Jeremy, it says Jeremy does not exist
 and verifies the fact that we were

0:22:54.500000 --> 0:23:00.100000
 successfully able to successfully able
 to bypass authentication here.

0:23:00.100000 --> 0:23:04.000000
 And then of course, delete the
 user account for Jeremy.

0:23:04.000000 --> 0:23:06.800000
 The bottom line is this
 would not have worked.

0:23:06.800000 --> 0:23:10.580000
 Had I not specified the username here?

0:23:10.580000 --> 0:23:19.480000
 Okay. And by the way, if we send this
 as is, yeah, it'll check for a user.

0:23:19.480000 --> 0:23:22.800000
 So we can do a lot of damage
 here, as you can imagine.

0:23:22.800000 --> 0:23:27.600000
 So this is not advisable, because we're
 now actually causing damage to

0:23:27.600000 --> 0:23:31.460000
 property. That's not ours, technically
 speaking, but all in the name of

0:23:31.460000 --> 0:23:35.540000
 education. Now another thing you can
 do, obviously, if you're testing

0:23:35.540000 --> 0:23:40.860000
 for SQL injection vulnerabilities
 is just fuzz with the intruder.

0:23:40.860000 --> 0:23:45.840000
 So for example, you know, we'll
 get rid of this here.

0:23:45.840000 --> 0:23:48.240000
 And we know that this does not exist.

0:23:48.240000 --> 0:23:50.960000
 And we'll say admin, right?

0:23:50.960000 --> 0:23:55.540000
 And we will get rid of this in here.

0:23:55.540000 --> 0:23:58.800000
 And I will send this to the intruder.

0:23:58.800000 --> 0:24:06.980000
 And if you have some good SQL injection
 payloads within a list, that will

0:24:06.980000 --> 0:24:08.900000
 be a prime place to test this out.

0:24:08.900000 --> 0:24:13.700000
 So I'll add this as the position, we
 can actually go into payloads load.

0:24:13.700000 --> 0:24:19.840000
 And we want to look for, let's see,
 if we do have set lists, then that

0:24:19.840000 --> 0:24:27.460000
 should work. But let's go up a
 level and into a meta exploit.

0:24:27.460000 --> 0:24:28.780000
 Yeah, that's the one we're
 using previously.

0:24:28.780000 --> 0:24:32.520000
 Do we have the sec lists world list here?


0:24:32.520000 --> 0:24:35.700000
 Let's see, we do we do fantastic.

0:24:35.700000 --> 0:24:40.120000
 So we can now go in here, and
 we can go into payloads.

0:24:40.120000 --> 0:24:45.620000
 And actually, no, we want to go into
 fuzzing, believe they are stored

0:24:45.620000 --> 0:24:54.220000
 in here, there we are.

0:24:54.220000 --> 0:24:57.340000
 And we'll test for SQL injection.

0:24:57.340000 --> 0:24:58.840000
 So we'll can now hit start.

0:24:58.840000 --> 0:25:02.800000
 So if you wanted to automate the process
 of, sorry, I don't want to start

0:25:02.800000 --> 0:25:05.040000
 this up here, this is going to fail.

0:25:05.040000 --> 0:25:06.500000
 So I'll just pause this.

0:25:06.500000 --> 0:25:07.760000
 Sorry, that's going to fail.

0:25:07.760000 --> 0:25:12.340000
 I always want to make sure my
 header is specified correctly.

0:25:12.340000 --> 0:25:17.080000
 So in here, the host demo.

0:25:17.080000 --> 0:25:21.860000
 I need local, and I'll
 just start this now.

0:25:21.860000 --> 0:25:26.320000
 And again, we're just monitoring the
 response to see what it's like.

0:25:26.320000 --> 0:25:31.740000
 So the response right over here,
 user admin does not exist.

0:25:31.740000 --> 0:25:32.780000
 Oh, interesting.

0:25:32.780000 --> 0:25:37.840000
 Are you telling me that I
 deleted the admin user?

0:25:37.840000 --> 0:25:42.020000
 Is that what you're telling me through
 some of the earlier techniques?

0:25:42.020000 --> 0:25:51.000000
 Oh, my God. Oh, don't tell me that we were
 that successful almost immediately.

0:25:51.000000 --> 0:25:56.620000
 Let's go back to the, yeah, so you definitely
 in the in the real world,

0:25:56.620000 --> 0:26:01.900000
 don't play around with operations like
 delete user, because they can actually

0:26:01.900000 --> 0:26:04.560000
 delete a user account, even the admin.

0:26:04.560000 --> 0:26:09.420000
 So if I say admin, admin should
 exist, it should exist.

0:26:09.420000 --> 0:26:14.620000
 Oh, my God, we even deleted the admin
 username, which is not good.

0:26:14.620000 --> 0:26:17.520000
 So I'm probably going to have
 to reset my lab environment.

0:26:17.520000 --> 0:26:23.300000
 But yeah, that is how to test for SQL
 injection vulnerabilities on a soap

0:26:23.300000 --> 0:26:26.100000
 web service endpoint.

0:26:26.100000 --> 0:26:29.080000
 And, you know, Motilide has
 some really cool examples.

0:26:29.080000 --> 0:26:33.740000
 I think you guys should be giving
 Motilide a bit more credit now.

0:26:33.740000 --> 0:26:36.540000
 They do have other endpoints
 or web services here.

0:26:36.540000 --> 0:26:43.300000
 So under soap, there is a SQL injection
 specific endpoint that has the

0:26:43.300000 --> 0:26:46.320000
 same operation. So you know,
 you can check that out there.

0:26:46.320000 --> 0:26:48.280000
 I think it should be the same.

0:26:48.280000 --> 0:26:53.180000
 And then of course, we have the command
 injection endpoint, which is what

0:26:53.180000 --> 0:26:54.940000
 we're going to be exploring
 in the next video.

0:26:54.940000 --> 0:26:59.200000
 So that is going to be it for the practical
 demonstration side of this

0:26:59.200000 --> 0:27:01.860000
 video. All right.

0:27:01.860000 --> 0:27:09.380000
 So that was the process of testing for
 SQL injection vulnerabilities on

0:27:09.380000 --> 0:27:14.080000
 a soap web service, specifically one
 that takes in input and does not

0:27:14.080000 --> 0:27:17.160000
 validate or sanitize it.

0:27:17.160000 --> 0:27:19.000000
 And hopefully, found that useful.

0:27:19.000000 --> 0:27:21.960000
 As you saw, we also explored a couple
 of other techniques that unfortunately

0:27:21.960000 --> 0:27:23.880000
 were not successful.

0:27:23.880000 --> 0:27:33.200000
 But again, you know, given that this
 is a deliberately vulnerable web

0:27:33.200000 --> 0:27:39.040000
 slim. And of course, you know, we also
 took a look at how you can automate

0:27:39.040000 --> 0:27:42.900000
 SQL injection with Burp Suite intruder.

0:27:42.900000 --> 0:27:47.520000
 And with our first attack, which did
 work with the intruder, looks like

0:27:47.520000 --> 0:27:48.940000
 it deleted the admin user.

0:27:48.940000 --> 0:27:53.000000
 So always be very, that's
 a cautionary tale.

0:27:53.000000 --> 0:27:58.740000
 When you are performing a pen test, do
 not ensure that you're not deleting

0:27:58.740000 --> 0:28:03.320000
 data or causing damage, because
 I shouldn't have done that.

0:28:03.320000 --> 0:28:06.880000
 But I wanted to show you how to utilize
 the intruder for fuzzing, you

0:28:06.880000 --> 0:28:08.860000
 know, with SQL injection payload.

0:28:08.860000 --> 0:28:11.840000
 So with that being said, that's
 going to be it for this video.

0:28:11.840000 --> 0:28:13.820000
 And I'll be seeing you in the next video.