Kubernetes Recon: A Closer Look at Discovery from the Kubernetes Attack Matrix

 

Chris Hall
Cloud Security Researcher, Lacework Labs

 

On April 2nd, Microsoft released their Attack matrix for Kubernetes, a collection of Kubernetes attack patterns modeled after Mitre’s ATT&CK framework. While the matrix was compiled for Azure, many of the patterns are valid for all cloud providers. There are nine tactics in the ATT&CK framework, however this blog expands on the Discovery portion and highlights the patterns that one is most likely to encounter in the wild. 

Discovery, aka reconnaissance, is the furthest left on the killchain, meaning it will always occur prior to the initial infection. Additional reconnaissance is also performed during lateral movement activities so focusing efforts on this phase can pay off by preventing more severe incidents. For Kubernetes, the components of Discovery in the attack matrix include:

  • Access the Kubernetes API server
  • Access Kubelet API
  • Network mapping
  • Access Kubernetes dashboard
  • Instance Metadata API

Kubernetes attacks can fall into one of two general categories: direct or indirect. A direct attack initially targets components specific to Kubernetes, whereas an indirect attack targets them after initial access. A direct type attack would be preceded with reconnaissance against Kubernetes resources, namely the Kubernetes management dashboard and/or the server API or Kubelet API. This is opposed to an indirect attack which is opportunistic in nature and would start with an exploit against an application in a pod and then move on to the node, other pods, or further in the cluster. The “Network mapping” and “Instance Metadata API” both require some form of pod access, so these would be leveraged in an indirect attack. 

In our last blog  we looked at container reconnaissance by searching on scanning hosts in GreyNoise. That analysis revealed a number of hosts tagged as “Kubernetes crawlers.” These are indicated by hosts scanning on Kubelet API port 10250 and performing web requests containing for any of the following patterns:

 

‘/api/v1/secrets’

‘/api/v1/pods’

‘/api/v1/namespaces’

 

Kubelet API scanning doesn’t appear to be widespread. A search for Kubernetes scanners only returned a couple thousand results. This is an extremely small amount when compared to over 4 million hosts scanning on port 22. It is possible however that Kubernetes discovery is going unnoticed. For example, attackers could be identifying Kubernetes clusters through inspection of the server’s SSL certificate, which negates the need to scan on port 10250. 

 

Kubernetes artifacts in public SSL certificates

Figure 1. Kubernetes artifacts in public SSL certificates

 

Filtering hosts with “kubernetes” in the SSL shows over half a million results in Shodan (ssl:”kubernetes”). Fortunately, among all the hosts, only .01% had port 10250 open, and a mere 19 were actually tagged as Kubernetes. 

Discoverable Kubernetes deployments

Figure 2. Discoverable Kubernetes deployments

As described in the matrix, exposed Kubernetes dashboards represent an attack surface that is most likely to be targeted (either as part of lateral movement after access has been obtained to a container or in the initial access phase). If the dashboard is exposed on the internet then there is obviously a much greater risk to cloud resources. Even if an exposed dashboard requires authentication, it’s still subject to brute force, and risks disclosure of sensitive organizational information. Several exposed dashboards were discovered via Google dorking, however only a couple appeared accessible. A Google Dork uses advanced Google search modifiers , such as “inurl:” or “intitle:” to find security holes and/or sensitive data exposed by misconfigurations. 

While Google Dork results are by no means comprehensive, the limited results may indicate that open Kubernetes dashboards are not currently a widespread problem.  Fortunately, the Kubernetes dashboard is locked down and disabled by default in current versions so most installations will not be vulnerable unless they are specifically configured otherwise.  

Dashboard found from Google Dorking

Figure 3. Dashboard found from Google Dorking

In summary, a successful Kubernetes attack will most likely take advantage of a misconfiguration. Any exposed service can be considered “low hanging fruit” to an attacker so it’s important to not make their jobs easier. It’s already easy for attackers to identify clusters via SSL cert inspection or to identify exposed dashboards with a Google Dork or scanning. In case you missed it, check out our presentation from BSidesSF 2019 demonstrating how to discover internet accessible Kubernetes components.

Kubernetes has recently added a lot of cluster security features, so sticking with a recent version and using default installation configurations will go a long way in protecting against most attacks. As a general rule, its advisable to audit your infrastructure and make sure you don’t have any components that are unnecessarily internet facing.