SSRF vulnerability triggered

This page is not yet available in Spanish. We are working on its translation.
If you have any questions or feedback about our current translation project, feel free to reach out to us!

Goal

Detect successful exploitation attempts of the SSRF vulnerability.

Server-Side Request Forgery (SSRF) is a web security vulnerability that allows an attacker to deceive the application and make requests to an unintended location.

In a typical SSRF attack, the attacker might cause the server to make a connection to internal-only services within an organization’s infrastructure. In other cases, they may be able to force the server to connect to arbitrary external systems, potentially leaking sensitive data.

Strategy

Monitor application security events to detect SSRF attack patterns (@appsec.security_activity:attack_attempt.ssrf) on distributed traces where external HTTP requests are performed. The heuristic conducts additional analysis to detect if the SSRF vulnerability exists and is triggered or not. When a vulnerability exploitation attempt is detected (@appsec.security_activity:vulnerability_trigger.ssrf), a Security Signal with CRITICAL severity is generated.

The detection heuristics are as follow:

  • Analyze the external HTTP requests which are performed by the application to look for suspicious calls

    • Is the URL ambiguous? Such URLs may not be parsed in the same way by all network libraries and therefore enable bypasses (eg. bla.db.internal:6379:1324/?q=nice)
    • Is the tampered URL leading to a sensitive domain/IP (eg. instance metadata)?
  • Check if the user inputs is manipulating or tampering those requests

    • Does the user input appear to be changing the destination domain in an unexpected way?
    • Does the user input change the schema to a uncommon (non HTTP/FTP) schema?
    • Does the user input introduce new URL parameters?

The severity of the signal is lowered to High when the application threw an exception during execution, indicating they might not have succeeded at impacting the system.

Triage and response

  1. Consider blocking the attacking IPs temporarily to slow down further exploitation of your infrastructure.
  2. Investigate the domains and IP addresses accessed by this SSRF attack to scope the impact of the attack.
  3. Consider adding more restrictions on your code for the user inputs to prevent any user from making unsupervised external HTTP requests. You may also decide to isolate the services performing those requests.
  4. Consider switching the WAF rule rasp-934-100 to blocking mode to prevent exploitation.
PREVIEWING: rtrieu/product-analytics-ui-changes