CVE-2024-25623

Executive Summary

CVE-2024-25623 is a critical vulnerability in Mastodon, a free, open-source social network server based on ActivityPub. The flaw resides in the way Mastodon fetches remote statuses. When processing a request to fetch a remote ActivityStreams object, the server does not validate that the HTTP response from the remote server contains a Content-Type header of the Activity Streams media type (e.g., application/activity+json). This allows a threat actor to upload a crafted ActivityStreams document to a remote server that accepts arbitrary user uploads and serves them on the same domain as its ActivityPub actors. If the remote server also serves user-uploaded documents in response to requests with an Accept header value of the Activity Streams media type, the attacker can impersonate any account on that remote server.

The vulnerability has a CVSS score of 8.5 (High) and affects all Mastodon versions prior to 4.2.7, 4.1.15, 4.0.15, and 3.5.19. The EPSS score is 0.0%, indicating no active exploitation in the wild at the time of analysis, but the technical impact is severe as it enables account impersonation and potential data exfiltration.

Supply Chain & Package Security

Mastodon is a Ruby on Rails application distributed via GitHub and Docker images. The vulnerability is not in a package dependency but in the core application logic. However, administrators should ensure they are using official Mastodon images and verify the integrity of their deployment. The fix is included in the latest stable releases, and no additional package updates are required.

CVSS Breakdown & Threat Level

• CVSS Score: 8.5 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N
• Attack Vector: Network
• Attack Complexity: Low
• Privileges Required: None
• User Interaction: None
• Scope: Unchanged
• Confidentiality Impact: High
• Integrity Impact: High
• Availability Impact: None

Threat Level: High. The vulnerability allows unauthenticated remote attackers to impersonate any account on a vulnerable Mastodon server, leading to unauthorized actions, data access, and reputational damage.

Deep Dive & Mechanics

The vulnerability exploits the lack of Content-Type validation when fetching remote ActivityStreams objects. Mastodon's federation logic works by fetching remote statuses and profiles via HTTP requests. When a Mastodon server receives a request to fetch a remote object (e.g., a status from another instance), it sends an HTTP GET request to the remote server with an Accept header set to application/activity+json. The remote server is expected to respond with a JSON document of that media type.

However, Mastodon does not verify that the response's Content-Type header matches the expected Activity Streams media type. This allows an attacker to:

1. Register an account on a remote server that allows arbitrary user uploads (e.g., a file hosting service or a misconfigured web server).
2. Upload a crafted ActivityStreams document that impersonates a legitimate account (e.g., by setting the actor field to the URI of the target account).
3. Make the vulnerable Mastodon server fetch this document by sending a request to the uploaded file's URL.
4. The vulnerable server processes the document as if it were a legitimate ActivityStreams object, thereby impersonating the target account.

The attack requires the remote server to:

• Allow the attacker to register an account.
• Accept arbitrary user-uploaded documents and place them on the same domain as the ActivityPub actors.
• Serve user-uploaded documents in response to requests with an Accept header value of the Activity Streams media type.

This is a classic case of CWE-346: Origin Validation Error, where the software does not properly verify the source of a communication or data.

Vulnerable vs. Patched Code

The vulnerable code is in the ActivityPub::FetchRemoteStatusService or similar service that handles fetching remote objects. The fix involves adding a check for the Content-Type header.

Vulnerable Code (Ruby):

# app/services/activitypub/fetch_remote_status_service.rb
def call(url, ...)
  response = http_client.get(url, headers: { 'Accept' => 'application/activity+json' })
  # No Content-Type validation
  body = response.body
  process_activity(body)
end

Patched Code (Ruby):

# app/services/activitypub/fetch_remote_status_service.rb
def call(url, ...)
  response = http_client.get(url, headers: { 'Accept' => 'application/activity+json' })
  # Validate Content-Type
  content_type = response.headers['Content-Type']
  unless content_type&.include?('application/activity+json')
    raise "Invalid Content-Type: #{content_type}"
  end
  body = response.body
  process_activity(body)
end

The patch ensures that only responses with the correct Content-Type are processed, preventing the server from accepting arbitrary uploaded documents.

Exploitation & Lab Setup

Red Team

Prerequisites:

• A remote server that allows arbitrary file uploads and serves them on the same domain as its ActivityPub actors (e.g., a Mastodon instance with file upload enabled).
• An account on that remote server.
• A vulnerable Mastodon instance (version < 4.2.7, etc.).

Steps:

1. Craft a malicious ActivityStreams document: Create a JSON file that impersonates a target account. For example, to impersonate @victim@example.com, set the actor field to https://example.com/users/victim.

   {
     "@context": "https://www.w3.org/ns/activitystreams",
     "type": "Note",
     "id": "https://attacker-server.com/uploads/malicious.json",
     "actor": "https://example.com/users/victim",
     "content": "This is a fake status from victim.",
     "to": ["https://www.w3.org/ns/activitystreams#Public"]
   }
   

2. Upload the document to the remote server: Use the remote server's file upload functionality (e.g., via the Mastodon media upload API) to upload the crafted JSON file. Note the URL of the uploaded file (e.g., https://attacker-server.com/uploads/malicious.json).

3. Trigger the vulnerable Mastodon server to fetch the document: Send a request to the vulnerable Mastodon server to fetch the remote object. This can be done by posting a status that references the uploaded document's URL, or by directly calling the fetch API if available.

   curl -X POST "https://vulnerable-mastodon.example.com/api/v1/statuses" \
     -H "Authorization: Bearer <token>" \
     -d "status=Check this out: https://attacker-server.com/uploads/malicious.json"
   

4. Verify impersonation: The vulnerable server will process the malicious document and treat it as a legitimate status from the victim account. The fake status will appear on the vulnerable server's public timeline, attributed to the victim.

Note: No public exploit code is available at this time.

Blue Team

Detection:

• Monitor for unusual federation requests to unknown or suspicious domains.
• Check for statuses that appear to come from known accounts but have unexpected content or metadata.
• Look for HTTP responses with Content-Type headers that do not match application/activity+json when fetching remote objects.

Hunting:

• Search logs for requests to URLs that are not typical ActivityPub endpoints (e.g., /uploads/, /files/).
• Analyze the actor field of incoming federated activities to ensure they match the expected domain and user.

Lab Setup:

• Deploy a vulnerable Mastodon instance (e.g., version 4.2.6) in a controlled environment.
• Set up a remote server with file upload capabilities (e.g., a simple HTTP server that accepts uploads).
• Simulate the attack by uploading a crafted JSON file and triggering the fetch.

Indicators of Compromise (IOCs)

• Network IOCs:

  • HTTP requests to URLs containing /uploads/ or /files/ with an Accept: application/activity+json header.
  • Responses with Content-Type other than application/activity+json for ActivityPub fetch requests.
  • Unusual federation requests to domains not known to host ActivityPub services.

• File IOCs:

  • JSON files with actor fields pointing to external domains that do not match the server's domain.
  • Files with .json extension but served with incorrect Content-Type.

• Log IOCs:

  • Log entries showing ActivityPub::FetchRemoteStatusService processing URLs with non-standard paths.
  • Errors related to Content-Type validation (after patching).

Detection Engineering

YARA Rule

rule CVE_2024_25623_Mastodon_Impersonation {
    meta:
        description = "Detects crafted ActivityStreams documents used in CVE-2024-25623"
        author = "Valters IT"
        date = "2024-01-01"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-25623"
        severity = "high"
    strings:
        $actor = /"actor"\s*:\s*"https?:\/\/[^"]+/
        $content_type = /"Content-Type"\s*:\s*"application\/activity\+json"/
        $note = /"type"\s*:\s*"Note"/
    condition:
        $actor and $note and not $content_type
}

Sigma Rule

title: CVE-2024-25623 - Mastodon Remote Status Fetch Without Content-Type Validation
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects HTTP responses to Mastodon federation requests that lack the expected Content-Type header.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2024-25623
author: Valters IT
date: 2024-01-01
logsource:
    category: web
    product: mastodon
detection:
    selection:
        http.response.headers.Content-Type|contains: 'application/activity+json'
    condition: not selection
falsepositives:
    - Legitimate non-ActivityPub content fetched by mistake
level: high

Suricata Rule

alert http any any -> any any (msg:"CVE-2024-25623 - Mastodon Remote Status Fetch Without Content-Type Validation"; flow:to_server; content:"Accept|3a 20|application/activity+json"; http_header; content:"Content-Type|3a 20|"; http_header; pcre:"/Content-Type:\s*(?!application\/activity\+json)/i"; sid:1000001; rev:1;)

Remediation & Mitigation

Immediate Actions:

1. Upgrade Mastodon: Update to version 4.2.7, 4.1.15, 4.0.15, or 3.5.19 immediately. These versions include the fix for CVE-2024-25623.
2. Restrict Federation: Temporarily disable federation with untrusted servers until the upgrade is complete.
3. Monitor Logs: Review federation logs for any signs of exploitation.

Long-term Mitigations:

• Implement strict Content-Type validation for all incoming federation requests.
• Use Web Application Firewalls (WAF) to filter out requests with suspicious Accept headers.
• Regularly audit and update Mastodon instances to the latest stable versions.
• Educate users about the risks of interacting with untrusted content.

Workarounds:

• If immediate upgrade is not possible, consider blocking federation with servers that allow arbitrary file uploads on the same domain as ActivityPub actors. This can be done via the Mastodon admin panel or by modifying the federation allowlist/blocklist.

Valters IT
DevSecOps & Cyber Threat Intelligence Expert