Overview

In this second blog post in our series on cross account trust, we explore Alibaba Cloud’s approach to cross account trust and the security implications of their trust model. While any hosted platform can be impacted by cross account trust misconfigurations, Cloud providers are particularly sensitive to cross account trust attacks because they rely on customers delegating access. Considering that Alibaba Cloud is presently the third largest IaaS cloud provider globally and largest IaaS cloud provider in Asia Pacific, we thought that it would be a good time to explore the design of cross account trust in Alibaba Cloud. We start by explaining what cross account trust is and why it is crucial for certain applications. Next, we examine the way Alibaba Cloud has designed cross account trust. Finally, we explore the confused deputy problem and how Alibaba Cloud is susceptible to such an attack.

Terminology Used

  • SaaS Customer (Victim) – This refers to the victim of the attack and the legitimate customer of the SaaS vendor. This party will be granting access to the SaaS vendor for legitimate purposes.
  • Saas Vendor – This refers to a service granted legitimate access to a SaaS Customer’s (Victim) environment to provide services such as logging, security management, and billing management.
  • SaaS Customer (Attacker) – This refers to a user who tricks the SaaS vendor into accessing the SaaS Customer’s (Victim) cloud via the confused deputy problem.

What is account trust and why is it necessary?

Companies often use SaaS vendors to manage functions of their cloud environment, such as logging, patch management, and security monitoring. In these scenarios, the companies grant a certain level of access to SaaS vendors, with the expectation that access is limited to performing said managed services.

There are two main ways to grant cross account trust. The first way to grant this access is to generate access keypairs which contain an ID to identify the user and a secret which is used to verify the identity of the user. The second way of providing access to SaaS vendors would be to create a special role for them and to have specific access policies attached to the role. The policies would specify the account ID of the SaaS vendor and the roles in the SaaS vendor’s cloud that can assume this special role. Specific implementation of the access policies differ from provider to provider, so we chose to focus our research on Alibaba Cloud’s cross account trust implementation.

We find that each has its benefits and the choice will depend on the use case. We will not be going into the specifics but look out for the next blog post which will discuss the differences and use cases of both methods in detail.

How does Alibaba handle cross account trust?

To achieve cross account trust, Alibaba Cloud uses Resource Access Management (RAM) roles which have policies attached to them. The policy would specify the action “sts:AssumeRole” and the account ID of the SaaS vendor which the SaaS Customer (Victim) wishes to grant access to. The SaaS vendor would then be given the Alibaba Cloud Resource Name (ARN) which they would use to AssumeRole from their cloud account.

In the below example, the SaaS vendor has an Alibaba Cloud ID of 1234567890123456. The policy basically states that any user (as “root” is specified) from account 1234567890123456 that provides the correct ARN would be allowed to assume this role and gain the permissions of the role. The victim Cloud ID is 6543210987654321 and the role ARN is acs:ram::6543210987654321:role/ecs-admin. Normally, attackers would be unable to access the victim’s cloud environment even if they knew the ARN as the AssumeRole request has to originate from account 1234567890123456 specifically.

An example policy from the Alibaba manual is as follows:

		{"Statement":[{"Action":"sts:AssumeRole","Effect":"Allow","Principal":{"RAM":["acs:ram::1234567890123456:root"]}}],"Version":"1"}

For the SaaS vendor to gain access they would have to call the following endpoint to AssumeRole:

		https://sts.aliyuncs.com?Action=AssumeRole&acs:ram::6543210987654321:role/ecs-admin&RoleSessionName=alice

This means that Alibaba Cloud depends on the following for security of cross account trust:

  • Hard-to-guess ARN string (e.g. acs:ram::6543210987654321:role/ecs-admin where 6543210987654321 is the SaaS Customer’s (Victim) Cloud Account ID)
  • Request has to originate for explicitly specified Cloud Account ID (e.g. 1234567890123456 where this is the SaaS vendor’s Cloud Account ID)

The Confused Deputy Problem

The protections above seem sufficient until we introduce the confused deputy problem which negates the second security requirement. The problem arises when the SaaS vendor’s agent with delegated authority cannot differentiate between a request from the legitimate SaaS Customer (Victim) and a request from a different, illegitimate SaaS Customer (Attacker).

Example Scenario

Let’s walk through an example confused deputy attack on a fictitious billing management service. We will be using the above sample policy and values for this example.

The victim first creates a role with the policy mentioned previously that allows the billing management service to AssumeRole. The victim follows the following guide provided by Alibaba Cloud (https://www.alibabacloud.com/help/doc-detail/93745.htm). The victim will then confirm the role ARN “acs:ram::6543210987654321:role/ecs-admin” with the billing management service. Finally, the billing management service will use the role ARN to access the victim’s cloud to perform legitimate tasks.

An attacker will register with the billing management service and provide the role ARN “acs:ram::6543210987654321:role/ecs-admin“ masquerading as the victim. The billing management service will connect to the victim’s cloud on behalf of the attacker. Since the role has already been created and the request is originating from the policy-specified SaaS vendor’s account ID, it is allowed to AssumeRole. The attacker can now control the victim’s cloud via the billing management service.

ARN attacker user role model

You can read more about it from an AWS perspective at the following link.

Who would be susceptible to the Confused Deputy problem?

The only protection Alibaba Cloud has is the role ARN which has 2 main parts to it.

  1. SaaS Customer’s (Victim) account ID
  2. Role name (ARN)

The account ID is rather long but it can be enumerated from multiple sources as it is not considered sensitive. For example, we demonstrated this with a simple Github search.

repository results

Additionally, the role name will usually be suggested by the SaaS vendor who provides templates for the SaaS Customer (Victim) to use and since companies usually stick with the default, this should be easily guessable. If the SaaS Customer does change the role name from the suggested default, it is still possible to brute-force the role name as it usually describes the function of the role. Overall, depending on the role ARN alone is a bad practice.

AWS provides external IDs which prevents the confused deputy problem when implemented correctly. If you are unfamiliar with AWS external IDs, it is an extra condition that has to be fulfilled to assumeRole. It is a randomly generated token which the SaaS Customer would have to provide to prove that it has ownership of the account in question. This article provides a good explanation of external IDs and problems when implementation is not done correctly.

Alibaba Cloud does not have external IDs built into its design. If the role ARN is exposed, Alibaba Cloud does not have any in-built solutions to defend against the confused deputy problem. Therefore, any SaaS vendor would be vulnerable to the confused deputy problem if they do not implement specific checks.

Solution

Praetorian has contacted Alibaba Cloud with the suggestion that they add external IDs. As of publication date, Alibaba has not announced any plans that to add an external IDs feature. Therefore, the responsibility lies on SaaS providers to ensure secure implementation. Presently, the only protection against such an attack would be for SaaS vendors to check customer cloud account IDs against a database of cloud account IDs that it has associated with.

If a new customer tries to provide a role ARN with a Cloud Account ID that was previously associated with another customer, the SaaS vendor should not process this request. This has its limitations as the same SaaS account would not be able to connect to the same account ID twice which is a use case in certain applications. For example, a service that provides instrumentation for K8s clusters may need to connect to multiple clusters that share the same account ID.

Conclusion

In this post we have discussed how Alibaba Cloud handles cross account trust via assumeRole. Praetorian would like to advise all SaaS providers to keep the confused deputy problem in mind when designing systems.

References

Cloud Security

in

Security Insights