Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Unable to assume role #174

Closed
prsimoes opened this issue Sep 29, 2022 · 10 comments
Closed

Unable to assume role #174

prsimoes opened this issue Sep 29, 2022 · 10 comments
Assignees

Comments

@prsimoes
Copy link

What is not working?
On techniques that create an IAM role during warmup, I can't assume that new role. I'm running stratus with an already assumed role on my AWS account, not root. For example while looking at the IAM role that is created by https://github.com/DataDog/stratus-red-team/blob/main/v2/internal/attacktechniques/aws/credential-access/ec2-get-password-data/main.tf#L23, I get a trust relationship on the new role of :

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "",
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<MY_ACCOUNT_ID>:root"
            },
            "Action": "sts:AssumeRole"
        }
    ]
}

When it should be something like:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Effect": "Allow",
      "Principal": {
        "AWS": "arn:aws:iam::<MY_ACCOUNT_ID>:role/MY_CURRENT_ROLE"
      },
      "Action": "sts:AssumeRole"
    }
  ]
}

Looking at the Terraform in https://github.com/DataDog/stratus-red-team/blob/main/v2/internal/attacktechniques/aws/credential-access/ec2-get-password-data/main.tf#L33, I couldn't find a way to reference the role name instead of the root account.

What OS are you using?
Mac OS X

What is your Stratus Red Team version?
2.4.1

Full output?
Example error message from Cloudtrail:

"errorMessage": "User: arn:aws:sts::<MY_ACCOUNT_ID>:assumed-role/<MY_CURRENT_ROLE/stratus-session is not authorized to perform: sts:AssumeRole on resource: arn:aws:iam::<MY_ACCOUNT_ID>:role/sample-role-used-by-stratus-for-ec2-password-data"
@christophetd
Copy link
Contributor

arn:aws:iam::<MY_ACCOUNT_ID>:root doesn't mean "the root user of the AWS account", it means "any principal in the AWS account that has sts:AssumeRole permissions on this role".

If I run this detonation while authenticated under an admin role, it works well:

$ aws sts get-caller-identity
{
    "UserId": "xxx:christophetd",
    "Account": "012345678912",
    "Arn": "arn:aws:sts::012345678912:assumed-role/admin-role/christophetd"
}

$ stratus detonate aws.credential-access.ec2-get-password-data
2022/09/29 11:58:15 Checking your authentication against AWS
2022/09/29 11:58:15 Warming up aws.credential-access.ec2-get-password-data
2022/09/29 11:58:15 Initializing Terraform to spin up technique prerequisites
2022/09/29 11:58:21 Applying Terraform to spin up technique prerequisites
2022/09/29 11:58:35 Running ec2:GetPasswordData on 30 random instance IDs

Can you confirm the role you are using is authorized to perform sts:AssumeRole?

@prsimoes
Copy link
Author

The role has AdministratorAccess permission policy, which basically provides full access to resources. My get-caller-identity is pretty similar to yours. Did you double check if you see the GetPasswordData event in Cloudtrail? The reason I'm asking is because, for me, the detonate also shows no errors, but in the end, nothing real happens and I don't see the GetPasswordData event in my Cloudtrail, because the role I'm in, can't assume the new role.

Here's the output of my get-caller-identity:

aws sts get-caller-identity
{
    "UserId": "xxx:stratus-session",
    "Account": "<MY_ACCOUNT_ID>",
    "Arn": "arn:aws:sts::<MY_ACCOUNT_ID>:assumed-role/OrgAccessRole/stratus-session"
}

The OrgAccessRole is a role that I also need to assume at first, from my source identity, through aws sts assume-role --role-arn "arn:aws:iam::<MY_ACCOUNT_ID>:role/OrgAccessRole" --role-session-name stratus-session. It's with this role that I control the AWS account. This account belongs to an organization and the main Organizations account can assume this role, however, I don't think that's in play here. Here's the trust relationship for that OrgAccessRole:

{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Effect": "Allow",
            "Principal": {
                "AWS": "arn:aws:iam::<MAIN_ORG_ACCOUNT_ID>:root"
            },
            "Action": [
                "sts:AssumeRole",
                "sts:SetSourceIdentity"
            ]
        }
    ]
}

@christophetd
Copy link
Contributor

I know you said your role has AdministratorAccess, but this still sounds like a permission issue on your role to me. If you manually modify the trust policy of the role created by Stratus Red Team during warm-up, does it help?

@prsimoes
Copy link
Author

prsimoes commented Oct 3, 2022

I had to add sts:SetSourceIdentity to the trust policy of the sample-role-used-by-stratus-for-ec2-password-data role. I believe this has to do with the nature of my environment, as we assume the org role from our source account user. I can now see the failed GetPasswordData events, which is expected right since the role only has allow for ec2:Describe* methods.

@christophetd
Copy link
Contributor

What do you think we should do? Would it make sense to add sts:SetSourceIdentity to the trust policy of the role for everyone else?

@prsimoes
Copy link
Author

prsimoes commented Oct 5, 2022

Per AWS documentation, if you're doing role chaining and your role has the sourceIdentity set, the target role you're about to assume needs to allow the sts:sourceIdentity in the trust policy: https://docs.aws.amazon.com/IAM/latest/UserGuide/id_credentials_temp_control-access_monitor.html#id_credentials_temp_control-access_monitor-know.

I think doesn't make sense to setting it by default as it depends on your environment. Maybe just make a reference to that?

@christophetd
Copy link
Contributor

Conversely; is there any downside to allowing sts:SetSourceIdentity on the role? I think not. Let me send out a PR to make sure this works fine for most people

@christophetd
Copy link
Contributor

@prsimoes c.f. #224, can you have a look and confirm it fixes your issue? I attached a Mac OS build below for your convenience

https://drive.google.com/file/d/1ZZOJ9HqAIUvXbaIxKXbTmmgRHmfZF-sx/view?usp=sharing

@prsimoes
Copy link
Author

prsimoes commented Oct 6, 2022

Yes, it fixes, however, I noticed that I have to warmup first wait a few seconds and then detonate. If I do all at once with just detonate, I get permissions issues. Looks like the permissions takes a few seconds to settle.

@christophetd
Copy link
Contributor

Thanks. Guess it can't hurt to merge it. Thanks for reporting!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

No branches or pull requests

2 participants