29 September 2020
This is the final part of a 5-part series on AWS exploits and similar findings discovered over the course of 2020. All findings discussed in this series have been disclosed to the AWS security team and had patches rolled out to all affected regions, where necessary. A big thanks to my friend and fellow Australian Aidan Steele for co-authoring this series with me. Check out parts 2 and 4 for his work!
In the final part of this series we take a look at an exploit that let us tag S3 buckets without permission, even with an explicit deny, and what this means for attribute-based access control (ABAC).
I recently embarked on a project that attempts to generate detailed IAM policy statements given a defined CloudFormation template. I admit this was a little too ambitious and this didn’t get too far, but the process required me to create valid CloudFormation templates which hit every possible field for a resource type so I could incrementally determine what permissions were needed on a field-by-field basis.
When performing this for the AWS::S3::Bucket type, I eventually had a template where I had to define the Tags field. To my surprise, the stack successfully updated without the s3:PutBucketTagging permission I expected to require (as referenced in the ARC documentation).
After some testing, I determined that S3 buckets within a stack could have its tags modified without the presence of the tagging permission, or even if an explicit deny IAM permission is set. I could also bring existing S3 buckets into a stack using the CloudFormation import feature and adjust tags for the imported resource.
I never had the exact reason for this discrepancy explained to me, but my theory relates to the automatic application of stack tags to supported resources within a stack. These stack tags are prefixed with aws:, which is a prefix that standard users are not permitted to use. I believe that the application of these stack tags are performed through an internal endpoint and that perhaps the S3 tag application was also occurring through this endpoint, which means that the usual automated reasoning was not being performed - however this is just a theory.
I raised the issue directly with the AWS security team, who got back to me within a day.
This issue had some complications that led to a couple of delays with the rollout likely due to the fact that some in-depth analysis was occurring to determine which customers would be affected and, if necessary, reach out to them to ensure their workloads wouldn’t be affected by providing remediation steps. Per those communications, it seems RDS and ELB had similar issues.
If users attempt to perform the S3 action today, they’d receive the following stack event:
This incident did not change my view on ABAC and only strengthened my beliefs that it is a high risk approach for the security of your cloud resources. The AWS team publish great content on how the ABAC model improves agility however I strongly believe that at this point tags are a tool for auditing, billing and automation - not for access control.
With the amount of services utilizing tags for their own purposes and subsequently tagging permissions being seen as a low risk permission, I recommend cloud security practitioners stick to traditional resource-based access control. @ me if you disagree!
I was able to work with the teams to get this patched, however it is a good opportunity to revisit your security model if you’re using ABAC in your organization. Many services and methods have functionality that is built with an RBAC model in mind, and you should be vigilant that the assumptions within your environment continue to hold true.
Thanks to the AWS security, S3 and CloudFormation team members who worked with me to help remediate this issue, and thanks for those readers who took the time to read this series. Both Aidan and I enjoyed writing it and I hope you all enjoyed reading it!
✌️
One Cloud Please