Amazon Web Services Keys Token

ID

aws_token

Severity

low

Vendor

Amazon Web Services

Family

API Token

Description

Amazon Web Services (AWS) use access keys for programmatic calls to AWS or for authentication in the AWS command-line interface. An access key is a pair (Access Key ID, Secret Key) where Access Key ID (like AKIAIOSFODNN7EXAMPLE) acts as the username and Secret Key (like wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY) acts as a password.

A user typically have at most two AWS access keys, which should be stored in a safe place.

The Session Token is a short term, temporary credential. After expiration, it is no longer valid. They may be used in less secure environments.

Security

Any leakage of the Secret Access Key is critical. The Access Key ID is less sensitive, but it should not be made public.

The Session Token, due to its temporary nature, is less sensitive and expires automatically.

Examples

The following example shows a hardcoded AWS access key (id and secret) in a shell script:

export AWS_ACCESS_KEY_ID=AKIAIOSFODNN7EXAMPLE
export AWS_SECRET_ACCESS_KEY=wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

The following example shows a Terraform template with hardcoded AWS key:

provider "aws" {
  region = var.region
  - access_key = "AKIAIOSFODNN7EXAMPLE"
  - secret_key = "wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY"
}

In this case, it is better to use one of the alternatives for managing secrets in Terraform code.

Mitigation / Fix

  1. Remove the Access Key from the source code or committed configuration file. Avoid hardcoded secrets, and instead place the keys in a 'secrets vault'.

  2. Follow your policy for handling leaked secrets, which typically require revoking the secret in the target system(s). Go to the AWS Management Console as the AWS account root user, and choose the desired account name. Go to 'My Security Credentials', expand the 'Access Keys' section, and delete the leaked access key.

Do not inactivate the key. Disabled keys can be re-enabled later, but when leaked the key should be deleted and never reused.

  1. If under a git repository, you may remove unwanted files from the repository history using tools like git filter-repo or BFG Repo-Cleaner. You may follow the procedure listed here for GitHub.

You should consider any sensitive data in commits with secrets as compromised.

Remember that secrets may be removed from history in your projects, but not in other users' cloned or forked repositories.

  1. Check access logs to ensure that the secret was not used by unintended actors during the compromised period. They can be accessed using AWS CloudTrail.

Reference

https://docs.aws.amazon.com/IAM/latest/APIReference/welcome.html