📂Path Traversal
What is it?
Path traversal (aka Directory traversal) is a type of vulnerability that let's access data on the target system exposing sensible informations, source code and system files, so it basically is a vulnerability that can compromise the Confidentiality part of the CIA triad, leading to arbitrary file read for data exfiltration.
How to test for it?
As a general rule, whenever you spot some parameter or else in the page that let's you load file (images, scripts, documents etc) from the system or remote URLs, it's possible to try playing around with it and insert something like ../../../../etc/passwd to see what happens.
For example if the URL is something like:
https://testpage.com/home?file=image1.jpg you can see that the file=image1.jpg tries to load an image from the system, maybe in the same folder, so it's worth a try.
How to exploit it?
As said above if it's possible to load resources directly using the detected parameter, the main exploit would be playing around with it to bypass potential filters, WAFs ecc.
For example, if the test ../../../etc/passwd doesn't work, it could be possible to urlencode the special characters and try again, like:
%2e%2e%2f%2e%2e%2f%2e%2e%2fetc%2fpasswd
or for non-recursive filter bypass:
....//....//....//etc/passwd
Why this works?
This works because the character sequence ../ let's us go to the parent folder. Since in most Linux based OS we're usually in folders like: /var/www/html/<something> with the previous sequence used 3 times, we're going back 3 folders, positioning ourselves in the / (root) folder and then going on to /etc/passwd where we can find user and services accounts on the system. The mentioned above techniques for url encoding and non-recursive filter bypass could work depending on the filter used and where the parameter is, if it's in the url, both methods could work.
The first bypasses filters that tries to remove the parent directory sequence ../ because it directly encodes it, resutling in %2e%2e%2f , while the second method could work if the filter is not recursing because if the filter aims to remove the ../ string everywhere in the string just once, using ....// will end up wit a first run of the filter with ../ as result, giving us the chance to try the exploit anyway.
What's the impact?
Mainly is arbitrary file read, in some cases it's possible to even write on the target system, leading to critical attack chains.
How to mitigate?
As a rule of thumb, validating user input is always a good idea. It's important to use good filters and strong WAFs to prevent and potentially avoid every possible tentative of path traversal.
Another good technique could be using the provided data as PART of the file path, surrounding the provided input with other code or the missing part of the filename.
The use of chrooted jails also could be a great idea.
References
Last updated