IAM-Flaws: Exploiting User and Group Policies in AWS IAM
Hi everyone, back with another blog. A few days back I had written about how we could exploit misconfigurations in an AWS S3 Bucket and had also built a tool that could easily automate the whole process after which I thought of expanding my knowledge on AWS a bit more. So today I’ll be writing about a few misconfigurations while setting up IAM policies in AWS that could be exploited leading to escalation of privileges. Along with this, I’ll also be introducing to a tool/script “IAM-Flaws” that I along with my friend Shivram Amirtha have built for this purpose that would automate this up to some extent and is also equipped with some additional features related to AWS IAM.
What is AWS IAM?
Simply put, AWS IAM ( Identity and Access Management ) is a web service that allows handling authorization mechanism in the AWS environment/console. It is used to set users, groups, roles, policies in order to give different permissions to different entities.
The AWS IAM consists of identities and resources where the identities include the users, groups, roles and the resources include services like s3, EC2, DynamoDB, etc
AWS ARN(Amazon Resource Name) is used to uniquely identify AWS resources. ARNs are associated with all standalone resources and entities.
partition: specifies where the resource is in. By default it is aws.
services: specifies the aws service. In our case its IAM.
region: specifies where the resource is residing in. However, for IAM, it is generally kept blank.
account: specifies the AWS account ID.
resource: specifies the name of the particular resource.
A user is an entity that you create in AWS to represent the person or application that uses it to interact with AWS. A user in AWS consists of a name and credentials.
A group is an entity that you can create in AWS in order to manage multiple users with ease. Groups help in assigning and managing permissions of multiple users sharing the same needs. For eg, you could have a group called admins and assign permissions to the group than an admin would need. Any user that is added to the group then inherits the permissions of the group.
An IAM role is similar to an IAM user, however, instead of being uniquely associated with one person, a role is intended to be assumable by anyone who needs it. Also, a role does not have standard long-term credentials such as a password or access keys associated with it. Instead, when you assume a role, it provides you with temporary security credentials for your role session. They are used to grant specific permission to specific actors for a set of duration of time. An IAM role is something virtual that a resource can assume. For example, an EC2 instance can assume a role and execute AWS command with that assigned privileges. The same goes for other services like API gateway, Lambda, Kinesis, RDS and so on.
A policy is simply an entity/object in AWS which is applied to identities and resources wherein you could specify what permissions are allowed and denied to a specific set of resources/identities. When a specific request is originated from any of the identity, then the AWS checks the permissions specified in these policies to check whether to allow or deny the request.
Policies could be either managed or inline:
AWS Managed Policies: These are a set of pre-built policies that are managed by AWS itself and each of the policies is associated with their specific ARNs and could be attached to any of the AWS identities. Eg: “IAMReadOnlyAccess”, “AdministratorAccess” etc.
Custom Managed Policies: These policies are created and managed by the customer/user and is also associated with ARNs. They could be attached to any of the AWS identities.
Inline policies are the policies that are specific to a particular specified identity and are not associated with an ARN. All users, groups, roles could have their own inline policies containing a set of permissions applied on certain resources. These policies can’t be attached or reused with any other identity (Be it of the same type or a different type). Eg: An inline policy created for a particular user cannot be used for any other user or any other type of identities like groups and roles.
Privilege escalation is one of the most fascinating topics in any of the Cyber Security Assessments especially when it is less discovered or mostly untouched like the cloud. Few years back, Spencer Gietzen from Rhino Security Labs had come up with a set of 21 brilliant methodologies through which privilege escalation was possible in an AWS environment. These methodologies were nothing but simply exploiting the misconfigurations of the permissions given to users, groups and roles in an AWS environment. It is suggested to go through the original link methodologies to perform any IAM based technical assessments.
So below we have filtered and listed down 10 user escalation methods that we have implemented in our toolkit and also these are related to permissions given to users and group only. All the role based escalation methods are part of our future scope.
1. New Policy Version Creation
A user with “iam:CreatePolicyVersion” permission can create a new version of an existing policy. The existing policy needs to be a custom managed policy only which is either attached to the user itself or to a group of which the user is a part of. A new version of the policy could be created by specifying the policy document which could be in the json format.
To make the escalation effective the –set-as-default flag must also be set in order to specify that the newly created version is set as the default policy version. This would lead to escalation of the privileges of the IAM user giving him all the permissions that are spcified in the json document provided by us.
This is how a json policy would look like which in this case specifies to give all permissions to all resources eventually giving admin privileges to the resource.
The user should know the ARN of the policy to which it is attached to. (either directly or indirectly)
aws iam create-policy-version –policy-arn <ARN of the policy> –policy-document file:///<path to the json document> –set-as-default
2. Setting the Default Policy Version
A user with “iam:SetDefaultPolicyVersion” permission would be able to change the version of a policy of which he is a part of (either directly attached or policy attached to a group of which he is a part of). This would be possible only if the targeted policy has any other versions which has higher permissions attached to it.
The user should know the ARN of the policy to which it is attached to. (either directly or indirectly)
aws iam set-default-policy-version –policy-arn <ARN of the policy> –version-id <version of the policy>
3. Creating a New User Access Key
A user with “iam:CreateAccessKey” permission would allow a user to create access key and secret key for any other user if they already don’t have two sets of keys associated with them. This might be helpful if the other user has higher permissions compared to the current account. Once we have access to the other user’s key, we could configure them with awscli and run queries/commands as that particular user.
aws iam create-access-key –user-name <name of another user>
4. New Login Profile Creation
A user with “iam:CreateLoginProfile” permission on other users could allow a user to set a login password for the other user if they already don’t have it set. This would be helpful if the other user has higher permissions than the current user. Once we set the password, we could login to the AWS console as that user.
aws iam create-login-profile –user-name target_user –password ‘<password>‘ –no-password-reset-required
5. Updating an existing login profile
A user with “iam:UpdateLoginProfile” permission on other users could allow a user to update the login password for the other user if they already have the login profile set. This would be helpful if the other user has higher permissions than the current user. Once we update the password, we could login to the AWS console as that user.
aws iam update-login-profile –user-name target_user –password ‘<password>‘ –no-password-reset-required
6. Policy Attachment to a User
A user with “iam:AttachUserPolicy” permission could allow a user to attach a managed policy(both custom and AWS managed ) to a user. This would lead to escalation of privileges if we could attach a policy containing higher permissions like the AdministratorAccess policy.
aws iam attach-user-policy –user-name <username> –policy-arn <arn of the policy to attach>
7. Policy Attachment to a Group
A user with “iam:AttachGroupPolicy” permission could allow a user to attach a managed policy(both custom and AWS managed ) to a group of which he is a part of. This would lead to escalation of privileges if we could attach a policy containing higher permissions like the AdministratorAccess policy.
aws iam attach-group-policy –group-name <groupname> –policy-arn <arn of the policy to attach>
8. Setting an Inline Policy for a User
A user with “iam:PutUserPolicy” permission could allow a user to either create a new inline policy or update an old inline policy for a particular user. This could lead to full Administrator Privilege access by specifying the wildcard entry in the Actions and Resource field of the Json document which needs to be passed in the command itself.
aws iam put-user-policy –user-name <username> –policy-name <policy name> –policy-document <Path to Json Document>
9. Setting an Inline Policy for a Group
A user with “iam:PutGroupPolicy” permission could allow a user to either create a new inline policy or update an old inline policy for a particular group of which the user is a part of. This could lead to full Administrator Privilege access by specifying the wildcard entry in the Actions and Resource field of the Json document which needs to be passed in the command itself.
aws iam put-group-policy –group-name <groupname> –policy-name <policy name> –policy-document <Path to Json Document>
10. Adding a user to a group
A user with “iam:AddUserToGroup” permission could allow a user to add themselves to a group of which they are not a part of. This could lead to gaining higher permissions if the group is itself attached with any higher permissions policies.
aws iam add-user-to-group –group-name <group name> –user-name <username>
So time for a little bit of show off :-p
IAM-Flaws is basically a script or tool which we have built using bash with a goal to include all IAM related technical checks for faster completion of assessments. Also, since these topics are usually less touched we thought it would be a good subject to put our efforts and understand it more deeply and I feel that is only possible if we build some kind of tool for that subject because only if one starts preparing or building, new limitations and exceptions arises which gives us a much better clarity.
As of now, it supports the following modules:
– AWS IAM related CIS Benchmarks
– Enumeration of AWS IAM User, Groups and it’s associated Policies
– Privilege Escalation Scanning and Exploitation Based on the Enumeration results
For performing all the Benchmark checks, we have filtered out 22 checks that are only related to AWS IAM out of which we have included 18 checks in our script while the rest 4 checks could only be done manually through the AWS console.
CIS Benchmark Checks
For privilege escalation, as already stated earlier, we have focused only on misconfigurations affecting the user and group policies as of now. We’ll soon be adding escalation methods related to roles as well which is part of our future scope.
User and Group Policy permissions Enumeration
Privilege Escalation Scanning
Privilege Escalation Exploitation
Requirements: A valid access key and a secret key of an IAM user is required which needs to be configured in your machine using awscli (make sure you have this set up as well).
Now coming to permissions, there are a few permissions that needs to be set for a user in order for our enumeration script to work properly and for an effective and complete enumeration. Below is listed a few permissions that is recommended to be set for a user before proceeding with our script.
These were the recommended additional permissions that needs to be given for proper enumeration, however if you don’t provide these permissions, the script will try to enumerate as much as possible based on the permission a certain user has.
Usage: The usage of the script is very simple. There are 3 different modules/scripts for benchmark checks, enumeration and privilege escalation respectively and all the 3 of them could be run independently, however it is highly recommended to use iam-flaws.sh directly which is kind of a central script through which you could select any module and it would also help in storing your output to a file.
Reporting: As of now, we have only added the functionality to save the complete terminal output to a file in plain text format if the script is run through the main file i.e iam-flaws.sh
And yes, also do check out pacu built by rhino security labs which is an awesome tool for aws security assessments, it is also refferred as the metasploit for AWS.
So that’s for now. See you next time.
Till then Stay Safe, Stay Home
Happy Hacking !!!
You can have a look at my previous article on Hack The Box: Traverxec Box Walkthrough. Here is the link of the article
Loved what you read?
If so, then kindly comment, follow and share our website for much more interesting stuff
For any queries you can send a Hi to my Linkedin Handle: Here