Docker Vulnerability Scanning 102 - Going Deeper

In the first part of this series, we had just learned how to use Nmap to scan a running container for exposed vulnerabilities. There are several flaws with this approach. First being that it only shows you vulnerabilities to services exposed outside the container, the second being you must run this container to actually scan it. We will show you how to get around those issues today.

Meet Trivy

Trivy is the most popular open source security scanner, reliable, fast, and easy to use. Use Trivy to find vulnerabilities & IaC misconfigurations, SBOM discovery, Cloud scanning, Kubernetes security risks,and more.
From the website

Trivy has been on the scene for awhile (May, 2019), but didn't really hit it's stride until Aquasecurity gobbled it up and decided to foster it's growth while still leveraging it's tooling to make some cash.

Trivy is a docker image scanner written in Go that supports not only a CLI mode, but also a client server mode as well. This means you can have your CI/CD platform run a scan, and fail the build if the score is higher than your configuration allows. That last part is cool, but beyond the scope of this article.

Installing Trivy

The documents for installing Trivy are well fleshed out and easy to understand.As I run Debian, we will use the apt package manager to add a package repo, and install Trivy.

sudo apt-get install wget apt-transport-https gnupg lsb-release
wget -qO - https://aquasecurity.github.io/trivy-repo/deb/public.key | sudo apt-key add -
echo deb https://aquasecurity.github.io/trivy-repo/deb $(lsb_release -sc) main | sudo tee -a /etc/apt/sources.list.d/trivy.list
sudo apt-get update
sudo apt-get install trivy -y

Scanning an image

There are tons of ways to scan a docker image and filter the results in Trivy, but we will be focusing on the most common here. First, incase you didn't follow our first article (FOR SHAME!)... let's pull a very old version of apache.

docker pull httpd:2.4.17

Now, let's run Trivy by running

trivy image httpd:2.4.17

Scroll back to the top of all that mess, and look at Trivy work. It updates it's local DB of CVE's, scans the image, detects the OS, and finally outputs the total vulnerabilities sorted by category. Note these are all vulnerabilities, including all packages on the system, not just services.

Here is an example of APT's vulns from Debian 8.2

Filtering the output

Let's first start with getting a newer image to work with to cut down on some of the noise. We can start with Debian Stable

docker pull debian:stable-slim

As you can see from the screen above, there are way less vulnerabilities in Debian 11.6 than our old version (8.2). However, it's still a good amount. Let's look for vulns that are actually patchable, often times you will find, there isn't a fix for a vulnerability available yet.

trivy image --ignore-unfixed debian:stable-slim

And just like that, all was right in the world. As you can see, once we remove vulnerabilities that aren't patched yet, Debian is 100% patched and good to go! Let's filter for only Critical vulnerabilities, even if they haven't been patched yet.

trivy image --severity CRITICAL debian:stable-slim

Following the breadcrumbs for CVE-2019-8457

Just because there is a vulnerability, doesn't mean all is lost. Let's do some digging into this one. We see it's for SQLite. Let's look at the web link provided

Assume all input is malicious. Use an “accept known good” input validation strategy, i.e., use a list of acceptable inputs that strictly conform to specifications. Reject any input that does not strictly conform to specifications, or transform it into something that does.

Well pretty much every application worth it's salt already does this.

Don't forget to check other resources for CVE information. Here is a list of places I check to verify if something is likely to be exploited.

• Exploit DB - Great place to search for POC code against a vulnerability
• NIST - The government ran location for all CVE Data
• Debian Security Tracker - Very easy to read output about any package in Debian.

Results for CVE-2019-8457

Known Exploits:
Exploit DB doesn't show a POC for this vuln. However this checkpoint article pretty much gives you the tutorial on how to do this. So it's possible, and thanks to this article, my 11 year old daughter could to this, assuming she could get access to run raw SQL statements. So either local access, or a bad web application that uses SQLite and doesn't clean inputs.

NIST
NIST says it's been modified - but needs to be re-evaluated. So, innovation at the speed of government - https://nvd.nist.gov/vuln/detail/CVE-2019-8457

Debian Security Tracker
It would appear that the SQLite verison is listed as "fixed" however, the DB5.3 package is "vulnerable" so, that's our target for this vuln - https://security-tracker.debian.org/tracker/CVE-2019-8457

Proper Judgement on Vulnerabilities.

When looking at Vulns, one has to remember, just because it's vulnerable, doesn't mean it's exploitable. For this vuln we selected, it is exploitable. However, another piece of the pie is what is the likelihood of it being exploited. In this case, we have a to look at what application is using the library. For that, we need to run the image and see if it's actually being used by the container.

Tracking down the files

Let's look into this container and see if this file is actually being used.We will need to update apt, and install the procps and lsof utilities

docker run --rm -it debian:stable-slim /bin/bash

apt update && apt install procps lsof -y

Let's look into the package details for this package. You will find by running ps aux that only bash is running. This is because it's debian slim. It has the absolute bare-bones available.

Let's look to ensure this libdb isn't running somewhere else:

lsof | grep libdb5

That comes back clean - since this is such a small image, you can do a lsof yourself and just look at the output to verify, but this package isn't being used currently. I say currently because this is a very small image of Debian, with nothing really installed. If you use this as your base image to install something on top of, you most likely will have more packages installed.

Final Note

Is it vulnerable? yes, the library is there, however, it's not being used currently, so it's safe.

Try this methodology on something you run in your lab, and see what you might dig up!