My next class:

How Safe Are Your Docker Images?

Published: 2021-04-22. Last Updated: 2021-04-22 07:21:43 UTC
by Xavier Mertens (Version: 1)
3 comment(s)

Today, I don't know any organization that is not using Docker today. For only test and development only or to full production systems, containers are deployed everywhere! In the same way, most popular tools today have a "dockerized" version ready to use, sometimes maintained by the developers themselves, sometimes maintained by third parties. An example is the Docker container that I created with all Didier's tools[1]. Today, we are also facing a new threat: supply chain attacks (think about Solarwinds or, more recently, CodeCov[2]). Let's mix the attraction for container technologies and this threat, we realize that  Docker images are a great way to compromise an organization! 

When we deploy Docker images, we have to take care of two things:

  • Vulnerabilities present in the software installed in the image.
  • Potential malicious changes (implementation of a backdoor, extra SSH keys, exfiltration of data, etc...)

Many Docker images have already been detected as malicious[3] and are more difficult to detect but how to address "common" vulnerabilities? When you are implementing a vulnerability scanning process in your organization (note that I say "process" and not "tool"!), there are components that are difficult to scan like virtual machines in suspended mode and... Docker images!

Here is an interesting tool that you can add to your arsenal to quickly scan Docker images for vulnerabilities: grype[4]. Written in Go, the tool is very easy to deploy and use:

root@lab0:/# docker images|grep ssl
drwetter/testssl.sh       latest     699c2c42986f   7 weeks ago     48.5MB
jumanjiman/ssllabs-scan   latest     2a46bf22e388   10 months ago   5.66MB
root@lab0:/# grype docker:drwetter/testssl.sh:latest
 - Vulnerability DB        [no update available]
 - Loaded image
 - Parsed image
 - Cataloged packages      [36 packages]
 - Scanned image           [2 vulnerabilities]
NAME     INSTALLED  FIXED-IN  VULNERABILITY  SEVERITY
openssl  1.1.1j-r0            CVE-2021-3450  High
openssl  1.1.1j-r0            CVE-2021-3449  Medium

grype scans the contents of the Docker image to find know vulnerabilities at the operating system level (Alpine, Busybox, Ubuntu, ...) but also language-specific issues (Ruby, Java, Python, ...). Personally, I like the JSON output (--output=json) to process the results with other tools or index them.

My advice is to scan all your new Docker images, especially the ones that you downloaded from 3rd party websites. 

And you? How do you scan/audit your Docker images? Please share your tools/processes in the comments.

[1] https://isc.sans.edu/forums/diary/DSSuite+A+Docker+Container+with+Didiers+Tools/24926/
[2] https://www.bleepingcomputer.com/news/security/hundreds-of-networks-reportedly-hacked-in-codecov-supply-chain-attack/
[3] https://unit42.paloaltonetworks.com/attackers-tactics-and-techniques-in-unsecured-docker-daemons-revealed/
[4] https://github.com/anchore/grype

Xavier Mertens (@xme)
Senior ISC Handler - Freelance Cyber Security Consultant
PGP Key

3 comment(s)
My next class:

Comments

(First sentence - you mean "that is NOT using docker"?! ;)

Important topic, especially when you see them targeting people "in a hurry" with "up-to-date images" that, for sure, may have been updated more recently than the original. But there could also be an "extra twist" that has been added...

For professional use we are fronting https://www.paloaltonetworks.com/prisma/environments/docker which is designed to be integrated in all parts of the lifecycle / processes.

A thought I have had is that we should be able to use DNS to allow automated verification of downloaded images/components. By providing a checksum posted as a TXT record for versionnumber. [dockerimage/software]. origincompany . tld... Thoughts?
Indeed, "not" was missing, fixed! ;-)

Thank you for the feedback, the idea is interesting... Let me have a look at it.
A reminder that the whole container thing is still fairly early in the process and it is so easy to imagine what we do day to day is everywhere and not just our particular bubble(s).
"is not using Docker today" is 100% opposite of my client base. None of mine are using it in any fashion yet. They range from "What is this Docker stuff?" through "What relevant apps are available to me that can even use Docker yet" to the one client that has any Dev lightly thinking of how they'd have to re-engineer their whole processes to allow for it. I even had one prospect who wouldn't even do any virtualization last year.

It is nice to see one can now get Containers from the VMware Marketplace, and at least one of the applications I work with now has one component optionally as a Docker image in beta. So we are getting there, but for now it is mostly the realm of where Dev is involved which limits it to those organizations those few shops with more than a couple IT persons. i.e. all those many small shops that account for about half the GDP

Diary Archives