Die häufigsten Schwachstellen in Maven Central und npm

Die vollständige Version dieses Blogbeitrags wurde ursprünglich von Snyk als Gastbeitrag im Cloud Foundry Blog veröffentlicht.

In diesem Beitrag werfen wir einen Blick auf die häufigsten Arten von Schwachstellen in zwei der wichtigsten Ökosysteme, die wir in unserer Schwachstellendatenbank erfassen: Maven Central und npm. Die Snyk Vulnerability Database umfasst Schwachstellen in über 1.000.000 Open-Source-Paketen, die wir erfassen und die Composer, Go, Maven Central, npm, NuGet, pip und Rubygems verwenden.

2017 erreichte die Zahl der in unseren erfassten Ökosystemen veröffentlichten Schwachstellen einen Höchststand und stieg gegenüber 2016 um 83 Prozent. Wir können sehen, welche Arten von Schwachstellen in den beiden wichtigsten Ökosystemen am häufigsten auftraten. Darum geht es in diesem Beitrag.

In unseren Beiträgen im April und Mai gehen wir näher auf einige dieser Schwachstellen ein und zeigen, wie sie ausgenutzt werden können.

JavaScript (npm)

1. Directory Traversal – Beispiel: das Paket st.

Die häufigste Schwachstelle im npm-Ökosystem ist Directory Traversal. Diese Schwachstelle tritt typischerweise auf, wenn ein relativer Verzeichnispfad angegeben, aber nicht validiert wird. Ohne Validierung kann der übergebene relative Pfad auf ein übergeordnetes Verzeichnis verweisen und so den Zugriff auf sensible Daten ermöglichen. Ein häufig verwendeter Ansatz, um einen Exploit auszuführen, ist beispielsweise die Verwendung von HTML-Entitäten, bei denen „.“ durch „%2E“ dargestellt wird. In solchen Fällen führt eine Anfrage an die folgende URL /%2E%2E/%2E%2E/%2E%2E/etc/password dazu, dass /etc/passwd offengelegt wird.

2. Ressourcen-Download über ein unsicheres Protokoll – Beispiel: Chromedriver.

Diese Schwachstelle ermöglicht Angreifern einen Man-in-the-Middle-Angriff (MitM). Werden Ressourcen über ein unsicheres Protokoll heruntergeladen, kann ein Angreifer die Verbindung abfangen und die empfangenen Pakete verändern.

3. Cross-Site-Scripting (XSS) – Beispiel: das handlebars-Paket.

XSS-Angriffe treten auf, wenn ein Angreifer den Browser eines Nutzers dazu bringt, schädlichen JavaScript-Code in der Umgebung des Opfers auszuführen. Solche Skripte können Sitzungscookies des Nutzers für die Domain stehlen, eingegebene Passwörter oder Kreditkartendaten auslesen, Inhalte auslesen oder verändern sowie Aktionen im Namen des Nutzers ausführen oder verändern. Diese Aktionen würden normalerweise durch die Same-Origin-Policy des Browsers blockiert. Weitere Informationen finden Sie unter XSS-Angriffe: die nächste Welle.

Maven Central

1. Denial of Service (DoS) – Beispiel: der Jackson-Datenprozessor.

Ein Denial-of-Service-Angriff erschöpft die Ressourcen der Backend-Server und beeinträchtigt dadurch weitere Nutzeranfragen. Dies geschieht häufig durch eine hohe CPU-Auslastung, kann aber auch durch das Füllen von Festplatten, Arbeitsspeicher oder anderen Ressourcen verursacht werden.

2. Ausführung beliebigen Codes – Beispiel: die Apache-Struts-Bibliothek.

Bei der Ausführung beliebigen Codes wird schädlicher Code auf einem anfälligen Server ausgeführt. Häufig ruft dieser Code Befehle auf dem entfernten Computer auf. Oft ist eine andere Schwachstelle die Ursache, beispielsweise eine Deserialisierungsschwachstelle wie im Fall von Struts.

3. Cross-Site-Scripting (XSS) – Beispiel: Jenkins-CI-Server-Plugin.

Eine Beschreibung von XSS finden Sie oben im Abschnitt zu npm.

Weitere häufige Schwachstellen in diesen Ökosystemen finden Sie in unserem vollständigen Beitrag im Cloud Foundry Blog.