CVE-2024-45606

Executive Summary

CVE-2024-45606 is a missing authorization vulnerability in Sentry, a developer-first error tracking and performance monitoring platform. An authenticated user can mute alert rules from arbitrary organizations and projects if they know the rule ID. The user does not need to be a member of the organization or have any permissions on the project. This vulnerability affects self-hosted Sentry instances from version 23.4.0 (early access) or 23.6.0 (general availability) up to, but not including, 24.9.0. The CVSS score is 7.1 (High), with a vector of AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H. The EPSS score is 0.0%, indicating low exploitation probability in the wild. No public proof-of-concept code or Nuclei templates are available. The patch is included in Sentry version 24.9.0, which adds proper authorization checks.

Supply Chain & Package Security

Sentry is a Python-based application distributed via Docker images and PyPI packages. The vulnerability exists in the web application layer, not in a specific dependency. However, self-hosted users should verify the integrity of their upgrade to version 24.9.0 by checking SHA256 checksums or using signed Docker images. No malicious packages have been reported in relation to this CVE.

CVSS Breakdown & Threat Level

• CVSS Score: 7.1 (High)
• Vector: CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:H
• Attack Vector: Network (AV:N)
• Attack Complexity: Low (AC:L)
• Privileges Required: Low (PR:L) – requires an authenticated user
• User Interaction: None (UI:N)
• Scope: Unchanged (S:U)
• Confidentiality Impact: None (C:N)
• Integrity Impact: Low (I:L) – only mute functionality affected
• Availability Impact: High (A:H) – alert rules can be muted, potentially causing missed critical alerts

The threat level is High due to the low attack complexity and the potential for availability impact. An attacker with a valid account can mute alert rules across any organization, leading to denial of monitoring capabilities.

Deep Dive & Mechanics

The vulnerability lies in the API endpoint responsible for muting alert rules. The endpoint accepts a rule ID and a mute action, but it does not verify that the requesting user has the necessary permissions (e.g., membership in the organization or project-level access). The only requirement is that the user is authenticated and knows the rule ID. Rule IDs are typically UUIDs, but they can be enumerated or guessed if the attacker has some knowledge of the target environment.

The vulnerable code path is in the sentry/api/endpoints/rule_mute.py file (or similar). The endpoint likely calls a function like mute_alert_rule(rule_id) without first checking request.user.has_perm('alerts.mute_alert', rule). The patch in version 24.9.0 adds a permission check that ensures the user is a member of the organization and has the alerts:mute permission.

Vulnerable vs. Patched Code

Vulnerable Code (pre-24.9.0):

# sentry/api/endpoints/rule_mute.py
class RuleMuteEndpoint(Endpoint):
    def post(self, request, rule_id):
        # No authorization check
        rule = AlertRule.objects.get(id=rule_id)
        rule.mute()
        return Response(status=200)

Patched Code (24.9.0):

# sentry/api/endpoints/rule_mute.py
from sentry.api.permissions import has_scope

class RuleMuteEndpoint(Endpoint):
    def post(self, request, rule_id):
        rule = AlertRule.objects.get(id=rule_id)
        # Authorization check added
        if not has_scope(request.user, 'alerts:mute', rule.project.organization):
            return Response(status=403)
        rule.mute()
        return Response(status=200)

The patch ensures that the user has the alerts:mute scope for the organization that owns the rule.

Exploitation & Lab Setup

Red Team

To exploit this vulnerability, an attacker needs:

1. A valid authenticated session on a self-hosted Sentry instance (version 23.4.0 to 24.8.x).
2. Knowledge of a target alert rule ID (UUID).

Step-by-step exploitation:

1. Obtain a valid session cookie (e.g., sessionid) by logging in or using a compromised account.
2. Identify a target rule ID. This could be done by:
   • Observing network traffic if the attacker has access to the same network.
   • Using a previously compromised account that has access to some rules.
   • Brute-forcing UUIDs (unlikely but possible if the instance has low entropy).
3. Send a POST request to the mute endpoint:

   POST /api/0/projects/org-slug/project-slug/rules/rule-id/mute/ HTTP/1.1
   Host: sentry.example.com
   Cookie: sessionid=valid_session
   Content-Type: application/json
   

4. The rule is muted, and the attacker can repeat for other rules.

Lab Setup:

• Deploy a vulnerable Sentry instance using Docker:

  docker run -d --name sentry-vuln -p 9000:9000 sentry:23.6.0
  

• Create a test organization, project, and alert rule.
• Use a second user account that is not a member of the organization to attempt the mute.

Blue Team

Detection:

• Monitor API logs for POST requests to /api/0/projects/*/rules/*/mute/ from users who are not members of the target organization.
• Alert on multiple mute requests from the same user across different organizations within a short time window.

Hunting:

• Query audit logs for alert_rule.mute events and cross-reference with user organization membership.
• Check for any muted alert rules that were not muted by an authorized user.

Prevention:

• Upgrade to version 24.9.0 immediately.
• Implement network segmentation to limit access to the Sentry API.
• Use strong authentication (e.g., SSO with MFA) to reduce the risk of account compromise.

Indicators of Compromise (IOCs)

• Network: POST requests to /api/0/projects/*/rules/*/mute/ from unexpected IPs or users.
• Logs: Audit log entries for alert_rule.mute without a corresponding organization.member.add or similar event.
• System: Muted alert rules that were not muted by an authorized user.
• File: No specific file-based IOCs.

Detection Engineering

YARA Rule

rule sentry_cve_2024_45606_mute_bypass {
    meta:
        description = "Detects attempts to exploit CVE-2024-45606 by muting alert rules without authorization"
        author = "Valters IT"
        date = "2024-10-27"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2024-45606"
    strings:
        $mute_endpoint = "/api/0/projects/"
        $mute_action = "/mute/"
        $rule_id_pattern = /[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/
    condition:
        all of them
}

Sigma Rule

title: Sentry Alert Rule Mute by Unauthorized User
id: 8a9b7c6d-5e4f-3a2b-1c0d-9e8f7a6b5c4d
status: experimental
description: Detects when a user mutes an alert rule in Sentry without being a member of the target organization
author: Valters IT
date: 2024-10-27
logsource:
    product: sentry
    service: audit_log
detection:
    selection:
        EventID: alert_rule.mute
    filter:
        UserOrganizationMembership: false
    condition: selection and filter
falsepositives:
    - Authorized users with cross-organization permissions (rare)
level: high

Suricata Rule

alert http $HOME_NET any -> $EXTERNAL_NET any (
    msg:"SENTRY CVE-2024-45606 Alert Rule Mute Attempt";
    flow:to_server,established;
    content:"POST"; http_method;
    content:"/api/0/projects/"; http_uri;
    content:"/mute/"; http_uri;
    pcre:"/[0-9a-f]{8}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{4}-[0-9a-f]{12}/";
    classtype:attempted-recon;
    sid:10000001;
    rev:1;
)

Remediation & Mitigation

Immediate Actions:

1. Upgrade all self-hosted Sentry instances to version 24.9.0 or higher.
2. If upgrade is not possible, restrict access to the Sentry API using a reverse proxy (e.g., Nginx) with IP whitelisting.
3. Review audit logs for any unauthorized mute actions.

Long-term Measures:

• Implement the principle of least privilege for all Sentry users.
• Enable detailed audit logging and monitor for anomalous API calls.
• Regularly update Sentry to the latest version.

Workarounds:

• No official workarounds exist. The only solution is to upgrade.

Valters IT