Creating an Initial Admin Role Credentials For Automation With MFA

ACM.376 Leveraging the “adminroot” credentials to deploy initial resources for an organization

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

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

🔒 Related Stories: AWS Security | Secure Code | IAM

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

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

In the last post I deployed an Organization with CloudFormation for a new or existing organization so we can use it in our policies.

In this post, I want to revisit using a container to deploy AWS resources using the rootadmin user we created and create automation credentials.

Note: I have a link to some updates at the bottom of the post.

Consider our policies in the post where I assigned permissions to the rootadmin user directly. If there was some sort of emergency, the rootadmin user could login and perform various actions in the AWS console. Requiring MFA in the console would work.

What the user cannot do would be to leverage developer credentials with an AWS CLI profile using those policies. Why?

Recall that MFA required for developer credentials without boolifexists doesn’t work. And using boolifexists is a flawed approach if you are trying to restrict automation actions with MFA.

Why? Because when you use developer credentials no indication of MFA exists either way. It’s just not there. The flawed logic with boolifexists is that if there’s no MFA indicator we’ll just let the action occur. What?

To enforce MFA with developer credentials, you enforce MFA to assume a role. No one can assume the role without MFA so they can’t use the permissions without MFA.

Note: I’m only talking about the scenario where an attacker steals developer credentials. If the attacker gets a handle on an active session, MFA doesn’t matter for the length of the session. I explained different types of attacks in prior IAM posts which you can get to via the links at the top.

To require MFA to perform AWS CLI actions with developer credentials, we will need to define a role that the rootadmin can assume with MFA. The trust policy for the role will require MFA. Once the rootadmin has assumed the role, MFA is no longer required and they can use the CLI for the length of the assume session to perform whatever actions the role can assume.

In this post I want to add a role and role policy that allows the root admin to programmatically create new roles in the root account, with a required permission boundary.

Deploy a rootadmin role

I already have a template for creating a role, but not for this specific scenario. I can copy my GroupRole and make a few adjustments.

I create the file in the following location:

/resources/iam/role/rootadminrole.yaml

Add a new command to the deploy script to deploy the role.

That deploys my role.

Deploy the rootadmin role policy

The reason the rootadmin user needs a role is to automate the creation of some other resources to build out our initial organization. Rather than try to figure out all the permissions at once, I’m going to add them as they are required.

The first thing the role needs to be able to do is to deploy other administrative roles in the root account but only with a permission boundary.

After initial testing, I came back and added additional role permissions I might need. I also may have to remove the Permissions Boundary restriction off some of these actions.

This role needs to be able to deploy resources via cloudformation, but only with a “rootadminrole-” prefix.

Add a command to the deploy script to deploy the role policy.

Role policy deployed:

Making sure the role cannot modify root resources

Now wait. The rootadmin user cannot change its own permissions but what about if it assumes the rootadminrole? There are no such restrictions on modification of root resources in this policy. But really, every role we create should not modify any resources created by the root user. So for that we can make sure those actions are disallowed in our Permissions Boundary created in a prior post.

Then we can apply that permission boundary to the rootadminrole.

Update the rootadmin user policy

Now along the way, I realized that I needed to allow the GetAccountPasswordPolicy without MFA and I need to allow the user to change their password without MFA if I require that on first login. There are a lot of conundrums related to assigning passwords to new users on AWS. Those risks are limited in part by processes, monitoring, and alerts not technology as explained in prior posts due to the way AWS works.

I also simplified my policy in some ways to try to make it more clear.

I’m still allowing all actions with MFA which will work in the console.

I’m allowing the user to change their own credentials.

I’ve hardcoded the user in here since all other policies will disallow actions on this user except for what the root user can do in this account.

I’m disallowing any CloudFormation actions on the root stacks except read-only actions.

The rootadmin user can look but not touch when it comes to the stacks and resources created by the root user.

Test initial access

To test initial access I logged in as the rootadmin user and reset the password. That’s when I realized I was missing a few of the actions above.

Next I added hardware MFA. The name of the hardware MFA device can be anything.

Then I added a virtual MFA device which must match the user name.

Next I attempted to assume the rootadmin role in the console.

That worked but I’m pretty much denied access to everything — which is fine and good actually. Because this role is for automation, not for use in the console.

Next I switched back to the rootadmin user and created developer credentials.

All that worked.

Now I have to test my role assumption via the CLI and try to create some roles in the root account with my rootadmin developer credentials. I’m going to work on creating my container and deploying that from another AWS account. You could also do that from a container on your desktop — or any machine where the AWS CLI exists and you have valid credentials and network access to the account.

I tested these out over time and eventually made a few additional updates documented here, including limiting this user to modifying its own CloudFormation stacks only but to view and detect drift on any stack.

Follow for updates.

Teri Radichel | © 2nd Sight Lab 2023

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