Exploiting Joomla's com_oziogallery2: Arbitrary File Write

What this paper is

This paper details a vulnerability in the com_oziogallery2 component for Joomla!, specifically within its imagin script. The vulnerability allows an attacker to write arbitrary files to the web server's filesystem by manipulating two POST parameters: path and raw_data. This can lead to various malicious outcomes, including code execution.

Simple technical breakdown

The core of the vulnerability lies in a PHP script (writeToFile.php) that doesn't properly sanitize user input for file paths.

1. The script takes a path and raw_data from a POST request.
2. It constructs a full file path by prepending ../../ to the provided path. This is a common technique to traverse up the directory structure.
3. It attempts to open this constructed file path in write mode ('w').
4. If successful, it writes the content of raw_data (after removing backslashes) into the file.
5. Finally, it closes the file.

Because the path parameter is not validated, an attacker can specify a path that points to any location on the server that the web server process has write permissions for.

Complete code and payload walkthrough

The provided code snippet is the vulnerable part of the writeToFile.php script.

<?php
// Vulnerable code snippet from /scripts_ralcr/filesystem/writeToFile.php

$file = "../../".$_POST["path"]; // Constructs the file path

$fh = fopen ($file, 'w') or die("error::Can't open file for writing"); // Opens the file for writing
echo fwrite ($fh, stripslashes($_POST["raw_data"])); // Writes data to the file

fclose($fh); // Closes the file
?>

Let's break down each meaningful part:

• $file = "../../".$_POST["path"];

  • Purpose: This line constructs the target file path.
  • Inputs: It takes the value of the path parameter from the incoming HTTP POST request ($_POST["path"]).
  • Behavior: It concatenates the string "../../" to the beginning of the user-supplied path. The "../../" is a directory traversal sequence, meaning it tells the system to go up two directory levels from the current script's location.
  • Output: The resulting string is stored in the $file variable, representing the absolute or relative path to the file the script will attempt to write to.

• $fh = fopen ($file, 'w') or die("error::Can't open file for writing");

  • Purpose: This line attempts to open the file specified by $file for writing.
  • Inputs: The $file variable (constructed in the previous step) and the mode 'w'.
  • Behavior:
    • fopen($file, 'w'): Tries to open the file at the path stored in $file. The 'w' mode means:
      • If the file exists, its contents will be truncated (deleted).
      • If the file does not exist, it will be created.
      • The file is opened for writing only.
    • or die(...): If fopen fails (e.g., due to insufficient permissions or the path not existing in a way that allows creation), the script will terminate immediately and display the error message "error::Can't open file for writing".
  • Output: If successful, it returns a file pointer resource, which is stored in the $fh variable. This resource is used for subsequent file operations.

• echo fwrite ($fh, stripslashes($_POST["raw_data"]));

  • Purpose: This line writes the attacker-supplied data into the opened file.
  • Inputs:
    • $fh: The file pointer resource obtained from fopen.
    • stripslashes($_POST["raw_data"]): The value of the raw_data parameter from the incoming HTTP POST request, with any backslashes stripped. stripslashes is often used to counteract the effect of PHP's magic_quotes_gpc setting, which automatically adds slashes to certain characters.
  • Behavior:
    • stripslashes(...): Removes backslashes from the input string. This is important because if the attacker wants to write code that contains quotes (e.g., <?php echo 'hello'; ?>), they might need to escape those quotes. stripslashes helps ensure the raw data is written as intended.
    • fwrite($fh, ...): Writes the processed data to the file pointed to by $fh.
  • Output: The number of bytes successfully written to the file. This number is then echoed back to the attacker, confirming the write operation's success and size.

• fclose($fh);

  • Purpose: This line closes the file pointer.
  • Inputs: $fh, the file pointer resource.
  • Behavior: It flushes any buffered data to the file and releases the file handle. This is good practice to ensure data is written and resources are freed.
  • Output: Returns true on success or false on failure.

Mapping list:

• $file = "../../".$_POST["path"]; -> Constructs the target file path, enabling directory traversal.
• fopen ($file, 'w') -> Attempts to create or overwrite a file at the constructed path.
• stripslashes($_POST["raw_data"]) -> Prepares the attacker's payload by removing potential escape characters.
• fwrite ($fh, ...) -> Writes the attacker's payload into the target file.
• fclose($fh); -> Finalizes the file write operation.

Payload:

The "payload" in this context is the content of the raw_data POST parameter. For example, an attacker would send a POST request with:

• path: ../../../../path/to/webroot/backdoor.php (or similar, depending on the server's structure and the script's location)
• raw_data: <?php phpinfo(); ?> (or malicious PHP code for a backdoor)

The script would then create a file named backdoor.php in the specified webroot directory containing the phpinfo() function (or the malicious code).

Practical details for offensive operations teams

• Required Access Level: Unauthenticated access to the vulnerable Joomla! site. The vulnerability is exposed via a POST request to a publicly accessible script.
• Lab Preconditions:
  • A target Joomla! installation with the com_oziogallery2 component installed.
  • The imagin/scripts_ralcr/ directory must be accessible and contain writeToFile.php.
  • The web server process must have write permissions to the target directory where the attacker intends to place their file. This is the most critical prerequisite. Common targets include:
    • The Joomla! root directory (if writable).
    • The images or media directories.
    • Temporary directories.
    • Any custom directories the component might create or use.
• Tooling Assumptions:
  • A web browser for manual testing or reconnaissance.
  • An HTTP client tool like curl or Burp Suite (or its Intruder module) for crafting and sending POST requests.
  • A proxy tool like Burp Suite or OWASP ZAP is highly recommended for intercepting, modifying, and replaying requests.
• Execution Pitfalls:
  • Incorrect Path Traversal: The ../../ sequence might need adjustment based on the exact location of writeToFile.php relative to the desired write location. For example, if writeToFile.php is in /components/com_oziogallery2/imagin/scripts_ralcr/ and the target is /images/, the path might need to be ../../../images/webshell.php.
  • File Permissions: The most common failure point. If the web server process cannot write to the target directory, fopen will fail, and the exploit will not work.
  • Web Server Configuration: Some web servers might have security configurations (e.g., open_basedir in PHP) that restrict where PHP scripts can write files, even if the OS permissions would otherwise allow it.
  • WAF/IDS Evasion: Modern Web Application Firewalls (WAFs) or Intrusion Detection Systems (IDS) might flag suspicious POST requests containing directory traversal sequences (../) or common shellcode patterns. Encoding or obfuscation might be necessary.
  • File Overwriting: The 'w' mode truncates existing files. If an attacker targets an important file, they risk disrupting the site. It's generally safer to write to non-critical locations or create new files.
  • Payload Detection: Antivirus or security software on the server might detect common PHP webshells if they are written to disk.
• Tradecraft Considerations:
  • Reconnaissance: Thoroughly map the Joomla! installation's directory structure and identify writable directories. Look for common web shell drop locations.
  • Staged Payloads: Instead of writing a full, complex shell directly, consider writing a small PHP script that downloads and executes a more sophisticated payload from an attacker-controlled server. This can help evade signature-based detection.
  • Obfuscation: If the raw_data is detected, consider encoding it (e.g., base64) and then using PHP functions like base64_decode within the payload to reconstruct the original code.
  • Timing: Be mindful of when the write operation occurs. If the target site is heavily monitored, performing the write during off-peak hours might reduce the chance of immediate detection.
  • Cleanup: If the objective is to maintain persistence, the attacker might need to remove the writeToFile.php script or the exploit script itself after successful exploitation, or ensure their dropped payload is self-sufficient.

Where this was used and when

• Context: This vulnerability was specific to the com_oziogallery2 component in Joomla!. It was likely used by attackers targeting Joomla! websites running this particular component.
• When: The paper was published in January 2010. Therefore, this vulnerability was actively exploitable around that time and likely for some period afterward until the component was patched or removed. Exploits of this nature are often discovered and weaponized shortly after their public disclosure.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user input, especially when it's used in file system operations. Always validate and sanitize paths, ensuring they conform to expected patterns and do not contain traversal sequences (../, ..\).
• Principle of Least Privilege: Ensure the web server process only has write permissions to directories that are absolutely necessary for its operation (e.g., cache, upload directories). Avoid granting broad write access to the entire web root.
• Component Security Audits: Regularly audit third-party components and extensions for security vulnerabilities. Keep them updated to the latest versions, as vendors often patch such issues.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common attack patterns like directory traversal, SQL injection, and cross-site scripting.
• File Integrity Monitoring (FIM): Implement FIM solutions to detect unauthorized file creation, modification, or deletion within the web root and critical system directories.
• Secure Coding Practices: Educate developers on secure coding principles, emphasizing the dangers of insecure file handling and the importance of input validation.
• PHP Configuration: Review PHP configurations like open_basedir to restrict the directories PHP scripts can access, limiting the impact of file system vulnerabilities.

ASCII visual (if applicable)

This exploit doesn't lend itself to a complex architectural diagram. It's a direct interaction with a vulnerable script. However, we can visualize the data flow:

+-----------------+      HTTP POST Request      +-------------------------------------+
| Attacker System | --------------------------> | Web Server (Joomla! Site)           |
|                 |                             |                                     |
| (Crafted Data)  |                             | +---------------------------------+ |
| - path=../../...|                             | | /components/com_oziogallery2/   | |
| - raw_data=PHP  |                             | |   imagin/scripts_ralcr/         | |
|   code          |                             | |     writeToFile.php               | |
+-----------------+                             | +---------------------------------+ |
                                                |         |                         |
                                                |         | (Reads $_POST vars)     |
                                                |         v                         |
                                                | +---------------------------------+ |
                                                | | $file = "../../" . $_POST["path"];| |
                                                | | $fh = fopen($file, 'w');         | |
                                                | | fwrite($fh, stripslashes(...));  | |
                                                | | fclose($fh);                    | |
                                                | +---------------------------------+ |
                                                |         |                         |
                                                |         | (Writes to disk)        |
                                                |         v                         |
                                                | +---------------------------------+ |
                                                | | Target File on Server's Disk    | |
                                                | | (e.g., /var/www/html/shell.php) | |
                                                | +---------------------------------+ |
                                                +-------------------------------------+

Source references

• Paper ID: 10979
• Paper Title: Joomla! Component com_oziogallery2 / IMAGIN - Arbitrary File Write
• Author: Ubik & er
• Published: 2010-01-03
• Paper URL: https://www.exploit-db.com/papers/10979
• Raw Exploit URL: https://www.exploit-db.com/raw/10979

Original Exploit-DB Content (Verbatim)

# Exploit Title: Joomla component com_oziogallery2 / IMAGIN arbitrary file write
# Date: 01-01-10
# Author: Ubik and er
# Software Link: oziogallery.joomla.it / imagin.ro
# Version: all
# Disclaimer : all the information in this document is provided "as is", for educational purposes only. The authors will not be responsible for any damage.

technical information
---------------------
We can find this obviously flawed code in /scripts_ralcr/filesystem/writeToFile.php:

*************************
$file = "../../".$_POST["path"];

$fh = fopen ($file, 'w') or die("error::Can't open file for writing");
echo fwrite ($fh, stripslashes($_POST["raw_data"]));

fclose($fh);
*************************

An attack can be easily performed by manipulating the parameters (path and raw_data).
Probably other php files in scripts_ralcr are coded without any care about security.
In Oziogallery the vulnerable files are located in /components/com_oziogallery2/imagin/scripts_ralcr/.