A Scalable AWS Enumeration and Footprinting Tool

This article is intended to serve as a “blue team” focused response to last week’s post on Quiet Riot, a tool I built for unauthenticated enumeration of services, roles, and users in an AWS account or in every AWS account in existence.

 If you haven’t read that blog post, I would encourage you to start there to gain the relevant context regarding what Quiet Riot does and how it works.

Impact

Core Capabilities

If you’ve read the initial post on Quiet Riot, you know that Quiet Riot supports the ability to identify valid account IDs, roles, and users for accounts across AWS, without having privileges against the AWS account, users, or roles.

By itself, this capability has limited value. While it may be helpful to know what account IDs are active in AWS or what roles and users are in a particular account, this information can only enhance an attacker’s context to a small degree and only aids in reconnaissance.

With the core capabilities of Quiet Riot, I am aware of two specific benefits to an attacker:

• An attacker with a known target account and a valid user list could attempt to dictionary attack login credentials for the AWS portal, subject to optional MFA.
• An attacker with a known target account and a list of potential service-linked roles could identify AWS services in use for a target account.

Thanks to Rodrigo Montoro and Kinniard McQuade, I was able to update the wordlist of service-linked roles to include every service-linked role that was queryable via AWS IAM APIs. This has allowed an update to provide the option to “footprint” an AWS account once you specify the Account ID. If you choose the “footprint” option, you can scan the account to determine what services have been enabled in the account for services that support service-linked roles.

Other Common Roles and Users

Furthermore, I’ve expanded the wordlist to include other common roles and users. For instance — if an account is the Organization Management account for an AWS Organization, someone may have configured:

  arn:aws:iam::{account_id}:role/OrgMgmtRole

within the account to perform various Organization-wide automations. More likely, if the account is a child account of an AWS Organization and the account provisioner used the AWS-recommended/default-configuration role name for provisioning the account’s organization management role it will be named:

arn:aws:iam::{account_id}:role/OrganizationAccountAccessRole

Perhaps the organization is using Okta as the Identity Provider (IdP) for Single Sign-On (SSO) or DataDog is integrated for logging and monitoring. These are some of the potential roles that are identifiable via the new ‘footprint’ option.

I am sure the list can still be expanded tremendously. Anyone who knows of other default or common roles or users is encouraged to make a pull request against the Quiet Riot repository to update the included wordlist.

New Capability: Root Account E-mail Addresses

Thanks to the seemingly exhaustivethreat model of s3 performed by TrustOnCloud, we know that s3 ACLs (a legacy feature from before bucket policies existed) allow the enumeration of root account e-mail addresses. Root account e-mails are another method for signing in to the AWS portal with a password (and optional MFA). Root account credentials are the most privileged credentials in any AWS account. They would allow an attacker to perform any action, including deleting all resources and closing the account. I have updated Quiet Riot to allow for enumeration of these root account e-mails, albeit at a significantly slower speed than other capabilities.

Mitigations

To recap, Quiet Riot currently enables enumeration of:

• AWS Account IDs
• AWS users and roles when provided an AWS Account ID
• AWS Root Account e-mail addresses

and limited enumeration of:

• AWS services in use via service-linked roles
• Vendor services in use via common or default vendor roles

Shared Responsibilities Model

The shared responsibilities model has always been a vague gesture towards some approximate division of responsibilities between AWS and its customers, without addressing vendors or the responsibilities that exist for patterns deployed by vendors across widespread AWS customer accounts. Below, I’ll address potential mitigations for each issue individually and the three different parties that are a part of a practical shared responsibilities model:

• AWS — the cloud service provider.
• Vendors — marketplace vendors and other vendors with widespread deployment of IAM roles configured with cross-account trusts to a single account or vendors who configure insecure use of IAM users. AWS customers can (largely) identify their vendors by reviewing roles with cross-account trusts external to their known accounts and users with names that appear to be technology product-related. Attackers can identify these vendors by using Quiet Riot, scraping the internet for vendor roles and users, and evaluating the associated permissions policies to determine which vendor roles or accounts would have the most significant impact. Once the associated Quiet Riot capability matures, I hope it will be used by defenders as well.
• AWS Customers — the owner of an AWS account and a consumer of AWS and vendor services.

Account ID

AWS — Unfortunately, it will be very challenging to keep this information from the public domain. Personally, I’ve enumerated what I estimate to be 0.05% of all AWS accounts currently in existence. You can find these ~35k (and growing) Account IDs in the Quiet Riot Github repository as one of the wordlists. If 100 accounts are running Quiet Riot with no slow-downs for ~3.5 months and no repetition of random Account IDs, all 1 trillion AWS Account IDs would be enumerated. I believe by crowdsourcing, this could be cut down much further. You can make pull requests to add to the list of known Account IDs.

AWS Customers —N/A, AWS customers have no option regarding this configuration.

Users and Roles

AWS —Increased throttling of put-resource-based policy API calls across services would reduce the effectiveness of this particular attack, but given enough time and a targeted user and/or role list, the capability would still be effective. However, there is the possibility for AWS to suppress this particular error message as part of API endpoint error management. AWS has been reluctant to take this approach due to usability trade-offs. Based on a Twitter response from Luc Van Donkersgoed, we know that at least one AWS service does not allow this enumeration (SQS).

AWS Customers —For users and roles that are custom-named by the AWS customer, the addition of a UUID or similar high-entropy string in the role or user name will dramatically improve resistance to enumeration. Key risks to consider are any dependencies that may exist in a particular account or in other accounts for the specific user or role. AWS customers can leverage CloudTrail to review users and roles to determine their uses*. For users, ensuring MFA and strong password complexity is critical to breaking the attack chain at the reconnaisance phase. I personally don’t believe users should be a part of almost any AWS account in 2021, but that is for another post.

*Note: If the user or role is a resource owner for certain AWS resources, this won’t necessarily appear in CloudTrail, but may create breaking changes.

Root Account E-mail Addresses

AWS —Increased throttling of S3 put-bucket-acl and put-object-acl would reduce the effectiveness of this particular attack, but given enough time and a targeted e-mail list, the capability would still be effective. Of course, AWS could deprecate this capability as it is only supported in “legacy” regions. In addition, there is an option to suppress this particular error message as part of error management as mentioned regarding users and roles above.

AWS Customers —Using an e-mail address for the root account that includes a high-entropy string and is not re-used for other purposes decreases the likelihood that a particular root account e-mail will be enumerated. Unfortunately, it isn’t particularly easy to change a root account e-mail at scale if you haven’t already used a high-entropy e-mail address.

Configuring MFA on the relevant root account is also a necessary mitigation to address the risk associated with this capability and a general best practice.

Another available mitigation is the use of complex passwords for root accounts. Fortunately, if you leverage AWS Organizations to create a child account, the root account will be provisioned a very complex password by default.

AWS Services (Service-Linked Roles)

AWS — It’s hard to say what would be a reasonable or appropriate mitigation for this particular capability. It depends heavily on how AWS is leveraging these service-linked roles in codebases (and the downstream automations) across AWS services. If possible, it would be beneficial to add a high-entropy string to each service-linked role provisioned in a specific account, but I do not know if this would work and suspect it would take significant engineering effort likely better spent elsewhere. TL;DR — we are likely stuck with this capability.

AWS Customers — N/A, AWS customers have no option regarding this configuration.

Vendor Roles and a Supply Chain Risk

AWS —AWS should provide vendors guidance regarding best practices for deploying widespread roles and the associated permissions securely.

I also have concerns about supply-chain attacks exploiting widespread misconfiguration of vendor roles. Namely, if attackers are able to identify a vendor role or user that is used across many accounts with privileged access, the source vendor account becomes an extremely high-value target for attack. It is already known, from limited sampling, that vendors don’t always have strong security practices associated with these roles. An SSO provider, CI/CD provider, SD-WAN provider, virtualization infrastructure provider, or other security load-bearing software providers pose a critical risk if compromised in a fashion that allows widespread use of STS assume-role or similar to initiate ransomware of the vendor’s customer accounts.

AWS should expand guidance to vendors and third-party solution providers in AWS to address this systemic issue along with the issue around enumeration, as the enumeration capabilities make this risk even more visible.

Vendors —Vendors can configure their AWS integrations to support the use of unique, high-entropy role names.

AWS Customers —AWS customers who are extremely cautious can attempt to rename certain vendor roles that are customer-defined to include a UUID or other high entropy string to make it significantly more difficult to enumerate. However, I recommend against this without extensive testing to determine what dependencies may exist on the specific role.