Welcome back, my aspiring Cyber Warriors!
In this series--Web App Hacking--we are exploring the many ways that an attacker can compromise Web Applications. In this tutorial, we will explore using Local File Inclusion or LFI.
Many scripting languages used in web applications support the use of include() function. These make it easy for the developer to place reusable code into separate files and then call these code files when needed. The code will then be executed and interpreted just as if it had been inserted into the application at the location of the include. Numerous scripting languages have this capability including PHP, JSP, ASP, and others
An example of some PHP code that is vulnerable to LFI below.
This vulnerability is a result of inadequate input validation in the web app that allows the attacker to enter files that should not be accessible to the outsider.
LFI can be used to execute any file on the local server including configuration files and any confidential files on the system.
Let's take a look at how this works on the Damn Vulnerable Web App (DVWA) that is built into Metasploitable 2.
Step #1: Setting Up LFI into DVWA
To start, make certain that DVWA security setting are set to LOW. Next, click on the File Inclusion tab on the left.
Note that DVWA instructs you, "To include a file edit the ?page=index.php in the URL...". Before we do that, let's take a look at the source code that enables file inclusion. We can view the source code by navigating to:
<IP>/dvwa/vulnerabilities/view_source.php?id=fi&security=low
This will open a screen like that below.
Note that the source code simply accesses whatever file comes after the $file. The application provides NO input validation.
When he hit the compare button, we can see that the medium and high security code use some input validation. The high security source code is very specific and only allows only files that contain "include.php". Other options might be to white list acceptable files, file extensions or exclude directory separators such as "/".
Step #2: LFI of /etc/passwd
Let's try to access a well-known file on the Linux server, the /etc/passwd file. Although this file does not include the passwords (those are in /etc/shadow), it will reveal all the user accounts on the server.
Simply enter /etc/passwd after the page= in the URL.
As you can see, the app displayed the contents of the /etc/passwd file across the top of the DVWA page in your browser.
A similar attempt to access the /etc/shadow file results in a "permission denied" message as we do not have root privileges to access it.
Step #3: LFI on Configuration Files
On the other hand, we may be able to access other files on the system where root access is not required. For instance, we may be able to read the apache2.conf or other configuration files on the server.
Try entering the location of the apache2.conf file (/etc/apache2/apache2.conf) in the URL after page=.
As you can see, we are able to display the entire contents of the apache2.conf from the server in our browser.
Step #4: LFI on Confidential Files
Finally, we may be able to find and read files that we really should not have access to. We could explore the server looking for important or confidential files.
Here we found a confidential file named appropriately, "confidential", in the /home/msfadmin directory.
As you can see above, we were able to display in our browser the contents of this confidential file on the underlying server defeating the writer's attempt to maintain confidentiality of this file.
Conclusion
Local File inclusion (LFI) enables the attacker to display files on the underlying server that should not be available and accessible to them. This is because many languages--PHP in this example--enable the developer to use includes to reuse code files for convenience and simplicity. Without adequate input validation and santization, the attacker have be able to display in their browser the contents of otherwise inaccessible files on the server.