We are back in the pull request view within the GitHub UI,
I'm going to go ahead and merge this pull request so
we can see the workflow in action.
Because I'm an administrator,
we don't have to go through the whole approval process.
I can just go ahead and merge this.
Nice!
It looks like everything worked out correctly.
At this point, let's see if the workflow was triggered.
We see it going.
Perfect!
I'm going to click on it.
I'm going to wait until the workflow finishes.
Remember, this was triggered because we merged code into the main branch.
Nice!
We see the green checkmark, so the script successfully executed.
Let's click on this and drill in a little bit more.
We see the Trivy installation was successful.
We went ahead and logged into Docker Hub.
Let's drill into Docker Registry Interactions.
We see that this was the first time building this Docker image,
thus we are skipping the integrity checks.
Up here, we also see the push to Docker Hub.
This is uploading the Docker image to the Docker registry.
Let's go back into the main repo view.
Oh, nice!
We see the Security Bot updating Docker image signature.
Let's check that out.
This is the signature that is committed into the repo
and is used for tampering checks.
Nice!
It looks like everything is working as we expected.
At this point,
we are going to go ahead and simulate Docker image tampering and
see if our script picks up the malicious actions.
Okay, let's go back to our main Docker file.
Let's assume we are the attacker and we are trying to
introduce a vulnerable Docker image.
This version of Bash is vulnerable to shellshock.
Shellshock is a critical vulnerability in Bash that could allow a
remote attacker to execute arbitrary shell commands.
I'm going to go ahead and un‑comment this vulnerability.
Also,
we're going to introduce a regular expression
denial‑of‑service vulnerability through a Python package.
Okay, we un‑comment that as well.
Remember, the attacker can introduce any type of vulnerability,
for example, a cryptominer.
And just think about it.
If thousands of servers download a Docker image that has a cryptominer,
you can imagine how lucrative this would be for an attacker.
Okay, I'm going to go ahead and save my changes.
We buil tthe Docker image ourselves.
In other words, we don't want to commit our changes into Git.
This will probably get us caught by all the process we just implemented.
Here we see that we give the Docker image the appropriate tag.
This will allow us to upload our image to the
appropriate repo within Docker Hub.
So zachroofsec is the Docker Hub user,
and trivy‑tutorial is the Docker Hub repo we are uploading to.
Let's kick off this build.
Before we upload this malicious image to the Docker registry,
we need the Docker registry credentials.
As an aside, the attacker can steal these credentials in many ways.
For a sophisticated example,
please see my Container Infrastructure Analysis with
Kube‑hunter course here on Pluralsight.
The link is in the course notes.
Okay, we're going to proceed with the login.
Perfect.
Let's push it up to Docker Hub.
Nice!
It looks like the push was successful.
Let's see if our automation will catch the Docker image tampering.
I'm going to go ahead and re‑trigger the GitHub action.
For the purposes of this demo, we'll manually re‑trigger our workflow.
Remember,
this can be triggered on a schedule by un‑commenting the
schedule block within the workflow file.
Oh wow!
It looks like our script found the tampering.
Let's dive in a little bit deeper.
Okay, we see the 'investigation needs to occur' message.
Obviously tampering was present.
If you recall from our script logic, when tampering is present,
we go ahead and run Trivy on the tampered image.
Here we see that Trivy successfully found the regular expression
denial‑of‑service that was added into the image,
but notice that the shellshock vulnerability was not found.
Let's quickly go back to our Docker file.
Okay, at this point, we're going to go back to our original Docker file.
Here we see the introduction of the shellshock vulnerability,
but notice something.
We are not installing this through a package manager.
This is simply a make installation, and this leads us to a very important point.
Trivy can only find vulnerable packages that are
installed via a package manager.
This is why we need at least one human to approve the pull request.
In other words,
an engineer might introduce a vulnerability that can't be scanned by Trivy.
Let's go back to the output of the GitHub workflow.
Okay,
so we previously saw how Trivy found the Python vulnerability and how Trivy
did not report on the Bash vulnerability or shellshock.
How do we get a hint as to what the attacker installed in the new image?
We can get a hint through Google's container‑diff tool.
Google's container‑diff tool looks for differences between Docker
images. Examples include file system changes,
image size changes, etc.
Take note that a very determined attacker could hide parts of
their changes from the container‑diff tool.
We'll see an example of this later on in the course. In general,
no cybersecurity tool can monitor for all attacks.
This includes Trivy and the container‑diff tool.
However, this combination of tooling might give you hints as to what has changed.
Let's go to the container‑diff output.
In particular, we see changes related to Bash.
This would be very helpful within an investigation.
Remember, the shellshock vulnerability was predicated on this Bash change.
Let's do a recap of what we've learned.
We used GitHub Actions to upload a Docker image to the Docker registry.
We also witnessed how Docker images can be rebuilt on a
schedule to reduce vulnerabilities.
Then we used GitHub Actions to expose Docker registry
tampering, and then we analyzed the tampered Docker image with
Trivy and Google's container‑diff tool.