Exploiting DZCP 1.3.6: Arbitrary File Upload for Remote Code Execution

What this paper is

This paper details a critical vulnerability in deV!L`z Clanportal (DZCP) version 1.3.6. It describes how an attacker can upload a specially crafted file that is both a valid image (JPEG or GIF) and executable PHP code. This allows the attacker to run arbitrary PHP code on the web server, leading to a complete compromise of the server with the privileges of the DZCP application.

Simple technical breakdown

The core of the vulnerability lies in how DZCP handles user-uploaded images. The application expects image files but doesn't sufficiently validate their content. By creating a file that tricks the server into thinking it's an image while actually containing PHP code, an attacker can bypass security checks. Once uploaded, this malicious file can be accessed and executed by the web server, effectively giving the attacker control.

Complete code and payload walkthrough

The provided exploit description doesn't include explicit code for the malicious file itself, but it outlines the method for creating it and the method for uploading and executing it.

1. Creating the Malicious File (Conceptual):

The paper states: "the attacker needs a file that is both a valid JPEG or GIF file and valid PHP (or probably other) code".

• Concept: This means crafting a file that, when opened by an image parsing function (like getimagesize()), is recognized as a valid image format (JPEG or GIF). Simultaneously, this file must contain PHP code that the web server will interpret and execute when the file is requested.
• Mechanism (as described): "Get a JPEG file, open it in a hex editor, add some PHP inside the EXIF data or in similar places."
  • EXIF Data: This is metadata stored within image files (like JPEGs) that contains information about the image, camera, settings, etc. Attackers can often embed arbitrary data within these fields.
  • "Similar places": This could refer to other metadata sections or even directly within the image data itself, as long as it doesn't corrupt the image structure to the point where it's no longer recognized as a valid image by the getimagesize() function.
• Validation Requirements:
  • PHP's getimagesize() does not return false: This function checks if a file is a valid image and returns its dimensions. The crafted file must pass this check.
  • the file does not throw parse errors or the like when fed to PHP: This implies that the PHP code embedded within the file must be syntactically correct and not cause immediate errors when PHP attempts to process the file.

2. Uploading the Malicious File:

The paper provides a curl command to demonstrate the upload process.

• Command: curl -F 'file=@img.php;type=image/jpeg' 'http://<dzcp>/upload/index.php?action=userpic&do=upload'
• Breakdown:
  • curl: A command-line tool for transferring data with URLs.
  • -F 'file=@img.php;type=image/jpeg': This is a curl option for sending multipart/form-data.
    • file: This is the name of the form field that the DZCP application expects for file uploads.
    • @img.php: This tells curl to read the content of the local file named img.php and send it as the value for the file field.
    • type=image/jpeg: This explicitly sets the Content-Type header for this part of the multipart request to image/jpeg. This is crucial for tricking the server into believing it's receiving a JPEG.
  • 'http://<dzcp>/upload/index.php?action=userpic&do=upload': This is the target URL.
    • <dzcp>: Placeholder for the vulnerable DZCP installation's hostname or IP address.
    • /upload/index.php: The script responsible for handling uploads.
    • ?action=userpic&do=upload: These are GET parameters that likely instruct the index.php script to perform a user picture upload operation.

3. Executing the Malicious Code:

The paper describes how to access the uploaded file to trigger execution.

• Access Method: "Then check http:///inc/images/uploads/userpics/.php"
• Breakdown:
  • http://<dzcp>/inc/images/uploads/userpics/: This is the expected directory where DZCP stores uploaded user pictures. The exact path might vary slightly depending on the DZCP configuration, but this is the path indicated by the paper.
  • .php: This is the critical part. The attacker uploads a file that is both an image and PHP code. The server might save it with its original filename (e.g., malicious.jpg or malicious.php). However, the paper suggests accessing it with a .php extension. This implies one of two scenarios:
    • Scenario A (Direct Execution): The uploaded file was named something like shell.php.jpg or shell.php and the server's web server configuration (e.g., Apache's AddHandler or AddType directives) is configured to execute files ending in .php regardless of their actual content or preceding extensions.
    • Scenario B (Renaming/Exploiting Upload Logic): The upload script itself might be vulnerable to renaming or might save the file with a predictable name that can then be accessed with a .php extension. The paper's phrasing "check http:///inc/images/uploads/userpics/.php" strongly suggests the server's web server configuration is set up to execute files with a .php extension. If the uploaded file was named shell.jpg but contained PHP, and the server is configured to execute .php files, the attacker would need to find a way to make the server treat it as a .php file. The paper's example img.php in the curl command suggests the attacker might name the file with a .php extension, and the server's upload handler might strip it or append an image extension, but the web server configuration still allows .php execution.
  • Execution: When the web server processes the request for http://<dzcp>/inc/images/uploads/userpics/.php, it will interpret the file as PHP code and execute it.

Payload (Implied):

The "payload" is the PHP code embedded within the crafted image file. The paper doesn't provide the exact PHP code, but it implies it would be code designed to:

• Gain Information: e.g., retrieve database credentials from configuration files.
• Host Files: e.g., upload additional malicious scripts or backdoors.
• Get a Shell: e.g., execute commands on the server via PHP functions like exec(), system(), shell_exec(), or establish a reverse shell.

Mapping List:

• PHP's getimagesize() check -> Practical Purpose: Ensures the uploaded file is recognized as a valid image, bypassing initial image validation.
• EXIF data / similar places -> Practical Purpose: The location within the file where malicious PHP code is hidden to avoid corrupting the image structure.
• curl -F 'file=@img.php;type=image/jpeg' -> Practical Purpose: The command used to upload the crafted file, masquerading it as a JPEG.
• upload/index.php?action=userpic&do=upload -> Practical Purpose: The vulnerable script and parameters on the DZCP server that handle the file upload.
• http://<dzcp>/inc/images/uploads/userpics/.php -> Practical Purpose: The URL to access the uploaded malicious file, triggering its execution as PHP code.
• PHP code within the file -> Practical Purpose: The actual malicious code that performs the desired actions on the server (e.g., command execution, data exfiltration).

Practical details for offensive operations teams

• Required Access Level: Anonymous/Unauthenticated user. The vulnerability allows execution without needing a user account.
• Lab Preconditions:
  • A running instance of DZCP version 1.3.6 (or a similar vulnerable version).
  • The web server must be configured to allow file uploads to the /upload/ directory and store userpics in /inc/images/uploads/userpics/.
  • The web server must be configured to execute files with a .php extension. This is a common configuration for PHP-enabled web servers.
  • The getimagesize() PHP function must be enabled and functional.
• Tooling Assumptions:
  • curl or a similar HTTP client for sending the upload request.
  • A hex editor (e.g., HxD, Bless, xxd) to craft the malicious image file.
  • A text editor to write the PHP payload.
  • A web browser to verify execution and interact with the compromised server.
• Execution Pitfalls:
  • Image Validation Bypass: The primary challenge is crafting a file that is both a valid image (passes getimagesize()) and contains valid PHP code without causing parse errors. This requires careful manipulation of image metadata or data.
  • File Naming/Extension: If the upload script sanitizes filenames or forces specific extensions, the attacker might need to find a way to ensure the uploaded file is ultimately accessible and executable as a .php file. The paper's .php suffix in the access URL is a strong hint.
  • Web Server Configuration: If the web server is not configured to execute .php files (e.g., it's configured to serve them as text), the exploit will fail.
  • File Size Limits: Server-side or PHP configuration limits on upload file size could prevent larger payloads.
  • Antivirus/IDS: While less common for file content inspection in 2006, modern systems might flag suspicious file structures or known malicious PHP code.
  • Path Traversal/Absolute Paths: If the upload script is vulnerable to path traversal, the attacker might be able to upload the file to a different, more desirable location than the default userpics directory. However, this specific paper focuses on the default location.
• Tradecraft Considerations:
  • Reconnaissance: Identify the DZCP version and confirm the upload functionality is present and accessible.
  • Payload Development: Develop a robust PHP payload that can achieve the desired objective (e.g., a reverse shell, a web shell for further command execution).
  • Stealth: The initial upload might be logged. The subsequent access to the .php file will also generate web server logs. Minimizing noise and cleaning logs (if possible) is crucial.
  • Post-Exploitation: Once code execution is achieved, the immediate goal is often to establish persistence, escalate privileges, and exfiltrate data.

Where this was used and when

• Context: This vulnerability was relevant to websites using deV!L`z Clanportal for managing online gaming clan communities.
• Approximate Years/Dates: Published in December 2006. The vulnerability was likely exploited in the period leading up to and shortly after its discovery. Versions affected were <= 1.3.6, with a fix in 1.3.6.1.

Defensive lessons for modern teams

• Strict Input Validation: Never trust user-supplied data. All uploaded files must be rigorously validated for both type and content.
  • File Type Validation: Don't rely solely on the Content-Type header or file extension. Perform content-based checks (e.g., magic bytes, image parsing libraries).
  • Content Sanitization: If allowing mixed content (like images with embedded metadata), ensure that executable code within metadata is stripped or neutralized.
• Secure File Upload Handling:
  • Rename Uploaded Files: Store uploaded files with randomly generated names or names that do not reveal their true content type.
  • Store Outside Web Root: If possible, store uploaded files in a directory that is not directly accessible via HTTP. Serve them through a controlled script if necessary.
  • Restrict Execution Permissions: Ensure that directories where user-uploaded files are stored do not have execute permissions for the web server.
• Principle of Least Privilege: Run web applications with the minimum necessary privileges. If DZCP was compromised, it should not have had broad filesystem access or the ability to execute arbitrary commands directly.
• Regular Patching: Keep all web applications and their dependencies updated to the latest stable versions. This vulnerability was fixed in version 1.3.6.1.
• Web Application Firewalls (WAFs): A WAF can help detect and block malicious upload attempts based on known patterns and signatures.

ASCII visual (if applicable)

+-----------------+       +-----------------+       +-----------------+
| Attacker's Host | ----> | Vulnerable DZCP | ----> | Web Server      |
| (Crafts img.php)|       | (upload/index.php|       | (executes .php) |
|                 |       |  action=userpic)|       |                 |
+-----------------+       +-------+---------+       +--------+--------+
                                  |                        |
                                  | Uploads                | Serves
                                  | Malicious File         | Executed Code
                                  v                        v
                          +-----------------+       +-----------------+
                          | DZCP Upload Dir | ----> | Malicious PHP   |
                          | (e.g., /inc/...) |       | Code Execution  |
                          +-----------------+       +-----------------+

Explanation:

• The attacker crafts a file (img.php) that is both an image and PHP code.
• They use curl to send this file to the DZCP upload script (upload/index.php).
• The DZCP script, due to insufficient validation, saves the file.
• The attacker then accesses the saved file via its web-accessible path (e.g., /inc/images/uploads/userpics/.php).
• The web server, configured to execute .php files, runs the embedded PHP code.

Source references

• Paper ID: 2876
• Paper Title: DZCP (deV!L`z Clanportal) 1.3.6 - Arbitrary File Upload
• Author: Tim Weber
• Published: 2006-12-01
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/2876
• Raw URL: https://www.exploit-db.com/raw/2876

Original Exploit-DB Content (Verbatim)

S Y N O P S I S  /
================='
-(  access: remote   severity: high  )-
deV!L`z Clanportal allows nearly arbitrary files to be uploaded and stored on
the server's filesystem, which enables anyone, even without a user account, to
upload PHP code and execute it, leading to arbitrary code execution.


B A C K G R O U N D  /
====================='
deV!L`z Clanportal (short "DZCP") is a suite of PHP scripts that allow anybody
to create a feature-rich website for her online gaming clan.


A F F E C T E D   V E R S I O N S  /
==================================='
verified on:  1.3.6
possibly vulnerable:  <= 1.3.6
fixed in:  1.3.6.1


I M P A C T  /
============='
The attacker can run own code on the web sever with the same privileges as DZCP
itself, enabling her to do almost anything from getting the MySQL password to
hosting own files and scripts or getting a shell on the server.


P R E R E Q U I S I T I E S  /
============================='
the attacker needs a file that is both a valid JPEG or GIF file and valid
PHP (or probably other) code

A B O U T   T H E   A U T H O R  /
================================='
Tim Weber, computer science student at the University of Mannheim, Germany,
currently looking for an internship at some IT security or pentesting company,
can be reached via e-mail: scy-adv-061124b at the host scytale.de.

P R O O F   O F   C O N C E P T  /
================================='
Get a JPEG file, open it in a hex editor, add some PHP inside the EXIF data or
in similar places.  Make sure PHP's getimagesize() does not return false and
that the file does not throw parse errors or the like when fed to PHP.  Then:

curl -F 'file=@img.php;type=image/jpeg' 'http://<dzcp>/upload/index.php?action=userpic&do=upload'

Then check http://<dzcp>/inc/images/uploads/userpics/.php

# milw0rm.com [2006-12-01]