Privilege escalation analysis

[Techbrunch]

Describe the bug

Running the query with preset privesc * doesn't return anything.

pmapper --profile target query -s 'preset privesc *'

Running analysis does return something:

pmapper --account target analysis
...
The following principals could escalate privileges:

* user/user1 can escalate privileges by accessing the administrative principal user/user2:
   * user/user1 can access through administrative actions user/user2

* user/user2 can escalate privileges by accessing the administrative principal user/user1:
   * user/user2 can access through administrative actions user/user1

* role/TargetAdminRole can escalate privileges by accessing the administrative principal user/user1:
   * role/TargetAdminRole can access through administrative actions user/user1

* role/target-admin can escalate privileges by accessing the administrative principal user/user1:
   * role/target-admin can access through administrative actions user/user1

The analysis is a bit confusing.

Note:

• user1 and user2 have the policy IAMFullAccess
• TargetAdminRole and target-admin have the AdministratorAccess policy (note that they also both list a trusted entity)

Expected behavior

I'm probably missing something but I expected to see something like this:

* user/user1 can escalate privileges by using the policy `IAMFullAccess`
* user/user2 can escalate privileges by using the policy `IAMFullAccess`

Should both role be mentionned since using the AdministratorAccess policy is not really a privilege escalation ?

EDIT:

I just realized that PMapper does not report some privesc reported by ScoutSuite. For example in the same account there is a user with a policy allowing iam:PassRole for all resources but it is not listed by PMapper.

Is it because no role can be exploited to get administrator access ?

Thanks for the awesome tool.

[Rackme]

@Techbrunch try v1.1.1-dev branch, I had no trouble so far for privesc audit.

Is it because no role can be exploited to get administrator access ?

Role have Trust Relationship policy, can you share more details about this Role ?

[ncc-erik-steringer]

There are a couple questions here, I'll tackle the first one in this comment:

It looks like your IAM Users user1 and user2 are already admins by virtue of assigning them IAMFullAccess. With that managed policy, they can simply grant themselves access to whatever they want to call by assigning themselves more inline policies or attaching the AdministratorAccess policy to themselves. PMapper likely saw this and designated them as admins. I believe that if you run the privesc query without the -s flag, it'll report all of your users/roles.

I think you've found a bug in analysis, because for some reason it's explaining how those users to get to other admin users (i.e. each other) rather than saying "hey these are already admins".

[ncc-erik-steringer]

Regarding:

I just realized that PMapper does not report some privesc reported by ScoutSuite. For example in the same account there is a user with a policy allowing iam:PassRole for all resources but it is not listed by PMapper.

Is it because no role can be exploited to get administrator access ?

ScoutSuite will report IAM Policies with that use the unsafe pattern "iam:PassRole for resource *" which might yield a privesc vulnerability. PMapper goes and actually simulates the different authorization checks to confirm that some user could pass some role and gain access to that role + it's permissions. PMapper answers the question "If I assign broad passrole access to this user, what can it actually go and access?".

[ncc-erik-steringer]

Just released v1.1.1 with a fix for this, pushed it to the master branch and dropped it onto PyPI.

[Techbrunch]

@ncc-erik-steringer

It looks like your IAM Users user1 and user2 are already admins by virtue of assigning them IAMFullAccess. With that managed policy, they can simply grant themselves access to whatever they want to call by assigning themselves more inline policies or attaching the AdministratorAccess policy to themselves. PMapper likely saw this and designated them as admins. I believe that if you run the privesc query without the -s flag, it'll report all of your users/roles.

Is there a list of what is considered an admin "by virtue" ? I think it makes sense that AdministratorAccess is considered admin by virtue but I think it can be argued that IAMFullAccess should be considered a privesc since it requires multiple steps to get AdministratorAccess. That's why I was expecting something like this:

* user/user1 can escalate privileges by using the policy `IAMFullAccess`
* user/user2 can escalate privileges by using the policy `IAMFullAccess`

[ncc-erik-steringer]

For PMapper, an admin is anyone that can modify their own IAM Policies (being able to attach AdministratorAccess to themselves or adding an inline policy to themselves). In other words, admins are users/roles that can call any action for any resource either directly or by modifying their own permissions. Here's the current code that does that check: https://github.com/nccgroup/PMapper/blob/f047d19bf6eb9444180d109c77d1d215edfc4410/principalmapper/graphing/gathering.py#L668

The hard part here is intent. I could see someone setting up their account by having a dedicated "make other users/roles" administrative IAM User and assigning it IAMFullAccess. Could that user be abused by granting itself extra permissions? Sure, as it could do by creating other users/roles and attaching policies to them, but that's also the point of that user is to be a high-level principal. Then again, someone might toss IAMFullAccess onto a user because they needed to pass a role to an EC2 instance.

The best option, in my opinion, is to mark these principals as admins. Users of PMapper can run the privesc query or use visualize and those admins will get highlighted for the users to inspect and handle according to their intents.

All that aside, there's room for improvement here. Something I've been mulling for v1.2.X is either adding an attribute or modifying is_admin for Node objects that states a reason why a given user/role is an admin.

[ncc-erik-steringer]

In v1.1.5, we added the wrongadmin query that I think covers the gap here. This preset query identifies principals that have admin permissions, but don't have the AdministratorAccess (or equiv. inline policy) attached. I'm closing this issue as a result.