Patching a system or solution helps keep things safe and secure. But what if the vendor doesn’t release a patch for a known bug or vulnerability? This is the exact situation that has arisen with CVE-2020-8554, a security vulnerability in Kubernetes. The vulnerability was discovered a year ago and has not yet been patched. The Kubernetes platform is widely popular and has been evolving quickly, so it’s essential that vulnerabilities like this be closed off or at least mitigated in some fashion to prevent threat actors from disrupting your environment. But it also raises a larger question of what to do when a vendor of a product or solution you use fails to patch known vulnerabilities for whatever reason.
Kubernetes security: Be aware of this vulnerability
“In November,” says Gadi Naor, “the Kubernetes project disclosed a vulnerability that every Kubernetes administrator or adopter should be aware of.” Gadi is an expert on runtime security for Kubernetes-native applications and is also the CTO and co-founder of Alcide, a leading Kubernetes security solution provider. “The vulnerability, known as CVE-2020-8554,” he continues, “stems from default permissions allowing users to create objects that could act as a man-in-the-middle (MiTM) and therefore potentially intercept sensitive data. The vulnerability works by redirecting a victim’s legitimate network traffic through a secret attacker on the network, where the attacker can eavesdrop or actively tamper with the victim’s data before sending it to its intended destination.”
Is that something new with Kubernetes? I asked this next, and he replied: “Most of the previously discovered MiTM attacks took advantage of the default overly permissive way Kubernetes provisions workloads/pods — specifically CAP_NET_RAW permissions. Unlike those previous vulnerabilities, this vulnerability is related to the Kubernetes API design and behavior, and there is no software patch or a fix available. An attacker who has obtained permissions to create a Kubernetes Service of type LoadBalancer or ClusterIP might be able to intercept network traffic originating from other pods in the cluster. For example, Kubernetes clusters hosting multiple tenants would enable one tenant to intercept other tenant’s network traffic.”
I wondered if the reason this vulnerability hasn’t been patched yet could be due to the rapid pace of development of Kubernetes versions. Or if there may be other reasons involved for the delay of more than a year in getting this vulnerability patched. “There is no patch for this issue,” says Gadi, “and it can currently only be mitigated by placing an active policy enforcement that identifies and restricts users that are allowed to create Service but do try to exploit this design flaw. Since it’s a flaw in Kubernetes design, a fix would require a breaking change.”
Wow, that’s interesting. But to broaden the perspective a bit, I asked Gadi whether it’s difficult in general to secure Kubernetes-native applications and what’s involved in doing this. “There’s application security, which in the context of cloud-native applications and Kubernetes-native applications, means that we would normally have more moving parts, that translates into more components or microservices that we need to secure. Specifically, Kubernetes offers application builders an extremely powerful and flexible cloud-native infrastructure with excellent native security controls and excellent extensibility to complement any missing native piece.
Learning curve
“This means that there is a healthy learning curve that practitioners would need to go through, absorb, understand, and implement gradually across the system. The practice can be roughly broken into three domains. First, configuration and security posture related to continuous enforcement — it can provide great surface coverage in terms of reducing risk and potential threat vectors. Second, runtime workload protection, which revolves around network segmentation, process monitoring, threat detection, and prevention. And third, runtime Kubernetes infrastructure threat monitoring which captures users and entity behavior analysis using both compliance policies as well as machine learning to detect anomalies and incidents related to how Kubernetes infrastructure is utilized.”
I asked him where in the development and production cycle is it most difficult to secure Kubernetes deployments. “Traditionally, it is relatively harder to implement runtime security. Rolling out security runtime protection might be easy, but tuning policies, maintaining policies, and, in general, lifecycle management requires dedicated cycles and the ability to analyze events surfaced from the security monitoring systems. All of which requires the option to integrate into monitoring and security systems as well as having security response personnel.”
A possible solution
Focusing on a solution, I asked him how real-time scanning and machine learning can protect Kubernetes applications from unpatched vulnerabilities such as CVE-2020-8554. “CVE-2020-8554 falls into that security vulnerability class that can be detected by a relatively simple configuration analysis, whereas prevention can be implemented by a Kubernetes-specific mechanism extensibility mechanism called Admission Controllers that enable Kubernetes operators a plug-in enforcement point that can be used to define and enforce a fine-grained policy that looks specifically for this misconfiguration.”
As a final word, he added, “Historically, we have seen Kubernetes vulnerabilities that do fall into the class of exploits that runtime monitoring would be the only way for real-time detection. In some cases, AI-driven detection was the only way to intercept exploit attempts. In other cases, runtime network segmentation would be the best mitigation strategy.” I encourage readers who deploy Kubernetes apps to take a look at what Alcide can provide in the area of Kubernetes security.
Featured image: Shutterstock
