SSRF Defense Step 1: Protect Data Storage Targets

In previous posts Rich Mogull discussed using IAM Roles to break the attacker kill chain in AWS. We are excited to announce that DisruptOps now supports guardrails to automatically ensure you’re not exposed to these issues. We’ll be releasing a number of different guardrails and today I want to discuss the first one, which addresses how to protect data storage targets.

The Problem

In any attack scenario, the first step is to understand the attacker’s objectives. More often than not the goal is data theft, making data repositories their highest target priority. In AWS Amazon S3 and DynamoDB are two of the largest, most valuable data repository platforms, which are directly accessible using Amazon’s APIs and inherent IAM. This makes them different than databases hosted on RDS, which use old-school SQL queries and authentication. But this direct Internet and API access leads to new types of exposures on S3 and DynamoDB, which require new kinds of defenses.

Rich’s blog post discusses non-traditional ways the metadata service can be used to gain access to credentials that allow for API access, including making remote calls to an S3 bucket or DynamoDB databases.

Breaking the Kill Chain

Breaking the kill chain involves analyzing the data storage protection configuration across a number of different areas:

First you need to identify all EC2 instances and ECS tasks/hosts with IAM roles to determine whether the instance profile allows S3 or Dynamo access. If they allow access you need to check for resource restrictions on the number of buckets or tables accessible to determine whether the IAM role allows overly broad access.

  • D:Ops Guardrail – If any container instances were found with excessive access to S3 or Dynamo, restrict the IAM role data access policy to specific ARNs or remove the exposed data actions from IAM statements. Either action will rectify this issue.

Next you should determine if there is a VPCE in the VPC/subnet for the instance, but only if the instance has S3 or Dynamo access in the first place. A VPCE provides a “gate” we can use to further layer in defenses.

  • D:Ops Guardrail – If an instance with access to S3 or Dynamo is not protected using a VPC endpoint with a restrictive policy, create a compliant VPC endpoint with ARNs of DynamoDB tables or S3 buckets to restrict data exposure from EC2 and ECS.

Finally, if there is a VPCE, determine whether it has any access policies to restrict resources. Ensure you take into account rules for the IAM policies from the first step. A VPCE access policy adds a backstop to IAM and can catch access from any over-privileged instances in the VPC.

  • D:Ops Guardrail – If any S3 bucket or Dynamo DB has a misconfigured VPC endpoint policy this guardrail restricts access to specific ARNs using the policy or removes the data actions from the IAM statements.

Check back soon to see other SSRF Defense functionality we are releasing. Or try our platform free and use the new analysis on your own cloud. It takes less than 20 minutes and no resources to start using our product.

View this Op

Learn More About This Guardrail

Read more about what this guardrail does, what type of automated actions
can be enforced upon the found issues, or simply test drive it in your environment.
View this Op

Leave A Comment

nineteen − 13 =

About the Author: Ty Murphy

Ty Murphy
As the Director of Marketing at DisruptOps, Ty oversees all the corporate and digital product marketing initiatives for the company. Previously, Ty helped start-up the 2nd largest value added cybersecurity reseller in Kansas City, before managing the global marketing efforts for an Israeli-based security automation company. Ty brings over a decade of enterprise software security marketing experience to DisruptOps. Outside of work, Ty is an aspiring golf enthusiast and enjoys time outside with his family and traveling to the beach.

Sign-up for Updates!

  • This field is for validation purposes and should be left unchanged.


Related Posts