The next vulnerability that we will be looking at will be File Inclusion.
What is it?
Many website frameworks try to be generic and allow their users to include pages they have made themselves. This is done by including the page (the actual PHP script in this case) into the template page, rendering the content from that included page as if it were part of the template page.
This sounds very convenient, but what if you could trick the system into loading any page you would like? In this post we will find out how this works.
The lowest security setting should be no trouble for us. When you click on one of the files we see that the browser actually passes the filename to the
http://localhost:32770/vulnerabilities/fi/?page=file1.php and then loads the file into the page.
Lets try to load up a well known file such as
/etc/passwd. On a Linux operating system this file contains the list of users on the system, in case you didn’t know. The URL will be
Sure enough, the contents of the file is added to the top of the page as we would expect. If it is really badly implemented you could even include files from other websites, lets try my blog
Wow, it just worked! This means that low security really means no security at all. Lets level up!
Sadly we are no longer able to include my wonderful blog as a source. But what about a direct file inclusion? Lets try to include something from the application itself.
We will need to know some things about the application; in what directory is it running and what files are available? In the previous post we examined command injections, lets use them to find these things out.
|| pwd tells us we are in the directory
/app/vulnerabilities/exec. If we look at the current url for file inclusion we see the following URI:
/vulnerabilities/fi. This means that the document root is at
/app. By browsing around using
|| ls ../.. we find several interesting files in the
/app directory. Lets try to include the
README.md to see if it all works. If we use relative paths (
../../README.md) this does not work, but direct (
/app/README.md) works like a charm!
On the low level relative paths worked, so on medium security both URLs and relative paths are filtered.
Well this is a bummer, everything we previously used stopped working. For every request we are now greeted with a big fat ERROR.
We know, from the screen itself, that there are 3 files to include, lets try to increment the counter of the file. Perhaps there are other files we can take a look at?
Hey, thats nice, we found a hidden file! If we were playing capture the flag it would probably have a nice flag to score some points!
file5.php the screen turns blank. No error, nothing. That is odd, because the other files we tried to include returned an *ERROR. Lets try to fuzz the filename to see what will cause an error or a blank screen. Changing the number or increasing the filename to things like
file1more.php all yield a blank page. Lets start removing characters from the filename to see what triggers this change.
file1.php, normal page.
file1.ph, blank page.
file, blank page.
fil, error! Ok, so it seems there is something special going on with
file and anything larger!
This reminds me of the File URI Scheme which is basically the same as an URL, but then to access files. both
file:// are protocols that can be used to access information.
If we enter
file:// as the page again we are returned a blank page again, lets try
file:///etc/passwd to access the local password file.
Yes! The file is loading again as it did before!
I tried everything I know, but couldn’t figure it out. Looking at the source they whitelisted only the specific files that are to be loaded, so there seems to be no way to actually load anything else…