Cross account AWS IAM roles with external IDs and MFA

Credentials for cloud penetration tests and security assessments

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

⚙️ Check out my series on Automating Cybersecurity Metrics. The Code.

🔒 Related Stories: Cloud Governance | IAM | AWS Security

💻 Free Content on Jobs in Cybersecurity | ✉️ Sign up for the Email List

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

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.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2020

About Teri Radichel:
~~~~~~~~~~~~~~~~~~~~
⭐️ Author: Cybersecurity Books
⭐️ Presentations: Presentations by Teri Radichel
⭐️ Recognition: SANS Award, AWS Security Hero, IANS Faculty
⭐️ Certifications: SANS ~ GSE 240
⭐️ Education: BA Business, Master of Software Engineering, Master of Infosec
⭐️ Company: Penetration Tests, Assessments, Phone Consulting ~ 2nd Sight Lab

Need Help With Cybersecurity, Cloud, or Application Security?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
🔒 Request a penetration test or security assessment
🔒 Schedule a consulting call
🔒 Cybersecurity Speaker for Presentation

Follow for more stories like this:
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ 
❤️ Sign Up my Medium Email List
❤️ Twitter: @teriradichel
❤️ LinkedIn: https://www.linkedin.com/in/teriradichel
❤️ Mastodon: @teriradichel@infosec.exchange
❤️ Facebook: 2nd Sight Lab
❤️ YouTube: @2ndsightlab