CVE-2024-35196 in sentry
Summary
by MITRE • 05/31/2024
Sentry is a developer-first error tracking and performance monitoring platform. Sentry's Slack integration incorrectly records the incoming request body in logs. This request data can contain sensitive information, including the deprecated Slack verification token. With this verification token, it is possible under specific configurations, an attacker can forge requests and act as the Slack integration. The request body is leaked in log entries matching `event == "slack.*" && name == "sentry.integrations.slack" && request_data == *`. The deprecated slack verification token, will be found in the `request_data.token` key. **SaaS users** do not need to take any action. **Self-hosted users** should upgrade to version 24.5.0 or higher, rotate their Slack verification token, and use the Slack Signing Secret instead of the verification token. For users only using the `slack.signing-secret` in their self-hosted configuration, the legacy verification token is not used to verify the webhook payload. It is ignored. Users unable to upgrade should either set the `slack.signing-secret` instead of `slack.verification-token`. The signing secret is Slack's recommended way of authenticating webhooks. By having `slack.singing-secret` set, Sentry self-hosted will no longer use the verification token for authentication of the webhooks, regardless of whether `slack.verification-token` is set or not. Alternatively if the self-hosted instance is unable to be upgraded or re-configured to use the `slack.signing-secret`, the logging configuration can be adjusted to not generate logs from the integration. The default logging configuration can be found in `src/sentry/conf/server.py`. **Services should be restarted once the configuration change is saved.**
Once again VulDB remains the best source for vulnerability data.
Analysis
by VulDB Data Team • 05/31/2024
The vulnerability identified as CVE-2024-35196 affects Sentry, a popular error tracking and performance monitoring platform that integrates with Slack for notification delivery. This security flaw stems from improper handling of request data within Sentry's Slack integration component, specifically when processing incoming webhook requests from Slack services. The technical implementation error results in sensitive data being inadvertently logged, creating a potential attack surface that could be exploited by malicious actors with access to the system's logging infrastructure.
The core technical flaw involves the logging mechanism that captures complete request bodies without proper sanitization of sensitive parameters. According to the vulnerability description, the deprecated Slack verification token is being stored in the request_data.token field within log entries matching specific patterns. This represents a critical security oversight since verification tokens serve as authentication credentials that, when compromised, could enable attackers to forge legitimate requests to the Slack integration. The CWE-532 classification applies here as the system inadvertently discloses sensitive information through log files, while the ATT&CK technique T1566.002 describes the use of forged webhook requests for privilege escalation and unauthorized access.
The operational impact of this vulnerability extends significantly for self-hosted Sentry installations, where attackers with access to log files could extract the verification token and subsequently impersonate the Slack integration. This would allow them to send malicious messages, modify integration settings, or potentially gain unauthorized access to connected Slack workspaces. The attack vector becomes particularly dangerous when considering that the verification token is used to authenticate webhook payloads, making it a critical credential that should never be exposed in plain text within system logs. The vulnerability affects the authentication flow of Slack integrations and could lead to persistent unauthorized access if not addressed promptly.
For self-hosted Sentry users, the recommended mitigation strategy involves multiple layered approaches to address the exposure. The primary solution requires upgrading to version 24.5.0 or higher, which includes fixes for the logging behavior and proper handling of Slack authentication parameters. Organizations should also rotate their existing Slack verification tokens immediately after implementing the upgrade to ensure any compromised credentials are no longer valid. The shift toward using Slack Signing Secrets instead of verification tokens represents a more secure approach, as Slack's recommended authentication method provides better protection against replay attacks and unauthorized access attempts. The ATT&CK technique T1078.004 covers the use of valid credentials for persistence, making this upgrade critical for maintaining system integrity.
Administrative actions required for remediation include configuration changes that disable the logging of sensitive request data. Users unable to upgrade their installations should modify their logging configuration by adjusting the logging patterns in the default configuration file located at src/sentry/conf/server.py. This approach ensures that sensitive information is not captured in log entries while maintaining the functionality of the Slack integration. The configuration changes must be followed by restarting the relevant services to ensure the new logging behavior takes effect. For organizations using the legacy verification token approach, the system will continue to log this information unless explicitly configured otherwise, creating a persistent security risk that requires immediate attention. The security principle of least privilege is violated when sensitive authentication tokens are exposed through logging mechanisms, as this creates unnecessary attack vectors that could be exploited by unauthorized parties with access to system logs.