Cloud Security
Published in

Cloud Security

Cross account AWS IAM roles with external IDs and MFA

Credentials for cloud penetration tests and security assessments

When 2nd Sight Lab performs cloud penetration tests or cloud security assessments for customers, we ask for credentials with a specific set of permissions to analyze accounts to see if they have any security issues. We look at whether the account is following best practices, review architectural issues, can quickly query the network and IAM access, and check places where developers may be storing secrets in code. Some customers specifically request a penetration test, rather than an assessment or architecture review, because they require one to maintain compliance with PCI, HIPAA, or some other regulation.

We usually combine an assessment of cloud infrastructure with a web application assessment or penetration test because a vulnerable application is one of the gateways into your cloud account. We report external web application vulnerabilities on an assessment. On a penetration test, we attempt to exploit vulnerabilities to demonstrate whether the vulnerabilities provide account or data access. We usually also test the internal functionality of applications. If the developers or DevOps team has configured things correctly, the permissions we obtain should expose no sensitive data. If we can access sensitive data via a misconfiguration or vulnerability, that is one of the things we would let customers know in our report.

Our customers provide different credentials depending on what type of assessment or penetration test they are requesting. They may provide web application credentials to perform testing on web applications to see if one customer can access an account belonging to another customer, escalate privileges to an administrative account. We also use internal credentials to test whether then can obtain access to the host or other things in the cloud environment that should not be accessible. For an AWS account, they can give us credentials via an AWS IAM access key to review the security of the AWS account configuration. As long as these keys are created for a short term (our engagements are most often 2–4 weeks) and deactivated or deleted immediately after, the risk should be low.

However, a better approach is to use a cross-account role. That limits the access to people who have the required access from our 2nd Sight Lab account, rather than anyone on the Internet who can obtain an AWS access key. This post covers access to the AWS accounts using AWS IAM roles. Handling the secure transport of web application credentials or other shared credentials like AWS access keys is not included here. We cover that in our instructions provided to customers, our cloud security class, and may provide that in a future blog post.

Requirements for creating an AWS IAM role for an external account:

  1. An IAM policy that has the specified permissions you want to give the user in the other account.
  2. A role that has the IAM policy assigned to it.
  3. A trust policy that gives access to the other account.
  4. A user in the external account that has permission to assume the role.

Create or select an IAM policy

You can create or select a policy in IAM by choosing policies on the left of the IAM dashboard and either searching for and using a specific policy, or creating a new one. The SecurityAudit policy allows a user to review security in the account. 2nd Sight Lab requests a few other permissions to check for access to secrets and other misconfigurations but limited to read-only access.

Assign the policy to a role and add a trust policy that gives the external account access.

On the AWS IAM console, click Roles. Then click the Create role button.

On the next screen, choose Another AWS account. Enter the AWS account number you want to give permissions to access your account. You may want to include an external ID that you provide to the person in the other account (securely). You may also want to require that the person has authenticated via MFA. Then click Next: Permissions.

Note that the external account assigns MFA to the user that assumes the role, and AWS requires that user to login using MFA via the console and programmatically if you select this option. The following page provides more information explaining why you might want to require an external ID:

https://docs.aws.amazon.com/IAM/latest/UserGuide/id_roles_create_for-user_externalid.html

On the next screen, select the role you created, or choose a built-in role. Below, I am searching for the built-in auditor role. Check the box next to it and click Next:Tags

For our purposes, we are not going to enter any tags. Click Next:Review.

Enter a name and description. Click Create Role.

Now click on your new role name.

Click on the Trust Relationships tab. Here you can see permissions granted to the other account. The screenshot below redacted the account number, which you would see next to the label This account. Click on Show policy document.

That is the trust policy that gives access to the other AWS account (account number redacted below.)

Note that the above policy gives access to root in the external account. You probably want to change that to a specific user or group of users. In our case, we give access to a user named pentester in the external account. Note that the ARN (a unique identifier for something in an AWS account) changes to include the word “user” when assigning the ARN. Unfortunately, it does not appear that we can add an ARN for a group, so every user would need to be added individually.

Set up access in the external account to assume the role

In the external account (in our case, the account owned by 2nd Sight Lab who is performing the cloud penetration test or assessment), go to the IAM dashboard click Policies on the left menu and Create Policy.

On the next screen, click the JSON tab. Enter a policy, as shown. We would enter the customer account number in the policy where indicated below. If the external role requires MFA added a condition to require MFA in this policy as well. You might want to do this in any case. Click Review policy.

On the next screen, create a name and description. Then click Create policy.

Best practice would be to assign this policy to a user in a group. On the IAM dashboard, click Groups on the left. Then click Create New Group.

Enter a Group Name and click Next Step.

Select your new policy and click Next Step.

Click Create Group.

Click on your new group in the console.

Click on the Users tab and then Add Users to Group. If you don’t have an existing user for this purpose, you can create a new one and add it to the group.

Choose the user you want to add to the group. Click Add users.

Now you have a user that can assume the role and perform work in the external account. Note that when adding an external ID, the user can only take programmatic actions and cannot use the AWS console. Stay tuned for more information on this and other cloud security topics.

Teri Radichel

If you liked this story please clap and follow:

Medium: Teri Radichel or Email List: Teri Radichel
Twitter: @teriradichel or @2ndSightLab
Requests services via LinkedIn: Teri Radichel or IANS Research

© 2nd Sight Lab 2020

____________________________________________

Want to learn more about Cloud Security?

Check out: Cybersecurity for Executives in the Age of Cloud.

Cloud Penetration Testing and Security Assessments

Are your cloud accounts and applications secure? Hire 2nd Sight Lab for a penetration test or security assessment.

Cloud Security Training

Virtual training available for a minimum of 10 students at a single organization. Curriculum: 2nd Sight Lab cloud Security Training

Have a Cybersecurity or Cloud Security Question?

Ask Teri Radichel by scheduling a call with IANS Research.

____________________________________

2020 Cybersecurity and Cloud Security Podcasts

Cybersecurity for Executives in the Age of Cloud with Teri Radichel

Teri Radichel on Bring Your Own Security Podcast

Understanding What Cloud Security Means with Teri Radichel on The Secure Developer Podcast

2020 Cybersecurity and Cloud Security Conference Presentations

RSA 2020 ~ Serverless Attack Vectors

AWS Women in Tech Day 2020

Serverless Days Hamburg

Prior Podcasts and Presentations

RSA 2018 ~ Red Team vs. Blue Team on AWS with Kolby Allen

AWS re:Invent 2018 ~ RedTeam vs. Blue Team on AWS with Kolby Allen

Microsoft Build 2019 ~ DIY Security Assessment with SheHacksPurple

AWS re:Invent and AWS re:Inforce 2019 ~ Are you ready for a Cloud Pentest?

Masters of Data ~ Sumo Logic Podcast

Azure for Auditors ~ Presented to Seattle ISACA and IIA

OWASP AppSec Day 2019 — Melbourne, Australia

Bienvenue au congrès ISACA Québec 2019 KeynoteQuebec, Canada (October 7–9)

Cloud Security and Cybersecurity Presentations

White Papers and Research Reports

Securing Serverless: What’s Different? What’s Not?

Create a Simple Fuzzer for Rest APIs

Improve Detection and Prevention of DOM XSS

Balancing Security and Innovation with Event-Driven Automation

Critical Controls that Could have Prevented the Target Breach

Packet Capture on AWS

--

--

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Teri Radichel

Teri Radichel

1.1K Followers

Cloud Security Training and Penetration Testing | GSE, GSEC, GCIH, GCIA, GCPM, GCCC, GREM, GPEN, GXPN | AWS Hero | Infragard | IANS Faculty | 2ndSightLab.com