Die 10 größten Open-Source-Risiken

Foto: Roman Samborskyi | shutterstock.com

Die kürzlich entdeckte Backdoor im Linux-Datenkomprimierungs-Tool xz-utils war nach Log4j ein weiterer Warnschuss für Unternehmen. Die Hintertür hätte zu einem folgenreichen Software-Supply-Chain-Angriff führen können, wenn sie nicht rechtzeitig entdeckt worden wäre. Doch die Risiken im Bereich Open Source Software sind breit gefächert.

Das veranschaulicht auch ein Experten-Team der Non-Profit-Organisation OWASP – bestehend aus 20 CISOs und CTOs. Und zwar mit einem aktuellen Risiko-Ranking, das mit eindrücklichen Angriffsbeispielen und konkreten Handlungsempfehlungen versehen ist.

Die OWASP Open-Source-Risiko-Top-Ten

Im Folgenden lesen Sie, welche Open-Source-Risiken Entwicklungs- und IT-Sicherheits-Teams nach Empfehlung des OWASP-Expertenteams auf dem Schirm haben sollten.

1. Bekannte Schwachstellen in Abhängigkeiten

Hierunter fallen laut OWASP Code-Schwachstellen, die beispielsweise unabsichtlich durch die Entwickler eingeflossen sind. Vulnerabilities dieser Art werden im Regelfall von Kontributoren oder Sicherheitsexperten entdeckt und publik gemacht – entweder im Rahmen eines CVE, über GitHub oder andere (Community-)Plattformen. Für bekannte Schwachstellen gibt es möglicherweise sowohl Exploits als auch Patches.

Beispiele:

• CVE-2017-5638 in Apache Struts – führte zum Data Breach bei Equifax;

• CVE-2021-44228 in Apache Log4j – auch bekannt als Log4Shell.

Maßnahmen:

• Applikationen, Container und Systeme auf Open-Source-Abhängigkeiten mit bekannten Schwachstellen überprüfen;

• Scores und Metriken wie CVSS und EPSS einsetzen;

• Threat Intelligence einbinden;

• OSINT-Tools wie den KEV-Katalog der CISA nutzen;

• DAST- und SAST-Tools einsetzen.

2. Kompromittierte, legitime Packages

Laut OWASP haben es Angreifer im OSS-Bereich häufig auch auf legitime Projekte abgesehen – besser gesagt auf die Ressourcen innerhalb der Distributions-Infrastruktur. Um hier Schadcode einzuschleusen, verschafften sich Angreifer Zugang über Account Hijacking oder indem sie Schwachstellen in Package Repositories ausnutzten. Gelinge ihnen das, seien die Systeme aller nachgelagerten Benutzer und Organisationen gefährdet.

Beispiele:

• npm-Event-Stream-Incident;

• Supply-Chain-Attacke auf SolarWinds.

Maßnahmen:

• Aufkommende Standards und Frameworks wie das Secure Supply Chain Consumption Framework (S2C2F) von Microsoft nutzen, um mögliche Abwehrmaßnahmen zu eruieren;

• Die anzuwendenden Maßnahmen richten sich laut der Experten nach den individuellen Sicherheitsanforderungen und Risikobereitschaft der Organisation. Dazu können beispielsweise manuelle oder automatisierte Code Reviews zählen. Eine alternative Maßnahme ist, Komponenten nur aus einem extra abgesicherten, internen Store zu beziehen.

3. Name-Confusion-Angriffe

Bei Name-Confusion-Attacken schaffen Angreifer Komponenten, deren Nomenklatur der von legitimen Open-Source- oder Systemkomponenten (stark) ähnelt. Die von den Komponenten abhängige Software könne so mit Schadcode infiziert werden, warnen die Entscheider in OWASP-Diensten.

Beispiel:

• Typo-Squatting-Attacke “Colourama“

Maßnahmen:

• Code- und Projekt-Charakteristika auf Risikoindikatoren überprüfen;

• legitime Signatur der Komponenten verifizieren;

4. Nicht gewartete Software

Komponenten, die nicht mehr weiterentwickelt oder unterstützt werden, erhalten auch keine funktionalen und sicherheitstechnischen Updates mehr. Das kann laut den OWASP-Experten dazu führen, dass Downstream-Entwickler mit weniger Erfahrung und Wissen über diese Komponenten das Patch Management übernehmen müssen – was zusätzlichen Arbeitsaufwand erzeuge und in der Konsequenz auch erhöhte Wartungs-, respektive Ausfallzeiten nach sich ziehen könne.

Beispiele:

• core-js

• Gorilla Web Toolkit

• Minimist

Maßnahmen:

• Projekte darauf überprüfen, ob sie aktiv und gesund sind;

• Informationen zur Wartungs- und Support-Strategie des Projekts einholen;

• offizielle Projekt-Seite checken, um den Wartungsstatus zu ermitteln;

5. Veraltete Software

Einen weiteren bedeutenden Risikofaktor sieht OWASP darin, veralteten Komponentenversionen – obwohl entsprechende Updates zur Verfügung stehen. In Sachen Softwareaktualisierungen zurückzufallen, schaffe in Notfallsituationen zeitintensive Flaschenhälse. Falls die eingesetzte Software nicht mit der aktuellen Version kompatibel sei, führe das unter Umständen zu signifikanten Update- oder Migrationserfordernissen, so die Experten.

Beispiele:

• Spring Boot Support Time Frames

• Schwachstellen in Apache Tomcat

Maßnahmen:

• Rekurrierende Dependency Updates einplanen;

• Update-Management zum Beispiel durch Merge/Pull Requests automatisieren;

• Change Impact Analysis Tools nutzen.

6. Ungetrackte Abhängigkeiten

Situationen, in denen Entwickler respektive Organisationen die Abhängigkeiten von einer bestimmten Softwarekomponente erst gar nicht bewusst ist, hat das OWASP-Entscheider-Team ebenfalls auf dem Risiko-Ranking-Zettel. Dazu komme es beispielsweise, wenn solche Komponenten nicht Teil der SBOM sind, Software Composition Analysis (SCA)-Tools nicht eingesetzt werden oder nicht funktionieren wie sie sollen. Im Endeffekt blieben solche Komponenten außerhalb jeder Kontrolle.

Beispiele:

• Unvollständige SBOMs für Upstream-Komponenten;

• Drittanbieter-Code, der nicht ins Dependency Tracking eingebunden wird;

• Abhängigkeiten werden nicht durch Manifest Files oder Package Manager etabliert;

• IDE Plugins, Build Scripts, Test Dependencies und andere Dev-Tools hängen zwar nicht direkt mit der Software zusammen, stellen jedoch ebenfalls Risiken im Bereich Security und Operations dar.

Maßnahmen:

• SCA-Tools hinsichtlich ihrer Fähigkeiten evaluieren und vergleichen.

7. Lizenzrechtliche und regulatorische Unwägbarkeiten

In diesem Bereich sehen die OWASP-Experten Softwarekomponenten oder Projekte, die jegliche Lizenz vermissen lassen, jedoch mit lizenzrechtlichen Schwierigkeiten verbunden sind (etwa, wenn die Komponente an sich unter GPL-Lizenz steht, einzelne enthaltene Dateien jedoch unter die BSD-Lizenz fallen) oder mit existierenden gesetzlichen oder regulatorischen Regelungen in Konflikt stehen.

An dieser Stelle mahnt OWASP, ausschließlich auf Komponenten zu setzen, die in Sachen Lizenzrecht compliant sind. Anderenfalls könne das nicht nur rechtliche Konsequenzen nach sich ziehen, sondern sich auch negativ auf Mergers & Acquisitions auswirken und Unternehmen unter Umständen auch den Zugang zu bestimmten Märkten versperren.

Beispiel:

• Free Software Foundation vs. Cisco (PDF)

Maßnahmen:

• Geeignete Lizenzen für die vorgesehene Nutzung der Komponente innerhalb der sich in der Entwicklung befindlichen Software identifizieren;

• Open-Source-Lizenzbedingungen einhalten;

• Komponenten ohne Lizenz meiden;

• Komponenten-Dateien auf mehrere, respektive inkompatible Lizenzen prüfen.

8. Unausgereifte Software

Der Reifegrad von Open Source Software ist höchst unterschiedlich ausgeprägt. Ein Risiko stellt es laut OWASP dar, wenn keine standardisierte Versionierung zum Einsatz kommt, keine Regressionstests eingesetzt werden oder weder Guidelines noch Dokumentation existieren. In der Konsequenz sei es nicht zu gewährleisten, dass die betreffenden Softwarekomponenten zuverlässig und sicher sind. Das zahle wiederum auf operative Risiken ein, mache Software übermäßig komplex und könne zu Kostenexplosionen führen, warnt OWASP.

Maßnahmen:

• Tools wie OpenSSF Scorecard nutzen;

• Qualitätsindikatoren für Development Best Practices überprüfen (enthält das Projekt Test Code? Enthält das Code Repository eine Dokumentation?).

9. Nicht genehmigte Änderungen

Das OWASP-Team warnt darüber hinaus davor, dass sich Komponenten ohne Wissen der Entwickler verändern – etwa, weil ein Download-Link zu einer unversionierten Ressource führt, versionierte Ressourcen manipuliert wurden oder aufgrund unsicherer Datenübertragungen.

Beispiele:

• Codecov Bash Uploader;

• CVE-2021-26291 in Apache Maven.

Maßnahmen:

• Resource Identifier nutzen;

• Komponenten-Signaturen nach dem Download und vor der Installation verifizieren;

• Sichere Protokolle für Connections und Distribution verwenden, um MITM-Angriffe zu verhindern.

10. Abhängigkeits-Extreme

Die Experten weisen darauf hin, dass auch sehr kleine Softwarekomponenten, die nur aus einigen Zeilen Code bestehen, dieselben Risiken für die Supply Chain beinhalten können, wie größere. Diese wiederum beinhalteten oft zu viele Features, die gar nicht gebraucht werden – jedoch zur Vergrößerung der Angriffsfläche beitragen. Von den Sicherheitsrisiken abgesehen, könne das auch zu “Bloated Dependencies” führen, mahnen die Experten.

Beispiele:

• Apache Log4j

• npm Left-pad

Maßnahmen:

• Ungenutzte Komponenten-Features identifizieren und deren API-Zugriff prüfen – eventuell Alternativen ohne Overhead in Erwägung ziehen;

• Micro Packages im Blick behalten und deren Funktionalität bei Bedarf intern neu entwickeln.

(fm)

Sie wollen weitere interessante Beiträge rund um das Thema IT-Sicherheit lesen? Unser kostenloser Newsletter liefert Ihnen alles, was Sicherheitsentscheider und -experten wissen sollten, direkt in Ihre Inbox.

Jetzt CSO-Newsletter sichern

Dieser Beitrag basiert auf einem Artikel unserer US-Schwesterpublikation CSO Online.