Slide deck of the presentation at DEF CON 28 "Safe Mode" Cloud Village by Alexandre Sieira. 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.

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
RoleRequiresExternalID?
NoYes
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