Understanding local file inclusion (LFI) attacks: history, detection, exploitation and prevention
Web application weaknesses remain a major target for cyber criminal. The most dangerous - yet is still underestimated - the danger is the local file inclusion (LFI). Similar to the Remote File Inclusion (RFI), LFI involves exploiting an application to include files on the local server. When successfully exploited, attackers can get access to sensitive files, can perform arbitrary code, or even increase privileges. This article provides intensive analysis of LFI: its history, how it works, how it is exploited, how it is detected, and how to reduce risks.
What is local file inclusion (LFI)?
Local File Inclusion (LFI) is a type of vulnerability that occurs when a web application dynamically incorporates the user input without properly validing files. Instead of loading only safe, intended files, the application inadvertently provides access to local files stored on the server - such as configuration files, credentials, logs or even source code.
LFI usually affects PhP-based applications that include use (), requirement (), or similar functions.
Difference between RFI and LFI
- Remote file increment (RFI): Loading files from the remote server.
- Local File Inclusion (LFI): Loading files from local server file system.
While RFI allows attackers to inject and execute remote scripts, LFI is often used to read sensitive files - although in some circumstances, it can also carry the code execution.
A brief history of LFI attacks
LFI has been a known vulnerability for more than two decades, early PHP-based CMSs and forums like WordPress (older version), Zoomla, PhPB, and others.
- 2007–2012: A surge of LFI exploits were discovered across widely used PHP applications.
- 2014: High-profile data leaks tied to poorly configured LFI vulnerabilities hit government and educational websites.
- 2020s onward: LFI is often used in combination with other attacks such as log poisoning, PHP wrappers, and symlink attacks for greater impact.
How Does LFI Work?
A basic example of a vulnerable PHP code snippet:
php
<?php
$file = $_GET['page'];
include($file);
?>
If a user accesses the page like this:
arduino
http://example.com/index.php?page=about.php
The server includes about.php. However, an attacker can modify the URL:
bash
http://example.com/index.php?page=../../../../etc/passwd
Now the script attempts to include /etc/passwd, potentially revealing sensitive system files.
Common Targets in LFI Attacks
- /etc/passwd (Linux systems)
- /proc/self/environ (can be used for log poisoning)
- Web server logs (e.g., /var/log/apache2/access.log)
- Application source code files (e.g., config.php)
- SSH private keys
- Database connection settings
How to Detect LFI Vulnerabilities
Manual Detection:
Input Fuzzing:
Try including ../ sequences in parameters (directory traversal).
Example payload: ../../../../etc/passwd
Observe Server Responses:
Presence of strings like "root:x:0:0" indicates /etc/passwd access.
PHP warnings like failed to open stream or include() failed are clues.
Try Null Byte Injection (older PHP versions):
Example: ?page=index.php%00
Automated Tools:
- Burp Suite – Spidering and fuzzing input parameters.
- Nikto – Scans for inclusion vulnerabilities.
- OWASP ZAP – Passive and active scanning.
- Liffy – A tool specifically designed for exploiting LFI.
LFI Exploitation Techniques
LFI can be used for much more than reading files. Here’s how attackers weaponize it:
1. Sensitive File Disclosure
Access critical files like /etc/passwd, wp-config.php, .htaccess.
2. Log file injection (log poisoning)
If an attacker can inject the PHP code into a log file (eg, using user-agent header) and then using LFI to include that log, the arbitrary code can execute.
Example steps:
- Inject: <?php system($_GET['cmd']); ?>
- Include: ?page=/var/log/apache2/access.log&cmd=ls
3. PHP Wrappers
PHP has stream wrappers like php://input and php://filter that can be abused.
Example:
bash
?page=php://filter/convert.base64-encode/resource=index.php
This returns the base64-encoded source code of index.php.
4. Simlink exploitation
If the attacker has the ability to create symbolic links, they can create links to protected files and include them via LFI.
5. Remote code execution (RCE)
By combining LFI with log poisoning or upload weaknesses, attacker can convert file inclusion into code execution.
Real-World Example
Report in DVWA (Damn unsafe web app):
DVWA includes an LFI module that mimics vulnerable PHP applications:
URL:
ruby
http://localhost/vulnerabilities/fi/?page=include.php
Payload:
bash
?page=../../../../etc/passwd
The application renders the contents of /etc/passwd.
How to Prevent LFI
✅ 1. Input Validation and Whitelisting
- Only allow specific, pre-approved files to be included.
php
$whitelist = ['home.php', 'about.php'];
if (in_array($_GET['page'], $whitelist)) {
include($_GET['page']);
}
✅ 2. Avoid Dynamic Includes
- Never use user input directly in include/require functions.
- Use hard-coded file names where possible.
✅ 3. Use web app Firewall (WAF)
- Tools such as modesecurity can detect malicious inclusion efforts and block.
✅ 4. Disable Unused PHP Functions
- Disable allow_url_include and allow_url_fopen in php.ini.
ini
allow_url_include = Off
allow_url_fopen = Off
✅ 5. Keep software updated
- LFI often affects old CMS, plugins and libraries. Keep all the components up -to -date.
✅ 6. Set appropriate file permissions
- Restrictive files and access to folders using appropriate file system permissions.
How to Log and Monitor LFI Attacks
- Server Logs: Monitor for excessive ../ sequences or access to sensitive paths.
- Intrusion Detection Systems (IDS): Detect anomalies in traffic patterns.
- SIEM Platforms: Use tools like Splunk, ELK, or Wazuh to correlate LFI indicators.
LFI in Bug Bounty Programs
Many bug bounty hunters exploit LFI for cash rewards. Platforms like HackerOne and Bugcrowd often list LFI vulnerabilities in reports, especially in APIs, internal services, and development environments.
Example bounty note:
"LFI in API GET parameter allows reading /etc/passwd – Reward: $1,250"
conclusion
Local file inclusion at first glance may look less dangerous than remote file inclusion, but in practice, it can be disastrous. When other weaknesses such as inappropriate logging, poor configurations, or uploaded defects, LFI may proceed to compromise a full server.
Developers and security professionals should take LFI seriously by implementing safe coding practices, organizing regular code audit and deploying the system that detects correct monitoring and infiltration. Understanding how LFI works and takes steps to stop it, organizations can significantly reduce their attack surface.
Comments
Post a Comment