CVE-2020-8562: Kubernetes Auth Bypass Vulnerability

CVE-2020-8562 Overview

CVE-2020-8562 is a DNS rebinding vulnerability in Kubernetes that allows authenticated users to bypass network proxy restrictions and potentially access private networks on the control plane. This vulnerability exists due to a Time-of-Check Time-of-Use (TOCTOU) race condition in how Kubernetes validates DNS resolution responses.

As mitigations to a prior 2019 report and CVE-2020-8555, Kubernetes implements protections to prevent proxied connections from accessing link-local (169.254.0.0/16) or localhost (127.0.0.0/8) networks when making user-driven connections to Services, Pods, Nodes, or StorageClass service providers. However, the implementation performs DNS name resolution twice: once for validation and once for the actual connection. A non-standard DNS server returning different non-cached responses can enable attackers to bypass these restrictions.

Critical Impact

Authenticated users with certain privileges can bypass network proxy IP restrictions and access private networks on the Kubernetes control plane, potentially exposing sensitive internal services.

Affected Products

• Kubernetes versions prior to patched releases
• Kubernetes 1.21.0
• All Kubernetes deployments using proxied connections with non-standard DNS configurations

Discovery Timeline

• 2022-02-01 - CVE CVE-2020-8562 published to NVD
• 2024-11-21 - Last updated in NVD database

Technical Details for CVE-2020-8562

Vulnerability Analysis

This vulnerability is classified as CWE-367 (Time-of-Check Time-of-Use), a race condition vulnerability that occurs when Kubernetes performs two separate DNS resolution operations without proper synchronization. The root cause lies in the architectural decision to validate DNS responses separately from the actual connection establishment.

When a user initiates a proxied connection to Services, Pods, Nodes, or StorageClass service providers, Kubernetes first resolves the DNS name and validates that the resulting IP addresses are not within restricted ranges (link-local 169.254.0.0/16 or localhost 127.0.0.0/8). If the validation passes, Kubernetes then performs a second DNS resolution to establish the actual connection. This creates a window of opportunity for exploitation.

The attack requires network-level access and an authenticated user with low privileges. Additionally, the attacker must have control over or access to a malicious DNS server that can return different IP addresses for consecutive queries to the same hostname.

Root Cause

The fundamental issue is the TOCTOU race condition in the DNS validation logic. Kubernetes treats DNS resolution as a stateless operation but relies on the assumption that the same hostname will resolve to the same IP address between the validation check and the actual connection. This assumption breaks down when dealing with DNS servers that implement DNS rebinding or return non-cached, varying responses.

The validation step correctly blocks restricted IP ranges, but the second unvalidated DNS lookup for the actual connection can return a different IP address pointing to localhost or link-local addresses, effectively bypassing the security controls.

Attack Vector

The attack exploits the gap between DNS validation and connection establishment. An attacker with authenticated access to the Kubernetes API can craft requests that target a hostname controlled by a malicious DNS server. The attack proceeds as follows:

1. The attacker sets up or leverages a DNS server configured to return alternating IP addresses
2. On the first query (validation), the DNS server returns a legitimate, non-restricted IP
3. Kubernetes validates this IP and approves the connection request
4. On the second query (connection), the DNS server returns a restricted IP (e.g., 127.0.0.1 or 169.254.x.x)
5. Kubernetes establishes a connection to the restricted address, bypassing the intended security controls

This technique, commonly known as DNS rebinding, allows attackers to access internal services on the control plane that would otherwise be inaccessible through normal API interactions.

Detection Methods for CVE-2020-8562

Indicators of Compromise

• Unusual DNS query patterns showing the same hostname resolving to different IP addresses in rapid succession
• API server logs showing proxied connections to link-local or localhost addresses
• Unexpected network traffic originating from the API server to internal addresses (127.0.0.0/8 or 169.254.0.0/16)
• Audit logs indicating user-driven connections to Services, Pods, or Nodes with suspicious hostnames

Detection Strategies

• Monitor Kubernetes API server audit logs for unusual proxy connection patterns to internal services
• Implement DNS query logging and analyze for potential rebinding attacks targeting Kubernetes infrastructure
• Deploy network monitoring to detect unexpected connections from control plane components to localhost or link-local addresses
• Review authentication and authorization logs for privileged operations involving proxied connections

Monitoring Recommendations

• Enable comprehensive Kubernetes audit logging to capture all proxy-related API calls
• Configure DNS logging on cluster DNS servers to identify suspicious resolution patterns
• Implement network segmentation monitoring to detect lateral movement attempts within the control plane
• Establish baseline network behavior for control plane components and alert on deviations

How to Mitigate CVE-2020-8562

Immediate Actions Required

• Review the Kubernetes Security Announcement for specific patching guidance
• Audit cluster access to ensure only trusted users have permissions that allow proxied connections
• Review DNS infrastructure for non-standard configurations that could enable rebinding attacks
• Implement network policies to restrict control plane outbound connections

Patch Information

Organizations should consult the official Kubernetes GitHub Issue for detailed information on available patches and affected versions. The NetApp Security Advisory also provides guidance for environments using NetApp products with Kubernetes.

Apply patches according to your Kubernetes version:

• Upgrade to the latest patched version of your Kubernetes release branch
• Review release notes for security fixes related to proxy connection handling

Workarounds

• Implement network segmentation to isolate the Kubernetes control plane from sensitive internal networks
• Use network policies to block outbound connections from API servers to localhost and link-local ranges at the infrastructure level
• Deploy a trusted DNS resolver that does not support non-cached varying responses for the same hostname
• Restrict user permissions to minimize the number of users who can initiate proxied connections

# Example network policy to restrict control plane outbound connections
# Apply at infrastructure/firewall level
# Block API server connections to restricted IP ranges:
# - Block 127.0.0.0/8 (localhost)
# - Block 169.254.0.0/16 (link-local)
# Consult your network infrastructure documentation for specific implementation