This will be one of the much shorter entries in the list of applied review sections because path traversal is pretty straight forward.
Even though this one is pretty simple, there are lots of different miscellaneous countermeasures and workarounds to take note of. This is also super useful if you find it in a CTF or engagement when trying to map out a web application.
What is Path Traversal?#
Path traversal, also known as directory traversal, is a vulnerability where an attacker can read arbitrary files on the underlying server that is running the application.
This data being read could be anything from application code to sensitive operating system files and even credentials in some cases.
Sometimes, depending on the circumstances, you can even write files to the system and leverage them to take control over the affected server.
Path Traversal to Read Arbitrary Files#
Before continuing, I will clarify that it helps to have some experience with the Linux file system and command line because some of the command references and file locations will be parallel to those found on a Linux box.
Imagine your buddy has a photography site that he wants you to test for security issues. Your friend is pretty good with computers and has it hosted on their personal server back home that he port-forwarded.
The website they deployed displays the images and loads them using the following HTML:
<img src="/loadImage?filename=coolpic.png">
This loadImage URL takes the filename parameter and gives back the contents of the file with the matching name. These images are actually stored in the server’s disk at /ver/www/images/.
To return the image, the web application appends the requested filename (coolpic.png) to this base directory and uses the filesystem API to read the contents of the file.
So the web application is actually reading the file path:
/var/www/images/coolpic.png
Do you see where this might cause trouble?
Your buddy hasn’t implemented any path traversal protections and as a result, we can read the contents of other files on the system:
https://coolphotography.com/loadImage?filename=../../../etc/passwd
Requesting this URL would cause the application to read from the following path:
/var/www/images/../../../etc/passwd
The ../ sequence is a valid file path which just moves you back one level in a directory. So, the three consecutive ../ character sets bring you back three directories, where you can then navigate to /etc/passwd. Which is a file that contains names of users and some other supplementary details.
On a Windows-based server, you’d probably want to use the ..\ set because the Windows command line uses backslashes instead.
Quiz 1 - HTB Inject#
This machine has us navigate to a website where you can find a /upload endpoint at the top right of the home page.
When we upload an image we are given a URL to view it:
When we navigate to that page we see a 500 error for some reason, let’s look at it in our Burp Suite repeater:
Let’s try some path traversal payloads like ../ and see what happens:
This is more promising, it looks like we can not only read file contents, but we can easily navigate through the file system because of how the web application shows us the output.
If we look around the file system, we can find a user in the /home directory called frank and in we can find another user’s password just a few files deeper:
Overall, a pretty simple example of path traversal that lets us read some files we shouldn’t be seeing.
Common Countermeasures & Workarounds#
Many applications place user input into file paths and implement defenses against path traversal attacks, but not every defense is perfect.
Sometimes applications will strip out the traversal sequence (../) from the user-supplied filenames, but depending on how the application does this, you might be able to bypass it.
For example, if the application is filtering out the ‘../’ sequence, you might be able to use an absolute file path like filename=/etc/passwd to directly reference a file.
Or, if we know that the ../ sequence is being blocked, we could try inserting ....// so that the inner ../ is removed and just leaves another ../ in its place.
Here is a bit more of a verbose demonstration:
Web application removes user input '../'
> user enters '../../../etc/passwd'
> cleaned string is '/etc/passwd' which doesn't exist in the current directory
> user enters '....//....//....//etc/passwd'
> cleaned string is '../../../etc/passwd' which would work
You also might be able to bypass other filters by URL encoding or double URL encoding the ../ sequence.
You might also encounter pages that require you to have a file extension for your parameter. this can sometimes be bypassed by including a null byte like this:
filename=../../../etc/passwd%00.png
These are only some of the possibilities you can find here and I would highly recommend looking at the page on HackTricks for more information that you could use when seeking out these vulnerabilities.
Quiz 2 - HTB Trick#
This machine first has us do some subdomain enumeration to find the preprod-marketing.trick.htb endpoint. And when navigating to the contact page we observe the following URL:
http://preprod-marketing.trick.htb/index.php?page=contact.html
We can try to perform path traversal on the page parameter like this:
http://preprod-marketing.trick.htb/index.php?page=../../../../etc/passwd
But this just returns a blank page. Let’s try another approach:
http://preprod-marketing.trick.htb/index.php?page=....//....//....//etc/passwd
This time it works and we are able to read the file with no issues, indicating that the ../ characters in the middle are being stripped from our input.
Quiz 3 - HTB BroScience#
This machine has a website where a blog of some kind is being hosted. If we look at a image we see the following URL:
https://broscience.htb/includes/img.php?path=bench.png
And if we try the following path traversal exploit:
https://broscience.htb/includes/img.php?path=bench.png../../../etc/passwd
We sill see that the page returns an error like this:
Let’s try to use some URL encoding and see if it works for us:
That didn’t seem to work, let’s try double URL-encoding and see if it works.
This seemed to work, but the page is only able to render images. If we use the curl command, we should be able to read the file with no issues:
╰─ curl -k https://broscience.htb/includes/img.php\?path\=..%252F..%252F..%252F..%252Fetc%252Fpasswd
root❌0:0:root:/root:/bin/bash
daemon❌1:1:daemon:/usr/sbin:/usr/sbin/nologin
bin❌2:2:bin:/bin:/usr/sbin/nologin
sys❌3:3:sys:/dev:/usr/sbin/nologin
sync❌4:65534:sync:/bin:/bin/sync
---SNIP---
In this case, we needed to use -k to allow insecure connections to the site but we were able to read the contents of the file!
Preventing Path Traversal Attacks#
Ideally, you avoid passing user input into the filesystem API entirely, but if that isn’t possible there are some options:
- Validate user input before processing it. Try comparing the user input to a whitelist of permitted values first. Or at least verify it against allowed characters.
- After validating input from the user, append the input to a base directory and use a platform filesystem API to interpret the path. Verify that this path is in the expected directory.
Here is an example in java of some code that you could use to do this:
File file = new File(BASE_DIRECTORY, userInput);
if (file.getCanonicalPath().startsWith(BASE_DIRECTORY)) {
// process the file
}