Posted on August 13th, 2019
Kubernetes (sometimes shortened to K8s) is an open-source container-orchestration system released in 2015 that’s commonly used for automating application deployment, scaling, and management. Kubernetes use is growing in popularity because it saves engineering teams time and work at scale. Since the technology is fairly new and the adoption is so high, many developers are learning how to use it as they go, which often leads to misconfigurations and built-in insecurities.
Lately, the community has focused quite a bit on the security of Kubernetes. Just last week at Black Hat USA 2019, there were several training sessions on the topic, and a briefing specifically about how to attack Kubernetes, called “The Path Less Traveled: Abusing Kubernetes Defaults.”
To help researchers exploring the topic and corporate security teams searching for their unknown and exposed Kubernetes components, we recently added the Kubernetes protocol to our IPv4 data set. We’ll go into more detail later in this post, but we currently detect about 16,000 hosts running Kubernetes around the world, with most hosts running versions 1.13 and 1.10.
Luckily, many companies have started paying more attention to the risks containerization protocol can open them up to.
Real-world attacks exploiting Kubernetes weaknesses
Kubernetes security vulnerabilities are a hot topic in the community. While some real vulnerabilities and exploits do exist, misconfigurations are a much more common problem.
- Shopify made the news recently by discussing how a bug bounty researcher alerted them to a vulnerability that allowed him to gain control of the container cluster. While it’s not clear if this was tied specifically to Kubernetes, it’s a similar type of security risk tied to orchestration tools.
- In early 2018, Tesla fell victim to a Kubernetes-based attack thanks to an oversight in the Kubernetes setup, which didn’t even require a password to gain access. “Within that one Kubernetes pod, access credentials were exposed to Tesla’s AWS environment which contained an Amazon S3 (Amazon Simple Storage Service) bucket that had sensitive data such as telemetry,” RedLock researchers said.
- Our friends at Laceworks Labs have been doing some ongoing research using Censys data to find vulnerable Kubernetes instances in the wild. Specifically, they were using our data to search for Kubernetes dashboards.
- “In our recent analysis, we found over 500 [Kubernetes dashboards] exposed to the internet. For the API server, we again used Censys and found over 21,000 accessible API servers and 800 insecure API servers (no authentication or authorization, more to come on the research!).” Their blog on the topic goes into more detail. In fact, they presented their research at BSidesSF 2019 and their talk is worthy viewing.
- StackRox and Skybox recently published a (gated) report, warning of the dangers and potential security impact of poor container security practices.
Now that we’ve established that there are ongoing attacks on these types of orchestration tools, let’s dive further into how you can find Kubernetes components that are exposed on the Internet.
How do I find Kubernetes in Censys?
Happily, this is an easy one, since we’ve added a new protocol: Port 6443. You can just use our protocol tag (protocols:”6443/kubernetes”) to find them quickly.
We suggest starting your search for looking for Kubernetes with the dashboard running, which are often particularly weak spots in these components.
To search specifically for any Kubernetes components tied to your ASN or CIDR block, just add “AND [ASN][CIDR]” to this query.
For each Kubernetes component we’re able to find, you’ll find the following data:
- names
- addresses (internal and external),
- If the web UI dashboard is running
- rbac roles
- info on the host machine or guest node:
- OS
- Kernel
- Architecture
- Docker Version
- kubelet Version
- kube proxy version
- container images
- volumes attached
- volumes in use
The image below is from a single host we found through our scans:
In addition to these attributes, we collect data on security roles and pods. The risk of misconfigured security roles is the potential for privilege escalation attacks. We also attempt to tell if the WEB UI dashboard is running, which is considered insecure even when authentication is required.
Tips for Securing Kubernetes Properly
First and foremost, we strongly recommend that you don’t expose Kubernetes, which is inherently a pretty insecure port, to the Internet. There’s no real upside to connecting it and all it does is open you up to risk.
Secondly, don’t allow anonymous authentication, which in some very specific situations, can be enabled by default for some versions of Kubernetes.
A few steps to securing these properly:
In general, make sure that your components are properly setup and configured, the CIS Kubernetes security benchmark is a good baseline to evaluate yourself against. Any steps you skip in this process can become a huge problem down the road and end up creating a significant security issue. Configuration monitoring at this initial step is critical.
Kubernetes actually provides a fairly in-depth article about security issues and “gotchas” and how to avoid them, which is worth a read. Rather than just regurgitating what they already provided, we’ll send you over to their site for very specific suggestions about security your Kubernetes components.
Remember that you can use Censys to find all kinds of exposed devices and infrastructure. Check out some of our most recent additions to our data sets: Microsoft Server Message Blocks (SMBs), and remote desktop applications, like pcAnywhere, remote desktop protocol (RDP), and virtual network computing VNC), for example.
If you’re looking for more tips like these on how to use Censys data to keep your business network secure, keep an eye on our blog and subscribe to our Twitter feed @censysio.
