How it happens: Internal S3 Buckets Exposed via Public EC2 Instances

circle
circle

In this query and graph walk-through, we'll be looking for internal S3 Buckets that are accessible via a public EC2 instance. This approach to accessing an S3 Bucket was responsible for one of the major data breaches at an international financial organization. It is something that flies under the radar of most security organizations. With the query language of JupiterOne, the ability to traverse the graph and see how instances are connected to the internet, and also connected to roles having access policies connecting to S3 Buckets is very simple. 

The Query

FIND Internet 
THAT ALLOWS aws_security_group
THAT PROTECTS aws_instance with active=true
THAT USES aws_iam_role that assigned AccessPolicy
THAT ALLOWS (aws_s3|aws_s3_bucket) with classification!='public'
RETURN TREE

Start the query with FIND Internet allowed by a security group, THAT ALLOWS aws_security_group.   Those AWS security groups should protect those instances that are active, THAT PROTECTS aws_instance with active=true.  These are instances that are truly exposed to the internet. Those instances use iam roles that are assigned iam policies, THAT USES aws_iam_role that assigned AccessPolicy, that allow S3 access, THAT ALLOWS (aws_s3|aws_s3_bucket) with classification!='public' to the service or specific buckets that are not public buttons.   

This query will give us a problematic list, which can be viewed in a graph.

Analyze the results graph

The resulting graph from the J1 Query gives a dependency graph for tracing and eliminating connections that will expose internal S3 Buckets. The first segment of the graph shows that the security group has egress rules and ingress rules that include 0.0.0.0/0

Internal S3 Buckets Exposed - 101

It is protecting an active instance.

Internal S3 Buckets Exposed - 102

The instance has a role assigned to it...

Internal S3 Buckets Exposed - 103

... that has an iam role policy attached to it.

Internal S3 Buckets Exposed - 104

... that allows specific actions on this S3 Bucket.

Internal S3 Buckets Exposed - 105

The outcome of this graph is to show that even though this S3 Bucket is not public, it can be accessed via the EC2 instance that is public.

Conclusion

What was shown here was responsible for one of the largest, financial institution breaches in recent history.

Use J1 Queries and examine the graph output quickly and simply protect our buckets against unwanted public exposure. The query outlined here is part of our S3 Dashboard, which is part of the free, lifetime license for using JupiterOne. This dashboard can be used in the J1 interface, or downloaded from GitHub.

Internal S3 Buckets Exposed - 106

 

avatar

Posted By Akash Ganapathi

Akash Ganapathi comes from an enterprise security, data privacy, and data analysis background, working exclusively in the B2B software solutions space throughout his career. He is currently a Principal Security Solutions Architect at JupiterOne.

To hear more from Akash, get our newsletter. No spam, just the good stuff once or twice a month. Sign up below.

PREVIOUS ARTICLE