WEBVTT 0:00:10.920000 --> 0:00:17.200000 Okay. So, key thing to note here is if we just drag this to the side, 0:00:17.200000 --> 0:00:21.200000 I just want to see whether this will affect if we make a new request or 0:00:21.200000 --> 0:00:24.780000 we try and log in again, whether the new select request will prompt it 0:00:24.780000 --> 0:00:28.420000 to, you know, limit the sleep time to only five seconds. 0:00:28.420000 --> 0:00:31.140000 And again, I said, this is not something you need to worry about is just 0:00:31.140000 --> 0:00:34.500000 something that I'm curious off at the moment. 0:00:34.500000 --> 0:00:38.400000 So we will just put in some tests. 0:00:38.400000 --> 0:00:42.880000 Actually, we'll just say, Alexis and password and keep that at the ready. 0:00:42.880000 --> 0:00:45.460000 And we'll send this request here. 0:00:45.460000 --> 0:00:47.800000 And we'll try and log in. 0:00:47.800000 --> 0:00:53.960000 Just try and log in to see whether that will invoke a response after five 0:00:53.960000 --> 0:00:55.960000 seconds and not any any longer. 0:00:55.960000 --> 0:00:58.820000 So not the entire 35 seconds. 0:00:58.820000 --> 0:01:01.580000 But in this case, this doesn't look like it's working. 0:01:01.580000 --> 0:01:06.140000 And I should have actually intercepted that or disabled intercept there. 0:01:06.140000 --> 0:01:11.540000 So in this case, it'll take the entire 35 seconds. 0:01:11.540000 --> 0:01:14.620000 So we'll just wait for the response here. 0:01:14.620000 --> 0:01:19.440000 All right, we can see 35 seconds here. 0:01:19.440000 --> 0:01:21.840000 I just want to try something else out here. 0:01:21.840000 --> 0:01:26.140000 So within a new session, because these are tied to cookies, if I know 0:01:26.140000 --> 0:01:30.480000 the users making a request, would it interrupt that particular flow? 0:01:30.480000 --> 0:01:36.060000 So in my version of Firefox, now I'm just going to send this. 0:01:36.060000 --> 0:01:41.340000 And then if I make a request on the page, again, here, that should limit 0:01:41.340000 --> 0:01:43.420000 it only to sleep for five seconds. 0:01:43.420000 --> 0:01:48.520000 So you know, test and test, and hit log in, for example, there we are, 0:01:48.520000 --> 0:01:52.900000 don't save. No, still looks like it's going to take 35 seconds. 0:01:52.900000 --> 0:01:56.120000 So don't worry, I'm going to explain why this is happening. 0:01:56.120000 --> 0:01:59.220000 I'm just going to wait for the response now. 0:01:59.220000 --> 0:02:03.920000 All right, so there we are exactly 35,000 milliseconds. 0:02:03.920000 --> 0:02:07.040000 So the way this the reason this is not working is because of the logical 0:02:07.040000 --> 0:02:12.900000 operation here. Whereas I said, you know, it'll not find the username 0:02:12.900000 --> 0:02:15.860000 because we have not provided it and is going to run this operation. 0:02:15.860000 --> 0:02:19.560000 And this is going to wait for the next request. 0:02:19.560000 --> 0:02:25.460000 So the way we can fix this is by saying providing a legitimate option 0:02:25.460000 --> 0:02:30.540000 here. So we say, sorry about that, min, so because that we know that's 0:02:30.540000 --> 0:02:34.420000 a legitimate user, and instead of using or we say, and sleep for five 0:02:34.420000 --> 0:02:37.040000 seconds, and one equals one. 0:02:37.040000 --> 0:02:40.420000 All right, so now this should only take five seconds, and this will confirm 0:02:40.420000 --> 0:02:43.740000 the blind time based SQL injection. 0:02:43.740000 --> 0:02:45.220000 So pay attention to the response time. 0:02:45.220000 --> 0:02:48.340000 It should be 5000 milliseconds and some change. 0:02:48.340000 --> 0:02:50.220000 So I'll hit send. 0:02:50.220000 --> 0:02:55.440000 All right, there we are. 0:02:55.440000 --> 0:03:00.540000 So 5,262 milliseconds and now the payload is working as intended, we can 0:03:00.540000 --> 0:03:02.460000 change it to 10 seconds. 0:03:02.460000 --> 0:03:05.100000 And that would be 10,000 milliseconds. 0:03:05.100000 --> 0:03:07.640000 So we'll just run this second test here. 0:03:07.640000 --> 0:03:11.580000 So this again proves that this log in form is indeed vulnerable to SQL 0:03:11.580000 --> 0:03:16.420000 injection, more specifically blind time based SQL injection, and also 0:03:16.420000 --> 0:03:18.780000 to a certain extent, Boolean based injection. 0:03:18.780000 --> 0:03:22.300000 So there we are 10,260 milliseconds. 0:03:22.300000 --> 0:03:27.280000 So again, this all comes down to the actual payload itself, and what we 0:03:27.280000 --> 0:03:30.500000 were essentially asking here of the database. 0:03:30.500000 --> 0:03:32.960000 So we're saying admin, that's true. 0:03:32.960000 --> 0:03:38.040000 So pretty much when utilizing the end operator here, all or both of the 0:03:38.040000 --> 0:03:43.820000 options or queries, or in this case functions and operations need to be 0:03:43.820000 --> 0:03:47.300000 correct. So in this case, admin is a legitimate user. 0:03:47.300000 --> 0:03:51.720000 So it says, okay, I also need to execute this so sleep for five seconds, 0:03:51.720000 --> 0:03:54.080000 and then, you know, one equals one. 0:03:54.080000 --> 0:03:58.320000 So it sleeps for five seconds, and then, you know, also executes one equals 0:03:58.320000 --> 0:04:02.320000 one. And you know, it does it in five seconds as requested. 0:04:02.320000 --> 0:04:08.000000 So this confirms that, you know, there is a blind time based SQL injection 0:04:08.000000 --> 0:04:09.620000 vulnerability here. 0:04:09.620000 --> 0:04:12.940000 And from this point on, you can now move on to the exploitation phase. 0:04:12.940000 --> 0:04:16.340000 However, I really want to focus on some of the other, you know, time based 0:04:16.340000 --> 0:04:21.820000 payloads you can utilize are not limited to, you know, just the sleep 0:04:21.820000 --> 0:04:24.580000 function, which again, can be a little bit tricky to use. 0:04:24.580000 --> 0:04:29.460000 A much better one that I like is the ability to perform a benchmark where 0:04:29.460000 --> 0:04:35.420000 you can tell SQL, or in this case, really the back, the database management 0:04:35.420000 --> 0:04:39.880000 system, which is, and this particular command or function is available 0:04:39.880000 --> 0:04:44.680000 in most mice, most SQL databases or relational databases that utilize 0:04:44.680000 --> 0:04:50.540000 SQL as their primary language, where we can essentially say, right over 0:04:50.540000 --> 0:04:57.120000 here, admin, and I'll just get rid of that here, we can say admin, single 0:04:57.120000 --> 0:05:03.600000 quote, or we can then say benchmark, and we can get it to perform some, 0:05:03.600000 --> 0:05:10.000000 you know, we can pretty much get it to calculate to perform some calculations. 0:05:10.000000 --> 0:05:15.320000 So there's multiple stuff that we can do, we can tell it to encode it, 0:05:15.320000 --> 0:05:19.620000 to encode a specific string of text a certain amount of times, which will 0:05:19.620000 --> 0:05:22.700000 take some time. Right, obviously. 0:05:22.700000 --> 0:05:27.520000 So for example, we can say, or benchmark, any year we can put in maybe, 0:05:27.520000 --> 0:05:38.760000 you know, 1000 times, we want you to encode the string, hello, and yeah, 0:05:38.760000 --> 0:05:39.820000 I think that should be good. 0:05:39.820000 --> 0:05:41.940000 And we'll close that here. 0:05:41.940000 --> 0:05:45.600000 And we'll put in the comment or the pound symbol, and let's control, let's 0:05:45.600000 --> 0:05:48.160000 encode that there, let's send it over. 0:05:48.160000 --> 0:05:53.080000 Now based on the encoding that you specify, it'll obviously take a short 0:05:53.080000 --> 0:05:55.620000 amount of time or a long amount of time, right? 0:05:55.620000 --> 0:06:00.380000 So in this case, we'll have to use and because admin is a real user forgot 0:06:00.380000 --> 0:06:04.860000 to do that. So I'll say send that executed relatively fast, so I'll increase 0:06:04.860000 --> 0:06:09.720000 this. So let's go 10,000. 0:06:09.720000 --> 0:06:13.780000 Actually, let's go 100,000 times or iterations. 0:06:13.780000 --> 0:06:17.340000 In this case, it looks like there's an issue with our query. 0:06:17.340000 --> 0:06:26.400000 So what I'm going to do now is let's change this here to actually let's 0:06:26.400000 --> 0:06:33.360000 unencode this. And we can actually get rid of that there, we can say or 0:06:33.360000 --> 0:06:37.680000 benchmark, 1000 times, in this case, we can increase that a little bit, 0:06:37.680000 --> 0:06:41.500000 encode the word, hello, the string hello there. 0:06:41.500000 --> 0:06:43.840000 And let's try the delimiter. 0:06:43.840000 --> 0:06:45.920000 Maybe that's what's causing the issue there. 0:06:45.920000 --> 0:06:51.700000 So control you to encode URL encode specifically, in this case, yeah, 0:06:51.700000 --> 0:06:53.960000 it didn't look like it did anything there. 0:06:53.960000 --> 0:06:55.620000 Query was passed in successfully. 0:06:55.620000 --> 0:07:00.300000 So maybe we can try and comment this here. 0:07:00.300000 --> 0:07:12.900000 There we are. 30 milliseconds, let's increase this to Alexis or something 0:07:12.900000 --> 0:07:15.540000 a bit longer. Like, let's see. 0:07:15.540000 --> 0:07:25.860000 It's the only word I can think of at the moment, but let's send that over. 0:07:25.860000 --> 0:07:27.920000 Yeah, so that's really not working. 0:07:27.920000 --> 0:07:30.940000 And this is why I said you need to make sure you're monitoring standard 0:07:30.940000 --> 0:07:34.900000 response times and anomalous response time. 0:07:34.900000 --> 0:07:42.080000 So the way I think the way we can make this work, because of I think how 0:07:42.080000 --> 0:07:48.960000 this is structured is, let's just say in this case, admin, and I will 0:07:48.960000 --> 0:07:53.120000 get rid of the remainder of the payload here. 0:07:53.120000 --> 0:07:56.540000 And we can say or benchmark. 0:07:56.540000 --> 0:08:07.460000 And in this case, let's try a 100,000 or actually a million times I want 0:08:07.460000 --> 0:08:10.800000 you to MD five encode the following. 0:08:10.800000 --> 0:08:16.280000 So in this case, we just say one, and then we can use the comment there. 0:08:16.280000 --> 0:08:22.000000 So actually, let's change this to and because admin is exists. 0:08:22.000000 --> 0:08:25.900000 So control you to encode and we'll hit send. 0:08:25.900000 --> 0:08:26.980000 And there we are. 0:08:26.980000 --> 0:08:28.260000 So that looked like it works. 0:08:28.260000 --> 0:08:33.480000 So five 89 milliseconds, if we increase this to, we can say, you know, 0:08:33.480000 --> 0:08:37.220000 we've changed this to five, I think that'll take a bit longer. 0:08:37.220000 --> 0:08:42.700000 Actually, not longer, let's increase this value here to by one more zero 0:08:42.700000 --> 0:08:46.820000 and it's send. Yep, that's going to take much longer now. 0:08:46.820000 --> 0:08:50.300000 So there we are, that took four seconds. 0:08:50.300000 --> 0:08:53.260000 We can obviously, you know, put in some more here. 0:08:53.260000 --> 0:08:58.520000 So, you know, 125, for example, so we just increased the number of iterations. 0:08:58.520000 --> 0:09:01.960000 And that calculation will take longer and therefore delay the execution 0:09:01.960000 --> 0:09:06.980000 of the query. And consequently, the response. 0:09:06.980000 --> 0:09:10.720000 So that proves again, that SQL injection is or this particular application 0:09:10.720000 --> 0:09:14.120000 input, the login form is indeed vulnerable to SQL injection. 0:09:14.120000 --> 0:09:17.440000 So that was four seconds or 4000 milliseconds. 0:09:17.440000 --> 0:09:22.040000 And we'll submit that this will take maybe seven seconds, I think, we'll 0:09:22.040000 --> 0:09:23.620000 see, or eight seconds. 0:09:23.620000 --> 0:09:30.180000 So five seconds, all right, we can increase this to maybe, maybe something 0:09:30.180000 --> 0:09:35.260000 like that, let's see what we can actually maybe put in another five here 0:09:35.260000 --> 0:09:40.180000 just to make it a little bit higher, in terms of the number of iterations. 0:09:40.180000 --> 0:09:43.580000 And you don't want to set this too high, because this can cause delays 0:09:43.580000 --> 0:09:51.700000 or even longer tests to prove that the higher the number of iterations, 0:09:51.700000 --> 0:09:55.220000 the longer the calculation time, and consequently, the longer the response 0:09:55.220000 --> 0:10:01.300000 time, which ultimately verifies that we do have a blind time based SQL 0:10:01.300000 --> 0:10:03.260000 injection vulnerability. 0:10:03.260000 --> 0:10:09.720000 And our SQL query or payload is being successfully executed by the database. 0:10:09.720000 --> 0:10:16.540000 The other option that you have, of course, is is the ability to utilize 0:10:16.540000 --> 0:10:22.080000 the wait for delay option, which again, is really not that difficult to 0:10:22.080000 --> 0:10:27.880000 use with regards to, you know, whether you're dealing with a string, whether 0:10:27.880000 --> 0:10:30.800000 you're dealing with string based injection or string based parameter or 0:10:30.800000 --> 0:10:33.120000 an integer based, based parameter. 0:10:33.120000 --> 0:10:36.020000 The way this would work is, and I think I showed you guys this in the 0:10:36.020000 --> 0:10:41.120000 finding SQL injection vulnerabilities manually video. 0:10:41.120000 --> 0:10:45.680000 But what we'll do is let's get rid of this particular payload here. 0:10:45.680000 --> 0:10:54.380000 And we say admin and, and in this particular case, we can say, let's see, 0:10:54.380000 --> 0:10:59.080000 actually, I don't think we need to do that. 0:10:59.080000 --> 0:11:05.640000 But we could say, for example, and actually, I think we can just say wait 0:11:05.640000 --> 0:11:14.260000 for delay. So wait, wait for delay, and we can specify now a proper time. 0:11:14.260000 --> 0:11:20.500000 So we can say 005 seconds, and we'll use the comment there. 0:11:20.500000 --> 0:11:21.880000 Let's see if this works. 0:11:21.880000 --> 0:11:25.960000 I doubt it's going to work, but we'll need to modify a player around with 0:11:25.960000 --> 0:11:28.500000 a little bit. So send that over. 0:11:28.500000 --> 0:11:30.180000 Yeah, so that's not working. 0:11:30.180000 --> 0:11:32.860000 So let's play around with this payload here. 0:11:32.860000 --> 0:11:38.260000 So we can try including us bracket there. 0:11:38.260000 --> 0:11:40.500000 And let's try and encode this again. 0:11:40.500000 --> 0:11:43.980000 So control you send that over. 0:11:43.980000 --> 0:11:47.060000 So yeah, nothing changed there. 0:11:47.060000 --> 0:11:51.420000 I'm just going to get rid of that comment there. 0:11:51.420000 --> 0:11:56.360000 And control you here, send that over should respond in five seconds. 0:11:56.360000 --> 0:11:58.420000 So this is how you test whether your payloads are working. 0:11:58.420000 --> 0:12:02.600000 You can see that when there's no execution, it takes about 250 milliseconds 0:12:02.600000 --> 0:12:08.420000 to respond, which again, is expected. 0:12:08.420000 --> 0:12:16.580000 What we can do is, let's see, I'm trying to find a way to make this particular 0:12:16.580000 --> 0:12:23.440000 payload work. And I think the best way we can go about doing that is let's 0:12:23.440000 --> 0:12:25.140000 just try and bring this here. 0:12:25.140000 --> 0:12:31.400000 So we say wait for delay, and then let's encode if we need to add a comment, 0:12:31.400000 --> 0:12:32.960000 we will do that. 0:12:32.960000 --> 0:12:38.820000 So we are send. So that's 254 milliseconds or no change there. 0:12:38.820000 --> 0:12:41.800000 We'll add the comment there. 0:12:41.800000 --> 0:12:44.000000 Sorry, that's the wrong position. 0:12:44.000000 --> 0:12:47.800000 But after the single quote there. 0:12:47.800000 --> 0:12:52.820000 And there we go, control you, let's send that over. 0:12:52.820000 --> 0:12:54.600000 Still not working. 0:12:54.600000 --> 0:12:59.220000 Might be down to the use of single quotes here. 0:12:59.220000 --> 0:13:04.020000 I think that might cause an issue, but hey, let's try it out. 0:13:04.020000 --> 0:13:08.860000 Here we are, control you send and we're looking for response of five seconds, 0:13:08.860000 --> 0:13:10.200000 which we don't get. 0:13:10.200000 --> 0:13:11.760000 So we can try other ones. 0:13:11.760000 --> 0:13:17.700000 But I think in this case, what we want to do is let us stick with the 0:13:17.700000 --> 0:13:20.860000 single quote here. 0:13:20.860000 --> 0:13:26.180000 And we will, instead of using the pound symbol, let's try and use the 0:13:26.180000 --> 0:13:28.760000 double hyphen or double dash. 0:13:28.760000 --> 0:13:39.760000 And control you, and we want to payload to utilize. 0:13:39.760000 --> 0:13:46.380000 Maybe we can put this juxtaposed against that, which would then force 0:13:46.380000 --> 0:13:48.200000 it to execute it. 0:13:48.200000 --> 0:13:51.620000 Control you send that over nothing. 0:13:51.620000 --> 0:13:54.020000 So let me try a couple of them. 0:13:54.020000 --> 0:14:01.340000 Let us try and get rid of the single quote here. 0:14:01.340000 --> 0:14:03.520000 And we'll add a space there. 0:14:03.520000 --> 0:14:07.000000 So we terminate and then wait for delay. 0:14:07.000000 --> 0:14:11.980000 We may need to uppercase this, but I think this should work. 0:14:11.980000 --> 0:14:18.740000 So let's see this here, control you, and we will send that over. 0:14:18.740000 --> 0:14:26.140000 So nothing yet. And let's send that over now as is or nothing there. 0:14:26.140000 --> 0:14:27.740000 And you know, even if we did not. 0:14:27.740000 --> 0:14:35.100000 So let's say wait for actually that is. 0:14:35.100000 --> 0:14:41.780000 Yeah, there might be certain cases. 0:14:41.780000 --> 0:14:49.760000 So wait for and then the delay, depending on the SQL version being used, 0:14:49.760000 --> 0:14:57.260000 we can try this out here. 0:14:57.260000 --> 0:15:00.240000 Okay, nothing there. 0:15:00.240000 --> 0:15:09.900000 Wait for delay. Let me try this here. 0:15:09.900000 --> 0:15:11.480000 So again, it's all about testing. 0:15:11.480000 --> 0:15:13.480000 Let's see what's going to work. 0:15:13.480000 --> 0:15:20.360000 And the payload that definitely works here is this one right over here, 0:15:20.360000 --> 0:15:24.680000 where we could actually try and modify, I'll actually show it to you with 0:15:24.680000 --> 0:15:30.720000 a fake user. So let's see if that actually makes it delay for 30 seconds, 0:15:30.720000 --> 0:15:34.600000 because in this case, the sleep duration is set to 10 seconds. 0:15:34.600000 --> 0:15:48.020000 But the time of my SQL, at least in this particular case, but there's 0:15:48.020000 --> 0:15:52.040000 other payloads that I wanted to touch on that I'll get to shortly that 0:15:52.040000 --> 0:15:56.640000 would allow you to, for example, perform database version enumeration 0:15:56.640000 --> 0:16:02.700000 similar to what we did in the previous video, where we essentially trying 0:16:02.700000 --> 0:16:15.360000 to identify whether this will take arguably much longer, given that we're 0:16:15.360000 --> 0:16:18.380000 utilizing a the or statement here. 0:16:18.380000 --> 0:16:22.840000 So just give it a couple of seconds till it's done. 0:16:22.840000 --> 0:16:26.360000 There we are about 70 seconds. 0:16:26.360000 --> 0:16:30.420000 Now there's obviously another one that we can utilize here another another 0:16:30.420000 --> 0:16:34.600000 payload. So I'm just going to get rid of that here, we'll provide a legitimate 0:16:34.600000 --> 0:16:39.760000 user. Or in this case, we don't really, because we can just say, fake, 0:16:39.760000 --> 0:16:42.520000 and we're just gonna paste that in here. 0:16:42.520000 --> 0:16:47.280000 So or if the in this case, we're just trying to confirm whether the database 0:16:47.280000 --> 0:16:54.660000 is indeed running my SQL version five similar to what we did, as I said, 0:16:54.660000 --> 0:16:58.380000 in the previous in the previous video, when you're taking a look at Boolean 0:16:58.380000 --> 0:17:01.060000 based injection, we send. 0:17:01.060000 --> 0:17:05.020000 And I'm gonna wait for the result here. 0:17:05.020000 --> 0:17:08.260000 So there we are. 0:17:08.260000 --> 0:17:12.680000 So seven seconds, five, one, one, and two. 0:17:12.680000 --> 0:17:17.240000 So this looks like it is indeed running version five, we can obviously 0:17:17.240000 --> 0:17:18.460000 modify this here. 0:17:18.460000 --> 0:17:20.700000 So we'll say send to four. 0:17:20.700000 --> 0:17:21.220000 And there we are. 0:17:21.220000 --> 0:17:25.520000 So however, we change it back to five, based on the time taken to execute 0:17:25.520000 --> 0:17:29.460000 it'll execute the sleep operation or function. 0:17:29.460000 --> 0:17:33.460000 And it looks like in this case takes about seven seconds. 0:17:33.460000 --> 0:17:36.300000 So just give it a couple here. 0:17:36.300000 --> 0:17:41.780000 And yeah, looks like that is the case. 0:17:41.780000 --> 0:17:43.520000 So seven seconds. 0:17:43.520000 --> 0:17:46.960000 And that's how you know, you can confirm what version of my SQL or the 0:17:46.960000 --> 0:17:51.320000 database really, the DBMS is running in this case, we know that the first 0:17:51.320000 --> 0:17:58.980000 character of the version info is five, because we, you know, just equated 0:17:58.980000 --> 0:18:02.200000 that there. And if that's the case, it's to sleep. 0:18:02.200000 --> 0:18:05.360000 As you can see here, taking the first value of the character, which is 0:18:05.360000 --> 0:18:10.820000 five. And then that's set to two, which is seven, which makes sense. 0:18:10.820000 --> 0:18:17.280000 So that's seven seconds, which again, is fairly easy or simple to understand. 0:18:17.280000 --> 0:18:19.840000 So again, you can definitely go through this. 0:18:19.840000 --> 0:18:24.780000 There's tons of payloads you can run with regards to time based SQL injection 0:18:24.780000 --> 0:18:26.120000 vulnerabilities. 0:18:26.120000 --> 0:18:31.040000 And that is going to bring us to the end of the practical section of this 0:18:31.040000 --> 0:18:33.540000 video. All right. 0:18:33.540000 --> 0:18:39.260000 So that brings us to the end of the blind SQL injection section of this 0:18:39.260000 --> 0:18:46.320000 course, where we've been able to take a look at both in band SQL injection 0:18:46.320000 --> 0:18:50.780000 vulnerabilities, as well as the respective sub types, that being or those 0:18:50.780000 --> 0:18:55.640000 being error based SQL injection, union based SQL injection. 0:18:55.640000 --> 0:18:59.660000 And then we turned our attention to blind SQL injection vulnerabilities, 0:18:59.660000 --> 0:19:05.060000 where we took a look at the, again, respective subtypes, those being Boolean 0:19:05.060000 --> 0:19:10.180000 based SQL injection, more specifically blind Boolean based SQL injection. 0:19:10.180000 --> 0:19:16.260000 And obviously in this video, we have just concluded our exploration of 0:19:16.260000 --> 0:19:18.720000 time based SQL injection vulnerabilities. 0:19:18.720000 --> 0:19:22.220000 We're now going to turn our attention to the final section of this course, 0:19:22.220000 --> 0:19:28.580000 we will be exploring the fundamentals of no SQL injection or essentially 0:19:28.580000 --> 0:19:35.720000 no SQL databases and the consequent injection of no SQL databases. 0:19:35.720000 --> 0:19:39.880000 With that being said, I'll be seeing you in the next section.