Role Trust Relationship for AWS services not reported

[Kamerabuilt]

First, thank you for the tool and what it offers so far. I really think that it has a great potential.

Issue1: For testing purposes, I created a Role which has an admin policy attached to it. In the trust relationship of that role, I allowed an AWS service to assume that role, for example:

"Principal": { "Service": "lambda.amazonaws.com" },
"Action": "sts:AssumeRole"

It would be very useful if PMapper would be able to find and list the AWS services which can assume a role with admin privileges.

Issue2: If a user can assume Role1, and through it, assume Role2 (and obtain STS tokens for the permissions of role2), it would be something MPapper should be able to point out. Role2 would have to have a trust relationship similar to the following:

"Principal": { "AWS": "arn:aws:iam::123456789000:root" }

Which means: Any IAM user/role in the account can assume this role, as long as their permission allows it. In this case, Role1 (with an admin policy) can actually assume Role2, since the trust relationship of Role2 allows it, in combination of the permissions of Role1 to assume the role.

When doing an account audit, these 2 issues will greatly help get a better overall picture of excessive privileges assigned to users, roles, and services.

Thank you!

[ncc-erik-steringer]

Hi there! I'm gonna try splitting up the asks here, lemme know if I've missed anything.

Issue 1:

Currently PMapper's library code supports letting you pass a service to check if they are allowed to assume a role. This is thru the resource_policy_authorization function in principalmapper.querying.local_policy_simulation. Here's an example of how it's used when checking if Lambda can use a role for an execution role:

PMapper/principalmapper/graphing/lambda_edges.py

Lines 85 to 92 in 722efec

	sim_result = resource_policy_authorization(
	'lambda.amazonaws.com',
	arns.get_account_id(node_destination.arn),
	node_destination.trust_policy,
	'sts:AssumeRole',
	node_destination.arn,
	{}
	)

Right now there isn't a way to check from the command line if a service can call an action/etc. We should probably add that in the future to handle a type of risk involving checks against aws:SourceAccount conditions.

One more note: right now, the analysis command and underlying code should be checking if any Lambda or EC2 roles are admins, and will generate corresponding findings. I think that should handle your primary use case in that case? We could go further and build a preset query that goes through all nodes, filters to the admin roles, and checks if there's an Allow statement in the trust doc that specifies the Service field. Programmatically it'd look like:

candidates = [x for x in graph.nodes where x.is_admin and x.searchable_name().starts_with('role/')]
for candidate in candidates:
    # inspect trust doc here

Issue 2:

The way PMapper works, if there's a "chain" of access, we don't create an edge from the first node in the chain to the final node. In other words, if there's a situation like this:

user1 -> role1 -> role2 -> role3 -> roleN

We don't add edges from user1 to role2/role3/etc. That's because user1 doesn't directly have access to the roles down the chain.

However, in any case, PMapper will should correctly handle these types of chains when calling query or argquery, as well as when using the library function principalmapper.querying.query_interface.search_authorization_full. If you run a query against user1, then ask if they can do something that roleN is allowed to do, then PMapper should return that info plus the chain that user1 has to follow.

[Kamerabuilt]

Thanks for your detailed reply!

For issue 1, I just took a deeper look at "analysis", the output produced by it is pretty much what I was looking for. To better explain what I was suggesting: can we include the output of "analysis" for the roles that have admin policies and can be assumed by other AWS services in "visualize" with the arrows? In other words, it would a box with for example "EC2" that has an arrow towards the role in blue named "EC2_admin_role". That way, we can inform the security team that the service EC2 has a role which is too powerful (and can be abused via the command line within EC2).

For issue 2, I will try to clarify things a bit more. Can the tool, again through "visualize", let us know which roles having an admin policy attached, can be "assumed" by other users/roles in the same or other accounts (without necessarily telling us which ones specifically)? During an audit, this should be a red flag, as someone can for example assume Role 1, then assume Role 2, only to assume Role 1 again, and so on, to make it much harder to trace the STS tokens produced. One easy way to find the roles which can be assumed by other roles or users would be filtering the ones with the following trust relationship:

"Statement": [
{
"Effect": "Allow",
"Principal": {
"AWS": "arn:aws:iam::account_number:root"
},
"Action": "sts:AssumeRole",
"Condition": {}
}

and making a list of them in "visualize" with a different color box :)

Thanks again

[ncc-erik-steringer]

Issue 1

Okay, I see what you're looking for. I think we could possibly add a --with-services flag to visualize to add additional nodes representing services that can access nodes in the account. I still like the preset query idea as well.

Issue 2

In visualization, the admin nodes in an account are colored blue. Non-admins are colored white. Non-admins that have a way to gain access to an admin are colored red. At least within the account, you should see if someone can assume an admin role. In terms of visualizing if an admin role can potentially be assumed from outside the account, we don't have anything in place for that yet. We could implement a new color (yellow? orange?) to denote that pattern (such as when someone sets up an OrganizationsAccountAccessRole).

[Kamerabuilt]

Issue 1: Exactly, something like visualize --with-services (or even including it by default) would be amazing. I am still not clear how would the preset query work?

Issue 2: Yep, I did notice the Red, blue, and white boxes. I guess what I was thinking if 2 blue boxes can be "assumed" by one or the other, we could include an arrow between them. So that for example, it would look like a red box --> blue box --> another blue box :)

Exactly, a yellow or orange would mean a different account_ID can assume any of the existing blue boxes w/ an admin policy attached. Naturally, a yellow/orange box was a blue box, but turned yellow/orange since it has an "external" link.

[ncc-erik-steringer]

Issue 1

The query and argquery components are loaded up with "preset" queries: queries that go beyond "can some user/role call with when ". https://github.com/nccgroup/PMapper/wiki/Query-Reference#preset-queries . I was thinking for your idea, we add a new preset called serviceaccess that displays a list of services and which roles they can access, as well as highlighting if those roles are admins.

Issue 2

Since all the admins can access any user/role in the account, we avoid storing those edges and displaying those edges in visualizations because it creates a ton of output and clutters the visualization.

I think for externally-accessible roles (accounts), we can do:

• Yellow nodes -> externally accessible nodes that are not admins
• Orange nodes -> externally accessible nodes that are admins

[Kamerabuilt]

100% agree for both points! Thank you

[ncc-erik-steringer]

v1.1.4 is out and addresses Issue 1. Keeping this open and aim to do "yellow/orange" coloring for externally-accessible roles.