Fief-server Server-Side Template Injection vulnerability
Dieser Beitrag wurde aus dem Englischen übersetzt. Zum Originalbeitrag.
Im vergangenen Jahr führte ich einen Penetrationstest einer Webanwendung durch, die für die Generierung von Softwarelizenzen zuständig ist.
Benutzer konnten sich für diesen Service registrieren und nach Freigabe durch einen Administrator oder privilegierten Nutzer darauf zugreifen.
Nach der Freigabe konnten sie entsprechend ihrer Anforderungen neue Lizenzen anfordern.
Die Anwendung nutzte das Open-Source-Projekt Fief für Authentifizierung und Autorisierung.
Während des Penetrationstests wurden mehrere Befunde im Bereich Autorisierung identifiziert.
Dieser Artikel konzentriert sich jedoch auf eine Server-Side Template Injection (SSTI)-Schwachstelle, die zu Remote Code Execution (RCE) führte.
Was ist Fief?
Laut der offiziellen Fief-Website:
„Fief ist eine Open-Source-Plattform zur Verwaltung von Benutzern und Authentifizierung in Anwendungen. Unser Ziel ist es, User-Management und Sicherheit in wenigen Minuten statt in Tagen zu ermöglichen.“
Einrichtung der Testumgebung
Zur Einrichtung der Testumgebung kann eine Docker Compose Datei verwendet werden.
Nach dem Herunterladen und Starten ist die Anwendung unter folgender URL erreichbar: http://localhost:8000/login mit dem Benutzernamen test@test.com und dem Passwort fief123fief.
Details zur Schwachstelle
Wichtig ist, dass sich jeder Benutzer registrieren und einen eigenen Workspace innerhalb des Systems erstellen kann.
Zusätzlich haben Nutzer die Möglichkeit, das Fief-Management-System mit einer eigenen gehosteten Datenbank zu verbinden – was weitere Sicherheitsrisiken mit sich bringt – oder alternativ den Cloud-Service von Fief zu verwenden.
Ein zentraler Angriffspunkt sind die E-Mail-Templates, insbesondere der Bereich zur Anpassung unter:
/customization/emailtemplates/.
Dort stehen verschiedene Templates zur Auswahl.
Bei der Analyse des Template-Editors fällt auf, dass eingehende Inhalte im Kommentar-Editor direkt gerendert werden.
Ein einfacher Cross-Site-Scripting (XSS)-Payload wie <script>alert('xss')</script> wird ohne weitere Validierung ausgeführt, was auf fehlende Eingabevalidierung hinweist (Self-XSS).
Kritischere Schwachstelle: SSTI
Deutlich gravierender ist jedoch eine Server-Side Template Injection (SSTI).
Webanwendungen verwenden Template-Engines, um dynamische Inhalte für Webseiten und E-Mails zu generieren.
Wenn benutzergesteuerte Eingaben ohne ausreichende Sanitization direkt in Templates eingebunden werden, entsteht eine SSTI-Schwachstelle.
Im Gegensatz zu XSS, das clientseitig wirkt, ermöglicht SSTI Angreifern, serverinterne Prozesse zu manipulieren – bis hin zur vollständigen Kompromittierung.
Die Auswirkungen reichen von Informationsabfluss bis hin zu Remote Code Execution (RCE), wodurch die Anwendung als Ausgangspunkt für weitere Angriffe missbraucht werden kann.
Identifizierung von SSTI
Wie von James Kettle beschrieben (Artikel), gibt es verschiedene Methoden zur Identifikation der verwendeten Template-Engine.
In diesem Fall zeigt ein Blick in den Quellcode, dass als Backend Jinja eingesetzt wird.
https://portswigger.net/cms/images/migration/blog/screen-shot-2015-07-20-at-09-21-56.png
Zur Überprüfung auf SSTI können typische Payloads verwendet werden, z. B.:
Wenn die Anwendung den Wert 49 zurückgibt, wird die Eingabe vom Server als Template interpretiert – ein klarer Indikator für eine SSTI-Schwachstelle.
Standardmäßig erlaubt die Jinja-Umgebung den Zugriff auf potenziell unsichere Attribute und Methoden wie __init__, was die Ausnutzung erheblich erleichtert.
Angreifer können dadurch beispielsweise:
-
interne Konfigurationen auslesen
-
Dateien auf dem Server lesen
-
Systembefehle ausführen
Im Extremfall führt dies zu Remote Code Execution, wodurch vollständige Kontrolle über den Server erlangt werden kann.
Remediation
Die Schwachstelle wurde behoben, indem das Rendering der E-Mail-Templates auf eine Jinja Immutable Sandboxed Environment umgestellt wurde.
Diese verhindert explizit den Zugriff auf unsichere Methoden und Attribute sowie Modifikationen an internen Objekten.
Eine solche Sandbox-Umgebung unterbindet kritische Operationen und sorgt dafür, dass unsicherer Template-Code nicht ausgeführt werden kann.
Die entsprechenden Änderungen zur Behebung der Schwachstelle sowie der vollständige Vulnerability Report sind öffentlich dokumentiert.
.png?width=327&height=160&name=04_04%201%20(1).png)
