All right, onto our next demo.
We are going to leverage nmap to hunt for vulnerable Kubernetes services.
We are going to dive deeper into the /pods metadata endpoint and
hit it directly to hunt for vulnerabilities.
And we are also going to leverage a kubelet
vulnerability to do an investigation.
Let's get started.
Here we run nmap.
The ‑p flag will numerate all ports, ‑sV for version detection.
For the script flag, we're going to be running some scripts
specifically to look for vulnerabilities.
In a real engagement,
you'd also want to use a more comprehensive vuln scanner such as OpenVAS,
but for simplicity, we're just going to use nmap.
Let's go to the top of our nmap findings.
At this point we see the Apache pod within the nmap findings.
In particular, look at this Heartbleed vulnerability.
The Heartbleed Bug is a serious vulnerability in the popular
OpenSSL cryptographic software library.
It allows for stealing information intended to be protected by TLS encryption.
As you see, the risk factor is high, and this is a pretty serious vulnerability.
But this is kind of odd.
Globomantics stated that they were patched,
and at the time of this recording,
the Heartbleed vulnerability has been out for about 6 years.
Something here isn't adding up.
We're going to take note of this, and specifically,
we're going to investigate this Apache service even further.
At this point,
we're going to dive deeper into the /pods metadata endpoint so we
can get more information about the Apache pod.
If you recall, a kube‑hunter finding was that the /pods endpoint was exposed.
From a reconnaissance point of view,
this endpoint is valuable because it can leak information
about the pods running on a Kubernetes node.
In particular, given the nmap finding,
I'm curious what information we can get from the Apache pod.
And also, as a blue teamer, you want to simulate these steps of an attacker.
As recon is often the first step,
this curl command will get us started in the right direction.
So the URL, as we previously stated, is the /pods metadata endpoint.
We got all this information from the kube‑hunter findings.
The Python command is simply pretty printing the JSON that is
returned from the endpoint, and the grep command simply searches
for information about the Apache pod, and we tee the output so we
can look at it later if needed.
So I went ahead and scrolled up within the output.
First off, we see the containers key of the returned JSON. These
containers map to various containers within the pods that the kubelet
has jurisdiction over. In particular, we see the Apache container, and
we see the image that it is leveraging.
Okay,
so the attacker would know the internal image name that is
being leveraged for the Apache service.
Take note of this image name.
This is big from a reconnaissance perspective.
Also note the volume mounts within the Apache container.
We see a mountPath of /host that is exposing the host‑volume.
Okay, so I'm trying to put 2 and 2 together here.
It looks like the underlying host‑volume is accessible
through the container at the host path.
We also see that the volume is readOnly.
Okay, this is some really good information.
So now we need to think a little bit.
How could an attacker exploit these findings?
Well, the answer lies in the kubelet. Let's investigate the kubelet further.