PMapper 1.1.5 builds edges that include role/AWSServiceRoleForSupport when performing authorization checks

[DanHatesNumbers]

PMapper 1.1.5 builds edges that include role/AWSServiceRoleForSupport when performing authorization checks

[ncc-erik-steringer]

Just pushed dc7ab36, would you be willing to let me know if that's working better? You'll need to regraph the account due to the version bump.

[DanHatesNumbers]

The weird behaviour I was seeing where the principals I'd expect to be allowed to call the action I'm querying were being denied was because I forgot to also include the default Allow All SCP in my simulation. Now it behaves exactly as I'd expect.

[DanHatesNumbers]

The concern with this approach is with service principals like lambda.amazonaws.com, ec2.amazonaws.com, glue.amazonaws.com, codebuild.amazonaws.com, and sagemaker.amazonaws.com. These are all accessible by other users/roles in AWS accounts and the list may expand as AWS adds new services. However, per #104 and discussions elsewhere, we do know that service-linked roles can be determined by that common prefix and handled with their special cases as in here.

Thanks for that explanation, that makes sense!

Also thanks so much for building this tool! I've literally just finished giving my team a crash course in how to use PMapper to analyse AWS accounts and also this SCP simulation usecase to assess the impact of applying a new SCP without needing to 'do it live' and they loved it!

[DanHatesNumbers]

#109 fixes this issue, hopefully this comment will autolink them

[ncc-erik-steringer]

Hello!

To make sure I understand, you're running a query and one of the query results has a list of edges that looks like:

<Principal 1> -- Edge 1 --> <role/AWSServiceRoleForSupport> -- Edge N --> [...]

If that role can only be assumed by support.amazonaws.com, could you drop info on how another principal in the account is able to gain access to that service role? i.e. the reason field of that Edge where that role is the destination?

[DanHatesNumbers]

Hi!

You're correct, that's the behaviour I'm observing. There's a handful of roles in the account I'm querying that have edge lists that include the role/AWSServiceRoleForSupport role and the reason field for those edges is: role/codebuild-role-eu-west-1 can access through administrative actions role/AWSServiceRoleForSupport.

If it would be helpful, I can try and replicate this behaviour with Localstack and provide a minimal example of the script I'm running my query with and steps to create the required IAM principals and policies.

[ncc-erik-steringer]

Ah, I know what's happening:

• Your query includes SCPs
• The codebuild role isn't directly authorized to call cognito-idp:DescribeUserPoolClient
• The codebuild role is an admin

Because there are SCPs in play, PMapper does not assume that an admin can arbitrarily call a given action. Instead, if the admin node isn't directly authorized to call the action, PMapper generates Edge objects linking to all other Node objects to continue searching.

There is a bug here, PMapper is assuming that IAM Users/Roles are able to gain access to service-linked roles (IAM Roles that start with the prefix AWSServiceRoleFor). That is not true (https://aws.amazon.com/blogs/security/introducing-an-easier-way-to-delegate-permissions-to-aws-services-service-linked-roles/), and we should be excluding these roles as destinations. I'll implement a fix in the v1.2.0-dev branch.

[DanHatesNumbers]

Running the regraph now using v1.2.0-dev, I'll report back with the results!

[DanHatesNumbers]

I'm no longer seeing edges being constructed that involve assuming the role/AWSServiceRoleForSupport role, however, I'm also not seeing any edges that I would expect to see there. This may be due to a faulty SCP I'm testing on my part, so I'll do some more digging and let you know what I find.

I've had a look at the change, and I wonder if it's worth using the role's trust policy to exclude roles that only include service principals in their trust policy? That way it would correctly handle roles created by customers that can be assumed by a service that don't follow the AWS naming conventions, as well as roles that can be assumed by both service principals and other types of principals.

[ncc-erik-steringer]

Now it behaves exactly as I'd expect.

Excellent!

I've had a look at the change, and I wonder if it's worth using the role's trust policy to exclude roles that only include service principals in their trust policy? That way it would correctly handle roles created by customers that can be assumed by a service that don't follow the AWS naming conventions, as well as roles that can be assumed by both service principals and other types of principals.

The concern with this approach is with service principals like lambda.amazonaws.com, ec2.amazonaws.com, glue.amazonaws.com, codebuild.amazonaws.com, and sagemaker.amazonaws.com. These are all accessible by other users/roles in AWS accounts and the list may expand as AWS adds new services. However, per #104 and discussions elsewhere, we do know that service-linked roles can be determined by that common prefix and handled with their special cases as in here.