CVE entschlüsseln: Ein praktischer Leitfaden zur Bewertung und Behebung von Sicherheitsrisiken

Zusammenfassung 

Entdecken Sie die Welt der Common Vulnerabilities and Exposures (CVEs) anhand von Schritt-für-Schritt-Beispielen, mit denen Sie prüfen können, ob eine CVE Ihr Projekt betrifft, sowie pragmatischen Strategien für eine wirksame Behebung. Dieser Leitfaden hilft Ihnen, Sicherheitslücken gezielt anzugehen. Lassen Sie CVE-Warnungen nicht unbeachtet – erfahren Sie, wie Sie souverän und effizient darauf reagieren.

Inhalt

Als Entwickler jonglieren wir ständig mit mehreren Projekten und müssen Fehlerbehebungen und Funktionserweiterungen priorisieren. Doch inmitten dieses hektischen Tempos stoßen wir immer wieder auf die beunruhigende Tatsache, dass unsere Projekte für Common Vulnerabilities and Exposures (CVEs) anfällig sein können. Die Zahl der gemeldeten CVEs steigt täglich und stellt uns vor die große Herausforderung, die Sicherheit unserer Projekte zu gewährleisten. Aber keine Sorge: Ich möchte Ihnen praktische Strategien vorstellen, mit denen Sie dieses Problem gezielt angehen können. In diesem Beitrag stelle ich verschiedene Ansätze vor, um die CVE-Prüfung nahtlos in Ihren Entwicklungs-Workflow zu integrieren. So können Sie Ihre Projekte mit Zuversicht schützen.

Ohne eine klare Strategie zur Behebung der CVEs kann uns die Zahl der täglich entdeckten CVEs schnell überfordern – insbesondere im Node.js-Ökosystem, in dem Anwendungen häufig sehr viele Abhängigkeiten haben. Ulises Gascón. Node.js für Einsteiger (Kapitel 15: Webanwendungen absichern)

Wie prüft man eine CVE?

Nehmen wir CVE-2020-8203 als Beispiel. Diese Prototype-Pollution-Schwachstelle betrifft die beliebte Bibliothek Lodash.

Je nachdem, welche Tools wir verwenden, um über Schwachstellen in unserem Projekt informiert zu werden, sehen wir möglicherweise unterschiedliche Berichte, die mehr oder weniger dieselben Informationen enthalten:

• Snyk-Bericht: SNYK-JS-LODASH-567746

• Github: GHSA-p6mc-m468-83gw

Wie Sie sehen, enthalten beide Abbildungen ähnliche Informationen (vor allem Metadaten) zur Schwachstelle. Die jeweilige Beschreibung liefert jedoch unterschiedliche Informationen, die unsere Analyse ergänzen können.

Schweregrad prüfen

Zunächst können wir anhand des Schweregrads unsere Arbeit priorisieren. Er basiert auf einer Skala von eins bis zehn. Zur Ermittlung des Werts kommt das Common Vulnerability Scoring System (CVSS) zum Einsatz. Die Bewertung ist außerdem aufgeschlüsselt und kann uns viele zusätzliche Kontextinformationen liefern. Wenn wir mehrere Schwachstellen prüfen müssen, sollten wir Patches nach ihrer Kritikalität priorisieren.

Je nach Informationsanbieter können die Ergebnisse unterschiedlich ausfallen. In der Abbildung unten sehen wir, dass Snyk einen Wert von 8,2 zuweist, während Red Hat und NVD 7,4 vergeben.

Es spielt keine Rolle, welchem Bewertungssystem Sie folgen, solange Sie es konsequent verwenden. Insgesamt sollten kritische oder schwerwiegende CVEs geprüft werden, während Schwachstellen mit einem niedrigeren Schweregrad möglicherweise mehr Zeit lassen.

Sobald eine CVE veröffentlicht wird, ist sie weltweit bekannt. Deshalb können Angreifer kritische CVEs leicht in ihr Arsenal aufnehmen und damit Systeme angreifen, wenn sich eine Gelegenheit dazu bietet.

Wenn Sie nicht wissen, wie schnell Angreifer handeln können, lesen Sie diesen Honeypot-Bericht.

Weitere Informationen einholen

Als Nächstes sollten wir möglichst viele Informationen über diese Schwachstelle und ihre potenzielle Ausnutzung sammeln. Manchmal finden Sie viele Informationen, wenn Sie die Links im Abschnitt „Referenzen“ auf der offiziellen CVE-Berichtsseite prüfen.

In diesem Fall können wir sogar den ursprünglichen Bericht auf HackerOne lesen und die Diskussion zwischen der meldenden Person und den Maintainerinnen und Maintainer verfolgen. Das kann uns viele Informationen liefern. Auch der Snyk-Bericht und der GitHub-Bericht enthalten hier hilfreiche Informationen.

Angriffsfläche klären

Nach dem vorherigen Schritt sollten wir wissen, welche Versionen der Bibliothek betroffen sind (>=4.1.0 <4.17.20) und welche Methoden im Umfang dieser Schwachstelle liegen (pick, set, setWith, update, updateWith und zipObjectDeep) – und im Hinterkopf behalten, dass es sich um eine Prototype-Pollution-Schwachstelle handelt.

Wir können das Repository kurz prüfen und feststellen, ob wir betroffen sind. Wenn wir diese Methoden nicht mit den genannten Versionen verwenden, können wir bestätigen, dass unser Code nicht betroffen ist und es sich in unserem Fall um einen False Positive handelt.

Diese Bewertung kann komplexer sein als erwartet. Im JavaScript-Ökosystem sind devDependencies in Entwicklungstools sehr verbreitet, haben aber keine tatsächlichen Auswirkungen auf die Produktionsumgebung – zum Beispiel Linter, Test-Frameworks oder bestimmte Hilfsprogramme. Das hängt stark von den Besonderheiten des jeweiligen Projekts ab. Wir können PM2 lokal verwenden, um eine Produktionsumgebung zu simulieren, aber Container und Kubernetes für das Deployment in der Produktionsumgebung einsetzen. Dadurch wird die Angriffsfläche für CVEs im Zusammenhang mit PM2 erheblich eingeschränkt, da wir PM2 in den meisten Fällen in einer „sicheren Umgebung“ ausführen, die wir vollständig kontrollieren. Denken Sie jedoch daran: Auch wenn ein Paket nicht in der Produktion verwendet wird, kann es sich bei einer Kompromittierung negativ auf unsere Entwicklungsumgebung auswirken. So wurde beispielsweise eslint 2018 kompromittiert.

Wenn wir keine klare Begründung dafür haben, dass diese Schwachstelle unser Projekt nicht betrifft, sollten wir davon ausgehen, dass wir potenziell betroffen sind, und eine geeignete Behebungsmaßnahme ergreifen.

Zusätzlich zu den Informationen in der Beschreibung können Sie mehr über die Angriffstechnik erfahren, indem Sie sich die in der CVE genannten Common Weakness Enumerations (CWEs) ansehen.

In diesem Fall wurde die CWE-1321: Improperly Controlled Modification of Object Prototype Attributes ('Prototype Pollution') genannt. Das hilft uns dabei, ähnliche CVEs zu finden und besser zu verstehen, wie sich die Schwachstelle ausnutzen lässt.

Einfach ausgedrückt: Die CWE ist eine Liste möglicher Schwachstellenarten, während die CVE eine Liste tatsächlich entdeckter Sicherheitslücken umfasst. Ulises Gascón. Node.js für Einsteiger

Gibt es einen ausnutzbaren POC?

Nicht alle CVEs enthalten einen Proof of Concept (POC) für die gemeldete Schwachstelle, der sich leicht ausnutzen lässt. In diesem Fall gibt es jedoch einen eindeutigen POC:

const _ = require('lodash');
_.zipObjectDeep(['__proto__.z'],[123]);
console.log(z); // 123

Dieser hilft uns nicht nur, das Problem besser zu verstehen, sondern auch unseren Code zu testen und die Schwachstelle eindeutig zu bestätigen. Nehmen wir an, unsere Anwendung enthält den folgenden Code:

const _ = require('lodash');

const normalizeData = (users, ages) => {
    return _.zipObjectDeep(users,ages);
}

module.exports = { normalizeData }

Wir können leicht annehmen, dass der Code für einen Prototype-Pollution-Angriff anfällig ist. Wir können aber auch einen Test erstellen, um sicherzustellen, dass wir über Mechanismen verfügen, die solche Schwachstellen künftig verhindern. Manchmal führen Bibliotheken Änderungen ein, die Regressionen und damit Schwachstellen verursachen. Mit einem einfachen Test wie dem folgenden können wir das verhindern:

const { normalizeData } = require('../utils');

describe('normalizeData behaviour', () => {
    it('should return the data structured properly', () => {
        const users = ['John', 'Doe'];
        const ages = [30, 40];
        const result = normalizeData(users, ages);
        expect(result).toEqual({ John: 30, Doe: 40 });
    });
    it('should not be affected by a prototype pollution (CVE-2020-8203)', () => {
        normalizeData(['__proto__.z'], [123]);
        expect(global.z).toBe(undefined);
    });
});

Dieser Test wird erwartungsgemäß fehlschlagen, da unser Code derzeit für diese Prototype Pollution anfällig ist und wir in unserem Projekt keine Änderungen zur Behebung vorgenommen haben.

Abbildung: mit Node.js@21 und lodash@4.17.0

Sehen wir uns nun an, wie wir diese Schwachstelle beheben können.

Strategien zur Risikominderung bei einer CVE

Es gibt verschiedene Strategien zur Behebung einer CVE. Wir stellen einige davon vor, geordnet nach dem erforderlichen Aufwand.

Versionen aktualisieren oder zurücksetzen

Die empfohlene Methode zur Behebung einer CVE ist, die betroffene Bibliothek zu aktualisieren. In diesem Fall können wir auf lodash@4.17.20 oder höher aktualisieren. Das ist häufig die beste Methode, da die Maintainer der Bibliothek eine Fehlerbehebung bereitstellen, die auch gemeinsam mit der meldenden Person getestet wurde. So können wir sicher sein, dass der Patch funktioniert.

Wenn wir diesen Patch anwenden (npm i lodash@4.17.20), können wir den zuvor erstellten Test erneut ausführen und sicherstellen, dass die Schwachstelle behoben ist.

Abbildung: mit Node.js@21 und lodash@4.17.21

Das klingt nach einer einfachen Aufgabe, kann aber sehr komplex werden. Möglicherweise müssen wir andere Abhängigkeiten aktualisieren oder zurücksetzen, die mit der neuen Bibliotheksversion nicht kompatibel sind. Oder die neuere Version der Bibliothek enthält weitere Änderungen, die nicht mit unserem Code kompatibel sind.

Manchmal wird eine CVE veröffentlicht, bevor ein Patch verfügbar ist. Dann müssen wir andere Strategien zur Behebung der Schwachstelle prüfen, bis der endgültige Patch bereitsteht.

Migrieren

Wird die Bibliothek nicht mehr gepflegt oder stellen die Maintainer keinen Patch für die Schwachstelle bereit, müssen wir möglicherweise zu einer anderen Bibliothek mit gleicher oder ähnlicher Funktionalität migrieren. Das ist zwar mit erheblichem Aufwand verbunden, kann sich aber lohnen, wenn die neue Bibliothek sicherer ist und besser gepflegt wird als die bisherige.

So können wir sicherstellen, dass wir künftig weniger CVEs prüfen müssen und Aktualisierungen einfacher verwalten können.

Manueller Patch (DIY)

Wenn wir die Bibliothek weder aktualisieren noch zu einer anderen migrieren können, müssen wir möglicherweise selbst einen Patch erstellen. Das ist auch eine sinnvolle Strategie, wenn die CVE vor Veröffentlichung des Patches bekannt wird und wir die Schwachstelle so schnell wie möglich beheben müssen, während wir auf den offiziellen Patch warten.

Jeder manuelle Patch setzt voraus, dass wir die Bibliothek und die Schwachstelle gut verstehen. Wir können den im CVE-Bericht bereitgestellten POC nutzen, um einen eigenen Patch zu erstellen, und mit dem bereits erstellten Test überprüfen, ob er funktioniert. Sehen wir uns an, wie wir einen Patch für diese Schwachstelle erstellen können:

const _ = require('lodash');

const normalizeData = (users, ages) => {
    const safeUsers = users.filter(user => !/__proto__|prototype|constructor/.test(user));
    return _.zipObjectDeep(safeUsers, ages);
}

module.exports = { normalizeData }

Dieser einfache Patch veranschaulicht, wie sich die Schwachstelle beheben lässt. Für eine bessere Compliance sollten Sie jedoch den offiziellen Patch prüfen, da unser Testfall sehr grundlegend war. Wir können den Test jetzt erneut ausführen und sicherstellen, dass die Schwachstelle behoben ist.

Abbildung: mit Node.js@21 und lodash@4.17.0 sowie dem Patch

Strategien zur Dokumentation von Entscheidungen zu CVEs

Bei der Zusammenarbeit im Team ist es wichtig, unsere Entscheidungen zu CVEs zu dokumentieren. So können wir nachverfolgen, welche Schwachstellen behoben wurden und bei welchen die Behebung noch aussteht. Das hilft uns, die Arbeit zu priorisieren und sicherzustellen, dass wir keine Schwachstelle übersehen.

Mit einer einfachen Tabelle können wir die geprüften CVEs, ihren Schweregrad und Status, die Behebungsstrategie sowie das Datum der Behebung dokumentieren. So behalten wir im Blick, welche Schwachstellen behoben wurden und bei welchen die Behebung noch aussteht.

Diese Tabelle lässt sich nach jeder CVE-Prüfung aktualisieren und mit dem Team teilen. So stellen Sie sicher, dass alle über die bestehenden und behobenen Schwachstellen informiert sind.

Noch besser: Sie können diese Tabelle in die Projektdokumentation aufnehmen, damit sie Teil des Code-Distributionsprozesses ist.

Wenn Sie ein Tool zur Prüfung von CVEs verwenden, kann es schwierig sein, den Status einer als False Positive eingestuften CVE oder einer manuell behobenen Schwachstelle richtig festzuhalten. Wenn Sie beispielsweise Snyk verwenden, können Sie die CVE als ignoriert markieren.

Wenn Sie in unserem Fall den manuellen Patch verwendet haben, können Sie die CVE im Snyk-Bericht wie folgt als ignoriert markieren: snyk ignore --id=SNYK-JS-LODASH-567746 --reason="manual patch in place with tests".

Dadurch wird der folgende Inhalt in der Datei .snyk erstellt:

# Snyk (https://snyk.io) policy file, patches or ignores known vulnerabilities.
version: v1.25.0
# ignores vulnerabilities until expiry date; change duration by modifying expiry date
ignore:
  SNYK-JS-LODASH-567746:
    - '*':
        reason: manual patch in place with tests
        expires: 2024-05-15T17:27:20.339Z
        created: 2024-04-15T17:27:20.340Z
patch: {}

Insgesamt ist für diesen Prozess etwas manuelle Arbeit erforderlich. Die Zusammenarbeit im Team ist sehr empfehlenswert, um Voreingenommenheit und menschliche Fehler so weit wie möglich zu vermeiden.

Checkliste

Zusammenfassend sind bei der Prüfung einer CVE die folgenden Schritte erforderlich:

1.  Schweregrad der CVE prüfen

2.  Weitere Informationen zum Angriffsvektor einholen

3.  Angriffsfläche klären

4. Prüfen Sie, ob es einen ausnutzbaren POC gibt

5. Bewerten Sie die Auswirkungen auf Ihr Projekt

6. Beheben Sie die Schwachstelle bei Bedarf

7. Dokumentieren Sie die Entscheidungen zu den CVEs

8. Teilen Sie die Schlussfolgerungen mit Ihrem Team

Weitere Ressourcen

Wenn Sie weitere Themen rund um die Sicherheit in Node.js erkunden möchten, lesen Sie mein Buch Node.js für Einsteiger. Darin behandle ich zahlreiche Themen rund um die Sicherheit in Node.js.