Cyber Security

Are AWS Account IDs secrets?

Uncover the Truth: Are AWS Account IDs Secrets? Learn Crucial Insights for ECR Security and Prevention. Essential Reading for IT Managers and Administrators!

Albert Heinle
Written by
Albert Heinle

There are active debates about whether or not AWS account IDs should be treated as secrets or not.

The common consensus is “no”. Trivy removed AWS account IDs from their checks based on commentary and community feedback. The AWS git-secrets checker continues to flagging account ids. Suggesting there are differing views of role or potential risk of exposing AWS Account IDs.

We think that these discussions are bonkers.

You read that correctly. At CoGuard, we follow guidelines that seek to expose only the minimum amount of information required. Asking the question, is this information I need to expose? Yes: do it, but check that you are doing it right. No: Don’t do it.

The more information an attacker has an a system and it’s users, the more adeptly they can craft a targeted attack. Rhino Labs has shown that AWS Account IDs can be used for different attack scenarios including resource enumeration (identifying existing roles, users, etc.), Lambda function invocation, and IAM role assumption.

AWS ECR - A Treasure Trove of AWS IDs

If you use AWS Elastic Container Registry (ECR) to store and deploy your Docker containers, you might not be aware that your account ID is exposed even for private registries. All endpoints, even private ones, include the AWS Account ID in the URL Endpoint. This means that any post to your container registry is exposing your account ID.

A common location for exposing container registry information is in the build scripts as part of a CI/CD pipeline. If we look a bit deeper, can we find Account IDs in GitHub Actions?

A simple query on GitHub exposes over 35,000 results for a single AWS Region (US-East-1).

It is possible to expand and refine the list of active IDs using unauthenticated tools like Quiet Riot to expand the list with more than account ids. Additional information can be gathered about each Account ID using Rhino Security Labs Pacu (or a number of other available tools).

Searching on GitHub for AWS Account ID returns results that include the main contributors to each repository. It is quite likely that each contributor also has some form of an AWS account? It may take additional effort and social engineering to gain more insight. An attacker can now target those individual users to figure out their username (likely their email address) through social discoverability. It leaves only a password, which may be exposed through previous breaches or may potentially access through further social engineering.

An attacker would like to gain access to the users/accounts’ AWS management console. To do this they need an account number (see above), a username and a password. The GitHub repositories show a potential attacker the main contributors to the repository. It is very likely that the main or key contributors have AWS access.

Limiting Access to External Attacks

Even private ECR instances can be identified through enumeration of ECR endpoints. For any AWS account only aws_account_id and aws_region change in the ECR endpoint

One method of prevention would be to limit the IP addesses accessing ECR. Unfortunately, there is no direct way of limiting the IP addresses which are able to access ECR (CloudFormation documentation of ECR). It is difficult to add extra layer of security (IP address restrictions) to ECR. 

This leaves the ECR endpoints open and available for external access. And while the endpoints are behind a layer of authentication, this provides a false sense of security. Because each endpoint is one CVE away from external access. If an attacker has access to the ECR, they have the ability to run docker login --username userNameFromToken --password passwordFromToken and access the auth token which is a base64 encoded username and password that can be used for AWS CLI access. ECR tokens have a validity of 12 hours. This means if an ECR authentication token is compromised,there is a high possibility that an attacker will have sufficient time to infiltrate and exploit images and beyond.

Automating Infrastructure & Configuration

We appreciate the ongoing complexity as IT operations must support legacy environments and adapt to new-new development where teams may use whatever technology they feel is the best fit. While senior management may believe they have solved these challenges with DevOps, we know that dev teams may not know where ops teams sit in the building. At CoGuard, we know in that heterogenous, multi-cloud environments that automation of the configuration and deployment of infrastructure and applications is necessary to manage the complexity.

CoGuard provides automated tools that discover configuration files for applications, containers, infrastructure and perform configuration scanning (akin to SAST). We have added a new rule that checks your pipeline scripts for accidental exposure of your account id via ECR (github_actions_ecr_account_id_exposed). The rule raises an alert to the exposure of AWS Account ID in build scripts including GitHub Actions. If you use GitHub Actions, it is not difficult to move the account ID to a secret and fill it in in your pipeline scripts.

Photo credit: CHUTTERSNAP on Unsplash

Explore a test environment

Thank you! Your submission has been received!
Oops! Something went wrong while submitting the form.

Check out and explore a test environment to run infra audits on sample repositories of web applications and view select reports on CoGuard's interative dashboard today.