Exposed Container Orchestration Systems Putting Many Orgs at Risk

More than 22,600 open container orchestration and API management systems discovered on the Internet.

New research confirms that many organizations are deploying workloads to the public cloud without adequate security controls and processes in place first.
Lacework recently used the Shodan search engine, SSL data mining techniques, and some internally developed tools to uncover as many as 22,672 open container orchestration dashboards and API management systems on the Internet. The applications that Lacework discovered during its research were Kubernetes, Mesos Marathon, Swagger API, Red Hat Openshift and Docker Swarms Portainer and Swarmpit.
Some 95% of the exposed dashboards and management systems were hosted inside of Amazon Web Services. More than half of those exposed services were hosted on AWS regions in the US. Though a vast majority of the open container orchestration interfaces had credentials for controlling access, the fact that they were exposed to the Internet at all is troublesome, says Dan Hubbard, chief security at Lacework.
The dashboard provides top-level access to all the functions required to manage and administer container clusters. Anyone with access to the dashboard can carry out tasks like starting and stopping workloads, adding or modifying applications and setting key security controls.
Container management interfaces that are not properly configured and are exposed on the Internet pose a major risk for enterprises. Even with credentials set up, information related to the organization might be disclosed, Hubbard points out. This includes information contained in host headers or SSL certificates. Lacework researchers, for instance, were relatively easily able to derive company names from certificates and hostnames without even having to access the exposed container interfaces.
Weak authentication schemes - like inadequate credential requirements - can allow an attacker to brute-force the password of an exposed container management interface. Similarly, not using SSL can allow an attacker to gain access via clear text authentication. Any vulnerabilities in the container application itself are also likely to be easier to exploit via exposed management dashboards.
Laceworks
research
also uncovered some 300 container management dashboards with no authentication at all, giving attackers a way to easily spin up and stop containers, delete or destroy information, and harvest data about the infrastructure, Hubbard says. Such completely open dashboards also give attackers a way to potentially move laterally to other cloud resources, log into cloud instances and launch new instances for abuse like Bitcoin mining and DDoS. In addition, attackers can exploit the dashboards to set up a backdoor or to drop malicious code for performing command-and-control and other activities.
Because Kubernetes is currently one of the most popular and fastest-growing container orchestration and management systems, Lacework researchers decided to drill down into some of the issues related to the use of these dashboards in public clouds. Although Kubernetes comes with security features like default SSL use and default authentication, Lacework researchers discovered many open Kubernetes dashboards that were still in the process of being set up; dashboards with no authentication; dashboards that could be brute-forced and those that were leaking information about the organization.
Researchers also discovered 38 servers running a container health check service called healthz for Kubernetes environments, live on the Internet with no authentication at all. Besides potentially giving attackers a way to potentially perform full remote code execution capabilities, the app also provides a way to monitor workloads and stop them from running via the dashboard.
The data highlights the need for organizations to follow fundamental security best practices when deploying containers in the public cloud. Examples include protecting them behind a proxy, using multifactor authentication and role-based models to control access, and enforcing the use of SSL, Hubbard says. Limiting the scope of what you can do via a management interface is also a good idea. For example, it is not a great idea to have one management hub for all workloads because if one pod is compromised, all workloads get put at risk, he says.
The general theme of our discoveries is that there needs to be a bridge in communication, process, and technology between DevOps and security, Hubbard notes. The operating model here is very different and that needs to be acknowledged.
Related Contents:
Security vs. Speed: The Risk of Rushing to the Cloud
Cloud Security: New Research Says IT Pros Still Skittish
Trust, Cloud & the Quest for a Glass Wall around Security
Containerized Apps: An 8-Point Security Checklist

Top industry experts will offer a range of information and insight on who the bad guys are – and why they might be targeting your enterprise. Click for
more information

Last News
▸ 7 arrested, 3 more charged in StubHub cyber fraud ring. ◂ Discovered: 23/12/2024 Category: security	▸ Nigerian scammers now turning into mediocre malware pushers. ◂ Discovered: 23/12/2024 Category: security	▸ Beware EMV may not fully protect against skilled thieves. ◂ Discovered: 23/12/2024 Category: security

**Cyber Security Categories**
Google Dorks Database	Exploits Vulnerability	Exploit Shellcodes

CVE List

Tools/Apps

News/Aarticles

Phishing Database

Deepfake Detection

Trends/Statistics & Live Infos

Tags:
Exposed Container Orchestration Systems Putting Many Orgs at Risk