LFI Log Poison

Local File Inclusion (LFI) combined with log poisoning is a powerful attack chain that can escalate from information disclosure to remote code execution. LFI vulnerabilities occur when web applications include files from the server's filesystem based on user-controlled input without proper validation. When attackers chain LFI with log poisoning techniques, they can inject malicious code into server log files and then include those logs through the LFI vulnerability to achieve code execution.

Understanding Local File Inclusion

LFI vulnerabilities arise when applications use user input to construct file paths for dynamic includes. A common pattern involves a page parameter like page=dashboard that the application translates to a file path for inclusion. If the application does not properly sanitize this input, attackers can use directory traversal sequences (../) to break out of the intended directory and read arbitrary files on the server, such as /etc/passwd, application configuration files, or server logs.

How Log Poisoning Works

Log poisoning leverages the fact that web servers record request details - including User-Agent headers, URLs, and other client-controlled data - into log files. An attacker sends a request with malicious code (such as PHP code) injected into the User-Agent header. The web server writes this code into its access log file. When the attacker then uses the LFI vulnerability to include the log file, the web server processes the injected code, achieving remote code execution. This technique transforms a read-only file inclusion into full server compromise.

Attack Chain in Practice

A typical LFI-to-RCE attack through log poisoning follows a methodical process: first, the attacker confirms the LFI vulnerability by reading known files. Next, they identify the location of server log files (commonly /var/log/apache2/access.log or /var/log/nginx/access.log). They then inject a code payload through an HTTP header that gets logged. Finally, they include the poisoned log file through the LFI vulnerability to execute their code. This attack chain demonstrates how seemingly minor vulnerabilities can be chained for devastating impact.

Prevention and Detection

Defending against LFI and log poisoning requires multiple layers of security. Applications should use whitelists for file includes rather than relying on blacklists or sanitization. Input validation must prevent directory traversal sequences. Web server configurations should restrict the PHP engine from processing log files. File permissions should limit which files the web application process can read. Security monitoring should alert on unusual file access patterns and suspicious log entries containing code-like patterns.