Over 900,000 Kubernetes Instances Found Exposed Online
Over 900,000 misconfigured Kubernetes clusters were found exposed on the Internet to potentially malicious scans, some even vulnerable to data-exposing cyberattacks.
Kubernetes is a highly versatile open-source container orchestration system for hosting online services and managing containerized workloads via a uniform API interface.
It enjoys massive adoption and growth rates thanks to its scalability, flexibility in multi-cloud environments, portability, cost, app development, and system deployment time reductions.
However, if Kubernetes isn’t configured properly, remote actors might be able to access internal resources and private assets that weren’t meant to be made public.
Also Read: Document Shredding Services for Commercial Document Destruction
Additionally, depending on the configuration, intruders could sometimes escalate their privileges from containers to break isolation and pivot to host processes, granting them intial access to internal corporate networks for futher attacks.
Finding exposed Kubernetes
Researchers at Cyble have conducted an exercise to locate exposed Kubernetes instances across the internet, using similar scanning tools and search queries to those employed by malicious actors.
The results show a massive 900,000 Kubernetes servers, with 65% of them (585,000) being located in the United States, 14% in China, 9% in Germany, while Netherlands and Ireland accounted for 6% each.
Of the exposed servers, the top most exposed TCP ports were “443”, with just over a million instances, “10250” counting 231, 200, and “6443” with 84,400 results.
It is essential to underline that not all of these exposed clusters are exploitable, and even among those that are, the level of risk varies depending on the individual configuration.
Cases of high risk
To evaluate how many of the exposed instances might be at significant risk, Cyble looked into the error codes returned to the unauthenticated requests to the Kubelet API.
The vast majority of the exposed instances return error code 403, meaning the unauthenticated request is forbidden and can’t go through, so no attacks can transpire against them.
Then there’s a subset of approximately five thousand instances that answer with error code 401, denoting that the request is unauthorized.
Also Read: 4 Steps to Data Protection Certification For Your Business
However, this response gives a potential attacker a tip that the cluster is functioning, and they could try out additional attacks based on exploits and vulnerabilities.
Finally, there’s a small subset of 799 Kubernetes instances that return a status code 200, which are completely exposed to external attackers.
In these cases, threat actors can access the nodes on the Kubernetes Dashboard without a password, access all secrets, perform actions, etc.
While the number of vulnerable Kubernetes servers are fairly low, all you need is a remotely exploitable vulnerability to be discovered for a far larger number of devices to become vulnerable to attacks.
To ensure that your cluster is not among those 799, or even the less severely exposed set of 5,000 instances, consult NSA and CISA’s guidance on hardening your Kubernetes system’s security.
Getting a clear picture
Last month, The Shadowserver Foundation released a report on exposed Kubernetes instances where they discovered 381,645 unique IPs responding with a 200 HTTP error code.
Cyble told BleepingComputer that the reason for this large discrepancy is that they used open-source scanners and simple queries that would be available to any threat actor, whereas Shadowserver scanned the entire IPv4 space and monitored for new additions daily.
“The stats provided in the Kubernetes blog that is published from our end is on the basis of Open-source scanners and the Queries available for the product. As mentioned in the blog we have searched on the basis of queries “Kubernetes”, “Kubernetes-master”, “KubernetesDashboard”,” K8”, and favicon hashes along with status codes 200,403 & 401,” explained Cyble.
“The Shadowserver takes a different approach for finding the exposure as per their blog on Kubernetes ‘We scan daily with a HTTP GET request using the /version URI. We scan all of the IPv4 space on ports 6443 and 443. We include only Kubernetes servers that respond with a 200 OK (with accompanying JSON response), and hence disclose version information in their response.’”
“As we are not scanning complete IPv4 space like the shadow server and relying on intel that is in the open-source, the results we are getting are different from Shadowserver.”
Whereas Cyble’s figures may not be as impressive, they are very important from the perspective that those numbers correspond to Kubernetes clusters that are very easy to locate and attack.