How to remediate – Magento Cacheleak

1. Introduction

Magento Cacheleak is a vulnerability affecting Magento 1 installations where cache files are stored in publicly accessible directories with misconfigured authorisation on the /var directory. This allows attackers to access sensitive information, potentially including database credentials. Affected systems typically include e-commerce websites running unpatched or improperly configured Magento 1 instances. A successful exploit could lead to data breaches and compromise of website functionality.

2. Technical Explanation

The vulnerability stems from predictable filenames used for cache files stored within the public directory, combined with insufficient access controls on the /var directory containing these files. An attacker can directly request these files via HTTP, potentially exposing configuration data. The root cause is an insecure default configuration and missing restrictions on file access.

• Root cause: Misconfigured authorisation for the /var directory allows public access to cache files.
• Exploit mechanism: An attacker can enumerate and request cache files directly via HTTP, exposing sensitive data like database login credentials. For example, an attacker could attempt to retrieve a file containing configuration information by guessing its filename based on known patterns.
• Scope: Magento 1 installations are affected.

3. Detection and Assessment

To confirm vulnerability, check directory permissions and access controls. A quick check involves listing files in the public directories. Thorough assessment requires reviewing server configuration for open access to /var.

• Quick checks: Use a web browser or `ls -l` command on the Magento installation’s public directories (e.g., `/pub/static`, `/pub/media`) to check file permissions and ownership.
• Scanning: Nessus plugin ID 16729 can detect this vulnerability, but results should be verified manually.
• Logs and evidence: Examine web server access logs for requests targeting files within the /var directory or cache directories. Look for unusual activity or attempts to access configuration files.

ls -l /pub/static

4. Solution / Remediation Steps

Fix this issue by restricting directory listing and blocking access to the /var directory. These steps should be performed in a controlled environment.

4.1 Preparation

• Ensure you have SSH access to the server and appropriate permissions. A roll back plan involves restoring the backup.
• A change window may be required depending on your environment. Approval from a security team is recommended.

4.2 Implementation

1. Step 1: Prevent directory listing for all Magento public directories by adding an appropriate index file (e.g., `index.html`) to each directory.
2. Step 2: Restrict access to the /var directory using web server configuration files (e.g., `.htaccess` or virtual host settings).
3. Step 3: Block direct access to the /var directory and its content via firewall rules if possible.

4.3 Config or Code Example

Before

# No restrictions on /var directory in .htaccess

After

<Directory /var>
  Order deny,allow
  Deny from all
</Directory>

4.4 Security Practices Relevant to This Vulnerability

Several security practices can help prevent this issue. Least privilege reduces the impact of exploitation. Secure configuration prevents misconfigurations that expose sensitive data.

• Practice 1: Implement least privilege by granting only necessary permissions to users and processes.
• Practice 2: Enforce secure configurations through automated checks and regular audits.

4.5 Automation (Optional)

# Example Bash script to add index.html files to public directories
for dir in /pub/static /pub/media; do
  touch "$dir/index.html"
done

5. Verification / Validation

Confirm the fix by checking directory listing and access controls again. Re-test the earlier detection method to verify the issue is resolved.

• Post-fix check: Use a web browser or `ls -l` command on the Magento installation’s public directories (e.g., `/pub/static`, `/pub/media`) and confirm directory listing is disabled.
• Re-test: Attempt to access files within the /var directory via HTTP; you should receive an error message indicating access is denied.
• Smoke test: Verify core website functionality, such as product browsing and checkout, remains operational.
• Monitoring: Monitor web server logs for any attempts to access the /var directory or cache files.

ls -l /pub/static

6. Preventive Measures and Monitoring

Update security baselines and implement CI/CD checks to prevent similar issues. A regular patch cycle ensures timely updates.

• Baselines: Update a security baseline or policy to include restrictions on directory listing and access controls for web server directories.
• Pipelines: Add static code analysis (SAST) tools to your CI/CD pipeline to identify potential configuration vulnerabilities.
• Asset and patch process: Implement a regular patch cycle for Magento 1, including security updates and configuration reviews.

7. Risks, Side Effects, and Roll Back

• Risk or side effect 1: Incorrectly blocking access to /var may cause unexpected errors or website malfunctions. Mitigation involves carefully reviewing the configuration and testing thoroughly.
• Risk or side effect 2: Adding index files could interfere with other applications or services running on the server. Mitigation involves ensuring compatibility and proper file placement.
• Roll back: Remove the added index files and restore the original web server configuration from backup.

8. References and Resources

• Vendor advisory or bulletin: https://royduineveld.nl/magento-cacheleak-exploit/
• NVD or CVE entry: No specific CVE is associated with this vulnerability, but it’s related to CWE-16.
• Product or platform documentation relevant to the fix: Magento File System Permissions