Exploiting IAM security Misconfigurations — Part 1
As more and more companies move their operations to the cloud, security has become a significant concern for cloud service providers like Amazon Web Services (AWS).
AWS security is constantly evolving to keep up with the growing threats and vulnerabilities in the cloud.
A popular trend is the rise of cryptojacking attacks, where attackers use compromised AWS resources to mine cryptocurrency. In addition, there has been an increase in attacks targeting misconfigured AWS S3 buckets, which can lead to data breaches and leaks. To address these trends, AWS has continued to improve its security offerings and provide guidance to its customers on best practices for securing their AWS infrastructure.
Despite the abundance of best practices and defense advice offered by the cloud providers and the security community, misconfigurations exist and provide attackers with fast-track access for exploits.
Identity and Access Management misconfigurations are one of the most common concerns in cloud security across all the cloud providers.
Cloud providers do not provision most environments that are secure by default. As long as there exists a choice to alter a resources configuration, misconfigurations will continue to exist. The shared responsibility model enforces the idea of security being a shared responsibility between the cloud provider and the user.
In its simplicity, cloud provider takes care of the security of the hardware and network configurations while the user takes care of the user interfaces and resource configurations that are required for the services to be exposed and function.
What if a misconfiguration exists over the users or roles in your environment? Was the misconfiguration applied intentionally by a known-insider? Or was it an attacker with access to keys to your kingdom?
If attackers already have access to your cloud environment, misconfigurations can help them perform lateral movement, use the account for malicious purposes (crypto mining) or exfiltrate sensitive data.
This multipart series covers IAM security misconfigurations and how it is possible for an attacker to use them to gain access to resources and data.
AWS IAM is a service that lets you manage identities that can be used to access AWS services and resources securely.
With IAM, AWS users can be created and can, optionally, be grouped into groups. Permissions can then be assigned to these users or groups to allow / deny them access to AWS resources.
Due to fine granularity of permissions available, while assigning the permissions to users or groups, the best practice is always to follow the principle of least privilege. i.e carefully giving users permissions to make sure they only have access to actions and resources that are absolutely fundamental to performing their daily operations.
It is very important to highlight is that it is often not just a single overly permissive permission that could allow the user to perform unwanted actions, but the combination of this single misconfigured permission with all the others already assigned to the user.
Scenario 1: Misconfigured AssumeRole policy and updating AssumeRolePolicyDocument
Assumptions are made and most assumptions are wrong
- Albert Einstein
Let us consider an attacker who has successfully launched an OSINT campaign to find leaked secrets of an internal user. With this, an attacker is able to get valid leaked AWS credentials to login to the AWS account.
The compromised user has an attached IAM policy that is misconfigured.
This lets the attacker edit the AssumeRolePolicyDocument of any existing role, which could range from minimal privileges to full control of Elastic Cloud Compute (EC2s) inside the account.
In this case the compromised user is “engineer”
The next step is to check if the user is part of any groups. In this case, the user is part of the “testers” group. This requires the “engineer” user to have the “iam:ListGroupsForUser” permission.
The next logical step for the attacker would be checking the attached policies for this group. This requires the “engineer” user to have the “iam:ListAttachedGroupPolicies” permission.
On observing the output, there are two policies. ReadOnlyAccess is a special managed policy that gives permissions to perform Get and List operations across all of AWS resources. Very useful from a information gathering perspective.
The more powerful policy here, though, is the assumeRole policy.
The assumeRole policy attached to the group allows a user to assume all the roles.
Next step, would be to read the policy definition and read the group permission
Checking inline policies, the compromised IAM user also has IAM_Policy
The IAM permission above looks like it was a permission that was granted for a specific task and not removed afterward or just a permission that was misconfigured.
Checking the actions contained in the policy:
You can see the attached iam:UpdateAssumeRolePolicy
With the iam:UpdateAssumeRolePolicy permission, the user is able to do the following:
- Edit the role they can assume
- Elevate privileges inside the account
The command below is used for privilege escalation
The attacker can now impersonate the new role with assume-role command. The command below returns the temporary security credentials that can be used to access the cloud environment using the new role.
The next step would be the attacker imports these keys locally into his local environment and checks the current logged in user.
Hereby, the attacker has successfully escalated the privileges inside the environment and has impersonated the new role with assume-role.
In this real-world scenario, a user with a misconfigured iam:UpdateAssumeRolePolicy privilege could lead an attacker to gain full control over EC2 instances inside the cloud account.
The information could be used to access all the policies, including AWS managed policies.
For an attacker, this means the chance to create new instances and destroy running instances. This attack could cause catastrophic damage to the company’s cloud infrastructure.
Watch out for the Part 2 and Part 3 posts where we cover other variants of IAM misconfigurations.
— — — —
