CVE-2021-25320: Privilege Escalation via Improper Access Control in Rancher Proxy

CVE-2021-25320 is a critical improper access control vulnerability (CWE-284) affecting the Rancher container management platform. The flaw resides specifically within the /meta/proxy endpoint, a utility designed to proxy API requests to external cloud providers (such as AWS, Azure, or Google Cloud) to perform infrastructure operations. This endpoint is intended to simplify cloud resource management by attaching stored credentials to outgoing requests automatically.

The vulnerability stems from a failure to enforce authorization boundaries in two distinct ways. First, the application failed to verify that the user initiating the proxy request had permission to utilize the specified cloud credentials. Second, the proxy mechanism transparently forwarded sensitive headers, specifically Impersonate-User and Impersonate-Group, without sanitization. This allowed low-privileged users to manipulate the identity context of the request, effectively escalating their privileges to that of an administrator or other high-value accounts.

The root cause of this vulnerability lies in the implementation of the request forwarding logic within the Rancher API. When a user sends a request to /meta/proxy, they typically include a cloudCredentialId parameter. The system is designed to look up the corresponding secret, attach it to the request (e.g., as an Authorization header or signed query parameter), and forward the request to the cloud provider.

1. Missing Object-Level Authorization: The code correctly authenticated the user against the Rancher API but failed to perform an object-level permission check on the cloudCredentialId. The system retrieved the credential object based on the ID provided in the request but did not verify if the creatorId or RBAC bindings of the requesting user authorized them to use that specific credential. This meant any valid user could piggyback on the administrative cloud credentials stored in the system simply by knowing or guessing their ID.

2. Unsafe Header Forwarding: Rancher utilizes Impersonate-User headers for internal communication, allowing services to perform actions on behalf of users. The proxy implementation utilized a "pass-through" approach where headers from the incoming client request were copied to the outgoing proxy request. Because Impersonate-User and Impersonate-Group headers were not explicitly denylisted or stripped, an attacker could manually inject these headers. If the downstream service or a loopback request trusted these headers, the action would be performed under the identity of the target user rather than the actual requester.

The remediation for CVE-2021-25320 involved distinct changes to the request handling pipeline in the Rancher source code. The fixes were applied in the meta package where the proxy logic resides.

Before the Fix: The logic flowed linearly: receive request, extract cloudCredentialId, retrieve credential, sign request, and forward. There was no step to validate the relationship between User and Credential.

The Fix Implementation: The patch introduced a mandatory permission check and a header sanitization step. The logic flow was altered as follows:

// Pseudo-code representation of the fix logic
func (h *Handler) Proxy(rw http.ResponseWriter, req *http.Request) {
    // 1. Validate the user has 'use' permissions on the specific credential
    credID := req.URL.Query().Get("cloudCredentialId")
    credential, err := h.credentialStore.Get(credID)
    
    // NEW: Access Control Check
    if !h.accessControl.CanUse(req.Context(), credential) {
        http.Error(rw, "Forbidden", http.StatusForbidden)
        return
    }
 
    // 2. Prepare the outgoing request
    outReq := new(http.Request)
    *outReq = *req
    
    // NEW: Header Sanitization
    // Explicitly remove impersonation headers to prevent privilege escalation
    outReq.Header.Del("Impersonate-User")
    outReq.Header.Del("Impersonate-Group")
    
    // 3. Attach credentials and forward
    attachCredentials(outReq, credential)
    h.reverseProxy.ServeHTTP(rw, outReq)
}

This change ensures that even if an attacker knows a valid cloudCredentialId, the request is blocked immediately if they lack the RBAC permission to use it. Furthermore, the removal of impersonation headers neutralizes the identity spoofing vector.

Exploiting this vulnerability requires a valid, low-privileged account within the Rancher cluster. The attack does not require direct access to the cloud provider's console, only network access to the Rancher API.

1. Credential Enumeration: The attacker first needs a valid cloudCredentialId. In many Rancher setups, credential IDs may be predictable or leaked via other metadata endpoints accessible to authenticated users (e.g., cr-xxxxx).

2. Request Crafting: The attacker constructs an HTTP request to the proxy endpoint. A typical exploit request would look like this:

GET /meta/proxy/https://ec2.us-west-2.amazonaws.com/?Action=DescribeInstances HTTP/1.1
Host: rancher-target.local
Cookie: R_SESS=...
Impersonate-User: admin

In the URL, the attacker appends the cloudCredentialId parameter pointing to an administrative credential set (e.g., ?cloudCredentialId=cc-admin).

3. Execution: Rancher receives the request. Due to the vulnerability, it ignores that the current session belongs to a low-privileged user. It accepts the Impersonate-User: admin header and attaches the AWS keys associated with cc-admin. The request is forwarded to AWS. AWS executes the action (e.g., listing instances, terminating VMs) assuming the request is legitimate. The response is then piped back to the attacker.

The impact of CVE-2021-25320 is rated as Critical (CVSS 9.9) due to the complete bypass of access controls and the potential for lateral movement from the management plane to the cloud infrastructure.

Confidentiality: Attackers can use stolen credentials to read sensitive data from cloud providers, such as S3 buckets, database connection strings, or secret keys managed by the cloud environment.

Integrity: With write access to the cloud API, attackers can modify infrastructure. This includes modifying security groups to allow external access, deploying malicious compute instances (cryptominers), or tampering with existing workloads.

Availability: The most immediate threat is the destruction of resources. An attacker could issue TerminateInstances or DeleteVolume calls, causing catastrophic data loss and service outages for applications running on the managed clusters.

The vulnerability is patched in Rancher versions 2.4.16 and 2.5.9. Administrators must upgrade immediately. There are no viable configuration workarounds that do not involve restricting access to the Rancher API itself, which may break functionality.

Upgrade Paths:

• If using Rancher 2.4.x, upgrade to 2.4.16 or later.
• If using Rancher 2.5.x, upgrade to 2.5.9 or later.

Post-Incident Activity: After patching, security teams should rotate all cloud credentials stored within Rancher. Since the vulnerability allowed the use of credentials without logging the true unauthorized context effectively, it is prudent to assume credentials may have been exposed or misused. Review cloud provider logs (e.g., AWS CloudTrail) for anomalous API calls originating from the Rancher IP address during the window of exposure.