Misconfigured S3 buckets have led to major hacking incidents, for which the Magecart Group has been largely responsible. The Capital One data breach (100 million customers impacted), Facebook data breach, the Honda database leak, and the data breaches at British Airways, Ticketmaster, and numerous other companies – were all incidents due to misconfigured Amazon S3 buckets. While the blame cannot be put squarely on Amazon (which issues plenty of documentation on how to secure S3 buckets), it is the responsibility of the companies who avail of S3 services from Amazon. In this article, I will cover the functions of the S3 buckets, how cloud storage repositories become vulnerable, and how to secure S3 buckets.
By Brian Pereira, Principal Editor, CISO MAG
S3 buckets are an object storage service offered by Amazon called Simple Storage Service (S3). It is cloud storage. At some point traditional, on-premise databases could not handle the immense scale required by modern enterprise applications served to millions of users, and hence storage technology had to evolve. Mobile applications and big data analytics on cloud also require object storage. And then there is the explosive growth of data generated by users and IoT devices. Scalability is a key advantage of cloud computing and services like Amazon S3 can handle mega databases with billions of records. The other advantage of cloud storage services is high availability. Amazon, for instance, claims to offer 99.999999999% (11 9’s) of “durability,” though there have been occasional outages.
Why Do S3 Buckets Get Hacked?
S3 buckets are storage repositories or storage containers on the cloud, which means they could be accessible to anyone, unless the administrators configure the S3 buckets and their Access Control Lists (ACLs) to give explicit or exclusive access to certain users. More often than not, this configuration is not correctly done, and hence S3 buckets become vulnerable.
Amazon S3 access control lists (ACLs) enable you to manage access to buckets and objects. Each bucket and object has an ACL attached to it as a subresource. It defines which AWS accounts or groups are granted access and the type of access. When a request is received to access a resource, Amazon S3 checks the corresponding ACL to verify that the requester has the necessary access permissions (Source: Aws.Amazon.com).
When you create a bucket or an object, Amazon S3 creates a default ACL that grants the resource owner full control over the resource.
Let’s step back and explain what all that means.
Almost every organization has its IT infrastructure deployed on the cloud today. Virtual Private Clouds (VPCs) are like private clouds hosted within the public cloud. VPCs are private and secure spaces for organizations, on the public cloud, and are not to be confused with the private cloud. A private cloud, on the other hand, is single-tenant and exclusively for the use of one organization. Public clouds are multi-tenant and shared.
If an organization has a VPC, on say, the Amazon Public Cloud, then its ecosystem of employees, partners, and customers will access its resources on the VPC via a gateway. The VPC itself is divided into logical segments called subnets (security groups). Technically, a subnet is a range of reserved IP addresses within a network that is not available to everyone within the network. Subnets divide part of the network for private use. Similar functions and resources are grouped in a subnet. But to access those resources, users need to go through an ACL that specifies who is allowed to access which resource in that subnet.
The problem is ACLs and S3 buckets are poorly configured, and the cloud customer is to blame. By default, S3 buckets are private and secured, but someone in the organization (or a consultant) changes the security settings, leaving the buckets exposed. It allows even unauthorized persons (hackers) to get in and access storage repositories in the subnet.
What Can You do to Protect Your S3 Buckets?
In 2017, Amazon introduced encryption and other features to secure S3 buckets. They also offer guidance and advice, like AWS Config to monitor for and respond to Amazon S3 buckets allowing public access.
So, the first step to securing S3 buckets is to take advantage of all these features by reading the Amazon documentation and following the instructions.
Always comply with the Amazon S3 policies to define who can access the objects stored within the bucket. Train your IT and security teams to never open access to the public, unless necessary. Open access will expose PII and other sensitive data. Be sure to take advantage of capabilities like AWS Config to prevent unauthorized access to your data.
Document these best practices and create policies. Train your IT staff to follow these policies. The actions of third parties, such as consultants, should be closely monitored. If they have high-level access to your storage containers, check what kind of configuration changes they are making.
Closing notes
Protecting S3 buckets is about careful configuration — don’t ever expose your storage containers to the public. Train your IT staff in the nuances of security configurations and keep a Hawkeye on anyone who has access to S3 configurations and ACLs.
About the Author
Brian Pereira is the Principal Editor of CISO MAG. He has been writing on business technology concepts for the past 26 years and has achieved basic certifications in cloud computing (IBM) and cybersecurity (EC-Council).
