Effective LFI and path traversal Exploitation

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.

The good ol’ ../../../ did not work so i used php wrappers. 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:

/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)
application server side code to gain a deeper understanding on the app.
N/B Access/error logs are gold as they may reveal other paths.


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
input:// stream

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.

search previous next tag category expand menu location phone mail time cart zoom edit close