Zur tagtäglichen Arbeit von Softwareentwicklern gehört das Arbeiten mit Bibliotheken (Dependencies). So sehr solche Bibliotheken die Arbeit erleichtern, sind sie andererseits eine potenzielle Gefahr für Security-Lücken.
Spätestens seit dem Log4Shell-Vorfall sollte dieses Risiko allen klar sein. Die Sicherheitslücke betrifft die beliebte Log4j-Protokollierungsbibliothek für Java-Anwendungen und hat eine Schwachstelle in log4j, die es Angreifern gegebenenfalls ermöglicht, auf dem Zielsystem eigenen Programmcode auszuführen und so den Server zu kompromittieren.
Bereits vor dem Bekanntwerden von Log4Shell erwähnte der bbv Technica Radar Vol. 2 ‘Dependency Vulnerability Scanning’ als Use – basierend auf diversen Nennungen aus verschiedenen Quellen wie zum Beispiel dem Thoughtworks Radar, welcher den OSS Index im Oktober 2020 in das Assess eingebaut hat. Darüber hinaus sind beim OWASP Top 10 2021 Update die «Vulnerable and outdated components» 3 Plätze nach vorne gerutscht und werden somit ebenfalls als potenziell grösseres Risiko gehandelt.
Doch wie können Risiken früh erkannt und verhindert werden? Auf Basis der OWASP-Erkenntnisse haben wir eine Übersicht erstellt und potenzielle Gefahren sowie Lösungsansätze aufgelistet.
Potenzielle Gefahren beim Einsatz von Bibliotheken:
- Nicht alle Versionen von Komponenten sind bekannt (Client- und Serverseitig). Dies beinhaltet direkte und transitive genutzte Komponenten.
- Eine vulnerable Software wird eingesetzt. Etwa ein Betriebssystem, Web/Application Server, Datenbanken, Anwendungen, APIs und alle Komponenten, Runtime Environments sowie Bibliotheken.
- Die Bibliotheken werden nicht regelmässig auf Schwachstellen durchsucht und es sind auch keine Security-Bulletins abonniert worden. Beispielsweise bei den Komponenten, welche im Einsatz sind.
- Darunterliegende Plattformen, Frameworks und Abhängigkeiten werden nicht risikobasiert und zeitnah korrigiert oder aktualisiert.
- Softwareentwickler testen nicht die Kompatibilität von aktualisierten Bibliotheken.
- Eine Komponente wurde falsch konfiguriert.
Wie können diese Gefahrenquellen verhindert werden?
OWASP schlägt vor, ein Patch-Management einzurichten, welches folgende Punkte abdeckt:
- Nicht mehr verwendete Abhängigkeiten, unnötige Funktionen, Komponenten, Dateien und Dokumentationen sollten entfernt werden.
- Ein kontinuierliches Inventar der verwendeten Version von Client- und Serverseitigen Komponenten und deren Abhängigkeiten sollte erfasst sein. Dieses Inventar sollte fortlaufend auf bekannte Schwachstellen geprüft werden, die in den Listen zu «Common Vulnerability and Exposures» (CVE) und «National Vulnerability Database» veröffentlicht sind. Diese Überprüfung gilt es zu automatisieren. Zudem sollte man unbedingt sicherstellen, dass man E-Mail-Benachrichtigungen erhält, sobald bei den eingesetzten Komponenten neue Sicherheitslücken gefunden werden.
- Verwendete Komponenten sollten nur von offiziellen Quellen über sichere Links eingesetzt werden, wenn immer möglich mit Hilfe von signierten Paketen.
- Bibliotheken und Komponenten, die nicht mehr gewartet werden oder die keine Sicherheitsupdates für ältere Versionen freigeben, sollten im Auge behalten werden.
Wie können bekannte Sicherheitslücken automatisiert gefunden werden?
Eine Möglichkeit ist das Dependency Vulnerability Scanning im .NET-Ökosystem. Im .NET-Ökosystem können bekannte Systeme wie beispielsweise einen Sonarqube oder den OSS Index verwendet werden. Seit .NET SDK 5.0.200 bietet .NET die Überprüfung auch direkt an.
Mit folgendem Befehl im Solution-Verzeichnis werden alle direkten oder transitiven Abhängigkeiten aufgelistet, die in der verwendeten Version eine bekannte Sicherheitslücke aufweisen:
1 | dotnet list package --vulnerable --include-transitive |
.NET verwendet hierbei ihre eigenen kuratierten Listen von GitHub, die auf den öffentlichen CVE aufbauen.
Zur Implementation der Schwachstellenüberprüfung im dotnet sind einige Punkte zu beachten. So ist der Befehl noch nicht wirklich komfortabel gelöst. Weder ist die Ausgabe in einem einfachen maschineninterpretierbaren Format, noch ist der Rückgabewert des Kommandos auswertbar und es wird immer das Resultat 0 zurückgegeben.
Basierend auf der Idee von yarn audit hilft folgendes Bash-Script mit der Umformung und Interpretation der Kommandozeilen Ausgabe.
#!/bin/bash # interpretes dotenet list package --vulnerability output and flags the level based on yarn implementation https://classic.yarnpkg.com/lang/en/docs/cli/audit/ # Low 2 # Moderate 4 # High 8 # Critical 16 flagLevel () { if grep -l $2 $1 > /dev/null;then echo $3; else echo 0;fi } low=$(flagLevel $1 'Low' 2) moderate=$(flagLevel $1 'Moderatee' 4) high=$(flagLevel $1 'High' 8) critical=$(flagLevel $1 'Critical' 16) vulnerability=$(expr $low + $moderate + $high + $critical) echo $vulnerability
Dieses Script – nennen wir es dotnet-vuln-level.sh – hilft uns nun, bei gefundenen Gefahren eine Notifikation auszulösen oder einen Build auf dem Continuous-Integration Server scheitern zu lassen.
Verwendbar mit:
dotnet list package --vulnerable --include-transitive > report.txt ./dotnet-vuln-level.sh report.txt
Es lohnt sich auf jeden Fall, vorzu nach neuen Schwachstellen zu suchen und diese zu beheben. In den USA ist dies sogar gesetzlich verankert: Im Rahmen von Log4Shell wurden bereits Regelungen erlassen, nach denen Unternehmen verpflichtet sind, aktuelle Patches zu installieren. Wer damit zu lange wartet, riskiert eine Busse der Handelskommission.
Benutzte Quellen
Der Experte
Marco Ravicini
Marco Ravicini ist als Senior Software-Architekt .NET bei der bbv tätig. Als Lead der Software Craftsmanship und .NET Community innerhalb der bbv ist ihm der Erfahrungs- und Wissensaustausch sehr wichtig. Marco ist passionierter Vertreter der Software Craft Bewegung.
bbv Technica Radar
Der bbv Technica Radar zeigt eine aktuelle Einschätzung der Trends zu Technologien, Tools, Methoden, Sprachen und Konzepte auf einen Blick. Im Radar sind verschiedene Expertenmeinungen und Quellen konsolidiert. Der Fokus des Radars liegt auf dem Schweizer Markt. Alle drei Monate wird der Technica Radar aktualisiert, so ist er eine aktuelle und wichtige Entscheidungsgrundlage.
Sie möchten wissen, was die Einschätzungen für Ihr Unternehmen bedeuten? Buchen Sie Ihren Beratungstermin unter info@bbv.ch