Technischer Hintergrund von CVE-2013-7285
Wie angreifbar ist die "unsicherste" Docker-Anwendung wirklich?
Das JFrog Security Research Team analysiert die Ausnutzbarkeit von Schwachstellen anhand der bewusst unsicher konzipierten Docker-Anwendung "WebGoat"
Bereits die frühere Untersuchung der Ausnutzbarkeit von CVEs (Common Vulnerabilities and Exposures) in den wichtigsten DockerHub-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 OWASP 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 zehn kritischen CVEs, die von den Ergebnissen der Kontextanalyse als anwendbar gemeldet wurden. Die Ausnutzbarkeitsbedingungen für diese zehn 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 Remotecode-Ausführung durchgeführt werden konnte.
CVE-2022-22965 (SpringShell)
Eine weitere sehr bedeutsame gemeldete CVE ist die berühmte SpringShell – eine Klassenlader-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 Sie hier: https://jfrog.com/blog/testing-the-actual-security-of-the-most-insecure-docker-application/ (JFrog: ra)
eingetragen: 24.03.23
Newsletterlauf: 21.06.23
JFrog: Kontakt und Steckbrief
Der Informationsanbieter hat seinen Kontakt leider noch nicht freigeschaltet.
