Directory Traversal Tutorial

00:06

understand how an attacker might perform a directory, traverse Alexe, ploy it on a vulnerable application and be able to identify and remediate instances of this vulnerability

00:16

directory Traverse A ll. Attacks can be performed in a variety of ways. The goal, however, is always the same. And that is to access. Restricted resource is on a file system.

00:27

Hello. My name is Kevin Richard, and I'm a security researcher with VERACODE.

00:32

Today I'm here to provide a brief demonstration of the application security weakness called directory Traverse A LL.

00:39

To do so, I'm going to use an application called Vera and secure a Web app we're building to demonstrate a number of real security vulnerabilities.

00:48

Let's get started.

00:50

Take a look at the page on my screen.

00:52

Here we have a simple form that prompts the user to choose a file from this drop down box.

00:58

Once the user does so and clicks open file, the application will return that file's contents.

01:04

As I will demonstrate, this page is vulnerable to a directory traverse a ll attack.

01:11

Let us assume the role of an attacker, one who will seek to use this application in ways that its creator did not intend or expect.

01:19

In this example, the attacker will try to misuse this page in order to gain access to a sensitive file that the applications and users should never be able to view.

01:29

It's often the case that the attacker does not begin with all of the information they would need to successfully perform this attack.

01:36

Instead, they will examine the application toe, learn how it handles input from its users, and along the way they will take note of any assumptions that its designer has made

01:47

to craft a successful exploit. It is often necessary for the attacker to infer details about the business logic that will handle their requests.

01:55

Of course, the attacker likely does not have access to the applications source code, however, they can still in for properties about it, based on the applications behavior or on previously observed mistakes in other applications.

02:08

In this case, the attacker wants to know how their choice of book is represented in the request that the open file button initiates.

02:16

We can inspect the contents of that request using a type of tool called an intercepting proxy.

02:23

Here, I've chosen to use a Firefox extension called Tamper data.

02:27

Let's ask this tool to start monitoring my browser's traffic,

02:30

select a new link

02:36

and send a new request.

02:38

Temper data intercepts the request in progress and offers the option to modify it before we submit it.

02:45

Let's do that.

02:47

It appears that the local file name corresponding to this book is about to be sent in the requests Post data.

02:53

Now, if the attacker stops and thinks about this for a moment, they may speculate that some service side code will now upended the data to a string containing the directory where this file can be found

03:06

and will then pull that file from the location. However, is it possible to trick the application into pulling files from other locations on the server

03:14

for that exploit? To succeed, the attacker would need to change the directory where the application tries to locate the file.

03:20

But so far, the application has not exposed to direct means of doing so

03:28

So far. What does the attacker know that they can control?

03:32

They can select any option from the dropdown, and although the application does not directly allow the user to modify this value, a simple browser extension provides disability

03:44

within this field. Any characters of the application does not specifically deny are by default allowed

03:51

by default, the application will not account for every possible value that he user could submit.

03:57

So not only can the attacker type any valid file name if the designer has not implemented any validation techniques on the string that the user provides, then the attacker can submit data which, under the right conditions, could change how the application process is this request.

04:14

Let's have the attacker test their theory.

04:17

They instruct temper data to intercept the next request that the browser will send

04:21

returned to the page,

04:24

select any item from the list

04:27

and then click open file.

04:30

Tamper Data sees this request and asks the attacker if they wish to modify it.

04:34

They do, of course, and they locate the file name in the request parameters.

04:40

They clear the original value and replace it with the following string.

04:45

This string begins with an instance of the sequence dot dot slash

04:48

dot dot slash means in the parent of the current directory or go on level up.

04:55

The attacker has prepared did this sub string so that the application will look one directory above the one where it normally would.

05:01

So to repeat the sub string five times would, for example, cause of the application to begin five levels higher in the file system than had been intended.

05:12

It follows that with enough repetitions the attacker could begin all the way at its root directory,

05:16

but here they've added just one, which breaks them out of the folder they were in.

05:21

And from there they go one folder down to the Conflict Directory and instruct the application to retrieve the application dot yeah mo file.

05:30

Once the request reaches the application, it still uses this string to locate the file because no code was written to stop it from doing so.

05:43

And here is application dot yeah, mo.

05:46

As you can see, this is a very sensitive configuration file used by the spring framework.

05:50

The attacker knew of its existence because the page actually indicated that this application was built using spring,

05:58

provided that there are no other restrictions such a system or network permissions. The attacker could potentially access any file in the system that they could desire.

06:06

This ability causes a very serious liability for the designer of the application and its users as this could facilitate the leakage of very sensitive data

06:17

to summarize this demonstration.

06:19

If an attacker is allowed to specify all or part of the file name,

06:25

it may be possible to gain unauthorized access to files on the server, including those outside the Webroot that would normally be inaccessible to end users.

06:33

The level of exposure depends on the effectiveness of input validation routines, if any,

06:40

to summarize. We have now demonstrated how a directory traverse a ll attack can facilitate the compromise of very sensitive data.

06:47

It's worth mentioning that this is only one form of directory reversal and that several others do exist

06:54

to learn more about different kinds of payloads and attacks, as well as remediation for directory. Traverse A ll. Please continue to watch our training videos or participate in our training courses.

07:04

This is Kevin Richard from Veracode. Thank you very much for watching.

07:12

If loss has been detected in your application, the next step is to update your code in order to remediate. Hm.

07:17

Click on any tab to see how to secure your code from the threat of directory. Traverse A ll.

07:27

Hello Again.

07:28

This is Kevin Richard, security researcher with veracode and you've been watching our OPSEC tutorial on directory traverse a ll

07:35

in the previous sections. We showed you how an attacker could discover and explain an instance of the soldier ability, and we demonstrated how malicious users could potentially access. Restricted resource is by changing the file name or directory path used within a file system operation.

07:51

Once you understand this vulnerability, it's time to learn how to fix it.

07:56

I've chosen selection of possible RA mediations for directory Traverse A LL, and I encourage you to use the strategy that best applies to your application.

08:05

First, let's examine the code that retrieves this file.

08:09

Starting in the front end, we see that the file names are stored within an HTML form.

08:15

Once the user clicks the open file button. This triggers an http post request, which contains the file name in its body.

08:22

Next server side code reads the file name from that request, and it pens this file name to a predefined directory path.

08:33

Finally, the application sends the contents of the file at that location back to the client. In an HDTV response,

08:43

we begin by deciding where to implement the FEC's

08:46

no matter how we choose to address this issue. There is no ideal fix within client side code.

08:52

It is trivial for any user to circumvent client side validation, and for this reason, there is never a guarantee that what the server receives is trustworthy.

09:01

Therefore, we must focus our attention on the server side code.

09:05

In the case of this example, we have one distinct advantage. We already know the set of all permissible files,

09:13

this page intended only to allow one of six predefined selections from a drop down box.

09:18

Since we already know the file names that correspond to these options, there is no need to make the client submit them.

09:26

Instead, we can have the clients send a key value and have the server side code map that value to a file name.

09:33

So let's remove the file names from this form

09:37

and replace each one with a numeric i d. As one possibility.

09:43

Next, let's have the server side code. Map the number to a file name,

09:48

join that foul name with the directory path

09:50

and let the application proceed from there

09:54

Now, no matter what value the user sentence, there are only six possible values that can return to final and any other input will be rejected.

10:03

This approach will successfully prevent the user from accessing unauthorized files

10:07

in any scenario with a set of fixed input values, this is an efficient approach to remediation.

10:16

A more general solution is to define a white list.

10:20

A white list is a set of characters that are allowed to exist within data.

10:24

We can use a white list to validate the data that the user sends to the server.

10:28

In our previous example, the attacker could access a configuration file by first typing dot, dot, slash to modify the directory.

10:37

We know that the value of this perimeter should not include a slash or any character except letters, spaces and period.

10:45

So if those air the characters that we allow in our white list and we compare, the user submitted data against it rejecting any data that fails this chuck.

10:54

This would ensure that only the files in the correct directory where accessible

11:01

a similar technique, is to evaluate the file name against a regular expression.

11:07

In our example, we allow the user to access any file in one directory, but on Lee files in that directory,

11:15

therefore We know that any valid string would match the forum file name dot file extension and that no valid string would contain characters that manipulate the directory path

11:26

and efficient for mediation is to simply check that the user's string matches this pattern prior to using it.

11:33

In our case, one could even improve this fixed by restricting the file type as well.

11:41

The flaw in our example represents a very common form of directorate reversal.

11:46

If a very code skin has reported directory traverse A ll flaws in your application,

11:50

it's possible that the details of these issues will differ slightly from the exploit that you've just seen.

11:56

But don't worry, because the root cause is still the same. The application just needs to account for unexpected user input.

12:05

This has been Kevin Richard from veracode. Thank you very much for your time.

12:11

Hello again.

12:13

This is Kevin Richard, security researcher with Veracode. And you've been watching our OPSEC tutorial on directory traverse a ll

12:20

in the previous sections. We showed you how an attacker could discover and exploit an instance of the soul durability, and we demonstrated how malicious users could potentially access. Restricted resource is by changing the file name or directory path used within the file system operation.

12:37

Once you understand this vulnerability, it's time to learn how to fix it.

12:41

I've chosen selection of possible ra mediations for directory Traverse A LL, and I encourage you to use the strategy that best applies to your application.

12:50

First, let's examine the code that retrieves this file.

12:54

Starting in the front end, we see that the file names are stored within an HTML form.

13:00

Once the user clicks the open file button, this triggers an http post request, which contains the file name in its body.

13:09

Next server side code reads the file name from that request, and it pens this file name to a predefined directory path.

13:18

Finally, the application sends the contents of the file at that location back to the client. In an HDTV response,

13:28

we begin by deciding where to implement the FEC's.

13:31

No matter how we choose to address this issue, there is no ideal fix within client side code.

13:37

It is trivial for any user to circumvent client side validation. And for this reason, there is never a guarantee that what the server receives is trustworthy.

13:46

Therefore, we must focus our attention on the server side code.

13:52

In the case of this example, we have one distinct advantage. We already know the set of all permissible files,

13:58

this page intended only to allow one of six predefined selections from a drop down box.

14:03

Since we already know the file names that correspond to these options, there is no need to make the client submit them.

14:11

Instead, we can have the clients send a key value and have the server side code map that value to a file name.

14:18

So let's remove the file names from this form

14:22

and replace each one with a numeric i d. As one possibility.

14:28

Next, let's have the server side code. Map the number to a file name,

14:33

join that foul name with the directory path

14:35

and let the application proceed from there

14:39

now, no matter what value they use their sentence, there are only six possible values that can return to final, and any other input will be rejected.

14:48

This approach will successfully prevented the user from accessing unauthorized files

14:52

in any scenario with a set of fixed input values, this is an efficient approach to remediation.

15:01

A more general solution is to define a white list.

15:05

A white list is a set of characters that are allowed to exist within data.

15:09

We can use a white list to validate the data that the user sends to the server.

15:13

In our previous example, the attacker could access a configuration file by first typing dot, dot slash to modify the directory.

15:22

We know that the value of this perimeter should not include a slash or any character except letters, spaces and a period.

15:30

So if those air the characters that we allow in our white list and we compare, the user submitted data against it rejecting any data that fails this chuck,

15:39

this would ensure that only the files on the correct directory were accessible.

15:48

A similar technique is to evaluate the file name against a regular expression.

15:52

In our example, we allow the user to access any file in one directory, but on Lee files in that directory.

16:00

Therefore, we know that any valid string would match the form file name dot file extension, and that no valid string would contain characters that manipulate the directory bath

16:11

and efficient for mediation is to simply check that the user's string matches this pattern prior to using it.

16:18

In our case, one could even improve this fix by restricting the file type is well,

16:26

the flaw in our example represents a very common form of directory Traverse A ll.

16:30

If of Eric owed Skin has reported directory Traverse A ll Flaws in your application.

16:36

It's possible that the details of these issues will different slightly from the exploit that you've just seen.

16:41

But don't worry, because the root cause is still the same. The application just needs to account for unexpected user input.

16:51

This has been Kevin Richard from Veracode. Thank you very much for your time.

17:02

The scope of this course was not intended to cover all aspects of directorate reversal, attacks and their remediation. Rather, it was designed as the groundwork for further investigation.

17:11

Further information is available through the following links.