Types of File Inclusion
There are two types of vulnerabilities I’ll be covering in this piece! The first is Local File Inclusion, for which I’ll be providing demonstrations, and the second is Remote File Inclusion, which I’ll only be giving a brief overview of!
Local File Inclusion
A local file inclusion vulnerability allows for the reading of server operating system resources. An attacker can read local files on the OS that contain sensitive data that should not be accessible. This is done by attaching parameter query strings to a URL that can be used to retrieve data; that is, the attacker will manipulate the web application’s URL to gain access to files containing sensitive data.
Take for example the following:
In the above example, file is the parameter, and userCV.pdf is the file being accessed; the contents of userCV.pdf will be displayed in the browser. If an attacker passes another input into the function(replaces user.CV.pdf with a different file they’d like to access) they may be able to view documents not intended for the public.
This is made possible through poor coding practices of the application developer. When an attacker changes the parameter value of an HTTP request such as this, and the input is not validated before being used, it allows them to control which file is executed(displayed/accessed).
Testing For Local File Inclusion
Now that you’ve gotten an idea of what a local file vulnerability is, let’s test for one!
Let’s say there is a php application:
The first thing you’ll want to do is look for an entry point, which in this case would be /page.php?file=examplefile.txt. Assuming the server runs on Linux, here are some system files that contain sensitive data that we should attempt to access:
/etc/issue
/etc/passwd
/etc/shadow
/etc/group
/etc/hosts
/etc/motd
/etc/mysql/my.cnf
/proc/[0-9]*/fd/[0-9]* (first number is the PID, second is the filedescriptor)
/proc/self/environ
/proc/version
/proc/cmdlineA great first test would be trying to read the /etc/passwd file! Modify the parameter value in the URL like so:
If the contents to this local file are displayed to the webpage, then you would have discovered a Local File Inclusion Vulnerability!
Let’s talk PHP filters. Say you wanted to read the actual page content; the literal PHP source code. Well, you can’t just request the php file you’d like to view and have the contents displayed like in the previous example. Doing so would cause an error! This is because PHP files get executed when called in an application that supports PHP, not displayed. But the good news is, we can use PHP filters to show the contents of PHP files in a different encoding format, such as base64! So let’s apply a filter to view the contents of page.php. For Example:
This will return the source code of page.php in base64 which you can then convert to plaintext and read using a website like so www.base64decode.org
Path/Directory Traversal
Sometimes the files an attacker want access to do not exist in the same directory. If this is the case, and the web application allows for it, they can retrieve files from other directories by traversing them. This is done through the use of transversal characters! For example, you can move directories by using ../
- Each .. moves one directory until it gets to the / and then reads from the directory it is currently in.
Let’s say the current directory you are in is https://example.com/page.php?file=here/is/an/example. The following URL request is an example of how you could traverse these directories to access the /etc/passwd file.
The first .. moves the directory from /example to /an. The second .. from /an to /is. The third from /is to /here. the fourth .. moves from /here to the next directory(which would be /etc, and we don’t want to skip that one so we don’t add .. and instead include the name of the directory) and then the passwd file is accessed.
Bypassing Default Extensions
In some cases, during file inclusion, a file extension is automatically added to the end of the user input. That is, there is a function in the code of the application that specifies the file type of any user input. For example.
- Even if we request like so https://example.com/page.php?file=examplefile
On the server side, the application will read the request like so:
- https://example.com/page.php?file=examplefile.php
This poses a problem. We want access to /etc/passwd not etc/passwd.php. We can avoid the default extension by using the null byte terminator %00. Adding this terminator to the end of our user supplied data will cause the application to ignore anything coming after it, which is this case would be the add on .php
Remote File Inclusion
While I won’t be demonstrating how to take advantage of remote file inclusion vulnerabilities, I’ll be giving a brief overview to put the impact associated with file inclusion vulnerabilities into better perspective!
Remote file inclusion vulnerabilities allow attackers to gain Remote Code Execution(RCE). A malicious file is supplied as the parameter value when sending an HTTP request to the web applications server, and the contents of that file executes on the server.
What is the Risk?
To sum up, here are some of the risks associated with File Inclusion vulnerabilities:
- Leaking/exfiltration of sensitive data (including source code, password databases, or credentials for back-end systems).
- Malicious, remote code execution in the web server.
- XXS and DoS attacks!(Once RCE is achieved)
Remediation
In short, minimizing the risk of File Inclusion vulnerabilities boils down to proper user input validation and sanitation. User input should never be implicitly trusted and used without it first being validated.
That’s what I’ve learned about File Inclusion vulnerabilities so far! I hope you learned something too! Thankyou so much for reading!
Happy Hacking!
