Kubernetes: Multiple issues in aws-iam-authenticator Kubernetes AWS IAM integration (https://github.com/kubernetes-sigs/aws-iam-authenticator/) is implemented on top of the sts:GetCallerIdentity AWS API (https://docs.aws.amazon.com/STS/latest/APIReference/API_GetCallerIdentity.html). A client authenticates by pre-signing a request to the API endpoint and forwarding it to the server as an Auth token. The server decodes the token and forwards the request to the AWS STS server. The server side part of this code is implemented in the Verify method in pkg/token/token.go (https://github.com/kubernetes-sigs/aws-iam-authenticator/blob/master/pkg/token/token.go). Looking at this method there are a couple of issues: 1. Host regexp is too lax: The server needs to ensure that the presigned URL received from the client actually points to a real STS server. Otherwise, the auth mechanism is easy to bypass by pointing the request at an attacker controlled server. aws-iam-authenticator uses `^sts(\\.[a-z1-9\\-]+)?\\.amazonaws\\.com(\\.cn)?$` to enforce that the URL host component points to an STS server. However, this regex is not strict enough and allows requests to a wide range of AWS services. The most interesting one is probably S3, where URLs like sts.s3.amazonaws.com, sts.s3-us-gov-west-1.amazonaws.com or sts.s3-control.cn-north-1.amazonaws.com.cn point at S3 buckets named STS that can be owned by an arbitrary AWS customer. Luckily I was not able to find a simple way to exploit this as S3 does not allow you to host user controlled content on the \"/\" path. If that changes, you can somehow trick the AWS query parser or an additional AWS service with a similar domain scheme launches, this could become exploitable. FWIW I'm also slightly concerned about the complete lack of region isolation here. It seems unexpected to me that the owner of a random amazonaws.com.cn subdomain can login into arbitrary EKS clusters. 2. HTTP client follows redirects: The code uses the standard Golang HTTP client in its default configuration which follows HTTP redirects. This might make 1. easier to exploit if an attacker can find an open redirect issue on a host that matches the hostname regex. 3. URL.Query vs ParseQuery: The function enforces an allowlist of valid query values by iterating through the parameter map returned by URL.Query(). However, Query() silently drops parameters that Go considers invalid. This could become a problem if the AWS URL parser and Go disagree. The ParseQuery() method additionally returns an error if it encounters invalid parameters and should probably be used instead. 4. Request smuggling for Go version < 1.12: Older versions of Golang are vulnerable to request smuggling issues when requesting malformed URLs containing spaces and newlines (https://github.com/golang/go/issues/22907). As Go reuses TCP connections for the default HTTP client, this can be used to bypass most of the request filtering implemented in token.go and potentially to leak parallel request from other clients. Current official releases of aws-iam-authenticator are not built with a vulnerable Go version, but it might be useful to verify if this is a problem for older clusters. (https://amazon-eks.s3.us-west-2.amazonaws.com/ lists a couple of binaries that are affected by this, but I'm not sure if they would still be used somewhere) Credits: Felix Wilhelm of Google Project Zero This bug is subject to a 90 day disclosure deadline. After 90 days elapse, the bug report will become visible to the public. The scheduled disclosure date is 2020-10-13. Disclosure at an earlier date is also possible if agreed upon by all parties Found by: fwilhelm@google.com