WEBVTT 00:00:01.040 --> 00:00:01.670 Hey, everyone. 00:00:02.240 --> 00:00:03.180 My name is Casey Dunham. 00:00:03.940 --> 00:00:07.000 Thank you for joining me on Pluralsight to learn how to use sqlmap to gain 00:00:07.000 --> 00:00:12.010 initial access by exploiting SQL injections. Many teams will find it 00:00:12.010 --> 00:00:15.450 useful to use sqlmap For red teams, it simplifies the process of 00:00:15.450 --> 00:00:18.220 identifying and exploiting SQL injection flaws. 00:00:19.040 --> 00:00:21.350 Blue teams and developers can use it to check that 00:00:21.350 --> 00:00:23.270 security controls are working as intended. 00:00:23.640 --> 00:00:27.230 This is also an ideal tool to use during the testing phase of 00:00:27.230 --> 00:00:29.070 a secure software development lifecycle. 00:00:29.640 --> 00:00:31.940 I want to take a moment to acknowledge and thank the creators of 00:00:31.940 --> 00:00:35.720 sqlmap. Bernardo Demele and Miroslav Stampar continue to do an 00:00:35.720 --> 00:00:37.450 incredible job developing sqlmap. 00:00:38.140 --> 00:00:41.360 It's been an often‑used part of my toolkit for a long time. From 00:00:41.360 --> 00:00:43.570 myself and the community, thank you for your work. 00:00:44.510 --> 00:00:48.070 Sqlmap's capabilities extend beyond only identifying SQL injections. 00:00:48.540 --> 00:00:50.940 It removes a lot of the manual and very often tedious 00:00:50.940 --> 00:00:52.650 work in exploiting these flaws. 00:00:53.140 --> 00:00:57.370 This is especially true when working with time‑based and blind SQL injections. 00:00:58.240 --> 00:01:02.170 You can use sqlmap to fingerprint the type and version of the database in use. 00:01:02.170 --> 00:01:04.860 You can enumerate the database schema and exfiltrate data. 00:01:05.760 --> 00:01:07.010 Under the right circumstances, 00:01:07.020 --> 00:01:10.250 you can even use it to gain an initial foothold into the system. 00:01:10.940 --> 00:01:13.370 You can find sqlmap releases and documentation on the 00:01:13.370 --> 00:01:16.250 sqlmap home page at sqlmap.org. 00:01:16.740 --> 00:01:20.810 The sqlmap source code is available on GitHub. Sqlmap will run on any 00:01:20.810 --> 00:01:24.270 platform that supports Python 2.6, 2.7, or Python 3. 00:01:25.040 --> 00:01:27.260 It is also preinstalled on Kali Linux. 00:01:28.240 --> 00:01:32.290 So where does sqlmap fit in on the kill chain? Since sqlmap is an active 00:01:32.290 --> 00:01:36.550 identification tool, it fits in at the exploitation phase. Any web 00:01:36.550 --> 00:01:39.130 application that you find during the reconnaissance phase may be 00:01:39.130 --> 00:01:42.750 vulnerable to SQL injection. You can use sqlmap to detect and exploit 00:01:42.750 --> 00:01:46.890 these flaws. In the MITRE ATT&CK framework, sqlmap is a tool that can 00:01:46.890 --> 00:01:48.790 provide you with your initial access. 00:01:49.240 --> 00:01:54.130 This places it under tactic T1190, Exploiting a Public Facing 00:01:54.130 --> 00:01:57.030 Application. Once you gain initial access, 00:01:57.220 --> 00:01:58.810 you'll need to turn to other tools. 00:01:59.100 --> 00:02:02.420 Sqlmap can help you with privilege escalation or pivoting 00:02:02.420 --> 00:02:04.060 further into the target environment. 00:02:04.640 --> 00:02:07.700 Let's take a moment to review what a typical attack scenario 00:02:07.700 --> 00:02:11.140 involving a SQL injection looks like. The following is a simple 00:02:11.140 --> 00:02:14.590 web application architecture. Both the application and database 00:02:14.590 --> 00:02:15.950 live on their own servers. 00:02:16.340 --> 00:02:20.150 A network firewall sits between the application server and the public internet. 00:02:20.840 --> 00:02:25.250 All network connections use HTTPS with modern and secure configurations. 00:02:25.940 --> 00:02:28.400 The database also uses at rest encryption. 00:02:29.040 --> 00:02:31.360 Consider the scenario where a normal user attempts to 00:02:31.360 --> 00:02:33.060 access the data of another user. 00:02:33.640 --> 00:02:35.830 The user authenticates to the application and 00:02:35.830 --> 00:02:37.750 attempts to view the other user's data. 00:02:38.440 --> 00:02:41.820 Now, the user's interaction with the application occurs in 00:02:41.820 --> 00:02:43.960 the context of their own user account. 00:02:44.540 --> 00:02:48.430 Logic within the application determines what the user can and cannot see. 00:02:48.800 --> 00:02:52.250 This is generally based on some form of role‑based access control. 00:02:53.140 --> 00:02:56.320 The application implements access control through constraints 00:02:56.330 --> 00:02:58.450 it adds to its queries to the database. 00:02:59.540 --> 00:03:01.720 The application queries the database using its own 00:03:01.720 --> 00:03:03.470 service account and credentials. 00:03:03.940 --> 00:03:06.830 This connection is most likely the same, regardless of who the 00:03:06.830 --> 00:03:10.570 application user is. Now, a SQL injection modifies the query that 00:03:10.570 --> 00:03:12.670 the application sends to the database. 00:03:13.040 --> 00:03:14.050 When this happens, 00:03:14.060 --> 00:03:16.380 the database has no way of knowing that it isn't what 00:03:16.380 --> 00:03:18.360 the application intended to ask for. 00:03:18.370 --> 00:03:21.290 All it sees is that the query is coming from the application. 00:03:21.490 --> 00:03:22.170 Likewise, 00:03:22.180 --> 00:03:24.010 the application has no way of knowing it's 00:03:24.010 --> 00:03:25.710 receiving more data than it should be. 00:03:26.040 --> 00:03:29.830 This means that if an attacker can exploit a SQL injection flaw, 00:03:29.950 --> 00:03:32.450 they could access any data available to the application. 00:03:32.940 --> 00:03:35.140 This is because they will often be able to bypass the 00:03:35.140 --> 00:03:37.080 application‑level access controls. 00:03:37.130 --> 00:03:39.550 It's also worth mentioning that stored procedures and views by 00:03:39.550 --> 00:03:42.450 themselves don't provide protections against SQL injections. 00:03:42.940 --> 00:03:45.730 A SQL injection may still exist in either of these if they 00:03:45.730 --> 00:03:47.940 aren't handling user controlled data properly. 00:03:48.060 --> 00:03:48.630 Likewise, 00:03:48.630 --> 00:03:51.080 the at rest encryption the database is using is also not a 00:03:51.080 --> 00:03:54.200 defense since the data needs to be unencrypted for the 00:03:54.200 --> 00:03:55.710 application to make use of it. 00:03:55.720 --> 00:03:57.730 One last thing to note is that this is all going to 00:03:57.730 --> 00:03:59.050 go unnoticed by the firewall. 00:03:59.940 --> 00:04:01.740 The network firewall operates at a level below the 00:04:01.740 --> 00:04:04.360 application. It has no way of knowing whether the user has 00:04:04.360 --> 00:04:06.360 legitimate access to the data or not. 00:04:07.240 --> 00:04:09.370 While a web application firewall can offer some 00:04:09.370 --> 00:04:12.670 protections against SQL injection exploitations, 00:04:13.040 --> 00:04:15.990 it isn't a replacement for fixing the vulnerable application code. 00:04:17.040 --> 00:04:20.670 Now, this is all a simplified view of real life. SQL injections 00:04:20.670 --> 00:04:22.540 are generally much more complex to exploit, 00:04:22.670 --> 00:04:24.570 but they're almost always exploitable.