what you don't know can hurt you

Kubernetes AWS IAM Integration Issues

Kubernetes AWS IAM Integration Issues
Posted Oct 13, 2020
Authored by Google Security Research, Felix Wilhelm

Kubernetes has multiple issues in aws-iam-authenticator where lax controls can lead to a lower security posture.

tags | advisory
MD5 | 0efac33980805dcdab8d64773d7981d5

Kubernetes AWS IAM Integration Issues

Change Mirror Download
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

Login or Register to add favorites

File Archive:

November 2020

  • Su
  • Mo
  • Tu
  • We
  • Th
  • Fr
  • Sa
  • 1
    Nov 1st
    2 Files
  • 2
    Nov 2nd
    9 Files
  • 3
    Nov 3rd
    15 Files
  • 4
    Nov 4th
    90 Files
  • 5
    Nov 5th
    22 Files
  • 6
    Nov 6th
    16 Files
  • 7
    Nov 7th
    1 Files
  • 8
    Nov 8th
    1 Files
  • 9
    Nov 9th
    40 Files
  • 10
    Nov 10th
    27 Files
  • 11
    Nov 11th
    28 Files
  • 12
    Nov 12th
    13 Files
  • 13
    Nov 13th
    18 Files
  • 14
    Nov 14th
    2 Files
  • 15
    Nov 15th
    2 Files
  • 16
    Nov 16th
    29 Files
  • 17
    Nov 17th
    15 Files
  • 18
    Nov 18th
    15 Files
  • 19
    Nov 19th
    21 Files
  • 20
    Nov 20th
    16 Files
  • 21
    Nov 21st
    1 Files
  • 22
    Nov 22nd
    0 Files
  • 23
    Nov 23rd
    19 Files
  • 24
    Nov 24th
    32 Files
  • 25
    Nov 25th
    9 Files
  • 26
    Nov 26th
    11 Files
  • 27
    Nov 27th
    15 Files
  • 28
    Nov 28th
    9 Files
  • 29
    Nov 29th
    0 Files
  • 30
    Nov 30th
    0 Files

Top Authors In Last 30 Days

File Tags

Systems

packet storm

© 2020 Packet Storm. All rights reserved.

Services
Security Services
Hosting By
Rokasec
close