Eine weitere RCE-Sicherheitslücke stört die Java-Anwendungs-Community

Eine weitere Zero-Day-Schwachstelle, im Zusammenhang mit der Ausführung von Remote-Code (RCE), sorgt für Aufruhr in der Community der Java-Anwendungs-Experten, nach der Veröffentlichung einer Sicherheitslücke im weit verbreiteten Spring Framework für die Erstellung dieser Anwendungen.

Bekannt als Spring4Shell, ermöglicht die Schwachstelle einem Angreifer per Fernzugriff beliebigen Code auf dem Zielserver auszuführen. Sie ermöglicht Angreifern, eine RequestMapping-Anmerkung auszunutzen, die eingehende HTTP-Anfragen den entsprechenden Handler-Funktionen zuordnet. Der gefährdete Zustand entsteht, wenn RequestMapping in Verbindung mit herkömmlichen Java-Objekten als Handler-Parameter verwendet wird.

Ein derartiger Angriff könnte den Zugriff auf alle internen Daten der Website ermöglichen, einschließlich aller Datenbanken. Er kann auch den Zugriff auf zusätzliche interne Ressourcen ermöglichen, um mehr Berechtigungen zu erhalten oder auf andere Teile des internen Netzes zuzugreifen. Die betroffenen Java-Anwendungen setzen Versionen 5.3.17 oder 5.2.19 des Spring Framework und Version 9 oder höher des Java Development Kit (JDK) ein.

Die Aufdeckung der Spring4Shell-Schwachstelle folgt direkt auf die Ausnutzung von RCE in der Open Source Log4j-Software Log4Shell, auf die sich viele Unternehmen bei der Verwaltung der Protokolle verlassen, die von einer Java-Anwendung erstellt wurden. Nach der Entdeckung dieser Schwachstelle haben die Sicherheitsforscher offenbar ihre Bemühungen verstärkt, weitere RCE-Schwachstellen in Java-Anwendungen zu entdecken.

Verlagerung nach links zum Beheben von Schwachstellen

Niemand kann mit Sicherheit sagen, ob es mehr Schwachstellen wie diese gibt, aber Cybersecurity-Teams sollten sich gut auf das Schlimmste vorbereiten. Neben der Modernisierung von Vorfallsmanagementprozessen haben viele Organisationen die Einführung von DevSecOps-Best-Practices beschleunigt, die mehr Verantwortung für die Anwendungssicherheit nach links in Richtung Entwickler verlagern. Schließlich sind die Entwickler nicht nur diejenigen, die diese Schwachstellen beheben müssen, sondern sie können in der Regel auch besser einschätzen, welche laufenden Anwendungen an welcher Stelle betroffen sein könnten.

Es gibt natürlich viele Diskussionen darüber, wie weit man die Verantwortung für die Anwendungssicherheit nach links verlagern sollte. Theoretisch sind jetzt viele Entwickler für die Verwaltung des gesamten Lebenszyklus einer Anwendung verantwortlich, einschließlich aller Sicherheitsupdates. Das Problem ist, dass die meisten Entwickler nicht viel Sicherheits-Know-how haben. Es wird dafür plädiert, stattdessen verschiedene Arten von Code-Analyse-Tools in die Continuous Integration/Continuous Delivery (CI/CD) Plattformen einzubetten, die viele Organisationen heute zur Verwaltung der Anwendungsentwicklung einsetzen. Anstatt einer vollständigen Verlagerung nach links lehnen sich die Betriebsteams, die Entwickler unterstützen, tatsächlich weiter nach links in einer Weise, die nicht erfordert, dass Entwickler zu Sicherheitsexperten werden.

Unabhängig von der Herangehensweise hat eine genaue Überprüfung von Software-Lieferketten im Zuge einer Reihe von spektakulären Verstößen bereits zugenommen, die dazu führten, dass die Biden-Administration eine Durchführungsverordnung erließ, die strengere Praktiken vorschreibt. Das eigentliche Problem besteht nun darin zu bestimmen, welche älteren Anwendungen trotz des Potenzials weiterer Zero-Day-Schwachstellen bleiben sollten, anstatt sie durch neuere Anwendungen zu ersetzen, die in einer Programmiersprache entwickelt wurden, die an sich sicherer sein könnte.

Das Problem ist, dass die Zahl der bekannt gewordenen Zero-Day-Schwachstellen ständig zunimmt. Leider schenken Cyberkriminelle diesen Offenlegungen viel mehr Aufmerksamkeit als viele der betroffenen Unternehmen. In vielen Fällen werden Zero-Day-Schwachstellen überhaupt nicht verfolgt. Schließlich kann der Prozentsatz der Anwendungen, die von einer Zero-Day-Schwachstelle betroffen sind, relativ gering sein.