WEBVTT 0:00:09.880000 --> 0:00:13.920000 Apologies, just realizes that was going on that we made a few mistakes 0:00:13.920000 --> 0:00:20.980000 with the positions here where I had sort of added, I had sort of encapsulated 0:00:20.980000 --> 0:00:22.920000 words exact as a payload. 0:00:22.920000 --> 0:00:26.300000 So I'm just going to reset them again and I'll show you what I'm doing. 0:00:26.300000 --> 0:00:32.360000 So words all is a parameter, so I'll add a value or a section there and 0:00:32.360000 --> 0:00:37.240000 we then have words exact equals test and we want to highlight this here. 0:00:37.240000 --> 0:00:42.600000 So I'll add that there and in this particular case, we can essentially 0:00:42.600000 --> 0:00:47.280000 add, you know, test here as well just to make sure it works simply. 0:00:47.280000 --> 0:00:50.320000 This is something I typically like doing with SAP, but again, just the 0:00:50.320000 --> 0:00:54.620000 same thing. I'll start the attack again and this time I'll just take a 0:00:54.620000 --> 0:00:57.100000 look at the request just to see that it's working. 0:00:57.100000 --> 0:01:01.340000 There we are and it's going to go through both of them or iterate through 0:01:01.340000 --> 0:01:03.000000 both parameters. 0:01:03.000000 --> 0:01:06.160000 So right now it's going through words all and then it's going to go through 0:01:06.160000 --> 0:01:12.480000 words exact. So once it's done with the first round, you'll then see it 0:01:12.480000 --> 0:01:17.240000 goes through the second parameter which is words exact and checks it for 0:01:17.240000 --> 0:01:20.720000 injection. So let me see if I can show you this here. 0:01:20.720000 --> 0:01:22.800000 We're almost halfway done. 0:01:22.800000 --> 0:01:29.240000 And if we were to check the actual size of that payload that we had generated, 0:01:29.240000 --> 0:01:33.040000 so this was stored on the desktop SQL injection. 0:01:33.040000 --> 0:01:34.300000 And there we are. 0:01:34.300000 --> 0:01:36.000000 So this about 77. 0:01:36.000000 --> 0:01:42.000000 So after the 77th one is then going to start testing the second parameter 0:01:42.000000 --> 0:01:44.940000 here, which is words exact for injection. 0:01:44.940000 --> 0:01:47.420000 So we're almost there actually. 0:01:47.420000 --> 0:01:52.040000 And in fact, we can actually continue without waiting for this to complete. 0:01:52.040000 --> 0:01:54.260000 So there we are 77. 0:01:54.260000 --> 0:01:58.520000 So the 78th one should start testing words exact. 0:01:58.520000 --> 0:01:59.920000 There we are. Fantastic. 0:01:59.920000 --> 0:02:01.580000 So we can take a look at the results here. 0:02:01.580000 --> 0:02:05.440000 So again, we looks like we have some common lengths here for some of the 0:02:05.440000 --> 0:02:17.180000 payloads. We have a bit of an anomaly here. 0:02:17.180000 --> 0:02:20.700000 So that looks like an increase in terms of the size of the payload. 0:02:20.700000 --> 0:02:26.060000 If we check this one here, it looks like the first parameter is injectable. 0:02:26.060000 --> 0:02:29.460000 So that is words all. 0:02:29.460000 --> 0:02:33.140000 And the reason for that is obviously because we get the database error. 0:02:33.140000 --> 0:02:36.540000 So we know it is vulnerable to error based SQL injection. 0:02:36.540000 --> 0:02:41.500000 And in this case, it also gives us the remaining section of the query 0:02:41.500000 --> 0:02:45.120000 or the second part of the query after the injection point or after we've 0:02:45.120000 --> 0:02:48.220000 terminated the string literal using the single quote. 0:02:48.220000 --> 0:02:54.140000 And if we go to anything after, like for example, the second parameter. 0:02:54.140000 --> 0:02:58.020000 So where it's exact, that also looks like it is vulnerable because we 0:02:58.020000 --> 0:02:59.780000 get an error here. 0:02:59.780000 --> 0:03:04.780000 So now that we've identified all application inputs and we know that really 0:03:04.780000 --> 0:03:08.940000 all of them are injectable, the question is which one do we start off 0:03:08.940000 --> 0:03:15.420000 with with regards to performing or utilizing payloads together more information. 0:03:15.420000 --> 0:03:17.020000 Well, the one we can start off with. 0:03:17.020000 --> 0:03:19.600000 And again, I'm not going to wait for the fuzzing to complete here because 0:03:19.600000 --> 0:03:22.940000 we've already identified what we needed to identify. 0:03:22.940000 --> 0:03:29.800000 I'm just going to discard that and we can for that request there. 0:03:29.800000 --> 0:03:30.500000 And there we are. 0:03:30.500000 --> 0:03:34.480000 So we'll go back to the web app and we can all proceed with the next phase. 0:03:34.480000 --> 0:03:39.240000 So now that we've identified the application inputs, we've tested them. 0:03:39.240000 --> 0:03:41.980000 We know that there is no input validation. 0:03:41.980000 --> 0:03:45.600000 And we know that pretty much all of them with regards to specific parameters 0:03:45.600000 --> 0:03:50.700000 are vulnerable to error based SQL injection with specific payloads. 0:03:50.700000 --> 0:03:55.060000 We can now turn our attention to identifying or performing, you know, 0:03:55.060000 --> 0:03:58.260000 essentially learning more about the database and the web application itself 0:03:58.260000 --> 0:03:59.880000 through the use of other payloads. 0:03:59.880000 --> 0:04:03.560000 So going back to the GitHub repo where we copied, you know, some of these 0:04:03.560000 --> 0:04:08.140000 SQL injection payloads, you can now look for error based payloads here 0:04:08.140000 --> 0:04:13.040000 that can be utilized to enumerate information about the database. 0:04:13.040000 --> 0:04:17.620000 So for example, in this particular case, we can try and enumerate the 0:04:17.620000 --> 0:04:21.720000 MySQL version or the version of the database using this payload. 0:04:21.720000 --> 0:04:25.840000 And the way we can do that is obviously by injecting it. 0:04:25.840000 --> 0:04:30.400000 So I'll just disable intercept and we can utilize the search here and 0:04:30.400000 --> 0:04:35.120000 we'll use the exact phase, the exact phrase parameter. 0:04:35.120000 --> 0:04:41.220000 And what we can do is just say test and I'm going to turn in or turn on 0:04:41.220000 --> 0:04:45.360000 intercept and we can then search and then inject it in here. 0:04:45.360000 --> 0:04:49.820000 So I'm just going to, for the parameter words exact, I'm just going to 0:04:49.820000 --> 0:04:52.160000 paste in the payload there. 0:04:52.160000 --> 0:04:56.100000 And in this case, we're going to add the comment and we're also going 0:04:56.100000 --> 0:05:04.280000 to add the single quote delimiter. 0:05:04.280000 --> 0:05:06.560000 So I'm going to add the text to payloads and I'll walk you through how 0:05:06.560000 --> 0:05:09.200000 we can automate this, but I'll say forward. 0:05:09.200000 --> 0:05:10.780000 All right, there we are. 0:05:10.780000 --> 0:05:14.920000 So in this particular case, it's saying we, the injection is successful. 0:05:14.920000 --> 0:05:17.820000 However, it says that we have a syntax error. 0:05:17.820000 --> 0:05:19.860000 So this payload might not be applicable. 0:05:19.860000 --> 0:05:26.620000 All right. And if we go into this and we go back into search or we sort 0:05:26.620000 --> 0:05:27.820000 of resend that again. 0:05:27.820000 --> 0:05:30.400000 And we paste in the payload there. 0:05:30.400000 --> 0:05:33.940000 I'm just going to URL encoded because in certain cases, this might be 0:05:33.940000 --> 0:05:35.340000 causing the issue. 0:05:35.340000 --> 0:05:38.360000 So there we are single URL and code and for that. 0:05:38.360000 --> 0:05:40.480000 And let's see what we get. 0:05:40.480000 --> 0:05:42.340000 Still, we still get the database error. 0:05:42.340000 --> 0:05:45.480000 So again, just make another request there. 0:05:45.480000 --> 0:05:50.060000 Paste that in. Maybe try double URL encoding in case any special characters 0:05:50.060000 --> 0:05:52.960000 are not being sent successfully in the URL. 0:05:52.960000 --> 0:05:55.440000 So for that there. 0:05:55.440000 --> 0:06:00.480000 And yeah, that's typically when you do a double URL encoding that will 0:06:00.480000 --> 0:06:02.940000 also convert the string or the SQL query. 0:06:02.940000 --> 0:06:05.020000 So we don't want to do that. 0:06:05.020000 --> 0:06:09.540000 So we can go back to that GitHub repo here and try and find some others. 0:06:09.540000 --> 0:06:13.280000 Now, of course, as you can obviously tell, this will take a lot of time 0:06:13.280000 --> 0:06:15.680000 and we're dealing with error based injection here. 0:06:15.680000 --> 0:06:20.360000 So it's again, it's all going to depend on the back end or the DBMS being 0:06:20.360000 --> 0:06:24.780000 used and you know how the web application is designed, what query is being 0:06:24.780000 --> 0:06:29.040000 used, etc. The point I'm making is at this point, we typically want to 0:06:29.040000 --> 0:06:32.620000 utilize a tool like SQL map. 0:06:32.620000 --> 0:06:34.880000 All right. Now, what is SQL map? 0:06:34.880000 --> 0:06:36.300000 I'll just introduce you to it here. 0:06:36.300000 --> 0:06:38.440000 I'll just perform a quick Google search. 0:06:38.440000 --> 0:06:42.500000 I'll open up their website and I'll give you an intro to it. 0:06:42.500000 --> 0:06:46.940000 So SQL map is an open source penetration testing tool that automates the 0:06:46.940000 --> 0:06:51.500000 process of detecting and exploiting SQL injection flows and taking over 0:06:51.500000 --> 0:06:52.720000 database servers. 0:06:52.720000 --> 0:06:57.480000 It comes with a powerful detection engine, many niche features for the 0:06:57.480000 --> 0:06:59.080000 ultimate penetration tester. 0:06:59.080000 --> 0:07:05.000000 In our case, the reason we want to use it in this case is to identify 0:07:05.000000 --> 0:07:10.240000 the payload that we can use to enumerate information or to get information 0:07:10.240000 --> 0:07:12.320000 from the database. 0:07:12.320000 --> 0:07:16.880000 And in most cases, when you're dealing with real world web applications, 0:07:16.880000 --> 0:07:21.500000 the standard vanilla SQL payloads displayed here will only work great 0:07:21.500000 --> 0:07:26.940000 for identifying the vulnerability, but not really for information extraction. 0:07:26.940000 --> 0:07:31.280000 So the point I'm making is firstly, we're using it to generate payloads 0:07:31.280000 --> 0:07:33.280000 and it'll do it really well for us. 0:07:33.280000 --> 0:07:39.260000 And as you can see here, the SQL map comes with a powerful detection engine, 0:07:39.260000 --> 0:07:42.760000 many niche features for the ultimate penetration tester and a broad range 0:07:42.760000 --> 0:07:46.080000 of switches lasting from database fingerprinting, which is fantastic, 0:07:46.080000 --> 0:07:49.300000 which we've done at a basic level. 0:07:49.300000 --> 0:07:52.600000 We have made an assumption about, we know it's running MySQL, but not 0:07:52.600000 --> 0:07:57.720000 the exact version over data fetching from the database to accessing the 0:07:57.720000 --> 0:08:01.620000 underlying file system and executing commands on the operating system 0:08:01.620000 --> 0:08:03.380000 via out of band connection. 0:08:03.380000 --> 0:08:08.460000 So SQL SQL map is what is typically used for out of band SQL injection 0:08:08.460000 --> 0:08:13.340000 in that. Once the injection is performed, we essentially get the database 0:08:13.340000 --> 0:08:16.560000 to communicate to another endpoint, which in this case is controlled by 0:08:16.560000 --> 0:08:20.160000 SQL map. With that being said, let's take a look at how to use it. 0:08:20.160000 --> 0:08:24.480000 So to use it on Linux specifically on Kali Linux, you want to make sure 0:08:24.480000 --> 0:08:28.680000 your repositories are updated and you can install it by saying sudo apt 0:08:28.680000 --> 0:08:31.700000 get install SQL map. 0:08:31.700000 --> 0:08:35.880000 All right. It's typically not installed by default on Kali. 0:08:35.880000 --> 0:08:38.740000 In my case, it looks like we have an update here. 0:08:38.740000 --> 0:08:41.360000 So I'll go ahead and go through the update. 0:08:41.360000 --> 0:08:44.160000 It's always good to keep it up to date. 0:08:44.160000 --> 0:08:48.020000 And what I'm going to do now is just wait for this to complete. 0:08:48.020000 --> 0:08:53.200000 There we are. And there we are. 0:08:53.200000 --> 0:08:57.680000 So you can launch SQL map by saying it's a command line utility by just 0:08:57.680000 --> 0:08:59.220000 opening up the help menu. 0:08:59.220000 --> 0:09:01.560000 And again, we're not focusing on all the features here. 0:09:01.560000 --> 0:09:04.540000 We're going to go through these exploitation videos and I'm going to show 0:09:04.540000 --> 0:09:06.480000 you a little bit about how to use it. 0:09:06.480000 --> 0:09:09.640000 And by the end of it, you should know all of the essentials. 0:09:09.640000 --> 0:09:12.900000 So it's a very, very, very powerful tool. 0:09:12.900000 --> 0:09:16.540000 And I'm showing you how to use it firstly to generate the error based 0:09:16.540000 --> 0:09:22.460000 payload that can help us get information from the database information 0:09:22.460000 --> 0:09:26.620000 that can be used to learn more about the database, how data is stored 0:09:26.620000 --> 0:09:33.260000 tables, etc. And then once that is done, we can actually utilize SQL map 0:09:33.260000 --> 0:09:38.940000 to dump the tables, the columns within tables, so on and so forth. 0:09:38.940000 --> 0:09:40.700000 So that's what we're going to be taking a look at. 0:09:40.700000 --> 0:09:46.280000 So I'll just navigate to the desktop and let's identify the application 0:09:46.280000 --> 0:09:48.280000 input that we want to test. 0:09:48.280000 --> 0:09:50.340000 So let's use the search one here. 0:09:50.340000 --> 0:09:52.020000 So do search.php. 0:09:52.020000 --> 0:09:55.500000 Going to go back into burp suite and I'm going to show you a really easy 0:09:55.500000 --> 0:09:57.540000 way of using SQL map. 0:09:57.540000 --> 0:09:59.380000 So intercept is on. 0:09:59.380000 --> 0:10:02.700000 I'm going to just resubmit this here. 0:10:02.700000 --> 0:10:04.940000 And we can again test for the same one here. 0:10:04.940000 --> 0:10:09.720000 So words exact equals, we'll test this parameter for injection. 0:10:09.720000 --> 0:10:13.160000 And we want to save this post request. 0:10:13.160000 --> 0:10:15.100000 All right, so you just want to copy it. 0:10:15.100000 --> 0:10:16.840000 Burp suite allows you to do this. 0:10:16.840000 --> 0:10:19.660000 And I'm going to open up a text editor here. 0:10:19.660000 --> 0:10:24.500000 And I'm going to paste it in as is and I'm going to save it on my desktop 0:10:24.500000 --> 0:10:27.440000 as request dot txt. 0:10:27.440000 --> 0:10:28.700000 So save it as a text file. 0:10:28.700000 --> 0:10:32.360000 So in this case, I'll just save it as request. 0:10:32.360000 --> 0:10:37.000000 There we are. Now, the reason I'm doing this is because when a lot of 0:10:37.000000 --> 0:10:38.760000 people are learning. 0:10:38.760000 --> 0:10:46.100000 Or are using SQL map, they typically will need to specify the URL manually. 0:10:46.100000 --> 0:10:51.160000 The parameter that they want to inject as well as the type of injections 0:10:51.160000 --> 0:10:52.400000 they want to test for. 0:10:52.400000 --> 0:10:55.660000 So in this case, we've already identified that, you know, it's error based 0:10:55.660000 --> 0:10:58.020000 injection, which will save us a lot of time. 0:10:58.020000 --> 0:11:02.240000 So I'll just forward that request there and we'll go back into our terminal. 0:11:02.240000 --> 0:11:04.520000 So first things first. 0:11:04.520000 --> 0:11:06.060000 What can you do? 0:11:06.060000 --> 0:11:08.800000 What's the typical way of using SQL map? 0:11:08.800000 --> 0:11:12.040000 Right. So the typical way is very, very, very simple. 0:11:12.040000 --> 0:11:16.400000 And that will typically involve, you know, running a command like, and 0:11:16.400000 --> 0:11:19.200000 this is again without the actual request file. 0:11:19.200000 --> 0:11:24.320000 We say SQL map. You for the URL and then within double quotes, we want 0:11:24.320000 --> 0:11:26.940000 to put in the URL itself so we can just copy it. 0:11:26.940000 --> 0:11:29.460000 So again, copy the injectable URL. 0:11:29.460000 --> 0:11:35.060000 Or the URL of the page that is where you're performing the injection. 0:11:35.060000 --> 0:11:37.840000 So within the double quotes, I'll put it in here. 0:11:37.840000 --> 0:11:44.580000 And now you typically say, you typically specify the data that you want 0:11:44.580000 --> 0:11:45.960000 to submit or the parameter. 0:11:45.960000 --> 0:11:49.560000 So in this case, data is going to be words exact. 0:11:49.560000 --> 0:11:52.900000 So the name of the parameter. 0:11:52.900000 --> 0:11:57.420000 So words exact is equal to and then close the quotes there. 0:11:57.420000 --> 0:12:02.480000 And then you can say, P for the payload. 0:12:02.480000 --> 0:12:05.700000 In this case, the payload is going to be words exact. 0:12:05.700000 --> 0:12:09.520000 So where you want to inject the payloads or where you want SQL map to 0:12:09.520000 --> 0:12:10.420000 inject the payloads. 0:12:10.420000 --> 0:12:12.760000 And I'm going to zoom in a little bit here. 0:12:12.760000 --> 0:12:15.980000 And then the method in this case is post. 0:12:15.980000 --> 0:12:18.120000 All right, because this is a post request. 0:12:18.120000 --> 0:12:22.060000 If we take a look at the request here that we saved, it's a post request. 0:12:22.060000 --> 0:12:24.400000 So that this is one way of doing it. 0:12:24.400000 --> 0:12:25.940000 And this will work just fine. 0:12:25.940000 --> 0:12:30.520000 However, this usually causes issues with some of the later versions of 0:12:30.520000 --> 0:12:32.740000 the later versions of SQL map. 0:12:32.740000 --> 0:12:37.920000 So what I typically like doing is saving the request and leaving SQL map 0:12:37.920000 --> 0:12:40.620000 to identify the rest like the URL, etc. 0:12:40.620000 --> 0:12:42.420000 And whether to use SSL. 0:12:42.420000 --> 0:12:47.680000 So what we can do now is essentially say SQL map. 0:12:47.680000 --> 0:12:52.860000 And we specify R for request and then make sure you are within the working 0:12:52.860000 --> 0:12:56.620000 directory where you saved the request or just specify the absolute path 0:12:56.620000 --> 0:12:59.780000 to the request file or the file containing the request. 0:12:59.780000 --> 0:13:01.980000 And then you specify the payload. 0:13:01.980000 --> 0:13:05.160000 So where you want the parameter you want injected. 0:13:05.160000 --> 0:13:07.280000 In this case, words exact. 0:13:07.280000 --> 0:13:11.400000 Right. So we'll say words exact. 0:13:11.400000 --> 0:13:18.800000 And now we want to what we can do is specify the technique that we want 0:13:18.800000 --> 0:13:21.340000 to use, which will save us a lot of time. 0:13:21.340000 --> 0:13:24.620000 And again, I'm showing you some really useful tips and tricks. 0:13:24.620000 --> 0:13:28.500000 So with SQL map, you can specify the techniques SQL injection techniques 0:13:28.500000 --> 0:13:33.780000 or error based Boolean based union, etc. 0:13:33.780000 --> 0:13:37.580000 In this case, we'll let's go for error based because we've already identified 0:13:37.580000 --> 0:13:40.880000 that it's an error based SQL injection vulnerability. 0:13:40.880000 --> 0:13:43.240000 And we're going to hit enter. 0:13:43.240000 --> 0:13:48.340000 All right. Now it's going to ask us to that it got a 307 redirect because 0:13:48.340000 --> 0:13:53.520000 it's an HTTPS site and it doesn't have an invalid SSL set. 0:13:53.520000 --> 0:13:57.060000 We're just going to it enter for the default option, which is yes. 0:13:57.060000 --> 0:14:03.300000 It's now going to ask you do the there is a reader because of the redirect 0:14:03.300000 --> 0:14:05.560000 because it's a post request. 0:14:05.560000 --> 0:14:10.520000 Do you want to send or resend the original post data to a new location? 0:14:10.520000 --> 0:14:12.300000 The answer to that is no. 0:14:12.300000 --> 0:14:15.820000 Always set that to know, especially with post requests. 0:14:15.820000 --> 0:14:18.340000 All right. So we'll give it a couple of seconds. 0:14:18.340000 --> 0:14:21.600000 It's now going to ask you right over here. 0:14:21.600000 --> 0:14:24.780000 If we take a look at the results. 0:14:24.780000 --> 0:14:29.400000 Heuristic or basic tests show that the post parameter words exact might 0:14:29.400000 --> 0:14:34.600000 be injectable and the possible database management system is MySQL. 0:14:34.600000 --> 0:14:36.320000 All right. We already knew that. 0:14:36.320000 --> 0:14:41.120000 And then it says testing for SQL injection on post parameter words exact. 0:14:41.120000 --> 0:14:44.940000 It looks like the backend database management system is MySQL. 0:14:44.940000 --> 0:14:51.500000 Do you want to skip to skip test payloads specific for other DBMSs? 0:14:51.500000 --> 0:14:52.820000 Yes, we do because we already know that. 0:14:52.820000 --> 0:14:54.200000 We already know it's MySQL. 0:14:54.200000 --> 0:14:59.520000 So there's no need of running or testing payloads for other database management 0:14:59.520000 --> 0:15:01.980000 systems like postgreSQL, et cetera. 0:15:01.980000 --> 0:15:07.440000 So let's yes. It's going to say after that for the remaining test, you 0:15:07.440000 --> 0:15:12.560000 want to include all tests for MySQL extending provided level one and risk 0:15:12.560000 --> 0:15:18.220000 one value. So level one refers to the depth and risk one refers to the 0:15:18.220000 --> 0:15:21.720000 types of payloads that will be used with regards to what type of information 0:15:21.720000 --> 0:15:22.680000 they'll extract. 0:15:22.680000 --> 0:15:26.140000 So if you're doing a bug bounty, if you're, you know, if you're doing 0:15:26.140000 --> 0:15:30.080000 bug bounty hunting or web application, pen test, always leave the level 0:15:30.080000 --> 0:15:31.740000 and risk at one. 0:15:31.740000 --> 0:15:37.140000 And I'll explain what these levels and risk levels are as we progress 0:15:37.140000 --> 0:15:41.100000 in this course. But for now, just hit yes, it will essentially ensure 0:15:41.100000 --> 0:15:45.680000 that SQL map does not use any payloads that might damage the database 0:15:45.680000 --> 0:15:48.700000 or the data stored there in or anything. 0:15:48.700000 --> 0:15:51.200000 It'll not use any malicious SQL payload. 0:15:51.200000 --> 0:15:52.760000 So I'll hit yes. 0:15:52.760000 --> 0:15:58.560000 All right. So now it's going to test in this particular case, MySQL version 0:15:58.560000 --> 0:16:05.560000 5.5 or greater than or equal to 5.5 and error based payloads. 0:16:05.560000 --> 0:16:06.760000 So there we are. 0:16:06.760000 --> 0:16:10.020000 And in this case, it looks like the pig integer unsigned. 0:16:10.020000 --> 0:16:12.640000 So we're going to let this run for a couple of seconds. 0:16:12.640000 --> 0:16:17.920000 Now, in certain cases, as you can see here, this is going to take a couple 0:16:17.920000 --> 0:16:22.780000 of seconds to a couple of minutes, depending on the tests being run. 0:16:22.780000 --> 0:16:27.800000 All right. Now, there's a better way of speeding this up. 0:16:27.800000 --> 0:16:32.380000 All right. And the way you can go about speeding this up is to, you know, 0:16:32.380000 --> 0:16:37.540000 utilize the time second interval or to optimize the scan. 0:16:37.540000 --> 0:16:40.700000 Now, by default, we can already see that it's done. 0:16:40.700000 --> 0:16:42.900000 All right. So it's right over here. 0:16:42.900000 --> 0:16:48.280000 It's going to tell us post parameter words exact is MySQL greater than 0:16:48.280000 --> 0:16:53.540000 or equal to 5.5 and error based injectable and SQL map identified the 0:16:53.540000 --> 0:16:57.360000 following injection points with a total of 37 HTTP requests. 0:16:57.360000 --> 0:17:01.600000 So it ran multiple iterations to identify the correct payload that in 0:17:01.600000 --> 0:17:03.880000 this case looks like it's going to display. 0:17:03.880000 --> 0:17:08.320000 If we take a look at the payload here, we can see that the payload is 0:17:08.320000 --> 0:17:15.140000 exact test equals test in Boolean mode and select if select from select 0:17:15.140000 --> 0:17:20.780000 concatenate. And these have been turned into hacks, select. 0:17:20.780000 --> 0:17:26.640000 And there's a utilization of a logical or mathematical operation always 0:17:26.640000 --> 0:17:31.220000 said to true. And it's going to extract specific information. 0:17:31.220000 --> 0:17:34.080000 All right. Now, I'll explain what this means. 0:17:34.080000 --> 0:17:38.600000 But what we can do is just copy the payload here that is provided to you 0:17:38.600000 --> 0:17:40.880000 again, ending with the payload ends. 0:17:40.880000 --> 0:17:47.300000 So before the other injectable parameter, which is words any, we'll copy 0:17:47.300000 --> 0:17:50.740000 this here. And I'm going to open up a new text file. 0:17:50.740000 --> 0:17:52.740000 And I am going to save it in here. 0:17:52.740000 --> 0:17:54.360000 And I'm going to zoom in. 0:17:54.360000 --> 0:17:58.860000 All right. So what we can do now is copy this and go back into the web 0:17:58.860000 --> 0:18:00.740000 app and into burp suite. 0:18:00.740000 --> 0:18:02.740000 Sorry, and make sure intercept is on. 0:18:02.740000 --> 0:18:05.240000 And we're going to make another request here. 0:18:05.240000 --> 0:18:09.540000 And within this particular or the value for this parameter will perform 0:18:09.540000 --> 0:18:14.520000 the injection. However, now with the payload provided to us by SQL map. 0:18:14.520000 --> 0:18:16.720000 So we'll paste it in. 0:18:16.720000 --> 0:18:20.060000 All right. And it is recommended to always URL encode this. 0:18:20.060000 --> 0:18:26.740000 So one time URL encode, which is done through the keyboard keyboard combination 0:18:26.740000 --> 0:18:28.260000 control and you. 0:18:28.260000 --> 0:18:31.240000 And you can then just hit forward. 0:18:31.240000 --> 0:18:34.720000 We'll now take a look at the web application here. 0:18:34.720000 --> 0:18:38.340000 And in this particular case, we do get some information. 0:18:38.340000 --> 0:18:40.480000 So what information have we got. 0:18:40.480000 --> 0:18:45.620000 So in order to identify what info has been dumped here, because SQL map 0:18:45.620000 --> 0:18:47.320000 will not tell us that. 0:18:47.320000 --> 0:18:50.660000 If we take a look at it here and let's take a look at the other results 0:18:50.660000 --> 0:18:53.680000 firstly, but we can see that it's error based, right? 0:18:53.680000 --> 0:18:55.280000 And the parameter is words exact. 0:18:55.280000 --> 0:18:57.100000 It tells us the payload. 0:18:57.100000 --> 0:19:01.320000 In this case, we're having order by group by clause and the payload. 0:19:01.320000 --> 0:19:03.880000 Don't tell us what it what info it displays. 0:19:03.880000 --> 0:19:08.280000 But it tells us the web server operating system is Linux Ubuntu. 0:19:08.280000 --> 0:19:14.920000 And the web application technology is Apache 2.4.7 and PHP 5.5.9. 0:19:14.920000 --> 0:19:20.540000 And the backend DBMS is my SQL 5 greater than or equal to 5.5. 0:19:20.540000 --> 0:19:22.880000 Not the exact version and nothing else. 0:19:22.880000 --> 0:19:28.480000 Now these string of numbers have been encoded in hexadecimal. 0:19:28.480000 --> 0:19:34.440000 This is something that MySQL will typically do or rather not MySQL SQL 0:19:34.440000 --> 0:19:39.300000 map will typically do to evade detection. 0:19:39.300000 --> 0:19:42.700000 So bypass very rudimentary input validation. 0:19:42.700000 --> 0:19:47.380000 And the way we can check what each of these means or what each of these 0:19:47.380000 --> 0:19:53.660000 hex encoded strings or rather pieces of data means is by utilizing cyber 0:19:53.660000 --> 0:19:58.820000 chef. So we can actually convert from hex into clear text. 0:19:58.820000 --> 0:20:01.720000 And this is obviously not the correct way of doing it. 0:20:01.720000 --> 0:20:06.580000 What we can obviously try and view is what data is being displayed. 0:20:06.580000 --> 0:20:11.780000 So we can copy any of these here, for example, like this here. 0:20:11.780000 --> 0:20:15.040000 And we can see in this case, it looks like it's just a random string of 0:20:15.040000 --> 0:20:16.960000 text. Let's try the other one. 0:20:16.960000 --> 0:20:19.620000 So for example, this one here. 0:20:19.620000 --> 0:20:21.780000 And let's see what this means. 0:20:21.780000 --> 0:20:24.000000 We print that out looks like the same. 0:20:24.000000 --> 0:20:28.080000 And we can then say zero X 78. 0:20:28.080000 --> 0:20:30.400000 And that refers to a single X. 0:20:30.400000 --> 0:20:31.580000 So it's just taking a big string. 0:20:31.580000 --> 0:20:34.380000 And we can see a payload that you might have seen are publicly accessible 0:20:34.380000 --> 0:20:39.120000 or publicly available on a GitHub repo and just converting it right. 0:20:39.120000 --> 0:20:43.680000 And what we can do in this particular case, if we take a look at the the 0:20:43.680000 --> 0:20:48.720000 output from the web application, it says it displays exactly that select 0:20:48.720000 --> 0:20:51.960000 the following string from dual. 0:20:51.960000 --> 0:20:56.260000 And then, you know, these two operations here, right. 0:20:56.260000 --> 0:21:01.440000 And now what we can do is we can modify this particular payload to display 0:21:01.440000 --> 0:21:03.640000 info that is useful to us. 0:21:03.640000 --> 0:21:05.680000 Now what type of info might we want? 0:21:05.680000 --> 0:21:11.420000 So for example, the type of info we may want is so after this here, we 0:21:11.420000 --> 0:21:14.360000 know that this just displays X, right. 0:21:14.360000 --> 0:21:20.900000 We can utilize the MySQL version command to display the MySQL version. 0:21:20.900000 --> 0:21:23.060000 So just version and double quotes. 0:21:23.060000 --> 0:21:24.900000 And then we can use the same payload. 0:21:24.900000 --> 0:21:29.440000 And this should output the version of the MySQL database being used. 0:21:29.440000 --> 0:21:35.520000 So go back into BERF suite and we're going to resend the request. 0:21:35.520000 --> 0:21:41.200000 And we're going to replace that particular value there with our own SQL 0:21:41.200000 --> 0:21:42.840000 injection payload. 0:21:42.840000 --> 0:21:48.040000 And again, make sure we actually URL encode this. 0:21:48.040000 --> 0:21:49.660000 So there we are one time. 0:21:49.660000 --> 0:21:52.220000 And I'm going to forward that request there. 0:21:52.220000 --> 0:21:53.800000 We take a look at the results. 0:21:53.800000 --> 0:21:58.400000 You can now see that if select, and then we have that string here, it 0:21:58.400000 --> 0:22:04.120000 then displays the version of MySQL running on this particular web server. 0:22:04.120000 --> 0:22:09.820000 And in this case, it tells us it's 5 .5.47 on Ubuntu, which verifies that 0:22:09.820000 --> 0:22:11.580000 this info is correct. 0:22:11.580000 --> 0:22:17.440000 So as you can see, SQL map is useful, not just for the crazy complex attacks. 0:22:17.440000 --> 0:22:22.880000 It's really useful, firstly, in identifying payloads that can be used 0:22:22.880000 --> 0:22:27.400000 to dump info. And again, as I said, this is the accidental stuff is typically 0:22:27.400000 --> 0:22:32.220000 added there to evade detection, which you can also explore. 0:22:32.220000 --> 0:22:35.360000 And in this case, you know, you're able to use a tool like Cyber Chef 0:22:35.360000 --> 0:22:39.160000 to easily decode it or view it in ASCII. 0:22:39.160000 --> 0:22:44.280000 And in this case, you know, it's just trying to utilize again where having 0:22:44.280000 --> 0:22:48.100000 order by your group by clauses to display information. 0:22:48.100000 --> 0:22:53.260000 And in this case, we're able to get the version of MySQL running, which 0:22:53.260000 --> 0:22:55.600000 it wasn't able to get in and of itself. 0:22:55.600000 --> 0:22:56.840000 So that's pretty cool. 0:22:56.840000 --> 0:23:00.100000 Let's take a look at what else we can do. 0:23:00.100000 --> 0:23:05.120000 So after you've identified the DBMS running, as well as the version of 0:23:05.120000 --> 0:23:10.040000 the DBMS, you can take a look at another GitHub repo called payload, all 0:23:10.040000 --> 0:23:13.340000 the things which most of you should be familiar with if you're a pen tester. 0:23:13.340000 --> 0:23:19.920000 And under SQL injection, we have a MySQL injection section or Markdown 0:23:19.920000 --> 0:23:24.760000 file that will provide you with advanced payloads right over here to identify 0:23:24.760000 --> 0:23:28.900000 specific information based on the version of MySQL that's running. 0:23:28.900000 --> 0:23:34.620000 So for example, if we have the version of MySQL running is greater than 0:23:34.620000 --> 0:23:40.920000 or equal to 5.1, we can utilize these payloads here to try and enumerate 0:23:40.920000 --> 0:23:46.800000 information. So for example, if I take a look at some of these here, let's 0:23:46.800000 --> 0:23:50.800000 see one that matches the one that's SQL map utilized, we can see the one 0:23:50.800000 --> 0:23:54.480000 that's SQL map utilized was something similar to this, but we can try 0:23:54.480000 --> 0:23:58.400000 any of them. So let's try this one here. 0:23:58.400000 --> 0:24:01.260000 All right, and we may need to modify it, but let's go ahead and try it 0:24:01.260000 --> 0:24:06.180000 out. So I'll re send that and we'll intercept it with burp suite. 0:24:06.180000 --> 0:24:08.880000 And I'll paste this in here. 0:24:08.880000 --> 0:24:13.080000 And the first thing we want to do is use a single quote there, because 0:24:13.080000 --> 0:24:14.840000 this is string based injection. 0:24:14.840000 --> 0:24:18.840000 And we want to instead of using the double dash here, we may want to try 0:24:18.840000 --> 0:24:25.440000 it out. We can actually just URL encode that payload, say, control you 0:24:25.440000 --> 0:24:27.360000 to encode it and we can afford it. 0:24:27.360000 --> 0:24:29.740000 Let's see whether this is valid at all. 0:24:29.740000 --> 0:24:34.180000 In this particular case doesn't look like it's working. 0:24:34.180000 --> 0:24:37.760000 So we take a look at it here. 0:24:37.760000 --> 0:24:41.440000 I didn't give us the exact line at line one. 0:24:41.440000 --> 0:24:43.800000 So there's an issue with this here. 0:24:43.800000 --> 0:24:46.400000 So we may need to redo this again. 0:24:46.400000 --> 0:24:50.100000 So I'm just going to again replace this with our payload. 0:24:50.100000 --> 0:24:55.620000 And we can say, for example, in here, let's remove these two dashes and 0:24:55.620000 --> 0:24:58.420000 use the pound symbol that usually seems to work. 0:24:58.420000 --> 0:25:04.520000 We can take that in here and say, control you, for example, and Ford and 0:25:04.520000 --> 0:25:06.500000 doesn't display the version. 0:25:06.500000 --> 0:25:07.960000 So again, it's trial and error. 0:25:07.960000 --> 0:25:11.760000 If you want to go through it manually to find specific information. 0:25:11.760000 --> 0:25:13.280000 So this is all error based. 0:25:13.280000 --> 0:25:14.440000 We can try some of this. 0:25:14.440000 --> 0:25:17.820000 This actually looks similar to what we were doing or the payload that 0:25:17.820000 --> 0:25:19.080000 was generated here. 0:25:19.080000 --> 0:25:22.000000 So ID equals one. 0:25:22.000000 --> 0:25:28.160000 And we would need to say in this particular case, and in this particular 0:25:28.160000 --> 0:25:30.080000 case, we don't have a URL parameter. 0:25:30.080000 --> 0:25:33.140000 So we might be better using this one here. 0:25:33.140000 --> 0:25:35.760000 So let's try this particular payload. 0:25:35.760000 --> 0:25:40.620000 And we will resubmit and we'll then replace that particular parameter. 0:25:40.620000 --> 0:25:42.500000 And by the way, you can test the other parameters. 0:25:42.500000 --> 0:25:44.640000 It's entirely up to you. 0:25:44.640000 --> 0:25:47.980000 And we will, you are a line code this once. 0:25:47.980000 --> 0:25:49.840000 There we are for that. 0:25:49.840000 --> 0:25:52.160000 Let's take a look at the results here. 0:25:52.160000 --> 0:25:56.360000 So looks like we have an issue with the syntax. 0:25:56.360000 --> 0:26:01.220000 I'm going to resend that again and paste this in here. 0:26:01.220000 --> 0:26:02.820000 That looks fine. 0:26:02.820000 --> 0:26:05.680000 So what's exact, we can actually just put in a string there. 0:26:05.680000 --> 0:26:09.380000 So test, single quote and update XML. 0:26:09.380000 --> 0:26:15.400000 And then in here, sort of using the, we can just use a pound symbol there. 0:26:15.400000 --> 0:26:17.360000 And then URL and code this. 0:26:17.360000 --> 0:26:19.340000 So there we are. 0:26:19.340000 --> 0:26:21.940000 And we'll hit forward. 0:26:21.940000 --> 0:26:24.460000 And that still doesn't display any information. 0:26:24.460000 --> 0:26:28.820000 So it says, looks like we have a bit of a issue with our syntax. 0:26:28.820000 --> 0:26:30.740000 But yeah, trial and error. 0:26:30.740000 --> 0:26:34.740000 I just want to try a couple of them just to see which one is a better 0:26:34.740000 --> 0:26:36.580000 chance of working here. 0:26:36.580000 --> 0:26:41.580000 Let's see. We can also try and extract the data. 0:26:41.580000 --> 0:26:45.500000 But that's really not what we're interested at this point in time. 0:26:45.500000 --> 0:26:48.420000 You can go ahead and take a look at some of these payloads here. 0:26:48.420000 --> 0:26:54.580000 I'll now show you how we can utilize SQL map to dump data from the actual 0:26:54.580000 --> 0:27:00.480000 database. And this comes now into the exploitation phase of the vulnerability. 0:27:00.480000 --> 0:27:04.540000 So this is typically not what you would do in a bug bounty when you're 0:27:04.540000 --> 0:27:06.260000 doing bug bounty hunting. 0:27:06.260000 --> 0:27:08.820000 Because you're now, you know, extracting info. 0:27:08.820000 --> 0:27:12.140000 Although, as I said in the slides, you may be required to do this. 0:27:12.140000 --> 0:27:17.020000 If you have been asked to prove the severity of the vulnerability, so 0:27:17.020000 --> 0:27:19.260000 you know, proof of concept not being enough. 0:27:19.260000 --> 0:27:22.700000 So in this case, we'll just run the previous command here and we need 0:27:22.700000 --> 0:27:24.020000 to change a couple of things. 0:27:24.020000 --> 0:27:27.000000 So we're still using error based injection. 0:27:27.000000 --> 0:27:31.760000 What we can do now is list out the current database that is being used 0:27:31.760000 --> 0:27:34.520000 or that we have access to, right? 0:27:34.520000 --> 0:27:36.740000 And I'll hit enter. 0:27:36.740000 --> 0:27:42.320000 And yes, we want to follow the redirect and no, we do not want to resend 0:27:42.320000 --> 0:27:43.680000 the original post data. 0:27:43.680000 --> 0:27:47.500000 And it already has all sessions saved. 0:27:47.500000 --> 0:27:55.400000 In this particular case looks like it gives us the payload and not the 0:27:55.400000 --> 0:27:57.540000 current DB, which is very interesting. 0:27:57.540000 --> 0:28:03.020000 It should actually enumerate that current DB is that displayed here. 0:28:03.020000 --> 0:28:04.840000 Yes, it is. Sorry, my bad. 0:28:04.840000 --> 0:28:08.740000 So there we are fetching the current database, retrieve the database called 0:28:08.740000 --> 0:28:13.180000 recipe. So once you've identified the database, that's really good enough. 0:28:13.180000 --> 0:28:18.920000 What you can do now is say, okay, the database is called recipes. 0:28:18.920000 --> 0:28:20.920000 And I want you to. 0:28:20.920000 --> 0:28:26.480000 Hmm, let's see. I want you to display the tables. 0:28:26.480000 --> 0:28:31.680000 So in this case, we'll follow the redirect and no, just follow the same 0:28:31.680000 --> 0:28:35.980000 instruction is going to fetch the tables for this particular database. 0:28:35.980000 --> 0:28:37.700000 So in this case, there we are. 0:28:37.700000 --> 0:28:41.920000 We can see all the tables for that database and it lists it out here. 0:28:41.920000 --> 0:28:44.340000 So we have these tables within the database. 0:28:44.340000 --> 0:28:50.020000 So we have categories, ingredients, recipe, ingredients, recipes, sessions, 0:28:50.020000 --> 0:28:51.740000 units and the users. 0:28:51.740000 --> 0:28:56.580000 Fantastic. So what if we want to dump the data within the users table? 0:28:56.580000 --> 0:28:59.900000 Well, what we would do is we would specify the table. 0:28:59.900000 --> 0:29:03.620000 So database is recipes and then the table is called users. 0:29:03.620000 --> 0:29:05.920000 And then we can say dump. 0:29:05.920000 --> 0:29:10.020000 All right. So yes, follow the redirect. 0:29:10.020000 --> 0:29:12.840000 Do we want to re send the original post data? 0:29:12.840000 --> 0:29:18.240000 No, we do not. And now it's going to fetch the columns for the table users 0:29:18.240000 --> 0:29:19.600000 in the database recipes. 0:29:19.600000 --> 0:29:20.980000 And there we are. 0:29:20.980000 --> 0:29:24.380000 Looks like we're getting the actual columns here. 0:29:24.380000 --> 0:29:27.500000 And just going to give it a couple of seconds. 0:29:27.500000 --> 0:29:31.060000 Let's see how many user accounts we have. 0:29:31.060000 --> 0:29:33.960000 So we're now getting the records themselves. 0:29:33.960000 --> 0:29:35.320000 So these were the rows. 0:29:35.320000 --> 0:29:36.580000 Second rule, there we are. 0:29:36.580000 --> 0:29:42.140000 So we have ID, name, email, privileges, password and the username. 0:29:42.140000 --> 0:29:47.820000 So in this case, it looks like we've identified the admin account. 0:29:47.820000 --> 0:29:53.020000 So username is recipes and the password looks like it is encoded in base 0:29:53.020000 --> 0:30:00.220000 64. So if we go into cybershelf, which is a great online tool, we can 0:30:00.220000 --> 0:30:06.840000 use it to decode a lot of common encoding algorithms or hashes, if you 0:30:06.840000 --> 0:30:09.200000 will. I'll paste that in here. 0:30:09.200000 --> 0:30:10.960000 It doesn't look like it's base 64. 0:30:10.960000 --> 0:30:11.580000 That's interesting. 0:30:11.580000 --> 0:30:13.180000 That just might be the password. 0:30:13.180000 --> 0:30:17.800000 That's my bad. But, you know, we can try and log into the site now. 0:30:17.800000 --> 0:30:21.740000 So if we go back into the site and I've disabled the intercept feature, 0:30:21.740000 --> 0:30:25.200000 we know that the username is the password. 0:30:25.200000 --> 0:30:28.440000 And I'm just showing you the exploitation side of things. 0:30:28.440000 --> 0:30:30.900000 So paste in the password, log in. 0:30:30.900000 --> 0:30:33.460000 And it says the password is incorrect. 0:30:33.460000 --> 0:30:37.740000 So that might be in a hashed format, which means we need to obviously 0:30:37.740000 --> 0:30:39.360000 try and crack this. 0:30:39.360000 --> 0:30:45.480000 It could be in. We used something like hash identify hash identifier, 0:30:45.480000 --> 0:30:48.040000 put that in there. 0:30:48.040000 --> 0:30:51.480000 It tells us that sorry, let's paste that in here. 0:30:51.480000 --> 0:30:59.480000 So it's ds Unix, which means we would actually need the secret, which 0:30:59.480000 --> 0:31:01.440000 we don't have here. 0:31:01.440000 --> 0:31:07.300000 Because this is in ds format to decrypt ds, you need the actual encoded 0:31:07.300000 --> 0:31:14.740000 ds string as well as the actual secret. 0:31:14.740000 --> 0:31:19.360000 So this might not be this might not work that well. 0:31:19.360000 --> 0:31:22.960000 So if we go into cyber chef, you can see we can decrypt it. 0:31:22.960000 --> 0:31:25.700000 However, we need the secret key. 0:31:25.700000 --> 0:31:28.220000 And that would allow us to do it. 0:31:28.220000 --> 0:31:32.640000 So, you know, we would have essentially got the clear text password. 0:31:32.640000 --> 0:31:36.300000 And from that point on, we would have been able to log in now. 0:31:36.300000 --> 0:31:39.580000 There's additional functionality you can perform with SQL map. 0:31:39.580000 --> 0:31:43.960000 And that obviously will involve obtaining a system shell. 0:31:43.960000 --> 0:31:49.980000 So that's what you typically consider an out of band SQL injection attacks. 0:31:49.980000 --> 0:31:54.800000 So if I open up the help menu, you can see that you can utilize operating 0:31:54.800000 --> 0:31:58.640000 system access. So these options can be used to access the backend database 0:31:58.640000 --> 0:32:01.500000 management system underlying operating system. 0:32:01.500000 --> 0:32:05.740000 So the OS shell option will prompt for an interactive operating system 0:32:05.740000 --> 0:32:10.920000 shell. So in this particular case, what we would do is we would say, you 0:32:10.920000 --> 0:32:12.920000 know, just OS shell. 0:32:12.920000 --> 0:32:15.100000 In this case, let's see whether this would work. 0:32:15.100000 --> 0:32:20.120000 If we have the correct permissions, we should be able to get a shell. 0:32:20.120000 --> 0:32:22.880000 So we can try, for example, a PHP shell. 0:32:22.880000 --> 0:32:25.900000 Yeah, let's try that out. 0:32:25.900000 --> 0:32:28.260000 This might not work. 0:32:28.260000 --> 0:32:37.660000 We can go ahead and let's just perform a not sure. 0:32:37.660000 --> 0:32:39.600000 Let's just use option one. 0:32:39.600000 --> 0:32:40.820000 So access denied. 0:32:40.820000 --> 0:32:47.780000 So the user account we have access to will be will determine where or 0:32:47.780000 --> 0:32:53.600000 what directory we can upload the stage at two to obtain the shell. 0:32:53.600000 --> 0:33:01.380000 So in this case, you can see it's trying to upload to our www.html, etc. 0:33:01.380000 --> 0:33:04.860000 And I don't think with any with the user account, we currently have access 0:33:04.860000 --> 0:33:07.340000 to will be able to upload it to any. 0:33:07.340000 --> 0:33:11.500000 We may be able to do it in the temp directory, which might work. 0:33:11.500000 --> 0:33:14.840000 So that might provide us with some form of access. 0:33:14.840000 --> 0:33:17.060000 So there we are looks like all of these are failing. 0:33:17.060000 --> 0:33:19.740000 So I'm just going to wait for this to complete. 0:33:19.740000 --> 0:33:21.180000 So there we are. 0:33:21.180000 --> 0:33:22.760000 We can see that that didn't work. 0:33:22.760000 --> 0:33:26.360000 So we can try it again, just as a final demonstration. 0:33:26.360000 --> 0:33:31.380000 So no, and we can go for PHP. 0:33:31.380000 --> 0:33:35.800000 Yes. So full path disclosure. 0:33:35.800000 --> 0:33:40.460000 We can specify a custom location. 0:33:40.460000 --> 0:33:45.240000 So we can say TMP, for example, the temp directory looks like that is 0:33:45.240000 --> 0:33:50.420000 denied. And this might be because obviously if we go back here and we 0:33:50.420000 --> 0:33:54.700000 say SQL map help, we can try and execute an. 0:33:54.700000 --> 0:33:59.420000 You know, prompt for an O B shell, which should work, I think let's try 0:33:59.420000 --> 0:34:01.360000 it out. So OS pon. 0:34:01.360000 --> 0:34:03.260000 Let's try that out. 0:34:03.260000 --> 0:34:10.380000 Yes, and no. We'll go for the default and yes, to provoke the full path 0:34:10.380000 --> 0:34:13.240000 disclosure here and we'll use the default option there. 0:34:13.240000 --> 0:34:14.320000 So that's going to fail. 0:34:14.320000 --> 0:34:18.020000 Obviously, because it's going to try the same directories. 0:34:18.020000 --> 0:34:23.540000 What we can do. Is identify the current user. 0:34:23.540000 --> 0:34:27.840000 All right. So if we go back to the, some of the earlier commands we ran 0:34:27.840000 --> 0:34:33.400000 here, we can enumerate the current user to see what access we have with 0:34:33.400000 --> 0:34:36.200000 regards to the MySQL user account. 0:34:36.200000 --> 0:34:41.180000 So in this case, it looks like the current user is recipes at local host 0:34:41.180000 --> 0:34:47.360000 right now. Given that that is the case, we could obviously try some testing 0:34:47.360000 --> 0:34:48.960000 regarding where we can upload. 0:34:48.960000 --> 0:34:52.960000 The shell or the stage as it were. 0:34:52.960000 --> 0:34:55.720000 But that's something that we can explore as we proceed on. 0:34:55.720000 --> 0:35:00.060000 I just wanted to introduce you to SQL map and show you the crazy stuff 0:35:00.060000 --> 0:35:00.820000 that you can do. 0:35:00.820000 --> 0:35:04.880000 And of course, test all of this out, all of this functionality here. 0:35:04.880000 --> 0:35:09.280000 So for example, you can also enumerate the DBMS user password hashes. 0:35:09.280000 --> 0:35:12.460000 We've taken a look at retrieving the current user, current database. 0:35:12.460000 --> 0:35:16.240000 You can also retrieve everything, which will take quite a while, but there 0:35:16.240000 --> 0:35:20.840000 you go. So that is going to conclude the practical demonstration side 0:35:20.840000 --> 0:35:23.840000 of this video. All right. 0:35:23.840000 --> 0:35:29.900000 So that was how to identify and exploit error based SQL injection vulnerabilities 0:35:29.900000 --> 0:35:32.420000 in a real world web application. 0:35:32.420000 --> 0:35:37.060000 So that was quite a long demo, but it was essential just to show you how 0:35:37.060000 --> 0:35:39.240000 robust the testing process can be. 0:35:39.240000 --> 0:35:43.540000 The various options you can utilize, the tools you can utilize, what resources 0:35:43.540000 --> 0:35:46.300000 to leverage and of course, SQL map. 0:35:46.300000 --> 0:35:50.000000 This is the way I want to teach you how to use it using different use 0:35:50.000000 --> 0:35:51.900000 cases and scenarios. 0:35:51.900000 --> 0:35:56.860000 So hopefully that has given you enough of an idea as to what error based 0:35:56.860000 --> 0:36:00.800000 SQL injection looks like from an attacker's perspective. 0:36:00.800000 --> 0:36:06.020000 We're now going to turn our attention to union based SQL injection, which 0:36:06.020000 --> 0:36:07.980000 will be exploring in the next video. 0:36:07.980000 --> 0:36:11.760000 So with that being said, I'll be seeing you in the next video.