Detailed Technical Analysis of "Blind SSRF in Stripe.com Due to Sentry Misconfiguration"

Overview:
This write-up by 0ktavandi dissects a fascinating blind Server-Side Request Forgery (SSRF) vulnerability in Stripe.com, which was due to a misconfiguration in Sentry, an event logging and aggregation platform. The vulnerability allowed the researcher to escalate the issue by chaining further exploits, demonstrating a high-severity security flaw.

Key Technical Details:

  1. Initial Vulnerability Discovery:

    • Sentry Integration: Stripe uses Sentry for error logging and tracking across its infrastructure.
    • Misconfiguration: Properly configured Sentry installations can avoid SSRF by ensuring tight controls over what URLs can be requested. However, in this case, a misconfiguration allowed the attacker to induce SSRF.
    • SSRF Injection Point: The specific SSRF vulnerability was exposed via a user-controllable field within Sentry’s webhook, where the URL for webhook events could be manipulated.
  2. Blind SSRF:

    • Blind Nature: Unlike conventional SSRFs where the results of the request can be observed directly, in this case, the attacker could not directly see the response. Instead, they had to infer success or failure based on side-effects (hence "blind").
    • Exploitation Strategy: The attacker could send requests to internal systems or services without directly seeing the response. By measuring the effect of these requests (e.g., application errors or network behavior), they could glean information about the internal network.
  3. Chaining Exploits:

    • Information Leakage: Through blind SSRF, the attacker managed to induce requests to internal endpoints. By careful analysis, these requests leaked valuable information about internal infrastructure, such as IP addresses and reachable services.
    • Pivoting: After acquiring sufficient information, the attacker pivoted the attack to target sensitive services within the internal network, thereby escalating the severity.
  4. Technical Exploit Steps:

    • Inducing Requests: The attacker crafted payloads to exploit the misconfigured webhook. By injecting various endpoints, they were able to cause Sentry to make HTTP requests to internal Stripe resources.
    • Identifying Internal Services: By sending payloads to different internal IPs and observing network traffic and error logs, they mapped out reachable services within Stripe’s infrastructure.
    • Confirming SSRF Effectiveness: Repeated testing with controlled payloads confirmed that the SSRF allowed access to internal services, thus highlighting the critical nature of the vulnerability.
  5. Impact and Coordination:

    • Severity: This type of vulnerability is critically dangerous because it allows attackers to bypass perimeter defenses and interact directly with internal services, potentially leading to sensitive data exposure, unauthorized actions, and further pivots within the network.
    • Disclosure: The researcher responsibly disclosed the vulnerability to Stripe, which acknowledged the issue and rewarded them under their bug bounty program.

Key Takeaways:

Conclusion:

The write-up provides an insightful look into how a seemingly minor configuration error in an auxiliary service like Sentry can result in a serious security vulnerability. It underscores the critical need for secure configurations, vigilant security testing, and responsible disclosure practices to maintain robust defense mechanisms.

For full details, check the original write-up here.