Last week, vpnMentor’s research team published their findings around Pray.com’s data leakage. The leakage contained private data belonging to millions of users, including privately identifiable information like names, phone numbers, home addresses, email addresses and more. Some users of Pray.com chose to allow the app access to their phonebook, and so the buckets contained these contacts as well.
The vpnMonitor team assumes 10M users were affected and had their data leaked. According to the research, the Pray.com application was running on AWS infrastructure, using the S3 bucket for storage behind CloudFront, but unfortunately, had those misconfigured.
S3 Bucket and CloudFront Configurations
Image:vpnMonitor
S3 bucket is a very popular storage service provided by AWS. Among its many applications, it can be used to access static content. Connecting the bucket to Amazon CloudFront enables a secure and scalable connection, as the data is cached in various locations worldwide and users can access it easily and quickly.
Image:vpnMonitor
Due to many misconfiguration mistakes in the past, AWS made major improvements to the S3 bucket service, making it close to the internet by default. Should a user want to open it, they will be notified and asked to approve this step. In addition, the bucket will be marked.
So if you need to create an application that uses an S3 bucket and CloudFront, what would be the best way to protect it and provide access?
OAI (Origin Access Identity) – to make sure users access files stored in the S3 by using CloudFront URLs and not the bucket URL. This mechanism can be used for Get and Put actions altogether, but prevents unauthorized access directly to the bucket. The bucket policy would look like this:
If we look at the bucket protected by OAI we’ll see that AWS points out that the bucket is not public, but with the appropriate permissions, access can be granted. In this case, using the bucket URL will not allow access to the bucket and anyone who wants to access it will need the URL to CloudFront from the OAI.
Another popular and unsecured method, is using AWS managed policies. Many choose this route as they believe AWS is creating least-privileged policies. Unfortunately they often contain excessive permissions that are unnecessary for the use-case and in fact permit the executing of excessive actions that can lead to data leakage or disruption of business. In the Pray.com incident we can tell if any of these were used, but using policies like CloudFrontFullAccess or AmazonS3FullAccess can be exploited for such actions.
To sum up, storing data in the cloud makes it accessible easily and quickly from anywhere in the world. But with great power comes great responsibility, and we need to insist we only grant the relevant and least-privileged security policies, to make sure we protect our users, our data and our business. Solvo is here to create least-privileged security configuration for your cloud application, automatically and at scale. To check your cloud security configuration, visit our website and make sure you request a demo,