Let's step through the objectives of our first demo.
We're going to review kube‑hunter's command line flags,
we're going to audit our local Kubernetes cluster,
and then we're going to go ahead and review those findings,
through kube‑hunter, of course.
Now it's time to scan the demo environment with kube‑hunter.
Luckily for us, kube‑hunter can run within a Docker container,
so installation is a breeze.
Let's check out some of the various command line flags.
At this point, we're only going to focus on the major command line flags.
First off is ‑‑list.
This flag displays all tests in kube‑hunter,
and as we stated, by default, kube‑hunter runs in passive mode.
So if you want to see the active tests, you need to add the ‑‑active flag.
Next up is ‑‑pod.
In other words, set hunter as an insider Pod.
If you are running kube‑hunter with inside of a Pod, you can leverage this flag.
This is great for white box testing.
In this course, we're going to be taking a black box perspective.
In other words, we're going to be scanning the cluster from the outside.
However, I recommend you do both, if possible.
Next up is ‑‑cidr.
This allows you to scan an entire IP range for Kubernetes clusters.
As far as the ‑‑remote flag, we're going to be leveraging that in this course.
Here you can specify one or more IPs or DNS names.
Active, as we already stated, enables active hunting.
We're going to use that in this course as well.
Then also pay attention to the ‑‑report flag.
We are going to be leveraging the YAML option to give us more verbose output.
We'll see an example of this in a second.
Now it's time to scan the demo environment with kube‑hunter.
The ‑‑network flag is simply a Docker flag that allows us to
scan the local minikube Kubernetes cluster,
and we've already talked about the kube‑hunter flags,
‑‑remote and ‑‑active, so I won't go into those again.
We also leverage tee, just for saving the output.
Okay, so we're getting some pretty good information here.
Note the Nodes and the Detective Services all come from the same IP.
This makes sense, based on our minikube environment.
Also, note the Kubelet API and the port.
We're going to be leveraging this later on in the demo.
First,
we'll start with a pretty major finding in the
category of Remote Code Execution.
Specifically, there is anonymous authentication.
So the kubelet is misconfigured,
potentially allowing secure access to all requests on the kubelet,
without the need to authenticate.
We'll see the ramifications for this.
Next we see an Information Disclosure vulnerability, specifically Exposed Pods.
So an attacker could view sensitive information about the Pods that
are bound to a node using the pod's endpoint.
Then last, but not least, there is another remote code execution vulnerability,
specifically, Exposed Run Inside Container.
An attacker could run an arbitrary command within a container.
So let's take a step back.
The anonymous authentication allows the attacker to connect.
The Exposed Pods finding allows the attacker to do reconnaissance,
and then the Exposed Run Inside Container allows an attacker to take action.
In other words, to run arbitrary commands.
Given these findings,
it's safe to assume that this cluster might have already been breached.
Now, we see some evidence here on the right.
It's kind of difficult to see this within this view.
We'll solve this within the next command.
At this point,
we're going to be adding the ‑‑report flag with specifically a YAML value.
We also leverage yq for pretty‑printing the YAML.
Let's check it out.
I went ahead and scrolled up to the Apache Pod findings.
Here we see the power of the ‑‑active flag.
In other words,
kube‑hunter leveraged the kubelet vulnerability to get
environment variables from within the Apache Pod.
Also, it was able to get the service account token,
which is what the Apache Pod leverages to authenticate with the Kubernetes API.
I recommend that you instantiate the environment and explore
other vulnerabilities within this output.
As part of our information‑gathering phase,
let's run Nmap to get another perspective on this cluster.
Specifically, kube‑hunter gave a perspective on Kubernetes,
but we also want information on the underlying
server that is running Kubernetes.
To accomplish this, we'll run Nmap in the next demo.
Before we move on to the next demo,
let's do a brief recap of what we just learned.
We reviewed kube‑hunter's command line flags,
we audited a local Kubernetes cluster,
and then we reviewed kube‑hunter's findings.
We saw a case of information disclosure through the Pods metadata endpoint.
This would allow the attacker to do some pretty juicy recon.
We also saw an issue with anonymous authentication with the kubelet.
Obviously,
this would allow the attacker to connect directly to the Kubernetes cluster.
Then we saw a case of remote code execution.
This would allow an attacker to take action.
The general categories of these vulnerabilities,
recon, connect, and take action,
are going to be huge for us as we move forward within our investigation.