Defending Against SSRF Attacks in Cloud Native Applications

Originally published by Sweet Security.

Written by Sarah Elkaim, Head of Product Marketing, Sweet Security.

 

A Server-Side Request Forgery (SSRF) attack occurs when an attacker tricks a server into making requests to other internal or external services on behalf of the server itself. This can lead to unauthorized access to sensitive data, exploitation of internal systems, and even full system takeover. 

At Sweet Security, we’ve seen a surge in SSRF attacks within cloud environments, with 80% of our customers reporting that they’ve experienced this type of attack attempt. 

In this article, we dive into a unique SSRF attack attempt made against a Sweet customer in the Fintech space. We’ll share the attempt in detail and outline how the customer protected against it. 

 

Are SSRF Attacks Cloud Attacks? 

SSRF attacks often leverage misconfigurations or vulnerabilities in web applications, enabling attackers to access resources that should otherwise be protected. Because these requests are made from the server's context, they aren’t necessarily a cloud attack and can therefore bypass traditional cloud security measures like CNAPP and Cloud Detection and Response (CDR) solutions.  

 

A Real-Life SSRF Attack

However, there are instances where an SSRF attack can become a cloud attack. In the case of our customer, a threat actor used the SSRF against an instance metadata service of EC2. In other words, they leveraged the cloud control plane to conduct the SSRF attack. 

As a result, their CloudTrail logs erupted with alerts about unauthorized access attempts to their control plane from an API Gateway—an action that should never occur. Unfortunately, they were in the dark about:

1. The origin of this access
2. Whether the access was successful 
3. If the access came from an internal or external source

 

Is SSRF Detected by CSPM or CDR?

SSRF attacks are essentially conducted by tweaking a machine, and without visibility into the relevant processes of the application, you can’t know whether the activity was human-driven, what role the machine had, or even if the process was successful. Without application-level visibility, the customer was left with only the machine name from their cloud security solution. This is because CSPMs only provide a snapshot of your security posture but fail to capture the dynamic activity that leads to a change in state. You don’t end up seeing the activity that actually changed the status of the environment. For instance, if an attacker disables audit logs, you may see that logs are off in one scan and on in another, but you won't know who made that change or when.

 

Combining ADR & CDR 

A robust multi-layered detection and response strategy combines:

• Cloud Infra / CDR
• Workloads / CWPP
• API + App / ADR
• Network / NDR

 

Should We Rely Solely on Sensor Data and ADR?

The answer is no. Consider a scenario involving a supply chain attack on an identity provider. If an attacker obtains the golden ID of Company X, for example, they could potentially access X’s cloud infrastructure without triggering any alarms in the application layer. They could extract sensitive data from an S3 bucket, all while leaving no trace in the workload. This type of breach emphasizes that an attack can occur outside the application environment, targeting users directly and bypassing cloud security measures like ADR. 

This highlights a critical lesson: while ADR sensors are vital, they are not a complete solution on their own.

A threat actor breaches an identity provider through a vulnerability and accesses your cloud services using compromised credentials. 

 

The Bottom Line: Cross Correlating Application Activity with Cloud Logs is Key

The takeaway is clear: neither ADR, CWPP/EDR or CSPM/CDR is sufficient in isolation. It’s the correlation between the three that uncovers hidden threats. 

A top-of-the-line detection system utilizes advanced sensors (ADR) combined with comprehensive analysis of cloud logs (CDR), monitoring a wide array of sources, including:

	Data	Control Pane	Network
AWS	CloudTrail  CloudWatch RDS Audit Logs  DynamoDB Images S3 Data Events Logs	CloudTrail  CloudWatch	AWS Flow Logs
Google Cloud	Google Audit Logs  Cloud Storage Data Access Logs	Google Audit Logs	VPC Flow Logs
Azure	Azure Audit Logs  Storage Account Container Logs  SQL DB Audit Logs	Azure Audit Logs	Azure Network Flow Logs

This multi-layered monitoring ensures that all potential attack vectors are analyzed, providing robust defense against evolving cybersecurity threats.