Security researchers warned that Kubernetes clusters configured to use a certain container networking implementation (CNI) were vulnerable to Man-in-the-Middle (MitM) attacks.
In late-May 2020, the Kubernetes Product Security Committee warned that flaw didn’t affect Kubernetes itself but rather an IPv4-only cluster that was configured to use a specific type of networking implementation.
The team outlined how an attacker could misuse the bug in a GitHub post:
By sending “rogue” router advertisements, a malicious container can reconfigure the host to redirect part or all of the IPv6 traffic of the host to the attacker-controlled container. Even if there was no IPv6 traffic before, if the DNS returns A (IPv4) and AAAA (IPv6) records, many HTTP libraries will try to connect via IPv6 first then fallback to IPv4, giving an opportunity to the attacker to respond.
In doing so, a user with CAP_NET_RAW could create other containers on the affected cluster to intercept traffic from other containers and thereby potentially gain visibility into a target organization’s sensitive information.
The vulnerability affected kubelet v1.18.0-v1.18.3, kubelet v1.17.0-v1.17.6 and kubelet < v1.16.11, noted the Kubernetes Product Security Committee. All of those versions contained an affected “kubernetes-cni” package as a dependency.
The security issue also affected the containernetworking team’s CNI Plugins prior to version 0.8.6 (CVE-2020-10749), Calico and Calico Enterprise (CVE-2020-13597), Docker versions prior to 19.03.11 (CVE-2020-13401), Weave Net prior to version 2.6.3 and all Flannel versions.
Cilium, Juniper Contrail Networking, OpenShift SDN, OVN-Kubernetes and Tungsten Fabric were unaffected at the time of writing, Kubernetes’ Product Security Committee noted.
Per the GitHub post, organizations can determine whether they’re vulnerable to the security issue described above by reviewing the IPv6 routing table on nodes. Doing so could reveal an updated IPv6 route that leads to a host-side container network interface, which could indicate that a malicious container is capable of receiving IPv6 traffic. The alert also revealed that the issue could cause additional IPv6 addresses to appear after the host-side of a container network interface had received a rogue RA packet.
Cluster administrators can remove the threat of the vulnerability by upgrading their kubelet packages to the following versions: kubelet v1.19.0+ (master branch #91370), kubelet v1.18.4+ (#91387), kubelet v1.17.7+ (#91386) or kubelet v1.16.11+ (#91388). Those versions won’t become publicly available until June 17, 2020. In the meantime, cluster administrators may therefore choose to manually upgrade their CNI plugins by directly using the containernetworking/plugins v0.8.6 release.
It’s also possible for cluster administrators to mitigate the risks posed by the vulnerability discussed above. First, they should consider configuring the host default to reject router advertisements. They can do this by setting the sysctl “net.ipv6.conf.all.accept_ra” to 0. (Doing so could break legitimate traffic, however.) They should also implement TLS in combination with robust certificate verification as well as remove CAP_NET_RAW privileges from unnecessary users and/or workloads.
Last but not least, administrators should think about taking steps to harden their clusters in general against digital attackers. Kubernetes provides some security best practices that cluster administrators can use to achieve that end.
=======================
About the Author: David Bisson is an information security writer and security junkie. He’s a contributing editor to IBM’s Security Intelligence and Tripwire’s The State of Security Blog, and he’s a contributing writer for Bora. He also regularly produces written content for Zix and a number of other companies in the digital security space.
