WEBVTT

0:00:03.580000 --> 0:00:06.620000
 Hello everyone and welcome to this video.


0:00:06.620000 --> 0:00:12.360000
 In this video we're going to be taking
 a look at the XML external entity

0:00:12.360000 --> 0:00:21.500000
 vulnerability or XXE as it's popularly
 abbreviated to or as if you will.

0:00:21.500000 --> 0:00:27.620000
 So this vulnerability we actually got
 an intro to in the previous video,

0:00:27.620000 --> 0:00:31.800000
 albeit you know a very short
 and concise intro.

0:00:31.800000 --> 0:00:37.100000
 I think it sort of explained a lot
 of things or you're able to get the

0:00:37.100000 --> 0:00:42.700000
 gist of it. So in order for us to exploit
 this type of vulnerability we

0:00:42.700000 --> 0:00:46.400000
 really need to understand what
 it's targeting, right?

0:00:46.400000 --> 0:00:51.400000
 So you know to begin with the most dangerous
 type of XML injection attack

0:00:51.400000 --> 0:00:57.860000
 involves injecting external entities
 into the XML document definition.

0:00:57.860000 --> 0:01:04.840000
 And this type of attack is what we refer
 to as XXE or XML external entities,

0:01:04.840000 --> 0:01:12.460000
 right? Now XXE is a vulnerability that
 occurs when an XML parser processes

0:01:12.460000 --> 0:01:18.180000
 external entities referenced in an
 XML document and this can obviously

0:01:18.180000 --> 0:01:20.920000
 lead to a data exposure.

0:01:20.920000 --> 0:01:29.280000
 So reading sensitive files
 on very, very simple.

0:01:29.280000 --> 0:01:34.580000
 What we're trying to do to summarize this
 particular slide is we are trying

0:01:34.580000 --> 0:01:39.960000
 to and I think I did it in this slide
 is we're trying to instruct the

0:01:39.960000 --> 0:01:48.200000
 XML parser to load externally defined
 entities, therefore making it possible

0:01:48.200000 --> 0:01:52.560000
 to access sensitive content or data
 that's stored on the vulnerable host

0:01:52.560000 --> 0:01:57.200000
 or server. Now it's very important
 to note that there are two kinds of

0:01:57.200000 --> 0:01:58.500000
 external entities.

0:01:58.500000 --> 0:02:02.300000
 They can be private and public and
 the differences between the two are

0:02:02.300000 --> 0:02:04.960000
 based on or are based upon the usage.

0:02:04.960000 --> 0:02:09.120000
 Now private external entities are restricted
 to either a single author

0:02:09.120000 --> 0:02:10.940000
 or group of authors.

0:02:10.940000 --> 0:02:14.900000
 Public on the other hand was designed
 for you know more broad or broader

0:02:14.900000 --> 0:02:19.560000
 usage. The definitions can be illustrated
 in greater detail in the next

0:02:19.560000 --> 0:02:25.800000
 slide. So this is sort of the difference
 between public and private or

0:02:25.800000 --> 0:02:28.520000
 I should say private and
 public external entities.

0:02:28.520000 --> 0:02:31.720000
 So this is typically how
 you see them defined.

0:02:31.720000 --> 0:02:36.520000
 So entity name system which is private
 and then the URI and then in the

0:02:36.520000 --> 0:02:39.860000
 case of public entity name
 public and then public ID.

0:02:39.860000 --> 0:02:45.360000
 So that's an alternate URI or URL
 where the entity can be found.

0:02:45.360000 --> 0:02:49.600000
 And this is what the XML document looks
 like or what it looks like in

0:02:49.600000 --> 0:02:54.400000
 reality. So in this case what is being
 referenced is copyright in the

0:02:54.400000 --> 0:02:55.360000
 case of private.

0:02:55.360000 --> 0:03:00.880000
 They're both referencing a copyright
 page that's an you know an XML file.

0:03:00.880000 --> 0:03:03.020000
 But the way they're loaded
 is slightly different.

0:03:03.020000 --> 0:03:07.860000
 So in the case of the private entities
 you can see we have entity C system

0:03:07.860000 --> 0:03:13.560000
 and then the URL you know
 to the actual site.

0:03:13.560000 --> 0:03:19.120000
 The only difference is that this is not
 a public URL or it's not a public

0:03:19.120000 --> 0:03:20.500000
 entity if you will.

0:03:20.500000 --> 0:03:23.980000
 It's actually a local one
 or a private one right.

0:03:23.980000 --> 0:03:27.140000
 And then in the case of public you
 sort of have the opposite where now

0:03:27.140000 --> 0:03:32.120000
 the copyright is being pulled from
 a public entity or in this case W3

0:03:32.120000 --> 0:03:35.880000
 schools and their copyright.xml file.

0:03:35.880000 --> 0:03:38.260000
 So very very simple to understand.

0:03:38.260000 --> 0:03:44.840000
 Now sort of building on that with external
 entities we can create dynamic

0:03:44.840000 --> 0:03:46.360000
 references in the document.

0:03:46.360000 --> 0:03:49.780000
 Clearly the most dangerous entities
 are the private ones because they

0:03:49.780000 --> 0:03:55.480000
 allow us to disclose local system files
 or they can potentially allow

0:03:55.480000 --> 0:03:59.140000
 us to do so in addition to playing with
 the network schemes or manipulating

0:03:59.140000 --> 0:04:02.580000
 the internal applications etc.

0:04:02.580000 --> 0:04:05.620000
 Now let's take a look at some useful
 techniques that can be used to test

0:04:05.620000 --> 0:04:10.920000
 or attack XML passes and inject
 XML external entities.

0:04:10.920000 --> 0:04:18.380000
 So the most common vulnerability that you'll
 typically see with XXE especially

0:04:18.380000 --> 0:04:22.820000
 in bug bounties when you're trying to
 prove a POC is going to be resource

0:04:22.820000 --> 0:04:27.200000
 inclusion. So the first example resource
 inclusion in this scenario we're

0:04:27.200000 --> 0:04:29.580000
 using sort of a test scenario here.

0:04:29.580000 --> 0:04:33.100000
 The attacker uploads or crafts
 a malicious XML file.

0:04:33.100000 --> 0:04:37.800000
 Okay that's step one and this includes
 an external entity definition that

0:04:37.800000 --> 0:04:39.180000
 points to a local file.

0:04:39.180000 --> 0:04:43.880000
 So in this case the entity is pointing
 to system and local file.

0:04:43.880000 --> 0:04:47.480000
 In this case they're trying to get the
 contents of Etsy password or the

0:04:47.480000 --> 0:04:48.940000
 Etsy password file.

0:04:48.940000 --> 0:04:52.740000
 Next in the body of the XML request they
 put the reference to the created

0:04:52.740000 --> 0:04:56.100000
 entity. So that's what's being injected.

0:04:56.100000 --> 0:05:02.080000
 So you can see entity the XXE file system
 and you point to the path there

0:05:02.080000 --> 0:05:06.220000
 and after sending the request to both
 trigger the attack and to force

0:05:06.220000 --> 0:05:10.300000
 the XML parser into fetching the malicious
 content we must coax the application

0:05:10.300000 --> 0:05:12.700000
 into providing the information sent.

0:05:12.700000 --> 0:05:19.580000
 Now this is arguably the most I wouldn't
 say complex but coaxing the application

0:05:19.580000 --> 0:05:25.780000
 into now giving you the data that you
 have tried to extract from the system

0:05:25.780000 --> 0:05:31.040000
 like the password file is really dependent
 on what type of web application

0:05:31.040000 --> 0:05:36.460000
 you're testing and the demo that we'll
 be taking a look at shortly is

0:05:36.460000 --> 0:05:41.040000
 going to show you just how robust things
 can get or how nuanced this process

0:05:41.040000 --> 0:05:45.440000
 is but the bottom line is you obviously
 have to find a way to read you

0:05:45.440000 --> 0:05:52.480000
 know what information you just sent or
 the information that was extracted

0:05:52.480000 --> 0:05:54.760000
 from the system in this case.

0:05:54.760000 --> 0:05:59.120000
 So continuing with that same example
 once the receiver reads the message

0:05:59.120000 --> 0:06:03.600000
 you not only see the body of the message
 but also the content of the external

0:06:03.600000 --> 0:06:07.600000
 entity. In this case you can see this
 is what reading that would look

0:06:07.600000 --> 0:06:12.160000
 like. Again you can disregard the web
 application here but the point I

0:06:12.160000 --> 0:06:17.400000
 was trying to say or trying to make
 with this is you know depending on

0:06:17.400000 --> 0:06:22.280000
 the web application the actual process
 of getting that data back because

0:06:22.280000 --> 0:06:26.500000
 it may not be reflected back on the web
 page where you made the injection.

0:06:26.500000 --> 0:06:30.560000
 It may be stored on a different location
 and we're going to be exploring

0:06:30.560000 --> 0:06:35.920000
 one such advanced example by taking
 a look at a vulnerability in a real

0:06:35.920000 --> 0:06:40.200000
 world web application in this case you
 know XML external entity vulnerability

0:06:40.200000 --> 0:06:42.880000
 in Apache Solar.

0:06:42.880000 --> 0:06:46.120000
 So this video has a lab environment
 associated with it.

0:06:46.120000 --> 0:06:50.280000
 This lab environment will provide you
 with access to a pre-configured

0:06:50.280000 --> 0:06:55.240000
 calilinic system and the lab is just
 going to be below this video.

0:06:55.240000 --> 0:06:59.780000
 So I'm going to fire up my lab environment
 and I'll see you there in a

0:06:59.780000 --> 0:07:01.820000
 couple of seconds.

0:07:01.820000 --> 0:07:07.120000
 All right so I'm back in the lab environment
 and the target web application

0:07:07.120000 --> 0:07:11.200000
 is going to be running on the third
 IP address within your subnet or the

0:07:11.200000 --> 0:07:15.280000
 subnet the calilinic system is a part
 of so in your case it's going to

0:07:15.280000 --> 0:07:18.700000
 be different. So if you want to find
 the target IP address just open up

0:07:18.700000 --> 0:07:23.260000
 a terminal and you can use the iFconfig
 command to get your calilinics

0:07:23.260000 --> 0:07:28.160000
 IP so pay attention or the interface
 you're looking for is ethernet 1.

0:07:28.160000 --> 0:07:32.020000
 So this is going to be your calilinics
 IP in your case it'll be different.

0:07:32.020000 --> 0:07:36.160000
 However the calilinics IP is always
 going to be the second IP within the

0:07:36.160000 --> 0:07:39.900000
 subnet or the network if you will and
 the target is going to be the third

0:07:39.900000 --> 0:07:43.760000
 one. So you just need to copy this
 value and change the two at the end

0:07:43.760000 --> 0:07:45.400000
 to a three and your golden.

0:07:45.400000 --> 0:07:49.660000
 So I'll just copy that there open up
 our browser actually we don't know

0:07:49.660000 --> 0:07:54.200000
 what port Apache solar is running on
 so it's probably wise to perform

0:07:54.200000 --> 0:08:00.120000
 a quick nmap scan here and we're just
 going to use a timing template.

0:08:00.120000 --> 0:08:04.520000
 So I'll change the two at the end to
 a three and let's see what port solar

0:08:04.520000 --> 0:08:11.180000
 is running on. Maybe we have to scan
 all ports here but let's go ahead

0:08:11.180000 --> 0:08:12.920000
 and do that now.

0:08:12.920000 --> 0:08:17.600000
 Let's see it shouldn't take too much
 time you know we should identify

0:08:17.600000 --> 0:08:22.680000
 what port it's on but the meantime
 we can just change the two here to

0:08:22.680000 --> 0:08:26.340000
 a three and let's see what
 we get there we are.

0:08:26.340000 --> 0:08:31.300000
 So we can see that the nmap scan tells
 us that Apache solar is running

0:08:31.300000 --> 0:08:40.500000
 on 8983 so let's go ahead and specify
 that port there 8983 and we'll wait

0:08:40.500000 --> 0:08:43.640000
 for this to load and there we are we
 can actually see Apache solar so

0:08:43.640000 --> 0:08:47.140000
 we're logged in as admin doesn't look
 like authentication has been enabled

0:08:47.140000 --> 0:08:50.360000
 and we can now get started
 with the exploitation.

0:08:50.360000 --> 0:08:54.900000
 So the key thing to pay attention to
 is the version of Apache solar which

0:08:54.900000 --> 0:08:57.760000
 in this case is 8.1.1.

0:08:57.760000 --> 0:09:05.480000
 Now I'm going to switch over again for
 the sake of that sort of outlines

0:09:05.480000 --> 0:09:09.480000
 the vulnerability that affects this version
 of Apache solar more specifically

0:09:09.480000 --> 0:09:16.440000
 the XXE vulnerability and how it can
 be exploited so by the way the link

0:09:16.440000 --> 0:09:20.560000
 to this GitHub repo will be in the
 lab documentation so you don't need

0:09:20.560000 --> 0:09:22.360000
 to worry about that.

0:09:22.360000 --> 0:09:25.820000
 Okay so just give me a few seconds and
 I'm going to switch over into the

0:09:25.820000 --> 0:09:28.740000
 GitHub repo and explain
 a couple of things.

0:09:28.740000 --> 0:09:33.620000
 All right so I'm currently I'm currently
 on the GitHub repo here and you

0:09:33.620000 --> 0:09:37.380000
 can see there's you know it's called
 the Apache solar injection research

0:09:37.380000 --> 0:09:44.700000
 and what we're looking for here is going
 to be this one right over here

0:09:44.700000 --> 0:09:51.860000
 the third CVE that's CV 2019 0193 remote
 code execution via data import

0:09:51.860000 --> 0:09:57.540000
 handler so while this may not appear
 to be an XXE vulnerability we need

0:09:57.540000 --> 0:10:02.580000
 to read through it so it the target
 solar version is 1.3 to 8.2 so it

0:10:02.580000 --> 0:10:10.480000
 fits within the range you know we have
 8.1.1 I believe or 8 I'm not let

0:10:10.480000 --> 0:10:13.980000
 me verify the version will actually verify
 but this is the correct exploit

0:10:13.980000 --> 0:10:18.580000
 so let's read through it and understand
 exactly what's going on okay so

0:10:18.580000 --> 0:10:21.680000
 it says the requirements are that data
 import handler should be enabled

0:10:21.680000 --> 0:10:26.320000
 which is not by default we'll check that
 shortly so solar has an optional

0:10:26.320000 --> 0:10:31.120000
 data import handler that is useful to
 import data from databases or URLs

0:10:31.120000 --> 0:10:36.320000
 ah interesting it is possible to include
 arbitrary JavaScript code inside

0:10:36.320000 --> 0:10:41.440000
 the script tag of the data config parameter
 that'll be executed on the

0:10:41.440000 --> 0:10:46.020000
 solar server for each imported document
 so this is the exploit via direct

0:10:46.020000 --> 0:10:52.340000
 connection to the solar server um not
 really what we're interested in

0:10:52.340000 --> 0:10:58.640000
 is I think this one here so when you
 test it make sure the URL specified

0:10:58.640000 --> 0:11:03.540000
 in the entity or the entity section
 is accessible from the solar side

0:11:03.540000 --> 0:11:10.200000
 and returns a valid XML document for X
-path injection so um in this particular

0:11:10.200000 --> 0:11:15.000000
 case I believe this is the attack we
 want although let me check through

0:11:15.000000 --> 0:11:27.620000
 this may be the one let's see there's
 another um xxe in the update handler

0:11:27.620000 --> 0:11:31.700000
 so if you have a very old version it'll
 also be affected by yeah this

0:11:31.700000 --> 0:11:35.840000
 is definitely not the version but I'm
 thinking I just want to see where

0:11:35.840000 --> 0:11:42.080000
 there's an explicit reference to um
 let's see so that's seven and then

0:11:42.080000 --> 0:11:47.580000
 here we have this one here so this should
 be the correct one um the bottom

0:11:47.580000 --> 0:11:52.520000
 line yeah there we are so we can actually
 see that you know we can include

0:11:52.520000 --> 0:11:56.940000
 arbitrary JavaScript code inside the script
 tag of the data config parameter

0:11:56.940000 --> 0:12:02.320000
 and then this is what it will look
 like this is of course encoded but

0:12:02.320000 --> 0:12:08.260000
 the bottom line is at least in this
 case is um we can actually leverage

0:12:08.260000 --> 0:12:15.100000
 this functionality the data import handler
 to try and import uh you know

0:12:15.100000 --> 0:12:20.080000
 data let's call it from an external
 URL because in this case you can see

0:12:20.080000 --> 0:12:26.160000
 cdata function um actually hold on see
 what we're looking at here no right

0:12:26.160000 --> 0:12:31.320000
 over here so we can actually specify
 an entity name an external one um

0:12:31.320000 --> 0:12:37.600000
 and in this case it would be let's say
 cdata yeah so we can execute system

0:12:37.600000 --> 0:12:43.020000
 commands in the script tag right over
 here data source has to be sorry

0:12:43.020000 --> 0:12:48.980000
 data config data source type URL data source
 and then script tag the function

0:12:48.980000 --> 0:12:57.140000
 here so JavaScript which we can actually
 utilize and then um the entity

0:12:57.140000 --> 0:13:04.620000
 name URL processor x path entity processor
 for each response um okay so

0:13:04.620000 --> 0:13:07.820000
 I'm now going to switch back over into
 the lab environment and we can

0:13:07.820000 --> 0:13:12.040000
 go through how this can be exploited
 all right so I'm back within the

0:13:12.040000 --> 0:13:15.040000
 lab environment and the first thing
 we need to do is just check whether

0:13:15.040000 --> 0:13:20.080000
 we have uh the data import our handler
 I believe it's called so there

0:13:20.080000 --> 0:13:24.380000
 we are under db I'm just going to click
 on data import here there we are

0:13:24.380000 --> 0:13:29.000000
 so this will allow us to perform that
 you know import external entity

0:13:29.000000 --> 0:13:35.440000
 import if you will now analyzing the
 exploit uh revealed that you know

0:13:35.440000 --> 0:13:40.700000
 we can pretty much use that as a poc
 but we do need an XML file that will

0:13:40.700000 --> 0:13:47.520000
 be hosting on the calilinic system in
 order for this to work um because

0:13:47.520000 --> 0:13:52.100000
 the the the database config right over
 here so we click on the configuration

0:13:52.100000 --> 0:13:57.880000
 mode and debug there we are so we actually
 need to uh the database config

0:13:57.880000 --> 0:14:05.660000
 that will um code that will write will
 actually um call um will actually

0:14:05.660000 --> 0:14:10.260000
 fetch the config that we don't need
 anything complex that will then use

0:14:10.260000 --> 0:14:15.460000
 for remote code execution I've already
 set up the the XML file here and

0:14:15.460000 --> 0:14:23.640000
 um the config that will be we're just
 going to create uh I'll just copy

0:14:23.640000 --> 0:14:28.240000
 this here and we'll open up my terminal
 navigate to the desktop we just

0:14:28.240000 --> 0:14:34.980000
 want to create a very simple um very
 very simple uh XML file so I'll just

0:14:34.980000 --> 0:14:40.180000
 call it solar and I'll paste in that
 there so um actually what we want

0:14:40.180000 --> 0:14:44.340000
 to do is we probably also want to include
 XML I can believe I forgot that

0:14:44.340000 --> 0:14:52.720000
 so we're going to say XML version is
 equal to uh 1.0 and then we're going

0:14:52.720000 --> 0:14:57.000000
 to say encoding let's keep that to standard
 uh because that is required

0:14:57.000000 --> 0:15:02.380000
 I believe if we don't specify things
 can get haywire um and let's close

0:15:02.380000 --> 0:15:07.020000
 that tag there so XML version and then
 we're just saying uh greater own

0:15:07.020000 --> 0:15:13.360000
 tags or note uh to uh whatever user
 uh and then we close the note tag

0:15:13.360000 --> 0:15:20.000000
 all tags are closed so we can actually
 write uh and quit um and now we

0:15:20.000000 --> 0:15:23.720000
 say um there should be syntax highlighting
 there we are so everything

0:15:23.720000 --> 0:15:31.280000
 looks good um you can use whatever
 you want but make sure you create a

0:15:31.280000 --> 0:15:37.400000
 root um root entity here uh make sure
 you remember the name because that

0:15:37.400000 --> 0:15:43.400000
 will will be important um so now taking
 a look at the config that we'll

0:15:43.400000 --> 0:15:48.280000
 be using for RCE I'm just going to zoom
 in here so you can actually see

0:15:48.280000 --> 0:15:52.680000
 this uh it's pretty much extrapolated
 from the github repo I've obviously

0:15:52.680000 --> 0:15:59.360000
 formatted it a little bit better taking
 um you know uh you know just taking

0:15:59.360000 --> 0:16:04.840000
 the syntax into account so data config
 and then data source URL data source

0:16:04.840000 --> 0:16:08.660000
 and then the script here this is where
 we have the javascript what we're

0:16:08.660000 --> 0:16:13.100000
 doing is we're using um get runtime
 exec and then where what we're going

0:16:13.100000 --> 0:16:19.820000
 to do is um copy the uh the etse shadow
 file um which contains you know

0:16:19.820000 --> 0:16:24.380000
 uh user accounts on Linux as well as
 their hashed password uh and we're

0:16:24.380000 --> 0:16:30.080000
 going to copy it to the directory of
 the web application so solar uh by

0:16:30.080000 --> 0:16:34.520000
 the way this is also specified in the
 lab documentation but uh this is

0:16:34.520000 --> 0:16:37.620000
 in order for us to access it if you
 remember in the slides I mentioned

0:16:37.620000 --> 0:16:42.800000
 that this will be sort of the nuanced aspect
 of exploiting ex uh exe vulnerabilities

0:16:42.800000 --> 0:16:47.660000
 uh because it's dependent on the web
 application and how it's set up but

0:16:47.660000 --> 0:16:53.180000
 you know just going to save it under
 solar and poc.txt so hopefully if

0:16:53.180000 --> 0:16:58.320000
 this works then this should display
 the contents of the shadow file um

0:16:58.320000 --> 0:17:02.660000
 and then over here we have the you know
 document entity name we're just

0:17:02.660000 --> 0:17:05.800000
 calling it stack overflow and then
 the URL we need to actually set up

0:17:05.800000 --> 0:17:11.060000
 a web server here so we are going to
 set up you can use python or php

0:17:11.060000 --> 0:17:18.340000
 we're going to say phps and then on pretty
 much on on all IPs on the calilinic

0:17:18.340000 --> 0:17:23.940000
 system just say port 80 and we're going
 to need the calilinics IP address

0:17:23.940000 --> 0:17:27.700000
 right over here in your case it will
 be different um and we just want

0:17:27.700000 --> 0:17:31.860000
 to put it in here so we're essentially
 saying get the XML file from the

0:17:31.860000 --> 0:17:36.100000
 following web server which is just our
 calilinic system and the name of

0:17:36.100000 --> 0:17:40.440000
 the XML file in our case we called uh
 so we we actually called it solar

0:17:40.440000 --> 0:17:44.720000
 the process is going to be x path entity
 processor and then for each and

0:17:44.720000 --> 0:17:50.960000
 then this way you specify the the root
 here um the root entity so note

0:17:50.960000 --> 0:17:55.220000
 is what we specified and then the transformer
 is going to be script uh

0:17:55.220000 --> 0:18:00.320000
 and over here the function is going
 to call is poc which we created here

0:18:00.320000 --> 0:18:04.540000
 so that's the poc function there and
 that's pretty much it so what will

0:18:04.540000 --> 0:18:12.180000
 happen is uh solar will uh solar will
 essentially get this XML file and

0:18:12.180000 --> 0:18:18.040000
 then it's going to utilize that for the
 transformer it's going to utilize

0:18:18.040000 --> 0:18:23.160000
 that to execute the uh the poc function
 which will then consequently copy

0:18:23.160000 --> 0:18:26.760000
 the contents of the etse shadow file
 or you know just the file itself

0:18:26.760000 --> 0:18:33.220000
 um and it'll save it in the root of
 the uh the Apache solar web server

0:18:33.220000 --> 0:18:38.140000
 so we should just be able to access
 it uh by navigating to poc.txt so

0:18:38.140000 --> 0:18:42.660000
 we want to copy by the way this is also
 in the lab documentation so you

0:18:42.660000 --> 0:18:46.540000
 don't need to worry about that we'll
 just go into solar admin here um

0:18:46.540000 --> 0:18:51.420000
 and we want to get rid of the default
 config and i think that should be

0:18:51.420000 --> 0:18:56.640000
 good um is our web server running let's
 go ahead and check that there

0:18:56.640000 --> 0:19:01.020000
 there we are where we should actually
 see a request here if it works um

0:19:01.020000 --> 0:19:06.940000
 and we can now just hit execute with
 this configuration it's going to

0:19:06.940000 --> 0:19:10.760000
 take a few seconds and let's take a
 look and see there we are we can see

0:19:10.760000 --> 0:19:16.320000
 a get request made by the Apache solar
 server or the solar uh XML file

0:19:16.320000 --> 0:19:20.960000
 we created which is just an excuse
 really it's just a um you know just

0:19:20.960000 --> 0:19:25.280000
 a placeholder if you will but now to
 test it out we can try and access

0:19:25.280000 --> 0:19:31.060000
 um to see if we can access uh the poc
.txt which we configured to be saved

0:19:31.060000 --> 0:19:39.080000
 at the root of the solar web application
 so poc.txt hit enter and there

0:19:39.080000 --> 0:19:43.200000
 we are so we got the contents of the
 shadow file obviously you're not

0:19:43.200000 --> 0:19:47.520000
 going to see any passwords here but there
 we go and uh that's pretty much

0:19:47.520000 --> 0:19:52.980000
 how to exploit a uh an xxe vulnerability
 in a real world web application

0:19:52.980000 --> 0:19:58.080000
 um definitely try out some of the other
 things that you can do you know

0:19:58.080000 --> 0:20:02.680000
 sort of going beyond just getting um
 the the contents of the shadow file

0:20:02.680000 --> 0:20:07.260000
 um you know you can sort of play around
 with that uh with this particular

0:20:07.260000 --> 0:20:10.920000
 exploit also refer to the github repo
 because there's a lot you can learn

0:20:10.920000 --> 0:20:16.380000
 there about not just xxen injection
 or those types of vulnerabilities

0:20:16.380000 --> 0:20:21.140000
 but uh quite a few others anyway that
 brings us to the end of the practical

0:20:21.140000 --> 0:20:27.740000
 demonstration section of this video all
 right so that was um XML external

0:20:27.740000 --> 0:20:34.260000
 entity vulnerabilities in a nutshell
 you know what they are how uh what

0:20:34.260000 --> 0:20:40.140000
 causes the vulnerability um how to identify
 and exploit um xxe vulnerabilities

0:20:40.140000 --> 0:20:45.340000
 and we know we also took a look at a
 practical example so hopefully you

0:20:45.340000 --> 0:20:48.680000
 found that useful again definitely go
 through the lab more than once and

0:20:48.680000 --> 0:20:51.980000
 understand exactly what's going on
 it's been documented very very well

0:20:51.980000 --> 0:20:56.620000
 so you don't need to rely on this video
 but there we are um anyway that