CVE-2025-32432: Esecuzione di codice remoto non autenticato in Craft CMS

Attraverso un'analisi dettagliata di questo flusso di lavoro, i nostri colleghi hanno identificato che il metodo AssetsController::actionGenerateTransform viene richiamato ogni volta che viene inviata una richiesta POST all'endpoint esposto. Questa funzione recupera il parametro handle direttamente dal corpo della richiesta e lo inoltra a valle per un'ulteriore elaborazione nella fase successiva.

Nel passaggio successivo, viene richiamato il metodo ImageTransforms::normalizeTransform(). Questo metodo prende il parametro handle fornito dall'utente e lo converte in un oggetto ImageTransform. Poiché l'oggetto viene creato direttamente da un input non attendibile, ciò rappresenta un punto critico di rischio nel flusso di esecuzione.

Durante questo processo, tutte le coppie chiave-valore dell'array $transform controllato dall'utente (proveniente dal parametro handle) vengono unite in un array di configurazione. Il metodo normalizeTransform passa quindi questo array a Craft::createObject(), che è responsabile dell'istanziazione di un nuovo oggetto ImageTransform.

La vulnerabilità deriva dal modo in cui Craft::createObject() (che racchiude Yii::createObject() di Yii) elabora gli array di configurazione. Poiché questo meccanismo utilizza il contenitore DI per istanziare e configurare oggetti direttamente dall'array non convalidato, gli aggressori potrebbero ottenere il controllo sul processo di costruzione degli oggetti.

Quando viene passato un payload dannoso, il costruttore dell'oggetto (ereditato dalla classe Model ) richiama il metodo App::configure().

Questo metodo esegue un'iterazione su ciascuna proprietà dell'array controllato dall'autore dell'attacco e le assegna al nuovo oggetto.

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.

Uno di questi payload dannosi può essere creato per sfruttare il modo in cui Component::__set elabora le proprietà con prefisso as, come ad esempio exploit:

Dalla nostra analisi, l'implementazione di Component::__set include una misura di sicurezza: quando un comportamento viene associato tramite tale proprietà, il framework verifica che la classe specificata nell'array di configurazione sia una sottoclasse valida di yii\base\Behavior. Questo controllo ha lo scopo di impedire che classi arbitrarie vengano associate direttamente ai componenti.

Tuttavia, questa misura di sicurezza non è così efficace come sembra. La debolezza deriva dal modo in cui Yii::createObject gestisce gli array di configurazione.

Quando si istanzia un oggetto, Yii::createObject dà priorità al parametro speciale __class. Se questa chiave è presente, il suo valore viene utilizzato come classe di destinazione per l'istanziazione e la chiave di classe standard nell'array di configurazione viene ignorata.

L'autore dell'attacco può creare un payload per il comportamento dell'exploit che include due chiavi:

1. 'class' => '\craft\behaviors\FieldLayoutBehavior' - Una classe legittima che estende yii\base\Behavior. Questo valore esiste esclusivamente per soddisfare il controllo is_subclass_of in Component::__set, consentendo l'esecuzione senza generare un errore.
2. '__class' => '\yii\rbac\PhpManager' - Il vero obiettivo dell'autore dell'attacco. Si tratta della classe "gadget" che desidera istanziare.

Quando il codice viene eseguito, Component::__set supera il controllo di sicurezza perché ispeziona solo la chiave della classe. Tuttavia, quando il framework chiama successivamente Yii::createObject per allegare il comportamento, dà la precedenza a __class, con il risultato che viene istanziato invece l'oggetto \yii\rbac\PhpManager scelto dall'autore dell'attacco.

L'uso di \yii\rbac\PhpManager è intenzionale. La semplice creazione di un oggetto non è sufficiente per lo sfruttamento; per ottenere l'RCE è necessaria una classe gadget con effetti collaterali che possano essere utilizzati come arma. PhpManager è un bersaglio comune negli attacchi POI (PHP Object Injection) a causa del suo flusso di inizializzazione. Al momento dell'istanziazione, il suo metodo init() chiama load(), che a sua volta richiama loadFromFile($this->itemFile). Con il controllo su $this->itemFile, un aggressore può forzare l'applicazione a caricare un file dannoso, trasformando la creazione dell'oggetto in esecuzione di codice.

Il pericolo risiede nel metodo loadFromFile. In PHP, un require esegue il file di destinazione come codice, quindi se un aggressore controlla il percorso del file, può attivare l'esecuzione di codice arbitrario.

Per inserire codice dannoso sul server, l'autore dell'attacco sfrutta i file di sessione PHP. Inserendo PHP in un parametro di richiesta, Craft CMS salva il payload in un file di sessione durante il processo di reindirizzamento. Successivamente, quando PhpManager carica questo file, il codice dell'autore dell'attacco potrebbe essere eseguito.

La catena di attacco completa funziona in tre fasi. Innanzitutto, l'autore dell'attacco inserisce un codice PHP dannoso inviando un URL appositamente creato, che Craft CMS salva in un file di sessione. Successivamente, sfrutta il bypass __class nell'endpoint di trasformazione delle immagini per caricare il gadget PhpManager e indirizzarlo verso il file di sessione compromesso. Infine, quando PhpManager carica il file, viene eseguito il payload dell'autore dell'attacco, che ottiene l'RCE e il controllo completo del server, spesso tramite una webshell o una reverse shell.