Unable to assume role

[prsimoes]

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]

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]

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]

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]

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]

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]

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]

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]

@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]

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]

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