Wie Snyk Social Trends Ihnen helfen, kritische Sicherheitslücken zu beheben

Kürzlich hat Snyk Social Trends zu seinen Schwachstellendaten hinzugefügt. Dieser neue Indikator zeigt Ihnen, welche Sicherheitslücken gerade im Trend liegen, damit Sie deren Behebung besser priorisieren können. Unser Forschungsteam hat eine starke Korrelation zwischen Sicherheitslücken, die in sozialen Medien im Trend liegen, und dem Vorhandensein von Exploits festgestellt, die Ihrer Anwendung tatsächlich schaden können.

Die Trends bei Sicherheitslücken in sozialen Medien zu verfolgen, ist durchaus sinnvoll. Wenn eine bestimmte Sicherheitslücke in sozialen Medien – etwa auf Twitter – viel Aufmerksamkeit erhält, bedeutet das, dass viele Menschen von dem Problem wissen. Statistisch gesehen heißt das auch, dass mehr Menschen Ihnen schaden wollen. Deshalb kann es wichtig sein, den Sicherheitslücken in Ihrem System, die in sozialen Medien im Trend liegen, besondere Aufmerksamkeit zu schenken.

Sehen wir uns Snyk Social Trends (Sentiment-Analyse zu Sicherheitslücken) in der Praxis an.

Ein aktuelles Beispiel aus Java

Ich habe eine kleine Java-Anwendung auf Basis einer veralteten Spring-Boot-Version erstellt: 2.2.0-RELEASE. Nachdem ich das GitHub-Repository mit meinem Snyk-Konto verbunden hatte, fand ich die folgende Sicherheitslücke ganz oben in meiner Liste, weil sie derzeit in sozialen Medien im Trend liegt.

Es handelt sich um eine Sicherheitslücke zur Remote Code Execution (RCE) in der eingebetteten Apache-Tomcat-Version, die im verwendeten Spring-Boot-Starter-Paket enthalten ist. Als ich auf die Schaltfläche für Trends klickte, fand ich zahlreiche Tweets zu dieser konkreten Sicherheitslücke sowie einen veröffentlichten, funktionierenden Exploit. Darauf komme ich später zurück. Zunächst möchte ich die Sicherheitslücke erklären.

Die Sicherheitslücke CVE-2020-9484 zur Remote Code Execution erklärt

Ich erkläre kurz, wie diese RCE-Sicherheitslücke in Tomcat funktioniert. Sie besteht in allen Tomcat-Versionen, auch in der mit Spring Boot bereitgestellten eingebetteten Version. Wichtig ist auch, dass für alle Versionen bereits ein Update verfügbar ist, das das Problem behebt.

Angenommen, Sie verwenden in Tomcat den PersistentManager mit einem FileStore. Der PersistentManager verwaltet die Sitzung. Eine Sitzung dient dazu, den Status zwischen den Anfragen des Clients an den Server beizubehalten. Standardmäßig verwendet Tomcat den StandardManager, der Sitzungen im Arbeitsspeicher hält. Der PersistenManager hingegen lagert Sitzungen in einen Speicher aus, wenn sie einige Sekunden lang inaktiv sind. Das kann eine Festplatte mit dem FileStore oder eine Datenbank mit dem JDBCStore sein.

Mit dem FileStore speichert Tomcat Sitzungen an einem vordefinierten Speicherort unter dem Namen <JSESSIONID>.session. Ist eine neue Anfrage mit einer Sitzungs-ID nicht im Arbeitsspeicher vorhanden, sucht der PersistentManager auf der Festplatte nach gespeicherten Sitzungen und deserialisiert das gespeicherte Sitzungsobjekt in den Arbeitsspeicher, wenn er es findet.

Was aber, wenn meine Sitzung beispielsweise JSESSIONID=../../../../../../../foo/mysession lautet? Aufgrund des Path Traversal sucht Tomcat im Verzeichnis foo nach mysession.session. Wenn ich aus irgendeinem Grund eine Datei auf dieses System hochladen kann, kann ich eine serialisierte Sitzungsdatei hochladen. Anschließend kann ich die Deserialisierung auslösen, indem ich meine JSESSIONID auf den entsprechenden Speicherort setze. Je nach serialisiertem Objekt kann die Deserialisierung eine schädliche Remote Code Execution auslösen.

Wenn Sie wissen möchten, warum Deserialisierungs-Sicherheitslücken gefährlich sind, lesen Sie bitte den Blogbeitrag Serialisierung und Deserialisierung in Java: Die Java-Deserialisierungs-Sicherheitslücke erklärt.

Weitere Informationen zu dieser Sicherheitslücke in Tomcat finden Sie in einem ausführlichen Artikel auf redtimmy.com. Einen Proof of Concept für den Exploit finden Sie in diesem GitHub-Repository:  https://github.com/masahiro331/CVE-2020-9484

Wie Snyk Social Trends Ihnen helfen, sich auf das Wesentliche zu konzentrieren

Sie könnten einwenden, dass es einige Voraussetzungen gibt, bevor diese Sicherheitslücke tatsächlich ausgenutzt werden kann.

1. PersistentManager muss mit dem FileStore aktiviert sein

2. Angreifer müssen beliebige Dateien hochladen können

3. Für den Deserialisierungsangriff muss ein Gadget im Klassenpfad verfügbar sein

Manche könnten die Sicherheitslücke wegen dieser Voraussetzungen als kaum ausnutzbar abtun. Doch angesichts der großen Aufmerksamkeit auf Twitter habe ich genauer hingesehen und festgestellt, dass es gar nicht so schwer war, den Sitzungsmanager auf den PersistentManger mit FileStore umzustellen. Und angesichts der vielen Abhängigkeiten meiner Anwendung ist es durchaus möglich, dass sich darin ein Gadget befindet.

Wenn also jemand in meinem Team aus irgendeinem Grund den PersistentManger mit FileStore verwendet, fehlen nur noch Uploads beliebiger Dateien. Da Sicherheitsvorfälle fast immer durch eine Kette von Ereignissen entstehen, die in einer Katastrophe münden – und nicht durch ein einzelnes Ereignis oder eine einzelne Sicherheitslücke –, sollte man eine solche Sicherheitslücke nicht einfach abtun. Vor allem dann nicht, wenn es bereits eine Behebung gibt.

Noch wichtiger: Liegt eine Sicherheitslücke im Trend, wissen viele Menschen davon und sprechen darüber – auch Menschen mit bösen Absichten. Für mich ist das ein Signal, eine solche Sicherheitslücke noch genauer zu untersuchen, als ich es ohnehin tue, um festzustellen, ob ich jetzt oder künftig gefährdet bin.

Der Trendindikator in der Snyk-Benutzeroberfläche rückt die Sicherheitslücke nicht nur ins Blickfeld, sondern erhöht aus diesem Grund auch ihren Prioritätswert. Wir sind daher überzeugt, dass die Suche in sozialen Medien nach der Popularität bestimmter Sicherheitslücken ein wirkungsvolles Mittel ist, damit mir keine offensichtlichen und weithin bekannten Sicherheitsfehler entgehen. Wenn Sie also ein Trend-Tag sehen, empfehlen wir Ihnen, eine Sicherheitslücke, die Sie bisher vielleicht ignoriert haben, noch einmal genauer zu prüfen.