CVE-2024-25619

Executive Summary

CVE-2024-25619 is a security vulnerability in Mastodon, a free, open-source social network server. The issue arises from a failure to notify the streaming server when an OAuth Application is destroyed. Due to the use of dependent: delete_all in the Doorkeeper relationship between Applications and Access Tokens, the after_commit callback on AccessTokenExtension is not triggered, leaving Access Tokens active on the streaming server. This could allow a malicious application to continue listening to the streaming API after the application has been revoked by the user. The vulnerability has a low CVSS score of 3.1, as it requires the attacker to have control of an application owned by the user. The fix involves adding a before_destroy callback to ApplicationExtension to explicitly revoke all associated tokens on the streaming server.

Supply Chain & Package Security

This vulnerability is in the Ruby on Rails application Mastodon, which uses the Doorkeeper gem for OAuth. The issue is not a supply chain attack but a logic flaw in the application's use of the gem. The fix is implemented in the Mastodon codebase itself, not in a dependency.

CVSS Breakdown & Threat Level

• CVSS Score: 3.1 (Low)
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) - The attacker must have control of an OAuth application owned by the user.
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: Low (C:L) - Potential for continued access to streaming data.
• Integrity Impact: None (I:N)
• Availability Impact: None (A:N)

The low severity reflects the requirement that the attacker already controls a legitimate application. However, the vulnerability could be exploited in a scenario where a user revokes an application but the attacker retains access to the streaming API.

Deep Dive & Mechanics

Mastodon uses OAuth 2.0 for third-party application access. When a user authorizes an application, an Access Token is created and the streaming server is notified to allow the application to listen to real-time events (e.g., new posts, notifications). When the user destroys the application (e.g., via the settings page), the expectation is that all associated Access Tokens are revoked and the streaming server is notified.

The vulnerability lies in the use of dependent: delete_all in the Doorkeeper model relationship. This configuration deletes associated records directly from the database without triggering ActiveRecord callbacks. Specifically, the after_commit callback on AccessTokenExtension, which would normally notify the streaming server, is not executed. As a result, the streaming server continues to accept connections from the revoked tokens.

The fix introduces a before_destroy callback on ApplicationExtension. This callback explicitly announces to the streaming server that all Access Tokens for the application are being "killed" before the application record is destroyed. This ensures that the streaming server is always informed, regardless of how the tokens are deleted.

Vulnerable vs. Patched Code

Vulnerable Code (Conceptual):

# In the Application model (or similar)
class Application < Doorkeeper::Application
  has_many :access_tokens, dependent: :delete_all
  # No before_destroy callback to notify streaming server
end

# In AccessTokenExtension
module AccessTokenExtension
  after_commit :revoke_streaming, on: :destroy

  def revoke_streaming
    # Notify streaming server
  end
end

Patched Code (Conceptual):

# In the Application model
class Application < Doorkeeper::Application
  has_many :access_tokens, dependent: :delete_all
  before_destroy :revoke_all_tokens

  private

  def revoke_all_tokens
    # Notify streaming server to revoke all tokens for this application
    StreamingServer.revoke_tokens(access_tokens.pluck(:token))
  end
end

# In AccessTokenExtension
module AccessTokenExtension
  after_commit :revoke_streaming, on: :destroy

  def revoke_streaming
    # Notify streaming server (this still works for individual token revocations)
  end
end

The key change is the addition of the before_destroy callback in the Application model, which ensures the streaming server is notified even when delete_all is used.

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker would need to:

1. Create a malicious OAuth application and trick a user into authorizing it.
2. The user later discovers the application and destroys it via the Mastodon settings.
3. Due to the vulnerability, the Access Tokens are deleted from the database, but the streaming server is not notified.
4. The attacker can continue to use the revoked tokens to connect to the streaming API and receive real-time data.

Lab Setup:

1. Deploy a vulnerable Mastodon instance (version < 4.2.6, < 4.1.14, < 4.0.14, < 3.5.18).
2. Register a new OAuth application and obtain an Access Token.
3. Use the token to connect to the streaming API (e.g., /api/v1/streaming/user).
4. In the Mastodon UI, destroy the application.
5. Observe that the streaming connection remains active, and the attacker can still receive events.

Blue Team

To detect exploitation:

1. Monitor for streaming connections that persist after the associated application has been destroyed.
2. Look for anomalies in the streaming server logs, such as connections from tokens that are no longer in the database.
3. Implement logging of token revocation events and compare with active streaming sessions.

Detection Script (Python):

import requests
import time

# Check if a token is still valid for streaming
def check_token_validity(token, mastodon_url):
    headers = {'Authorization': f'Bearer {token}'}
    response = requests.get(f'{mastodon_url}/api/v1/streaming/health', headers=headers)
    return response.status_code == 200

# Example usage
token = 'your_access_token'
mastodon_url = 'https://mastodon.example.com'
if check_token_validity(token, mastodon_url):
    print('Token is still valid - potential vulnerability')
else:
    print('Token revoked')

Indicators of Compromise (IOCs)

• Network: Streaming connections from tokens that are not present in the database.
• Logs: Streaming server logs showing connections from tokens that were deleted.
• Behavior: An application continues to receive streaming data after being revoked by the user.

Detection Engineering

YARA Rule

rule CVE_2024_25619_Mastodon_OAuth_Token_Revocation
{
    meta:
        description = "Detects Mastodon code vulnerable to CVE-2024-25619"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-25619"
    strings:
        $s1 = "dependent: :delete_all" nocase
        $s2 = "after_commit" nocase
        $s3 = "AccessTokenExtension" nocase
    condition:
        all of ($s1, $s2, $s3)
}

Sigma Rule

title: CVE-2024-25619 - Mastodon OAuth Token Revocation Failure
id: 12345678-1234-1234-1234-123456789012
status: experimental
description: Detects potential exploitation of CVE-2024-25619 where a revoked OAuth token continues to be used for streaming.
author: Valters IT
date: 2024-01-01
logsource:
    category: application
    product: mastodon
detection:
    selection:
        event: "streaming_connection"
        token_status: "active"
    condition: selection
falsepositives:
    - Legitimate tokens that were not revoked
level: low

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (msg:"CVE-2024-25619 - Mastodon OAuth Token Revocation Bypass"; flow:to_server; content:"/api/v1/streaming/"; http_uri; nocase; content:"Authorization|3a| Bearer "; http_header; nocase; pcre:"/Bearer\s+[A-Za-z0-9\-._~+/]+/"; sid:1000001; rev:1;)

Remediation & Mitigation

1. Upgrade Mastodon: Update to version 4.2.6, 4.1.14, 4.0.14, or 3.5.18 or later.
2. Monitor Streaming Logs: Regularly review streaming server logs for connections from revoked tokens.
3. Implement Token Rotation: Encourage users to rotate tokens after revoking applications.
4. Network Segmentation: Limit access to the streaming API to trusted networks.

Workaround: There is no known workaround for this vulnerability. Upgrading is the only solution.

Valters IT
DevSecOps & Cyber Threat Intelligence