LOCAL/REMOTE FILE INCLUSION ATTACK
1 - File Inclusion
- A File Inclusion vulnerability is a type of vulnerability that is most commonly found to affect web applications that rely on a scripting runtime.
https://en.wikipedia.org/wiki/File_inclusion_vulnerability
- This issue is caused when an application builds a path to executable code using an attacker controlled variable in a way that allows the attacker to control which file is executed at run time.
- Successful exploitation of a File Inclusion vulnerability will result in remote code execution on the web server that runs the affected web application.
- A File Inclusion vulnerability is distinct from a generic Directory Traversal attack, in that directory traversal is a way of gaining unauthorized file system access, and a file inclusion vulnerability subverts how an application loads code for execution.
- Depending on how the File Inclusion is performed we can difference between Local and Remote File Inclusion.
2 - Local File Inclusion (LFI)
- Layout for this exercise:
- LFI vulnerabilities allow an attacker to read and even sometimes execute files on the victim machine.
- This can be very dangerous because if the web server is misconfigured and running with high privileges, the attacker may gain access to sensitive information.
- If the attacker is able to place code on the web server through other means, then they may be able to execute arbitrary commands.
- Let's see a couple of LFI examples using DVWA.
- First, right clicking on Upload tab and going to Inspect Element:
- Changing the allowed maximum file sizes to be uploaded:
2.1) Example 1: uploading a file
- Uploading a picture:
- The file uploading is successful, providing us with the path:
- Now, going to the browser and crafting the URL in this way the picture can be accessed:
2.2) Example: uploading and executing a wbshell PHP script
- web shells are small programs or scripts that can be uploaded to a vulnerable server and then opened from the browser to provide a web based interface to run system commands, so they are basically backdoors that run from the browser.
- For a given web server, the web shell script must be in the same language that the web server supports or is running (php, asp, jsp etc).
- Uploading to DVWA the webshell c99.php:
- The uploading is successful:
- Now, crafting an URL in this way:
- The result is that c99.php is executed, giving access to control the machine:
- For instance, running cat command the /etc/passwd is displayed:
3 - Remote File Inclusion
- Remote File Inclusion (RFI) occurs when the web application executes a remote file.
- The layout of this part of the exercise would be different because two devices are needed:
- To perform this attack we must take into consideration that the PHP language (DVWA runs on PHP) has a directive which, if enabled, allows filesystem functions to use a URL to retrieve data from remote locations.
- The directives is allow_url_fopen in PHP versions <= 4.3.4 and allow_url_include since PHP 5.2.0. In PHP 5.x this directive is disabled by default, in prior versions it was enabled by default.
- Let's notice that our DVWA web application have enabled both directives, located at the php.ini file:
- In this case the URL must be crafted in a different way than when LFI.
- The include.php section is replaced with the remote URL where the webshell script is stored:
- Entering the crafted URL the webshell c99.php is again executed:
4 - PHP include() function vulnerability
- Now that we have performed some examples of File Inclusion attacks, let's examine what are the reasons of these vulnerabilities at the DVWA web application.
- As said before DVWA is a PHP/MySQL web application.
- In PHP the main cause of vulnerabilities are due to the use of unvalidated user input with a filesystem function that includes a file for execution.
- For instance, functions prone to be vulnerable are include() and require().
- include() statement includes and evaluates a file that is passed to as a parameter by the input user.
- To exploit the include() vulnerability an attacker will alter a variable that is passed to one of these functions to cause it to include malicious code from a remote resource.
- To mitigate this vulnerability all user input needs to be validated before being used.
- Going to the DVWA web application, on the File Inclusion page, clicking on the View Source button the following source code is available:
- This code is not vulnerable by itself, it just take the input $file and prepends http/https.
- However, going to the index.php file of the DVWA application, at line 35 we find that the include() PHP function takes $file as parameter without further sanitization:
- This code is vulnerable because there is no sanitization of the user-supplied input.
- Specifically, the $file variable is not being sanitized before being called by the include() function.
