WEBVTT

0:00:03.640000 --> 0:00:07.320000
 Hello everyone and welcome to this video.


0:00:07.320000 --> 0:00:11.720000
 In this video we are going to be
 taking a look at LDAP injection.

0:00:11.720000 --> 0:00:16.320000
 So now that you have an understanding
 of LDAP or I should say fundamental

0:00:16.320000 --> 0:00:23.020000
 understanding, we can turn our attention
 to the attacks pertinent or pertaining

0:00:23.020000 --> 0:00:27.820000
 to LDAP and in this particular context
 given that you know this is a web

0:00:27.820000 --> 0:00:34.020000
 app testing course, we're going to be
 exploring LDAP injection even more

0:00:34.020000 --> 0:00:39.220000
 so because this is a course focused
 on injection attacks.

0:00:39.220000 --> 0:00:44.300000
 So to get things off we need to understand
 what LDAP injection is.

0:00:44.300000 --> 0:00:46.340000
 So what is LDAP injection?

0:00:46.340000 --> 0:00:51.220000
 Well LDAP injection is a web application
 vulnerability that occurs when

0:00:51.220000 --> 0:00:56.780000
 user supplied input is improperly sanitized
 or validated just like any

0:00:56.780000 --> 0:01:02.340000
 other injection or input based vulnerability
 before being incorporated

0:01:02.340000 --> 0:01:04.040000
 into an LDAP query.

0:01:04.040000 --> 0:01:10.620000
 Again pretty much almost exactly syntactically
 the same as SQL injection.

0:01:10.620000 --> 0:01:14.340000
 The only difference is you know
 the query language if you will.

0:01:14.340000 --> 0:01:18.240000
 So what this does is it allows attackers
 to manipulate the structure of

0:01:18.240000 --> 0:01:23.960000
 the query leading to unauthorized access such
 as you know bypassing authentication,

0:01:23.960000 --> 0:01:29.480000
 being one of the examples or you know
 just like SQL injection extracting

0:01:29.480000 --> 0:01:34.020000
 sensitive information from
 the directory itself.

0:01:34.020000 --> 0:01:37.940000
 So the bottom line is that if a query
 is not sanitized an attacker can

0:01:37.940000 --> 0:01:43.080000
 use a wildcard for example instead of
 a legitimate object or referencing

0:01:43.080000 --> 0:01:50.020000
 a legitimate object or a specific object
 therefore you know pulling or

0:01:50.020000 --> 0:01:53.420000
 listing all objects instead
 of a specific one.

0:01:53.420000 --> 0:01:57.820000
 And the placement of such payloads if
 I can call them like the wildcard

0:01:57.820000 --> 0:02:02.500000
 is sort of the key of what will be
 exploring in the practical section

0:02:02.500000 --> 0:02:10.220000
 of this video. So what causes the vulnerability
 or what causes LDAP injection

0:02:10.220000 --> 0:02:13.140000
 if you know if it isn't already clear.

0:02:13.140000 --> 0:02:17.780000
 Firstly we have improper input validation
 so accepting user input directly

0:02:17.780000 --> 0:02:20.580000
 without verifying or sanitizing it.

0:02:20.580000 --> 0:02:24.660000
 You then have concatenating user input
 into queries so dynamically building

0:02:24.660000 --> 0:02:29.400000
 LDAP queries using unsanitized user input
 instead of using safe parameterized

0:02:29.400000 --> 0:02:33.360000
 queries. And then of course there's the
 lack of escape mechanism so special

0:02:33.360000 --> 0:02:40.820000
 characters like the asterisk or wildcard
 you know brackets you know open,

0:02:40.820000 --> 0:02:46.500000
 close etc or you know the the actual
 OR operator in LDAP queries are not

0:02:46.500000 --> 0:02:52.420000
 properly escaped essentially allowing
 attackers to alter query logic.

0:02:52.420000 --> 0:02:58.480000
 So here I have an example a basic
 LDAP injection example.

0:02:58.480000 --> 0:03:02.020000
 So let's suppose that you know we have
 a web application that allows us

0:03:02.020000 --> 0:03:08.040000
 to list all available printers for
 whatever reason and these printers

0:03:08.040000 --> 0:03:14.660000
 obviously within being referenced
 within an LDAP directory right.

0:03:14.660000 --> 0:03:19.000000
 And one key thing is that in this particular
 case the web application

0:03:19.000000 --> 0:03:23.800000
 does not display any error messages
 or error messages are not returned.

0:03:23.800000 --> 0:03:27.240000
 So the application utilizes
 the following search filter.

0:03:27.240000 --> 0:03:31.860000
 So this is an example of an LDAP query
 where you have AND so the logical

0:03:31.860000 --> 0:03:33.280000
 operators there.

0:03:33.280000 --> 0:03:44.620000
 So both of these specific options if
 you will or checks or searches need

0:03:44.620000 --> 0:03:50.680000
 to be you know need to be need to match
 so object class printer and the

0:03:50.680000 --> 0:03:55.180000
 type has to be canon and there's a
 use of a wildcard so anything that

0:03:55.180000 --> 0:04:03.580000
 starts with the word canon you know
 will show up but it must also fall

0:04:03.580000 --> 0:04:09.240000
 or must also be a part of the object
 class printer okay which actually

0:04:09.240000 --> 0:04:15.960000
 makes sense. So you know in this particular
 case any if any canon printers

0:04:15.960000 --> 0:04:20.500000
 are available or within the directory
 icons in the case of how this web

0:04:20.500000 --> 0:04:24.120000
 application is built icons of these
 printers are shown to the client or

0:04:24.120000 --> 0:04:28.100000
 on that particular page otherwise
 no icon is present.

0:04:28.100000 --> 0:04:31.900000
 Now this is an example of that you know
 standard boolean or true or false

0:04:31.900000 --> 0:04:39.840000
 situation and this will become irrelevant
 or why I'm sort of starting

0:04:39.840000 --> 0:04:42.620000
 off with this example will
 become apparent shortly.

0:04:42.620000 --> 0:04:48.280000
 So there was no injection there but
 we're going to lead into it that was

0:04:48.280000 --> 0:04:53.400000
 just an example of a query if you will
 an LDAP query that's again legitimate

0:04:53.400000 --> 0:04:56.480000
 but hopefully you're starting
 to see the logic.

0:04:56.480000 --> 0:05:02.600000
 So what we're going to do now is we're
 going to take a look at some examples

0:05:02.600000 --> 0:05:06.020000
 of LDAP injection that will hopefully
 give you an understanding of how

0:05:06.020000 --> 0:05:07.720000
 all of this works.

0:05:07.720000 --> 0:05:11.800000
 So let's get started with some examples.

0:05:11.800000 --> 0:05:18.680000
 So we are going to you know kick off
 with the most basic of examples and

0:05:18.680000 --> 0:05:25.140000
 that's the standard authentication bypass
 vulnerability or attack in this

0:05:25.140000 --> 0:05:27.600000
 case through LDAP injection.

0:05:27.600000 --> 0:05:32.920000
 So you know I'm not saying that this
 is common or this is something you'll

0:05:32.920000 --> 0:05:37.020000
 run into just using it as an example
 to demonstrate what the injection

0:05:37.020000 --> 0:05:42.980000
 looks like and as you'll see it's fairly
 similar to you know what you

0:05:42.980000 --> 0:05:49.800000
 typically do or the payloads you know
 from a syntax perspective what you

0:05:49.800000 --> 0:05:54.780000
 do you know when when performing a SQL
 injection attack or when you know

0:05:54.780000 --> 0:05:56.340000
 testing for SQL injection.

0:05:56.340000 --> 0:06:00.360000
 So this is a typical LDAP query that's
 used for authentication whereby

0:06:00.360000 --> 0:06:07.080000
 they use name and password parameters
 or values here represented in the

0:06:07.080000 --> 0:06:09.680000
 actual query are user inputs.

0:06:09.680000 --> 0:06:13.800000
 So this is an example of what the query
 looks like in which both of these

0:06:13.800000 --> 0:06:21.960000
 search filters or sub filters if you
 will those being you know UID and

0:06:21.960000 --> 0:06:26.000000
 password you know both need
 to equate to true okay.

0:06:26.000000 --> 0:06:30.600000
 So the bottom line is that if user
 input is not sanitized for each of

0:06:30.600000 --> 0:06:35.500000
 these inputs which are filters because
 you know they're searching or querying

0:06:35.500000 --> 0:06:40.040000
 for information an attacker can inject
 the following you know as the username

0:06:40.040000 --> 0:06:46.500000
 for example. So they would use the
 wildcard or you know close you know

0:06:46.500000 --> 0:06:54.940000
 essentially wildcard and the closing bracket
 or they would close the bracket

0:06:54.940000 --> 0:07:00.160000
 then specify you know use ID is equal
 to and then wildcard to essentially

0:07:00.160000 --> 0:07:05.280000
 you know display everything.

0:07:05.280000 --> 0:07:11.300000
 The bottom line is that this particular
 payload in when injected will

0:07:11.300000 --> 0:07:17.260000
 essentially cause the entire query
 which you can see in the resulting

0:07:17.260000 --> 0:07:19.860000
 query to evaluate to true.

0:07:19.860000 --> 0:07:25.640000
 So what we're doing is you can see right
 over here in the original query

0:07:25.640000 --> 0:07:30.880000
 both we have the AND operator which
 means both of these search filters

0:07:30.880000 --> 0:07:37.240000
 need to equate to true or need to be
 true or need to match if you will.

0:07:37.240000 --> 0:07:42.100000
 What we're doing if we inject this
 particular query or payload in the

0:07:42.100000 --> 0:07:47.960000
 username field or supply it as the
 username is you can see where this

0:07:47.960000 --> 0:07:54.460000
 is expected what we're actually doing
 is closing the user ID you know

0:07:54.460000 --> 0:08:00.240000
 we're actually closing the user ID
 search filter there and specifying

0:08:00.240000 --> 0:08:01.660000
 the wildcard operator.

0:08:01.660000 --> 0:08:06.680000
 So this is the first in the resulting
 query this is what you can see here

0:08:06.680000 --> 0:08:12.360000
 so use ID and then this is where the
 payload that we injected begins so

0:08:12.360000 --> 0:08:17.260000
 we close that so we say you know use
 ID is equal to everything you know

0:08:17.260000 --> 0:08:26.200000
 just equate to true because as part of
 the wider as part of the the query

0:08:26.200000 --> 0:08:31.020000
 as a whole this will you know equate
 to true and then use ID is equal

0:08:31.020000 --> 0:08:37.440000
 to again wildcard true and that'll you
 know pretty much allows us to bypass

0:08:37.440000 --> 0:08:44.580000
 authentication. Using the same web
 application example in the previous

0:08:44.580000 --> 0:08:51.380000
 slide if we submit the following payload
 or query and we you know we utilize

0:08:51.380000 --> 0:08:56.700000
 the object class here and we also use
 the wildcard there we can see that

0:08:56.700000 --> 0:09:01.900000
 what this does is it'll also equate
 to true and the difference here is

0:09:01.900000 --> 0:09:05.600000
 that the query retrieves all entries
 in the directory where object class

0:09:05.600000 --> 0:09:10.320000
 is equal to you know wildcard
 or everything.

0:09:10.320000 --> 0:09:16.960000
 So that's in essence how it works now
 you may be asking what the asterisk

0:09:16.960000 --> 0:09:30.200000
 and the single quote it's sort of like
 a delimiter or it closes the previous

0:09:30.200000 --> 0:09:34.620000
 query if you will or terminates
 it so you can begin a new one.

0:09:34.620000 --> 0:09:38.980000
 So when combined the characters close
 an existing filter sorry they're

0:09:38.980000 --> 0:09:42.500000
 not called queries but filters as I
 mentioned search filters and adds

0:09:42.500000 --> 0:09:45.980000
 a new wildcard condition often to bypass
 restrictions or to change the

0:09:45.980000 --> 0:09:50.660000
 query logic. So using the authentication
 bypass example again the vulnerable

0:09:50.660000 --> 0:09:55.220000
 query you know is exactly the same as
 we saw in the previous slides the

0:09:55.220000 --> 0:10:00.840000
 attacker inputs so they use what would
 be the equivalent of the the single

0:10:00.840000 --> 0:10:05.460000
 quote in a MySQL query or payload which
 in this case is going to be the

0:10:05.460000 --> 0:10:15.500000
 asterisk and you know the the bracket
 there and then of course we specify

0:10:15.500000 --> 0:10:21.640000
 our own you know we add a new wildcard
 condition which will obviously

0:10:21.640000 --> 0:10:26.620000
 bypass any restrictions or change the
 query logic altogether and you know

0:10:26.620000 --> 0:10:29.560000
 the password can be anything.

0:10:29.560000 --> 0:10:37.900000
 And the apology I sort of forgotten
 what the closing bracket is it's a

0:10:37.900000 --> 0:10:42.180000
 parentheses my bad but yeah that's pretty
 much what I wanted to highlight

0:10:42.180000 --> 0:10:54.360000
 so the resulting injected you know
 is highlighted in red there so the

0:10:54.360000 --> 0:10:59.260000
 asterisk or wildcard and the parentheses
 the end parent you know the closing

0:10:59.260000 --> 0:11:05.100000
 parentheses ends the use ID filter early
 and adds a new wildcard filter

0:11:05.100000 --> 0:11:10.500000
 being use ID is equal to wildcard or
 the asterisk and this causes the

0:11:10.500000 --> 0:11:22.880000
 query to match all that's pretty much
 you know all the theoretical knowledge

0:11:22.880000 --> 0:11:29.160000
 I can give you about LDAP injection
 without you know causing you to to

0:11:29.160000 --> 0:11:34.080000
 pull your hair out it's time now to contextualize
 everything in the through

0:11:34.080000 --> 0:11:40.200000
 the use of a practical lab so this
 video has a lab associated with it

0:11:40.200000 --> 0:11:44.940000
 the lab is just going to be below this
 video and the lab will provide

0:11:44.940000 --> 0:11:49.420000
 you with access to a pre-configured
 Kaliland system so you don't need

0:11:49.420000 --> 0:11:55.220000
 to use your own and the target web application
 we're going to be exploiting

0:11:55.220000 --> 0:12:01.300000
 is a unintentionally vulnerable web
 application but a very good one and

0:12:01.300000 --> 0:12:06.160000
 you'll see why but yeah with that being
 said let's not take any more time

0:12:06.160000 --> 0:12:10.940000
 in these slides I'm going to fire up
 my lab and I'll see you there in

0:12:10.940000 --> 0:12:12.920000
 a couple of seconds.

0:12:12.920000 --> 0:12:18.360000
 All right so I'm back within the lab
 environment and as you can see you'll

0:12:18.360000 --> 0:12:23.840000
 be provided with access to a pre-configured
 Kaliland system and we're

0:12:23.840000 --> 0:12:30.460000
 good to go so the target web application
 is running on the URL or can

0:12:30.460000 --> 0:12:37.080000
 be accessed via the host demo.ini.local
 port 1990 this is also highlighted

0:12:37.080000 --> 0:12:41.500000
 in the documentation for this lab make
 sure you use HTTP and there we

0:12:41.500000 --> 0:13:14.900000
 are so we can see the name of the target
 web application is V the network

0:13:14.900000 --> 0:13:17.580000
 uses for authentication.

0:13:17.580000 --> 0:13:25.960000
 Hah! abuse this relationship to find
 details of the system users and as

0:13:25.960000 --> 0:13:31.860000
 a bonus it is known that the admin store
 SSH keys in the database in this

0:13:31.860000 --> 0:13:37.720000
 case the the LDAP directory if you will
 so see if you can find anything

0:13:37.720000 --> 0:13:42.780000
 interesting in there so we have a stock
 control system here and you can

0:13:42.780000 --> 0:13:47.500000
 see it tells us to select the category
 so fruit or vegetables we can click

0:13:47.500000 --> 0:13:52.520000
 on that and as you can see right over
 here we have the fruits so banana

0:13:52.520000 --> 0:13:57.720000
 this is a perfect example of how LDAP is used
 not just for let's say authentication

0:13:57.720000 --> 0:14:03.040000
 but also you know just querying data
 from the directory in this case you

0:14:03.040000 --> 0:14:08.020000
 know there would be there would be
 entries and you can see right over

0:14:08.020000 --> 0:14:12.180000
 here the object class is fruits which
 makes sense but then what falls

0:14:12.180000 --> 0:14:17.060000
 under fruits well we have bananas and
 we have banana and we have apple

0:14:17.060000 --> 0:14:22.000000
 okay so we can click on banana and
 you can see right over here if you

0:14:22.000000 --> 0:14:25.900000
 remember what I covered in the previous
 video so we have item and then

0:14:25.900000 --> 0:14:32.040000
 the canonical name is banana and display
 is equal to stock and then sorry

0:14:32.040000 --> 0:14:38.800000
 display the display parameter displays
 the the attributes for banana so

0:14:38.800000 --> 0:14:44.640000
 stock which is a you know the the amount
 of stock that this company has

0:14:44.640000 --> 0:14:51.560000
 the stock of bananas and then the description
 of the entry you know which

0:14:51.560000 --> 0:15:01.020000
 is just yellow and bendy as you can read
 there and then actually displayed

0:15:01.020000 --> 0:15:10.500000
 here exactly you know as we figured see
 yeah so there we go and from this

0:15:10.500000 --> 0:15:15.800000
 point you know we this is pretty much
 what I covered in the slides but

0:15:15.800000 --> 0:15:20.580000
 let's go back here and go to the object
 class which right now is displaying

0:15:20.580000 --> 0:15:25.000000
 fruits we also have vegetables which
 again you know object class equals

0:15:25.000000 --> 0:15:29.680000
 vegetables let's go back to fruits and
 what if we use the wildcard instead

0:15:29.680000 --> 0:15:33.180000
 of saying you know we want fruits what
 if we want to display everything

0:15:33.180000 --> 0:15:38.960000
 we hit enter and there we are so that's
 an example of held app injection

0:15:38.960000 --> 0:15:42.400000
 this is not being sanitized you know
 the asterisk is something that should

0:15:42.400000 --> 0:15:49.320000
 be sanitized now that also means if we
 again you know object class equals

0:15:49.320000 --> 0:15:55.260000
 yeah pretty much everything this would
 also mean that if we use you know

0:15:55.260000 --> 0:16:00.280000
 we just use the and operator that should
 also I believe give us the same

0:16:00.280000 --> 0:16:06.400000
 result so we hit enter yes indeed it
 does right over there anyway so now

0:16:06.400000 --> 0:16:12.440000
 we can see everything and in here we
 can see that it displays everything

0:16:12.440000 --> 0:16:19.900000
 so all entries if you will so we have
 potato, carrot, courgette, banana,

0:16:19.900000 --> 0:16:25.560000
 apple and then users and admins very
 interesting and we have users and

0:16:25.560000 --> 0:16:32.300000
 admins appear to be groups or organizational
 units let's see yeah so nothing

0:16:32.300000 --> 0:16:36.420000
 really too crazy in there and then we
 have users themselves what appear

0:16:36.420000 --> 0:16:41.800000
 to be users because of their names
 so Martha is a developer Joanne is

0:16:41.800000 --> 0:16:45.820000
 a manager David is an administrator but
 we also have the admins what appears

0:16:45.820000 --> 0:16:50.140000
 to be a group to me so we click on that
 and you can see just the description

0:16:50.140000 --> 0:16:56.680000
 is displayed what if we you know yeah
 that's not going to give us anything

0:16:56.680000 --> 0:17:03.920000
 there we can obviously try and just
 try and play around you know right

0:17:03.920000 --> 0:17:08.020000
 over here let's see yeah that probably
 will not doesn't make any sense

0:17:08.020000 --> 0:17:15.500000
 to do that there because it's just displaying
 the canonical name but when

0:17:15.500000 --> 0:17:19.120000
 we go back we can see something interesting
 POSIX group okay so that's

0:17:19.120000 --> 0:17:23.780000
 probably referring to the fact that
 these are indeed user accounts on

0:17:23.780000 --> 0:17:29.620000
 the system or on the underlying server
 again object class POSIX group

0:17:29.620000 --> 0:17:33.920000
 will perform some research into that
 shortly but if we go back to fruit

0:17:33.920000 --> 0:17:41.680000
 and let's go ahead and use wildcard here
 so sorry not not that one although

0:17:41.680000 --> 0:17:50.460000
 we can use that as well so I sort of
 you know went or sped through what

0:17:50.460000 --> 0:17:54.700000
 exactly we're doing so we can see right
 of the object class that's obviously

0:17:54.700000 --> 0:18:00.760000
 you know going to leverage LDAP as
 I as I've mentioned in the previous

0:18:00.760000 --> 0:18:06.540000
 video and in this video in the slides
 the asterisk wildcard is a special

0:18:06.540000 --> 0:18:13.900000
 character that you know injected or input
 in this particular context what

0:18:13.900000 --> 0:18:17.400000
 it's doing is pretty much returning
 all the object class items which as

0:18:17.400000 --> 0:18:21.380000
 I said I'm not really described but
 based on their names we can pretty

0:18:21.380000 --> 0:18:28.100000
 much infer that you know these would be
 you know these potatoes a vegetable

0:18:28.100000 --> 0:18:34.280000
 carrot etc but we then have what would
 appear to be groups in this particular

0:18:34.280000 --> 0:18:40.920000
 case you know those would be you know
 users so if we click on this here

0:18:40.920000 --> 0:18:49.140000
 you can see users via LDAP etc Martha
 David Joanne etc right so hopefully

0:18:49.140000 --> 0:18:54.320000
 that makes sense now you know if we
 when we clicked on a user here you

0:18:54.320000 --> 0:18:59.360000
 can see that you know the same directory
 structure that follows but in

0:18:59.360000 --> 0:19:04.020000
 this case what is sorry not the directory
 structure the syntax if you

0:19:04.020000 --> 0:19:10.420000
 will so the canonical name so item that
 gives us the you know canonical

0:19:10.420000 --> 0:19:17.580000
 name David and then what is displayed
 is the stock description and canonical

0:19:17.580000 --> 0:19:28.900000
 name so you will in this case it's
 David but in the because David I'm

0:19:28.900000 --> 0:19:33.540000
 assuming doesn't have is not a fruit
 nor vegetable that's not going to

0:19:33.540000 --> 0:19:39.540000
 be displayed okay now what was interesting
 that you know we just saw a

0:19:39.540000 --> 0:19:51.620000
 few seconds ago is when we go when we
 click back right over here the the

0:19:51.620000 --> 0:19:56.160000
 URL parameter object class now points
 to POSIX account which actually

0:19:56.160000 --> 0:20:01.900000
 makes sense because we successfully
 performed the injection and you know

0:20:01.900000 --> 0:20:09.780000
 we were not looking for any fruits
 or vegetables and as a result what

0:20:09.780000 --> 0:20:15.320000
 this does is it lists out you know because
 of the actual class POSIX account

0:20:15.320000 --> 0:20:21.140000
 is an actual class and I'll explain
 sorry is an actual object class and

0:20:21.140000 --> 0:20:25.240000
 I'll explain what it's used for because
 it's pretty standard what ends

0:20:25.240000 --> 0:20:29.760000
 up happening is it just lists the system
 users present in the LDAP database

0:20:29.760000 --> 0:20:35.500000
 so now you don't see any fruits or
 vegetables so we have Martha Joanne

0:20:35.500000 --> 0:20:41.100000
 David etc now this is where things get
 interesting the objective of the

0:20:41.100000 --> 0:20:47.920000
 challenge as you web application was
 to try and extract SSH passwords

0:20:47.920000 --> 0:20:54.100000
 or keys right and when we go and you
 know we click on let's say David

0:20:54.100000 --> 0:21:02.940000
 here you can see you know nothing too
 special however POSIX account or

0:21:02.940000 --> 0:21:08.320000
 that particular class is particular
 is quite interesting so if we take

0:21:08.320000 --> 0:21:13.900000
 a look at the LDAP schema information
 you know which I'll just open up

0:21:13.900000 --> 0:21:19.900000
 shortly you know just some basic documentation
 to learn more about you

0:21:19.900000 --> 0:21:24.600000
 know the POSIX account object class maybe
 we can get an idea of what type

0:21:24.600000 --> 0:21:30.080000
 of attributes it contains and based
 on the attributes we may be able to

0:21:30.080000 --> 0:21:35.520000
 get some additional information about
 a particular entry like you know

0:21:35.520000 --> 0:21:39.860000
 maybe David's passwords or something
 like that so I'm just going to switch

0:21:39.860000 --> 0:21:47.020000
 over into my browser and we can take
 a look at the LDAP schema information

0:21:47.020000 --> 0:21:53.420000
 particularly in reference to the POSIX
 account object class which is actually

0:21:53.420000 --> 0:21:57.220000
 been implemented because if we go back
 we can see right of the POSIX account

0:21:57.220000 --> 0:22:04.480000
 so I'll just switch over just give me
 a second all right so I'm back this

0:22:04.480000 --> 0:22:08.880000
 documentation has actually been added
 to the lab documentation or this

0:22:08.880000 --> 0:22:16.620000
 particular URL where you can actually
 see the you know the LDAP schema

0:22:16.620000 --> 0:22:20.900000
 information and right over here I've
 gone to machine accounts so the way

0:22:20.900000 --> 0:22:25.520000
 it's organized is in fact it's probably
 wise you know if I sort of explain

0:22:25.520000 --> 0:22:30.260000
 this so this is the LDAP implementation
 how to or the RFC if that makes

0:22:30.260000 --> 0:22:35.340000
 sense so this is a proposition of a schema
 that can be used to accommodate

0:22:35.340000 --> 0:22:43.600000
 all the existing listed functions etc
 and right over here you can see

0:22:43.600000 --> 0:22:48.840000
 it's just a schema right and over here
 we have the LDAP attributes and

0:22:48.840000 --> 0:22:57.340000
 object classes so right over here you
 can see the object class top where

0:22:57.340000 --> 0:23:01.200000
 you would have the attributes or you
 you know organizational unit and

0:23:01.200000 --> 0:23:07.360000
 then the value users etc account owners
 and account being the description

0:23:07.360000 --> 0:23:13.300000
 and then we have POSIX account right and
 under POSIX account the attributes

0:23:13.300000 --> 0:23:23.400000
 there would be the use ID number the
 GID number and the home directory

0:23:23.400000 --> 0:23:29.080000
 and the user password okay and this
 is an example of what those values

0:23:29.080000 --> 0:23:39.840000
 would look like so the bottom line is
 that if the object class you know

0:23:39.840000 --> 0:23:44.660000
 POSIX account is actually been implemented
 then that means we can probably

0:23:44.660000 --> 0:23:51.440000
 query you know the values or the attributes
 for a specific user like let's

0:23:51.440000 --> 0:23:58.020000
 say David and get the following information
 possibly right so what we

0:23:58.020000 --> 0:24:04.380000
 now need to understand and I'll just
 switch back over into the lab really

0:24:04.380000 --> 0:24:08.660000
 quickly is we need to understand the
 following so if we go back to the

0:24:08.660000 --> 0:24:14.000000
 main menu you can see right over here
 that it says as a bonus it is known

0:24:14.000000 --> 0:24:18.580000
 that admin store SSH keys we know that
 David is an admin and that's why

0:24:18.580000 --> 0:24:31.120000
 I'm sort of fixated with his account
 but we also we also we can see that

0:24:31.120000 --> 0:24:34.160000
 the challenge tells us that you know
 we're not going to get any passwords

0:24:34.160000 --> 0:24:41.700000
 but we may get we may get SSH keys so
 that brings us now to a different

0:24:41.700000 --> 0:24:45.540000
 conundrum and that is understanding and
 I'll just show you this reference

0:24:45.540000 --> 0:24:53.360000
 right over here and that is understanding
 you know how we can sort of

0:24:53.360000 --> 0:25:02.220000
 get the SSH key values using the attributes
 for the POSIX account object

0:25:02.220000 --> 0:25:15.580000
 class so this particular you know stack
 exchange and this has also been

0:25:15.580000 --> 0:25:22.940000
 added to the lab documentation yeah so
 what is being explained here pretty

0:25:22.940000 --> 0:25:28.680000
 much is you know if we take a look at
 this over here this answer update

0:25:28.680000 --> 0:25:34.800000
 LDAP to include the open SSH LPK schema
 we first need to update LDAP with

0:25:34.800000 --> 0:25:40.620000
 a schema to add the SSH public key
 attribute for users now this may be

0:25:40.620000 --> 0:25:46.260000
 separate it may be separate actually
 hold on if I'm just checking this

0:25:46.260000 --> 0:25:53.440000
 here just want to make sure that in
 this particular case yeah so they

0:25:53.440000 --> 0:25:59.260000
 wanted to add or to include the open
 SSH LPK schema and then what this

0:25:59.260000 --> 0:26:03.820000
 individual here is essentially telling
 us that we need to update the LDAP

0:26:03.820000 --> 0:26:08.600000
 schema if you want to do that and add
 SSH public key and add the SSH public

0:26:08.600000 --> 0:26:15.700000
 key attribute for users so then you
 know create a script that queries

0:26:15.700000 --> 0:26:20.820000
 LDAP for a user specific key so this
 is what the query would look like

0:26:20.820000 --> 0:26:26.380000
 and then you know update the SSH config
 or SSH config to point to the

0:26:26.380000 --> 0:26:33.400000
 script from the previous step okay so
 that means you know we can obviously

0:26:33.400000 --> 0:26:41.600000
 probably try and query this right over
 here and we can actually try this

0:26:41.600000 --> 0:26:48.000000
 out so what this means is that again
 based on this particular challenge

0:26:48.000000 --> 0:26:53.080000
 we can leverage or utilize the SSH
 public key attribute to get the SSH

0:26:53.080000 --> 0:27:04.180000
 keys and we would actually need to include
 the other attributes or sort

0:27:04.180000 --> 0:27:09.400000
 of combine them with they probably
 are you know it's probably part of

0:27:09.400000 --> 0:27:14.540000
 that if I just go back in here we can
 see POSIX account yeah there's no

0:27:14.540000 --> 0:27:22.860000
 mention of that but what we can do
 is POSIX account use ID so this is

0:27:22.860000 --> 0:27:32.560000
 the description what we could do is instead
 of displaying you know anything

0:27:32.560000 --> 0:27:37.320000
 specific we can say display the use ID
 instead of saying display the stock

0:27:37.320000 --> 0:27:41.600000
 and stuff like that we can say display
 the use ID number the group ID

0:27:41.600000 --> 0:27:48.820000
 if that makes sense the home directory
 and use a password and also the

0:27:48.820000 --> 0:27:56.060000
 SSH public key which is not a standard
 attribute but probably is what

0:27:56.060000 --> 0:28:00.720000
 we should be trying to do so what we're
 going to do now is go back to

0:28:00.720000 --> 0:28:06.580000
 stock control fruit and you know we
 can just perform use a wildcard here

0:28:06.580000 --> 0:28:11.980000
 and we go to david more info then so
 right over here david and display

0:28:11.980000 --> 0:28:21.820000
 instead of stock because you know this
 is you know the we actually have

0:28:21.820000 --> 0:28:34.040000
 the the POSIX account object class
 implemented what we can do is let's

0:28:34.040000 --> 0:28:42.580000
 see we can say so cn david and display
 is equal to uid number that was

0:28:42.580000 --> 0:28:49.420000
 the name of the attribute and then we
 had gid number and then we had the

0:28:49.420000 --> 0:28:59.380000
 home password let's see if that actually
 displays anything so yeah use

0:28:59.380000 --> 0:29:09.520000
 a password not displayed so maybe we can
 try and list SSH public key public

0:29:09.520000 --> 0:29:15.080000
 key i believe it enter and indeed we
 get that now what is very curious

0:29:15.080000 --> 0:29:20.540000
 or what i want to actually check which
 i'm not particularly sure of yeah

0:29:20.540000 --> 0:29:30.220000
 so it's not part of the part of the
 POSIX schema here um if i go back

0:29:30.220000 --> 0:29:35.020000
 yeah so POSIX account and then more
 info we can actually just display

0:29:35.020000 --> 0:29:43.920000
 what you know that particular um that
 particular attribute so i'll just

0:29:43.920000 --> 0:29:47.340000
 type that in again and you can see the
 public key which is not a public

0:29:47.340000 --> 0:29:50.480000
 key it appears to be a password i think
 for brevity of this particular

0:29:50.480000 --> 0:29:54.960000
 challenge we have that there and because
 you know this is the the object

0:29:54.960000 --> 0:29:59.360000
 class is POSIX account these are user
 accounts on the actual linux server

0:29:59.360000 --> 0:30:04.880000
 so that means we can pretty much i think
 SSH into this system now so let

0:30:04.880000 --> 0:30:12.400000
 me just say host demo.inie.local and
 we can say SSH what's the name of

0:30:12.400000 --> 0:30:19.100000
 the user sorry that is wrong tab or
 wrong browser the name was uh david

0:30:19.100000 --> 0:30:29.540000
 so david at 192 your IP will be different
 46 194.3 and we just hit yes

0:30:29.540000 --> 0:30:36.060000
 and there we go hit enter and there
 we are so we have the flag here i'll

0:30:36.060000 --> 0:30:42.140000
 just display it there and pretty much
 good to go so the other thing i

0:30:42.140000 --> 0:30:47.140000
 wanted to show you just to prove you
 know what i was saying um i say cat

0:30:47.140000 --> 0:30:51.700000
 let's see password you can see all the
 other users we saw they exist and

0:30:51.700000 --> 0:30:58.340000
 uh that was pretty much made clear
 when we saw the object class POSIX

0:30:58.340000 --> 0:31:03.700000
 account which i mentioned shortly uh right
 over here so the LDAP attributes

0:31:03.700000 --> 0:31:09.460000
 and object classes uh so you can see
 user accounts the object classes

0:31:09.460000 --> 0:31:15.880000
 you typically find uh you know would
 be uh POSIX accounts, SAMBA account

0:31:15.880000 --> 0:31:22.280000
 etc and then right over here you have
 uh you know the the attributes i

0:31:22.280000 --> 0:31:28.420000
 was referring to now one thing i'd like
 to point out um and this is quite

0:31:28.420000 --> 0:31:34.820000
 important while this example is fairly
 simple um i need to state that

0:31:34.820000 --> 0:31:39.940000
 the POSIX account object class is not
 always implemented by default so

0:31:39.940000 --> 0:31:43.900000
 you know you're not going to see this
 this schema documentation here just

0:31:43.900000 --> 0:31:50.560000
 uh outlining how you know uh it is to
 be implemented if you will or the

0:31:50.560000 --> 0:31:55.340000
 standard the standardized way of implementing
 it so the bottom line is

0:31:55.340000 --> 0:31:59.620000
 that the POSIX account object class
 in LDAP is not always implemented

0:31:59.620000 --> 0:32:05.320000
 by default it is implemented when required
 typically um and specifically

0:32:05.320000 --> 0:32:13.040000
 in in environments um where LDAP is
 used to manage uh you know UNIX or

0:32:13.040000 --> 0:32:22.500000
 Linux user accounts so uh just to elaborate
 on that or you know to take

0:32:22.500000 --> 0:32:27.740000
 um to explain this a little bit more
 you're it's highly unlikely to see

0:32:27.740000 --> 0:32:32.960000
 you know POSIX account um the the POSIX
 account object class implemented

0:32:32.960000 --> 0:32:38.860000
 uh in an active directory environment
 um and and you know the reason for

0:32:38.860000 --> 0:32:43.060000
 that is fairly obvious you're dealing
 with windows this particular object

0:32:43.060000 --> 0:32:49.400000
 class is only relevant to uh you know
 UNIX uh Linux accounts or systems

0:32:49.400000 --> 0:32:53.980000
 now the other thing that may have confused
 you is what exactly does POSIX

0:32:53.980000 --> 0:33:00.380000
 mean right uh well it's an abbreviation
 for um the portable operating

0:33:00.380000 --> 0:33:07.300000
 system interface uh which I believe
 is correct from wrong apologies um

0:33:07.300000 --> 0:33:12.820000
 and I yeah the the X is uh it's quite
 an old term but the X was uh refers

0:33:12.820000 --> 0:33:33.680000
 to UNIX now what is it um POSIX independently
 not POSIX that uh you know

0:33:33.680000 --> 0:33:42.620000
 pretty much designed or defined to uh
 set up a standardized uh um a set

0:33:42.620000 --> 0:33:47.020000
 up a standardization to essentially
 ensure compatibility across you know

0:33:47.020000 --> 0:33:54.820000
 different operating systems uh you know
 mainly UNIX um and uh in the context

0:33:54.820000 --> 0:34:03.220000
 of LDAP um the POSIX account class is
 designed to um it pretty much deals

0:34:03.220000 --> 0:34:09.080000
 with users but specifically it it is designed
 to map user account information

0:34:09.080000 --> 0:34:14.760000
 in LDAP to UNIX or Linux systems in a way
 that adheres to the POSIX standards

0:34:14.760000 --> 0:34:22.320000
 so um in this particular case you know
 the as I mentioned the standard

0:34:22.320000 --> 0:34:26.260000
 attributes listed here which actually
 might be a little bit outdated which

0:34:26.260000 --> 0:34:31.460000
 is what I was probably concerned about
 I I have encountered this before

0:34:31.460000 --> 0:34:36.900000
 and typically there's a few more attributes
 outside of you know the user

0:34:36.900000 --> 0:34:41.580000
 ID, user ID number, GID number, home
 directory, user password, there's

0:34:41.580000 --> 0:34:47.460000
 also um you know stuff like the login
 shell so stuff that you typically

0:34:47.460000 --> 0:34:54.120000
 see when talking about POSIX so um
 the home directory which uh yeah is

0:34:54.120000 --> 0:34:57.260000
 here but there's also other stuff like
 the login shell as you would see

0:34:57.260000 --> 0:35:02.900000
 on a Linux or UNIX uh system um you
 know when you're talking about user

0:35:02.900000 --> 0:35:08.300000
 accounts it's it's what's happening
 is pretty much trying to map um the

0:35:08.300000 --> 0:35:15.280000
 way user accounts are stored uh on
 Linux or organized on Linux if you

0:35:15.280000 --> 0:35:23.700000
 will or UNIX um to LDAP so if I um if
 I go back to the calilinic system

0:35:23.700000 --> 0:35:29.120000
 what you're essentially saying is a
 way for LDAP to interpret this so

0:35:29.120000 --> 0:35:36.220000
 name so canonical name and then use
 ID, GID and then the home directory

0:35:36.220000 --> 0:35:43.380000
 and I think the the the um the login
 shell attribute should be there but

0:35:43.380000 --> 0:35:47.500000
 that that's essentially what it's trying
 to do so there's no you know

0:35:47.500000 --> 0:35:52.600000
 I there's no uh real specific reason
 for me to explain this but I think

0:35:52.600000 --> 0:35:56.880000
 it's quite important especially with
 this very unique example uh that

0:35:56.880000 --> 0:36:03.260000
 sort of incorporates uh you know more
 than just LDAP injection uh anyway

0:36:03.260000 --> 0:36:10.420000
 that's besides the point hopefully that
 makes sense um and uh that pretty

0:36:10.420000 --> 0:36:15.960000
 much brings us to the um to the end of
 the practical demonstration section

0:36:15.960000 --> 0:36:21.640000
 of this video all right so that was
 uh LDAP injection uh in a nutshell

0:36:21.640000 --> 0:36:26.780000
 hopefully that made sense um as I said
 uh quite a trick you want to wrap

0:36:26.780000 --> 0:36:30.120000
 your mind around uh because you know
 you're now dealing with directory

0:36:30.120000 --> 0:36:34.440000
 services but uh hopefully you know
 at a conceptual level it made sense

0:36:34.440000 --> 0:36:43.880000
 as well as on a practical level I think
 that I've said or explained is

0:36:43.880000 --> 0:36:48.800000
 included in the lab documentation so
 if you ever feel lost don't worry

0:36:48.800000 --> 0:36:53.360000
 um I elaborated at the end there on
 a couple of important things related

0:36:53.360000 --> 0:36:58.480000
 to you know POSIX and and stuff like
 that which I think is important but

0:36:58.480000 --> 0:37:02.520000
 with that being said that's going to
 be it for this video and I'll be