CVE-2025-32432: Nicht authentifizierte Remote-Codeausführung in Craft CMS

Durch eine detaillierte Analyse dieses Workflows haben unsere Mitarbeiter festgestellt, dass die Methode AssetsController::actionGenerateTransform immer dann aufgerufen wird, wenn eine POST-Anfrage an den exponierten Endpunkt gesendet wird. Diese Funktion ruft den Parameter „handle” direkt aus dem Anfragetext ab und leitet ihn zur weiteren Verarbeitung in der nächsten Stufe weiter.

Im nächsten Schritt wird die Methode ImageTransforms::normalizeTransform() aufgerufen. Diese Methode nimmt den vom Benutzer bereitgestellten Handle-Parameter und wandelt ihn in ein ImageTransform-Objekt um. Da das Objekt direkt aus nicht vertrauenswürdigen Eingaben erstellt wird, stellt dies einen kritischen Risikopunkt im Ausführungsablauf dar.

Während dieses Vorgangs werden alle Schlüssel-Wert-Paare aus dem benutzergesteuerten $transform-Array (das aus dem Handle-Parameter stammt) in ein Konfigurations-Array zusammengeführt. Die Methode normalizeTransform übergibt dieses Array dann an Craft::createObject(), das für die Instanziierung eines neuen ImageTransform-Objekts zuständig ist.

Die Schwachstelle ergibt sich aus der Art und Weise, wie Craft::createObject() ( das Yii::createObject() von Yii umschließt) Konfigurationsarrays verarbeitet. Da dieser Mechanismus den DI-Container verwendet, um Objekte direkt aus dem nicht validierten Array zu instanziieren und zu konfigurieren, können Angreifer die Kontrolle über den Objektkonstruktionsprozess erlangen.

Wenn eine bösartige Nutzlast übergeben wird, ruft der Konstruktor des Objekts (geerbt von der Klasse „Model“ ) die Methode „App::configure() “ auf.

Diese Methode durchläuft jede Eigenschaft im vom Angreifer kontrollierten Array und weist sie dem neuen Objekt zu.

When App::configure() assigns properties from the attacker-controlled configuration array, most keys are mapped directly onto the object. However, if a key begins with the prefix as, the assignment is routed through Component::__set, Yii’s magic setter. This method interprets as <name> as an instruction to attach a behavior (mixin) to the object.

Eine solche bösartige Nutzlast kann so gestaltet werden, dass sie die Art und Weise ausnutzt, wie Component::__set Eigenschaften mit dem Präfix „as“ verarbeitet, wie beispielsweise „as exploit“:

Unsere Analyse hat ergeben, dass die Implementierung von Component::__set eine Sicherheitsvorkehrung enthält: Wenn ein Verhalten über eine solche Eigenschaft angehängt wird, überprüft das Framework, ob die im Konfigurationsarray angegebene Klasse eine gültige Unterklasse von yii\base\Behavior ist. Diese Überprüfung soll verhindern, dass beliebige Klassen direkt an Komponenten angehängt werden.

Diese Sicherheitsmaßnahme ist jedoch nicht so wirksam, wie es scheint. Die Schwachstelle liegt darin, wie Yii::createObject Konfigurationsarrays verarbeitet.

Bei der Instanziierung eines Objekts gibt Yii::createObject dem speziellen Parameter __class Vorrang. Ist dieser Schlüssel vorhanden, wird sein Wert als Zielklasse für die Instanziierung verwendet, und der Standardklassen-Schlüssel im Konfigurationsarray wird ignoriert.

Der Angreifer kann eine Nutzlast für das Exploit-Verhalten erstellen, die zwei Schlüssel enthält:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' – Eine gültige Klasse, die yii\base\Behavior erweitert. Dieser Wert dient ausschließlich dazu, die is_subclass_of-Prüfung in Component::__set zu erfüllen, sodass die Ausführung ohne Fehlermeldung fortgesetzt werden kann.
2. '__class' => '\yii\rbac\PhpManager' – Das eigentliche Ziel des Angreifers. Dies ist die „Gadget“-Klasse, die er instanziieren möchte.

Wenn der Code ausgeführt wird, besteht Component::__set die Sicherheitsprüfung, da nur der Klassenschlüssel überprüft wird. Wenn das Framework jedoch später Yii::createObject aufruft, um das Verhalten anzuhängen, gibt es __class Vorrang, was dazu führt, dass stattdessen das vom Angreifer gewählte Objekt \yii\rbac\PhpManager instanziiert wird.

Die Verwendung von \yii\rbac\PhpManager ist beabsichtigt. Das bloße Erstellen eines Objekts reicht für die Ausnutzung nicht aus; um RCE zu erreichen, ist eine Gadget-Klasse mit Nebenwirkungen erforderlich, die als Waffe eingesetzt werden können. PhpManager ist aufgrund seines Initialisierungsablaufs ein häufiges Ziel von POI-Angriffen (PHP Object Injection). Bei der Instanziierung ruft seine init() -Methode load() auf, die dann loadFromFile($this->itemFile) aufruft. Mit der Kontrolle über $this->itemFile kann ein Angreifer die Anwendung zwingen, eine schädliche Datei zu laden, wodurch die Objekterstellung in eine Codeausführung umgewandelt wird.

Die Gefahr liegt in der Methode „loadFromFile“. In PHP führt „require“ die Zieldatei als Code aus. Wenn ein Angreifer also den Dateipfad kontrolliert, kann er die Ausführung von beliebigem Code auslösen.

Um bösartigen Code auf dem Server zu platzieren, nutzt der Angreifer PHP-Sitzungsdateien aus. Durch das Einfügen von PHP in einen Anfrageparameter speichert Craft CMS die Nutzlast während des Umleitungsprozesses in einer Sitzungsdatei. Später, wenn PhpManager diese Datei lädt, könnte der Code des Angreifers ausgeführt werden.

Die gesamte Angriffskette läuft in drei Schritten ab. Zunächst platziert der Angreifer bösartiges PHP, indem er eine manipulierte URL sendet, die Craft CMS in einer Sitzungsdatei speichert. Als Nächstes nutzt er die __class-Umgehung im Bildtransformations-Endpunkt aus, um das PhpManager-Gadget zu laden und es auf die manipulierte Sitzungsdatei zu verweisen. Wenn PhpManager schließlich die Datei lädt, wird die Payload des Angreifers ausgeführt, wodurch er RCE und die vollständige Kontrolle über den Server erhält – häufig über eine Webshell oder Reverse-Shell.