380K Kubernetes API Servers Exposed to Public Internet

More than 380,000 Kubernetes API servers allow some kind of access to the public internet, making the popular open-source container-orchestration engine for managing cloud deployments an easy target and broad attack surface for threat actors, researchers have found.

The Shadowserver Foundation discovered the access when it scanned the internet for Kubernetes API servers, of which there are more than 450,000, according to a blog post published this week.

“ShadowServer is conducting daily scans of the IPv4 space on ports 443 and 6443, looking for IP addresses that respond with an ‘HTTP 200 OK status,’ which indicates that the request has succeeded,” according to the post.

Of the more than 450,000 Kubernetes API instances identified by Shadowserver, 381,645 responded with “200 OK,” researchers said. In all, Shadowserver found 454,729 Kubernetes API servers. The “open” API instances thus constitute nearly 84 percent of all instances that that Shadowserver scanned.

Moreover, most of the accessible Kubernetes servers—201,348, or nearly 53 percent–were found in the United States, according to the post.

While this response to the scan does not mean these servers are fully open or vulnerable to attacks, it does create a scenario in which the servers have an “unnecessarily exposed attack surface,” according to the post.

“This level of access was likely not intended,” researchers observed. The exposure also allows for information leakage on version and builds, they added.

Cloud Under Attack

The findings are troubling given that attackers already increasingly have been targeting Kubernetes cloud clusters as well as using them to launch other attacks against cloud services. Indeed, the cloud historically has suffered from rampant misconfiguration that continues to plague deployments, with Kubernetes being no exception.

In fact, Erfan Shadabi, cybersecurity expert with data-security firm comforte AG, said in an email to Threatpost that he was not surprised that the Shadowserver scan turned up so many Kubernetes servers exposed to the public internet.

“White [Kubernetes] provides massive benefits to enterprises for agile app delivery, there are a few characteristics that make it an ideal attack target for exploitation,” he said. “For instance, as a result of having many containers, Kubernetes has a large attack surface that could be exploited if not pre-emptively secured.”

Open-Source Security Exposed

The findings also raise the perennial issue of how to build security into open-source systems that become ubiquitous as part of modern internet and cloud-based infrastructure, making an attack on them an attack on the myriad systems to which they are connected.

This issue was highlighted all-too-unfortunately in the case of the Log4Shell vulnerability in the ubiquitous Java logging library Apache Log4j that was discovered last December.

The flaw, which is easily exploitable and can allow unauthenticated remote code execution (RCE) and complete server takeover–continues to be targeted by attackers. In fact,  a recent report finding millions of Java applications still vulnerable despite a patch being available for Log4Shell.

An Achilles heel in particular of Kubernetes is that the data-security capabilities built into the platform are only at a “bare minimum”–protecting data at rest and data in motion, Shadabi said. In a cloud environment, this is a dangerous prospect.

“There’s no persistent protection of data itself, for example using industry accepted techniques like field-level tokenization,” he observed. “So if an ecosystem is compromised, it’s only a matter of time before the sensitive data being processed by it succumbs to a more insidious attack.”

Shadabi’s advice to organizations that use containers and Kubernetes in their production environments is to take securing Kubernetes as seriously as they do all aspects of their IT infrastructure, he said.

For its part, Shadowserver recommended that if administrators find that a Kubernetes instance in their environment is accessible to the internet, they should consider implementing authorization for access or block at the firewall level to reduce the exposed attack surface.