Directory / Path Traversal - Cybr SY0-601 CompTIA Security+

Just like you have directories on your PC, laptop, and mobile phones, web servers also have directories.

For example, if you were to purchase web hosting for your new website, the hosting provider would go out to their servers that have capacity, and then create a directory for your files to reside in.

As you create your website, you upload files to your reserved directory. Again, this is just like if you were to create a new directory on your PC right now, and moved files in it.

Except in the case of the webserver, that usually then becomes public so that your customers can visit your website.

If a malicious actor were to visit your website and find what’s called a directory or path traversal vulnerability, then they could potentially navigate beyond the public files and directories stored on the webserver in order to access restricted areas.

This is a really bad situation to be in because it often means that they can access configuration files, and those configuration files can either reveal credentials, or provide the attacker with additional ammunition.

Or, in the worst-case scenario, they may be able to access administrative files and directories which contain system passwords.

They could then use those credentials to login as administrators and take over the server.

Demo of path traversal

Let’s take a quick look at a demo of how this works and how it could be abused. I’m running a vulnerable web application called the DVWA. I show you how to set this up quickly and easily in this blog post if you’d like to try it yourself.

Once the application is up and running, go to File Inclusion. Once on this page, we can see that the URL is: http://localhost/vulnerabilities/fi/?page=include.php

There’s a query parameter ?page= that takes a file name and uses that input to display the contents of the file on the page. In fact, if we click on any of the file names on this page:

file1.php
file2.php
file3.php

We can see that it changes both the URL and what’s displayed.

An attacker might see this and try to traverse through directories in order to see if they can navigate beyond just these files. While this would normally take a little bit of trial and error to get right, I happen to know that this payload will work so we’ll save some time:

http://localhost/vulnerabilities/fi/?page=../../../../../../etc/passwd
Code language: JavaScript (javascript)

Instead of loading file1, 2, 3…, I’m telling the application and webserver to get me the /etc/passwd file, and to display its contents on the page. Because this application is vulnerable, it will do just that:

root:x:0:0:root:/root:/bin/bash daemon:x:1:1:daemon:/usr/sbin:/usr/sbin/nologin bin:x:2:2:bin:/bin:/usr/sbin/nologin sys:x:3:3:sys:/dev:/usr/sbin/nologin sync:x:4:65534:sync:/bin:/bin/sync games:x:5:60:games:/usr/games:/usr/sbin/nologin man:x:6:12:man:/var/cache/man:/usr/sbin/nologin lp:x:7:7:lp:/var/spool/lpd:/usr/sbin/nologin mail:x:8:8:mail:/var/mail:/usr/sbin/nologin news:x:9:9:news:/var/spool/news:/usr/sbin/nologin uucp:x:10:10:uucp:/var/spool/uucp:/usr/sbin/nologin proxy:x:13:13:proxy:/bin:/usr/sbin/nologin www-data:x:33:33:www-data:/var/www:/usr/sbin/nologin backup:x:34:34:backup:/var/backups:/usr/sbin/nologin list:x:38:38:Mailing List Manager:/var/list:/usr/sbin/nologin irc:x:39:39:ircd:/var/run/ircd:/usr/sbin/nologin gnats:x:41:41:Gnats Bug-Reporting System (admin):/var/lib/gnats:/usr/sbin/nologin nobody:x:65534:65534:nobody:/nonexistent:/usr/sbin/nologin _apt:x:100:65534::/nonexistent:/bin/false mysql:x:101:101:MySQL Server,,,:/nonexistent:/bin/false
Code language: JavaScript (javascript)

/etc/passwd is a text-based database that has information for all user accounts on a Linux-based system. This is absolutely not a file that any unauthorized visitor of your application should be able to access, and so this basic exploit could cause serious damage.

How do you prevent Directory/Path traversals?

Because directory traversals can be exploited through vulnerable web applications, one place we need to look is in the application’s code. An attacker will submit inputs to try and find path traversal vulnerabilities, so it’s important that we verify all user input before processing it — especially if that user input will be used in code that pulls files directly from the webserver (just like we saw with the DVWA example)

A second place we need to look for directory traversal vulnerability is with the web server itself. Web servers running older versions of software may be vulnerable to this attack, so it’s important that you ensure you are running patched versions.

The way that your webserver is configured can also make a big difference. If it’s not properly configured, it may give too much flexibility that, again, enables this vulnerability.