Nicht erst Log4j hat der Welt vor Augen geführt, wie schnell Verwundbarkeiten in Abhängigkeiten zu großen Sicherheitslücken führen können. Veraltete Bibliotheken eingesetzter Software sollten bestenfalls automatisch und kontinuierlich überprüft werden. Der Security-Tipp in diesem Monat zeigt Ihnen die Theorie hinter der Prüfung und mit Trivy ein simples Werkzeug für diesen Zweck.
Die Schwachstelle in der Java-Bibliothek Log4j hat Ende des letzten Jahres für großes Aufsehen gesorgt. Was auch zur Konfusion in den ersten Tagen beigetragen hat, war die Tatsache, dass so gut wie niemand Log4j explizit installiert hat. In den meisten Fällen war Log4j nämlich eine Abhängigkeit und wurde bei der Installation eines größeren Softwareprodukts einfach mit aufgespielt. Kaum ein Administrator hat neben all der Software, die täglich installiert und verwaltet wird, noch eine Übersicht über die von dieser Software genutzten Bibliotheken. Das war auch bei Log4j der Fall. Die Konfiguration des Loggers hatte großen Einfluss auf die Möglichkeit für Kriminelle, die Schwachstelle auszunutzen – konfiguriert war sie aber meist schon von den Entwicklern der eigentlichen Software.
Der Siegeszug von Microservices nimmt derweil kein Ende. In einer definierten Umgebung, dem Container, bieten Softwareentwickler ihre Programme mit allen Abhängigkeiten fertig installiert zum Einsatz an. Tatsächlich bleiben dem Betreiber der Software Informationen über die Umgebung innerhalb des Containers jedoch häufig vorenthalten. Absichern muss er seine Systeme aber trotzdem.
Wichtige Updates
Während Sie die gängigen Betriebssysteme auf Ihren Rechnern vermutlich automatisch aktualisieren, müssen Sie eigentlich auch die in den eingesetzten Containern installierte Software im Blick behalten. Was Updates angeht, gibt es unterschiedliche Philosophien. In einem Security-Tipp geht natürlich Sicherheit vor Verfügbarkeit. Das bedeutet, dass verfügbare Updates schnellstmöglich automatisch installiert werden sollten. In den meisten Fällen finden die angebotenen Patches der Distributoren ohne Probleme ihren Weg auf die Systeme.
Die Schwachstelle in der Java-Bibliothek Log4j hat Ende des letzten Jahres für großes Aufsehen gesorgt. Was auch zur Konfusion in den ersten Tagen beigetragen hat, war die Tatsache, dass so gut wie niemand Log4j explizit installiert hat. In den meisten Fällen war Log4j nämlich eine Abhängigkeit und wurde bei der Installation eines größeren Softwareprodukts einfach mit aufgespielt. Kaum ein Administrator hat neben all der Software, die täglich installiert und verwaltet wird, noch eine Übersicht über die von dieser Software genutzten Bibliotheken. Das war auch bei Log4j der Fall. Die Konfiguration des Loggers hatte großen Einfluss auf die Möglichkeit für Kriminelle, die Schwachstelle auszunutzen – konfiguriert war sie aber meist schon von den Entwicklern der eigentlichen Software.
Der Siegeszug von Microservices nimmt derweil kein Ende. In einer definierten Umgebung, dem Container, bieten Softwareentwickler ihre Programme mit allen Abhängigkeiten fertig installiert zum Einsatz an. Tatsächlich bleiben dem Betreiber der Software Informationen über die Umgebung innerhalb des Containers jedoch häufig vorenthalten. Absichern muss er seine Systeme aber trotzdem.
Wichtige Updates
Während Sie die gängigen Betriebssysteme auf Ihren Rechnern vermutlich automatisch aktualisieren, müssen Sie eigentlich auch die in den eingesetzten Containern installierte Software im Blick behalten. Was Updates angeht, gibt es unterschiedliche Philosophien. In einem Security-Tipp geht natürlich Sicherheit vor Verfügbarkeit. Das bedeutet, dass verfügbare Updates schnellstmöglich automatisch installiert werden sollten. In den meisten Fällen finden die angebotenen Patches der Distributoren ohne Probleme ihren Weg auf die Systeme.
Für die seltenen Fälle, in denen ein Update zu einer Nichterreichbarkeit des betriebenen Dienstes führen kann, ließe sich argumentieren, dass ein nicht verfügbares System unter Umständen besser sein kann als ein verwundbares System. Für Entwickler steht im Gegensatz dazu die Erreichbarkeit der angebotenen Software im Vordergrund. Oft werden daher sogar die Versionsnummern der benötigten Bibliotheken festgelegt, um die Interoperabilität auch bei Updates der eigenen Software im Container sicherzustellen. Das führt mitunter dazu, dass vermeintlich aktuelle Container einer Software auch Abhängigkeiten beinhalten, die nicht der aktuellen Version entsprechen.
Versionen im Blick
Das System der Common Vulnerabilities and Exposures (CVE) zur Referenz von Schwachstellen und Sicherheitslücken wird von der US-amerikanischen Forschungseinrichtung MITRE verwaltet. Gefundene Sicherheitslücken erhalten damit eine eindeutige Nummer, sodass Kataloge mit Schwachstellen ein einheitliches Referenzsystem verwenden können. Ein bekannter Katalog ist die National Vulnerability Database (NVD) [1] des amerikanischen National Institute of Standards and Technology (NIST) [2]. Die NVD ist ein öffentlich verfügbarer Katalog mit Schwachstellen, den Sie kostenfrei abfragen können.
Um beispielsweise mehr Informationen zum Log4j-CVE zu erhalten, rufen Sie die folgende URL mit Ihrem Browser auf: "https://services.nvd.nist.gov/rest/json/cve/1.0/CVE-2021-44228". Für die systematische Nutzung der Datenbank können Sie einen API-Key anfragen, der ebenfalls kostenlos ist.
Wenn Sie selbst oder Ihre Kollegen im Bereich der Softwareentwicklung unterwegs sind, kennen Sie vielleicht das ein oder andere Werkzeug, das die Überprüfung von Abhängigkeiten auf Basis gemeldeter Schwachstellen ermöglicht. Einmal in den Entwicklungs- und Deploymentprozess integriert, erhalten Sie so für Ihre erstellten Container eine Warnung, wenn Abhängigkeiten mit bekannten Schwachstellen eingebunden werden.
Die Trivy-Ausgabe für ein älteres Ubuntu-Image mit Verwundbarkeiten für libsystemd0 und libudev1.
Container prüfen mit Trivy
Mit Trivy [3] von der Firma Aquasec prüfen Sie eigene und fremde Container auf mögliche Schwachstellen. Dafür verwendet Trivy im Hintergrund eine Datenbank, die Verwundbarkeitsinformationen unterschiedlicher Kataloge bündelt. Das ist natürlich nicht nur für Continuous Deployment interessant, sondern kann auch routinemäßig für von Ihnen genutzte Container eingesetzt werden. Praktischerweise kommt Trivy selbst im Container daher, sodass Sie in einer installierten Docker-Umgebung auf Ihrem System gleich loslegen können. Zu Testzwecken eignet sich ein etwas älteres Ubuntu-Image, zum Beispiel eines vom April 2019, das Sie etwa mit folgendem Kommando testen können:
docker run -ti aquasec/trivy image ubuntu:bionic-20190424
Die Ausgabe auf der Konsole zeigt Ihnen eine lange Liste mit installierten Bibliotheken und den für diese gemeldeten CVEs. Natürlich gibt es für die meisten Meldungen längst Updates, die Sie in dem Image installieren könnten. Allerdings werden Sie auch für das aktuelle Image "Ubuntu:latest" feststellen, dass durchaus einige CVEs in der Datenbank zu finden sind. Bei den Meldungen handelt es sich nämlich um Schwachstellenbeschreibungen, die nicht immer kritisch sind, sondern manchmal auch nur theoretische Angriffsmöglichkeiten aufzeigen.
Die gemeldeten Risiken für das aktuelle Ubuntu-Image sind ausschließlich von geringer oder mittlerer Schwere. In den meisten Fällen können Sie diese einfach ignorieren. Das geht auch mit Trivy sehr komfortabel: Ergänzen Sie einfach den obigen Aufruf um die Angabe der beiden höchsten Warnstufen und führen das folgende Kommando noch einmal aus:
docker run -ti aquasec/trivy image -s HIGH,CRITICAL ubuntu:bionic-20190424
Nun sehen Sie nur noch eine Meldung, die Ihnen die Verwundbarkeit in den Bib-liotheken "libsystemd0" und "libudev1" anzeigt. Es geht hier um einen Programmierfehler, der möglicherweise ausgenutzt werden kann, um Daten im Stack des Programms zu manipulieren. Für die aktuelle Ubuntu-Version erhalten Sie keine Ausgabe, es gibt also keine bekannten Schwachstellen mit hoher oder kritischer Einstufung.
Wenn Sie Trivy automatisch verwenden möchten, um beispielsweise Ihre eingesetzten Container zu überwachen, können Sie den Wert festlegen, der bei einem Fund von Trivy zurückgegeben werden soll. Je nachdem, welchen Cron-Daemon Sie einsetzen, ist es möglich, mit einem Rückgabewert ungleich 0 die Ausgabe des Programms per E-Mail an die im Crontab hinterlegte Adresse senden zu lassen. So erhalten Sie direkt alle kritischen Schwachstellen in eingesetzten Containern per E-Mail zugestellt.
Trivy bietet Ihnen neben dem Check von Containern auch weitere nützliche Features. So können Sie Verzeichnisse Ihrer eigenen Projekte prüfen lassen, Trivy berücksichtigt hier bekannte Abhängigkeitsdokumentationen wie Poetry für Python-Projekte. Ebenfalls können Sie etwa Terraform-Konfigurationen unter die Lupe nehmen, die unter dem Begriff Infrastructure-as-Code für die dynamische Verwaltung von größeren Clustersystemen wie Kubernetes zum Einsatz kommen.
Fazit
Veraltete Bibliotheken in Containern bleiben bei automatisierten Updateprozessen häufig außen vor. Mit Trivy verschaffen Sie sich einen Überblick und können automatisiert Warnungen versenden lassen. Als Administrator von Container-Clustern behalten Sie mit etwas Scripting auch die Images laufender Container im Auge, informieren die verantwortlichen Benutzer entsprechend und fordern Updates ein.