What is an LFI Attack?
Local File Inclusion attacks are used by attackers to trick a web application into running or exposing files on a web server. If the attack is successful, it will expose sensitive information, and in severe cases, can lead to XSS and remote code execution.
Learn more about LFI by reading this article – https://www.brightsec.com/blog/local-file-inclusion-lfi/
In this article you will learn:
- What is an LFI Attack?
- How does an LFI Attack Work
- Impact of LFI Attacks
- Real-life LFI Attack Examples
- LFI Attack Examples
- Preventing LFI Attacks
How does an LFI Attack Work
A Local File Inclusion can occur when an application includes a file as user input without properly validating it. This flaw enables an attacker to include malicious files by manipulating the input.
The following vulnerable PHP code could lead to LFI:
https://website-example.com/?page=filename.php
If there is improper input sanitization, an attacker can easily modify the input and manipulate the application into accessing unauthorized files and directories from the host server by using the “../” directive. This is known as Directory or Path Traversal:
https://website-example.com/?page=../../../../etc/test.txt
In the example above, an attacker can successfully exploit the vulnerability by replacing “filename.php” with “../../../../etc/test.txt” in the URL path and accessing the test file. This will enable the hacker to backdoor upload a malicious script on the host server. He can then use LFI to access the script.
Impact of LFI Attacks
The impact of an LFI attack can be anything from information disclosure to complete system compromise. Even if the included code is not executed, it can still give an attacker enough valuable information to be able to compromise the system.
Real-life LFI Attack Examples
Local File Inclusion is specific to your web server – a vulnerable setup could easily result in an LFI attack. We’ll take a look at some real-life LFI attack examples in order to demonstrate potential issues that you might be facing.
The most popular target for an LFI attack is a file containing usernames and passwords. If your website isn’t secured, all an attacker has to do is to use their intuition or even persistence to find what they’re looking for. So, for example:
http://www.example_target_website.com/download.php?file=document.html
For any attacker, this is a jackpot. Why? Well, to begin with, the request directly accesses the file system, and it can be changed to something arbitrary like:
http://www.example_target_website.com/download.php?file=../../../../etc/passwd
With a bit of luck, an attacker could gain access to usernames and passwords, with obvious repercussions.
Learn more in our detailed guide to file inclusion vulnerability.
Breaches enabled by LFI
Adult Friend Finder breach
Adult Friend Finder, a dating website, suffered a massive data breach back in 2016, where more than 300 million accounts were exposed and made available to online criminals.
The leaked database contained email addresses, poorly or unprotected passwords, usernames, IP addresses and browser information.
To compound matters, the database included over 15 million users who deleted their accounts, as well as users of subsidiaries the company no longer owned.
Just one month before the breach, a security researcher discovered local file inclusion vulnerabilities on the website, believed to be exploited to carry out this hack.
TimThumb breach
Back in 2011, a WordPress add-on script for image cropping and resizing, TimThumb, was used to compromise more than 1.2 million websites – and was used to gather data from databases hosted on servers that also hosted the compromised websites. Unlike the many mass compromises that were accomplished via SQL injection at that time, this attack took advantage of a local file inclusion vulnerability that allowed attackers to insert PHP shells onto Web servers. Attackers used those shells as the jumping-off point for other attacks, including database hacks.
Notable LFI Vulnerabilities
RedHat website
RedHat fixed multiple security issues on their website back in 2013. The issues allowed attackers to extract the website database by using Blind SQLi. RedHat also confirmed their website was vulnerable to XSS and LFI attacks.
Weather.gov
In 2012, Kosova Hacker’s Security group used a local file inclusion vulnerability in weather.gov to gather sensitive server information of “The National Weather Service”. The group later made that information available to the public.
Whatsapp Media Server
Back in 2013, Whatsapp media server interface was vulnerable to Traversal Local File Inclusion. The flaw allowed hackers to gather usernames via an “/etc/passwd” file and also other sensitive files like log files i.e. “/apache/logs/error.log” or “/apache/log/access.log”.
Related content: Read our guide to lfi attack.
LFI Attack Examples
LFI Attack Example 1: Including files to be parsed by the language’s interpreter
Modern website code is usually divided into directories, multiple files, etc., ideally separated into logical pieces. For an interpreter to be able to find these files, the correct file path has to be designated and then passed to a function. The function will then open the file and include it inside the document, for the parser to see it as valid code that can be interpreted.
To include a module, a developer will use the GET parameter with the filename of the function. For example:
https://example-vulnerable-website.com/?module=contact.php
If improper filtering is implemented the attacker can exploit the local file inclusion vulnerability by replacing contact.php with the path of a sensitive file such as a passwd file. The passwd file is where passwords are stored on a Unix system. By replacing the path, the attacker will be able to see the content of the passwd file:
https://example-vulnerable-website.com/?module=/etc/passwd
But this will not only allow the attacker to see the content of the file. An attacker can also inject code on the web server and let the parser interpret it as instructions to exploit the LFI vulnerability. For Example, an attacker can simply abuse the picture upload functionality with an image containing malicious code in its source, such as:
https://example-vulnerable-website.com/?module=uploads/image123.gif
When exploiting a local file inclusion vulnerability, an attacker can also perform directory traversal or path traversal attacks. For example, the attacker can access other files on the web server, such as web server log files (e.g. error.log and access.log) or other files that may contain sensitive metadata about the web application and web server.
LFI Attack Example 2: Including files that are printed to a page
Sometimes a developer needs to share the output of a file across multiple pages. This file could be plain html that doesn’t have to be interpreted by any parser on the server side.
Imagine the developer having a collection of .txt files with help text that he wants to make available through a web application. He can reach those files through a link:
https://example-vulnerable-website.com/?helpfile=login.txt
The content will be printed directly on the web page without using a database to store the information.
When no proper filtering is implemented, an attacker can change the link to something like https://example-vulnerable-website.com/?helpfile=../secret/.htpasswd to retrieve the password hashes of a .htpasswd file. The .htpasswd file usually contains the credentials of all users, including those that have access to restricted areas of the web server.
This can lead to the attacker being able to access and read the content of other hidden configuration files containing passwords and other sensitive information.
LFI Attack Example 3: Including files that are served as downloads
There are types of files that all web browsers open automatically – a PDF, for example. If the developer wants the pdf file to be downloaded instead of opened in the browser, he can simply add the header Content-disposition: attachment; filename=file.txt to the request. This will force the web browser to download the files instead of opening them.
Now imagine a company having brochures in pdf format available for download by using this link:
https://example-vulnerable-website.com/?download=brochure.pdf
If no proper sanitization of the request is implemented, the attacker can request the download of files that make up the web application – enabling them to read source code and eventually find other web application vulnerabilities or read sensitive file contents. The same function can be used by the attacker to read the source code of the file connection.php:
https://example-vulnerable-website.com/?download=../include/connection.php
If the attacker is able to find the database user, their passwords and the host, they can connect to the database remotely with the stolen credentials. If the compromised database user has file write privileges, the hacker can execute database commands and compromise the web server.
Preventing LFI Attacks
The recommended approach to eliminate the risk of LFI attacks is to disallow or prevent user-submitted input from being passed to any filesystem or framework API in your application. If that is not possible and you need that functionality, then make sure all user-input is properly sanitized.
Here are a few easy steps you can take to prevent LFI attacks:
- ID assignation – always save your file paths in a secure database. Give an ID for every single one. By doing so, users only get to see the ID
- Whitelisting – ignore everything that is not a verified and secured whitelist file
- Use databases – use a database instead of including files on a web server that can be compromised
- Better server instructions – configure the server so it sends the download headers automatically instead of executing files in a specified directory
Detecting LFI vulnerabilities with Bright
With Bright you can easily scan your web applications and APIs for security vulnerabilities, including local file inclusion.
Whether as a stand alone scanner or integrated across your CI/CD so developers can own security testing, Bright automatically validates every finding, delivering no false positive results with developer friendly remediation guidelines to find and fix issues early and often.
Start scanning your applications and APIs today, with a FREE Bright account – sign up here!
