Before we run the credential audit, we need to get some information.
Here, we get the Apache Pod name.
We'll use this in the next command.
So in summary,
we're about to use the kubelet's remote code
execution vulnerability to run shhgit,
in other words our credential audit script.
Now,
there's a lot of information in this command, so let's
break this down into digestible pieces.
First, we installed kubeletctl within our installation script.
Kubeletctl allows for us to take advantage of the
vulnerable kubelet and run commands within Pods.
Here, we download the installation script for shhgit,
our credential audit script, into the Apache Pod's tmp directory.
It's so funny saying that command name, but just bear with me.
So, shhgit will eventually be used to look for credentials on the file system.
But wait a second,
why aren't we just SSHing into the Kubernetes node
and running the script ourselves?
Well, first I want to demo how attackers can exploit this vulnerability so you,
the blue teamer, can understand how to investigate this appropriately.
And second, whenever possible,
it's helpful to view the investigation from the attacker's perspective.
Obviously there can be time constraints when performing an investigation,
so it's up to you to make that tradeoff wisely.
Okay, back to shhgit.
The particulars of shhgit are outside the scope of this
course, and I recommend going into the repo and
understanding the installation script.
For the pod and container flags,
we pass the Pod and container that we are investigating.
In this case, it's the Apache Pod.
And for the server flag, we pass in the IP of the kubelet.
In our demo environment, all the Kubernetes processes are on the same node,
and ignoreconfig ensures that this request does not have authentication.
We really want to mimic the attacker.
Okay.
It looks like the script was successfully saved into the tmp directory.
Now, we update the command a little bit to execute
shhgit and save the results to this path.
This command can take a little while to run,
so to avoid any connection timeouts we persist the command's output to disk.
I'm going to run this command and then wait about 5 minutes
for everything to install and execute.
All right, let's check for the output that was saved in the previous command.
Oh wow, it looks like there is a Docker authentication file that was discovered.
In the beginning of this course,
we saw how the Apache Pod has access to the host
file system through the hostPath.
In this case, the Pod has access to the underlying host's Docker credentials.
And to give you some background,
these credentials are usually used by the kubelet to
interact with the Docker registry.
Perhaps the attacker leveraged these credentials to
compromise the Docker images within the registry.
And, if we think about this even further,
maybe the attacker replaced the Apache image with an
image that is vulnerable to Heartbleed.
But, how did the attacker know which image to compromise?
We are currently at this point in our investigation.
It appears an attacker could have accessed the Docker registry credentials.
Given this, the attacker could have uploaded a malicious Docker image.
But how would they know what image to compromise?
Well, there's a few ways to get this information.
However,
that information was also readily available through the Pod's
metadata endpoint that we saw earlier on in the course.
As an aside,
isn't it crazy how all of these vulnerabilities can be chained together?
In the next demo,
we'll inspect the Docker image that was found through the
Pod's metadata endpoint in more detail.
Okay, before we move on to the next demo,
let's do a recap of what we have learned so far.
We leveraged nmap to hunt for vulnerable Kubernetes services Through that,
we found a Pod that was vulnerable to Heartbleed.
We also hunted for vulnerabilities via the Pod's metadata endpoint.
Through that, we saw the host mount was exposed within the Pod.
We also used a kubelet vulnerability to do an investigation.
Specifically, we executed shhgit within a Pod.
Sorry, I'm always going to laugh when I have to pronounce that.
We also used shhgit to find registry credentials within the host mount point.
So in other words,
through the host mount point we were able to find registry
credentials on the underlying Kubernetes node.