WEBVTT

0:00:03.580000 --> 0:00:06.460000
 Hello everyone and welcome.

0:00:06.460000 --> 0:00:11.420000
 In this video we are going to be exploring
 or getting an understanding

0:00:11.420000 --> 0:00:19.320000
 of OOB or out of band sequel injection
 and the objectives are going to

0:00:19.320000 --> 0:00:24.440000
 be twofold. There's obviously going
 to be the theoretical section where

0:00:24.440000 --> 0:00:29.900000
 I'll sort of explain out of band sequel
 injection attacks or vulnerabilities

0:00:29.900000 --> 0:00:35.120000
 and you know how they work when they
 usually come into play and the second

0:00:35.120000 --> 0:00:40.380000
 part is going to involve a short
 demo not in the form of a lab.

0:00:40.380000 --> 0:00:44.120000
 Again, given the constraints that you'll
 see, I sort of had to set up

0:00:44.120000 --> 0:00:48.520000
 a quick POC or demo to actually
 show you how it works.

0:00:48.520000 --> 0:00:52.720000
 But I think you'll actually by the end
 of this video as a whole get the

0:00:52.720000 --> 0:00:57.860000
 gist of what OOB sequel injection vulnerabilities
 are like or what the

0:00:57.860000 --> 0:00:58.900000
 attack looks like.

0:00:58.900000 --> 0:01:03.040000
 So to kick things off, I think we obviously
 need to answer the question

0:01:03.040000 --> 0:01:06.040000
 what is out of band sequel injection?

0:01:06.040000 --> 0:01:10.160000
 Well, out of band sequel injection is
 a type of sequel injection attack

0:01:10.160000 --> 0:01:14.740000
 where the attacker does not rely and
 this is very important on direct

0:01:14.740000 --> 0:01:18.280000
 meaning in-band feedback
 from the application.

0:01:18.280000 --> 0:01:22.320000
 Instead, the attacker triggers the database
 to communicate with an external

0:01:22.320000 --> 0:01:27.680000
 server that the attacker controls using
 channels or communication channels

0:01:27.680000 --> 0:01:34.280000
 like DNS or HTTP in order to exaltrate
 data or to confirm the vulnerability

0:01:34.280000 --> 0:01:38.680000
 and then this in the practical section
 will be more so just confirming

0:01:38.680000 --> 0:01:42.000000
 the vulnerability or giving you ideas
 to what it would look like in the

0:01:42.000000 --> 0:01:48.960000
 real world. So that begs the question
 when is OOB or out of band sequel

0:01:48.960000 --> 0:01:52.420000
 injection? When is it useful or
 when does it come into play?

0:01:52.420000 --> 0:01:57.160000
 Well, it usually comes into play when
 A, the application does not display

0:01:57.160000 --> 0:02:02.260000
 error messages. So think of blind
 sequel injection there.

0:02:02.260000 --> 0:02:05.560000
 B, the application responses
 are not observable.

0:02:05.560000 --> 0:02:10.260000
 So time-based sequel injection does not
 work or does not seem to be working

0:02:10.260000 --> 0:02:18.220000
 and C, in order for this to work, the
 target database can send outbound

0:02:18.220000 --> 0:02:21.980000
 requests to a remote server
 or domain for that matter.

0:02:21.980000 --> 0:02:28.620000
 So these are sort of the, this is when
 out of band sequel injection comes

0:02:28.620000 --> 0:02:34.880000
 into play, but more so this is also giving
 you ideas to what are the environmental

0:02:34.880000 --> 0:02:41.740000
 requirements in terms of your testing
 and what is actually required.

0:02:41.740000 --> 0:02:48.000000
 For example, the fact that the DBMS
 or RDBMS needs to be able to send

0:02:48.000000 --> 0:02:53.760000
 outbound requests being one of these
 requirements that needs to actually

0:02:53.760000 --> 0:03:00.080000
 exist otherwise you will not be able
 to verify it that way either.

0:03:00.080000 --> 0:03:09.440000
 So diving a little bit deeper into how
 out of band sequel injection works,

0:03:09.440000 --> 0:03:13.180000
 I'm sort of going to use an attack
 flow that will best sort of explain

0:03:13.180000 --> 0:03:18.620000
 it. So we start off as with any other
 injection vulnerability by identifying

0:03:18.620000 --> 0:03:20.840000
 a vulnerable input point.

0:03:20.840000 --> 0:03:24.520000
 So the attacker finds an input that
 interacts with the database.

0:03:24.520000 --> 0:03:30.020000
 So a query parameter or form field,
 you know, second step is crafting

0:03:30.020000 --> 0:03:31.200000
 a malicious payload.

0:03:31.200000 --> 0:03:35.380000
 So the attacker injects a payload designed
 to force the database to make

0:03:35.380000 --> 0:03:38.140000
 an external DNS or HTTP request.

0:03:38.140000 --> 0:03:43.920000
 All right. And then, you know, we as the
 attacker set up an external server,

0:03:43.920000 --> 0:03:48.000000
 you know, to monitor and capture the
 outbound requests are really not

0:03:48.000000 --> 0:03:52.300000
 really for exfiltration in this case,
 but more so confirming that, yes,

0:03:52.300000 --> 0:03:59.900000
 the database is actually, you know, calling
 back to our server, therefore

0:03:59.900000 --> 0:04:03.880000
 verifying the existence of the
 sequel injection vulnerability.

0:04:03.880000 --> 0:04:06.140000
 So that brings us to triggering
 the call back.

0:04:06.140000 --> 0:04:09.960000
 So in the database processes, the payload,
 it sends a request to the attacker

0:04:09.960000 --> 0:04:15.220000
 controlled server, exfiltrating data
 or confirming the presence of the

0:04:15.220000 --> 0:04:21.140000
 vulnerability. And that's, you know,
 that brings us to the next logical

0:04:21.140000 --> 0:04:25.640000
 point, which is what types of out of
 bound sequel injection attacks or

0:04:25.640000 --> 0:04:28.780000
 vulnerabilities, but more
 so attacks exist.

0:04:28.780000 --> 0:04:33.080000
 Well, there's HTTP and DNS based, at
 least those are the ones that I'm

0:04:33.080000 --> 0:04:37.480000
 outlining here because of, again, their
 prevalence or popularity, if you

0:04:37.480000 --> 0:04:42.640000
 will. So in the case of HTTP based out
 of band sequel injection, the database

0:04:42.640000 --> 0:04:47.500000
 is forced to send an HTTP request
 to an attacker controlled server.

0:04:47.500000 --> 0:04:52.800000
 And this is typically facilitated through
 the following database functions,

0:04:52.800000 --> 0:04:55.220000
 if you will, or queries.

0:04:55.220000 --> 0:04:58.880000
 In the case of Microsoft SQL Server, as
 some of you know, if your experience

0:04:58.880000 --> 0:05:01.600000
 spend test is going to
 be XP command shell.

0:05:01.600000 --> 0:05:07.020000
 In the case of PostgreSQL, it's going
 to be copy my sequel is load file,

0:05:07.020000 --> 0:05:11.980000
 right? And then in the, the other type
 is DNS based out of band sequel

0:05:11.980000 --> 0:05:15.080000
 injection. So in this case, the database
 is forced to resolve a domain

0:05:15.080000 --> 0:05:20.260000
 name, essentially sending a DNS query
 to an attacker controlled DNS server.

0:05:20.260000 --> 0:05:28.920000
 So in the case of, you know, the, the,
 uh, the query is the DBMS specific

0:05:28.920000 --> 0:05:30.620000
 queries that can be used to do this.

0:05:30.620000 --> 0:05:31.640000
 MySQL is load file.

0:05:31.640000 --> 0:05:39.620000
 Microsoft SQL Server is open, Rowset,
 you know, Oracle, your UTL HTTP,

0:05:39.620000 --> 0:05:44.960000
 the advantages of the, you know, DNS
 based out of band sequel injection

0:05:44.960000 --> 0:05:49.420000
 is that DNS callbacks are lightweight,
 work across firewalls.

0:05:49.420000 --> 0:05:53.380000
 And I'm generally speaking quite much
 more harder to detect or to flag

0:05:53.380000 --> 0:05:55.860000
 is let's say malicious.

0:05:55.860000 --> 0:05:59.300000
 So very important that you
 keep that in mind now.

0:05:59.300000 --> 0:06:04.340000
 I have some exploitation examples for
 both and I've just used this diagram

0:06:04.340000 --> 0:06:07.840000
 here. I'll use this diagram sort of
 explain or to outline that attack

0:06:07.840000 --> 0:06:11.740000
 flow that I just was going over shortly.

0:06:11.740000 --> 0:06:16.320000
 Where, you know, as the user, you inject
 the payload or, you know, in

0:06:16.320000 --> 0:06:20.160000
 this all, this obviously
 involves crafting one.

0:06:20.160000 --> 0:06:23.740000
 He then sent the payload, the database
 processes the payload.

0:06:23.740000 --> 0:06:27.940000
 If it's the first type, you know, DNS
 query, the DNS query sent to the

0:06:27.940000 --> 0:06:28.620000
 attacker server.

0:06:28.620000 --> 0:06:34.200000
 So the DNS server captures the query,
 verifying that the SQL injection

0:06:34.200000 --> 0:06:39.380000
 vulnerability does exist because
 the database called back.

0:06:39.380000 --> 0:06:44.060000
 If it doesn't call back, then you know,
 yeah, not necessarily that SQL

0:06:44.060000 --> 0:06:46.360000
 injection isn't possible.

0:06:46.360000 --> 0:06:48.720000
 There may be, you know, other factors.

0:06:48.720000 --> 0:06:51.380000
 The same goes for HTTP requests.

0:06:51.380000 --> 0:06:54.960000
 The bottom line is that when you get
 a call back on your server, all the

0:06:54.960000 --> 0:07:00.560000
 server you control regardless of what
 type of out of band technique you're

0:07:00.560000 --> 0:07:05.300000
 using, you'll know that yes, the vulnerability
 exists or it doesn't.

0:07:05.300000 --> 0:07:06.840000
 So hopefully that makes sense.

0:07:06.840000 --> 0:07:10.700000
 So let's take a look at DNS based
 out of band SQL injection.

0:07:10.700000 --> 0:07:14.300000
 And in this case, we'll use a scenario
 where a website has a vulnerable

0:07:14.300000 --> 0:07:17.800000
 parameter. In this case, the
 ID parameter in the URL.

0:07:17.800000 --> 0:07:19.880000
 So the attack flow is as follows.

0:07:19.880000 --> 0:07:22.360000
 We start off by setting
 up the DNS server.

0:07:22.360000 --> 0:07:27.460000
 So the attacker uses a service like DNS
 log dot CN or a custom DNS server

0:07:27.460000 --> 0:07:29.900000
 to monitor incoming DNS queries.

0:07:29.900000 --> 0:07:34.820000
 The payload injection step, you know,
 this is where the attack injects

0:07:34.820000 --> 0:07:38.060000
 payload like this in the ID parameter.

0:07:38.060000 --> 0:07:39.900000
 So union select load file.

0:07:39.900000 --> 0:07:43.200000
 So this is obviously my SQL
 and then you're calling.

0:07:43.200000 --> 0:07:49.040000
 So you're essentially telling the database,
 hey, you know, load a file

0:07:49.040000 --> 0:07:53.500000
 from this remote service with the
 following domain or subdomain.

0:07:53.500000 --> 0:07:58.440000
 And the resource could just be, you
 know, in this case, is just file.

0:07:58.440000 --> 0:08:04.480000
 But the most important point here is
 that the payload uses native to MySQL

0:08:04.480000 --> 0:08:08.440000
 to force the database to resolve the
 attacker control domain, which in

0:08:08.440000 --> 0:08:11.420000
 this case is attacker dot DNS log dot CN.


0:08:11.420000 --> 0:08:15.020000
 Okay. And then of course, step three
 database processing, the database

0:08:15.020000 --> 0:08:18.800000
 executes the query and attempts
 to access the domain.

0:08:18.800000 --> 0:08:22.820000
 In this case, attacker
 dot DNS log dot CN.

0:08:22.820000 --> 0:08:25.620000
 And then of course, as the attacker,
 you monitor the DNS log.

0:08:25.620000 --> 0:08:30.180000
 So the attacker observes the DNS query
 in the DNS server logs confirming

0:08:30.180000 --> 0:08:32.960000
 that the vulnerability exists because
 they'll see that there was a callback

0:08:32.960000 --> 0:08:37.540000
 from the remote database
 or the database itself.

0:08:37.540000 --> 0:08:44.440000
 And that, you know, verifies that yes,
 the payload we injected that, you

0:08:44.440000 --> 0:08:47.760000
 know, essentially calls back.

0:08:47.760000 --> 0:08:53.840000
 Or as I mentioned right over here, the
 payload that forces the database

0:08:53.840000 --> 0:09:01.060000
 to resolve the attacker control domain,
 you know, will will obviously

0:09:01.060000 --> 0:09:06.360000
 be logged. And yeah, so that, you know,
 just trying to explain it as best

0:09:06.360000 --> 0:09:09.800000
 as possible. So this is a visualization
 of how it works, where we have

0:09:09.800000 --> 0:09:16.640000
 the, we have the hacker site or DNS server,
 if you will, whether you know,

0:09:16.640000 --> 0:09:24.020000
 it's HTTP, you know, DNS based
 out of pan SQL injection.

0:09:24.020000 --> 0:09:28.480000
 And the bottom line is you as the attacker,
 you know, you inject a payload

0:09:28.480000 --> 0:09:33.140000
 that, you know, essentially telling
 the database, hey, can you resolve

0:09:33.140000 --> 0:09:38.560000
 the following domain, simply
 port, you know, inject it.

0:09:38.560000 --> 0:09:44.360000
 And then the database over here, you
 can see if the vulnerability does

0:09:44.360000 --> 0:09:46.600000
 exist, the database will execute it.

0:09:46.600000 --> 0:09:53.080000
 And if the database is allowed to load
 external resources, then it'll,

0:09:53.080000 --> 0:09:57.160000
 you know, essentially make a request
 to that domain that DNS or domain

0:09:57.160000 --> 0:09:58.880000
 is resolved to the IP of the server.

0:09:58.880000 --> 0:10:03.140000
 And then you actually, as the attacker,
 get to see the logs, verifying,

0:10:03.140000 --> 0:10:08.120000
 yes, you know, either yes, the, if we
 forget a log yet, then we know that

0:10:08.120000 --> 0:10:13.320000
 the, the website is vulnerable to SQL
 injection, or more importantly,

0:10:13.320000 --> 0:10:17.460000
 the database executed that particular
 payload or query, therefore confirming

0:10:17.460000 --> 0:10:19.760000
 that there is an injection vulnerability.


0:10:19.760000 --> 0:10:23.500000
 If you don't see it, then yeah, you know,
 that at least this payload didn't

0:10:23.500000 --> 0:10:25.300000
 work, for example.

0:10:25.300000 --> 0:10:31.740000
 The other example is obviously the HTTP
 based out of band SQL injection.

0:10:31.740000 --> 0:10:35.660000
 And in this case, you know, if we use
 an example scenario, a, where a

0:10:35.660000 --> 0:10:39.520000
 website has a vulnerable search
 parameter in its post request.

0:10:39.520000 --> 0:10:44.720000
 So you can see making a post to the
 following endpoint, which is search.

0:10:44.720000 --> 0:10:49.160000
 And then there's a search parameter,
 which in this case, equal to keyword.

0:10:49.160000 --> 0:10:52.900000
 So the attack flow is again, starts
 off with setting up in this case,

0:10:52.900000 --> 0:10:54.140000
 an HTTP service.

0:10:54.140000 --> 0:10:58.240000
 So the attacker uses a service like
 Collaborator or ng-rock to host an

0:10:58.240000 --> 0:11:01.660000
 HTTP endpoint for capturing callbacks.

0:11:01.660000 --> 0:11:03.660000
 And then we have the payload injection.

0:11:03.660000 --> 0:11:07.160000
 So the attacker injects the following
 payload in the search parameter.

0:11:07.160000 --> 0:11:11.760000
 So in this case, we're using XPC MD
 shell, which is a function native

0:11:11.760000 --> 0:11:17.920000
 to MSSQL. So execute XPC MD shell,
 and then you make a call request to

0:11:17.920000 --> 0:11:25.740000
 the attacker. You know, you make a, a,
 a call request, and then, you know,

0:11:25.740000 --> 0:11:31.560000
 you then have, you then inject
 the payload over there.

0:11:31.560000 --> 0:11:38.560000
 And yeah, so this payload uses the XPC
 MD shell function to send a request

0:11:38.560000 --> 0:11:43.320000
 to the attacker server, including the
 database version information in

0:11:43.320000 --> 0:11:44.400000
 the query string.

0:11:44.400000 --> 0:11:48.220000
 So yeah, we essentially connecting to
 the attacker, the attacker control

0:11:48.220000 --> 0:11:52.960000
 server, and then including then the
 data parameter, you can see there

0:11:52.960000 --> 0:11:56.940000
 the saying select version to essentially
 enumerate that info.

0:11:56.940000 --> 0:12:01.920000
 And then step three database processing,
 the database executes the payload

0:12:01.920000 --> 0:12:06.600000
 sending an HTTP request
 to httpattacker.com.

0:12:06.600000 --> 0:12:10.880000
 And then of course, the attacker, you
 know, step four capturing the request,

0:12:10.880000 --> 0:12:14.020000
 the attacker observes the HTTP request
 in their server logs, where you

0:12:14.020000 --> 0:12:16.080000
 can see a get request being made.

0:12:16.080000 --> 0:12:21.120000
 And then the version of the database
 is displayed as a value of the data

0:12:21.120000 --> 0:12:25.380000
 parameter. Again, very basic example,
 we're sort of going to be exploring

0:12:25.380000 --> 0:12:30.500000
 that right now. So before we end the
 video, I just want to show you, give

0:12:30.500000 --> 0:12:35.900000
 you a practical demo, using a simple
 web app that I created that again,

0:12:35.900000 --> 0:12:40.240000
 doesn't have a database or anything like
 that, but we'll pretty much explain

0:12:40.240000 --> 0:12:44.360000
 or help you understand, you
 know, how this works.

0:12:44.360000 --> 0:12:47.240000
 And the reason for that or the reason I
 can show it to you in a lab environment,

0:12:47.240000 --> 0:12:49.300000
 at least not yet.

0:12:49.300000 --> 0:12:53.740000
 If I am able to set up a lab environment
 that allows for emulation of

0:12:53.740000 --> 0:12:56.260000
 this, then you will see
 it under this video.

0:12:56.260000 --> 0:13:00.320000
 But again, for the purposes of this
 video and this demonstration, I'm

0:13:00.320000 --> 0:13:05.980000
 going to be using my own environment
 where I have a web application that

0:13:05.980000 --> 0:13:11.100000
 essentially will emulate or simulate
 making a callback to a particular

0:13:11.100000 --> 0:13:14.720000
 end point or a server that we control.

0:13:14.720000 --> 0:13:18.600000
 And I'll tell you what
 technologies I'm using.

0:13:18.600000 --> 0:13:26.900000
 And the bottom line is, we then are
 going to simulate performing a SQL

0:13:26.900000 --> 0:13:31.040000
 injection attack, where we, you know,
 attack a particular, a particular

0:13:31.040000 --> 0:13:36.520000
 parameter. And you know, the bottom line
 is when we make or when we perform

0:13:36.520000 --> 0:13:41.660000
 the injection, we essentially trigger
 the web application to make the

0:13:41.660000 --> 0:13:44.800000
 callback. So we're just simulating what
 would typically happen with the

0:13:44.800000 --> 0:13:49.540000
 database. So I'm just going to switch
 over into my Kali Linux environment.

0:13:49.540000 --> 0:13:53.640000
 And I may need to switch back and
 forth between one of my terminals.

0:13:53.640000 --> 0:14:03.780000
 But currently in my Kali Linux system,
 and you can see I have a plus web

0:14:03.780000 --> 0:14:05.540000
 application running.

0:14:05.540000 --> 0:14:07.860000
 So I'll just zoom in here.

0:14:07.860000 --> 0:14:12.240000
 I've just called it app dot pi.

0:14:12.240000 --> 0:14:13.540000
 And you can see it's fairly simple.

0:14:13.540000 --> 0:14:15.800000
 So we have a route called vulnerable.

0:14:15.800000 --> 0:14:17.760000
 The methods allowed our get here.

0:14:17.760000 --> 0:14:24.020000
 And you can see it has, it accepts user
 input through through two parameters,

0:14:24.020000 --> 0:14:28.880000
 one being, you can see
 right of a user input.

0:14:28.880000 --> 0:14:34.020000
 So the input query parameter and
 then the user agent HTTP header.

0:14:34.020000 --> 0:14:37.980000
 And over here is just a vulnerable
 simulated SQL query.

0:14:37.980000 --> 0:14:41.300000
 Again, just for the sake of demonstrating
 this where you can see select

0:14:41.300000 --> 0:14:47.580000
 all from users where input is equal
 to the user input and user agent is

0:14:47.580000 --> 0:14:49.740000
 equal to user agent, right?

0:14:49.740000 --> 0:14:53.440000
 And then I'm using interactive sage,
 which I'll explain shortly.

0:14:53.440000 --> 0:14:55.780000
 In explain it now.

0:14:55.780000 --> 0:14:57.660000
 Just give me a second.

0:14:57.660000 --> 0:15:00.240000
 Let me just open up a wrong site there.

0:15:00.240000 --> 0:15:07.360000
 So interact SH interact SH is an extremely
 useful tool for all be so you

0:15:07.360000 --> 0:15:12.320000
 can see it's an O be in an interaction
 gathering server and client library.

0:15:12.320000 --> 0:15:13.980000
 It's open source.

0:15:13.980000 --> 0:15:17.460000
 You can just search for it's interact SH.


0:15:17.460000 --> 0:15:20.980000
 So right over here, you can see interactive
 sage is an open source tool

0:15:20.980000 --> 0:15:23.100000
 for detecting out of band interactions.

0:15:23.100000 --> 0:15:27.840000
 It is a tool designed to detect vulnerabilities
 that cause external interaction.

0:15:27.840000 --> 0:15:33.860000
 So the features are DNS HTTP,
 HTTPS, SMTP, LDAP interaction.

0:15:33.860000 --> 0:15:36.140000
 There's a command line interface web.

0:15:36.140000 --> 0:15:41.080000
 There's a bug plug in or extension, the
 same for zap and a Docker client.

0:15:41.080000 --> 0:15:46.760000
 And you can see right over here, it
 also has, you can self host it is

0:15:46.760000 --> 0:15:50.040000
 multiple domain support.

0:15:50.040000 --> 0:15:54.960000
 And a lot of these features are
 in the event of self hosting.

0:15:54.960000 --> 0:16:05.000000
 So you can actually use the client right
 over here to just to essentially

0:16:05.000000 --> 0:16:17.220000
 spin up a very quick endpoint
 that, you know, an endpoint.

0:16:17.220000 --> 0:16:22.160000
 In this case, it would not be DNS, but
 more so actually it would be both.

0:16:22.160000 --> 0:16:26.240000
 But yeah, it's, you know,
 you spin up an endpoint.

0:16:26.240000 --> 0:16:34.720000
 Again, one that's, as you'll see, shortly,
 you know, you just spin up

0:16:34.720000 --> 0:16:50.540000
 an endpoint. And you can see right over
 your input, you can oast.pro.live,

0:16:50.540000 --> 0:16:53.020000
 etc. And I'll show you
 what that looks like.

0:16:53.020000 --> 0:16:58.780000
 And right over here, you have your
 filters and all of that good stuff.

0:16:58.780000 --> 0:17:02.540000
 And the bottom line is this is what
 it'll look like when a callback is

0:17:02.540000 --> 0:17:07.620000
 made. Again, regardless of, you know,
 regardless of the fact that we're

0:17:07.620000 --> 0:17:11.420000
 performing a simulation, but you can
 see that if the database server,

0:17:11.420000 --> 0:17:17.540000
 you know, makes a request or actually
 successfully processes the payload

0:17:17.540000 --> 0:17:21.960000
 you injected that is making a request
 to this external server, which in

0:17:21.960000 --> 0:17:26.080000
 this case will just be
 this right over here.

0:17:26.080000 --> 0:17:30.560000
 So you can see this will generate a
 unique payload that can be used for

0:17:30.560000 --> 0:17:34.340000
 be testing with minimal interaction
 information in the output.

0:17:34.340000 --> 0:17:38.660000
 So you can just use the client and
 it'll give you this, you know, this

0:17:38.660000 --> 0:17:41.900000
 particular payload, if you will.

0:17:41.900000 --> 0:17:47.960000
 And then you can pretty much
 include this in your query.

0:17:47.960000 --> 0:17:50.260000
 And I believe I had created
 a couple of them here.

0:17:50.260000 --> 0:17:54.520000
 So this, these would be examples of
 how you'd perform the injection.

0:17:54.520000 --> 0:17:56.300000
 So using load file.

0:17:56.300000 --> 0:18:01.940000
 And if I was injecting into the user
 agent header, right over here, you

0:18:01.940000 --> 0:18:04.300000
 know, in this case, union
 select load file.

0:18:04.300000 --> 0:18:11.800000
 And it would point to this particular
 interact SH payload or this particular

0:18:11.800000 --> 0:18:17.740000
 endpoint. And in this case, the request
 would be made, you know, in this

0:18:17.740000 --> 0:18:21.500000
 case, it's adapted to the Flaw Square
 application that I've set up anyway.

0:18:21.500000 --> 0:18:24.080000
 I'm, I'm probably confusing
 you at this point.

0:18:24.080000 --> 0:18:28.040000
 The best way to show you this
 is to actually show you this.

0:18:28.040000 --> 0:18:33.620000
 But I would highly recommend that you
 go through the, you go through the

0:18:33.620000 --> 0:18:35.500000
 GitHub repo and experiment with it.

0:18:35.500000 --> 0:18:40.180000
 So just give me a second as I
 switch into my terminal here.

0:18:40.180000 --> 0:18:42.460000
 And I just wanted to show you this here.

0:18:42.460000 --> 0:18:45.080000
 So just a second.

0:18:45.080000 --> 0:18:45.860000
 So there we are.

0:18:45.860000 --> 0:18:48.940000
 We can see I'd set up
 one right over here.

0:18:48.940000 --> 0:18:53.100000
 So let me just terminate
 this right over here.

0:18:53.100000 --> 0:18:55.300000
 So I have a remote server.

0:18:55.300000 --> 0:18:56.860000
 There we are. I can zoom in.

0:18:56.860000 --> 0:19:01.100000
 So I have a remote server with
 the client already ready to go.

0:19:01.100000 --> 0:19:05.340000
 So you just run, you know, the interactor
 Sage client and it'll give you

0:19:05.340000 --> 0:19:07.540000
 the payload for who will be testing.

0:19:07.540000 --> 0:19:10.640000
 So you can actually copy this here.

0:19:10.640000 --> 0:19:14.420000
 And now I'll go back into the
 into my calilnik system.

0:19:14.420000 --> 0:19:16.120000
 And I'll go in here.

0:19:16.120000 --> 0:19:20.640000
 And the way this web application works
 is it processes input in a simulated

0:19:20.640000 --> 0:19:23.820000
 SQL query. So there's no actual
 database interaction.

0:19:23.820000 --> 0:19:27.540000
 And then if the malicious payload is
 detected, which will need to simulate

0:19:27.540000 --> 0:19:33.240000
 very easily through a a call request,
 for example, in this particular

0:19:33.240000 --> 0:19:36.200000
 case, let me see if I can actually
 remember how I configured it.

0:19:36.200000 --> 0:19:44.180000
 Yeah. So if trigger callback and user
 input or trigger trigger callback

0:19:44.180000 --> 0:19:48.700000
 and user agent. So that's essentially
 what we need to specify.

0:19:48.700000 --> 0:19:52.380000
 But yeah, so again, I'll
 not complicate it.

0:19:52.380000 --> 0:19:54.520000
 I'll just put the interact
 SH domain here.

0:19:54.520000 --> 0:19:58.220000
 This is the domain that the callback
 will be made to if we provide the

0:19:58.220000 --> 0:20:02.660000
 correct payload, which in this case is
 just going to be trigger callback.

0:20:02.660000 --> 0:20:06.260000
 So you can think of this as a
 as our SQL injection payload.

0:20:06.260000 --> 0:20:12.860000
 Okay. And if successful, the web app
 will sort of simulate a database

0:20:12.860000 --> 0:20:20.120000
 executing the SQL injection payload that
 will then make a query or a call

0:20:20.120000 --> 0:20:25.880000
 back to this particular interact SH
 payload or endpoint, if you will,

0:20:25.880000 --> 0:20:30.140000
 for be testing. And you can see it right
 over your requests, it's going

0:20:30.140000 --> 0:20:35.500000
 to make a request to the interact
 SH domain callback.

0:20:35.500000 --> 0:20:38.600000
 Input is equal to, you
 know, the user input.

0:20:38.600000 --> 0:20:43.620000
 And then the agent needs to be just
 trigger callback, trigger callback.

0:20:43.620000 --> 0:20:50.760000
 And then there, what will be returned,
 if successful, is it, you know,

0:20:50.760000 --> 0:20:51.980000
 we'll get triggered.

0:20:51.980000 --> 0:20:55.360000
 And this web app is just a local web
 app that's listening on port 5000

0:20:55.360000 --> 0:20:58.020000
 local hosts. So very, very simple.

0:20:58.020000 --> 0:20:59.560000
 I'll write and quit.

0:20:59.560000 --> 0:21:03.280000
 And then I can say Python
 three app dot pi.

0:21:03.280000 --> 0:21:08.320000
 Okay. So the way this works is this is
 the curl request or the SQL injection

0:21:08.320000 --> 0:21:13.400000
 attack where you can see, you know,
 write a via very, very simple.

0:21:13.400000 --> 0:21:17.560000
 So we're making a curl request to the
 following vulnerable web application,

0:21:17.560000 --> 0:21:22.040000
 the flask web app, which is said
 is running local host port 5000.

0:21:22.040000 --> 0:21:24.020000
 Remember, the route was vulnerable.

0:21:24.020000 --> 0:21:27.740000
 And then input is equal
 to trigger callback.

0:21:27.740000 --> 0:21:33.740000
 And the user agent is also needs
 to be set to trigger callback.

0:21:33.740000 --> 0:21:39.640000
 And if both of these are provided, you
 know, trigger callback being the

0:21:39.640000 --> 0:21:44.040000
 SQL injection payload, if you will,
 then a callback will be made to the

0:21:44.040000 --> 0:21:47.920000
 interact SH payload or endpoint
 that is listening.

0:21:47.920000 --> 0:21:50.540000
 So we just hit enter.

0:21:50.540000 --> 0:21:52.840000
 And you can see it says
 call back triggered.

0:21:52.840000 --> 0:21:57.540000
 And if I look at the Python, the flask
 application log here, you can see,

0:21:57.540000 --> 0:21:59.280000
 yes, a get request was made.

0:21:59.280000 --> 0:22:01.480000
 That's because of the curl request.

0:22:01.480000 --> 0:22:06.260000
 And now if I switch back into my Windows
 terminal here, you can see interact

0:22:06.260000 --> 0:22:12.380000
 SH right over here, we receive a DNS
 interaction, an HTTP interaction.

0:22:12.380000 --> 0:22:16.320000
 And we have the timestamps here, therefore
 verifying or validating that

0:22:16.320000 --> 0:22:19.060000
 yes, you know, SQL injection
 vulnerability exists.

0:22:19.060000 --> 0:22:24.860000
 So this is typically what an out of band
 SQL injection attack looks like.

0:22:24.860000 --> 0:22:29.680000
 So again, what I can do now
 is sort of change this.

0:22:29.680000 --> 0:22:33.320000
 And maybe I just use a different
 payload like trigger.

0:22:33.320000 --> 0:22:37.500000
 In this case, actually, that would
 have only made one there.

0:22:37.500000 --> 0:22:40.360000
 Let's take a look at the logs here.

0:22:40.360000 --> 0:22:46.400000
 In this case, it's going to
 be, let's see that was 1954.

0:22:46.400000 --> 0:22:48.660000
 The other one was 19.

0:22:48.660000 --> 0:22:56.240000
 Yeah, so just two over here
 DNS and HTTP interaction.

0:22:56.240000 --> 0:23:00.900000
 So interesting. That's coming.

0:23:00.900000 --> 0:23:03.660000
 Yeah, okay. So DNS interaction.

0:23:03.660000 --> 0:23:09.080000
 Now, if I go back in here, and I make
 another curl request, let's say,

0:23:09.080000 --> 0:23:15.160000
 we'll also get just modify this
 so that they incorrect.

0:23:15.160000 --> 0:23:22.460000
 Yeah, executed query, one second
 trigger, let's look at this here.

0:23:22.460000 --> 0:23:24.300000
 Yeah, so that doesn't work.

0:23:24.300000 --> 0:23:31.160000
 So let's say write a via
 trigger call back.

0:23:31.160000 --> 0:23:37.600000
 If I just make a curl request
 to this one over here.

0:23:37.600000 --> 0:23:43.200000
 Yeah. And then if I take a look at this
 here, yeah, that does not work.

0:23:43.200000 --> 0:23:48.480000
 So yeah, the bottom line is
 just to make it simple.

0:23:48.480000 --> 0:23:54.900000
 We have a web app here running on
 port, you know, 5000 local host.

0:23:54.900000 --> 0:24:00.520000
 So you can see the route
 was vulnerable, right?

0:24:00.520000 --> 0:24:04.740000
 And in this case, it just gives you
 the, you know, just a query that's

0:24:04.740000 --> 0:24:06.420000
 being executed. Not really important.

0:24:06.420000 --> 0:24:08.720000
 You can disregard this.

0:24:08.720000 --> 0:24:18.220000
 But the bottom line is that what the parameter
 that personally is vulnerable

0:24:18.220000 --> 0:24:20.620000
 is the input one.

0:24:20.620000 --> 0:24:21.980000
 That's a URL parameter.

0:24:21.980000 --> 0:24:30.280000
 So, you know, if we go in here, and
 I say input is equal to, if I take

0:24:30.280000 --> 0:24:32.480000
 a look, yeah, we'll just say test, right?


0:24:32.480000 --> 0:24:36.580000
 That'll just, it just giving you an
 example of the query that is being

0:24:36.580000 --> 0:24:38.420000
 emulated, if you will.

0:24:38.420000 --> 0:24:41.600000
 So you can see it replicated there.

0:24:41.600000 --> 0:24:48.780000
 And then, of course, the user agent
 header is also injectable.

0:24:48.780000 --> 0:24:52.660000
 And what we're doing with the curl command
 is, we're just performing the

0:24:52.660000 --> 0:24:57.240000
 injection. The only thing is we're
 not specifying a real SQLI payload.

0:24:57.240000 --> 0:25:01.240000
 We're just, you know, using one that
 simulates it, call trigger callback,

0:25:01.240000 --> 0:25:05.360000
 that'll then perform the, you know,
 that'll then simulate the callback.

0:25:05.360000 --> 0:25:08.920000
 So again, if I hit enter, you can see
 call back triggered going to my

0:25:08.920000 --> 0:25:10.340000
 terminal. There we are.

0:25:10.340000 --> 0:25:12.860000
 We can see the new requests there.

0:25:12.860000 --> 0:25:14.540000
 And you can see that there.

0:25:14.540000 --> 0:25:21.000000
 So this is the best, you know, this
 is sort of the easiest way I could

0:25:21.000000 --> 0:25:25.180000
 I thought of in terms of showing you or
 giving your practical understanding

0:25:25.180000 --> 0:25:29.840000
 of what out of band SQL
 injection looks like.

0:25:29.840000 --> 0:25:35.940000
 So that brings us to the end of the
 practical demonstration section of

0:25:35.940000 --> 0:25:38.360000
 this video. All right.

0:25:38.360000 --> 0:25:41.820000
 So that was out of band
 SQL injection attacks.

0:25:41.820000 --> 0:25:48.700000
 Hopefully you found that enjoyable and
 definitely experiment with interactive

0:25:48.700000 --> 0:25:51.340000
 sage again. This is a very hard thing.

0:25:51.340000 --> 0:25:54.740000
 It's really it's rarely explained well.

0:25:54.740000 --> 0:25:58.960000
 But I thought it'd be much better to
 give you a practical demo as well

0:25:58.960000 --> 0:26:01.340000
 than just, you know, covering
 the theoretical stuff.

0:26:01.340000 --> 0:26:06.780000
 So you can actually see when you should
 actually opt for out of band.

0:26:06.780000 --> 0:26:10.680000
 And of course, I know we weren't able
 to cover the exaltration bit, but

0:26:10.680000 --> 0:26:13.640000
 it pretty much works in the same vein.

0:26:13.640000 --> 0:26:16.640000
 Or, you know, using the same methodology,
 if you will, the bottom line

0:26:16.640000 --> 0:26:21.500000
 is that I am as the attacker, I'm able
 to confirm that a SQL injection

0:26:21.500000 --> 0:26:25.800000
 vulnerability exists and the database
 is processing queries or the payloads

0:26:25.800000 --> 0:26:27.760000
 that I'm injecting.

0:26:27.760000 --> 0:26:33.600000
 You know, in the event that the web application
 does not give me an indication

0:26:33.600000 --> 0:26:36.320000
 of successful execution of queries.

0:26:36.320000 --> 0:26:40.800000
 So it's only in cases where, you know,
 blind doesn't work, you know, time

0:26:40.800000 --> 0:26:43.260000
-based doesn't work, I should say, etc.

0:26:43.260000 --> 0:26:45.800000
 Anyway, that's going to
 be it for this video.

0:26:45.800000 --> 0:26:47.940000
 And I'll be seeing you in the next video.