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

• Is it really necessary to strip the AWS account ID from tutorials?
• Are AWS account IDs sensitive information?
• AWS Account ID: An Attacker's Perspective

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

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. 

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.