CVE-2024-25618

Executive Summary

CVE-2024-25618 is an account takeover vulnerability in Mastodon, a free, open-source social network server. The flaw allows an attacker to hijack a user's account by exploiting the identity linking mechanism when external authentication providers (CAS, SAML, OIDC) are used. If an authentication provider allows email address changes or multiple providers are configured, an attacker can register with the same email as an existing user and gain control of that account. The vulnerability is rated medium severity (CVSS 4.2) and affects all Mastodon versions prior to 4.2.6, 4.1.14, 4.0.14, and 3.5.18. No public exploit code is available, but the attack vector is straightforward for misconfigured providers.

Supply Chain & Package Security

Mastodon is a Ruby on Rails application distributed via GitHub and Docker. The vulnerability is in the authentication logic, not in a specific package dependency. However, the reliance on external authentication providers introduces supply chain risk: if a provider (e.g., Microsoft Azure AD) allows unverified email changes, the Mastodon instance is vulnerable. Administrators should audit their OIDC/SAML provider configurations and ensure email verification is enforced.

CVSS Breakdown & Threat Level

• CVSS Score: 4.2 (Medium)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:L/I:L/A:N
• Attack Vector: Network (AV:N) – exploitable remotely.
• Attack Complexity: Low (AC:L) – no special conditions required.
• Privileges Required: None (PR:N) – attacker does not need prior access.
• User Interaction: Required (UI:R) – victim must log in via the external provider.
• Scope: Unchanged (S:U) – vulnerability affects only the vulnerable component.
• Confidentiality Impact: Low (C:L) – attacker gains access to user data.
• Integrity Impact: Low (I:L) – attacker can post or modify account settings.
• Availability Impact: None (A:N) – no denial of service.

Threat Level: Medium. The vulnerability requires the external authentication provider to allow email changes, but many popular providers (e.g., Microsoft Azure AD) make this easy to misconfigure. The attack is stealthy and can lead to full account takeover.

Deep Dive & Mechanics

Mastodon allows users to log in via external authentication providers (CAS, SAML, OIDC). When a user authenticates for the first time, Mastodon checks the email address provided by the external provider against existing local accounts. If a match is found, the new identity is linked to that existing account. The vulnerability arises because Mastodon does not verify that the email address is still controlled by the original user. If the external provider allows changing the email address (e.g., due to a misconfiguration or a feature like "change email without verification"), an attacker can:

1. Register an account with the external provider using the victim's email address.
2. Log in to Mastodon via that provider.
3. Mastodon links the new identity to the victim's existing account, giving the attacker full control.

This is particularly dangerous with OpenID Connect (OIDC) providers that support dynamic client registration, as an attacker could register a malicious client and exploit the flow.

Root Cause: The User model in Mastodon uses email as the sole identifier for linking external identities. The fix involves adding a verification step or using a unique, immutable identifier from the provider (e.g., sub claim in OIDC).

Vulnerable vs. Patched Code

Vulnerable Code (pre-4.2.6): In app/models/user.rb, the method find_by_email is used to locate existing users:

def self.find_by_email(email)
  User.find_by(email: email)
end

When an external authentication callback is processed, the email from the provider is passed directly to this method without additional checks.

Patched Code (4.2.6+): The fix introduces a verification step that checks the provider's unique identifier (e.g., sub for OIDC) before linking:

def self.find_by_identity(provider, uid)
  Identity.find_by(provider: provider, uid: uid)&.user
end

Additionally, the email matching is now only used if no existing identity is found, and a confirmation step is required to prevent automatic linking.

Exploitation & Lab Setup

Red Team

Prerequisites:

• Access to an external authentication provider that allows email changes (e.g., Microsoft Azure AD with "Email change without verification" enabled).
• A target Mastodon instance (version < 4.2.6) configured with that provider.

Exploitation Steps:

1. Identify a victim's email address (e.g., victim@example.com).
2. Register a new account with the external provider using that email.
3. Log in to the Mastodon instance via the external provider.
4. Mastodon links the new identity to the victim's existing account.
5. The attacker now has full control: can read DMs, post, change settings, etc.

Lab Setup:

• Deploy a vulnerable Mastodon instance (e.g., using Docker with version 4.2.5).
• Configure an OIDC provider (e.g., Keycloak or Azure AD) with email change enabled.
• Create a victim account on Mastodon.
• Execute the attack as described.

Blue Team

Detection:

• Monitor authentication logs for multiple accounts with the same email from different providers.
• Alert on new external identity links to existing accounts without prior verification.
• Use the detection rules below.

Prevention:

• Upgrade to patched versions immediately.
• Disable email change in external providers if not needed.
• Enforce email verification before allowing identity linking.

Indicators of Compromise (IOCs)

• Log Entries: Repeated Identity creation events for the same email but different uid values.
• Network Traffic: Unusual OIDC/SAML authentication requests from new IPs for existing users.
• User Behavior: Sudden changes in account settings or posts from a previously inactive user.

Example Log Pattern:

[2024-01-01 12:00:00] INFO  Identity created: provider=azure, uid=abc123, user_id=42
[2024-01-01 12:05:00] INFO  Identity created: provider=azure, uid=def456, user_id=42

Detection Engineering

YARA Rule

rule CVE_2024_25618_Mastodon_AccountTakeover {
    meta:
        description = "Detects Mastodon account takeover via external auth provider email mismatch"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "CVE-2024-25618"
    strings:
        $s1 = "find_by_email" nocase
        $s2 = "identity" nocase
        $s3 = "external" nocase
    condition:
        all of them
}

Sigma Rule

title: Mastodon Account Takeover via External Auth Provider
id: cve-2024-25618
status: experimental
description: Detects multiple identity links for the same user from different providers
logsource:
    product: mastodon
    service: auth
detection:
    selection:
        event: Identity created
    condition: selection | count(user_id) by email > 1
falsepositives:
    - Legitimate multiple provider usage (rare)
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-25618 Mastodon Account Takeover"; flow:to_server; content:"POST"; http_method; content:"/auth/"; http_uri; content:"identity"; http_client_body; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Mastodon to version 4.2.6, 4.1.14, 4.0.14, or 3.5.18.
2. Review external authentication provider configurations and disable email change if not required.
3. Enable email verification for all users.

Long-term:

• Implement multi-factor authentication (MFA) for all accounts.
• Monitor authentication logs for anomalies.
• Use immutable identifiers (e.g., OIDC sub) for identity linking.

Workarounds: None available. Upgrade is mandatory.

Valters IT