Governance & Risk Management , Next-Generation Technologies & Secure Development , Patch Management

Kubernetes Alert: Security Flaw Could Enable Remote Hacking

A severe vulnerability in Kubernetes, the popular open-source software for managing Linux applications deployed within containers, could allow an attacker to remotely steal data or crash production applications.

See Also: SASE Architecture For Dummies

That warning, sounded by Kubernetes expert Darren Shepherd, marks one of the first serious problems to be seen with Kubernetes, which was first developed by Google and then turned into an open-source project in 2014 (see: Protecting Containers From Cyberattacks).

On Monday, Red Hat and Microsoft said they've been taking steps to address the vulnerability, CVE-2018-1002105, which they say poses a "critical" risk.

Microsoft says its Azure Kubernetes Service "has patched all affected clusters by overriding the default Kubernetes configuration to remove unauthenticated access to the entrypoints [Kubernetes commands] that exposed the vulnerability."

Red Hat says its Kubernetes-based services, including its OpenShift Container Platform, OpenShift Online and OpenShift Dedicated, are affected by the flaw. Red Hat, which was acquired by IBM in October for $34 billion, has issued patches.

In an explanation video, Red Hat says patches will be automatically installed if administrators have auto-updates enabled. Otherwise, administrators should immediately manually install patches.

"The privilege escalation flaw makes it possible for a malicious user to gain full administrator privileges on any computer node in a Kubernetes pod," according to the Red Hat video. "Not only can this user potentially steal sensitive data or inject malicious code, but the user can also bring down production applications and services from within an organization's firewall."

Exploits: Difficult To Detect

The vulnerability can be exploited by sending a specially crafted request to the Kubernetes API and then onto a backend server, writes Jordan Liggitt, a staff software engineer at Google, in a post on Github.

After sending such a request, an attacker could then send "arbitrary requests over the same connection directly to that backend, authenticated with the Kubernetes API server's TLS credentials used to establish the backend connection," he says.

"Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log."
— Jordan Liggitt, Google

Liggitt writes: "An API call to any aggregated API server endpoint can be escalated to perform any API request against that aggregated API server, as long as that aggregated API server is directly accessible from the Kubernetes API server's network." In the default configuration, any user - whether authenticated or not - can perform discovery API calls that allow for escalation, he says.

Unfortunately, there's no simple way to figure out whether the vulnerability has been exploited. "Because the unauthorized requests are made over an established connection, they do not appear in the Kubernetes API server audit logs or server log," he writes. "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."

Red Hat: This Is 'A Big Deal'

In a blog post, Ashesh Badani, Red Hat's general manager of cloud platforms, describes the vulnerability as being "a big deal."

The vulnerability affects 3.x version of Red Hat's OpenShift Container Platform, allowing for the compromise of "pods," or a single instance of an app running in a container that runs on normal user privileges on a node, according to Red Hat's advisory.

Exploiting the vulnerability could enable a remote attacker to access all secrets, pods, environment variables, running pod/container processes and persistent volumes, Red Hat warns.

On Openshift Container Platform 3.6 and higher, "this vulnerability allows cluster-admin level access to any API hosted by an aggregated API server," the advisory says. "This includes the 'metrics-service' and 'servicecatalog' as possible targets. Cluster-admin level access to the service catalog allows creation of brokered services by an unauthenticated user with escalated privileges in any namespace and on any node. This could allow an attacker to deploy malicious code or alter existing brokered services."