Cybersecurity

Critical Vulnerability Allows Easy Access Kubernetes Containers

Kubernetes has picked up a great deal of steam over the past couple of years, easily becoming one of, if not the most popular cloud container organization system. And, as security-minded folks have seen time and again, when a software solution gains ground in the marketplace its vulnerabilities start to bubble to the surface. While minor bugs are to be expected, this new Kubernetes exploit is anything but, scoring a whopping 9.8 on the Common Vulnerability Scoring System (CVSS). What’s more, the only way to address the problem is to upgrade, now.

rendering of cloud-based netowrk

jijomathaidesigners / Shutterstock.com

The source of the problem is familiar, stemming from how users connect to containers through an application programming interface (API). APIs are in place to control a user’s access to the backend, but according to ZDNet, in this instance, Kubernetes is recognizing “a specially crafted network request” by an unauthorized user as valid. Once they get access, the attacker can then “send arbitrary requests over the network connection” to the backend server which are then “authenticated with the Kubernetes API server’s Transport Layer Security (TLS) credentials.

What this boils down to is Kubernetes API is giving a threat actor root access to the container’s backend servers.

To make this more dangerous, the vulnerability allows all authenticated and unauthenticated users to perform API calls on systems in default configurations to further escalate privileges. Essentially, if someone squeezes through the security gap, they can gain access to your entire Kubernetes cluster. Even worse, there’s no way for you to tell if someone has gained unauthorized access, as the traffic is indistinguishable from all other authorized access in the server logs. Yikes.

As mentioned earlier, the only way to fix the problem is to immediately stop using Kubernetes v1.0.x – v1.9.x and upgrade to a patched version (v1.10.11, v1.11.5, v1.12.3, or v1.13.0-rc.1). While the upgrade is guaranteed to be disruptive, there’s really no other option. As with any critical vulnerability, it’s better to be safe than sorry.