Last week, Skyhigh’s Cloud Security Labs published a discovery called GhostWriter, an S3 man-in-the-middle (MITM) exposure, whereby misconfigured S3 Buckets allow public writes, which can be used by a bad actor to leverage & launch a MITM attack. You can read more about it here.
Given that the exposure is created by S3 Bucket permissions that are misconfigured by customers, Skyhigh is providing the following guidance on AWS S3 Bucket permissions, in order to help you eliminate your company’s exposure to GhostWriter.
AWS S3 Bucket permissions overview
There are multiple ways one can grant access to a S3 Bucket and the objects within a Bucket. We will go through the different constructs and how they impact the final decision on whether access needs to be granted to the principal requesting access to a S3 resource, in this case a Bucket, or an object within a Bucket. The three different constructs which can be used to control access to S3 resources are:
- Access Control Lists (ACL)
- S3 Bucket Policies
- IAM Policies
Let’s take a look at each of them in brief
Access control lists
ACLs are a legacy access control mechanism which predate IAM. ACL’s are attached to every S3 Bucket and object and define which AWS accounts or groups are granted access. When a Bucket or an object is created, S3 automatically creates a default ACL and grants the resource owner full control.
AWS recommends using S3 Bucket policies or IAM policies to define access control. However, if ACL’s are sufficient then you can just continue using them. If you need to manage permissions on individual objects within a Bucket you can use ACL’s to do that whereas Bucket policies can be applied only at the Bucket level. There are four permissions which can be specified using ACLs and you cannot explicitly deny them:
- Read Bucket Permissions
- Write Bucket Permissions
ACLs can be used only to grant access to other AWS accounts but you cannot use ACLs to grant permissions to users in your AWS account. Think of ACLs as coarse-grained access control mechanisms, whereas S3 Bucket policies and IAM policies are more fine-grained.
S3 Bucket policies
S3 Bucket policies define which actions are allowed or denied for principals within an S3 Bucket (e.g. allow user Tom to PUT objects in a Bucket or allow user John to GET objects in a Bucket). Below is an example of a Bucket policy, which grants both PUT and GET to all users by specifying the wild card character for the principal.
S3 Bucket policies are attached to a Bucket as the name implies and cannot be attached to the objects within a Bucket, but the objects within a Bucket get the same permissions as the Bucket. Bucket policies are written in JSON using the AWS Access Policy Language.
IAM policies define which actions are allowed or denied on an AWS resource, thereby specifying what a principal can do in an AWS environment (e.g. allow TerminateInstance on EC2 instances or PUT Object on a S3 Bucket). You attach IAM policies to IAM users, roles, or groups, which are granted the permissions defined in the policy.
Below is an example of an IAM policy, which allows all actions on the Bucket and its contents. Note that there is no principal element here, compared to a Bucket policy, as the principal will be the entity to which this policy will be attached.
How does authorization work in AWS
Given the various mechanisms available with which to define access control, AWS determines access by evaluating all the applicable policies, both IAM and S3 Bucket, plus the ACLs applicable on the Bucket or object for which access has been requested for. Since there can be multiple allow or deny permissions defined in each policy or ACL, AWS applies what can be thought of as a policy-combining algorithm, the default one being Deny-Overrides. What this means is that if there is one explicit deny permission defined the end result is always deny. If there is no explicit deny and an explicit allow specified, the final decision will be allow.
Understanding ACL permissions
As we noted in the ACL section, there are four different permissions that can be set on the Bucket:
- List Objects – Allows the grantee to list the objects in a Bucket.
- Write Objects – Allows the grantee to upload, create or modify files within a Bucket.
- Read Bucket Permissions – Allows the grantee to read the Bucket ACLs. This gives the grantee the ability to find out accessible resources.
- Write Bucket Permissions – Allows the grantee to edit/update the Bucket’s ACLs. This is the permission that, when misconfigured, creates the GhostWriter exposure. It allows the grantee to modify the Buckets and its objects. A bad actor can use this permission to hijack control over Buckets or objects if this permission is set to the default groups like All Users or Authenticated Users.
Default User Groups in AWS
Let’s understand the two user groups in this context which we will be talking about.
- All Users – This group represents anyone in the world and granting permissions to this group can be risky. The requests can be authenticated or anonymous. It is recommended that no permissions are granted to this group. This is represented by http://acs.amazonaws.com/groups/global/AllUsers
- Authenticated Users – This group represents all AWS accounts, not just those in your organization, and any AWS user will get the permissions granted for this group, though the requests have to be authenticated. This is represented by http://acs.amazonaws.com/groups/global/AuthenticatedUsers
How to discover if your Buckets are exposed to GhostWriter
Skyhigh has assessed the approximately sixty five thousand S3 Buckets accessed across our customer-base, to determine which one are exposed to GhostWriter. We decided to check for the vulnerabilities across these Buckets. Based on our assessment, about 5.4% of them have ‘Read Bucket Permission’ enabled for the default group ‘All Users’. Similarly, 5.5% of them have ‘Read Bucket Permission’ enabled for the group ‘Authenticated Users’. Here are some of the aggregated stats:
- Publicly writeable Buckets – 2.2%
- Publicly writeable Bucket ACLs – 1.9%
- Buckets writeable by AWS Users – 0.8%
- Bucket ACLs writeable by AWS Users – 0.6%
As an example, one of the Buckets being used by a leading fact checking website was hijacked to mine crypto currency. Similarly we have found that many leading media websites also have S3 Buckets that are exposed to GhostWriter.
How does Skyhigh help remediate this problem
Skyhigh provides its customers with the ability to view the Buckets which are exposed to the MITM attack vector based on the permissions that we discussed above. Skyhigh then enables customers to block employees from accessing exposed Buckets.
The screen shot below shows a sample list of Buckets and depicts how users can select a subset of the Buckets and choose to block access to them via policies in their egress devices.
To ensure that your own company’s S3 Buckets are not exposed to Ghostwriter, users can use the policy “Publicly Writeable S3 Buckets” in the Configuration Audit section of the Skyhigh for AWS product to discover the Buckets which are affected by GhostWriter, as shown below:
Once users have imported and execute the policy, the results of the policy execution will show the Buckets which are affected by GhostWriter as shown below:
Skyhigh believes that it is our responsibility to help the cybersecurity community eliminate the GhostWriter exposure. If you are not a current Skyhigh customer, but would like Skyhigh to perform a free GhostWriter exposure assessment for your organization, please register here.
CASB Magic Quadrant 2019 is here – McAfee a Leader for third consecutive year
CASB RFP Template: 200+ Common Questions Enterprises Are Asking
9 Cloud Computing Security Risks Every Company Faces
Office 365 Security Concerns: Download Definitive Guide to Office 365 eBook
51 AWS Security Best Practices