26 Oct Design flaws that cause security vulnerabilities in Amazon S3 security
Design flaws that cause security vulnerabilities in Amazon S3 security
Amazon S3 is one of the popular cloud storage and cloud computing solutions that are used by a plethora of organisations for their storage and IT operations. It is preferred as S3 offers scalability and flexibility which reduce the operation cost and the effort required to run install and implement an on-premise security system. Amazon S3 is secure by default. The resource owners have the sole ownership of the S3 resources once it is created. Amazon S3 supports user access management and user authentication to protect its resources and data from unauthorised access. Bucket policies and Access Control lists (ACLs) are used as control access mechanisms to grant access and permissions to users. Amazon S3 console brings to your notice the organisations publicly accessible buckets, the source of the access and also lets you know of any changes to bucket policies which would make your bucket publicly accessible.
Using cloud solutions is like a double-edged sword. Its scalability and flexibility have made it easy to perform complex IT solutions such as host humongous amount of data and deploy sites and applications in no time. On the other hand, it has become easier for attackers due to large attack surface area to exploit vulnerabilities and launch a full-scale attack.
Security Vulnerabilities in Amazon S3
Over the years misconfiguration of S3 security settings has caused a lot of data breaches. AWS recently announced public access settings for S3 buckets. These newly created S3 buckets and objects are private and are protected inherently. The ACLs and policies provide organisation with flexibility. The organisations can grant permissions to multiple accounts, restrict access to specific users through their IP address blocking and use user authentication. The misconfiguration and leaky buckets have caused following data breaches.
- 540mn records were exposed from multiple third party developed Facebook apps.
- Go Daddy’s data exposure which included trade secrets and detailed infrastructure information.
- Pocket INet whose 73GB of data was exposed including passwords and AWS secret keys.
- A breach by Localblox, a private intelligence platform that exposed 48 million records of detailed personal information on tens of millions of individuals, gathered and scraped from multiple sources.
- The exposure of 14 million customer records by telecommunications carrier Verizon, an example of how third-party risk contributes to this problem.
- Viacom, who left a trove of system credentials and critical application data exposed in an open S3 bucket.
- The Tea Party Patriots Citizens Fund, who leaked the personal details of 527,000 individuals in a misconfigured S3 bucket.
Though S3 ensures that servers are private and are protected b y default, yet there are many leaky buckets and data breaches. The design of AWS S3 causes misconfiguration of buckets through the user’s side and make them publicly available and accessible. The 2 key product features that S3 provides are the main reasons for misconfiguration: Any authenticated user: This any authenticated user feature gives way to common misconfiguration problems. This feature allows or enables any user with an AWS account not just in your organisation but across the world to access your bucket after account set up. This feature causes significant number of breaches as this is a user side misconfiguration and is commonly misunderstood. Inconsistent ACL and bucket policies: Uncertain Access control list along with conflicting policies governing the buckets have caused bucket misconfiguration. The bucket policies are not accessible to the organisation and are written using JSON syntax which is secure and obscured which makes governing the bucket policies inflexible. This can leave scores of data open and accessible to the public which results in data breach.
Steps taken by AWS to make S3 more secure
AWS has announced multiple changes since 2017 that gives assurance of addressing misconfiguration issues and flexible bucket policies. It has helped in:
- Providing a “public” flag for open buckets, and an email outreach campaign to owners of those buckets.
- A machine learning security service named Macie that automatically discovers, classifies and secures sensitive and critical data in AWS.
Though these measures helped in eliminating bucket exposure, but there are still many buckets that have sensitive data and are yet to be secured since it is a user side misconfiguration and AWS cannot do anything about the publicly exposed and accessible data.
Mitigating the vulnerabilities
The following steps can be implemented to avoid misconfiguration from the user side Grant access permissions to your buckets and objects by using resource-based access policies. Focus primarily on
- Blocking public access.
- Editing bucket public access settings.
- Setting object permissions.
- Setting ACL bucket permissions.
- Adding a bucket policy.
- Using Access Analyzer for S3.
Will the new security features benefit?
The new security features will have minimal impact as more and more buckets will be secured but not all. For instance, your web application performs a service that imports data from a bucket. If for some reason the company running the service decides to remove the bucket either inadvertently or as a part of system reconfiguration, the bucket then becomes available and can be written upon by an attacker. A malicious code can be then written on the bucket that is accessible which may lead to an attack and data breach.
Essentially, if admins are not well educated or aware about properly configuring an S3 bucket, they hardly take the time out to learn, which puts everyone’s data at risk. As long as it is easy to misconfigure systems, the organisation will do so unknowingly. Adding new features makes it easy to configure S3 storage privately but does not remove the possibility of public access of configured buckets inadvertently.
Whatever measures amazon is undertaking to address the issue don’t seem to be enough to stop a barrage of attacks and data leaks through misconfigured buckets. The Amazon approach still seems to blame the user side misconfiguration as the main reason for leaks rather than the S3 design flaws. The organisations can expect their data to be accessible or exposed to public for attackers to carry out their criminal activities in future until and unless the design flaws are ironed out.
