Enumerating Access for AWS Temporary Credentials

Enumerating Access for AWS Temporary Credentials

I recently came across a scenario where I had access to AWS temporary credentials during a penetration test and there didn’t seem to be any clear articles detailing how to enumerate access to these credentials. The purpose of this article is to explain what AWS temporary credentials are, where you may find them and how to enumerate their permissions.

What is the AWS Instance Metadata Service (IMDS)

The AWS IMDS service provides EC2 instances with metadata about themselves like their instance ID, instance type and security groups. This service is available from within the metadata instance by calling an internal URL. This is typically used for configuring or managing the instance without needing a publicly accessible URL. Despite providing functionality to the virtual machine, attackers commonly exploit it.

What scenarios may result in access to these credentials?

Temporary credentials are available once you have access to the internal AWS network. This can be achieved through multiple attack vectors:

Server-side request forgery

If a web application is hosted in an AWS environment and it is possible to perform server-side request forgery attacks, it may be possible to query the IMDS and return temporary credentials. Server-side request forgery occurs when it is possible to trick the underlying server of a web application into making requests to an external resource. As the web server is part of the internal network, it may be able to access resources that can only be accessed internally.

Gaining RCE on an EC2 instance

If you are able to gain remote code execution, through exploiting a network or application layer vulnerability, such as an exploit on a service or exploiting a file-upload function, it may be possible to access these credentials. You may also be able to get access by other means like brute-forcing an SSH connection. This is because we are able to send requests from within the internal AWS environment.

Short-term vs. Long-term credentials

It is possible to access temporary credentials through the IMDS service. Temporary credentials are short-lived tokens that are dynamically generated and have a short expiry time.  These are typically created to give an application access to the AWS service or to temporarily give a user elevated credentials.

Long-term credentials are static and do not expire until they are deleted. They are typically given to long-term users or applications. As these do not expire, they are seen as a higher security risk than temporary credentials.

AWS Temporary Credentials

The AWS metadata API can be used to store arbitrary information and, therefore, can potentially give access to multiple forms of credentials, including API keys, environment variables, or configuration files. In this article, we are going to explore AWS temporary credentials that are issued by the AWS Security Token Service (STS). These credentials comprise three components:

• Firstly, an AccessKeyID which is the unique identifier for the temporary session.
  • For short term credentials, they key will start with ASIA and for long term credentials, the key will start with AKIA.
• A secret string is also used to sign and authenticate API requests; this is known as the SecretAccessKey.
• Finally, there is a SessionToken which is a required parameter for temporary credentials.

Unlike IAM user credentials, these credentials expire after a short, set time (usually between 15 minutes and 12 hours). They are typically tied to IAM roles, allowing for fine-grained permissions and time-based access.

These credentials can be accessed by sending a request to the following endpoint. Depending on the IMDS version, a header with an authentication token will need to be added to the request.

http://169.254.169.254/latest/meta-data/iam/security-credentials/{Role-name}

IMDSv1 vs IMDSv2

IMDSv1 utilizes a standard GET request with no authentication to access the metadata endpoint. This means that any data can be retrieved without providing an authentication token. The following curl command is a valid request to access the endpoint; it may list all available roles, depending on your permissions.

The following request will return temporary credentials relating to the role:

IMDSv2 utilizes authentication to access the metadata endpoint. This means that we need to send a request to the metadata API to obtain an authentication token that we attach to any future requests to the endpoint. The following PowerShell script can be used to request the token and request information from the metadata API using the token:

Why are temporary credentials used?

There are multiple reasons why these credentials may be used.

If a role is assumed, via the sts:AssumeRole action, AWS will issue temporary credentials. This action is part of the STS  (Security Token Service) and it allows a user, service, or application to adopt permissions that are associated with the chosen role.

For example, if you have an EC2 instance that needs temporary access to an S3 bucket in another AWS account, the EC2 instance (or its assigned IAM role) will assume a role in the target account. AWS will verify permissions and issue temporary credentials that match the role’s policies. These credentials can then be used to access the bucket until they expire.

An EC2 instance may be assigned an IAM role, and applications running on the instance can query the Instance Metadata Service (IMDS) for temporary credentials.

For example, a Python application running on an EC2 instance needs to upload logs to an S3 bucket. The EC2 instance has an IAM role with the s3:PutObject permission for the bucket. The application queries the IMDS which returns temporary credentials for the role.

Temporary credentials can also be created during authentication via SAML or OpenID Connect. Similarly, Lambda functions and ECS tasks also use temporary credentials issued for their respective roles. For example, a user logs in to the AWS Management Console using an organization’s SSO portal integrated with AWS via SAML.

Temporary credentials typically are associated with an IAM role, but they can also be associated with an IAM user.

IAM User

An IAM user is a user that requires direct access to AWS resources. These are designed for long-term access for employees, developers, and applications that require credentials. The permissions are explicitly attached to a user via the AWS IAM policies.

What are policies?

Policies are JSON documents that define the permissions granted to a user, group, or role. They specify actions, resources, and conditions under which access is allowed or denied.  They are structed as follows:

• Actions: The operations (e.g., s3:GetObject) that the entity can perform.
• Resources: The AWS resources (e.g., arn:aws:s3:::example-bucket) the entity can access.

For example, the following JSON shows a user with read only access to all S3 buckets:

IAM Role

An IAM role is a role that can be assumed by trusted entities such as applications, services, or users needing temporary elevated permissions. Permissions are attached to the roles via policies and a trusted entity can assume the role and gain the attached permissions. If the credentials are associated with an IAM role, they will always need the session token parameter. Roles are stateless entities that require a trusted entity to assume them. This prevents administrators from having to allocate a long-term key to a resource, reducing the impact of credential exposure.

If you can access temporary credentials on an assessment, you should consider the following questions:

• Are these credentials able to perform any sensitive actions?
• What resources are they able to access?
• Can you use them to escalate your privileges?

Are the credentials valid and what are they?

Firstly, you should validate the credentials to ensure that they are valid. This can be achieved by adding the credentials into a file in your ~/.aws/credentials directory and using the AWS CLI to run the following command:

If the credentials are valid, this will return the UserID, Account, and ARN, as displayed in the following example. It is possible to identify if the credentials are associated with an IAM role or an IAM user based on the output.

The following example output displays when using credentials attached to an IAM role:

The following example output displays when using credentials attached to an IAM user:

Can you enumerate the permissions attached to the credentials?

This can be achieved manually by querying the AWS CLI to view the attached policies:

If this does not return any permissions, you likely do not have permission to perform these actions. PACU (https://github.com/RhinoSecurityLabs/pacu) can be used to brute-force any permissions associated with the credentials by using the iam__bruteforce_permissions module via the following commands:

1. Create the ~/.aws/credentials file and store the credentials in the same format as the following example:

2. In PACU – run the import-keys command

3. Run the IAM brute-force permissions module

This module uses non-destructive techniques to brute-force what permissions the keys are associated with. This output should be used to identify future targets; for example, if you have a lot of permissions over S3, this should be investigated further.

Can you perform any sensitive actions on AWS resources?

S3 buckets

PACU can be used to enumerate which buckets you have access to. The following module will return all owned buckets and gather information about their permissions and policies.

EC2 instances

PACU can be used to enumerate EC2 instances. This command will gather details about all EC2 instances in the account, such as instance IDs, public and private IP addresses, instance types, and regions.

IAM (Identity)

PACU has a module that can be used to CHECK IAM for any potential privilege escalation techniques:

Conclusion

AWS temporary credentials are a way to create permission-based, short-lived access to AWS resources. As a pentester, you should always investigate these credentials, if discovered, to look at their permissions, what resources they can access, and look for any privilege escalation techniques. By design, these credentials typically have a small scope, however, they can be misconfigured.