WEBVTT 00:00:00.540 --> 00:00:03.870 In this course, we'll cover much of sqlmap's basic functionality. 00:00:04.240 --> 00:00:05.300 We won't cover everything, 00:00:05.310 --> 00:00:08.250 but you'll have what you need to start using sqlmap in your assessments. 00:00:08.260 --> 00:00:10.960 We'll start by learning the usage of the sqlmap command line. 00:00:11.540 --> 00:00:14.970 We'll do this by exploiting a known flaw in a vulnerable application. 00:00:15.940 --> 00:00:18.130 Sqlmap has the ability to crawl applications to 00:00:18.130 --> 00:00:19.960 identify more endpoints for testing. 00:00:20.340 --> 00:00:24.000 We'll use this functionality to find other areas to test for SQL injections. 00:00:24.190 --> 00:00:27.040 The most powerful feature in sqlmap is its enumeration 00:00:27.040 --> 00:00:30.340 capabilities. Using these capabilities, we'll identify the 00:00:30.340 --> 00:00:32.630 database schema and exfiltrate data. 00:00:32.860 --> 00:00:36.450 Sqlmap uses two variables to determine the types of test it uses. 00:00:36.760 --> 00:00:40.190 These are level and risk. We'll cover how these change the way sqlmap 00:00:40.190 --> 00:00:45.090 performs its testing. To finish our coverage, we'll use sqlmap to gain an 00:00:45.090 --> 00:00:48.750 initial foothold into the server. We'll keep it straightforward and use 00:00:48.750 --> 00:00:50.850 sqlmap's built‑in web shell functionality. 00:00:51.240 --> 00:00:54.060 I want to emphasize that sqlmap is an active attack tool. 00:00:54.940 --> 00:00:57.460 This tool will be sending quite a bit of requests to the target. 00:00:58.140 --> 00:01:00.680 It's illegal to run sqlmap against an application that you don't 00:01:00.680 --> 00:01:04.080 own or have permission to test. Throughout this course, we'll use 00:01:04.080 --> 00:01:07.870 the Damn Vulnerable Web Application, otherwise known as DVWA. 00:01:08.440 --> 00:01:12.850 This is an open source application built to contain common web vulnerabilities. 00:01:13.640 --> 00:01:17.150 You can download it at dvwa.co.uk. 00:01:18.340 --> 00:01:20.590 I'm running the application in a virtual machine locally, 00:01:20.600 --> 00:01:22.090 and I recommend that you do as well. 00:01:22.100 --> 00:01:25.290 We won't go through the setting up and configuring DVWA, but I want 00:01:25.290 --> 00:01:27.070 to draw your attention to a couple of things. 00:01:28.340 --> 00:01:31.460 The default login credentials for DVWA is admin for the 00:01:31.460 --> 00:01:33.050 username and password for the password. 00:01:33.940 --> 00:01:35.820 If we navigate over to the Setup page, 00:01:35.830 --> 00:01:38.770 it shows a list of checks that the application performs on startup. 00:01:38.780 --> 00:01:41.160 These configuration checks offer protections that can 00:01:41.160 --> 00:01:42.670 prevent our exploits from working. 00:01:43.140 --> 00:01:45.660 Make sure that these are all in a good state before continuing. 00:01:46.240 --> 00:01:48.330 Now let's head over to the Security page. 00:01:48.520 --> 00:01:51.430 DVWA has a concept of a security level. 00:01:51.990 --> 00:01:54.910 The security level controls how easy or difficult it is to 00:01:54.910 --> 00:01:58.340 exploit the vulnerabilities in the application. By default, 00:01:58.340 --> 00:02:03.350 this is set to impossible, which, well, makes exploitation impossible. 00:02:04.040 --> 00:02:06.620 This level represents good coding practices to prevent the 00:02:06.620 --> 00:02:09.720 vulnerabilities from occurring. For this course, we'll set 00:02:09.720 --> 00:02:10.759 the security level to Low. 00:02:11.240 --> 00:02:13.140 I encourage you to use what you learn here to 00:02:13.140 --> 00:02:15.050 experiment with higher security levels. 00:02:16.340 --> 00:02:19.300 Let's start by exploiting a very basic SQL injection flaw in 00:02:19.300 --> 00:02:21.860 a known location. Over here on the left, 00:02:22.240 --> 00:02:24.040 we'll use the first SQL Injection link. 00:02:24.290 --> 00:02:28.810 This page consists of a simple input field expecting a user ID. If we enter a 00:02:28.810 --> 00:02:32.890 couple of values, we'll see that it returns some user information. We can 00:02:32.890 --> 00:02:36.240 test that this is vulnerable by using a single apostrophe to break the syntax 00:02:36.240 --> 00:02:40.250 of the SQL query. And, as we expected, this caused a database error. 00:02:40.840 --> 00:02:42.850 Now let's turn to sqlmap to exploit this further.