AWS Pentest Series Privilige Escalation over IAM (assumerole)

In this part of the blog series we will examine the IAM privilige escalation by using assumerole. Before we start I want to give you some basic privilige escalation methods for IAM. Some common IAM (Identity and Access Management) privilege escalation methods:

1. Exploiting Weak or Stolen Credentials: Attackers may use techniques like phishing, brute-forcing, or credential theft to obtain valid user credentials. With these credentials, they can log in as legitimate users and potentially escalate their privileges within the IAM system.
2. Misconfigured IAM Policies: Improperly configured IAM policies can inadvertently grant excessive privileges to users or roles. Attackers search for misconfigurations that allow them to exploit these vulnerabilities and elevate their access within the system.
3. Abusing Trust Relationships: In complex IAM setups involving cross-account or cross-service trust relationships, attackers may exploit weak or misconfigured trust policies to gain elevated access across different accounts or services.
4. Exploiting IAM Role Assumptions: IAM roles often allow users or services to assume higher-level privileges temporarily. Attackers may identify roles with overly permissive policies or weak trust relationships and exploit them to assume those roles, granting them escalated access.
5. Permission Escalation through Group Membership: By manipulating group memberships within an IAM system, attackers can add themselves to groups with higher privileges. This allows them to inherit the permissions associated with those groups and gain elevated access.
6. API Call Abuse: IAM systems often provide APIs for programmatic access. If these APIs are not properly secured, attackers may discover and exploit vulnerabilities in the API endpoints to escalate their privileges.
7. Privilege Escalation via Service Accounts: Service accounts, used for automated processes or system-to-system communication, may have excessive privileges or weak security controls. Attackers can abuse these accounts to escalate their privileges within the IAM system.
8. Exploiting IAM Policy Language: The syntax and semantics of IAM policy language can be complex. Attackers may exploit weaknesses or ambiguities in policy definitions to craft or modify policies that grant them additional privileges.

It’s important to note that IAM privilege escalation methods can vary depending on the specific IAM implementation and configuration. Additionally, these methods evolve over time as new vulnerabilities are discovered. Organizations should regularly assess their IAM configurations, monitor for suspicious activities, and follow security best practices to mitigate the risk of privilege escalation.

Lets evealuate a scenerio for giving an dinstictive example;

Below the command show us the mfa devices;

ad-user’s arn and user Id can be shown from the output

we used get-login-profile for getting some information about the ad-user like passwordresetrequired.

We need to know group names. So we listed group names;

After that we have already known mfa devices, users, user login informations and groups. Now We wonder that each groups policy for finding a weakness;

Now it is time to dig the attached group policies.

Boom the policyname is AdministrotorAcess. Wow.. I used list-policies for retriewing the content of the policies;

Lets explore the acustomer-managed-policy;

This policy is attachable it is important. Because If can can get a chance we can attach the policy to normal group or user.

aws iam get-policy-version used for learning version and resource and actions.

When we listed roles we saw logging role;

Boom! Action is AssumeRole.. In AWS (Amazon Web Services), AssumeRole is a feature that allows you to delegate access to AWS resources across different AWS accounts or services. It enables an IAM (Identity and Access Management) user or application to assume a specific IAM role temporarily, granting them the permissions associated with that role.

Here’s how the AssumeRole process works:

1. IAM Role: First, an IAM role needs to be created in the AWS account that holds the resources you want to access. This role defines the specific permissions and policies that determine what actions can be performed and which resources can be accessed.
2. Trust Relationship: The IAM role must have a trust relationship established with another AWS account or AWS service. The trust relationship defines which entities are allowed to assume the role. For example, you can specify an IAM user, an IAM role from another account, or even an AWS service like AWS Lambda.
3. AssumeRole API: To assume a role, an IAM user or application must make an API call to the AssumeRole operation, providing the necessary parameters such as the ARN (Amazon Resource Name) of the role to be assumed and the session name.
4. Temporary Security Credentials: When the AssumeRole API call is successful, AWS validates the trust relationship and returns temporary security credentials to the calling entity. These credentials typically include an access key, a secret access key, and a session token.
5. Using Temporary Credentials: The entity receiving the temporary credentials can then use them to make requests to AWS services and resources. The temporary credentials have the permissions associated with the assumed role, allowing the entity to perform actions and access resources as defined in the role’s policies.

It’s important to note that the use of AssumeRole allows for fine-grained access control and helps in scenarios where you want to grant access across AWS accounts or services without sharing long-term credentials. Additionally, AWS provides various SDKs and CLI tools that simplify the process of assuming roles programmatically.

By leveraging the AssumeRole functionality, you can implement a more secure and controlled approach to access management within your AWS environment.

Now it’s time to use assumerole for exploiting the weakness;

aws sts assume-role

We have already obtained Credentials like AcessKeyId and SecetAccessKey and Sessiontoken. It’s time to export them;

Nice we have already escalate our privilige lets test it aws sts get-caller-identity;

When we list the attached role policies we can see S3readonly access. Lets try to read the bucket contents;

Now we can list the content of the buckets.

Thank you for reading.