AWS Identity Center (formerly known as AWS SSO): A Guide to Privilege Escalation and Identity and Access Management
Overview #
iam:PassRole
, sts:AssumeRole
, and iam:SetDefaultPolicyVersion
. One such example community post is by Rhino Security Labs.aws-portal
prefix that are to be retired. The console permission is sso-directory:AddMemberToGroup
and the API permission is identitystore:CreateGroupMembership
.Introduction to AWS Identity Center #
iam:AttachRolePolicy
.arn:aws:iam::123412341234:role/aws-reserved/sso.amazonaws.com/eu-central-1/AWSReservedSSO_AWSReadOnlyAccess_1111111111111111
in a target account looks as follows.{
"Version": "2012-10-17",
"Statement": [
{
"Effect": "Allow",
"Principal": {
"Federated": "arn:aws:iam::123412341234:saml-provider/AWSSSO_1111111111111111_DO_NOT_DELETE"
},
"Action": ["sts:AssumeRoleWithSAML", "sts:TagSession"],
"Condition": {
"StringEquals": {
"SAML:aud": "https://signin.aws.amazon.com/saml"
}
}
}
]
}
Dual Authorization #
PutPermissionPolicy
and PutInlinePolicyToPermissionSet
could work.Privilege Escalation with AWS Identity Center (SSO) #
sso
service prefix for Identity Center actions.identity-store
service prefix for Identity Store actions.sso-directory
service prefix for IAM Identity Center Directory actions.identitystore-auth
service prefix for Identity Store Auth actions.identity-sync
service prefix for Identity Sync actions.
sso
and identity-store
actions. Note: these will look different in CLI as sso-admin
and sso
are both service prefixes.1. Permission Set Modification #
Action: `sso:ProvisionPermissionSet`
In Identity Center, [a Permission Set](https://docs.aws.amazon.com/singlesignon/latest/userguide/permissionsetsconcept.html) is used to assign access to an Identity Center user or Identity Center group in one or more AWS Accounts. These are not the same users and groups in AWS IAM (IAM Users and Groups). When a permission set is assigned, Identity Center creates Identity Center IAM Roles in each account where the permission set corresponds to the role permissions in the corresponding AWS account.
Permission Sets are not provisioned by default when they are created (`sso:CreatePermissionSet`). For the permissions to go into effect, `sso:ProvisionPermissionSet` must be called. The same is required with adding permissions which is covered in the section below.
However, `sso:CreateAccountAssignment` as part of the Scope Change via Account Assignment section covered below will automatically provision permission sets as part of creating an account assignment.
2. Adding Permissions #
There are multiple different ways of adding permissions. Similar to attaching policies to IAM Roles and Users, the following are different methods of adding and removing policies to a permission set.
- Attaching an AWS Managed Policy
Action: `sso:AttachManagedPolicyToPermissionSet`
This action attaches an AWS managed policy to the Permission Set such as `AdministratorAccess`. An AWS managed policy is a standalone IAM policy that is created and managed by AWS. It is possible to grant more privileges via an attached managed policy.
- Attaching a Customer Managed Policy
Action: `sso:AttachCustomerManagedPolicyReferenceToPermissionSet`
This action attaches a customer managed policy to the Permission Set. A customer managed policy is an IAM policy created and managed by the customer (you). It is possible to grant more privileges via an attached managed policy.
- Adding an Inline Policy
Action: `sso:PutInlinePolicyToPermissionSet`
This action ties an inline policy to the permission set. Inline policies are not standalone policies but rather are policies created for a single identity. In this case, they’re created for Permission Sets. It is possible to grant more privileges via an inline policy.
- Detaching an AWS Managed Policy
Action: `sso:DetachManagedPolicyFromPermissionSet`
This action removes the association between an AWS managed policy from the specified permission set. It is possible to grant more privileges via detaching a managed policy (deny policy).
- Detaching a Customer Managed Policy
Permission: `sso:DetachCustomerManagedPolicyReferenceFromPermissionSet`
This action removes the association between a Customer managed policy from the specified permission set. It is possible to grant more privileges via detaching a managed policy (deny policy).
- Deleting an Inline Policy
Permission: `sso:DeleteInlinePolicyFromPermissionSet`
This action removes the permissions from an inline policy from the permission set. It is possible to grant more privileges via detaching an inline policy (deny policy).
- Deleting a Permission Boundary
Permission: `sso:DeletePermissionBoundaryFromPermissionSet`
This action removes the Permission Boundary from the permission set. It is possible to grant more privileges by removing the restrictions on the Permission Set given from the Permission Boundary.
Observations
- Attaching a Customer Managed Policy is a different permission than attaching an AWS Managed Policy. This is different than the standard IAM permission for attach managed policies. For example,
iam:AttachRolePolicy
attaches a managed policy (either customer managed or AWS managed) to an IAM Role. - Attaching and Detaching an AWS Managed Policy is
AttachManagedPolicyToPermissionSet
andDetachManagedPolicyFromPermissionSet
without a clarifyingAWS
. This is different than attaching a customer managed policy with the customer specifier inAttachCustomerManagedPolicyToPermissionSet
. - Permission modifications to existing Permission Sets do not go into effect without a
sso:ProvisionPermissionSet
call. For example, applying a new policy to a permission set and having the permissions go live requires 2 steps:sso:AttachManagedPolicyToPermissionSet
(Example usage of AWS Managed Policy)sso:ProvisionPermissionSet
3. Scope Change via Account Assignment #
Action: `sso:CreateAccountAssignment`
This call assigns access to a principal for a specified AWS account using a specified permission set. Thus, extra access scope may be granted to a principal. For example, a user may be granted access to highly sensitive Production AWS Accounts.
Additionally, as part of the `sso:CreateAccountAssignment` call, the permission set will be automatically provisioned as part of creating an account assignment.
([https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_CreateAccountAssignment.html](https://docs.aws.amazon.com/singlesignon/latest/APIReference/API_CreateAccountAssignment.html))
4. Membership Modification (User to Group Association) #
Action: `identitystore:CreateGroupMembership`
Action: `sso-directory:AddMemberToGroup`
Both these actions are listed here since they both achieve the same goal. `sso-directory:AddMemberToGroup` is a console only API call and `identitystore:CreateGroupMembership` is an API/CLI only call.
These actions creates a relationship between a member and a group since those are different IAM entities that can be assigned as part of an account assignment. If a group has account assignments, adding a user to the group will grant that user access to the assignments given to the group (inheritance).
{
"Version": "2012-10-17",
"Statement": [
{
"Sid": "VisualEditor0",
"Effect": "Allow",
"Action": ["sso-directory:AddMemberToGroup", "identitystore:CreateGroupMembership"],
"Resource": "*"
}
]
}
Permission Modification and Access Disruption #
sso:DeletePermissionSet
sso:PutPermissionsBoundaryToPermissionSet
sso:DeleteAccountAssignment
- Attaching a Managed Policy with Deny Statements that override allowed permissions already allowed by other IAM Policies.
- Associating a Permission Boundary with an effective boundary that limits the allowed permissions from IAM policies.
- Removing access to an account by deleting an account assignment.
- Disrupting access by deleting a permission set.
Security Detection: Identifying Identity Center Actions in CloudTrail Logs and How CloudQuery can help #
CloudQuery Setup and Configuration #
kind: source
spec:
name: "aws"
path: "cloudquery/aws"
registry: "cloudquery"
version: "v31.3.0"
destinations: ["postgresql"]
tables: ["aws_cloudtrail_events"]
spec:
accounts:
- id: '123412341234'
local_profile: 'cloudquery-view'
cloudquery sync aws.yml postgres.yml
. Keep in mind that this sync could take some time given the amount of data in CloudTrail Events. The account we sync is the delegated administrator account for AWS Identity Center in our example organization.Exploring CloudTrail Events #
SELECT * from aws_cloudtrail_events
WHERE (event_name = 'CreateAccountAssignment'
OR event_name = 'ProvisionPermissionSet')
AND cloud_trail_event -> 'errorCode' IS NULL
ORDER by event_time;
SELECT * from aws_cloudtrail_events
WHERE event_name = 'AddMemberToGroup' AND
cloud_trail_event -> 'errorCode' IS NULL
ORDER by event_time;
Conclusion #
References and Useful Links #
Written by Jason Kao
Jason worked as Head of Security Research and Solutions at CloudQuery and was a Senior Data Engineer prior to taking on that role. He focused on multi-cloud environments and has particular expertise on AWS.