Lets first start by defining these two very similar vulnerabilities.
Path Traversal
When developers do not properly implement the right access controls to files and directories, a web application may be subject to path/directory traversal attacks. This could enable an attacker to retrieve files they are unauthorized to.
Local File Includes
This exploits the applications ability to include certain files in is inherent functionality, allowing reading and executing files on the web server.
This said, it is a proper deduction that path traversal is a subset of LFI.
The Bad
So we can read files and navigate to directories we were not supposed to, big WOW.
However the issue comes with the ability to:
- Read Source code
- Read files outside the web servers application root.
Deep Dive
In a previous engagement, i located an interesting file include.php that gave a blank/white page with nothing to display.
Passing this path to arjun to detect possible get parameters, i noticed a parameter “view” returned a different content-length. With the message “incorrect path to csv document”. I guessed this was used to process or parse some csv files that had been uploaded to the server.
My next instinct was to read the index.php file’s source code. From the simple include, i got the page’s action and not the source code.
This is were the old fashion php wrappers come to the rescue. Over the past couple of years, i learnt that abusing wrappers are a crucial buddy when exploiting LFIs to read files contents. “php://filter/convert.base64-encode” to be specific.
How this works is the filter enables the application to read a resource and pass it to a handler as a base64 encoded entity.
Using curl we can decode this easily to obtain file contents. If it’s a HTML tagged output, pup can be used to process and display this properly.
In some cases, there is need to demonstrate the impact of such a bug. LFI can be leveraged to read files outside the application’s root.
Simple payloads like the proverbial “../../../../../../../etc/passwd” can be applied as a PoC. This can be done directly on the browser address bar or still by abusing the php filter.
Some common files you want to try read may be:
- /etc/hosts
- /var/logs/access.log (depending on the web server)
- /var/logs/error.log (depending on the web server)
- /var/logs/php_error.log (depending on the web server)
- proc/self/environ
- /var/log/messages
- /var/log/vsftpd.log
- /var/log/sshd.log
- /var/log/mail
- application server side code to gain a deeper understanding on the app.
N/B Access logs are gold as they may reveal other paths.
LFI to RCE
In some rare cases an LFI can be escalated to a sweet RCE. A very good display of such a vulnerability is the Tomcat “GhostCat” [CVE-2020–1938].
Some filters if enabled, can also lead to RCEs. They may include:
- upload forms/functions
- expect://command
- php://file
- input:// stream
- php://filter
I was however unable to leverage on the input:// stream for this engagement. The Apache process also did not seem to have the other filters enabled.
Since i also had access to some logs, i tried log poisoning to achieve RCE to no avail. However, i have encountered cases where this is possible
and i advice to always give this a try.