Amazon Web Services Keys Secret

ID

aws_secret

Severity

critical

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. Follow your policy for handling leaked secrets, which typically require generating a new Access Key and deleting the leaked one.

    • Using the console: Go to the AWS Management Console as an IAM administrator, and choose the desired account name. Go to Security Credentials, scroll down to the Access Keys section, click the Actions combo, and click on Delete.

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

      In the same Access Keys section, click Create access key to create a new access key for the user, and take note of the new Access Key ID and Secret.

    • Using aws tool: You may use the aws command-line tool to delete the leaked access key and generate a new one:

      aws iam delete-access-key --user-name <user-name> --access-key-id <access-key-id>
      aws iam create-access-key --user-name <user-name>
      # Take note of the new access key ID and secret pair.
  2. Remove the Access Key from the source code or committed configuration file. Replace hard-coded secrets with a more secure alternative, such as one of the options documented in How to Prevent Hard-Coded Secrets.

  3. (Optional) 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.

  4. 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.