2 Path Traversal Cases

March 29, 2020

Title

Directory traversal (also known as file path traversal) is a web security vulnerability that allows an attacker to read arbitrary files on the server that is running an application. In this post, two path traversal bugs will be shown. Endpoints are redacted to deny information leaks.

Path traversal in a statistic email

After enumeration and directory bruteforcing, an endpoint appeared https://redacted.com/act. In this endpoint, there was an input text element that asked form some code.

Let’s try a random code to check how the backend handles the input, maybe some information could be retrieved like code length, reflection of the input that could be vulnerable to XSS, vulnerable to SQLi, etc.

Okey, there is no captcha or something that could slow down the bruteforcing process, therefore we could use Burp’s Intruder to try to find some valid code and see if we can unlock some extra functionality.

Title

Perfect, 2 valid codes. Once entered, an email is asked. Let’s enter our email.

Title

Awesome, email’s domain is not checked against a whitelist so we could retrieve information associated to these codes, but… this is not a potential vulnerability.

Let’s analyze the final request:

POST /act/ HTTP/1.1
Host: redacted.com
...

prevEntered=445856&email=myemail%40domain.com&emailSubmit=Submit

And try to play with the prevEntered parameter:

prevEntered=445856'&email=myemail%40domain.com&emailSubmit=Submit

Title

Interesting, is the backend vulnerable to SQLi? After trying some logical querys like ' or 'l'='l, ' and 'l'='l'--, etc, I could determine that maybe is not vulnerable to SQLi.

But, what if the application is not using a database to retrieve that information? Maybe this code is matched with and existing file in the filesystem. Therefore trying:

prevEntered=../../../../../../../../../../../../etc/passwd&email=myemail%40domain.com&emailSubmit=Submit

Gave us:

Title

Path traversal in a video player

After navigating and following the logical flow of an endpoint, a video appeared. Normally, I use to ignore videos because they are loaded from third-party websites or they are in an static web folder. But after playing the video, the following traffic was shown:

GET /videos/2020/video1/video-1300Kbps/ HTTP/1.1
Host: redacted.com

And a lot of binary data was returned in the response. This could indicate that the backend is grabbing the video and performing some bandwith or video size limitation according.

After adding some ../ characters the response returned File not found."

What would happen if we add the following to the request?

GET /videos/2020/video1/video-1300Kbps/../../../../etc/passwd HTTP/1.1
Host: redacted.com

Response:

HTTP/1.1 200 OK
Accept-Ranges: bytes
Content-Type: text/plain

XXXXXX:x:23511:65534::/dev/null:/usr/bin/rssh
XXXXXX:x:23511:65534::/dev/null:/usr/bin/rssh
XXXXXX:x:23511:65534::/dev/null:/usr/bin/rssh

Lessons learned

1. Try to unlock the most of the application’s functionality possible. This will increase the attack vector.
2. If some endpoint seems vulnerable but we can not achieve a succesfull attack, maybe the attack is wrong. Think outside the box.
3. Try to interact with all the elements of the application. In this case, a web player was vulnerable to Path Traversal.