SaaSpocalypse - The Complexity and Power of AWS Cross-Account Access

AWS is a very complex and ever-changing platform, which presents a challenge to defenders and an opportunity for attackers. Among some of the most complex and powerful features of AWS is its IAM functionality, which allows for very granular control but is famously complex to learn and set up.

One the features of access control in AWS is that AWS accounts are a self-contained unit of processing, storage and access control. Given how AWS itself recommends segregation across accounts as a best practice, and the fact that many SaaS vendors request access to their customers' accounts in order to perform their services, this presents a challenge.

In this talk we will present in detail the policy-fu needed in order to securely allow principals from one account to perform actions on another, both inside different accounts in an organization but especially from the perspective of a SaaS provider that needs to access hundreds or thousands of customer accounts. Existing research on defenses and possible attacks will be presented and demonstrated to illustrate the concepts.

SaaS vendors like ""single pane of glass"" offerings, multi-cloud solutions and CSPM offerings are huge concentrators of risk since they have access to potentially thousands of customer AWS accounts. By exploring how this access can be uniquely secured due to capabilities only AWS provides and how vendors can fail at this we hope to allow attendees to better understand the risks of using these services, and also help service providers mitigate them.

Slide deck for talk presented at DEF CON 28 Cloud Village.

Transcript

1. SaaSpocalypse The Complexity and Power of AWS Cross-Account Access
2. arn:aws:iam:sa-east-1:*:user/AlexandreSieira • Founder @ Tenchi Security • Cloud Security Posture Chiropractor (h/t @swagitda_) • Previously: • Manager of the Product Management Team for the MSS Detect Portfolio @ Verizon • Co-Founder and CTO @ Niddel • Co-Founder and CTO @ CIPHER Security • São Paulo, Brazil 🇧🇷 sts:GetCallerIdentity asieira@tenchisecurity.com @AlexandreSieira
3. Motivation Why should you care? https://attack.mitre.org/techniques/T1199/
4. • AWS accounts are self-contained entities with resources, identities and policies. • Some resources can be shared with other accounts or publicly: S3 buckets, EBS snapshots and EC2 AMIs are common examples. ◦ https://github.com/SummitRoute/aws_exposab le_resources by Scott Piper • Most operations require an identity with privileges, so that’s what SaaS vendors will use. AWS IAM Overview Identities and Resources Theme song of people that do all their work logged in as root…
5. AWS IAM Overview Assuming Roles • Root and IAM user credentials last indefinitely. • AWS Security Token Service (STS) generates temporary credentials from roles. • Roles have three key settings: ◦ Trust policy – who can assume the role. ◦ Permissions policy – what privileges this role has. ◦ Maximum session duration. • Trust policy is not enough, caller also needs privileges to the sts:AssumeRole action.
6. Cross Account Access Option 1: Stored Credentials Customer • Creates an IAM user: ◦ Identity policy assigns privileges needed by SaaS / MSP. ◦ Creates long-lived access keys. • Sends credentials to SaaS / MSP via a trusted channel. SaaS / MSP • Gives workers access to IAM user credentials to perform necessary API calls on customer account. State stored: • IAM long-lived credentials (access key ID, secret access key).
7. Cross Account Access Option 1: Stored Credentials SaaS / MSP • Gives workers access to IAM user credentials to perform necessary API calls on customer account. State stored: • IAM long-lived credentials (access key ID, secret access key). SECRET!!!
8. Cross Account Access Option 2: naïve cross-account access Customer • Creates a cross-account access role: ◦ Trust policy allows SaaS / MSP account ID to assume it. ◦ Permissions policy assigns privileges needed by SaaS / MSP. SaaS / MSP • Grants workers sts:AssumeRole privileges on the customer role. • Uses temporary credentials to perform necessary API calls on customer account. State stored: • Customer role ARN (arn:aws:iam::account-id:role/role- name-with-path)
9. Cross Account Access Option 2: naïve cross-account access SaaS / MSP • Grants workers sts:AssumeRole privileges on the customer role • Uses temporary credentials to perform necessary API calls on customer account. State stored: • Customer role ARN (arn:aws:iam::account-id:role/role- name-with-path) NOT A SECRET!!!
10. Cross Account Access Confused Deputy Problem • Pre-requisites: ◦ Attackers obtain account ID of target. ◦ Customer has naïve cross-account access to SaaS / MSP. • Attack: 1. Attacker on-boards target account on SaaS / MSP claiming to own it. 2. SaaS / MSP accesses target account through cross- account access. 3. Attacker obtains information or functionality intended exclusively for target via SaaS / MSP.
11. Cross Account Access External ID
12. Cross Account Access Option 3: External ID as Proof of Ownership SaaS / MSP • Assigns unique external ID to customer and ensures it is required in the trust policy. • Grants workers access to external ID and sts:AssumeRole privileges to the customer role. State stored: • Customer role ARN. • External ID. Customer • Creates a cross-account access role: ◦ Trust policy allows SaaS / MSP account ID to assume it if correct external ID is provided. ◦ Permissions policy assigns privileges needed by SaaS / MSP.
13. Cross Account Access SaaS / MSP • Assigns unique external ID to customer and ensures it is required in the trust policy. • Grants workers access to external ID and sts:AssumeRole privileges to the customer role. State stored: • Customer role ARN. • External ID. STILL NO SECRETS!!! Option 3: External ID as Proof of Ownership
14. Cross Account Access Role Requires External ID? No Yes Correct External ID passed to sts:AssumeRole? Yes No 🛑
15. Cross Account Access Vendor Worker Privileges
16. Cross Account Access SCP Fail
17. Cross Account Access CloudTrail is Your Friend
18. Cross Account Access Incorrect Implementations • Kesten Broughton from Praetorian published amazing research on this: https://bit.ly/xacct_assume_role • Out of 200 vendors tested: ◦ 50% only work with IAM user credentials; ◦ 50% use assumed roles, and of those: ▪ 98% don’t check whether customers actually added external ID as a condition on the trust policy. ▪ 37% allow use of arbitrary external IDs on the UI. ▪ 15% unwittingly allow use of arbitrary external IDs through various other means. @kestenb
19. Cross Account Access PRIVILEGES
20. Cross Account Access
21. Cross Account Access
22. Cross Account Access • Prior and regular review of new 3rd party access to AWS accounts: ◦ Ensure business need and least privilege. ◦ Use CloudSplaining (https://github.com/salesforce/clo udsplaining) by Kinnaird McQuade. ◦ Use Parliament (https://github.com/duo- labs/parliament ) by Scott Piper. • Monitor using CloudTrail. Recommendations for Customers
23. Cross Account Access Recommendations for SaaS / MSP • Minimize privileges asked of customers. • Impose unique external IDs chosen by your back-end (random UUIDs also an option). • Ensure customers correctly implemented the trust policy. • Use CloudFormation to automate customer setup. • Limit attack surface and blast radius at the account customers trust. • Monitor using CloudTrail.
24. Questions? asieira@tenchisecurity.com @AlexandreSieira