A serious vulnerability in the Kubernetes that could enable an attacker to gain full administrator privileges over the open source container system's compute nodes, was confirmed this week.

The bug, CVE-2018-1002105, is a privilege escalation flaw in the Kubernete's platform and was spotted by Darren Shephard, founder of Rancher Labs.

It has since been patched by Red Hat, one firm that makes use of Kubernetes.

Unpatched, the flaw effectively allowed hackers to gain full administrator privileges on Kubernetes compute nodes, the physical and virtual machines on which Kubernetes containers run upon.

Once those privileges had been gained, hackers could then steal data, input corrupt code or even delete applications and workloads.

The flaw could be exploited in two ways: one through a 'normal' user gaining elevated priveledges over a Kubernetes pod, which is a group of one or more containers that share network and storage resources and run in a shared context, and from there they could wreak havoc.

The second involves the exploitation of API extensions that connect a Kubernetes application server to a backend server. While a hacker will need to create a tailoured network request to harness the vulnerability in this context, once done they could send requests over the network conection to the backend.

From there, the attacker has 'cluster-level' admin privileges - clusters are a collection of nodes - and therefore escalated privileges on any node. This would, in turn, allow said attacker to alter existing brokered services to deploy malicious code.

Due to the connection on Kubernetes API servers, where its authenticated with security credentials, malicious connections and unauthenticated users with admin privileges appear above board. This makes the flaw and its exploitation difficult to identify as would-be hackers appear as authorised users.

According to GitHub, this makes the vulnerability a critical flaw, mostly due to the fact it allows anyone with access to cause damages, but also because of its invisibility as abusing the flaw leaves no traces within system logs.

"There is no simple way to detect whether this vulnerability has been used. Because the unauthorised requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log. The requests do appear in the kubelet or aggregated API server logs, but are indistinguishable from correctly authorized and proxied requests via the Kubernetes API server."

There are fixes and remedies to this flaw, but it's mostly about upgrading the version of Kubernetes you run. Now. There are patched versions of Kubernetes, such as v1.10.11, v1.11.5, v1.12.3, and v1.13.0-rc.1 and it is recommended that you stop using Kubernetes v1.0.x-1.9.x.

For those that cannot move up, there are cures; you must suspend use of aggregated API servers and remove pod permissions from users that should not have full access to the kubelet API.

“Kubernetes, like all software, is not immune to security issues - the privilege escalation flaw makes it possible for any user to gain full administrator privileges on any compute node being run in a Kubernetes cluster.This is a big deal. Not only can this actor steal sensitive data or inject malicious code, but they can also bring down production applications and services from within an organisation’s firewall,” said Ashesh Badani, general manager of Red Hat‘s cloud platform business unit.

“It’s important to note that all Kubernetes-based services and products - including Red Hat OpenShift Container Platform, Red Hat OpenShift Online, and Red Hat OpenShift Dedicated - are affected. Red Hat has begun delivering patches and pushed service updates to affected users, enabling them to address this flaw either immediately or when it best fits their specific risk profile. A more detailed account of the Kubernetes privilege escalation flaw can be found here.”

Badani concluded: “As Kubernetes becomes more prominent for enterprises as they pursue digital transformation, it stands to reason that more flaws within the technology will be discovered. The community will be ready to fix the code, while Red Hat will be prepared to help you fix your critical systems in a way that can make the most sense for your unique organisational needs.”