Was ist an Exploits in freier Wildbahn so brisant – und wie können wir entsprechend priorisieren?

Nicht alle Schwachstellen sind gleich.Auch wenn Sie eine Open-Source-Schwachstelle niemals ignorieren sollten, kann es eine Weile dauern, bis manche davon ausgenutzt werden können, um Ihr System anzugreifen. Andere bekannte Schwachstellen stellen dagegen tatsächlich ein großes und unmittelbares Risiko dar.

In einer Welt mit stetig zunehmenden Schwachstellen ist es schwierig, sie alle schnell genug zu finden und zu beheben. Angesichts der schieren Anzahl ist anzunehmen, dass viele Maintainer schon aufgeben, bevor sie überhaupt richtig angefangen haben.

Um die verschiedenen Schwachstellen voneinander abzugrenzen und zu priorisieren, sollten wir das jeweilige Risiko bewerten, festlegen, welches Mindestrisiko wir angehen möchten, und dann dort beginnen.

Einer der wichtigsten Risikofaktoren ist, wie einfach sich eine bestimmte Schwachstelle ausnutzen lässt. Wenn jemand demonstriert, wie eine Schwachstelle ausgenutzt werden kann, nennt man das einen Exploit. Wird der Exploit über Quellen wie Blogbeiträge, Foren, exploit-db oder Exploit-Frameworks wie metasploit weithin veröffentlicht, spricht man häufig von einem Exploit in freier Wildbahn.

Nur ein kleiner Prozentsatz der bekannten Schwachstellen wird ausgenutzt, also tatsächlich für einen Angriff auf ein System verwendet. Schwachstellen mit dem höchsten Risiko werden mit größerer Wahrscheinlichkeit ausgenutzt und sollten daher zuerst priorisiert und behoben werden, wie in der Grafik dargestellt:

In diesem Beitrag erläutern wir, wie Exploits in freier Wildbahn das Risiko erhöhen, wie wir dieses Risiko bewerten und wie Sie Ihre Schwachstellen entsprechend priorisieren und schnell beheben können.

Apache Struts: Ein Exploit in freier Wildbahn führte zu einem realen Angriff

Wahrscheinlich haben Sie schon vom Datenleck bei Equifax gehört. Bei dem bekannten Anbieter von Bonitätsbewertungen wurden hochsensible persönliche Daten von 145,5 Millionen Kundinnen und Kunden offengelegt. Ursache des Datenlecks war eine bekannte Schwachstelle in einem Apache-Struts-Paket, zu der Exploits in freier Wildbahn veröffentlicht worden waren – nur wenige Tage vor dem Angriff. Dank des verfügbaren Exploit-Codes konnten Hacker später in die Systeme von Equifax eindringen. Der Angriff erfolgte zwei Monate nach der Veröffentlichung des Exploits – mit verheerenden Folgen. Die Angriffe auf Apache Struts sehen Sie in der folgenden Zeitleiste:

Was bedeutet Exploit-Code-Reife und wie beeinflusst sie das Risiko einer Schwachstelle?

Mit der Reife von Exploit-Code (kurz: Exploit-Reife) messen wir, wie praktikabel eine Schwachstelle in der realen Welt tatsächlich ist. Dabei betrachten wir:

• Ob der Exploit veröffentlicht wurde (also „in freier Wildbahn“ ist); und

• wie nützlich die veröffentlichten Exploits tatsächlich sind – also, ob sich die Schwachstelle dadurch leichter ausnutzen lässt.

Anders ausgedrückt: Wenn es überhaupt keinen Exploit gibt, lässt sich eine Schwachstelle wahrscheinlich schwieriger ausnutzen. Gleichzeitig bedeutet ein verfügbarer Exploit auch nicht zwangsläufig, dass die Schwachstelle weiterhin leicht ausgenutzt werden kann.

Faktoren, die das Risiko eines veröffentlichten Exploits beeinflussen

In diesem Beitrag betrachten wir zwei Faktoren, die die Reife von Exploit-Code beeinflussen.

Faktor I: Wie praktikabel ist es, diese Schwachstelle auszunutzen?

Der erste Faktor ist, ob und wie groß die Lücke zwischen akademischer Theorie und praktischer Umsetzung ist. Um die Risiken eines Exploits in freier Wildbahn zu verstehen, sollten wir prüfen, ob er:

• praktikabel ist und sich in der realen Welt einsetzen lässt oder derzeit nur theoretisch möglich ist; und

• ob er in allen Fällen anwendbar oder durch bestimmte Bedingungen eingeschränkt ist

Ein Exploit, der nur theoretisch beschrieben wurde, stellt möglicherweise ein weitaus geringeres Risiko dar als ein veröffentlichter, getesteter und erprobter Exploit. Ebenso ist das Risiko eines Exploits, der nur auf 1 % der Fälle anwendbar ist, in denen die Schwachstelle auftritt, deutlich geringer als das eines Exploits, der zeigt, wie sich die Schwachstelle unabhängig von den Umständen leicht ausnutzen lässt.

Faktor II: Welche Fachkenntnisse sind erforderlich?

Der zweite Faktor ist das erforderliche Fachwissen, um die Schwachstelle tatsächlich auszunutzen. Muss man ein erfahrener Hacker sein, um diese Schwachstelle auszunutzen, oder können das auch Einsteigerinnen und Einsteiger? Je einfacher die Anwendung ist, desto wahrscheinlicher ist es, dass jemand sie nutzt.

Mit diesem Hintergrund lässt sich leichter nachvollziehen, warum veröffentlichte Exploits häufig mit Schwachstellen in Verbindung stehen, die schließlich tatsächlich ausgenutzt werden. Kein Wunder also, dass diese Studie zeigt: Ist ein Exploit öffentlich verfügbar, wird die Schwachstelle mit viermal höherer Wahrscheinlichkeit tatsächlich ausgenutzt. Weitere Studien gehen sogar davon aus, dass die Veröffentlichung eines Exploits das Risiko um das Siebenfache erhöht!

Warum brauchen wir Exploit-Reife, wenn es bereits CVSS gibt?

Das Common Vulnerability Scoring System (CVSS-Score) berücksichtigt bei der Berechnung bereits mehrere Risikofaktoren, darunter die Reife des Codes. Damit wird gemessen, ob relevanter öffentlicher Exploit-Code verfügbar ist. Da die Zahl bekannter Schwachstellen jedoch exponentiell wächst, spiegelt das umfassende Bewertungssystem nicht immer das tatsächliche Risiko – oder dessen Fehlen – einer bestimmten Schwachstelle wider. In seinem Blogbeitrag Anfang des Jahres stellte Liran Tal fest, dass der CVSS-„Schwachstellen-Score zwar von einer anerkannten Stelle festgelegt wird, das komplexe System aber aus mehr als einem Dutzend wichtiger Merkmale besteht. Ohne angemessene Anleitung, Erfahrung und unterstützende Informationen passieren leicht Fehler.“

Die Priorisierung nach Exploit-Reife ist nicht nur sinnvoll, sondern auch effektiv

Wenn wir gezielt nach Exploit-Reife priorisieren, können wir die risikoreichsten Schwachstellen effektiv identifizieren und die priorisierte Auswahl auf etwa 10 % der Gesamtzahl eingrenzen. Bei Snyk-Kunden ist für nur 4–12 % der Schwachstellen ein ausgereifter Exploit verfügbar. Dieser Anteil variiert je nach Ökosystem (siehe Tabelle unten). Das deckt sich mit weiteren Zahlen, etwa der hier zu findenden Statistik, der zufolge für 5,5 % der veröffentlichten Schwachstellen Exploits bekannt sind, die in freier Wildbahn beobachtet wurden. 

Der Anteil ausnutzbarer Schwachstellen an allen Schwachstellen kann je nach Ökosystem und Paketnutzung variieren. Die Tabelle unten zeigt Durchschnittswerte bei Snyk-Kunden für ausgewählte wichtige Ökosysteme: 

Sollten wir auch andere Schwachstellen beheben? Natürlich. Jede Schwachstelle birgt ein Risiko – manche mehr als andere – und es gibt viele weitere Möglichkeiten zur Priorisierung, die wir künftig vorstellen werden. Entscheidend ist: Da jede Schwachstelle ein Risiko darstellt, müssen wir bei der Priorisierung wachsam sein. Am besten beginnen Sie mit der Bewertung der Exploit-Code-Reife.

Wie finde ich heraus, für welche meiner Schwachstellen Exploits in freier Wildbahn verfügbar sind?

Um unsere Nutzerinnen und Nutzer zu unterstützen und zu schützen, ermöglichen wir ihnen jetzt, die in ihren Projekten erkannten Schwachstellen nach Exploit-Reife zu priorisieren!

Auf Grundlage unserer Forschung und von CVSS haben wir drei Kategorien festgelegt:

• Ausgereift: Für diese Schwachstelle ist ein veröffentlichter Exploit-Code verfügbar, der sich leicht einsetzen lässt.

• Proof of Concept: Es gibt einen veröffentlichten theoretischen Proof of Concept oder eine detaillierte Erklärung, die zeigt, wie sich diese Schwachstelle ausnutzen lässt.

• Kein bekannter Exploit: Für diese Schwachstelle wurde weder Proof-of-Concept-Code noch ein Exploit gefunden oder beides ist nicht öffentlich verfügbar.

In der Projektansicht Ihrer Schwachstellen sehen Sie jetzt, ob eine bestimmte Schwachstelle einen Exploit in freier Wildbahn aufweist. Sie können Ihre Scan-Ergebnisse außerdem filtern und priorisieren, anschließend die Schwachstellen entsprechend beheben und einen zusammenfassenden Bericht aufrufen. So können Sie zuerst die wichtigsten und risikoreichsten Schwachstellen priorisieren und beheben.

Legen Sie jetzt los!

Der Einstieg ist ganz einfach:

1. Melden Sie sich bei Snyk an und öffnen Sie für eines Ihrer Projekte die Detailseite Projects:

2. Links finden Sie die neuen Filter:

3. Klicken Sie auf Ausgereift, um die risikoreichsten Schwachstellen anhand der Exploit-Reife anzuzeigen. Anschließend können Sie mit der Behebung beginnen.

Weitere Informationen finden Sie in unserer Dokumentation.

Wie geht es weiter?

Nachdem wir die Möglichkeit eingeführt haben, nach Exploit-Reife zu priorisieren, werden wir weitere Methoden zur Priorisierung der Schwachstellenbehebung vorstellen, um unsere Nutzerinnen und Nutzer dabei zu unterstützen, ihre Abhängigkeiten wirksam zu schützen.