All right, onto another demo.
In this demo we're going to inspect container image vulnerabilities with Trivy.
We are also going to look for signs of container image
modification with the docker history command.
In our installation script, we installed Trivy.
Trivy can find vulnerable packages within container images.
Remember, we found this image name through the /pods metadata endpoint.
Let's see what we can find.
Okay, I'm going to scroll up a little bit.
Holy smokes, 160 vulnerabilities in this image.
Oof.
Okay,
so we're going to scroll down a little bit and see if we
can find anything related to Heartbleed.
Well, there we go,
information disclosure and handling of TLS heartbeat extension packets.
That's Heartbleed for you.
Let's scroll up here a little bit.
So note the OpenSSL version that was leveraged.
We're going to verify this in the next command.
Now, we're going to go ahead and explore the contents of the Docker image.
First we pull down the image from the registry,
and then we leverage the docker history command.
This command shows the history of an image.
The format flag allows us to focus on the commands that make up the image.
We'll see this very soon.
Each line shows us the commands in the respective Docker image layer.
The docker history command can be helpful if the
original Dockerfile is not available, such as in this case.
We see OpenSSL is being installed through a nontraditional mechanism.
In this case, installations usually occur through apt.
This can be a red flag.
It appears the attacker used the Docker registry credentials
to implant a malicious container image, or in other words,
a container image that is vulnerable to Heartbleed.
This is a sophisticated persistence mechanism,
as there might be hundreds of Kubernetes nodes that leverage this image.
So what could Heartbleed do?
Well,
Heartbleed could allow a remote attacker to view the memory
contents of the Kubernetes node. As Apache is a web server, the
memory contents could include sensitive authentication cookies or
other sensitive information.
To note, the output of the docker history command by
itself can't be fully trusted.
In other words,
an attacker can influence the docker history output. For more
context on these types of attacks, please see the docker history
modification link in the course notes.
In our case, the attacker wasn't that sophisticated, and
the docker history command gave us valuable clues as to how
our cluster was compromised.
Let's recap what we've just learned.
We inspected a container image for vulnerabilities with Trivy, and
through that we found Heartbleed. We also looked for signs of Docker
image modification with the docker history command.