Wie angreifbar ist die „unsicherste“ Docker-Anwendung wirklich?

Das JFrog-Security-Research-Team analysierte die Ausnutzbarkeit von Schwachstellen anhand der bewusst unsicher konzipierten Docker-Anwendung „WebGoat“. Bereits die frühere Untersuchung der Ausnutzbarkeit von CVEs in den wichtigsten Docker-Hub-Images durch das JFrog-Security-Research-Team ergab, dass 78 Prozent der gemeldeten CVEs tatsächlich nicht ausnutzbar waren. Dieses Mal nutzten die Sicherheitsforscher das Xray-Contextual-Analysis-Feature, das automatisch die Anwendbarkeit der gemeldeten CVEs analysiert, um Webgoat zu scannen – eine absichtlich unsichere Anwendung, die es interessierten Entwicklern ermöglicht, Schwachstellen zu testen, die häufig in Java-basierten Anwendungen gefunden werden, die allgemeine und beliebte Open-Source-Komponenten verwenden.

 

Die wichtigsten Scan-Ergebnisse

Nachdem das Webgoat Docker-Image mit einem kontextbasierten Analyseprogramm gescannt wurde, kam zum Vorschein, dass von den 60 CVEs, die mit einem Critical-CVSS-Score gemeldet wurden, nur 10 tatsächlich ausnutzbar sind. Dieses exemplarische Scan-Ergebnis verdeutlicht, wie Contextual-Analysis basierte Sicherheitsanalysen Application-Security- und Sicherheitsteams dabei unterstützen kann, sich vorranging auf tatsächlich ausnutzbare CVEs zu konzentrieren und die Behandlung von CVEs, die nicht ohne weiteres ausnutzbar sind, hintanzustellen.

 

Analysieren der als anwendbar gemeldeten CVEs

Zunächst erfolgte die Analyse der 10 kritischen CVEs, die von den Ergebnissen der Kontextanalyse als anwendbar gemeldet wurden. Die Ausnutzbarkeitsbedingungen für diese 10 CVEs werden von der Kontextanalyse in diesem Docker-Image bestätigt. Das bedeutet, dass sie höchstwahrscheinlich von Black-Hat-Hackern angegriffen und ausgenutzt werden, so wie es in dieser Untersuchung durch die White-Hat-Hacker getan wurde.

 

Technischer Hintergrund von CVE-2013-7285

Eine besonders bemerkenswerte gemeldete CVE hierbei ist eine Befehlsinjektion in XStream für Java, die die Ausführung von Remotecode ermöglicht, wenn manipulierte XML- oder JSON-Daten deserialisiert werden. Um diese Schwachstelle auszunutzen, muss ein Angreifer in der Lage sein, beliebige Eingaben an die Funktion `xstream.fromXML()` zu übermitteln. Eine Installation von XStream in der verwundbaren Version reicht nicht aus, um diese Sicherheitslücke erfolgreich auszunutzen. Die Scan-Ergebnisse der Kontextanalyse des Webgoat-Abbilds helfen zu verstehen, ob diese Sicherheitsanfälligkeit kontextbezogen anwendbar ist. Ein zutreffendes Ergebnis der Kontextanalyse bedeutet, dass es eine verwundbare Verwendung von XStream in der Anwendung gibt, oder mit anderen Worten, die verwundbare Funktion `fromXML()` wird mit externer Eingabe aufgerufen. Wie die Ergebnisse zeigen, ist diese Schwachstelle anwendbar und sollte daher als ernstes Problem behandelt werden, das von Angreifern ausgenutzt werden kann. In den Untersuchungen konnte diese Schwachstelle erfolgreich ausgenutzt werden, indem ein bösartiges deserialisiertes Objekt als Parameter an diese Funktion übergeben wurde und so eine Remotecodeausführung durchgeführt werden konnte.

 

CVE-2022-22965 (SpringShell)

Eine weitere sehr bedeutsame gemeldete CVE ist die berühmte SpringShell – eine Schwachstelle in Spring Web, die zur Remotecodeausführung führt. Um diese Schwachstelle auszunutzen, muss ein Angreifer einen exponierten Web-Endpunkt finden, der Anfrageparameter an POJOs (Plain Old Java Objects) bindet. Die Schwachstelle liegt im „Datenbindungs“-Mechanismus von Spring-Framework. Dieser Mechanismus übernimmt Parameter aus der Anfrage-URL oder dem Anfragekörper und weist sie Funktionsargumenten oder in einigen Fällen Java-Objekten zu.

 

Analysieren der als „nicht ausnutzbar“ gemeldeten CVEs

Kontextuelle Scanner laufen auf ihrer konservativsten Einstellung, was eine Anwendbarkeitserkennung mit extrem hohem Vertrauen für Schwachstellen ermöglicht, die als nicht anwendbar gekennzeichnet sind. Die Möglichkeit, die Anzahl der zu untersuchenden Schwachstellen automatisch zu reduzieren, ist ein entscheidender Vorteil. Diese Fähigkeit hilft Sicherheitsingenieuren, Schwachstellen auf der Grundlage ihrer Ausnutzbarkeit und nicht nur ihres Schweregrads zu priorisieren und bei Bedarf sogar zu ignorieren.

 

Fazit

Die Scanergebnisse der Sicherheitsforscher zeigen, dass nur 10/60 kritische CVEs, die kontextuell analysiert wurden, tatsächlich ausnutzbar sind. Dies ist recht überraschend, wenn man bedenkt, dass WebGoat eine Anwendung ist, die absichtlich unsicher gebaut wurde. Man könnte erwarten, dass eine synthetische verwundbare Anwendung eine extrem große Anzahl von ausnutzbaren CVEs aufweist. Tatsächlich stimmen diese Ergebnisse mit dem überein, was bisher über CVEs bekannt ist – auch im Jahr 2023 sind in den meisten Fällen die Anwendbarkeitsbedingungen für die Ausnutzung der CVEs nicht erfüllt.

Der erste Grund dafür, dass so viele nicht ausnutzbare kritische CVEs gefunden wurden, ist, dass Webgoat darauf ausgelegt ist, unsichere logische Fehler im First-Party Code der Anwendung zu enthalten und nicht Sicherheitsprobleme, die durch verwundbare Software-Komponenten verursacht werden. Daher wird die Anzahl der ausnutzbaren CVEs und der potenziell ausnutzbaren CVEs nicht durch die Tatsache beeinflusst, dass Webgoat eine verwundbare Anwendung ist. Darüber hinaus reicht das Vorhandensein einer verwundbaren Komponente in Webgoat, wie in jeder anderen Anwendung, nicht aus, um eine Verwundbarkeit auszunutzen. Zusätzliche Parameter, die den Kontext der Schwachstelle darstellen wie Konfigurationen, Betriebsumgebungen und die Art und Weise, wie die Anwendung die verwundbare Komponente verwendet, sind die einflussreichsten Faktoren für die Ausnutzung der Schwachstelle. Obwohl es also eine große Anzahl von CVEs und verwundbaren Komponenten gibt, sind nur wenige von ihnen tatsächlich ausnutzbar. Die Autoren von Webgoat haben die notwendigen Voraussetzungen, wie die Verwendung angreifbarer Funktionen von Drittanbietern, einfach nicht eingebaut oder das System so konfiguriert, dass die betroffene Komponente nicht ausgeführt wird.

Weiter Informationen über die Untersuchung finden sich hier: https://jfrog.com/blog/testing-the-actual-security-of-the-most-insecure-docker-application/

#JFrog