Die Verwendung von Containern für Applikationen und Dienste bietet einige Vorteile. So sind Container portabel, können auf einem System gebaut und auf Server und Cloudsysteme ausgerollt werden. Container sind im Vergleich zu virtuellen Maschinen (VM) leichtgewichtig, da sie den Kernel des Hosts gemeinsam nutzen und über kein eigenes Gastbetriebssystem verfügen. Der Container ist eine Instanz eines Images zur Laufzeit. Aus einem Image können mehrere Container gleichzeitig auf mehreren Plattformen betrieben werden. Ein Image enthält unter anderem den Code der Applikation(en), Tools und Bibliotheken sowie die Konfiguration und Umgebungsvariablen. Deshalb sollte ein Image nur Komponenten beinhalten, die zur Ausführung der Applikation auch benötigt wird.

Für Container Images gelten dieselben Sicherheitsanforderungen wie für virtuelle und physische Systeme. Deshalb sollen Schwachstellen- und Patch-Managementprozesse auch Images umfassen. Es besteht die Gefahr, dass ein Image einmal erstellt, vielmals geteilt, aber nie mehr gewartet wird. Bei der Verwaltung einer Container Registry sollte beachtet werden, wer in welcher Umgebung Images hochladen darf. Während die Entwicklungsumgebung offen sein darf, sollten die Test- und Produktionsumgebung restriktiv gehandhabt werden. Dabei spielt auch die Versionierung durch Tags der Images eine wichtige Rolle.

In diesem Artikel setzen wir uns mit dem Scan von Images auseinander. Es existieren viele Lösungen dafür, unter anderem Anchore, JFrog Xray, OpenSCAP oder Docker Scan. Wir haben das Skript Invoke-ContainerKitty entwickelt, das Scans von Images auf der Basis von Docker Scan orchestriert.

ContainerKitty

Das manuelle Scannen vieler Container Images ist repetitiv und nicht effizient. Wir haben ContainerKitty entwickelt, um den Scan von Images zu automatisieren und so den Prozess zu vereinfachen. Für ContainerKitty wird keine Serverinfrastruktur benötigt, das Skript kann auf jedem Windows-System mit Docker verwendet werden. ContainerKitty steht in unserem GitHub Repository zur freien Verfügung.

Das Skript stellt eine Liste von Container Images aus einem GitLab Repository zusammen. Es ist aber auch mögliche eine Liste aus einer anderen Quelle zu verwenden. Diese Liste sollte pro Zeile ein Image beinhalten, beispielsweise registry.example.com/dev/example-image:4.2.0. ContainerKitty lädt die Images aus der Registry in die lokale Docker Instanz und startet danach den Scan. Die Resultate werden pro Image als JSON-Datei gespeichert. Die Report-Funktion parst alle JSON-Dateien und erstellt eine Zusammenfassung sowie eine CSV-Datei zur Weiterverarbeitung. Alle Schritte können bei Bedarf protokolliert werden.

Um Container Kitty zu verwenden, wird Docker Desktop unter Windows benötigt. Um Scans durchzuführen muss eine Docker ID registriert werden. Docker Scan nutzt die freie Version der Vulnerability Datenbank von snyk.io. Mit der Free-Version können pro Monat 100 Container Scans durchgeführt werden.

Nutzung von ContainerKitty

Docker und ContainerKitty können ohne Administratorenrechte ausgeführt werden. Für Docker besteht die Voraussetzung, dass der Benutzer der lokalen Gruppe docker-users angehört. Vor dem ersten Aufruf von ContainerKitty muss die PowerShell-Sitzung bei Docker authentisiert werden. Nach der Installation von Docker sollte zudem die Scan Engine bei snyk.io registriert werden. Danach kann ContainerKitty genutzt werden:

PS C:\> docker login
PS C:\> docker scan --login --token SNYK_AUTH_TOKEN
PS C:\> Import-Module -Force .\Invoke-ContainerKitty.ps1

Die Module von ContainerKitty können miteinander kombiniert werden. Im folgenden Beispiel erstellt ContainerKitty eine Liste aller Images des Benutzers mit der ID 5 aus GitLab und lädt danach dessen Images aus der Registry in die lokale Docker Instanz. Danach wird ein Scan der Images durchgeführt und die Resultate ausgewertet:

PS C:\> Invoke-ContainerKitty -BuildList https://gitlab.example.org -BuildId 5 -BuildIdType User -Scan -Report -ReportDirectory .\reports\ -Log

      =^._.^=
     _(      )/  ContainerKitty 0.2.0-1623130424

[*] 6/8/2021 7:32:51 AM - Starting ContainerKitty
[*] 6/8/2021 7:32:51 AM - Start API calls
[*] 6/8/2021 7:32:51 AM - ContainerKitty needs a private token to build the container list. This token will not be stored.
[$] 6/8/2021 7:32:56 AM - List of container images is finished: .\containerkitty_container_list-20210608-0732.txt
[*] 6/8/2021 7:32:56 AM - API calls done
[*] 6/8/2021 7:32:56 AM - Start pulling container image ubuntu:xenial-20210429
...
[$] 6/8/2021 7:32:58 AM - Pulling container image ubuntu:xenial-20210429 done
[*] 6/8/2021 7:32:58 AM - Start scanning container image ubuntu:xenial-20210429
[*] 6/8/2021 7:34:11 AM - Scanning container image ubuntu:xenial-20210429 done
[*] 6/8/2021 7:34:11 AM - Start creating the report .\containerkitty_report-20210608-0734.csv
[!] 6/8/2021 7:34:14 AM - docker-image|ubuntu (Tag: xenial-20210429): 368 vulnerable dependency paths / Unique count: 47
[*] 6/8/2021 7:34:28 AM - Creating report .\containerkitty_report-20210608-0734.csv done
[*] 6/8/2021 7:34:28 AM - ContainerKitty is done

Jedes Modul kann auch einzeln ausgeführt werden. So kann direkt ein Scan gestartet werden, indem ContainerKitty eine manuell erstellte Liste von Images erhält. Es ist auch möglich nur eine Auswertung über JSON-Dateien durchzuführen, die durch Docker Scan erstellt wurden. Beim Report wird eine CSV-Datei erstellt, mit den folgenden Informationen:

• Id und Id Snyk
• Image und Version (Tag)
• Betroffenes Paket und dessen Version
• Titel der Schwachstelle
• Beschreibung der Schwachstelle
• Gegenmassnahme und Aussage, ob ein Upgrade/Patch vorliegt
• CVSS-Score und Aufschlüsselung nach CVSSv3.1
• Quellen

Diese Daten können anschliessend weiter ausgewertet werden. Bei der Auswertung von Schwachstellen sowie dem Scan generell gibt es jedoch einige Punkte zu beachten.

Herausforderung Schwachstellenscan

Es gibt einige Herausforderungen zu lösen, bevor ein Schwachstellenscan regelmässig durchgeführt werden soll. Das beginnt mit der Organisation vom Images, geht über die Auswahl der passenden Scanlösung bis zur Risikoeinstufung der gefundenen Schwachstellen.

Versionierung

Bereits vor der Durchführung eines Schwachstellenscans liegt die erste Herausforderung: Welche Images werden gescannt? Es muss definiert werden, ob alle vorhandenen Images oder nur die aktuelle Version ausgewählt werden soll. Dabei ist ein Versionierungskonzept notwendig, beispielsweise nach Semantic Versioning, damit alle Projekte das gleiche Schema befolgen, und die aktuelle Version einfach bestimmt werden kann. Wenn keine Version angegeben wird, sucht Docker Scan nach dem Tag latest.

Manuelle Installation von Paketen

Die meisten Scanner verwenden die Paketverwaltung des Images um die installierten Pakete und deren Version zu bestimmen. Das bedeutet, dass manuelle installierte Anwendungen in einem Scan übersehen werden können. Für dieses Herausforderung gibt es keine einfache Lösung. Bei der Erstellung von Images sollte drauf geachtet werden, dass nur der Paketmanager verwendet wird und Ausnahmen dokumentiert werden.

Schwachstellendatenbank

Scanresultate unterscheiden sich je nach Schwachstellendatenbank. Ein essentieller Punkt ist die Verknüpfung einer Schwachstelle in einem Paket mit der Version der jeweiligen Linux Distribution. Wenn diese Verknüpfung nicht gepflegt wurde, kann der Schwachstellenscanner eine Schwachstelle auch nicht korrekt zuweisen. Da Docker Scan die freie Version von snyk.io verwendet, haben wir die Scanresultate manuell untersucht und einige Lücken gefunden:

• Die Schwachstelle CVE-2021-3541 in libxml, welche in der freien Datenbank von snyk.io zwar existiert, aber nicht für Alpine Linux erfasst wurde. Daher wird diese Schwachstelle bei einem Scan eines Alpine Images nicht identifiziert.
• Die Schwachstelle CVE-2021-24032 in libzstd, die ebenfalls in der freien Datenbank snyk.io vorhanden ist, aber keine Zuweisung zu Red Hat Linux hat. Daher wird diese Schwachstelle bei einem Red Hat Image auch nicht erkannt.

Es lohnt sich bei der Evaluation einer Schwachstellenscanlösung zu vergleichen und zu analysieren welche Lösung die beste Abdeckung für die verwendeten Container Images bietet.

Risikobewertung

Images weisen vielfach eine hohe Anzahl von Schwachstellen auf. Diese Schwachstellen sind nach einem Schweregrad eingestuft. Wie Tomaso Vasella im Artikel Schweregrad und Risiken aufgezeigt hatte, sollte der Schweregrad nicht ohne weitere Analyse als Risiko übernommen werden. In der Risikobetrachtung sollte unter anderem darauf geachtet werden, ob die Schwachstelle überhaupt ausnutzbar ist und eine betroffene Funktion in der Applikation auch genutzt wird. Dabei muss dies mit den Verantwortlichen des Images sowie der Container analysiert und abgestimmt werden.

Fazit

Container bieten Vorteile gegenüber traditionellen Methoden wie virtuelle oder physische Maschinen. Die Sicherheitsanforderungen bleiben jedoch bestehen und können mit bekannten Konzepten und Methoden angegangen werden.

Wir haben für den automatisierten Scan von Images eine frei erhältliche Lösung entwickelt, die unkompliziert auf einem Windowssystem genutzt werden kann um effizient viele Images zu scannen. Wir freuen uns über Feedback und Verbesserungsvorschläge für ContainerKitty.

Über den Autor

Michael Schneider arbeitet seit dem Jahr 2000 in der IT. Im Jahr 2010 hat er sich auf die Informationssicherheit spezialisiert. Zu seinen Aufgaben gehören das Penetration Testing, Hardening und das Aufspüren von Schwachstellen in Betriebssystemen. Er ist bekannt für eine Vielzahl in PowerShell geschriebener Tools zum Finden, Ausnutzen und Beheben von Schwachstellen. (ORCID 0000-0003-0772-9761)

Links

• https://anchore.com/opensource/
• https://docs.docker.com/docker-for-windows/install/
• https://docs.docker.com/engine/scan/
• https://github.com/scipag/ContainerKitty
• https://hub.docker.com/
• https://jfrog.com/xray/
• https://semver.org/
• https://snyk.io/
• https://snyk.io/vuln/search?q=CVE-2021-24032&type=any
• https://snyk.io/vuln/search?q=CVE-2021-3541&type=any
• https://vuldb.com/de/?id.170727
• https://vuldb.com/de/?id.175254
• https://www.alpinelinux.org/
• https://www.redhat.com
• https://www.redhat.com/sysadmin/container-vulnerabilities-openscap