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
-
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 theAccess Keys
section, click theActions
combo, and click onDelete
.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, clickCreate 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.
-
-
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. -
(Optional) If under a git repository, you may remove unwanted files from the repository history using tools like
git filter-repo
orBFG 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.
-
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.