Roles Here? Roles There? Roles Anywhere: Exploring the Security o...

Executive Summary

As organizations depend more on applications, devices and services to interact across hybrid environments, non-human identities are becoming more common. To enable secure access for these identities within the organization, Amazon Web Services (AWS) has introduced the AWS Identity and Access Management (IAM) Roles Anywhere service that allows workloads outside of AWS to authenticate using digital certificates instead of traditional access keys.

The AWS IAM Roles Anywhere service offers organizations several security advantages and it is relatively simple to configure, especially for an organization that already has a public key infrastructure (PKI). Usually, implementation of this service requires organizations to carefully consider least privilege and access permissions when designing the infrastructure. Failure to implement proper security controls and practical defense-in-depth architectures could allow an organization to inadvertently open their cloud environment to unwanted exposures.

In this article, we explore key risks associated with improper configuration or architectural design while using the Roles Anywhere service. These risks come from a common root cause. The service's default configuration is relatively permissive within the context of the AWS account and region where the service is configured for use.

We analyze these risks from both a threat actor's perspective and an organization's perspective. This exploration should help readers better understand the potential risks involved when designing the usage of this service and how organizations mitigate them.

Cortex Cloud provides protections against the Public Key Infrastructure (PKI) misconfigurations detailed within this article. By using both Cloud XDR Agent based rules, as well as behavioral analytic rules, to detect when IAM policies are being misused, Cortex Cloud is able to detect and prevent malicious operations using its XSOAR platform automation capabilities.

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

If you think you might have been compromised or have an urgent matter, contact the Unit 42 Incident Response team.

Introduction

Roles Anywhere is an access management service that was first introduced in 2022. It enables external workloads to authenticate to AWS using X.509 digital certificates. This capability eliminates the need to create and manage long-term credentials in such workloads and ultimately makes cloud API operations more secure and easier to manage within AWS environments.

To state it simply, Roles Anywhere can be used to define which certificate authority (CA) certificates are eligible to validate clients' certificates. A client certificate that is signed by such a CA can be used to:

• Authenticate to AWS
• Trade the certificate-based identity for a corresponding cloud-native identity (expressed as a set of temporary credentials)
• Call AWS cloud APIs as normal by signing requests with those temporary AWS credentials

Key Components and Concepts

The authentication process consists of several core components:

• Trust anchors: A trust anchor is the resource that represents the CA certificate in Roles Anywhere. When a trust anchor is created, a CA certificate must be attached to it. There are two types of trust anchors:
  • AWS Certificate Manager-Private Certificate Authority (ACM-PCA) certificate: This is a managed AWS resource.
  • Certificate Bundle: An X.509 certificate encoded in Privacy-Enhanced Mail (PEM) ASCII format that is attached to the trust anchor directly.
• Profiles: These are resources that determine the level of access for an entity that is authenticated with Roles Anywhere. Profiles are assigned with identity and access management (IAM) roles that define the permissions and with additional mechanisms to fine-tune the permissions.
• IAM Roles: The IAM roles are assigned with the actual IAM policies that grant (or remove) permissions.

In practice, authentication using Roles Anywhere is made by sending a request to the /sessionsendpoint. The request is signed with the private key of the certificate and takes as its parameters the Amazon Resource Name (ARN) of the Trust Anchor, as well as the ARNs of the Profile and Role.

An easy way to compose the request is by using the aws_signing_helpertool. This tool automates the authentication process, and it can also make the credentials available locally by emulating the Instance Metadata Service endpoint in much the same way that Amazon Elastic Compute Cloud (EC2) instances work.

Figure 2 shows examples of requests and responses using Roles Anywhere.

Regular Usage of Roles Anywhere

To better understand the configuration flow of Roles Anywhere, consider the following scenario:

• A Kubernetes pod outside of AWS requires access to read objects in a Simple Storage Service (S3) bucket.
• The cloud engineer issues a certificate and signs it using the Trust Anchor's certificate. The signed certificate is then stored in the pod, together with its private key.
• The engineer creates an IAM role that includes the relevant S3 permissions and attaches it to a Roles Anywhere profile.
• The Kubernetes pod can now use the certificate, as well as its associated role credentials, along with the key to sign, authenticate and read objects within the configured S3 bucket.

Securing the Default Authentication Process

One interesting aspect of this authentication process is that by default, there is no correlation between the trust anchor and a specific profile. It is crucial for organizations to understand the risks involved with this setup and configure the Roles Anywhere resources and the IAM roles trust policies accordingly.

In other words, organizations must configure a client certificate to be signed by a specific trust anchor and destined to a specific profile. This will prevent access from any other profile and trust anchor in the same AWS account and region.

To demonstrate the possible consequences of this process, consider the pod scenario outlined above. So far, the steps in the flow are legitimate. For all intents and purposes, the pod has the exact permissions it needs.

But what if an attacker obtains access to the pod? If other profiles were created in the same AWS account and region, the attacker may use the certificate to get access to the roles of these profiles:

• The attacker deduces the ARNs of another IAM role that is attached to the same profile or the ARNs and attached roles of another profile. Deducing these ARNs is a complex task that requires additional permissions to the AWS environment. We discuss these techniques later in this article.
• Having obtained all the necessary information, the attacker can now formulate requests to obtain credentials of different roles and use their permissions to conduct malicious operations.

AWS provides several ways to limit access from Roles Anywhere by using conditions in the role's trust policy. However, the Roles Anywhere default trust policyhas no condition in its statement, meaning that any environment using the default policy does not impose access limitations. It is the organization's responsibility to ensure they are not using default configurations for Roles Anywhere configurations.

When a default role that is used for Roles Anywhere is created, the following trust policy is set:

This policy states that this role can be assumed by the Roles Anywhere service. However, there are no other restrictions for the sources that can assume it. This means that if a role is attached to a profile, any certificate that is signed by a trust anchor in the same region can assume this role.

To address this, AWS created the Condition section in the policy. Conditions enable additional restrictions on resources, specifying the requirements these resources must meet to carry out an action.

The following policy adds a Condition section on top of the default policy, to limit the access of Roles Anywhere authentication to the role, only from a specific trust anchor.

To further limit the access of signed certificates, we recommend taking advantage of the certificate attribute mapping. AWS also recommends this in the Roles Anywhere documentation :

Essentially, it is possible to map a certificate's attributes to values that will be evaluated in the trust policy. People can use this to specify access to roles based on the certificate's Common Name, Organization Unit or any other attribute in the certificate.

This is recommended because it ensures that if a resource that uses Roles Anywhere for authentication is compromised, it will not be able to access additional roles.

The following condition uses the trust anchor condition from the last section and also limits access based on the certificate's attributes:

As with any other service, the principle of least privilege should be considered when implementing Roles Anywhere infrastructure. Certificate attribute mapping should be used to accomplish this.

Threat Actor's Perspective

Scenario #1 - Attacker's Use of Valid Certificates and Private Keys

As outlined above, the following pieces of information are needed to authenticate using Roles Anywhere:

• The client certificate
• The client certificate's private key
• The ARN of the trust anchor that signed the certificate
• The ARN of a profile in the same region
• The ARN of an IAM role that is attached to the profile

In the following scenario, an attacker compromises a default Roles Anywhere configuration for a client certificate that is used for authentication with its private key. To maliciously leverage the default configuration to access additional roles in the account the attacker still needs to discover the ARNs of the relevant resources to authenticate to AWS. Obtaining the ARNs is not a straightforward task and requires additional independent privileges inside the account.

The following techniques can be used to obtain this information:

Using Roles Anywhere actions: An attacker who has gained sufficient permissions to the Roles Anywhere service can simply execute actions to obtain the relevant ARNs. They can do this using the list-trust-anchorsand list-profilesactions, which require the rolesanywhere:ListTrustAnchorsand rolesanywhere:ListProfilespermissions, respectively. The output of these actions contains all the necessary ARNs for the authentication request, as the list-profilescommand will return all the roles that are attached to the profile.

Retrieving data from logs: CloudTrail is the main logging mechanism of AWS. Among CloudTrail logs, an attacker with independent access to CloudTrail logs (or to storage services that contain them) could locate items that are created by the Roles Anywhere service. Some CloudTrail logs contain all the ARNs required for the authentication process. Logs of the Roles Anywhere service disclose these ARNs in the events of several actions.

The most relevant log is CreateSession. This log is created when Roles Anywhere is used for authentication, in other words, to create temporary credentials and send them to the user. Figure 3 shows an example of a CreateSessionlog entry and notes the associated ARN.

The ARNs of a trust anchor, a profile and one of its attached roles appear in this event log. If the attacker's certificate was signed by the trust anchor that appears in the log, they can use it to perform authentication.

Figure 5 shows a high-level illustration of the attackers' steps.

Scenario #2 - Exploiting Direct Permissions to Roles Anywhere

Another scenario in which a default configuration of the Roles Anywhere service could be exploited is when an attacker gains access to an identity that has Roles Anywhere permissions. These permissions may be granted by a direct Allowstatement on the service or through the NotActionelement.

The following steps can be used to take advantage of these permissions:

• The attacker gains access to an identity that has Roles Anywhere default configurations and permissions.
• The attacker creates two certificates - a CA certificate and a client certificate - and then uses the CA certificate to sign the client certificate. Having created the certificates, the attacker also owns their private keys.
• The attacker uses the compromised identity to create a trust anchor and attaches the CA certificate to the anchor.
• Using listpermissions of Roles Anywhere, the attacker gathers profiles and IAM roles ARNs.
• Using the ARNs, the client certificate and its private key, the attacker authenticates using Roles Anywhere.
• If the trust policy of the IAM role denies access, the attacker can check the Roles Anywhere subjects to find details about a certificate that was previously used for authentication and copy its fields to a new client certificate.

In more detail, an attacker with sufficient Roles Anywhere permissions can create a certificate, sign it with the attacker's own CA certificate and upload it to a new or existing trust anchor. This requires the rolesanywhere:CreateTrustAnchoror rolesanywhere:UpdateTrustAnchorpermissions.

Since the attacker controls both the client certificate and the CA certificate, the certificate will be valid. The next step is to understand which profiles and roles are available, by using the Roles Anywhere list-profilescommand or any other technique that is mentioned above.

With this information, the attacker can create credentials through Roles Anywhere and perform operations in the context of the role that was used.

If the target organization's security measures fail to detect the malicious activity, this process also acts as a persistence vector for the attacker, as a trust anchor can be used to generate valid credentials until the issue is resolved.

Mitigations and Recommendations

• We highly recommend adding conditions to the default trust policy of roles that are used with Roles Anywhere. As mentioned above, the default policy allows any trust anchor to assume the role. It is crucial to limit the access to the role only from a specific trust anchor - the one that is used to authenticate the relevant workload.

Additional conditions should also be implemented to limit access only for certificates with certain attributes, such as Common Name or Organization. However, these conditions are not a silver bullet, and they can be bypassed under certain circumstances. For example, a bypass might be possible if an attacker was able to extract attribute information from the certificate.

• We recommend using trust anchors of the ACM-PCA type. When using ACM-PCA, even an attacker who obtains full access to the Roles Anywhere service will not be able to upload their own generated CA certificate to the trust anchor. The trust anchor type cannot be changed, meaning that ACM-PCA permissions (which are uncommon) are needed to authenticate.
  • This is a crucial point. If the roles that are supposed to be assumed by the trust anchors are using the condition from the previous bullet, they cannot be accessed. We should note that private CAs in AWS have their own security considerations and may also pose a risk if not configured correctly.
• Permissions should always be assigned based on the principle of least privilege. The ability to authenticate with Roles Anywhere is usually given to non-human identities, and the devices that use this service usually have specific and pre-determined tasks that they need to perform. Therefore, the access level of these identities should not exceed the requirements of the tasks they are assigned to complete. Apart from the IAM roles themselves, it is possible to associate a session policy with a profile. This policy defines the maximum permissions the role can have, when assumed through Roles Anywhere.
• Regularly monitor and track AWS IAM Roles Anywhere resources: It is crucial to maintain continuous monitoring of trust anchors, profiles and associated resources. Trust anchors and profiles are not created frequently, making their creation or modification suspicious events. Any unexpected changes to these resources should be immediately investigated to ensure no unauthorized activity is occurring. Regular audits and automated alerts can help detect and respond to potential security threats in a timely manner.
• Execute the following XQL query in Cortex Query Builder to identify roles that trust the Roles Anywhere service but do not enforce any conditions.

Conclusion

This article has explored key risks associated with using default configurations for the Roles Anywhere service in AWS, both from a potential attacker's perspective and a defender's perspective. We have provided several mitigation strategies organizations should implement to better manage the associated risks. We hope that this analysis helps readers better understand the potential vulnerabilities involved in using the default functionality of this service, and how best to mitigate them.

One key takeaway from this article is that when using services from cloud providers, it's crucial to thoroughly understand their configurations and architecture rather than relying on them uncritically.

• Follow security best practices, least privilege and defense-in-depth strategies.
• This helps ensure that services are properly architected and monitored for configuration modifications.
• Maintaining runtime monitoring will help to ensure customized cloud platforms operate securely

Cortex Cloud provides protections against the Public Key Infrastructure (PKI) misconfigurations detailed within this article. By using both Cloud XDR Agent based rules, as well as behavioral analytic rules, to detect when IAM policies are being misused, Cortex Cloud is able to detect and prevent malicious operations using its XSOAR platform automation capabilities.

Organizations can gain help assessing cloud security posture through the Unit 42 Cloud Security Assessment.

If you think you may have been compromised or have an urgent matter, get in touch with the Unit 42 Incident Response team or call:

• North America: Toll Free: +1 (866) 486-4842 (866.4.UNIT42)
• UK: +44.20.3743.3660
• Europe and Middle East: +31.20.299.3130
• Asia: +65.6983.8730
• Japan: +81.50.1790.0200
• Australia: +61.2.4062.7950
• India: 00080005045107

Palo Alto Networks has shared these findings with our fellow Cyber Threat Alliance (CTA) members. CTA members use this intelligence to rapidly deploy protections to their customers and to systematically disrupt malicious cyber actors. Learn more about the Cyber Threat Alliance.

Additional Resources