•  
  •  
  •  
  •  
  •  
Dependency Vulnerability Scanning in .NET

Wenn Bibliotheken zur Gefahr werden

Open-Source-Bibliotheken oder solche von Drittanbietern können vieles vereinfachen. Gleichzeitig bergen sie jedoch auch das Risiko, ungewollt Sicherheitslücken in ein System einzubinden – was spätestens der Log4Shell-Vorfall deutlich gezeigt hat.

20.01.2022Text: bbv0 Kommentare
Bibliothek_Bücherregale mit kreisförmigem Durchgang
  •  
  •  
  •  
  •  

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

  1. CVE-2021-44228 Log4j CVE Record
  2. bbv Technica Radar Vol 2
  3. OWASP Top 10
  4. OWASP A06:2021 – Vulnerable and Outdated Components
  5. OSS Index
  6. Vulnerability Scann Anouncement .NET SDK
  7. GitHub Security Advisories

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.

Unser Wissen im Abo

bbv Griechenland

«Der neue Standort ist mehr als ein Büro»

Offshoring
Ethical OS

Denn sie wissen, was sie tun

Digitalisierung
The Mountain Mind

Programmieren ist wie Bergsteigen

Agile Software Development

Artikel kommentieren

Die E-Mail-Adresse wird nicht publiziert. Notwendige Felder sind mit einem * versehen.

Beachtung!

Entschuldigung, bisher haben wir nur Inhalte in English für diesen Abschnitt.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.

Beachtung!

Entschuldigung, bisher haben wir nur Inhalte in English für diesen Abschnitt.

Achtung!

Entschuldigung, bisher haben wir für diesen Abschnitt nur deutschsprachige Inhalte.