Over 20,000 Container Management Dashboards Are Exposed on the Internet
Even though it’s highly discouraged to expose any kind of management dashboard directly to the internet, there are many users who continue to ignore this recommendation, and it seems that infrastructure admins are no exception.
A recent study by cloud security firm Lacework found over 22,000 publicly exposed container orchestration and API management systems, about 300 of which could be accessed without any credentials and gave attackers full control or remote code execution capability on containers.
Kubernetes dashboards accounted for over 75 percent of the exposed interfaces, followed by Docker Swarm (Portainer and Swarmpit) with 20 percent, Swagger API UI with 3 percent and Mesos Marathon and Red Hat OpenShift with under 1 percent each.
The vast majority, over 95 percent, of the exposed systems were hosted on Amazon AWS and 55 percent were in a U.S.-based AWS region.
“During the research, we noticed an alarming number of systems with no authentication whatsoever,” the Lacework researchers said in their report. “Some were clearly in the midst of being set up, but some were in full production. In cases where full access was available, one can perform operations like add and deploy their own applications, delete infrastructure, change credentials, and potentially exfiltrate data.”
This can happen even to large companies with big IT budgets. Earlier this year, researchers from RedLock found hundreds of openly accessible Kubernetes administration consoles, some belonging to Aviva, a British multinational insurance company; Gemalto, the world’s largest SIM card manufacturer and car maker Tesla. Many of them had been abused to run cryptocurrency mining software inside those companies’ cloud computing instances.
Although the vast majority of the 22,000 management interfaces found by Lacework did require authentication, their direct exposure to the internet is unnecessary and makes them a target for a variety of attacks, including credential stuffing—the use of credentials leaked in other breaches — and more general dictionary-based password guessing attempts.
“Additionally, just by being open, you are potentially disclosing information that can give attackers sensitive information on their targets,” the Lacework researchers said. “Within most discovered systems, the company name could be derived from certificates and hostnames even without access.”
Intentionally keeping a container administrative dashboard exposed means that you also need to commit to keeping track of all vulnerabilities or bugs that might affect that software stack and deploy patches for them as soon as they become available.
While it used to take attackers weeks to start exploiting newly announced vulnerabilities in the past, now they start doing it in days or even hours after an exploit becomes public. There’s also the possibility of zero-day exploits —exploits for vulnerabilities that don’t yet have patches — that you need to take into consideration.
“In cases where having the management UI open to the world is intentional — and it’s unclear what the use case would be – administrators and security operators for these companies should be aware that their exposure is transparent and that it poses a huge potential for risk of their data and cloud infrastructure.”
Kubernetes is constantly adding new security capabilities and recent versions provide SSL communication and authentication. Those features should be turned on and, if remote management is required, they can be augmented with VPN connections and multi-factor authentication.
For more in-depth information on hardening Kubernetes against a variety of attacks, you can watch this presentation from independent consultant Brad Geesaman at KubeCon + CloudNativeCon North America 2017.
