TYPO3-Sicherheitslücke im Backend-Lesezeichensystem: Wie ein einziger Klick das gesamte System blockieren kann
Die Stabilität und Zuverlässigkeit von Content-Management-Systemen wie TYPO3 ist geschäftskritisch, besonders wenn mehrere Administratoren Zugriff auf zentrale Funktionen des Backends haben. Im Rahmen eines Kundenprojektes haben wir eine relevante Schwachstelle in TYPO3 bis einschließlich Version 12.4.6 entdeckt, die zeigt, wie wichtig eine sorgfältige Eingabevalidierung gerade im Administratorbereich ist.
Durch unzureichende Überprüfung von Eingaben lässt sich im TYPO3-Backend über die Lesezeichen-Symbolleiste manipulierte Daten einschleusen. Nutzt ein Administrator diese Lücke gezielt aus oder geschieht dies versehentlich, kann ein fehlerhafter Dateneintrag in der Datenbank das komplette TYPO3-Backend für alle Nutzer unzugänglich machen. Das Team steht dann vor der Herausforderung, den Fehler manuell direkt in der Datenbank zu beheben, um die eigene Website-Verwaltung wiederherzustellen.
In diesem Blogbeitrag erfahren Sie, wie genau diese Schwachstelle im Lesezeichen-System von TYPO3 entsteht, welches Risiko daraus für Ihr Unternehmen entsteht und welche Maßnahmen Sie jetzt ergreifen sollten. Sie möchten mehr über gezielte Schwachstellenanalysen in Ihren Webanwendungen erfahren? Sprechen Sie uns gern an, wir helfen Ihnen, Ihre Systeme zuverlässig abzusichern.
TYPO3 bis Version 12.4.6 ermöglicht es aufgrund unzureichender Eingabevalidierung, dass manipulierte Daten, die in der Lesezeichen-Symbolleiste der Backend-Benutzeroberfläche gespeichert sind, einen allgemeinen Fehlerzustand verursachen und den weiteren Zugriff auf die Oberfläche blockieren. Um diese Schwachstelle auszunutzen, ist ein Backend-Benutzerkonto mit Administratorrechten erforderlich.
Beschreibung
Das Typo3-Backend ermöglicht das Speichern von Lesezeichen über die Symbolleiste.
Die Anfrage zum Erstellen eines Lesezeichens wird nicht überprüft.
In der Regel wird ein JSON-Objekt mit den erforderlichen Daten für den Parameter „argument” an den Server gesendet. Der Parameter „routeIdentifier” muss einen von mehreren möglichen Werten enthalten (z. B. „record_edit” oder „media_management”).
Um den DoS-Angriff durchzuführen, muss der Wert des Parameters „arguments” (ein gültiges Beispiel ist im folgenden Code-Block dargestellt) auf einen ungültigen Wert gesetzt werden. Ein ungültiger Wert ist jede Eingabe, die nicht im JSON-Format vorliegt oder kein edit-Attribut enthält, wenn routeIdentifier=record_edit.
{„id“:„2:\/formupload\/form_83e41043ea5be264fff30338878dae08a8231305\/“}
Nach der Änderung eines Datenbankeintrags mit dem Wert routeIdentifier=record_edit ist das Typo3-Backend nicht mehr nutzbar. Da Admin-Benutzer die Möglichkeit haben, diese Lesezeichen global für alle Benutzer zu definieren, führt dies dazu, dass das Backend für alle unzugänglich ist.
Der fehlerhafte Datenbankeintrag muss manuell korrigiert werden, um die Funktionalität der Anwendung wiederherzustellen.
Zugewiesene CVE: https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2024-34537
Betroffene Komponente: https://github.com/TYPO3/typo3 (typo3/cms-backend)
Angriffstyp: Remote
Auswirkung Codeausführung: Falsch
Angriffsvektoren: Um die Schwachstelle auszunutzen, benötigt ein Angreifer ein gültiges Benutzerkonto in der Typo3-Backend-Instanz mit den Rechten zum Erstellen eines Lesezeichens vom Typ record_edit. Nach dem Angriff kann kein Benutzer mehr auf das Typo3-Backend zugreifen, bis der bösartige Eintrag direkt in der Datenbank korrigiert wurde.
Referenz: https://github.com/TYPO3/typo3/security/advisories/GHSA-ffcv-v6pw-qhrp
