Edera Advisory Highlights Remote Code Execution Flaw in Kubernetes
Edera, a provider of a platform for securing container runtime environments, this week published an advisory that notes there is a design flaw that could enable full remote code execution (RCE) in any container on a Kubernetes node.
Building on a flaw first disclosed by security researcher Graham Helton that showed how a service account with nothing more than nodes/proxy GET permission can achieve full remote code execution (RCE) in any container on a Kubernetes node, the Edera advisory notes that this capability is routinely invoked by a wide range of monitoring tools and network overlays.
Jed Salazar, field CTO for Edera, said that if those tools are compromised it would then be relatively trivial for cybercriminals to launch an RCE attack against a Kubernetes cluster.
This issue has not been assigned a rating in the Common Vulnerabilities and Exposures (CVE) database because technically it’s a design flaw rather than actual vulnerability. The nodes/proxy GET permission capability works as intended; it can just be used for both legitimate and malicious purposes.
However, nodes/proxy GET permission that is being exploited is scheduled to be removed with the arrival of version 1.36 of the Kubernetes platform expected in April. That said, it may be months, sometimes even years, before many organizations will update their existing Kubernetes clusters running in production environments to run that release, noted Salazar.
It’s not clear if there have been any actual incidents where this issue has been exploited, but once research has been published cybersecurity teams generally assume that cybercriminals have at the very least begun to experiment with how best to exploit it. As such, IT teams managing Kubernetes clusters would be well advised to regularly scan their Kubernetes environments for examples of RCE that might be the work of a malicious actor, noted Salazar.
It’s not clear how much organizations today are investing in securing container environments, but many IT teams are making assumptions about the level of security being provided. While it’s simple to rip and replace containers that have vulnerabilities, there are still often thousands of containers running in production environments that can be compromised using jailbreaking techniques that are now well understood by cybercriminals. As more container applications are deployed in production environments, the overall level of risk steadily increases.
The truth is containers are not more secure than legacy technologies so much as they are differently insecure. Many of the platforms being relied on to run modern container applications are so complex it’s too easy for them to be misconfigured. The only way to effectively address that challenge is to make sure more fine-grained authorization controls are applied to secure a cloud-native computing environment from the point the container is created to when it is deployed in a runtime environment, said Salazar.
The more isolation there is between the various components that make up a container application environment the more likely it is that if and when there is a breach it will be easier to contain, he adds.
The challenge, as always, is making sure IT teams are aware enough of the potential risk to put the right level of mitigations in place to reduce the scope of any potential threat.
