Detect SSRF attacks in cloud applications and APIs

APIs can be vulnerable to a wide variety of attacks, such as poor inventory management and access controls, making them a primary target for attackers. Server-side request forgery (SSRF) is one type of attack that has become more prominent with the rising use of public clouds. This is primarily due to new development practices like using Instance Metadata Services (IMDS) to access valuable information about deployed instances, such as credentials. SSRF attacks can be difficult to surface in public cloud environments due to their complex network of application and metadata APIs, and can cause costly data breaches if not detected.

Understanding where SSRF attacks are likely to occur and how to detect them can help you secure your applications. In this post, we'll look at common SSRF attack scenarios and how to detect activity related to them.

A primer on SSRF attacks

Before we talk about how an SSRF attack takes advantage of vulnerable applications, let's review how applications and their APIs process requests. A typical workflow starts with an end user submitting a request to the frontend of an application, which may use an API service to fetch relevant data from a backend server. For example, when a user searches for a specific product in an ecommerce application, the app may use a "Product API" service to pull the result from a trusted database. In a case like this, the API request may look like the following example payload snippet:

POST /products/item
 {
"productApi":"http://data.ecommerce-app.com:3000/products/item/check?productId=3"
}

In an SSRF attack, an attacker may manipulate the body of this request (specifically, the value of productApi) so that it fetches data from other backend systems that might not otherwise be accessible to external users. This is possible because-in the "eyes" of the application-the request is coming from a trusted source, the "Product API" service.

One of the most common aims of an SSRF attack is to access a cloud-hosted application's Instance Metadata Service (IMDS), which typically exposes service metadata over well-documented paths. Other popular cloud technologies, such as Docker and Kubernetes, also provide similar metadata management and control systems, which attackers may also try to exploit. Using our ecommerce application example, an attacker may append the path to an Amazon EC2 IMDS endpoint in the body of the POST request, as seen in the following payload snippet:

POST /products/item
 {
"productApi":"http://169.254.169.254/latest/meta-data/iam/security-credentials/sample-ec2-role"
}

The application will then process the request by returning sensitive data associated with the sample-ec2-role, such as access keys and tokens. This is particularly dangerous because any permissions attached to that role are now accessible to the attacker. To take it a step further, if the associated EC2 instance has administrative access, then the attacker has that same level of access to the AWS environment where the instance is running. Upgrading to IMDSv2 is the recommended mitigation, but it is often not enforced across EC2 instances-on average, only 25 percent of instances are using IMDSv2. This statistic is just one example of many existing vulnerabilities that enable attackers to use SSRF attacks across modern cloud-based applications.

How SSRF attacks occur

What factors contribute to the success of these SSRF attacks? At the application level, simple misconfigurations in the code can grant an attacker access to internal systems. Since SSRF attacks often come in the form of user-provided data, this means that common entry points include sources that do not check user input for unexpected data. The following code snippet illustrates this scenario in a simple Java service that does not include proper validation or sanitation for request.url, which stores a user-provided URL:

@Service public classWebsiteTestService { @Autowired private RestTemplate rest; public String testWebsite(WebsiteTestRequest request) { try { return this.rest.exchange(request.url, HttpMethod.GET, String.class).getBody(); } catch (HttpClientErrorException | HttpServerErrorException e) { return "URL returned status code: " + e.getStatusCode(); } } } @RestController public classMainController { @Autowired private WebsiteTestService websiteTestService; @RequestMapping(method=RequestMethod.POST, value="/test-website", consumes="application/json") public ResponseEntity<String> testWebsite(@RequestBody WebsiteTestRequest request) { String result = websiteTestService.testWebsite(request); return new ResponseEntity<>(result, HttpStatus.OK); } }

Code vulnerabilities can also increase opportunities for attackers to take advantage of an application's API requests. Java services, in particular, are susceptible to vulnerabilities from third-party libraries. For example, using an outdated Jackson or Apache library, which are two popular Java libraries, could open the door for SSRF attacks.

Detect SSRF attacks in your cloud applications

SSRF attacks can be difficult to detect since they are disguised as application requests, but there are a few signs to look out for. One good place to start is monitoring the timing and nature of an API call's response for initial signs of malicious activity. For instance, if an API call times out consistently or suddenly takes longer than usual to process, it could mean that it has been manipulated as part of an attempt to access an unexpected resource. An error or significantly short response time could indicate that an attacker's target endpoint or resource wasn't available. A longer response time, on the other hand, suggests that the target was available and successfully processed the request.

In the following screenshot, you can see significant spikes in both the number of generated errors and latency within a short period of time for the /checkout API endpoint:

Investigating these issues further can help you confirm if the API is indeed being targeted by an attacker. For example, you can look for the following usage patterns in affected API calls:

• Requests to sensitive domains and IPs (e.g., metadata.google.internal)
• User input that tampers with a URL's structure to introduce new schemas in the request (e.g., file://, sftp://)
• Malformed URLs that attempt to bypass an application's parsing libraries (e.g., instance.db:8000:1234/?q=example)

As previously mentioned, one common sign of SSRF activity is seeing your application execute network requests to unusual hosts, such as cloud metadata APIs. For example, in the following screenshot, you can see that an attacker supplied the https://169.254.169.254 metadata URL in the body of a POST request, which Datadog Application Security Management flagged as malicious.

Datadog ASM's out-of-the-box detection rules automatically detect these actions and enable you to block the attacking IPs via its in-app web application firewall (WAF). Since Datadog ASM is designed to analyze service-to-service request traces, it can more efficiently block an attack than typical perimeter WAFs, which require constant re-tuning to mitigate attacks.

Protect your APIs from SSRF attacks

In this post, we looked at SSRF attacks and how they target cloud applications. We also walked through some practical ways that you can detect these types of attacks against your services. To mitigate SSRF attacks, OWASP provides several recommendations. For more information about using Datadog ASM to detect signs of SSRF attacks, check out our documentation. If you don't already have a Datadog account, you can sign up for a free 14-day trial.