WEBVTT 0:00:03.680000 --> 0:00:06.800000 Hello everyone and welcome to this video. 0:00:06.800000 --> 0:00:12.660000 In this video we're going to be taking a look at SQL map and sort of getting 0:00:12.660000 --> 0:00:21.780000 an understanding of what SQL map is, why it's used, obviously tied into 0:00:21.780000 --> 0:00:26.360000 that are the features that it offers, which is sort of one of the reasons 0:00:26.360000 --> 0:00:33.320000 why it's about pen testers or pen testers in general when it comes down 0:00:33.320000 --> 0:00:38.700000 to identifying and exploiting SQL injection vulnerabilities. 0:00:38.700000 --> 0:00:43.840000 But in addition to that, we're also going to be exploring again what I 0:00:43.840000 --> 0:00:45.340000 call the essential. 0:00:45.340000 --> 0:00:52.320000 So, if we use the Pareto principle, what that would mean is sort of the 0:00:52.320000 --> 0:00:58.760000 20% of the commands or options that you're likely to use 80% of the time. 0:00:58.760000 --> 0:01:04.240000 Now, we will be following up this particular video by taking a look at 0:01:04.240000 --> 0:01:07.340000 the advanced usage options. 0:01:07.340000 --> 0:01:10.120000 But that we know we're going to keep that separate. 0:01:10.120000 --> 0:01:14.920000 So to kick things off, what is SQL map? 0:01:14.920000 --> 0:01:20.860000 SQL map firstly is an open source tool that automates the process of detecting 0:01:20.860000 --> 0:01:26.100000 and exploiting SQL injection vulnerabilities in web applications. 0:01:26.100000 --> 0:01:30.300000 I'm going to go, I'm going to take a risk and say that if you're a pen 0:01:30.300000 --> 0:01:34.180000 tester or have been for any amount of time, you're probably most likely 0:01:34.180000 --> 0:01:40.760000 going to have heard of SQL map and you've probably already used it before. 0:01:40.760000 --> 0:01:48.300000 The objective for this section is we explore the usage of SQL map is going 0:01:48.300000 --> 0:01:54.660000 to go beyond the basics and what I really want is, by the time we're done 0:01:54.660000 --> 0:02:01.040000 using SQL map is for you to have a very, very good understanding of how 0:02:01.040000 --> 0:02:04.940000 it works and what exactly specific options do. 0:02:04.940000 --> 0:02:08.720000 But we're sort of getting ahead of ourselves now. 0:02:08.720000 --> 0:02:14.240000 So I've listed out a link to the official SQL map website as well as the 0:02:14.240000 --> 0:02:22.980000 GitHub project where you can not only get instructions and how to install 0:02:22.980000 --> 0:02:28.500000 it. It's obviously installed on most penetration testing distributions, 0:02:28.500000 --> 0:02:30.480000 namely Cali, Parrot, etc. 0:02:30.480000 --> 0:02:33.560000 So we're not going to be covering the installation. 0:02:33.560000 --> 0:02:46.260000 But more important that on the GitHub one of the best pieces of documentation 0:02:46.260000 --> 0:02:51.920000 that I've seen for again a pen testing tool apart from I would say Metasploit. 0:02:51.920000 --> 0:02:54.960000 So definitely check that out. 0:02:54.960000 --> 0:03:00.500000 So I've sort of listed out what it is and within the description you probably 0:03:00.500000 --> 0:03:03.760000 have a good idea of what it does. 0:03:03.760000 --> 0:03:09.420000 But what exactly is it used for or should I say why do pen testers use 0:03:09.420000 --> 0:03:12.960000 SQL map? Well, firstly is the automation. 0:03:12.960000 --> 0:03:17.640000 So it automates and more importantly simplifies the identification and 0:03:17.640000 --> 0:03:20.620000 exploitation of SQL injection vulnerabilities. 0:03:20.620000 --> 0:03:26.540000 Right. Secondly, it provides an efficient automated solution for extracting 0:03:26.540000 --> 0:03:31.900000 data from vulnerable applications or the backend databases. 0:03:31.900000 --> 0:03:33.620000 So what do I mean by that? 0:03:33.620000 --> 0:03:36.860000 Well, manual SQL injection is great. 0:03:36.860000 --> 0:03:42.340000 You know, you can pretty much verify that avonability exists. 0:03:42.340000 --> 0:03:48.660000 But what do you do when you need to ex-sultrate or extract data from the 0:03:48.660000 --> 0:03:55.140000 database? Not that I'm saying that you're going to be doing that illegally. 0:03:55.140000 --> 0:03:58.060000 How exactly would you accomplish that? 0:03:58.060000 --> 0:04:02.680000 Well, SQL map as you will see or as you know, you're probably already 0:04:02.680000 --> 0:04:11.240000 aware of makes this process scaringly easy and pretty much lowers the 0:04:11.240000 --> 0:04:17.300000 barrier for performing an SQL injection attack to the lowest. 0:04:17.300000 --> 0:04:21.500000 Pretty much anyone can run an SQL injection scan. 0:04:21.500000 --> 0:04:26.240000 And within a few, I would say one or two minutes be able again on a vulnerable 0:04:26.240000 --> 0:04:36.000000 website be able to extract data from and then thirdly, it supports fine 0:04:36.000000 --> 0:04:39.680000 grained and nuanced techniques or queries allowing penetration testers 0:04:39.680000 --> 0:04:44.580000 to perform in depth database assessments and ex-filtration of data. 0:04:44.580000 --> 0:04:46.660000 So they're all sort of linked together. 0:04:46.660000 --> 0:04:52.680000 The key thing is automation, secondly, speed, you know, speed of really 0:04:52.680000 --> 0:04:59.080000 everything, where you know, whether you're talking about testing for SQL 0:04:59.080000 --> 0:05:04.600000 injection vulnerabilities or trying to see if there are any, as well as 0:05:04.600000 --> 0:05:08.320000 then, you know, enumerating the information from the database and obviously 0:05:08.320000 --> 0:05:09.980000 then ex-filtration. 0:05:09.980000 --> 0:05:14.880000 The bottom line, if I can, you know, just make it as simple as possible, 0:05:14.880000 --> 0:05:22.580000 is that it's much faster to use SQL map to identify or to find identify 0:05:22.580000 --> 0:05:28.300000 exploit and then obviously leverage SQL injection vulnerabilities for, 0:05:28.300000 --> 0:05:33.520000 you know, database enumeration, ex-filtration of data, etc. 0:05:33.520000 --> 0:05:39.920000 Some other things that I want to sort of lay out in terms of SQL map are 0:05:39.920000 --> 0:05:44.400000 the supported DBMSs or databases, if you will. 0:05:44.400000 --> 0:05:49.800000 Firstly, you know, it has phenomenal support for relational databases 0:05:49.800000 --> 0:05:54.720000 and, you know, among the common culprits here, you have support for MySQL, 0:05:54.720000 --> 0:06:01.920000 PostgreSQL, Microsoft SQL Server, Oracle, SQLite, and of course MariaDB. 0:06:01.920000 --> 0:06:06.020000 You also have support, although it is quite experimental at this point 0:06:06.020000 --> 0:06:13.720000 in time for no SQL databases, namely or specifically MongoDB and CouchDB. 0:06:13.720000 --> 0:06:19.920000 Now, the key features, poignantly, when we're talking about SQL map are, 0:06:19.920000 --> 0:06:22.740000 you know, automatic detection of SQL injection types. 0:06:22.740000 --> 0:06:23.960000 That's very important. 0:06:23.960000 --> 0:06:29.120000 It's actually one of the main reasons people use it is because, you know, 0:06:29.120000 --> 0:06:33.000000 especially if you're following the approach of manually testing first 0:06:33.000000 --> 0:06:41.580000 and then using SQL map for verification of what you've found, it does 0:06:41.580000 --> 0:06:45.560000 that really well in that it actually tells you what type of SQL injection 0:06:45.560000 --> 0:06:50.780000 vulnerability you've found, whether it, you know, is error-based, time 0:06:50.780000 --> 0:06:53.520000 -based, Boolean-based, union-based, etc. 0:06:53.520000 --> 0:06:57.640000 And then also provides you with a sample payload or a payload that you 0:06:57.640000 --> 0:07:01.100000 can actually use yourself to verify it. 0:07:01.100000 --> 0:07:06.260000 Secondly, advanced fingerprinting to identify the target DBMS. 0:07:06.260000 --> 0:07:11.880000 So, you know, manual database identification of fingerprinting can be 0:07:11.880000 --> 0:07:16.680000 quite a tricky thing, although it's really not that difficult, but this, 0:07:16.680000 --> 0:07:22.460000 you know, solidly, conclusively verifies firstly, if you had a hunch that, 0:07:22.460000 --> 0:07:26.000000 you know, you're dealing with MySQL, it would tell you that it is indeed 0:07:26.000000 --> 0:07:32.100000 MySQL database, but more importantly, it also has the functionality, or 0:07:32.100000 --> 0:07:36.700000 has the ability to give you the exact version of the DBMS with, of course, 0:07:36.700000 --> 0:07:37.800000 a margin of error. 0:07:37.800000 --> 0:07:39.940000 It's not always exact. 0:07:39.940000 --> 0:07:43.080000 Thirdly, you know, the exploitation features. 0:07:43.080000 --> 0:07:46.680000 What I mean by that are, you know, data extraction, command execution 0:07:46.680000 --> 0:07:52.660000 by, you know, using the OS shell functionality, privilege escalation, 0:07:52.660000 --> 0:07:56.580000 and of course, a complete database takeover, which again can be very hard 0:07:56.580000 --> 0:08:01.080000 to perform manually, not impossible, but you get the idea. 0:08:01.080000 --> 0:08:05.240000 And obviously, you have excellent support or compatibility with get post 0:08:05.240000 --> 0:08:11.000000 and, you know, get, get, post, both get and post requests, as well as, 0:08:11.000000 --> 0:08:14.620000 you know, the HTTP headers for injection testing. 0:08:14.620000 --> 0:08:20.940000 And one thing that I would like to point out within this particular slide, 0:08:20.940000 --> 0:08:26.920000 as you can see here is I sort of want to reiterate the fact that it's 0:08:26.920000 --> 0:08:31.380000 always best to start off with manual testing or manual identification 0:08:31.380000 --> 0:08:36.060000 before using a tool as powerful as SQL map. 0:08:36.060000 --> 0:08:40.700000 So when performing a pen test, it is strongly recommended that you test 0:08:40.700000 --> 0:08:45.260000 your injections manually first, after which you can extend your testing 0:08:45.260000 --> 0:08:51.740000 with SQL map, whether using it for additional testing, and you're having 0:08:51.740000 --> 0:08:56.960000 a vulnerability manually, or you're verifying what you found manually, 0:08:56.960000 --> 0:09:02.400000 etc. So the underlying point is that if you go fully automatic in that 0:09:02.400000 --> 0:09:06.620000 you skip or don't perform any manual testing, you just get a URL with 0:09:06.620000 --> 0:09:15.320000 a parameter, and you just, you know, chuck it in SQL map and run. 0:09:15.320000 --> 0:09:22.400000 This is not ideal because SQL map, again, without specific options being 0:09:22.400000 --> 0:09:27.260000 specified that you can only have found manually, or by performing some 0:09:27.260000 --> 0:09:32.540000 preemptive manual testing, SQL map could choose to use a very inefficient 0:09:32.540000 --> 0:09:37.140000 exploitation strategy, or could even crash the remote service or database 0:09:37.140000 --> 0:09:39.740000 web application, etc. 0:09:39.740000 --> 0:09:44.520000 And this is something you see quite often, you want to be as careful as 0:09:44.520000 --> 0:09:49.960000 possible, or as cognizant of the, the target environment as possible in 0:09:49.960000 --> 0:09:51.540000 terms of stability, etc. 0:09:51.540000 --> 0:09:54.660000 And the reason for this is it should be obvious. 0:09:54.660000 --> 0:09:58.200000 Whenever you're testing databases or interacting with them, you must understand 0:09:58.200000 --> 0:10:08.180000 that databases are sort of the core of most web all data that the web 0:10:08.180000 --> 0:10:09.800000 application is using. 0:10:09.800000 --> 0:10:14.120000 And as a result, you want to be extremely careful, because you can actually 0:10:14.120000 --> 0:10:20.480000 destroy what, you know, in the view of many organizations is their most 0:10:20.480000 --> 0:10:23.860000 critical data. That's not to say that backups don't exist, obviously, 0:10:23.860000 --> 0:10:28.020000 but it's not a very good thing as a pen tester when you, you know, crash 0:10:28.020000 --> 0:10:29.960000 a database or you delete data. 0:10:29.960000 --> 0:10:41.620000 So the bottom line tool, and I've seen a lot of junior pen testers, you 0:10:41.620000 --> 0:10:45.660000 know, cause a lot of damage, or do things that they don't understand with 0:10:45.660000 --> 0:10:50.060000 SQL map that end up or result in damage being caused. 0:10:50.060000 --> 0:10:54.400000 So always start with identifying an SQL injection vulnerability manually 0:10:54.400000 --> 0:10:59.620000 first, then verify the presence and type of vulnerability with SQL map. 0:10:59.620000 --> 0:11:03.780000 SQL map pretty much will tell you more about the SQL injection vulnerability 0:11:03.780000 --> 0:11:08.180000 when you use this way, of course, it can also be used for exploitation 0:11:08.180000 --> 0:11:09.440000 of the vulnerability. 0:11:09.440000 --> 0:11:14.820000 But that again, is you, that's something that you rarely be required to 0:11:14.820000 --> 0:11:19.760000 do. You may want to extract some data as a, you know, as proof or evidence 0:11:19.760000 --> 0:11:24.400000 of the impact or potential impact of the SQL injection vulnerability. 0:11:24.400000 --> 0:11:31.740000 But generally speaking, my, from my experience, I've always gone in manually 0:11:31.740000 --> 0:11:37.980000 first. Once I'm sort of 50 to 80% sure that there's something there, or 0:11:37.980000 --> 0:11:40.120000 that I would like to investigate further. 0:11:40.120000 --> 0:11:43.980000 Now with the environment, with the situational awareness of the web application 0:11:43.980000 --> 0:11:46.220000 itself and how it works. 0:11:46.220000 --> 0:11:50.280000 And you know, exactly what parameter, for example, or input, I'm testing, 0:11:50.280000 --> 0:11:58.500000 I then utilize SQL map, but very guardedly or very very carefully. 0:11:58.500000 --> 0:12:01.040000 So I just wanted to point that out. 0:12:01.040000 --> 0:12:04.380000 So now that, you know, I've sort of given you that introduction, we can 0:12:04.380000 --> 0:12:06.840000 talk a little bit about how SQL map works. 0:12:06.840000 --> 0:12:09.060000 And this is very important. 0:12:09.060000 --> 0:12:14.920000 And when I say how it works, what I'm referring to is not only how to 0:12:14.920000 --> 0:12:27.160000 use it, we'll take a look at cases either after I've performed manual 0:12:27.160000 --> 0:12:32.640000 testing first, or in the second case, if I'm just using it to identify 0:12:32.640000 --> 0:12:34.740000 SQL injection vulnerability. 0:12:34.740000 --> 0:12:39.680000 So as I've already explained, SQL map automates the testing and exploitation 0:12:39.680000 --> 0:12:41.680000 of SQL injection vulnerabilities. 0:12:41.680000 --> 0:12:46.920000 And it does this by injecting payloads into input points, input points 0:12:46.920000 --> 0:12:53.720000 that, you know, you can specify or in some cases, you know, if you're 0:12:53.720000 --> 0:13:00.340000 using it without performing manual testing to firstly identify, I would 0:13:00.340000 --> 0:13:06.340000 say generally speaking, the input points themselves and then test them. 0:13:06.340000 --> 0:13:10.420000 And so, you know, analyzing responses and leveraging discovered vulnerabilities 0:13:10.420000 --> 0:13:17.580000 to extract or perform advanced to extract data, perform advanced exploitation. 0:13:17.580000 --> 0:13:24.520000 The bottom line is that, you know, it can be used in both contexts. 0:13:24.520000 --> 0:13:27.580000 And using this sample workflow. 0:13:27.580000 --> 0:13:30.020000 So again, let's start off right at the top. 0:13:30.020000 --> 0:13:32.600000 If you remember in the previous video, we're talking about the methodology 0:13:32.600000 --> 0:13:37.320000 with, you know, identifying the injection points. 0:13:37.320000 --> 0:13:42.380000 So SQL map scans the target URL or parameters to find where SQL injection 0:13:42.380000 --> 0:13:43.980000 might be possible. 0:13:43.980000 --> 0:13:48.180000 That's if you don't tell SQL map, you know, where it is. 0:13:48.180000 --> 0:13:54.120000 And what happens here is that with this example, you can see we'll get 0:13:54.120000 --> 0:13:57.180000 to the syntax. But you know, as you probably already know, you're on the 0:13:57.180000 --> 0:14:02.160000 SQL map command or the script, if you have not installed it, you specify 0:14:02.160000 --> 0:14:05.600000 the URL with the hyphen new option. 0:14:05.600000 --> 0:14:11.480000 And then the URL, as you can see right over here in double quotes, because 0:14:11.480000 --> 0:14:13.040000 of the delimiters. 0:14:13.040000 --> 0:14:18.700000 And what happens is that SQL map sends test payloads like in this particular 0:14:18.700000 --> 0:14:23.900000 case, one that would evaluate to true and will then analyze the response 0:14:23.900000 --> 0:14:27.360000 to detect potential SQL injection, right? 0:14:27.360000 --> 0:14:32.380000 Secondly, it does, you know, this is not something that it does automatically. 0:14:32.380000 --> 0:14:39.200000 But you know, if you were using SQL map prior to performing manual testing, 0:14:39.200000 --> 0:14:43.440000 you can use it to fingerprint to identify the database, right? 0:14:43.440000 --> 0:14:47.480000 So SQL map identifies this can also work in the second case, if you've 0:14:47.480000 --> 0:14:52.080000 already identified that a SQL injection vulnerability exists, you can 0:14:52.080000 --> 0:14:57.780000 specifically look or ask SQL map to identify the DBMS that's being used 0:14:57.780000 --> 0:15:03.200000 in order to tailor your attacks or to make your attacks more nuanced in, 0:15:03.200000 --> 0:15:10.380000 in support of or specifically tailored towards the DBMS that's running. 0:15:10.380000 --> 0:15:14.700000 So, you know, in this case, you can utilize the fingerprint option. 0:15:14.700000 --> 0:15:17.860000 So SQL map URL, and then the fingerprint option. 0:15:17.860000 --> 0:15:20.200000 And this is an example of what the output would look like. 0:15:20.200000 --> 0:15:25.500000 So the backend DBMS is my SQL version 5.7, right? 0:15:25.500000 --> 0:15:30.880000 You then would perform the injection or, you know, you can use it to perform 0:15:30.880000 --> 0:15:34.480000 the injection. So injecting the payloads to confirm the vulnerability. 0:15:34.480000 --> 0:15:38.020000 So SQL map tests for different types of SQL injection vulnerabilities, 0:15:38.020000 --> 0:15:44.660000 namely, or an example of those being error based, time based, Boolean 0:15:44.660000 --> 0:15:50.240000 based, etc. And some example payloads that are used by SQL map again, 0:15:50.240000 --> 0:15:51.880000 keep in word these examples. 0:15:51.880000 --> 0:15:54.800000 It's not entirely accurate. 0:15:54.800000 --> 0:15:58.400000 But in the case of Boolean based, you'd have in this case, you can see 0:15:58.400000 --> 0:16:06.540000 a delimiter with the single quote, and is one equals one, and that would 0:16:06.540000 --> 0:16:08.240000 be that would evaluate to true. 0:16:08.240000 --> 0:16:12.120000 So Boolean based, and then the second is union based, and then of course 0:16:12.120000 --> 0:16:16.380000 time based. So, you know, just using different payloads and different 0:16:16.380000 --> 0:16:24.040000 inputs, and then evaluating, analyzing the responses, right? 0:16:24.040000 --> 0:16:29.780000 And then of course, again, this will typically work either way, whether 0:16:29.780000 --> 0:16:43.480000 you're, you know, using typically used when you've identified that a vulnerability, 0:16:43.480000 --> 0:16:47.880000 an SQL injection vulnerability exists, you can now move on to data extraction 0:16:47.880000 --> 0:16:52.240000 or exaltration, where, you know, SQL map allows you to retrieve the information 0:16:52.240000 --> 0:16:56.880000 like the database schema tables and data, if the injection is confirmed 0:16:56.880000 --> 0:16:58.620000 or if a vulnerability is present. 0:16:58.620000 --> 0:17:02.440000 So in this case, what I'm doing here is I'm just listing out the databases 0:17:02.440000 --> 0:17:06.580000 or telling SQL map to list out the databases in order for this to work, 0:17:06.580000 --> 0:17:09.720000 there needs to be a SQL injection vulnerability. 0:17:09.720000 --> 0:17:12.620000 And, you know, it should be exploitable, right? 0:17:12.620000 --> 0:17:17.200000 So available databases, in this case, you can see this is just some sample 0:17:17.200000 --> 0:17:22.200000 output of what you're likely to come across the information schema, another 0:17:22.200000 --> 0:17:27.220000 one called another database called a user's DB, then within every database 0:17:27.220000 --> 0:17:31.500000 is going to be tables and within every table is going to be, you know, 0:17:31.500000 --> 0:17:34.760000 columns, etc. So you get the idea. 0:17:34.760000 --> 0:17:40.560000 Now there's also other options or functionality for, you know, revolving 0:17:40.560000 --> 0:17:44.840000 around advanced exploitation, where SQL map can also escalate attacks 0:17:44.840000 --> 0:17:48.040000 to gain OS level access. 0:17:48.040000 --> 0:17:55.120000 This is dependent on a couple of variables or essentially has a few requirements 0:17:55.120000 --> 0:17:56.900000 in order for this to work. 0:17:56.900000 --> 0:18:01.660000 We'll not touch on this at the moment, but for example, we can, you know, 0:18:01.660000 --> 0:18:07.200000 try and prompt or to get an operating system shell. 0:18:07.200000 --> 0:18:12.300000 If, you know, the vulnerability allows for command execution, in order 0:18:12.300000 --> 0:18:17.140000 to do that, you'd use the OS shell option. 0:18:17.140000 --> 0:18:22.700000 And yeah, so just an example or a workflow here just to give you an example 0:18:22.700000 --> 0:18:29.140000 of how it works, you know, going from identification to exploitation, 0:18:29.140000 --> 0:18:32.800000 enumeration of the database, exfiltration, etc, as well as some advanced 0:18:32.800000 --> 0:18:37.200000 options. So now we're going to turn our attention to some basic syntax. 0:18:37.200000 --> 0:18:42.620000 So I'm now going to explain the syntax to you and give you a couple of 0:18:42.620000 --> 0:18:44.000000 examples, right? 0:18:44.000000 --> 0:18:48.940000 So the basic structure of an SQL map command is obviously the SQL map 0:18:48.940000 --> 0:18:54.160000 command, the U option where you then specify the URL, you then have the 0:18:54.160000 --> 0:18:56.440000 P option. This is the injection parameter. 0:18:56.440000 --> 0:19:02.960000 You don't need to specify it always unless you ask you are you want SQL 0:19:02.960000 --> 0:19:08.680000 map to focus on a specific parameter that you want to inject the payloads 0:19:08.680000 --> 0:19:11.000000 into and then your options after that. 0:19:11.000000 --> 0:19:16.260000 So the U option here specifies the target URL. 0:19:16.260000 --> 0:19:22.000000 And then the options, this is where you modify or specify SQL maps behavior 0:19:22.000000 --> 0:19:25.920000 for specific testing or exploitation. 0:19:25.920000 --> 0:19:29.980000 The key thing or the key point I want to make here is that SQL map needs 0:19:29.980000 --> 0:19:33.680000 the URL, obviously, and the parameter. 0:19:33.680000 --> 0:19:39.320000 Now, if you don't specify the injection parameter, as you saw in the previous 0:19:39.320000 --> 0:19:45.820000 set of slides, SQL map will again automatically assume, for example, that 0:19:45.820000 --> 0:19:49.140000 it is ID using the example below, right? 0:19:49.140000 --> 0:19:51.620000 And that's what you want to inject. 0:19:51.620000 --> 0:19:57.140000 And again, there's different ways of tailoring SQL or telling SQL map 0:19:57.140000 --> 0:20:10.420000 to try and inject payloads into various types of parameters, whether they 0:20:10.420000 --> 0:20:14.240000 be in the URL, the cookie, etc. 0:20:14.240000 --> 0:20:15.940000 I'm getting a bit ahead of myself. 0:20:15.940000 --> 0:20:18.240000 We'll probably explore that in the advanced one. 0:20:18.240000 --> 0:20:22.960000 We take a look at the SQL maps advanced usage. 0:20:22.960000 --> 0:20:30.940000 But as I was saying here, SQL map can also operate fully in a fully automatic 0:20:30.940000 --> 0:20:36.340000 mode, where you don't provide any specific parameter to test. 0:20:36.340000 --> 0:20:39.300000 But that's generally speaking. 0:20:39.300000 --> 0:20:47.160000 This is typically the case when you are using SQL map prior to, let's 0:20:47.160000 --> 0:20:51.340000 say, manual testing, not always, but generally speaking, when you're not, 0:20:51.340000 --> 0:20:58.980000 you don't want to specify any specific parameter to inject. 0:20:58.980000 --> 0:21:01.080000 So that's what it will look like. 0:21:01.080000 --> 0:21:07.740000 A couple of other examples here are, for example, what, how would you 0:21:07.740000 --> 0:21:12.900000 specify, for example, HTTP methods and data? 0:21:12.900000 --> 0:21:16.720000 Well, in this case, or in this scenario, example scenario, let's say we're 0:21:16.720000 --> 0:21:20.640000 targeting a login form that sends post requests and includes form data 0:21:20.640000 --> 0:21:24.220000 in the body. So think of a login form, right? 0:21:24.220000 --> 0:21:30.640000 And you have a password set, you know, that's part of the body. 0:21:30.640000 --> 0:21:31.940000 How do you do that? 0:21:31.940000 --> 0:21:34.080000 Well, you know, you can specify the URL. 0:21:34.080000 --> 0:21:36.880000 So in this case, login.php. 0:21:36.880000 --> 0:21:43.040000 And then the data, which is going to be equal to the username and password 0:21:43.040000 --> 0:21:47.680000 parameters that are sent in the body in the form or format at the ascent. 0:21:47.680000 --> 0:21:51.200000 So for example, different web applications will have different names for 0:21:51.200000 --> 0:21:52.200000 the username parameters. 0:21:52.200000 --> 0:21:54.340000 So it just could be user. 0:21:54.340000 --> 0:22:00.920000 The bottom line is you need to specify exactly how it how it is sent in 0:22:00.920000 --> 0:22:03.400000 the, in the request. 0:22:03.400000 --> 0:22:07.160000 And in the next video, I'll actually show you that SQL map actually allows 0:22:07.160000 --> 0:22:11.640000 you to utilize an intercepted request, regardless whether it's get or 0:22:11.640000 --> 0:22:19.300000 post. And just use that as the basis for your SQL map scan, where you, 0:22:19.300000 --> 0:22:23.000000 you know, you can intercept a request with like burp and then save the 0:22:23.000000 --> 0:22:27.100000 request into a text file and then utilize the or tell SQL map to utilize 0:22:27.100000 --> 0:22:30.860000 the request. And then you can go ahead and specify, you know, whether 0:22:30.860000 --> 0:22:33.400000 you want specific payloads injected, etc. 0:22:33.400000 --> 0:22:37.160000 The bottom line is you do it by using the data option. 0:22:37.160000 --> 0:22:41.920000 And in this case, SQL map tests the post parameters, which in this case, 0:22:41.920000 --> 0:22:45.640000 I'll use name and password for injection vulnerabilities or to see whether 0:22:45.640000 --> 0:22:51.440000 they're vulnerable to any injections by, of course, testing different 0:22:51.440000 --> 0:22:59.560000 payloads. We now obviously have database enumeration more specifically, 0:22:59.560000 --> 0:23:02.680000 how would you extract the database banner? 0:23:02.680000 --> 0:23:06.740000 So the reason this is sort of important is because the very first step, 0:23:06.740000 --> 0:23:10.660000 one of the first steps in most SQL injection attacks involves grabbing 0:23:10.660000 --> 0:23:12.160000 the database banner. 0:23:12.160000 --> 0:23:15.900000 It's not always that important, but you know, you can you can do it with 0:23:15.900000 --> 0:23:22.060000 SQL map. This can be done by using the banner switch or option. 0:23:22.060000 --> 0:23:25.740000 And by using it, you can retrieve the database banner. 0:23:25.740000 --> 0:23:30.240000 This is extremely helpful both to test your injections and to have a proof 0:23:30.240000 --> 0:23:33.920000 of the exploitability or successful exploitation of the vulnerability 0:23:33.920000 --> 0:23:36.200000 for inclusion in your report. 0:23:36.200000 --> 0:23:40.840000 So specify, you know, and then the banner option. 0:23:40.840000 --> 0:23:44.600000 And then you can also utilize or combine it with other options. 0:23:44.600000 --> 0:23:46.600000 So you're not limited to just one option. 0:23:46.600000 --> 0:23:49.580000 Very similar to end map, you can combine options. 0:23:49.580000 --> 0:23:53.100000 This will become apparent when we actually go through some practical lab 0:23:53.100000 --> 0:23:56.900000 demos, not in this video, but as we proceed. 0:23:56.900000 --> 0:24:03.020000 If you wanted to enumerate the DBMS users, you can utilize the users option. 0:24:03.020000 --> 0:24:05.940000 If I wanted to detect this is very important. 0:24:05.940000 --> 0:24:10.920000 If you want to detect if the DBMS current user is the database admin, 0:24:10.920000 --> 0:24:14.240000 then you can utilize the is DBA option. 0:24:14.240000 --> 0:24:15.360000 What does this mean? 0:24:15.360000 --> 0:24:18.540000 Well, think of let's just take an example of WordPress, right? 0:24:18.540000 --> 0:24:22.920000 Let's say you install WordPress on a Linux server that's running the LAMP 0:24:22.920000 --> 0:24:28.020000 stack. So Linux Apache, MySQL, PHP. 0:24:28.020000 --> 0:24:33.240000 As you know, in order for you to install WordPress, you need to within 0:24:33.240000 --> 0:24:38.680000 the WordPress config file, specify the database user to authenticate with 0:24:38.680000 --> 0:24:46.600000 a MySQL database as or with in order for WordPress to create the necessary 0:24:46.600000 --> 0:24:57.800000 tables, etc. You can check through SQL map if that database user is actually 0:24:57.800000 --> 0:25:03.740000 admin. So does it have root privileges or admin privileges or not? 0:25:03.740000 --> 0:25:08.900000 And typically, it's not something that's good to see, but you typically 0:25:08.900000 --> 0:25:17.160000 see the root, the MySQL root user being used for during for these web 0:25:17.160000 --> 0:25:21.720000 applications. Because again, web applications need credentials to authenticate 0:25:21.720000 --> 0:25:24.280000 with a backend database. 0:25:24.280000 --> 0:25:32.020000 And if, if done, unsecuredly where you utilize, let's say, the database 0:25:32.020000 --> 0:25:36.120000 admin, and you compromise the web application through the SQL injection 0:25:36.120000 --> 0:25:39.860000 vulnerability operating under the context of the web application, which 0:25:39.860000 --> 0:25:44.820000 means your injection or your commands are being sent as the database user 0:25:44.820000 --> 0:25:49.120000 being used by the web application to authenticate with a backend DBS. 0:25:49.120000 --> 0:25:55.620000 What I'm saying is, is if WordPress used, let's say, a database user on 0:25:55.620000 --> 0:26:02.860000 the MySQL database called Alexis, you with SQL map performing your injections 0:26:02.860000 --> 0:26:08.840000 will be running those, those queries under the same context as the user 0:26:08.840000 --> 0:26:13.100000 Alexis. What I'm referring to here is that you can actually use SQL map 0:26:13.100000 --> 0:26:17.300000 to determine if the user Alexis actually database admin. 0:26:17.300000 --> 0:26:19.900000 Hopefully that makes sense. 0:26:19.900000 --> 0:26:23.320000 You can then obviously list the databases. 0:26:23.320000 --> 0:26:27.160000 So you can see that we actually used or saw this example previously, but 0:26:27.160000 --> 0:26:30.680000 the output will just list out the databases, which you can then extract 0:26:30.680000 --> 0:26:33.960000 more information from like listing the tables in a database. 0:26:33.960000 --> 0:26:39.260000 So let's say we had a database called users DB, we can then specify using 0:26:39.260000 --> 0:26:44.060000 the D option hyphen uppercase D, the name of the database that obviously 0:26:44.060000 --> 0:26:47.600000 has to exist. And then we use the tables flag or option. 0:26:47.600000 --> 0:26:50.960000 And that will now list, as you can see in the sample output here, the 0:26:50.960000 --> 0:26:56.760000 tables in the users database or users DB database. 0:26:56.760000 --> 0:27:00.880000 So you know, the the tables we can see over here are user credentials, 0:27:00.880000 --> 0:27:07.420000 user profiles. And then you can say select all from user credentials as 0:27:07.420000 --> 0:27:14.600000 an example, or select user credentials from that will be the the standard 0:27:14.600000 --> 0:27:21.320000 SQL query. And that's essentially what SQL map does when we're talking 0:27:21.320000 --> 0:27:27.680000 about enumerating information from a database of obviously after successful 0:27:27.680000 --> 0:27:33.080000 identification and verification that an SQL injection vulnerability exists. 0:27:33.080000 --> 0:27:44.700000 And then you can also push that a little in this case, you have, you know, 0:27:44.700000 --> 0:27:49.860000 specify the URL, the database, and then the tables or the table names, 0:27:49.860000 --> 0:27:55.100000 you can specify more than one table, obviously through a comma separated 0:27:55.100000 --> 0:28:00.360000 list and then columns to also list out the columns in each table. 0:28:00.360000 --> 0:28:06.700000 So you this can be further expounded on by dumping, which I'll get to 0:28:06.700000 --> 0:28:07.580000 in the next slide. 0:28:07.580000 --> 0:28:10.820000 But just want to highlight that here. 0:28:10.820000 --> 0:28:16.500000 So if you want to dump the contents of the table, you could do that by 0:28:16.500000 --> 0:28:19.980000 using the the dump option. 0:28:19.980000 --> 0:28:25.220000 So in this case, SQL map, the URL, the database is users DB, the table 0:28:25.220000 --> 0:28:28.760000 is users user credentials. 0:28:28.760000 --> 0:28:29.800000 And then we say dump. 0:28:29.800000 --> 0:28:33.780000 And this is an example, hopefully, of what we'll find. 0:28:33.780000 --> 0:28:38.320000 So we have the username column and the password column. 0:28:38.320000 --> 0:28:47.300000 And we have two rows, we have row with the ID zero, or one, however, it's 0:28:47.300000 --> 0:28:50.660000 configured is admin and the passwords are stored in clear text. 0:28:50.660000 --> 0:28:55.620000 No, you're always going to come across hash passwords, hopefully not MD 0:28:55.620000 --> 0:29:00.800000 five hash passwords, like some of the older websites or web applications 0:29:00.800000 --> 0:29:06.820000 out there. But they would typically be hashed unless something's gone 0:29:06.820000 --> 0:29:11.500000 terribly wrong. And they've decided to store passwords in clear text. 0:29:11.500000 --> 0:29:15.460000 But this is what it'll look like, right? 0:29:15.460000 --> 0:29:22.600000 Some other examples I can give you are this is no, not this is not related 0:29:22.600000 --> 0:29:27.800000 to database enumeration, or, you know, extracting database data from the 0:29:27.800000 --> 0:29:33.620000 database, but more so specifying, you know, custom authentication methods. 0:29:33.620000 --> 0:29:38.540000 So in this case, the example scenario is testing applications that this 0:29:38.540000 --> 0:29:43.040000 is very important testing applications that require authentication. 0:29:43.040000 --> 0:29:44.660000 So login credentials or headers. 0:29:44.660000 --> 0:29:49.860000 Now, if you're thinking correctly, and I'm assuming you are, you may be 0:29:49.860000 --> 0:29:55.160000 saying, well, Alexis, if we can use an intercept, an intercepted, but 0:29:55.160000 --> 0:29:59.560000 an intercepted request with burp, then we don't really need to do this. 0:29:59.560000 --> 0:30:02.540000 But again, that is true. 0:30:02.540000 --> 0:30:07.980000 But maybe you just want to, again, utilize, you know, you may just want 0:30:07.980000 --> 0:30:13.920000 to specify, or avoid using an intercepted request and just specify the 0:30:13.920000 --> 0:30:20.460000 authentication, the authentication method you want to use, you want to 0:30:20.460000 --> 0:30:23.540000 use, or used by the web application. 0:30:23.540000 --> 0:30:28.260000 A good example of this with me is just specifying the authenticated cookie. 0:30:28.260000 --> 0:30:32.140000 In this case, I'm just using this, you know, standard PHP one so PHP session 0:30:32.140000 --> 0:30:33.280000 ID is equal to whatever. 0:30:33.280000 --> 0:30:37.840000 In this case, the cookie represents, or essentially is not only useful 0:30:37.840000 --> 0:30:47.840000 session management, but, you know, also proves, also used to specify an 0:30:47.840000 --> 0:30:51.800000 authenticated session or represents an authenticated session. 0:30:51.800000 --> 0:30:57.300000 So what happens is that SQL map uses the session cookie to authenticate 0:30:57.300000 --> 0:30:58.760000 and proceed with testing. 0:30:58.760000 --> 0:31:00.580000 That's actually quite important. 0:31:00.580000 --> 0:31:05.820000 So I've sort of listed out a summary of the common options. 0:31:05.820000 --> 0:31:12.620000 Obviously, you have the U option, which can also be double hyphen URL. 0:31:12.620000 --> 0:31:16.060000 That allows you to specify the target URL, you then have the data option 0:31:16.060000 --> 0:31:22.440000 where you, this way you specify the test, the post parameters with the 0:31:22.440000 --> 0:31:25.240000 specified data, then you have the P option. 0:31:25.240000 --> 0:31:28.860000 That's the parameter to test if you want to be specific. 0:31:28.860000 --> 0:31:33.940000 So, you know, you may explicitly want to say I want you to test the parameter 0:31:33.940000 --> 0:31:40.740000 ID. And this is very important because then SQL map will know, hey, you 0:31:40.740000 --> 0:31:43.960000 don't want to test anything else, just this one. 0:31:43.960000 --> 0:31:48.720000 You have the fingerprint option, which identifies the DBMS type inversion. 0:31:48.720000 --> 0:31:52.740000 I'll not get into the rest in detail right now, but we have the tamper 0:31:52.740000 --> 0:31:57.240000 option, which allows you to temp to apply tamper scripts to evade wafts 0:31:57.240000 --> 0:32:03.580000 or filters. We'll be exploring this in the filter filter vision bypass 0:32:03.580000 --> 0:32:09.640000 course in depth, especially when we're talking about SQL injection, I 0:32:09.640000 --> 0:32:15.280000 mentioned OS shell, this spawns an OS shell on the target, if exploitable. 0:32:15.280000 --> 0:32:19.580000 Then we also have the file read, which I didn't sort of explain, but what 0:32:19.580000 --> 0:32:22.900000 it does allows you to read sort of an advanced exploitation technique, 0:32:22.900000 --> 0:32:28.720000 sort of unique to SQL map, it essentially allows you to read files from 0:32:28.720000 --> 0:32:29.640000 the target server. 0:32:29.640000 --> 0:32:33.940000 And then you have batch, the batch option allows you to run non interactively 0:32:33.940000 --> 0:32:36.200000 without prompts. 0:32:36.200000 --> 0:32:43.180000 So, if you've used SQL map before, you know that, at specific breakpoints, 0:32:43.180000 --> 0:32:48.340000 when SQL map needs user input, it would essentially stop and ask you whether 0:32:48.340000 --> 0:32:49.680000 you want to do something. 0:32:49.680000 --> 0:32:55.580000 So, do you want to use the cookie or include the cookie that we've received 0:32:55.580000 --> 0:32:58.200000 in every consequent request? 0:32:58.200000 --> 0:33:01.080000 Yes or no, the default being no, for example. 0:33:01.080000 --> 0:33:04.320000 Well, using the batch option, you can actually say whether you prefer 0:33:04.320000 --> 0:33:09.580000 yes or no, do those breakpoints or prompts, if you will. 0:33:09.580000 --> 0:33:15.220000 And you can then let it run non interactively without you having to, you 0:33:15.220000 --> 0:33:19.520000 know, intercede or interject at these points. 0:33:19.520000 --> 0:33:24.520000 And I've also listed a summary of the DBA enumeration options. 0:33:24.520000 --> 0:33:28.960000 So, the A option allows you to retrieve everything, be very cautious with 0:33:28.960000 --> 0:33:32.820000 this, because depending on how much data is in the database, it's going 0:33:32.820000 --> 0:33:34.820000 to take a while. 0:33:34.820000 --> 0:33:37.840000 The B option, this is for the banner. 0:33:37.840000 --> 0:33:42.900000 You have the DBS that enumerates available databases within the DPMs. 0:33:42.900000 --> 0:33:48.300000 I'm not talking about when I, when SQL map is referencing databases, it's 0:33:48.300000 --> 0:33:52.140000 not referring to the actual database database. 0:33:52.140000 --> 0:33:57.500000 So, not MySQL, it's referring to the database stored within the DPMs. 0:33:57.500000 --> 0:34:01.140000 And apologies, let me just go back here. 0:34:01.140000 --> 0:34:03.120000 You then have the tables option. 0:34:03.120000 --> 0:34:06.700000 So, this lists the tables in a specified database. 0:34:06.700000 --> 0:34:11.560000 It needs tables can only be used when you've, when you've specified using 0:34:11.560000 --> 0:34:17.020000 the D option, what database you want to list the tables from, and then 0:34:17.020000 --> 0:34:25.460000 columns enumerate DBS, database table columns, schema enumerates the DBS, 0:34:25.460000 --> 0:34:31.080000 the DBMS schema dump is used to extract data from a table dump all again, 0:34:31.080000 --> 0:34:34.260000 very, very dangerous, because it, you know, depending on the amount of 0:34:34.260000 --> 0:34:39.200000 data in the database, can take a while can be, I can also be quite resource 0:34:39.200000 --> 0:34:46.260000 intensive, both on your end, as well as the, from the end of the database. 0:34:46.260000 --> 0:34:51.480000 Then, of course, is DBA, which I explained a few minutes ago, which essentially 0:34:51.480000 --> 0:34:57.100000 a detective, the current DBMS user is the database admin. 0:34:57.100000 --> 0:35:02.700000 And then I've sort of outlined at the bottom there, the short form, or 0:35:02.700000 --> 0:35:15.000000 abbreviated database, the table, which can just be hyphen T, or you can 0:35:15.000000 --> 0:35:17.320000 use the double hyphen tables. 0:35:17.320000 --> 0:35:22.780000 And then columns can be hyphen up a case C instead of double hyphen columns, 0:35:22.780000 --> 0:35:24.860000 it's entirely up to your preference. 0:35:24.860000 --> 0:35:28.460000 But the key point is I just want you to know that these are separate options 0:35:28.460000 --> 0:35:33.200000 in this sort of representations in the case of T and C of just tables 0:35:33.200000 --> 0:35:43.140000 and columns D is really the one you want to enumerate information from. 0:35:43.140000 --> 0:35:46.680000 All right. So with that being said, that brings us to the end of this 0:35:46.680000 --> 0:35:50.440000 video. Hopefully, that's given you an understanding, I wouldn't say a 0:35:50.440000 --> 0:35:54.680000 deep understanding, but a general overview of exactly how it works, you 0:35:54.680000 --> 0:35:59.200000 know, what SQL map is, how it works, how you can use it or why pen testers 0:35:59.200000 --> 0:36:05.840000 use it. And through those, the those syntax examples, or examples full 0:36:05.840000 --> 0:36:10.820000 stop, you probably have an idea of when to use it, or what option to use 0:36:10.820000 --> 0:36:17.340000 when. And we're going to be expounding or adding on to this by exploring 0:36:17.340000 --> 0:36:24.840000 in the next video, some, you know, the advanced SQL map usage. 0:36:24.840000 --> 0:36:27.960000 And in that video, we're going to be using a lab environment. 0:36:27.960000 --> 0:36:32.340000 So we'll be sort of putting everything together or combining everything 0:36:32.340000 --> 0:36:35.480000 we've learned, not just in this video, but in the next video in that lab 0:36:35.480000 --> 0:36:39.080000 environment where you'll actually get to test it for yourself, again, 0:36:39.080000 --> 0:36:41.220000 against a real world web application. 0:36:41.220000 --> 0:36:44.200000 So that brings us to the end of this video. 0:36:44.200000 --> 0:36:46.720000 And I'll be seeing you in the next video.