As Kubernetes grows in popularity, it has attracted the attention of more security researchers, who probe the software looking for weaknesses. And like any software, there are certainly plenty of bugs to be found, some of which an attacker can use to penetrate and even take control of a cluster. In a recent a webinar from the Cloud Native Computing Foundation, Gadi Naor founder of the Kubernetes security provider Alcide, summarized five recent Kubernetes vulnerabilities — including one that took over six months for the CNCF to alert K8s users about.

The Common Vulnerabilities and Exposure (CVE) database that identifies and rates recently disclosed software vulnerabilities. They provide useful information to end users, who should have a good idea of what the “the risk is, or blast radius, associated with each and every vulnerability, or weakness,” in their environment Naor said.

Two of the recent vulnerabilities involve the Kubernetes control plane:

• CVE-2020-8555 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8555): The Kubernetes kube-controller-manager can be attacked by way of a Server Side Request Forgery (SSRF).The Kubernetes kube-controller-manager implements cloud-specific calls to services such as load balancing, storage and so on. The attack fools the control manager with an HTTP redirect to a resource of the attackers choice, providing, for instance, the ability to extract info from the metadata API server or elements.
• CVE-2020-8559 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8559): This vulnerability provides a way to escalate privileges from a node to an entire cluster, by way of an unvalidated redirect sent to the kube-apiserver, which would allow an attacker to escalate privileges from a node compromise to a full cluster.

The other three involve vulnerabilities reside in the node layer:

• CVE-2020-8557 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8557): This vulnerability, which can be done within a pod can take down the entire node through a Denial of Service (DOS) attack. Cause: The Kubernetes kubelet does not account for disk usage by a pod that writes to its own /etc/hosts file, allowing that pod to fill the disk with data.
• CVE-2020-8558 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-8558): This is a “man-in-the-middle” (MitM) attack can be used in all versions of containernetworking/plugins up until version 0.8.6. A malicious container can send rogue IPv6 router advertisements to the host or other containers, redirecting traffic to the malicious container. This vulnerability bypasses the local host trust boundary. “Essentially, an attacker can send traffic from a neighboring pod, or even from the host itself to the localhost address, 127.0.0.1,” Naor said.
• CVE-2020-10749 (https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2020-10749): Another MitM attack that uses the IPv6 router advertisements to fool the forwarding agent, such as Calico or the Container Networking Interface (CNI), into sending raw traffic into the host. Even if you don’t use IPv6, attackers can the working stack is already in Linux. In effect, they can hijack traffic heading to nearby pods by manipulating the underlying the forwarding plane.

Now that more vulnerabilities are being introduced, the Kubernetes Product Security Committee is scrambling to keep up. Microsoft filed the bug report for CVE-2020-8555 in December, Naor reported, but it was not until June that the K8s users were informed about it. Usually, the security committee will ask for time before a bug is made public in order to fix it before attackers find out about it. In this case, the embargo time was extended due to interruptions from the COVID pandemic. As a result, K8s systems “were running vulnerable for many many many months,” Naor said.

#kubernetes #security #news