Testing the AWS Organizations Role With an SCP That Enforces MFA

ACM.404 After applying an SCP that requires MFA for all non-role actions, how does the AWS Organizations cross-account role work?

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

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

🔒 Related Stories: Bugs | AWS Security | Secure Code

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

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

In the last post I added a service control policy (SCP) that enforces MFA for all actions except those taken by roles (hopefully). I still need to test it out.

In this post, I want to test accessing the AWS Organizations role deployed with my orgadmin account. I explain what that account is and how I’m using it here:

The AWS Organizations role gets automatically deployed when you add a new account to an AWS Organization. You can define the name of the role, which I did in my CloudFormation template. Then I set the name of the role in the stack outputs so it’s easy to see the AWS Organizations role for any account.

Here’s what I don’t know for sure based on the AWS documentation. It says (at the the time of this writing) that the management account is not affected by AWS SCPs.

The role we are going to assume is not in the management account. It is in a child account. But the user that will assume the role is in the management account.

• So does the MFA policy apply because the assume role action happens in the child account?
• Or does the MFA policy not apply because the user taking the action is in the management account?

First I will try to switch roles using the AWS console. That should work because my AWS Console requests should include MFA.

I explained how to switch roles in the AWS console here:

That works.

Now I’m going to switch back and try to use credentials without MFA for the AWS CLI. I’ve explained these things many times but I’m going to explicitly show what I’m doing again here so you can see the difference.

I am going to use developer credentials for my rootadmin user to configure an AWS profile. I head over to the IAM dashboard (not to be confused with AWS SSO or AWS Identity Center).

I click in my IAM user, and then Security credentials.

I’m going to create new security credentials for this test.

Scroll down and click Create access key.

Now you get this way too complicated screen. Click the first option.

Now you get this warning, and I’ve explained a number of times why I am not using these other options. Unless something changed since the last time I used AWS SSO / Identity Center, these are the reasons I’m not using it.

You can find more details and how to work around some of the limitations in these posts, like creating separate users for MFA enforcement across roles.

Note that I don’t know if some of the above has been fixed since I last used the service, but it seems like they are pretty set on using the browser which is not ideal from a security perspective or leveraging automation the way I’m doing in my architecture.

Developer credentials are generally risky — but in our case, we are enforcing MFA for all actions (hopefully — if our SCP works as advertised). With the design in this blog series:

• An attacker cannot use credentials exposed or checked into GitHub without MFA.
• Credentials in developer workstations can only assume roles, with MFA.
• Credentials used in containers on EC2 instances (which will be our primary use case long term) are only ever stored in Secrets Manager, not in EC2 instances or on developer workstations where code they are developing exists.

Ok so now that you understand under what circumstances I use developer access keys let’s proceed.

Now my long term plan is to store all credentials in Secrets Manager and access the credentials from an EC2 instance combined with a token to assume a short term session and run a specific job from a private network. But for this test I’m going to configure an AWS CLI profile as per usual so we can test our SCP.

Using my new credentials I run:

aws configure --profile nomfa-rootadmin

I’m going to enter my credentials, region, and json for the output type.

What happens if I try to run the assume role command with those credentials?

I put my assume role command in a script and execute it.

aws sts assume-role \
    --role-arn arn:aws:iam::xxxxxxxxxxxx:role/[org-cross-account-role] \
    --role-session-name test-no-mfa \
    --profile nomfa-rootadmin

Here’s the result:

Nope. Not allowed.

What if we assume the role with MFA? How can I do that?

Recall that’s what I’m doing in my container that assumes a role with MFA:

In the above, I’m obtaining temporary credentials and using them to execute a job with a short term session. As I explained in other posts, there are a number of ways to assume roles.

In this post, I’m going to configure a role manually because it’s simpler for this test. I’m going to test without and with MFA.

Test without MFA:

Define your profile name:

[profile nomfa-orgadmin]

Define the role you want to assume:

role_arn = arn:aws:iam::xxxxxxxxxx:role/[org-cross-account-role] 

Set the source_profile to the profile above that has the credentials:

source_profile = nomfa-rootadmin

Define your region and output:

region = us-east-2
output = json

Here’s the full profile:

[profile nomfa-orgadmin]
role_arn = arn:aws:iam::xxxxxxxxxx:role/[org-cross-account-role]
source_profile = nomfa-rootadmin
region = us-east-2
output = json

Try listing the roles in the orgadmin account.

Nope.

Test a role profile that includes MFA to assume the organization role

Add the name of the MFA device to the profile.

Recall that in my architecture I am forcing the virtual MFA device name to match the username for security reasons. See prior posts on a missing user resource in virtual MFA actions and this is my work around solution to prevent user MFA devices from being removed or altered by other users.

mfa_serial = arn:aws:iam::xxxxxxxxxx:mfa/rootadmin

Here’s the full profile.

[profile mfa-orgadmin]
role_arn = arn:aws:iam::xxxxxxxxxx:role/[org-cross-account-role]
source_profile = nomfa-rootadmin
mfa_serial = arn:aws:iam::xxxxxxxxxx:mfa/rootadmin
region = us-east-2
output = json

Now I can use that profile to try to assume the cross account role and list all the profiles in the other account.

When I use that profile, it asks me for an MFA token for the rootadmin user virtual MFA device:

And it works!

By adding a service control policy as I did in the last post that enforces MFA properly (without ifexists!) we can require MFA to assume the AWS Organizations role in any account, both in the console and programmatically.

Without updating every AWS Organizations role in every account.

Pretty cool.

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