WEBVTT

0:00:03.520000 --> 0:00:06.040000
 Hello everyone and welcome.

0:00:06.040000 --> 0:00:11.000000
 In this video we are going to be taking
 a look at one of the first server

0:00:11.000000 --> 0:00:14.820000
-side vulnerabilities, arguably the
 most important or most prevalent as

0:00:14.820000 --> 0:00:20.180000
 it features individually in the ORSP
 Top 10 and that is a server-side

0:00:20.180000 --> 0:00:22.060000
 request forgery.

0:00:22.060000 --> 0:00:27.760000
 So the idea here is to get an introduction
 to SSRF, understand what it

0:00:27.760000 --> 0:00:34.600000
 is, how it works, what's possible through
 successful exploitation, etc.

0:00:34.600000 --> 0:00:38.980000
 etc. and then throughout this particular
 section the SSRF section we're

0:00:38.980000 --> 0:00:43.120000
 going to be taking a look at various
 examples ranging from the most basic

0:00:43.120000 --> 0:00:46.000000
 to quite an advanced example.

0:00:46.000000 --> 0:00:49.280000
 But with that being said
 let's get started.

0:00:49.280000 --> 0:00:53.140000
 What is server-side request
 forgery or SSRF?

0:00:53.140000 --> 0:00:58.380000
 SSRF is a vulnerability that allows an
 attacker to trick a server, that's

0:00:58.380000 --> 0:01:02.420000
 the key word there, into making unauthorized
 requests to internal or external

0:01:02.420000 --> 0:01:05.260000
 resources on its behalf.

0:01:05.260000 --> 0:01:09.240000
 These requests are initiated by the
 vulnerable application, that's the

0:01:09.240000 --> 0:01:13.480000
 key thing to note there, but controlled
 by the attacker often leading

0:01:13.480000 --> 0:01:17.960000
 to exposure of sensitive data or
 access to restricted systems.

0:01:17.960000 --> 0:01:22.660000
 And what does this all mean from your
 perspective or from the perspective

0:01:22.660000 --> 0:01:27.940000
 of an attacker? Well, successful exploitation
 typically often leads to

0:01:27.940000 --> 0:01:32.720000
 sensitive data disclosure, theft of
 authentication information, that's

0:01:32.720000 --> 0:01:39.140000
 a bit of a bespoke outcome, but hopefully
 by the end of this section of

0:01:39.140000 --> 0:01:42.700000
 the course that will become clear,
 internal network reconnaissance, so

0:01:42.700000 --> 0:01:46.900000
 the ability to essentially, I would say
 this is more of an identification

0:01:46.900000 --> 0:01:51.960000
 or POC technique where you try and
 assess whether the application can

0:01:51.960000 --> 0:01:56.380000
 communicate with systems internally,
 so sort of ping or check a particular

0:01:56.380000 --> 0:02:01.560000
 port of a system within the network in
 which the web application is operating.

0:02:01.560000 --> 0:02:05.140000
 Or if it's in a cloud environment you
 can try and perform some network

0:02:05.140000 --> 0:02:10.580000
 discovery to see what other IPs you
 can, you sort of have access to via

0:02:10.580000 --> 0:02:15.620000
 the application itself or
 the application itself.

0:02:15.620000 --> 0:02:20.840000
 And then of course, you have
 remote code execution.

0:02:20.840000 --> 0:02:27.160000
 And what I mean by this is SSRF can
 be used or is typically used as an

0:02:27.160000 --> 0:02:32.640000
 entry point for more advanced attacks
 like RCE or even privilege escalation.

0:02:32.640000 --> 0:02:36.240000
 And then of course, you also have your
 standard file read or inclusion

0:02:36.240000 --> 0:02:40.500000
 vulnerabilities, or that's pretty
 much what you can get.

0:02:40.500000 --> 0:02:44.820000
 And again, for now, there's quite a bit
 and if you read any of the guides

0:02:44.820000 --> 0:02:52.880000
 online or, you know, some of the bug bounty
 reports, they sort of encapsulate

0:02:52.880000 --> 0:02:57.860000
 or all deal with, you know, various
 types of vulnerabilities or I should

0:02:57.860000 --> 0:03:04.540000
 say impact various types of SSRF exploitation
 techniques and also the

0:03:04.540000 --> 0:03:08.840000
 outcomes. And that's something
 that's quite important.

0:03:08.840000 --> 0:03:12.620000
 No SSRF vulnerabilities going to be
 the same in terms of, you know, what

0:03:12.620000 --> 0:03:17.580000
 you actually get to access after
 successful exploitation.

0:03:17.580000 --> 0:03:20.160000
 So what causes SSRF?

0:03:20.160000 --> 0:03:24.460000
 Well, SSRF vulnerabilities are typically
 caused by a unvalidated input,

0:03:24.460000 --> 0:03:29.300000
 obviously. So applications accept user
 supplied URLs or resources without

0:03:29.300000 --> 0:03:32.020000
 properly validating or sanitizing them.

0:03:32.020000 --> 0:03:33.980000
 And then of course, you
 have server trust.

0:03:33.980000 --> 0:03:37.540000
 So the server has access to the resources
 not directly available to the

0:03:37.540000 --> 0:03:40.920000
 attack. And if you remember what we've
 covered thus far, this is quite

0:03:40.920000 --> 0:03:44.020000
 important. And what am
 I referring to here?

0:03:44.020000 --> 0:03:48.740000
 Well, internal API's databases or cloud
 metadata services, the only difference

0:03:48.740000 --> 0:03:54.000000
 is you're not like an injection attack,
 you are not, you're not utilizing

0:03:54.000000 --> 0:03:58.400000
 the injection attack, or you're not utilizing
 SSRF, you know, to directly

0:03:58.400000 --> 0:04:00.100000
 access a database.

0:04:00.100000 --> 0:04:03.380000
 SSRF takes advantage of that
 server trust, right?

0:04:03.380000 --> 0:04:07.420000
 And as a result of that, you
 can do quite a few things.

0:04:07.420000 --> 0:04:12.180000
 But again, it's going to be entirely
 dependent on the application you're

0:04:12.180000 --> 0:04:15.320000
 testing and you know, what's accessible.

0:04:15.320000 --> 0:04:18.280000
 And then of course, see
 improper access control.

0:04:18.280000 --> 0:04:22.240000
 So applications do not enforce strict
 policies to prevent unauthorized

0:04:22.240000 --> 0:04:27.900000
 or unintended requests to, and this is
 quite important to let's say specific

0:04:27.900000 --> 0:04:33.160000
 files, you know, there may be no limitation
 to, you know, using specific

0:04:33.160000 --> 0:04:37.380000
 functions, like for example, the file
 read function in PHP that allows

0:04:37.380000 --> 0:04:42.040000
 you to read files on the actual server
 itself, which can be dangerous.

0:04:42.040000 --> 0:04:46.160000
 And you know, some examples of vulnerable
 scenarios, or some examples

0:04:46.160000 --> 0:04:50.620000
 of SSRF vulnerabilities found in web applications,
 you know, would include,

0:04:50.620000 --> 0:04:55.960000
 you know, a image fetches or URL preview
 generators that download content

0:04:55.960000 --> 0:05:01.780000
 from user supplied URLs, usually quite,
 quite interesting to see that,

0:05:01.780000 --> 0:05:04.560000
 or you know, it's quite
 prevalent, I should say.

0:05:04.560000 --> 0:05:08.620000
 And also another example where, you know,
 API integrations where the server

0:05:08.620000 --> 0:05:12.980000
 processes the user input as
 part of an external request.

0:05:12.980000 --> 0:05:15.420000
 So those are the causes.

0:05:15.420000 --> 0:05:18.880000
 And now I think, you know, to better
 understand SSRF, it's probably a

0:05:18.880000 --> 0:05:22.880000
 good idea to take a look at the anatomy
 of a SSRF attack or to, you know,

0:05:22.880000 --> 0:05:26.920000
 understand exactly what happens
 when it happens, etc.

0:05:26.920000 --> 0:05:31.180000
 So you know, firstly, the, you know,
 you as the pen tester or an attacker

0:05:31.180000 --> 0:05:33.400000
 would identify a vulnerable endpoint.

0:05:33.400000 --> 0:05:37.160000
 So look for functionality where the application
 fetches resources or content

0:05:37.160000 --> 0:05:38.800000
 from a user provided URL.

0:05:38.800000 --> 0:05:43.360000
 So you're not looking just for any,
 you know, user input, you're looking

0:05:43.360000 --> 0:05:47.980000
 for areas where a URL, you know, the
 user can supply URL doesn't have

0:05:47.980000 --> 0:05:51.640000
 to be direct, but the typical examples
 are, you know, downloaders.

0:05:51.640000 --> 0:05:55.040000
 So if you've ever seen a, you know,
 websites that allow you to download

0:05:55.040000 --> 0:05:59.160000
 a YouTube video where you provide the
 URL of the YouTube video, that's

0:05:59.160000 --> 0:06:01.740000
 an example. I'm not saying target
 does web applications.

0:06:01.740000 --> 0:06:04.820000
 I'm just, you know, trying to give you
 an idea of what I'm talking about,

0:06:04.820000 --> 0:06:09.000000
 you know, the other common one are web
 hooks or, you know, API testers.

0:06:09.000000 --> 0:06:10.840000
 Secondly, manipulate the input.

0:06:10.840000 --> 0:06:14.300000
 So craft the malicious URL that points
 to an internal or unauthorized

0:06:14.300000 --> 0:06:16.920000
 resource, such as internal servers.

0:06:16.920000 --> 0:06:21.100000
 So you could, you know, essentially
 try and see if you can, you know,

0:06:21.100000 --> 0:06:25.780000
 perform a ping or try and connect
 to local host or 127 001.

0:06:25.780000 --> 0:06:30.020000
 And again, if you're, if the web app
 is being hosted within a larger cloud

0:06:30.020000 --> 0:06:35.020000
 infrastructure, you can try and, you
 know, try and access cloud metadata

0:06:35.020000 --> 0:06:39.340000
 endpoints, for example, you know, the
 following IP or AWS just to see

0:06:39.340000 --> 0:06:43.100000
 what happens. And then of course, step
 three, the server processes the

0:06:43.100000 --> 0:06:46.400000
 request. So the application server
 processes the attacker control URL

0:06:46.400000 --> 0:06:48.540000
 and executes the request.

0:06:48.540000 --> 0:06:52.300000
 And the service trust in its network
 allows access to otherwise restricted

0:06:52.300000 --> 0:06:56.620000
 resources. So hopefully what I explained
 in the previous video, and also

0:06:56.620000 --> 0:06:59.640000
 what we talked about here, when we
 talk about server trust is starting

0:06:59.640000 --> 0:07:04.260000
 to make sense. And then step four extract
 or exploit the response of the

0:07:04.260000 --> 0:07:07.400000
 attacker may retrieve sensitive information,
 for example, internal service

0:07:07.400000 --> 0:07:09.280000
 data credentials.

0:07:09.280000 --> 0:07:12.840000
 And in advanced cases, the attacker may
 use SSRF to perform port scanning

0:07:12.840000 --> 0:07:16.600000
 on internal systems, chain attacks
 with other vulnerabilities.

0:07:16.600000 --> 0:07:21.400000
 So for example, deserialization
 or remote code execution.

0:07:21.400000 --> 0:07:25.240000
 So fairly simple in terms of the anatomy,
 this is what it looks like.

0:07:25.240000 --> 0:07:26.580000
 You have the attacker here.

0:07:26.580000 --> 0:07:30.520000
 So you send a crafted request, then
 the vulnerable application, this is

0:07:30.520000 --> 0:07:36.460000
 sort of, this is what you would call
 the application server layer.

0:07:36.460000 --> 0:07:40.380000
 And then of course, you also have the
 internal services or, you know,

0:07:40.380000 --> 0:07:44.380000
 potential targets, like the internal
 file server, internal API's cloud

0:07:44.380000 --> 0:07:48.960000
 metadata. But the bottom line is that,
 you know, the vulnerable application

0:07:48.960000 --> 0:07:51.080000
 processes the malicious input.

0:07:51.080000 --> 0:07:54.160000
 So, you know, you can just, you know,
 think of this as the internal server

0:07:54.160000 --> 0:07:56.500000
 responds with the set with
 the sensitive data.

0:07:56.500000 --> 0:08:01.660000
 And again, these can all be possible
 or potential targets, but it's fairly

0:08:01.660000 --> 0:08:03.460000
 simple to understand.

0:08:03.460000 --> 0:08:06.460000
 So that brings us to another
 important point.

0:08:06.460000 --> 0:08:10.040000
 And that is, you know, what are the
 various types of SSRF attacks?

0:08:10.040000 --> 0:08:14.000000
 Because this is something you may
 again have come across previously.

0:08:14.000000 --> 0:08:18.520000
 So the first is obviously what, you
 know, what is colloquially called

0:08:18.520000 --> 0:08:23.300000
 the basic SSRF, where the attacker utilizes
 a malicious URL to fetch internal

0:08:23.300000 --> 0:08:26.280000
 resources or external
 data via the server.

0:08:26.280000 --> 0:08:31.200000
 Examples of this are, you know, for example,
 the URL here, you know, HTTP

0:08:31.200000 --> 0:08:36.140000
 example.com fetch, the parameter URL
 is equal to, in this case, let's

0:08:36.140000 --> 0:08:40.820000
 say the, the web application allows
 you to load an external PNG.

0:08:40.820000 --> 0:08:45.260000
 But as the attacker, you modify it
 to point to your own, you know, the

0:08:45.260000 --> 0:08:49.260000
 attacker control server, where you're
 hosting whatever it could be a payload

0:08:49.260000 --> 0:08:50.660000
 or anything like that.

0:08:50.660000 --> 0:08:54.280000
 The bottom line is you're just trying
 to leverage the functionality of

0:08:54.280000 --> 0:08:59.360000
 the web application in relation to
 how it, it essentially utilizes or

0:08:59.360000 --> 0:09:03.340000
 how it reaches out to external or even
 internal services or servers, if

0:09:03.340000 --> 0:09:07.120000
 you will. And as a result of that,
 you're able to verify whether, you

0:09:07.120000 --> 0:09:12.660000
 know, yes, a, an SSRF vulnerability
 does exist or, you know, it doesn't

0:09:12.660000 --> 0:09:17.700000
 exist. And then of course, you have your
 blind SSRF, which sort of follows

0:09:17.700000 --> 0:09:21.380000
 your testing that you'd perform for
 basic, where the attacker is similar

0:09:21.380000 --> 0:09:23.740000
 to blind SQL injection.

0:09:23.740000 --> 0:09:27.540000
 The attacker, you know, cannot directly
 see the service response, but

0:09:27.540000 --> 0:09:31.980000
 can infer results through, side,
 through the side effects.

0:09:31.980000 --> 0:09:34.320000
 So for example, server
 logs or DNS resolution.

0:09:34.320000 --> 0:09:37.540000
 So in the advanced injection attacks
 course, if you remember, when we're

0:09:37.540000 --> 0:09:43.580000
 talking about out of band SQL injection
 and sort of utilizing or making

0:09:43.580000 --> 0:09:48.600000
 the database make external calls to
 a DNS server and then monitoring the

0:09:48.600000 --> 0:09:52.680000
 DNS server logs to see whether the,
 the target web application or target

0:09:52.680000 --> 0:09:56.680000
 application service or database, I should
 say, is actually reaching out

0:09:56.680000 --> 0:10:00.360000
 to our server. So, you know, the
 example here is exactly that.

0:10:00.360000 --> 0:10:02.960000
 So you send a DNS query
 to a control domain.

0:10:02.960000 --> 0:10:08.160000
 So you have HTTP example.com fetch
 parameter URL is equal to what the

0:10:08.160000 --> 0:10:09.900000
 application expects to be legitimate.

0:10:09.900000 --> 0:10:13.020000
 But in this case, you just pointed
 to the attacker control domain.

0:10:13.020000 --> 0:10:17.120000
 And you monitor as the attacker or pen
 tester, the DNS logs to see whether

0:10:17.120000 --> 0:10:22.100000
 you're getting any interesting requests
 from the target web application.

0:10:22.100000 --> 0:10:24.840000
 And then of course, you have SSRF
 to internal reconnaissance.

0:10:24.840000 --> 0:10:30.620000
 This is not really a vulnerability,
 but more so, you know, it is a type

0:10:30.620000 --> 0:10:34.000000
 of SSRF vulnerability.

0:10:34.000000 --> 0:10:38.160000
 The only difference is this is very
 specific in that you try and test

0:10:38.160000 --> 0:10:42.600000
 to see whether the SSRF vulnerability
 allows you to scan internal networks

0:10:42.600000 --> 0:10:44.660000
 or services that are not
 exposed externally.

0:10:44.660000 --> 0:10:49.240000
 So for example, testing for open ports
 on the actual local host on the

0:10:49.240000 --> 0:10:52.860000
 actual server where the, you know,
 the web application is hosted.

0:10:52.860000 --> 0:10:56.380000
 And you as a POC, you generally try
 and see if you can access the web

0:10:56.380000 --> 0:11:00.100000
 application itself that is, you know,
 being hosted on the web service

0:11:00.100000 --> 0:11:03.240000
 or, you know, port 80, port 443, etc.

0:11:03.240000 --> 0:11:06.560000
 And then of course, you have the advanced
 types of SSRF vulnerabilities

0:11:06.560000 --> 0:11:11.920000
 that involve chaining where SSRF is not
 the end goal, but part of a larger

0:11:11.920000 --> 0:11:16.400000
 exploit. So SSRF is combined with other
 vulnerabilities for advanced,

0:11:16.400000 --> 0:11:18.800000
 for advanced exploitation.

0:11:18.800000 --> 0:11:22.680000
 So for example, in the case of cloud exploitation,
 you access cloud metadata

0:11:22.680000 --> 0:11:27.540000
 services, for example, AWS, IAM credentials
 via, you know, the following

0:11:27.540000 --> 0:11:30.920000
 sample URL, so latest metadata, etc.

0:11:30.920000 --> 0:11:32.700000
 And then of course, privilege escalation.


0:11:32.700000 --> 0:11:35.720000
 So you access sensitive internal services
 that lead to privilege escalation

0:11:35.720000 --> 0:11:38.320000
 or lateral movement.

0:11:38.320000 --> 0:11:42.340000
 All right. So with that being
 said, that's an intro to SSRF.

0:11:42.340000 --> 0:11:45.480000
 In the next video, we're going to be
 taking a look at exactly what a SSRF

0:11:45.480000 --> 0:11:48.740000
 attack looks like through a
 very basic web application.

0:11:48.740000 --> 0:11:53.660000
 And that will then be followed up by sort
 of a real world practical example,

0:11:53.660000 --> 0:11:57.060000
 quite advanced that you will be
 able to play through yourself.

0:11:57.060000 --> 0:11:59.480000
 But with that being said, that's
 going to be it for this video.

0:11:59.480000 --> 0:12:01.620000
 And I will be seeing you
 in the next video.