Protect your AWS secrets

I accidentally published my AWS credentials online. I got an immediate email from AWS explaining the exposure of AWS secrets and the importance of securing these keys. They attached an AWS Quarantine Policy to the compromised IAM User, limiting access to AWS services and requested I take action to ensure the security of my AWS account, with clear and detailed instructions.

A few hours later, I got a call from an AWS representative reminding me to secure my account, as I missed that original email. This is awesome and appreciated!

We should not have credentials stored in code at any point in time (I've seen this in too many places, though). I was testing an AWS service and was too lazy to set up my credentials as environment variables when running the nodejs program. They ended up on Github. This post explains in detail what to do if you inadvertently exposed your AWS keys: https://aws.amazon.com/blogs/security/what-to-do-if-you-inadvertently-expose-an-aws-access-key/.

How can we prevent this kind of incident?

Scan your repositories

As I was investigating a few ways to prevent exposing keys, I stumbled across git-secrets, an excellent library. Here's how it works.

git-secrets scans the commits and prevents adding secrets to a commit according to a pre-configured regular expression.

Installation & Usage

• As I am using a macOS, I will use brew for installation (the documentation covers other operating systems): brew install git-secrets.
• To make it simple, we will use an index.js file with the following code:

  const credentials = {
  accessKeyId: 'asdfsdfse33SSDFFF',
  secretAccessKey: 'GHGSDFS@###RWSDFSZssssss',
  };

  console.log(credentials);

• Afterwards, we will configure a pattern for git-secrets. In your terminal: git secrets --add 'credentials'. You could replace 'Credentials' with any regular expression of your choice.
• Scan the repository: git secrets --scan src/*.js - index.js lives under the src folder in this case. Notice the response you:

  src/index.js:1:const credentials = {
  src/index.js:6:console.log(credentials);

  [ERROR] Matched one or more prohibited patterns

  Possible mitigations:
  - Mark false positives as allowed using: git config --add secrets.allowed
  - Mark false positives as allowed by adding regular expressions to .gitallowed at repository's root directory
  - List your configured patterns: git config --get-all secrets.patterns
  - List your configured allowed patterns: git config --get-all secrets.allowed
  - List your configured allowed patterns in .gitallowed at repository's root directory
  - Use --no-verify if this is a one-time false positive

Now let's delete this pattern and move to check more advanced patterns. That's a bit of work as there's no command implemented yet to remove a pattern (Feel free to contribute to the implementation of this feature). In the meantime, here are the steps to remove the pattern manually:

- In your repository, open `.git/config` and delete the patterns line under the [secrets] tag

Re-run the scan and notice how no patterns matched, even though we still have the credentials in our index.js file.

Configure git-secrets for AWS keys

Instead of configuring a pattern manually, git-secrets enables us to check against common AWS patterns using the --register-aws option. To add these patterns, run: git secrets --register-aws. Notice the following patterns added to the .git/config file:

providers = git secrets --aws-provider
patterns = (A3T[A-Z0-9]|AKIA|AGPA|AIDA|AROA|AIPA|ANPA|ANVA|ASIA)[A-Z0-9]{16}
patterns = (\"|')?(AWS|aws|Aws)?_?(SECRET|secret|Secret)?_?(ACCESS|access|Access)?_?(KEY|key|Key)(\"|')?\\s*(:|=>|=)\\s*(\"|')?[A-Za-z0-9/\\+=]{40}(\"|')?
patterns = (\"|')?(AWS|aws|Aws)?_?(ACCOUNT|account|Account)_?(ID|id|Id)?(\"|')?\\s*(:|=>|=)\\s*(\"|')?[0-9]{4}\\-?[0-9]{4}\\-?[0-9]{4}(\"|')?
allowed = AKIAIOSFODNN7EXAMPLE
allowed = wJalrXUtnFEMI/K7MDENG/bPxRfiCYEXAMPLEKEY

To test this, copy your AWS credentials from ~/.aws/credentials into the index.js file, then run git secrets --scan src/*.js. Notice the matched pattern.

Finally, include this as part of your process. You could add git-secrets as a pre-commit hook by running git secrets --install - Once the hooks are installed for a git repository, commits, and non-fast-forward merges for that repository will be prevented from committing secrets. Also, it could be a good idea to scan your repository as part of CI/CD and fail the pipeline if secrets exposure occurred - this enables you to take immediate actions as soon as possible, even though after the fact.

How do you protect your secrets?